Das heutige ZTNA reicht für vielfältige Anwendungen nicht aus

Authentifizierung und Autorisierung gibt es in verschiedenen Farben

Die Zero Trust Network Access (ZTNA)-Komponente von SASE wurde entwickelt, um einen sicheren eingehenden Zugriff auf ent zu ermöglichenerpAnstieg privater Anwendungen. Im Einklang mit dem Kernprinzip der identitätsbasierten Zugriffskontrolle in der Zero Trust Architecture (ZTA) spielt ZTNA eine entscheidende Rolle bei der Authentifizierung von Benutzern und der Durchsetzung von Zugriffskontrollen basierend auf Benutzertypen, Gruppen und Rollen bei jeder eingehenden Sitzung zum EnterpAufstiegsanwendungen.

Die ZTNA-Sicherheit bietet in den folgenden Szenarien erhebliche Vorteile:

• Legacy-Anwendungen: Legacy-Anwendungen, denen integrierte Sicherheitsmaßnahmen fehlen, sind aufgrund von Sicherheitsbedenken häufig nicht für WFA-Benutzer (Work-From-Anywhere) verfügbar. Durch den Einsatz von ZTNA als Front-End dieser Legacy-Anwendungen können HTTPS-Terminierung mit Zertifikatsverwaltung, Authentifizierung mithilfe von 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 bei der Entwicklung auf Sicherheit geachtet wurde, kann es sein, dass einige Anwendungen über einen längeren Zeitraum nicht aktualisiert wurden. Bei diesen Anwendungen mangelt es möglicherweise an einer ordnungsgemäßen Zertifikatsverwaltung, und das Hochladen neuer Zertifikate oder die automatische Verlängerung wird veraltet oder nicht unterstützt. ZTNA kann als Sicherheitsersatz für diese defekten Anwendungen dienen und einen sicheren Zugriff gewährleisten und gleichzeitig deren Sicherheitsbeschränkungen überwinden.
• Neue Anwendungsarchitektur: Moderne enterpRise-Anwendungen werden häufig unter Berücksichtigung von Sicherheitsüberlegungen auf externe Einheiten wie ZTNA und Service-Mesh-Technologien entwickelt. Dieser Ansatz entlastet Anwendungsentwickler von der Last, HTTPS, Authentifizierung und Autorisierung zu handhaben, da die Sicherheit auf die Front-End-Entität verlagert wird. Durch die Zentralisierung des Sicherheitsmanagements werden Vorteile wie die einheitliche Durchsetzung von Sicherheitsrichtlinien, eine höhere Produktivität bei der Anwendungsentwicklung und eine vereinfachte Wartung erreicht. Da Sicherheitsupdates zudem extern verwaltet werden, kann die Häufigkeit von Patch-Veröffentlichungen zur Behebung von Sicherheitsproblemen erheblich reduziert werden.

Viele ZTNA-Lösungen eignen sich heute gut für das Frontend von einfacher EnterpEs gibt immer mehr Anwendungen, aber sie bieten keine Authentifizierung und Autorisierung für mandantenfähige Anwendungen wie z SaaS um weitere Anwendungsbeispiele zu finden.

Die Rolle von ZTNA in SaaS Anwendungen: Im Kontext von Software-as-a-Service (SaaS)-Anwendungen wird ZTNA meiner Ansicht nach eine entscheidende Rolle bei der Stärkung und Verbesserung der Authentifizierungs- und Autorisierungsmechanismen spielen. SaaS Für Anwendungen gelten besondere Anforderungen, darunter Mandantenfähigkeit, Widerstandsfähigkeit gegen DoS/DDoS-Angriffe und robuster Schutz gegen Authentifizierungsumgehungs- und Privilegieneskalationsangriffe. Dieser Artikel befasst sich mit den Funktionen von ZTNA der nächsten Generation, die beim Auslagern oder Verbessern der Authentifizierungs- und Autorisierungsprozesse für hilfreich sein können SaaS Anwendungen. Bitte beachten Sie, dass dieser Artikel andere Funktionen von ZTNA nicht behandelt, wie z. B. WAAP (Web Application and API Protection), HTTPS-Beendigung, Verkehrsverwaltung eingehender Sitzungen zu verschiedenen Anwendungsinstanzen, Webifizierung von SSH/RDP/VNC-Dienste und machen Anwendungen für Port-Scanner unsichtbar. Der Schwerpunkt liegt auf den Authentifizierungs- und Autorisierungsaspekten von ZTNA.

