Mit Identity Proxies können Unternehmen den Use Case „sicherer SaaS-Zugriff von BYOD-Geräten“ umsetzen. Das bedeutet: Anstatt den Zugriff auf SaaS-Applikationen mithilfe von IdP-Funktionen wie Microsofts Conditional Access einfach nur „stumpf zu blockieren“, wenn der Benutzer von einem nicht verwalteten Gerät kommt, kann die Session dynamisch – basierend auf dem Gerätezustand – in eine Browser-Isolation umgeleitet oder für den nativen Zugriff freigegeben werden.
So wird ein sicherer Zugriff auf SaaS-Applikationen von privaten Geräten ermöglicht, ohne die User Experience zu beeinträchtigen.
Wie funktionert der Zugriff klassisch?
Klassisch blockieren Unternehmen den Zugriff auf SaaS-Applikationen (z. B. Salesforce) schlichtweg, wenn der Benutzer nicht von einem verwalteten Gerät aus zugreift. Dafür werden beispielsweise in Entra Conditional Access Regeln definiert, die den Compliance-Status des Geräts prüfen (z. B. „is domain joined“). Nur wenn das Gerät „compliant“, also „domain joined“, ist, wird der Zugriff erlaubt – andernfalls blockiert.
Der Benutzer meldet sich also an der SaaS-Applikation an. Die SSO-konfigurierte SaaS erkennt, dass sie den Benutzer am IdP authentifizieren muss, und leitet die Anfrage an den IdP weiter. Dieser antwortet dann an die SaaS, ob der Benutzer zugreifen darf oder nicht. Dementsprechend wird der Login erlaubt oder verweigert (ohne hier auf die verschiedenen SAML-Methoden – SP-initiated oder IdP-initiated – einzugehen).
Das bedeutet faktisch, dass der Benutzer von seinem privaten Gerät aus keinen Zugriff erhält. Viel schöner wäre es jedoch, wenn der User zwar zugreifen kann, die IT aber steuert, was er auf Unternehmensgeräten tun darf – und was er auf privaten Geräten nicht darf.
Was kann man mit einem Identity Proxy erreichen?
Bei der Verwendung eines Identity Proxies (Teil einer SSE-Lösung) wird der Zugriff auf eine SaaS-Applikation nicht einfach nur blockiert oder erlaubt. Stattdessen schafft man eine dritte Option: Browser Isolation. Innerhalb dieser Isolation kann im Detail gesteuert werden, was der Benutzer in der Session tun oder eben nicht tun darf.
Übliche Features sind:
- Einschränkungen basierend auf Gruppen, Benutzern, Zeit, Gerätetyp, URL oder Applikation (u. v. m.)
- Verwendung von Mikrofon und Kamera innerhalb der SaaS (z. B. Microsoft Teams)
- Steuerung der Copy-Paste-Funktion (Clipboard) in oder aus der Isolation
- Kontrolle von Datei-Uploads und -Downloads
- Erlaubnis oder Verbot von Druckfunktionen
- Read-only-Modus (Tastatureingaben deaktiviert)
- Anzeige von Office-Dokumenten innerhalb der Isolation
- Deep Linking (das Öffnen von Applikationslinks lokaler Anwendungen auf dem Client) aus der Isolation
Effektiv bedeutet das, dass Benutzer auch von privaten Geräten sicher auf SaaS-Applikationen zugreifen können – ohne Risiko von Datenverlust, Malware-Infektion oder Verstößen gegen Compliance-Richtlinien. Sicheres BYOD für SaaS also.
Wie funktioniert der Zugriff mit einem Identity Proxy?
Damit BYOD-Geräte dynamisch in eine Browser-Isolation umgeleitet werden können, muss die Authentifizierung der SaaS-Applikation zunächst über die SSE-Komponente laufen. Das heißt: Der SAML-Request landet nicht direkt beim IdP, sondern zuerst beim SSE-Provider.
Der SSE-Provider prüft, ob die Anfrage von einem verwalteten oder einem nicht verwalteten Gerät stammt, und merkt sich diese Information. Anschließend wird die Anfrage an den eigentlichen IdP (z. B. Entra) weitergeleitet und dort verifiziert, ob der Benutzeraccount aktiv ist, existiert und für die SaaS freigeschaltet ist. Gruppenzugehörigkeiten können dabei durchgereicht werden, damit IdP-basierte Rollen und Berechtigungen in der SaaS weiterhin funktionieren.
Ist der Benutzer berechtigt, die SaaS zu verwenden, schickt der SSE-Provider – basierend auf dem Gerätezustand – entweder einen Redirect in die Browser-Isolation oder authentifiziert den Benutzer transparent an der SaaS.
Ob ein Gerät als „managed“ gilt, wird über ein Browser-Plugin oder über die Existenz eines SSE-Agents auf dem Gerät ermittelt. Innerhalb der Browser-Isolation werden anschließend die oben genannten Sicherheitsrichtlinien angewendet.
Sowohl Zscaler als auch Cloudflare können als Identity Proxies eingesetzt werden und unterstützen Browser Isolation (mit leicht unterschiedlichen Features). Das folgende Beispiel zeigt den isolierten (Zscaler) und den nativen (Cloudflare) Zugriff.
Fazit
Et voilà: Wir haben die sichere Nutzung von SaaS-Applikationen auf privaten Geräten ermöglicht!
Benutzer können nun endlich auch von ihren privaten Geräten auf Unternehmens-SaaS zugreifen – ohne die (Daten-)Sicherheit zu gefährden.
Hätten Sie’s gewusst?
