Sophos Protected Browser für SaaS-Anwendungen erzwingen

Der Zugriff auf kritische SaaS-Anwendungen lässt sich so einschränken, dass er nur über Sophos Protected Browser funktioniert. Entra ID oder Okta authentifiziert die Anfragen und lässt für die ausgewählten Anwendungen nur die kopierten IP-Adressen eines ZTNA-Bereichs der Datenebene zu. Ein Zugriff aus einem anderen Browser wird dadurch blockiert.

Der sichere Ablauf besteht aus vier Teilen: Identitätsanbieter und Anwendungen vorbereiten, die Browserdurchsetzung in Sophos Central aktivieren, die kopierten ZTNA-IP-Adressen beim Identitätsanbieter als vertrauenswürdigen Standort erfassen und die Zugriffsrichtlinie zunächst begrenzt aktivieren. Bei Entra ID begrenzt eine kleine Pilotgruppe den Benutzerkreis. Der dokumentierte Okta-Ablauf enthält dagegen keine entsprechende Gruppenauswahl: Verwende dort eine dedizierte Pilotanwendung oder prüfe vorab ausdrücklich, welche Benutzer der ausgewählten Anwendung zugewiesen sind. Wähle Entra ID oder Okta, nicht beide Abläufe parallel für dieselbe Pilotanwendung.

Sophos bezeichnet diese Aufgabe in der Navigation als Globale Einstellungen > Protected Browser erzwingen. In der beschriebenen Oberfläche führt der konkrete Klickweg über Globale Einstellungen > Produkte und Services > Protected Browser > Browserdurchsetzung. Die offizielle Entra-ID-Anleitung stellt zusätzlich ein Video für diesen Ablauf bereit; die nachfolgenden Schritte sind jedoch vollständig ohne das Video ausführbar.

Voraussetzungen, Lizenz und Zuständigkeit

Kläre vor der Änderung, wer Sophos Central und wer den Identitätsanbieter administriert. Die freigegebenen Quellen nennen keine eigene Sophos-Lizenz oder konkrete Sophos-Central-Rolle für diesen Ablauf. Erfinde daraus keine Berechtigung: Das zuständige Konto muss den Bereich Globale Einstellungen > Produkte und Services > Protected Browser > Browserdurchsetzung öffnen und die Einstellungen ändern können. Fehlt der Menüpunkt oder die Änderungsmöglichkeit, ist dies ein Berechtigungs- oder Produktzugangsproblem, das vor dem Rollout geklärt werden muss.

Für Entra ID gelten diese belegten Voraussetzungen:

Microsoft Entra ID P1-Lizenz.
Entra ID ist als föderierter Identitätsprovider in Sophos Central hinzugefügt.
Die zu schützenden Anwendungen sind in Entra ID hinzugefügt.
SAML ist in Entra ID für die Benutzerauthentifizierung konfiguriert.
Das Konto, das die Browserdurchsetzung in Entra ID einrichtet, ist Administrator.

Für Okta gelten diese Voraussetzungen:

Okta ist als föderierter Identitätsprovider in Sophos Central hinzugefügt.
Die zu schützenden Anwendungen sind in Okta hinzugefügt.
SAML ist in Okta für die Benutzerauthentifizierung konfiguriert.
Das Konto, das die Browserdurchsetzung in Okta einrichtet, ist Administrator.

Ausserdem braucht man für beide Varianten einen auswählbaren Bereich der Datenebene. Die Anleitung setzt diesen ZTNA-Bereich voraus, beschreibt aber weder seine Erstellung noch allgemeine ZTNA-, Verzeichnis- oder Rollenverwaltung.

Vor dem Pilot notieren: ausgewählter Identitätsanbieter, ZTNA-Bereich, kopierte IP-Liste und Pilotanwendung. Halte bei Entra ID zusätzlich Testbenutzer oder Testgruppe fest. Dokumentiere bei Okta stattdessen die der Pilotanwendung zugewiesenen Benutzer. Drittanbieter-Menüs ändern sich unabhängig von Sophos. Vergleiche deshalb die hier genannten Entra-ID- beziehungsweise Okta-Pfade vor der produktiven Aktivierung mit der aktuellen Herstellerdokumentation.

