Identitätsmakler In meinem vorherigen Blog über identitätsbewusstes SASE habe ich über Zero Trust, die Rolle von SASE und die Bedeutung der Identität bei der Zugriffskontrolle gesprochen. In einem anderen Blog über SASE Proxy wurde erläutert, wie SASE-Lösungen die Identitäten von Benutzern erhalten, nachdem diese über Identitätsanbieter (IdPs) authentifiziert wurden. Zusammenfassend lässt sich sagen, dass der Forward-Proxy-Teil von SASE-Lösungen Benutzer über die Authentifizierungsmethoden Kerberos, NTLM, Digest und Basic authentifiziert. Ungeschützte Portale hingegen authentifizieren Benutzer über Kerberos oder OIDC. Der Reverse-Proxy-Teil von SASE-Lösungen verwendet in der Regel entweder Kerberos oder OIDC zur Authentifizierung von Benutzern. VPN Gateway von SASE authentifiziert Benutzer auch mit Enterprise-Authentifizierungsdatenbanken. SASE-Lösungen erwarten Benutzerinformationen wie den Identitätsanbieter, der die Benutzeranmeldeinformationen validiert hat, die E-Mail-Adresse des Benutzers, die Gruppen und Rollen, denen der Benutzer angehört, usw. im JWT-Format (JSON Web Token). SASE-Lösungen verwenden diese Informationen (in der JWT-Terminologie als Claims bezeichnet), um identitätsspezifische Zugriffskontrollen durchzusetzen.

Identitätsmakler