Es ist wichtig zu beachten, dass es zu Verwechslungen zwischen den Rollen kommen kann CASB (Cloud Access Security Broker) und ZTNA im Rahmen von SaaSdem „Vermischten Geschmack“. Seine CASB Bestandteil von SASE konzentriert sich auf die Sicherung von Verbindungen zu SaaS Von ent genutzte Diensteerpsteigt, wo enterpAnstiege sind Verbraucher von SaaS und CASB Dienstleistungen. Andererseits ZTNA im Kontext von SaaS, dient dem Schutz der SaaS Anwendung selbst, machen SaaS Unternehmen, die ZTNA-Dienste nutzen. Diese Differenzierung ist wichtig, um die unterschiedlichen Rollen und Verantwortlichkeiten von zu verstehen CASB und ZTNA im SASE Lösungen

In einem früheren Artikel über Identitätsvermittler, haben wir die zahlreichen Vorteile der Integration von Brokern untersucht SASE Lösungen. Die besprochenen Vorteile drehten sich hauptsächlich um die Modularität und Einfachheit des Designs, was letztendlich die Widerstandsfähigkeit von erhöhte SASE Lösungen. In diesem Artikel werden wir uns mit der zentralen Rolle von Identitätsbrokern bei der Unterstützung komplexer Anwendungen befassen und uns dabei insbesondere darauf konzentrieren SaaS um weitere Anwendungsbeispiele zu finden.

Was sind die Herausforderungen bei mandantenfähigen Anwendungen?

ZTNA von SASE zeichnet sich durch die Bereitstellung robuster Unterstützung für richtlinienbasierte Autorisierung aus. Die darin enthaltenen Autorisierungs-Engines 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 einem erfolgreichen Match ausgefü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, z. B. URIs und die Methoden (z. B. GET, PUT, POST, DELETE), die zur Interaktion mit diesen Ressourcen verwendet werden. Andererseits sind Quellattribute typischerweise mit den Subjekten verknüpft, die auf die Ressourcen zugreifen. Diese Attribute umfassen benutzerbezogene Attribute wie Name, Gruppe, Rolle, Authentifizierungsdienst, der die Benutzeranmeldeinformationen validiert hat, und andere Benutzeransprüche. Sie umfassen auch Gerätekontextattribute, die den sicheren Status der vom Subjekt verwendeten Geräte und den Standort des Geräts erfassen, von dem aus der Benutzer auf die Ressourcen zugreift.

Allerdings sind viele ZTNA-Lösungen nicht in der Lage, umfassende Authentifizierungsszenarien abzudecken, und beschränken ihre Fähigkeiten oft auf nicht-basierte Authentifizierungsszenarien.SaaS Anwendungen. Die Einbeziehung eines Identitätsbrokers in SASE/SSE-Lösungen sind ein fortschrittlicher Schritt hin zu einer umfassenden Authentifizierung für alle Arten von Anwendungen. Man kann zwar argumentieren, dass dies der Fall ist SaaS Da Anbieter über die Möglichkeit verfügen, Authentifizierung und Autorisierung innerhalb ihrer Anwendungen durchzuführen, hat sich die Landschaft erheblich weiterentwickelt.

Im heutigen agilen Umfeld SaaS Anbieter erkennen zunehmend die Vorteile der Auslagerung von Sicherheitsverantwortung an externe Stellen wie z SASE. Auf diese Weise können sie von einer höheren Produktivität und einem größeren Vertrauen in ihre allgemeine Sicherheitslage profitieren. Darüber hinaus ermöglicht dieser Ansatz neue SaaS Dies ermöglicht Anbietern einen schnelleren Markteintritt, da sie die Authentifizierung und Autorisierung an eine externe Stelle auslagern und sich hauptsächlich auf ihre Kerngeschäftslogik konzentrieren können. SASE Lösungen können eine entscheidende Rolle bei der Unterstützung dieser neuen Entwicklungen spielen SaaS Anbieter.

Das ist unsere Überzeugung SASE Lösungen sollten und werden bereit sein, sich dieser Herausforderung der Bereitstellung von Authentifizierungs- und Autorisierungssicherheit für komplexe Anwendungen wie z SaaS Anwendungen. Das folgende Szenario zeigt ein repräsentatives Beispiel für a SaaS Anwendung und untersucht, wie SASEDurch die Integration von Identitätsbrokern kann die Delegation der Authentifizierung und Autorisierung von den Anwendungen unterstützt werden.