Entra ID für die Browserdurchsetzung konfigurieren

Entra ID authentifiziert Anfragen an login.microsoftonline.com und führt den zugelassenen Verkehr durch den gewählten ZTNA-Bereich. Verwende für den ersten Test nur eine Pilotanwendung und eine kleine Testgruppe. So bleibt eine fehlerhafte Bedingung begrenzt.

Entra ID im Protected Browser aktivieren

Öffne Globale Einstellungen > Produkte und Services > Protected Browser.
Klicke auf Browserdurchsetzung.
Aktiviere Entra ID.
Wähle unter Bereich der Datenebene den ZTNA-Bereich aus, der für die Authentifizierung verwendet werden soll.
Klicke auf IP-Liste kopieren. Diese IP-Adressen werden im nächsten Schritt als benannter Standort hinterlegt.

Wichtig bei einer später installierten Erweiterung: Wenn die Protected-Browser-Erweiterung erst nach der Browserdurchsetzung mit Entra ID installiert wird, muss man Entra ID in dieser Einstellung deaktivieren und anschliessend wieder aktivieren.

In Entra ID einen benannten Standort erstellen

Öffne in Entra ID Enterprise-Anwendungen > Bedingter Zugriff.
Wähle Benannte Standorte und klicke auf IP-Bereichsstandort.
Vergib einen eindeutigen Namen, beispielsweise Sophos-PB-ZTNA-Pilot. Der Name ist frei wählbar; er sollte den zugehörigen ZTNA-Bereich und den Zweck erkennen lassen.
Klicke auf das Plus-Symbol und füge die zuvor mit IP-Liste kopieren übernommenen IP-Adressen ein.
Klicke auf Erstellen.

Kontrolliere die eingefügten Werte gegen die notierte IP-Liste. Eine alte oder unvollständige Liste würde legitimen Protected-Browser-Verkehr blockieren oder einen falschen Standort ausnehmen.

Bedingte Richtlinie erstellen

Bleibe unter Enterprise-Anwendungen > Bedingter Zugriff, wähle Richtlinien und klicke auf Neue Richtlinie.
Vergib einen Namen, beispielsweise SaaS nur via Protected Browser - Pilot.
Öffne Benutzer > Einbeziehen > Benutzer und Gruppen auswählen, klicke auf Benutzer und Gruppen und wähle nur die Pilotbenutzer oder Pilotgruppe.
Öffne Zielressourcen > Einbeziehen, klicke auf Ressourcen auswählen und wähle zunächst nur die Pilotanwendung.
Öffne Netzwerk und setze Konfigurieren auf Ja.
Wähle unter Einbeziehen die Option Jedes Netzwerk oder jeder Standort.
Wähle unter Ausschliessen die Option Ausgewählte Netzwerke und Standorte und dann den zuvor erstellten benannten Standort.
Öffne Gewähren, wähle Zugriff blockieren und klicke auf Auswählen. Damit werden alle einbezogenen Zugriffe ausserhalb des benannten ZTNA-Standorts blockiert.
Setze Richtlinie aktivieren auf Ein und klicke auf Erstellen.

Prüfe vor dem letzten Schritt nochmals die Kombination aus Testbenutzern, Pilotanwendung und ausgenommenem ZTNA-Standort. Eine zu breite Auswahl kann den direkten SaaS-Zugriff vieler Benutzer sofort blockieren.

Okta für die Browserdurchsetzung konfigurieren

Bei Okta gibt man in Sophos Central die Domain an, welche die Anfragen zum Anwendungszugriff empfängt. Okta authentifiziert diese Anfragen und führt zugelassenen Verkehr durch den ausgewählten ZTNA-Bereich. Anders als im beschriebenen Entra-ID-Ablauf wird die Okta-Richtlinie hier nicht auf eine Pilotgruppe begrenzt. Bereite deshalb eine dedizierte Pilotanwendung vor. Falls stattdessen eine bereits produktiv verwendete Anwendung ausgewählt werden soll, prüfe und dokumentiere vor der Änderung ausdrücklich ihre Anwendungszuweisungen.

Okta im Protected Browser aktivieren

