Die heutige ZTNA ist für verschiedene Anwendungen nicht ausreichend

Authentifizierung & Autorisierung ist in verschiedenen Farben erhältlich

Die Komponente Zero Trust Network Access (ZTNA) von SASE wurde entwickelt, um einen sicheren Zugang zu privaten Unternehmensanwendungen zu ermöglichen. Im Einklang mit dem Kernprinzip der identitätsbasierten Zugriffskontrolle in der Zero Trust Architecture (ZTA) spielt die ZTNA eine wichtige Rolle bei der Authentifizierung von Benutzern und der Durchsetzung von Zugriffskontrollen auf der Grundlage von Benutzertypen, Gruppen und Rollen bei jeder eingehenden Sitzung zu den Unternehmensanwendungen. Die ZTNA-Sicherheit bietet in den folgenden Szenarien erhebliche Vorteile:

• Ältere Anwendungen: Legacy-Anwendungen, die keine eingebauten Sicherheitsvorkehrungen haben, werden aufgrund von Sicherheitsbedenken oft nicht für Work-From-Anywhere (WFA)-Benutzer freigegeben. Durch den Einsatz von ZTNA als Front-End für diese Legacy-Anwendungen können HTTPS-Terminierung mit Zertifikatsverwaltung, Authentifizierung mit Protokollen wie OIDC und Autorisierung auf der Grundlage kontextbezogener Zugriffskontrollen bereitgestellt werden. Dadurch können WFA-Benutzer sicher über das Internet auf ältere Anwendungen zugreifen.
• Defekte Anwendungen: Obwohl einige Anwendungen mit Blick auf die Sicherheit entwickelt wurden, sind sie möglicherweise über einen längeren Zeitraum nicht aktualisiert worden. Diese Anwendungen verfügen möglicherweise nicht über eine ordnungsgemäße Zertifikatsverwaltung mit veralteter oder fehlender Unterstützung für das Hochladen neuer Zertifikate oder die automatische Erneuerung. ZTNA kann als Sicherheitsersatz für diese defekten Anwendungen fungieren und einen sicheren Zugriff gewährleisten, indem es deren Sicherheitseinschränkungen überwindet.
• Neue Anwendungsarchitektur: Bei der Entwicklung moderner Unternehmensanwendungen werden Sicherheitsaspekte häufig auf externe Einrichtungen wie ZTNA und Service-Mesh-Technologien verlagert. Dieser Ansatz entlastet die Anwendungsentwickler von der Last der Handhabung von HTTPS, Authentifizierung und Autorisierung, da die Sicherheit an die Front-End-Einheit ausgelagert wird. Durch die Zentralisierung der Sicherheitsverwaltung ergeben sich Vorteile wie die einheitliche Durchsetzung von Sicherheitsrichtlinien, eine höhere Produktivität bei der Anwendungsentwicklung und eine vereinfachte Wartung. Da die Sicherheitsaktualisierungen extern durchgeführt werden, kann die Häufigkeit von Patch-Versionen zur Behebung von Sicherheitsproblemen erheblich reduziert werden.