Ein Identitätsbroker ist ein Dienst, der als Vermittler fungiert und die Authentifizierung von Endbenutzern durch SASE-Lösungen bei verschiedenen Identitätsanbietern (IdPs) erleichtert. Nicht alle IdPs implementieren alle Authentifizierungsprotokolle; einige implementieren vielleicht nur OIDC, OAuth2 oder SAMLv2. Da SASE-Lösungen für die Zusammenarbeit mit mehreren IdPs konzipiert sind, steigt ihre Komplexität, da sie verschiedene Authentifizierungsprotokolle unterstützen müssen. Identitätsbroker können als vertrauenswürdige Vermittlungsdienste die SASE-Lösung in die Lage versetzen, ein einziges Authentifizierungsprotokoll im Backend zu verwenden und den Identitätsbroker den Authentifizierungsprozess über die von den IdPs unterstützten Authentifizierungsprotokolle an IdPs weiterleiten lassen. Die folgende Abbildung zeigt die SASE-Lösung mit und ohne Identitätsbroker. SASE-Lösung Die linke Seite des Bildes zeigt SASE ohne einen Identitätsbroker: Benutzer-Browser/Apps authentifizieren sich beim SASE Forward Proxy mit Kerberos, NTLM, Benutzername/Passwort, Benutzername/Digest-Passwort. SASE muss die Anmeldedaten des Benutzers validieren. Es verwendet mehrere funktionale Backend-Module, um mit verschiedenen IdPs/Authentifizierungssystemen zu kommunizieren. Im Falle von Kerberos wird das Serviceticket lokal in der SASE-Datenebene validiert und erhält dann Benutzerdekorationen von Authentifizierungssystemen wie AD über LDAP oder SCIM. Im Falle von Benutzername/Passwort wird das LDAP-Backend auch für die Validierung der Benutzeranmeldeinformationen verwendet. SASE Reverse Proxy und Captive Portals authentifizieren Benutzer entweder über OIDC (Open ID Connect) oder über SAMLv2. Wenn die Backend-IdPs ebenfalls auf OIDC oder SAMLv2 basieren, leitet es die Benutzer an die IdPs weiter. Im Falle von LDAP-basierten Systemen wird erwartet, dass SASE als IdP fungiert und LDAP zur Validierung von Benutzeranmeldeinformationen und zum Erhalt von Benutzerdekorationen verwendet, um das Identitäts-Token in JWT-Form zu erstellen. VPN Gateway ist ein weiteres Modul, das für den Fernzugriff verwendet wird. Als Teil des IKEv2-Tunnelaufbaus authentifiziert das VPN-Gateway den Benutzer. Die Benutzeranmeldeinformationen werden mit der lokalen DB, dem RADIUS-Server oder dem LDAP-Server validiert. Wie Sie sehen, sind mehrere Komponenten auf der Datenebene erforderlich, um verschiedene Protokolle zu unterstützen und mit verschiedenen Benutzer-Browsern und nativen Anwendungen zu arbeiten. Außerdem müssen sie nicht nur mit mehreren IdPs verschiedener Mandanten arbeiten, sondern auch mit mehreren IdP-Anforderungen innerhalb einer Mandantenumgebung. Die rechte Seite des Bildes zeigt SASE mit integriertem Identitätsbroker: Mit dem Identitätsbroker wird die SASE-Datenebene drastisch vereinfacht. Die SASE-Datenebene muss nur mit einem Authentifizierungsprotokoll gegenüber dem Broker arbeiten. In der obigen Abbildung ist OIDC das einzige Protokoll, das die SASE-Datenebene unterstützen muss. Der Broker kann Authentifizierungssitzungen mit mehreren IdPs orchestrieren/föderieren. Es wird erwartet, dass der Identitätsbroker auch JWT aus den Benutzerinformationen des SAMLv2-Sicherheitstokens, aus JWT, die von den vorgelagerten IdP-Servern kommen, oder aus den Benutzerinformationen in der lokalen Datenbank oder über LDAP erstellt. Das heißt, von einem Identitätsbroker, der für SASE entwickelt wurde, wird erwartet, dass er JWT in allen Fällen bereitstellt – unabhängig davon, ob der Benutzer sich mit Kerberos über Proxy-Header, Kerberos über WWW-Header, OIDC, IKEv2 authentifiziert und ob die IdPs auf OIDC, SAMLv2 oder LDAP basieren. Die Trennung der SASE-Datenebene vom SASE-Identitätsmakler hat mehrere Vorteile. Einige Vorteile sind im Folgenden aufgeführt.

  1. Modularität macht die gesamte Lösung weniger komplex, weniger fehleranfällig und damit robuster.
  2. Secure:Identity Broker kann in vertraulichen Computerumgebungen getrennt von der SASE-Datenebene instanziiert werden, um sicherzustellen, dass die Schlüssel/Passwörter/Zeugnisse, die für die Kommunikation mit IdPs verwendet werden, auch dann geschützt sind, wenn sie in Gebrauch sind.
  3. Erweiterbarkeit: Neue IdPs mit neueren Authentifizierungsprotokollen können unterstützt werden, ohne dass dies Auswirkungen auf die SASE-Datenebene hat.
  4. Konsolidierung: Identity Broker-Lösungen werden zunehmend auch für andere Anwendungen in Betracht gezogen. Unternehmen können den Identitätsmakler, der mit der SASE-Lösung geliefert wird, für ihre Anwendungen nutzen, anstatt einen separaten Identitätsmakler-Service/eine separate Lösung zu verwenden.

SASE-spezifische Merkmale