Öffne Globale Einstellungen > Produkte und Services > Protected Browser.
Klicke auf Browserdurchsetzung.
Aktiviere Okta und gib die Domain ein, welche die Anfragen zum Anwendungszugriff erhält.
Wähle unter Bereich der Datenebene den vorgesehenen ZTNA-Bereich.
Klicke auf IP-Liste kopieren. Diese Adressen werden als Okta-IP-Zone verwendet.

Wichtig bei einer später installierten Erweiterung: Wenn die Protected-Browser-Erweiterung erst nach der Browserdurchsetzung mit Okta installiert wird, muss man Okta deaktivieren und anschliessend wieder aktivieren.

In Okta eine IP-Zone hinzufügen

Öffne in Okta Sicherheit > Netzwerke.
Klicke auf Zone hinzufügen und wähle IP-Zone.
Vergib einen Namen, beispielsweise Sophos-PB-ZTNA-Pilot.
Füge unter Gateway-IPs die aus Sophos Central kopierten IP-Adressen des ZTNA-Bereichs ein.
Klicke auf Speichern.

In Okta eine Richtlinie für bedingten Zugriff erstellen

Auswirkung vor dem Bearbeiten prüfen: Die Catch-all-Regel gilt für alle Benutzer, die der ausgewählten Anwendung zugewiesen sind. Wird sie bei einer produktiven Anwendung auf Verweigert gesetzt, kann dies deren Zugriff ausserhalb der erlaubten ZTNA-IP-Zone für alle zugewiesenen Benutzer blockieren. Fahre nur mit einer dedizierten Pilotanwendung oder mit einer vorab geprüften und dokumentierten Anwendungszuweisung fort.

Öffne Sicherheit > Authentifizierungsrichtlinien und klicke auf App-Anmeldung.
Klicke auf Richtlinie erstellen, vergib beispielsweise den Namen SaaS nur via Protected Browser - Pilot und klicke erneut auf Richtlinie erstellen.
Klicke unter Regeln neben der Catch-all-Regel unter Aktionen auf Bearbeiten.
Setze Dann ist der Zugriff auf auf Verweigert und klicke auf Speichern.
Klicke auf Regel hinzufügen und vergib einen eindeutigen Namen.
Setze Die IP des Benutzers ist auf In einer der folgenden Zonen und wähle die zuvor erstellte IP-Zone.
Setze Dann ist der Zugriff auf auf Erlaubt nach erfolgreicher Authentifizierung und klicke auf Speichern.
Wähle unter Anwendungen nur die dedizierte Pilotanwendung beziehungsweise die Anwendung mit der zuvor geprüften Zuweisung aus und klicke auf Speichern.

Die Reihenfolge ist sicherheitsrelevant: Die Catch-all-Regel verweigert den Zugriff für die der Anwendung zugewiesenen Benutzer; die zusätzliche Regel erlaubt ihn nur aus der Zone mit den kopierten ZTNA-IP-Adressen und nach erfolgreicher Authentifizierung.

Wirkung mit einem begrenzten Pilot prüfen

Die freigegebenen Quellen nennen keinen eigenen Report als Erfolgssignal. Prüfe deshalb die tatsächliche Zugriffswirkung mit genau dem Benutzer und der Anwendung, die im Pilot enthalten sind:

Melde den Testbenutzer vollständig von der Pilotanwendung ab, damit keine alte Sitzung das Ergebnis verfälscht. Bei Entra ID muss er zur Pilotgruppe gehören; bei Okta muss er der dedizierten oder vorab geprüften Pilotanwendung zugewiesen sein.
Öffne die Pilotanwendung im Protected Browser und authentifiziere den Testbenutzer. Der Zugriff muss nach erfolgreicher Authentifizierung möglich sein.
Öffne dieselbe Anwendung als derselbe Testbenutzer in einem anderen Browser. Dieser Zugriff muss blockiert werden.
Prüfe die Begrenzung passend zum Anbieter: Bei Entra ID darf sich das Verhalten eines Benutzers ausserhalb der Pilotgruppe nicht unbeabsichtigt ändern. Bei Okta darf sich das Verhalten einer anderen, nicht mit dieser Authentifizierungsrichtlinie verknüpften Anwendung nicht ändern. Prüfe ausserdem, dass die dokumentierten Anwendungszuweisungen weiterhin dem beabsichtigten Pilotkreis entsprechen.
Dokumentiere den gewählten ZTNA-Bereich und vergleiche die beim Identitätsanbieter hinterlegte IP-Liste nochmals mit IP-Liste kopieren.