Viele der heutigen ZTNA-Lösungen eignen sich gut für das Front-End einfacher Unternehmensanwendungen, aber sie sind nicht in der Lage, Authentifizierung und Autorisierung für mandantenfähige Anwendungen wie SaaS-Anwendungen zu bieten. Die Rolle von ZTNA bei SaaS-Anwendungen: Im Zusammenhang mit Software-as-a-Service (SaaS)-Anwendungen wird ZTNA meiner Meinung nach eine entscheidende Rolle bei der Stärkung und Verbesserung der Authentifizierungs- und Autorisierungsmechanismen spielen. SaaS-Anwendungen stellen besondere Anforderungen, wie z.B. Mandantenfähigkeit, Widerstandsfähigkeit gegen DoS/DDoS-Angriffe und robuster Schutz gegen Authentifizierungsumgehung und Angriffe zur Privilegienerweiterung. Dieser Artikel befasst sich mit den Funktionen der ZTNA der nächsten Generation, die bei der Auslagerung oder Verbesserung der Authentifizierungs- und Autorisierungsprozesse für SaaS-Anwendungen helfen können. Bitte beachten Sie, dass dieser Artikel nicht auf andere Funktionen von ZTNA eingeht, wie z.B. WAAP (Web Application and API Protection), HTTPS-Terminierung, Traffic-Management von eingehenden Sitzungen zu verschiedenen Anwendungsinstanzen, Webifizierung von SSH/RDP/VNC-Diensten und Unsichtbarmachen von Anwendungen für Port-Scanner. Sein Hauptaugenmerk liegt auf den Authentifizierungs- und Autorisierungsaspekten der ZTNA. Es ist wichtig zu beachten, dass die Rollen von CASB (Cloud Access Security Broker) und ZTNA im Zusammenhang mit SaaS verwechselt werden können. Die CASB-Komponente von SASE konzentriert sich auf die Absicherung von Verbindungen zu SaaS-Diensten, die von Unternehmen genutzt werden, wobei die Unternehmen Verbraucher von SaaS- und CASB-Diensten sind. Andererseits ist ZTNA im Zusammenhang mit SaaS darauf ausgelegt, die SaaS-Anwendung selbst zu schützen, wodurch SaaS-Unternehmen zu Verbrauchern von ZTNA-Diensten werden. Diese Unterscheidung ist wichtig, um die unterschiedlichen Rollen und Verantwortlichkeiten von CASB und ZTNA bei den SASE-Lösungen zu verstehen. In einem früheren Artikel über Identitätsbroker haben wir die zahlreichen Vorteile der Integration von Brokern in SASE-Lösungen untersucht. Die diskutierten Vorteile betrafen vor allem die Modularität und die Einfachheit des Designs, die letztlich die Widerstandsfähigkeit von SASE-Lösungen erhöhen. In diesem Artikel befassen wir uns mit der zentralen Rolle von Identitätsbrokern bei der Unterstützung komplexer Anwendungen, wobei wir uns besonders auf SaaS-Anwendungen konzentrieren.

Was sind die Herausforderungen bei mandantenfähigen Anwendungen?

ZTNA von SASE zeichnet sich durch eine robuste Unterstützung für richtlinienbasierte Autorisierung aus. Die Autorisierungs-Engines in SASE bieten die Möglichkeit, mehrere Richtlinientabellen zu verwalten, wobei jede Tabelle mehrere Richtlinien enthält. Jede Richtlinie besteht aus mehreren Regeln und legt die Aktion fest, die bei einer erfolgreichen Übereinstimmung durchgeführt werden soll. Die Regeln selbst umfassen verschiedene übereinstimmende Attribute, die als Quell- und Zielattribute klassifiziert werden können. Zielattribute beziehen sich in erster Linie auf die Ressourcen der Anwendungen, auf die zugegriffen wird, wie URIs und die Methoden (z.B. GET, PUT, POST, DELETE), die zur Interaktion mit diesen Ressourcen verwendet werden. Andererseits sind Quellattribute normalerweise mit den Subjekten verbunden, die auf die Ressourcen zugreifen. Diese Attribute umfassen benutzerbezogene Attribute wie Name, Gruppe, Rolle, Authentifizierungsdienst, der die Anmeldedaten des Benutzers validiert hat, und andere Benutzeransprüche. Sie enthalten auch Gerätekontextattribute, die die Sicherheitslage der von der Person genutzten Geräte und den Standort des Geräts, von dem aus der Benutzer auf die Ressourcen zugreift, erfassen. Viele ZTNA-Lösungen sind jedoch unzureichend, wenn es darum geht, umfassende Authentifizierungsszenarien zu adressieren, und beschränken ihre Fähigkeiten oft auf Nicht-SaaS-Anwendungen. Die Einbeziehung eines Identity Brokers in SASE/SSE-Lösungen ist ein fortschrittlicher Schritt hin zu einer umfassenden Authentifizierung über alle Arten von Anwendungen hinweg. Auch wenn man argumentieren könnte, dass SaaS-Anbieter über die Fähigkeit verfügen, Authentifizierung und Autorisierung innerhalb ihrer Anwendungen zu handhaben, hat sich die Landschaft erheblich weiterentwickelt. In der heutigen agilen Umgebung erkennen SaaS-Anbieter zunehmend die Vorteile einer Auslagerung der Sicherheitsverantwortung an externe Unternehmen wie SASE. Auf diese Weise können sie von einer höheren Produktivität und einem stärkeren Vertrauen in ihre allgemeine Sicherheitslage profitieren. Darüber hinaus ermöglicht dieser Ansatz neuen SaaS-Anbietern einen schnelleren Markteintritt, da sie die Authentifizierung und Autorisierung an ein externes Unternehmen auslagern und sich in erster Linie auf ihre Kerngeschäftslogik konzentrieren können. SASE-Lösungen können eine entscheidende Rolle bei der Unterstützung dieser neuen SaaS-Anbieter spielen. Wir sind davon überzeugt, dass SASE-Lösungen bereit sein sollten und sein werden, diese Herausforderung anzunehmen und Authentifizierungs- und Autorisierungssicherheit für komplexe Anwendungen wie SaaS-Anwendungen zu bieten. Das folgende Szenario ist ein repräsentatives Beispiel für eine SaaS-Anwendung und zeigt, wie SASE durch die Integration von Identitätsbrokern bei der Delegation der Authentifizierung und Autorisierung durch die Anwendungen helfen kann. Betrachten Sie dieses Beispielszenario einer SaaS-Anwendung (gehostet unter app.example.com), die aus mehreren API-Ressourcen besteht:

In diesem Szenario nehmen wir außerdem an, dass die IDP für den SaaS-Anbieter example-idp ist. Es gibt zwei Tenants: XYZ und ABC. Ihre jeweiligen IDP-Dienste sind XYZ-idp und ABC-idp. Jeder Mieter hat auch zwei Partner, die jeweils ihren eigenen IDP-Service haben. XYZ-P1-idp und XYZ-P2-idp sind IDP-Dienste von XYZ-Partnern. ABC-P1-idp und ABC-P2-idp sind IDP-Dienste von ABC-Partnern. Darüber hinaus verlangt der Mieter XYZ eine Authentifizierung über Google und Facebook für den Zugriff auf den öffentlichen API-Bereich, während der Mieter ABC eine Authentifizierung über LinkedIn und GitHub bevorzugt. Die folgenden Autorisierungsrichtlinien werden in ZTNA benötigt, um das obige Szenario zu bewältigen:

1. Domain = app.example.com; user-role=app-admin; authservice=example-idp; uri = /service-admin-api/* ALLOW: Erlauben Sie jedem Benutzer, der sich erfolgreich beim Dienst example-idp angemeldet hat und über die Rolle app-admin verfügt, den Zugriff auf alle Ressourcen unter der admin-api der Anwendung mit der Domäne app.example.com.
2. Domain = app.example.com; user-group=admin-group; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-admin-api/* ALLOW: Erlauben Sie jedem Benutzer, der sich erfolgreich beim Dienst XYZ-idp angemeldet hat und die Rolle admin-group besitzt, den Zugriff auf alle Ressourcen unter XYZ/tenant-admin-api.
3. Domain = app.example.com; user-role=admin-role; authservice=ABC-idp; uri = /tenants/ABC/tenant-admin-api/* ALLOW: Erlauben Sie jedem Benutzer mit der Rolle admin, der mit dem Dienst ABC-idp authentifiziert ist, den Zugriff auf die Ressourcen ABC/tenant-admin-api
4. Domain = app.example.com; authservice=XYZ-idp; uri = /mieter/XYZ/mieter-benutzer-api/*, /mieter/XYZ/collaboration-api/*, /mieter/XYZ/public-api/* ALLOW: Erlaubt den Zugriff auf die in der Regel angegebenen Ressourcen für jeden Benutzer, der erfolgreich mit dem XYZ-idp-Dienst authentifiziert wurde
5. Domain = app.example.com; authservice=ABC-idp; uri = /mieter/ABC/mieter-benutzer-api/*, /mieter/ABC/collaboration-api/*, /mieter/ABC/public-api/* ALLOW: Erlaubt den Zugriff auf die in der Regel angegebenen Ressourcen für jeden Benutzer, der erfolgreich mit dem ABC-idp-Dienst authentifiziert wurde
6. Domain = app.example.com; authservice=XYZ-P1-idp; uri = /Mieter/XYZ/collaboration-api/*, /Mieter/XYZ/public-api/* ALLOW: Erlauben Sie Benutzern, die mit dem Dienst XYZ-P1-idp authentifiziert sind, den Zugriff auf den XYZ Collaboration Space.
7. Domain = app.example.com; authservice=XYZ-P2-idp; uri = /Mieter/XYZ/collaboration-api/*, /Mieter/XYZ/public-api/* ALLOW: Erlauben Sie Benutzern, die mit dem Dienst XYZ-P2-idp authentifiziert sind, den Zugriff auf den XYZ Collaboration Space.
8. Domain = app.example.com; authservice=ABC-P1-idp; uri = /Mieter/ABC/collaboration-api/*, /Mieter/ABC/public-api/* ALLOW: Erlauben Sie Benutzern, die mit dem Dienst ABC-P1-idp authentifiziert sind, den Zugriff auf den ABC-Kollaborationsraum.
9. Domain = app.example.com; authservice=ABC-P2-idp; uri = /Mieter/ABC/collaboration-api/*, /Mieter/ABC/public-api/* ALLOW: Erlauben Sie den Zugriff auf den ABC-Kollaborationsraum für Benutzer, die mit dem ABC-P2-idp-Dienst authentifiziert sind.
10. Domain = app.example.com; authservice=google.com; uri = /mieter/XYZ/public-api/* ALLOW: Erlauben Sie den Zugriff auf den XYZ public-api Bereich für alle Benutzer, die mit google.com authentifiziert sind.
11. Domain = app.example.com; authservice=facebook.com; uri = /mieter/XYZ/public-api/* ALLOW: Erlauben Sie den Zugriff auf den XYZ public-api Bereich für alle mit facebook.com authentifizierten Benutzer
12. Domain = app.example.com; authservice=linkedin.com; uri = /mieter/ABC/public-api/* ALLOW: Erlauben Sie allen mit linkedin.com authentifizierten Benutzern den Zugriff auf den ABC public-api Bereich
13. Domain = app.example.com; authservice=github.com; uri = /mieter/ABC/public-api/* ALLOW: Erlauben Sie allen mit github.com authentifizierten Benutzern den Zugriff auf XYZ public-api space
14. Domain = app.example.com; DENY: Verweigert den Zugriff auf die Anwendung, wenn keine der oben genannten Regeln zutrifft.

SASE-Lösungen zeichnen sich durch eine attributbasierte Zugriffskontrolle aus. Das bedeutet, dass sie die Autorisierungsfunktionen gut handhaben. Sie sind jedoch nicht sehr umfassend, wenn es um die Authentifizierung geht. In den obigen Richtlinien werden verschiedene Zugriffsebenen gewährt, die auf dem Identitätsanbieter (IDP) basieren, bei dem sich die Benutzer authentifizieren. Außerdem möchten sich einige Benutzer vielleicht absichtlich bei einem bestimmten IDP-Dienst authentifizieren, um mit minimalen Berechtigungen auf Ressourcen zuzugreifen und so mögliche Fehler bei der Datenexfiltration zu vermeiden.

Die Rolle der Identitätsmakler

Um solche Szenarien zu bewältigen, ist die integrierte Funktionalität eines Identitätsbrokers erforderlich. Identitätsbroker dienen als OIDC (OpenID Connect)-Provider für die SASE/SSE-Proxy-Komponente und fungieren gleichzeitig als OIDC/SAML/LDAP-Clients für die vorgeschalteten Identitätsdienste (Authentifizierungsdienste). Keycloak, ein Open-Source IAM-System, ist für viele eine beliebte Wahl. Es kann so konfiguriert werden, dass es die Rolle eines Identitätsmaklers übernimmt und wird häufig von SASE-Dienstleistern und Anbietern von Service-Mesh-Produkten verwendet. Daher wird hier die Keycloak-Terminologie verwendet. Keycloak bietet die Flexibilität, die Authentifizierung für verschiedene Arten von Anwendungen zu handhaben, einschließlich SaaS-Anwendungen mit mehreren Mandanten. Die Authentifizierung für mandantenfähige SaaS-Anwendungen kann mithilfe von ‚Identitätsbrokern‘ auf folgende Weise erreicht werden: Ein Realm mit einem Client für jede SaaS-Anwendung mit modifizierten Authentifizierungsabläufen: In Fällen, in denen der Anwendungs-Mandant nicht anhand des URL-Pfads oder der HTTP-Anfrage-Header identifiziert werden kann, kann die SASE-Proxy-Komponente nur einen OIDC-Client zur Kommunikation mit dem Identitätsbroker haben. Bei der Benutzerauthentifizierung muss der Identitätsbroker wissen, gegen welchen IDP-Dienst er den Benutzer authentifizieren soll. Keycloak bietet Standard-Authentifizierungsabläufe wie z.B. den Browser-Flow und ermöglicht die Erstellung von benutzerdefinierten Abläufen und die Verknüpfung mit Keycloak-Clients. SASE macht sich diese Funktion zunutze, indem es Authentifizierungsabläufe erstellt, bei denen die Benutzer aufgefordert werden, Mieterinformationen anzugeben. Auf der Grundlage dieser Informationen können die Authentifizierungsströme dem Benutzer die verfügbaren Identitätsanbieter zur Auswahl präsentieren. Mit diesen Informationen kann der Broker die Benutzer an den entsprechenden Identitätsdienst weiterleiten. Ein Realm mit mehreren Clients für jede SaaS-Anwendung: Wenn der Anwendungs-Mandant anhand der URL oder der HTTP-Anfrage-Header identifiziert werden kann, kann die SASE-Proxy-Komponente so konfiguriert werden, dass sie einen Client für jeden Anwendungs-Mandanten verwendet. In diesem Fall können Standard-Browser-Flows mit verschiedenen Sets von Identitätsanbietern verwendet und mit den entsprechenden Client-Entitäten in Keycloak verknüpft werden. Dies hat den Vorteil, dass der Benutzer nicht aufgefordert wird, den Namen des Mieters anzugeben, was die Benutzerfreundlichkeit erhöht. Zusammenfassend lässt sich sagen, dass diese Strategien SASE-Lösungen in die Lage versetzen, die Authentifizierung für mandantenfähige SaaS-Anwendungen effektiv zu handhaben und dabei die Fähigkeiten von Keycloak als Identitätsbroker zu nutzen.

Richtlinienbasierte OIDC-Client-Auswahl

Der Keycloak-Broker bietet Unterstützung für mehrere Realms und mehrere Clients innerhalb jedes Realms. Es ermöglicht Standard-Authentifizierungsabläufe, die Erstellung von benutzerdefinierten Authentifizierungsabläufen und die Zuordnung dieser Abläufe zu Clients. Die Keycloak-Brokerfunktionalität ermöglicht auch die Vermittlung von Authentifizierungssitzungen zwischen benutzerseitigen Authentifizierungsmechanismen und Backend-(Upstream-)Authentifizierungsdiensten. Wir haben bereits erörtert, wie Keycloak Benutzer auffordern kann, ihren Anwendungs-Mandanten zu identifizieren und den Identitätsdienst für die Authentifizierung auszuwählen. Diese Fähigkeiten sollten auch vom SASE-Proxy genutzt werden, der als OIDC-Client (auch als OIDC-Relay bekannt) für verschiedene Kundenanwendungen, einschließlich mandantenfähiger Anwendungen, fungiert. Der SASE-Proxy muss mehrere OIDC-Clients unterstützen. Ein Ansatz besteht darin, eine Reihe von OIDC-Clients für jeden Kunden zu haben, um sicherzustellen, dass kundenspezifische Konfigurationen im Zusammenhang mit der Authentifizierung von den anderen isoliert sind. Normalerweise ist jeder OIDC-Satz eines SASE-Kunden mit einem Realm in Keycloak verbunden. In Szenarien, in denen ein Kunde des SASE-Proxys mehrere Anwendungen mit jeweils eigenem Domänennamen hat, ist es notwendig, eine Isolierung zwischen mehreren Anwendungsadministratoren zu gewährleisten. In solchen Fällen sollte eine Untergruppe von OIDC-Clients konfiguriert werden, wobei jeder Anwendung ein Client zugewiesen wird. Für viele Anwendungen reicht ein einziger OIDC-Client aus, wenn es sich um eine mandantenfähige Anwendung handelt oder wenn der Mandant nicht anhand des Datenverkehrs identifiziert werden kann, wie bereits erwähnt. Wenn der Mandant jedoch identifiziert werden kann, kann für jeden Anwendungs-Mandanten ein OIDC-Client konfiguriert werden. Da mehrere OIDC-Clients erforderlich sind, sollte der SASE-Proxy einen Mechanismus zur Auswahl des geeigneten OIDC-Clients bieten. An dieser Stelle wird die richtlinienbasierte OIDC-Auswahl entscheidend. Es wird eine Richtlinientabelle mit mehreren Richtlinien verwendet, wobei jede Richtlinie auf den entsprechenden OIDC-Client-Datensatz verweist. Während des Verkehrsflusses prüft der SASE-Proxy, ob eine OIDC-Authentifizierung erforderlich ist, und gleicht dann den Kunden, den Anwendungsdomänennamen und den Anwendungsmieter mit den Richtlinien in der Tabelle ab. Wenn eine Übereinstimmung gefunden wird, wird der entsprechende OIDC-Client-Datensatz zur Kommunikation mit dem Broker verwendet. Einige Implementierungen können mehrere Richtlinientabellen haben, wobei eine Tabelle jedem Kunden gewidmet ist, um den Richtlinienabgleich zu beschleunigen.

NextGen ZTNA wird sich an mandantenfähige Anwendungen anpassen

ZTNA (Zero Trust Network Access) innerhalb von SASE (Secure Access Service Edge) Lösungen spielen eine entscheidende Rolle bei der Sicherung von Anwendungen. Es ermöglicht die Auslagerung von Authentifizierungs- und Autorisierungsaufgaben aus den Anwendungen, so dass sich die Entwickler auf ihre Kerngeschäftslogik konzentrieren können. Dieser Ansatz verbessert die Produktivität und erhöht die allgemeine Sicherheit. Schwachstellen bei der Umgehung der Authentifizierung und der Ausweitung von Privilegien sind in Anwendungen weit verbreitet, da nicht alle Entwickler über Fachwissen im Bereich Sicherheit verfügen. Das Auslagern der Sicherheit kann diese Schwachstellen beseitigen und so die Widerstandsfähigkeit von Anwendungen stärken. Die Zentralisierung der Sicherheit in einem Commonplace wie SASE vereinfacht die Arbeit der Sicherheitsadministratoren, die nur eine einzige Schnittstelle für alle Anwendungen verwalten müssen. Um sowohl Sicherheit als auch Flexibilität zu erreichen, sollte die nächste Generation von ZTNA innerhalb von SASE-Lösungen verschiedene Anwendungstypen abdecken. Viele bestehende ZTNA-Lösungen haben oft Schwierigkeiten, mandantenfähige Anwendungen effektiv zu unterstützen. Zukünftige Erweiterungen werden voraussichtlich Identitätsbroker-Funktionen und eine richtlinienbasierte OIDC (OpenID Connect) Client-Auswahl umfassen, um eine Vielzahl von Anwendungsszenarien zu unterstützen.

• 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.