DNS Protection und ZTNA mit Sophos Protected Browser integrieren

Sophos Protected Browser bindet DNS Protection und ZTNA über zwei getrennte Betriebswege ein. DNS Protection wird nicht im Browser selbst konfiguriert: Sophos Endpoint fängt DNS-Anfragen unterstützter Geräte ab und leitet sie per HTTPS an DNS Protection weiter. Für private oder lokale Anwendungen verbindet sich der Protected Browser dagegen mit dem vorbereiteten ZTNA-Gateway.

Der kurze Ablauf lautet deshalb:

Unter Meine Produkte > Protected Browser prüfen, ob man im richtigen Tenant arbeitet. Auf der Integrationsseite gibt es keinen gemeinsamen DNS-/ZTNA-Schalter.
Die bestehende Endpoint-DNS-Konfiguration anhand der unten genannten Bereitschaftspunkte prüfen und mit einer kleinen Windows-Pilotgruppe testen.
ZTNA mit Identität, Gateway, Ressourcen und Richtlinien vollständig einrichten.
Für agentenlose Anwendungen und Ressourcen ausser RDP und SSH Protected Browser erzwingen aktivieren.
DNS-Auflösung und ZTNA-Zugriff getrennt positiv und negativ testen. Ein erfolgreicher DNS-Test belegt keinen funktionierenden ZTNA-Zugriff und umgekehrt.

Voraussetzungen, Lizenz und Rollen

Für den DNS-Pfad braucht man eine Workspace-Protection-Lizenz, einen installierten Sophos Endpoint Agent und unterstützte Windows-Endpoints. Windows Server und macOS lassen sich der dafür dokumentierten Endpoint-Richtlinie derzeit nicht hinzufügen. Die detaillierte Lizenzabgrenzung ist nicht Teil dieser Integration; vor dem Pilot muss lediglich bestätigt sein, dass Workspace Protection im Tenant verfügbar und Sophos Endpoint auf den Pilotgeräten installiert ist.

Für den ZTNA-Pfad müssen Benutzer und Gruppen, Identitätsanbieter, Gateway, Ressourcen, Richtlinien, DNS und Zertifikate bereits funktionieren. Der Protected Browser ergänzt diesen vorbereiteten Zugriffspfad; er ersetzt keine dieser Grundlagen. Die Reihenfolge und die Abnahme beschreibt Sophos ZTNA einrichten.

Sophos nennt für diese Integrationsseite keine konkrete Administratorrolle. Die ausführende Person benötigt daher nachweislich Zugriff auf die benötigten Endpoint-, DNS-Protection-, ZTNA- und Protected-Browser-Objekte, ohne vorsorglich Super-Admin-Rechte zu erhalten. Fehlt ein Produkt oder ein Steuerelement, werden zuerst Tenant, Lizenz und zugewiesene Berechtigungen geklärt.

Vor dem Pilot werden ausserdem festgehalten:

eine kleine Benutzer- und Gerätegruppe;
eine erlaubte sowie eine bewusst blockierte öffentliche Testdomain;
ein interner Name, der weiterhin über den lokalen DNS-Dienst aufgelöst werden muss;
eine erlaubte ZTNA-Testressource und ein nicht berechtigter Testbenutzer;
der bisherige Resolver- und Zugriffspfad als Rückweg;
Zeitpunkt, zuständige Person und erwartetes Ergebnis jeder Änderung.

DNS Protection für den Protected Browser bereitstellen

Die Seite unter Meine Produkte > Protected Browser ist für DNS Protection eine Wegweiserseite. Sie enthält keine lokale DNS-Konfiguration. Installation, Paketstand, vollständige Endpoint-Richtlinie, Locations, Filterung, Domänenausnahmen, Blockseiten, Fehlersuche und Rücknahme sind deshalb zentral in Sophos DNS Protection für Endpoints konfigurieren beschrieben.

Für diese Protected-Browser-Integration genügt vor dem Pilot eine Bereitschaftsprüfung:

Auf den Pilotgeräten ist die DNS-Komponente installiert; je nach Lizenz kann sie DNS und ZTNA heissen.
Die den Pilotgeräten oder -gruppen zugewiesene Endpoint-Richtlinie ist aktiv und Sophos DNS Protection verwenden ist eingeschaltet.
Die ausgewählte Default location oder eine eigene Location verwendet die Verbindungsmethode Secure DNS. Eine neu erstellte Location darf für diesen Endpoint-Pfad nicht mit einer anderen Verbindungsmethode verwendet werden.
Die erwartete Filterrichtlinie ist der Location zugeordnet. Eine Filterrichtlinie kann mehreren Locations oder Firewalls zugeordnet werden, jede einzelne Location jedoch nur einer Filterrichtlinie. Falls die Filterung überprüft werden muss, gelten ausserdem diese Grenzen: DNS Protection unterstützt maximal 50 Filterrichtlinien; Erlauben erlaubt alle Kategorien einer Gruppe, Blockieren blockiert sie und Angeben legt die Aktion pro Kategorie fest. Erstellt und geändert werden Filterrichtlinien nach der verlinkten Anleitung.
Der interne Testname ist dort als Ausnahme berücksichtigt, damit ihn weiterhin der vorgesehene lokale DNS-Dienst auflöst.

Sophos Endpoint fängt danach den DNS-Verkehr ausser den ausgeschlossenen Domains ab und leitet ihn per HTTPS an DNS Protection weiter. Antworten gehen direkt an die Anwendung. Ohne aktivierte Integration verarbeitet der lokale DNS-Dienst die Anfragen wie zuvor. Domänenlisten, NXDOMAIN-Retry und Zertifikatsverteilung werden nicht zusätzlich in diesem Artikel konfiguriert, sondern nach der verlinkten Anleitung geplant und geprüft.

ZTNA für den Protected Browser bereitstellen

ZTNA muss vor der Browserintegration fertig eingerichtet sein. Der Protected Browser verbindet sich mit dem ZTNA-Gateway und ermöglicht dadurch kontrollierten Zugriff auf interne Anwendungen und private Cloud-Umgebungen. Die gemeinsame ZTNA-Konfiguration bleibt im verlinkten ZTNA-Runbook; hier wird sie nicht als zweiter, möglicherweise abweichender Ablauf wiederholt.

Für agentenlosen Zugriff auf Anwendungen und Ressourcen ausser RDP und SSH wird anschliessend Protected Browser erzwingen aktiviert. Sophos dokumentiert dafür keinen belastbaren Menüpfad und keine weiteren Formularfelder. Man verwendet den Schalter deshalb nur in der im eigenen Tenant sichtbaren ZTNA-Konfiguration. Fehlt er, wird die Konfiguration hier nicht weiter geändert, statt einen Pfad aus einer anderen Produktansicht zu erraten.

RDP und SSH sind eine eigene Variante. Dafür verlangt Sophos eine spezifische ZTNA-Konfiguration für agentenlose RDP- beziehungsweise SSH-Ressourcen. Ein allgemeiner Webanwendungs-Test oder das Aktivieren von Protected Browser erzwingen allein belegt diesen Pfad nicht.

Pilot validieren

Die Abnahme trennt DNS und ZTNA bewusst. Zuerst wird genau ein Pilotgerät mit einem berechtigten Benutzer getestet.

DNS-Ergebnis prüfen

Erwartet wird:

Die erlaubte öffentliche Testdomain löst auf und ist erreichbar.
Die blockierte Testdomain wird gemäss der zugewiesenen Filterrichtlinie blockiert.
Der interne Testname geht über den vorgesehenen lokalen DNS-Dienst und bleibt erreichbar.
DNS-Anfragen des Pilotgeräts erscheinen bei der erwarteten Location beziehungsweise in der dazugehörigen DNS-Auswertung.
Eine Anwendung mit eigenem Secure-DNS- oder DNS-over-HTTPS-Verhalten wird separat geprüft, statt aus einem reinen Browsertest auf alle Anwendungen zu schliessen.

Fehlt ein erwarteter Treffer, wird nicht sofort die Filterung gelockert. Zuerst prüft man die installierte Komponente, die effektiv aktive Endpoint-Richtlinie, Sophos DNS Protection verwenden, die Secure-DNS-Location und den tatsächlich verwendeten Resolver. Die weitere DNS-Fehlersuche steht in der verlinkten Anleitung.

ZTNA-Ergebnis prüfen

Mit dem berechtigten Benutzer wird die vorbereitete private Testressource im Protected Browser geöffnet. Erfolg bedeutet, dass Anmeldung, ZTNA-Gateway, Ressourcenzuweisung und Anwendung gemeinsam funktionieren. Danach bestätigt ein Benutzer ausserhalb der freigegebenen Gruppe den Negativfall: Die Ressource darf für ihn nicht verfügbar beziehungsweise nicht erreichbar sein.

Der DNS-Test und der ZTNA-Test werden mit Zeitpunkt und Ergebnis getrennt protokolliert. So bleibt sichtbar, welcher Pfad bei einem späteren Fehler betroffen ist.