Das Authentifizierungstoken wird vom Identitätsanbieter verwaltet. Dort konfigurierte Sitzungssteuerungen für bedingten Zugriff haben Vorrang. Eine dort festgelegte Anmeldehäufigkeit von zwei Tagen beendet die Sitzung daher nach zwei Tagen. Ist beim Identitätsanbieter keine Sitzungssteuerung konfiguriert, verwendet Protected Browser laut Sophos eine standardmässige Sitzungsablaufzeit von sieben Tagen. Ein bereits vorhandenes Token kann einen Test somit anders erscheinen lassen als eine neue Anmeldung.

Troubleshooting nach Symptom

Ein anderer Browser erhält weiterhin Zugriff

Prüfe zuerst, ob der getestete Benutzer und die richtige SaaS-Anwendung tatsächlich von der Richtlinie erfasst werden. Vergleiche danach die beim Identitätsanbieter erlaubte IP-Zone beziehungsweise den benannten Standort mit der aktuellen, in Sophos Central kopierten IP-Liste. Bei Entra ID muss Jedes Netzwerk oder jeder Standort einbezogen, der benannte ZTNA-Standort ausgeschlossen und für den übrigen Zugriff Zugriff blockieren gewählt sein. Bei Okta muss die Catch-all-Regel verweigern und die erlaubende Regel auf die erstellte IP-Zone begrenzt sein.

Beende bestehende Anwendungssitzungen und teste mit einer neuen Anmeldung. Bleibt der Zugriff möglich, stoppe die Ausweitung des Pilots und prüfe die aktuelle Richtlinienauswertung beim Identitätsanbieter; die Quellen belegen keinen zusätzlichen Sophos-Schalter, mit dem man eine fehlerhafte Drittanbieter-Regel umgehen sollte.

Der Protected Browser wird ebenfalls blockiert

Vergleiche die IP-Adressen aus IP-Liste kopieren Zeichen für Zeichen mit dem benannten Standort oder den Gateway-IPs. Prüfe auch, ob in Sophos Central derselbe Bereich der Datenebene gewählt ist, dessen Adressen beim Identitätsanbieter hinterlegt wurden. Danach kontrollierst du SAML, die ausgewählte Anwendung und den Testbenutzer anhand der Voraussetzungen.

Wurde die Protected-Browser-Erweiterung nachträglich installiert, deaktiviere den konfigurierten Anbieter in Sophos Central und aktiviere ihn anschliessend wieder. Dies ist für Entra ID und Okta ausdrücklich erforderlich. Ändere nicht gleichzeitig ZTNA-Bereich, IP-Liste und Zugriffsrichtlinie; sonst lässt sich die Ursache nicht mehr sauber eingrenzen.

Sitzungen enden früher oder später als erwartet

Prüfe die Sitzungssteuerung und Anmeldehäufigkeit im Identitätsanbieter. Diese Werte haben Vorrang vor dem Sitzungsverhalten des Protected Browser. Erst wenn dort keine Sitzungssteuerung gesetzt ist, gilt die dokumentierte Standardablaufzeit von sieben Tagen.

Drittanbieter-Menüs oder Feldnamen weichen ab

Entra ID und Okta sind Drittanbieterprodukte. Speichere bei einem nicht eindeutig zuordenbaren Menü oder Kontrollfeld keine sinngemäss ähnliche Regel. Vergleiche den Ablauf mit der aktuellen Dokumentation des jeweiligen Anbieters oder eskaliere an dessen Administration beziehungsweise Support. Die sicherste Zwischenmassnahme ist, den produktiven Rollout nicht über den bereits erfolgreich getesteten Pilotumfang hinaus zu erweitern: bei Entra ID die Pilotgruppe, bei Okta die dedizierte beziehungsweise vorab geprüfte Anwendungszuweisung.