Betrachten Sie dieses Beispiel SaaS Anwendungsszenario (gehostet unter app.example.com), bestehend aus mehreren API-Ressourcen:

Nehmen wir in diesem Szenario auch an, dass der IDP für die SaaS Anbieter ist example-idp.

Es gibt zwei Mandanten: XYZ und ABC, wobei ihre jeweiligen IDP-Dienste XYZ-idp und ABC-idp sind. Jeder Mieter hat außerdem zwei Partner mit jeweils eigenem IDP-Service. 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 erfordert der XYZ-Mandant eine Authentifizierung über Google und Facebook für den Zugriff auf den öffentlichen API-Bereich, während der ABC-Mandant die Authentifizierung über LinkedIn und GitHub bevorzugt.

Die folgenden Autorisierungsrichtlinien sind in ZTNA erforderlich, um das oben genannte Szenario zu bewältigen:

1. Domain = app.example.com; Benutzerrolle=App-Administrator; authservice=example-idp; uri = /service-admin-api/* ALLOW: Zugriff für jeden Benutzer zulassen, der sich erfolgreich beim Beispiel-IDP-Dienst angemeldet hat und die App-Administratorrolle für alle Ressourcen unter der Admin-API der Anwendung mit der Domänen-App besitzt .example.com.
2. Domain = app.example.com; Benutzergruppe=Administratorgruppe; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-admin-api/* ALLOW: Zugriff für jeden Benutzer zulassen, der sich erfolgreich beim XYZ-idp-Dienst angemeldet hat und über die Administratorgruppenrolle für alle Ressourcen unter XYZ/tenant-admin-api verfügt .
3. Domain = app.example.com; Benutzerrolle=Administratorrolle; authservice=ABC-idp; uri = /tenants/ABC/tenant-admin-api/* ALLOW: Ermöglicht den Zugriff auf die ABC/tenant-admin-api-Ressourcen für jeden Benutzer mit der Administratorrolle, der mit dem ABC-idp-Dienst authentifiziert ist
4. Domain = app.example.com; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-user-api/*, /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Erlauben Sie jedem Benutzer den Zugriff auf die in der Regel angegebenen Ressourcen wurde erfolgreich mit dem XYZ-idp-Dienst authentifiziert
5. Domain = app.example.com; authservice=ABC-idp; uri = /tenants/ABC/tenant-user-api/*, /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Erlauben Sie jedem Benutzer den Zugriff auf die in der Regel angegebenen Ressourcen wurde erfolgreich mit dem ABC-idp-Dienst authentifiziert
6. Domain = app.example.com; authservice=XYZ-P1-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Zugriff auf den XYZ-Kollaborationsraum für Benutzer zulassen, die mit dem XYZ-P1-idp-Dienst authentifiziert sind.
7. Domain = app.example.com; authservice=XYZ-P2-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Zugriff auf den XYZ-Kollaborationsraum für Benutzer zulassen, die mit dem XYZ-P2-idp-Dienst authentifiziert sind.
8. Domain = app.example.com; authservice=ABC-P1-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Zugriff auf den ABC-Kollaborationsraum für Benutzer zulassen, die mit dem ABC-P1-idp-Dienst authentifiziert sind.
9. Domain = app.example.com; authservice=ABC-P2-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Zugriff auf den ABC-Kollaborationsraum für Benutzer zulassen, die mit dem ABC-P2-idp-Dienst authentifiziert sind.
10. Domain = app.example.com; authservice=google.com; uri = /tenants/XYZ/public-api/* ALLOW: Zugriff auf den öffentlichen XYZ-API-Bereich für alle mit google.com authentifizierten Benutzer zulassen.
11. Domain = app.example.com; authservice=facebook.com; uri = /tenants/XYZ/public-api/* ALLOW: Zugriff auf den öffentlichen XYZ-API-Bereich für alle mit facebook.com authentifizierten Benutzer zulassen
12. Domain = app.example.com; authservice=linkedin.com; uri = /tenants/ABC/public-api/* ALLOW: Zugriff auf den öffentlichen ABC-API-Bereich für alle mit LinkedIn.com authentifizierten Benutzer zulassen
13. Domain = app.example.com; authservice=github.com; uri = /tenants/ABC/public-api/* ALLOW: Zugriff auf den öffentlichen XYZ-API-Bereich für alle mit github.com authentifizierten Benutzer zulassen
14. Domain = app.example.com; DENY: Zugriff auf die Anwendung verweigern, wenn keine der oben genannten Regeln zutrifft.

SASE Lösungen zeichnen sich durch attributbasierte Zugriffskontrolle aus. Das bedeutet, dass sie die Autorisierungsfunktionalität gut beherrschen. Allerdings sind sie hinsichtlich der Authentifizierung nicht sehr umfassend. In den oben genannten Richtlinien werden unterschiedliche Zugriffsebenen gewährt, basierend auf dem Identitätsanbieterdienst (IDP), mit dem sich Benutzer authentifizieren möchten. Einige Benutzer können es auch absichtlich tun want die Authentifizierung bei einem bestimmten IDP-Dienst, um mit minimalen Berechtigungen auf Ressourcen zuzugreifen, um mögliche Fehler bei der Datenexfiltration zu vermeiden.

Rolle von Identitätsbrokern

Um solche Szenarien zu bewältigen, ist die integrierte Funktionalität eines Identitätsbrokers erforderlich. Identitätsbroker fungieren als OIDC-Anbieter (OpenID Connect). SASE/SSE-Proxy-Komponente, während sie als OIDC/SAML/LDAP-Clients für die Upstream-Identitätsdienste (Authentifizierungsdienste) fungiert.

Keycloak, ein Open-Source-IAM-System, ist für viele eine beliebte Wahl. Es kann so konfiguriert werden, dass es die Rolle eines Identitätsbrokers übernimmt und wird häufig von verwendet SASE Dienstleister und Anbieter von Service-Mesh-Produkten. Daher wird hier die Keycloak-Terminologie verwendet. Keycloak bietet die Flexibilität, die Authentifizierung für verschiedene Arten von Anwendungen, einschließlich mandantenfähiger Anwendungen, durchzuführen SaaS um weitere Anwendungsbeispiele zu finden.

Authentifizierung für Multi-Tenant SaaS Anwendungen können mithilfe von „Identitätsbrokern“ auf folgende Weise erreicht werden:

Ein Realm mit jeweils einem Client SaaS Anwendung mit geänderten Authentifizierungsabläufen:

In Fällen, in denen der Anwendungsmandant nicht anhand der identifiziert werden kann URL Pfad- oder HTTP-Anfrageheader, die SASE Die Proxy-Komponente kann nur einen OIDC-Client haben, der mit dem Identitätsbroker kommuniziert. Während der Benutzerauthentifizierung muss der Identitätsbroker wissen, gegen welchen IDP-Dienst er den Benutzer authentifizieren soll. Keycloak bietet Standard-Authentifizierungsabläufe wie Browser-Abläufe und ermöglicht die Erstellung benutzerdefinierter Abläufe und Verknüpfungen mit Keycloak-Clients. SASE nutzt diese Funktion, indem es Authentifizierungsflüsse erstellt, bei denen Benutzer aufgefordert werden, Mandanteninformationen anzugeben. Basierend auf diesen Informationen können die Authentifizierungsabläufe dem Benutzer die verfügbaren Identitätsanbieter zur Auswahl präsentieren. Mit diesen Informationen kann der Broker Benutzer zum entsprechenden Identitätsdienst weiterleiten.

Ein Bereich mit jeweils mehreren Clients SaaS Anwendung:

Wenn der Anwendungsmandant anhand der identifiziert werden kann URL oder HTTP-Anfrageheader, die SASE Die Proxy-Komponente kann so konfiguriert werden, dass sie für jeden Anwendungsmandanten einen Client verwendet. In diesem Fall können Standardbrowserabläufe mit unterschiedlichen Sätzen von Identitätsanbietern verwendet und den entsprechenden Client-Entitäten in Keycloak zugeordnet werden. Dies hat den Vorteil, dass der Benutzer nicht aufgefordert wird, den Mandantennamen anzugeben, was zu einer besseren Benutzererfahrung führt.

Zusammenfassend lässt sich sagen, dass diese Strategien befähigen SASE Lösungen zur effektiven Handhabung der Authentifizierung für mehrere Mandanten SaaS Anwendungen und nutzt dabei die Fähigkeiten von Keycloak als Identitätsbroker.

Richtlinienbasierte OIDC-Clientauswahl

Der Keycloak-Broker bietet Unterstützung für mehrere Realms und mehrere Clients innerhalb jedes Realms. Es ermöglicht Standardauthentifizierungsflüsse, die Erstellung benutzerdefinierter Authentifizierungsflüsse und die Zuordnung dieser Flüsse zu Clients. Die Keycloak-Broker-Funktionalität ermöglicht auch die Vermittlung von Authentifizierungssitzungen zwischen benutzerseitigen Authentifizierungsmechanismen und Backend-Authentifizierungsdiensten (Upstream). Wir haben zuvor besprochen, wie Keycloak Benutzer auffordern kann, ihren Anwendungsmandanten zu identifizieren und den Identitätsdienst für die Authentifizierung auszuwählen.

Diese Fähigkeiten sollten auch von der genutzt werden SASE Proxy, der als OIDC-Client (auch als OIDC-Relay bezeichnet) für verschiedene Kundenanwendungen, einschließlich mandantenfähiger Anwendungen, fungiert.

Das SASE Der Proxy muss mehrere OIDC-Clients unterstützen. Ein Ansatz besteht darin, für jeden Kunden eine Reihe von OIDC-Clients zu haben, um sicherzustellen, dass kundenspezifische authentifizierungsbezogene Konfigurationen von anderen isoliert sind. Normalerweise jeder SASE Das OIDC-Set des Kunden ist mit einem Bereich in Keycloak verknüpft.

In Szenarien, in denen ein Kunde der SASE Da der Proxy über mehrere Anwendungen verfügt, von denen jede ihren eigenen Domänennamen hat, ist es notwendig, für eine Isolierung zwischen mehreren Anwendungsadministratoren zu sorgen. In solchen Fällen sollte eine Teilmenge 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 Single-Tenant-Anwendungen handelt oder wenn der Mandant nicht anhand des Datenverkehrs identifiziert werden kann, wie bereits erläutert. Wenn der Mandant jedoch identifiziert werden kann, kann für jeden Anwendungsmandanten ein OIDC-Client konfiguriert werden.

Aufgrund der Anforderung mehrerer OIDC-Clients ist die SASE Der Proxy sollte einen Mechanismus zur Auswahl des geeigneten OIDC-Clients bieten. Hier kommt der richtlinienbasierten OIDC-Auswahl entscheidende Bedeutung zu.

Es wird eine Richtlinientabelle mit mehreren Richtlinien verwendet, wobei jede Richtlinie auf den entsprechenden OIDC-Client-Datensatz verweist. Während des Verkehrsflusses ist die SASE Der Proxy prüft, ob eine OIDC-Authentifizierung erforderlich ist, und gleicht dann den Kunden, den Anwendungsdomänennamen und den Anwendungsmandanten mit den Richtlinien in der Tabelle ab. Wenn eine Übereinstimmung gefunden wird, wird der entsprechende OIDC-Client-Datensatz für die Kommunikation mit dem Broker verwendet. Einige Implementierungen verfügen möglicherweise über mehrere Richtlinientabellen, wobei jedem Kunden eine Tabelle zugeordnet ist, um den Richtlinienabgleichsprozess zu beschleunigen.

NextGen ZTNA passt sich an mandantenfähige Anwendungen an

ZTNA (Zero Trust Network Access) innerhalb 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 Anwendungen, sodass sich Entwickler auf ihre Kerngeschäftslogik konzentrieren können. Dieser Ansatz steigert die Produktivität und erhöht die allgemeine Sicherheit.

Schwachstellen bei der Authentifizierungsumgehung und der Rechteausweitung kommen in Anwendungen häufig vor, da nicht alle Entwickler über Fachwissen im Bereich Sicherheit verfügen. Durch das Auslagern der Sicherheit können diese Schwachstellen beseitigt und so eine stärkere Anwendungsresilienz gewährleistet werden.

Zentralisierung der Sicherheit in einem alltäglichen Bereich, z SASEvereinfacht die Arbeit von Sicherheitsadministratoren, die nur eine einzige Schnittstelle für alle Anwendungen verwalten müssen.

Um sowohl Sicherheit als auch Flexibilität zu erreichen, ist die nächste Generation von ZTNA enthalten SASE Lösungen sollten verschiedene Anwendungstypen abdecken. Viele bestehende ZTNA-Lösungen haben oft Schwierigkeiten, mandantenfähige Anwendungen effektiv zu unterstützen. Zukünftige Verbesserungen werden voraussichtlich Identitätsbrokerfunktionen und richtlinienbasierte OIDC-Clientauswahl (OpenID Connect) umfassen, um ein breites Spektrum an Anwendungsszenarien abzudecken.

• CTO Insights-Blog

  Die Aryaka-CTO-Insights-Blogserie bietet Vordenker für Netzwerk, Sicherheit und SASE-Themen. Aryaka Produktspezifikationen beziehen sich auf Aryaka Datenblätter.