Die Identity Broker-Funktionalität kann in der Tat eine wichtige Rolle dabei spielen, den direkten Zugriff auf SaaS/Cloud-Dienste zu unterbinden, indem sie Richtlinienprüfungen durchsetzt und sicherstellt, dass nur authentifizierte Benutzer mit entsprechender Zugriffskontrolle auf diese Ressourcen zugreifen können. Darüber hinaus bieten herkömmliche Identitätsbroker möglicherweise keine gute Unterstützung für Proxy-Kerberos, das für die SASE-Authentifizierung unerlässlich ist. Daher ist es wichtig, dass Identitätsbroker Proxy-Kerberos und andere SASE-Anforderungen unterstützen, um sich effektiv in SASE-Lösungen zu integrieren. Durch diese Erweiterungen können Identitätsbroker die Sicherheit und Benutzerfreundlichkeit von SASE-Lösungen für Unternehmen verbessern.

  1. Sicherstellung einer identitätsbasierten Zugriffskontrolle für SaaS- und Cloud-Dienste – immer und deterministisch: Unternehmen nutzen zunehmend SaaS- und Cloud-Infrastrukturdienste, auf die von überall aus zugegriffen werden kann. Dies ist ein großer Vorteil, aber auch ein Sicherheitsrisiko für viele Unternehmen. Unternehmen möchten den Zugriff auf ihre Daten in SaaS/Cloud-Diensten für bestimmte Mitarbeiter einschränken, und SASE soll dies gewährleisten. Dies ist jedoch nur möglich, wenn der Benutzerverkehr zu SaaS/Cloud-Diensten über die SASE-Datenebene läuft. Wenn der Datenverkehr direkt zu SaaS/Cloud-Diensten geht und die SASE-Datenebene umgeht, wird der Zugriff voraussichtlich verweigert. Ein Identitätsbroker kann dabei helfen, diese Zugriffe zu unterbinden. Wenn Sie die SaaS/Cloud-Dienste so konfigurieren, dass sie den SASE Identitätsbroker verwenden, landet jede neue Benutzerauthentifizierungssitzung zuerst beim SASE Identitätsbroker. Der SASE-Identitätsmakler kann über seine Richtlinienprüfungen verhindern, dass Benutzer direkt auf Dienste zugreifen.
  2. Unterstützung für Kerberos-Grant: Für viele Anwendungsfälle sind implizite Autorisierungs- und Passwort-Grant-Typen ausreichend. Diese beiden Grant-Typen sind jedoch nicht ausreichend, um die Kerberos-Authentifizierung zu unterstützen. Es wird erwartet, dass die SASE-Datenebene, sobald sie das Kerberos-Service-Ticket entweder über Proxy-Header oder WWW-Header vom Benutzer (z.B. Browser) erhält, das Service-Ticket validiert und die entsprechenden Benutzerdekorationen aus Authentifizierungsdatenbanken abruft. Da der Broker für die Validierung der Berechtigungsnachweise verwendet wird, muss die Implementierung des OIDC-Protokolls erweitert werden, um das Senden des Service-Tickets von der SASE-Datenebene an den Identitätsbroker zu unterstützen und das JWT zu erhalten, wenn die Berechtigungsnachweise validiert sind.

Abschließende Gedanken

Identitätsmakler können in der Tat eine entscheidende Rolle in einer umfassenden SASE-Lösung (Secure Access Service Edge) spielen. Durch die Integration eines Identitätsbrokers in die SASE-Architektur können Unternehmen die Integration von Identitäts- und Zugriffsmanagement-Lösungen (IAM) in ihre SASE-Infrastruktur vereinfachen. Dies kann zu einem schlankeren und sichereren Authentifizierungs- und Zugangskontrollprozess für Benutzer führen. Darüber hinaus kann ein Identitätsmakler durch die Durchsetzung von Zero-Trust-Sicherheitsprinzipien sicherstellen, dass nur autorisierte Benutzer auf Ressourcen innerhalb der SASE-Umgebung zugreifen. Dies kann dazu beitragen, das Risiko von Datenschutzverletzungen und anderen Sicherheitsvorfällen zu verringern. Auch wenn Branchenanalysten derzeit nicht über Identitätsbroker im Zusammenhang mit SASE sprechen, ist es möglich, dass sich dies ändert, da Unternehmen weiterhin nach Möglichkeiten suchen, die Sicherheit und Effizienz ihrer IT-Umgebungen zu verbessern.

  • CTO Insights Blog

    Die Blogserie Aryaka CTO Insights bietet Denkanstöße zu Netzwerk-, Sicherheits- und SASE-Themen.
    Aryaka Produktspezifikationen finden Sie in den Aryaka Datenblättern.