Sicherer Rückweg und Offboarding

Die freigegebenen Quellen dokumentieren keinen vollständigen Lösch-, Offboarding- oder Rollback-Ablauf. Lösche deshalb nicht zuerst Standort, IP-Zone oder SAML-Anbindung: Eine solche Reihenfolge könnte die weiterhin aktive Blockierregel ohne passende Ausnahme zurücklassen.

Für jede Rücknahme gilt dieser sichere Rahmen:

Stoppe jede Ausweitung und halte Pilotbenutzer, Pilotanwendung, Identitätsanbieter, ZTNA-Bereich und IP-Liste fest. Sichere bei Entra ID zusätzlich die Pilotgruppe und bei Okta die aktuellen Anwendungszuweisungen.
Ermittle in der aktuellen Entra-ID- oder Okta-Dokumentation den unterstützten Weg, die konkrete Zugriffsrichtlinie kontrolliert ausser Kraft zu setzen.
Setze nur die Pilot-Richtlinie auf dem bestätigten Weg ausser Kraft. Melde den Pilotbenutzer vollständig von der Anwendung ab und authentifiziere ihn neu. Das erwartete Ergebnis ist, dass die Pilotanwendung sowohl im Protected Browser als auch in einem anderen Browser wieder erreichbar ist, sofern keine andere Zugriffsrichtlinie dies verhindert. Bei Entra ID muss ein Benutzer ausserhalb der Pilotgruppe weiterhin unverändert zugreifen können; bei Okta muss eine andere, nicht mit der Pilot-Richtlinie verknüpfte Anwendung unverändert bleiben.
Vergleiche das tatsächliche Ergebnis mit diesen Erwartungen. Weicht auch nur ein Ergebnis ab, stoppe die Rücknahme und lösche keine weiteren Richtlinien, Standorte, IP-Zonen oder Anwendungszuweisungen. Prüfe stattdessen die aktuelle Richtlinienauswertung und eskaliere an die zuständige Administration beziehungsweise den Herstellersupport.
Entferne benannten Standort beziehungsweise IP-Zone erst, wenn das erwartete Ergebnis erreicht ist und keine aktive Richtlinie mehr darauf verweist.
Deaktiviere die Browserdurchsetzung in Sophos Central oder entferne föderierte Identität, SAML oder ZTNA-Komponenten nur im Rahmen ihrer jeweils eigenen, bestätigten Betriebsanleitung.

Kann der unterstützte Deaktivierungsweg beim Identitätsanbieter nicht eindeutig bestätigt werden, ist dies der Stop- und Eskalationspunkt. Ein vermuteter Schalter ist bei einer Richtlinie, die SaaS-Zugriff blockiert, kein sicherer Rückweg.

Betrieb und Lifecycle

Behandle die Browserdurchsetzung als gemeinsame Änderung von Sophos Central, ZTNA-Datenebene und Identitätsanbieter. Nach einem Wechsel des ZTNA-Bereichs oder seiner IP-Adressen muss die beim Identitätsanbieter hinterlegte Liste erneut verglichen und mit einem begrenzten Benutzer getestet werden. Gleiches gilt nach Änderungen an SAML, den geschützten Anwendungen, Benutzer- oder Gruppenzuordnungen und Sitzungssteuerungen.

Nimm die Kontrolle ausserdem in den regulären Review der Entra-ID- beziehungsweise Okta-Richtlinien auf. Dabei sollten der Owner, die ausgewählten Anwendungen, der erfasste Benutzerkreis, der referenzierte Standort und die dokumentierte IP-Liste weiterhin zusammenpassen. Bei Installation der Protected-Browser-Erweiterung ist die oben genannte Reaktivierung des jeweiligen Identitätsanbieters ein eigener Change-Schritt mit anschliessendem Positiv- und Negativtest.

Die Quellen belegen keine pauschale Laufzeit, kein Migrationsdatum und kein End-of-Life-Verhalten für diese Konfiguration. Solche Entscheidungen müssen deshalb anhand der aktuellen Produkt- und Herstellerdokumentation getroffen werden, nicht aus historischen Annahmen.