Troubleshooting nach Symptom

DNS funktioniert auf dem Pilotgerät nicht

Zuerst prüfen, ob es ein unterstützter Windows-Endpoint ist, ob Sophos Endpoint und die DNS-Komponente installiert sind und ob die effektive aktive Endpoint-Richtlinie Sophos DNS Protection verwenden einschaltet. Danach die ausgewählte Secure-DNS-Location und die HTTPS-Erreichbarkeit von DNS Protection kontrollieren. Windows Server und macOS sind für diesen Endpoint-Richtlinienpfad keine geeigneten Gegenproben. Policy-, Location-, Filter-, Domänen- oder Rücknahmeänderungen werden nach der verlinkten Anleitung durchgeführt.

Wird zur Eingrenzung auch eine netzwerkbasierte Location geprüft, benötigt sie eine gültige öffentliche IPv4-Adresse oder einen auflösbaren Location-FQDN. RFC-1918-Adressen aus 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 sind dafür keine gültigen öffentlichen Adressen. Nicht jede Adresse mit 172. oder 192. am Anfang ist jedoch privat; eine solche Kurzform darf deshalb nicht als Prüfkriterium dienen.

ZTNA-Anmeldung funktioniert, die Anwendung aber nicht

Dann ist DNS Protection nicht der erste Verdacht. Man prüft Benutzer- und Gruppenzuweisung, die ZTNA-Ressource, das ausgewählte Gateway sowie die Erreichbarkeit der Anwendung aus Sicht dieses Gateways. Anschliessend wird bestätigt, dass Protected Browser erzwingen für den vorgesehenen agentenlosen Zugriff aktiv ist. RDP und SSH werden nicht mit dem allgemeinen Webanwendungsweg verglichen.

Fehlt Protected Browser erzwingen oder ist der im Tenant sichtbare Ablauf unklar, wird die Konfiguration an dieser Stelle nicht weiter geändert. Das zuständige ZTNA-Team klärt Lizenz, Berechtigung und aktuelle Produktansicht, bevor Schutzmechanismen umgangen oder Ressourcen neu angelegt werden.

Sicherer Rückweg und Offboarding

DNS und ZTNA werden nicht gleichzeitig zurückgebaut. Vor jeder Rücknahme dokumentiert man Pilotgeräte, betroffenen Pfad, zuständige Person und das letzte erfolgreiche Testergebnis.

Den DNS-Pfad nimmt man ausschliesslich nach dem Rückweg in der verlinkten Anleitung zurück und validiert danach interne wie öffentliche Namensauflösung. Die gemeinsam als DNS und ZTNA bezeichnete Softwarekomponente wird nicht als Sofortmassnahme entfernt, weil dies den ZTNA-Pfad mitbetreffen könnte.

Sophos dokumentiert keinen vollständigen Lösch- oder Rücknahmeablauf für Protected Browser erzwingen. Für ZTNA werden deshalb weder Gateway noch Identitäts-, DNS-, Zertifikats- oder gemeinsam verwendete Richtlinienobjekte als vermeintlicher Sofort-Rollback gelöscht. Muss der Zugriff gestoppt werden, erhält das zuständige ZTNA-Team die betroffene Ressource und Benutzergruppe; anschliessend wird der Negativtest wiederholt. Ohne einen im Tenant bestätigten reversiblen Schritt endet die Rücknahme an diesem Punkt.

Betrieb und regelmässige Prüfung

Nach dem Pilot werden für den DNS- und den ZTNA-Pfad unterschiedliche Personen zuständig. Nach Änderungen an der Endpoint-DNS-Konfiguration sowie an Benutzergruppen, Gateway oder ZTNA-Ressource werden die jeweils betroffenen Positiv- und Negativtests wiederholt. Regelmässig kontrolliert man die Verfügbarkeit von Workspace Protection, die installierte Endpoint-Komponente, die DNS-Bereitschaftspunkte, den ZTNA-Zugriff und den dokumentierten Rückweg.

Für Entscheide zum weiteren Betrieb sind die aktuell im Tenant sichtbare Produktkonfiguration und die aktuelle Hilfe der jeweiligen Komponente massgeblich. Aus historischen Ankündigungen werden keine Migrationsfristen, Abschalttermine oder EOL-Daten abgeleitet. Ändert Sophos eine Voraussetzung oder Produktansicht, wird zuerst der Pilot erneut durchgeführt, bevor man den breiten Rollout anpasst.