Warum Identitätsbewusstsein in SASE?

Verwirklichung von identitätsbewusstem SASE In meinem vorherigen Blog über die Entschlüsselung von SASE habe ich über das Identitätsbewusstsein in verschiedenen Sicherheitskomponenten von SASE gesprochen. Dieser Beitrag beschreibt die verschiedenen Methoden zur Realisierung von identitätsbewusstem SASE. Die Zugriffskontrollen in der traditionellen Perimeter-Sicherheit werden über IP-Adressen und Dienste definiert. Clients werden in Zugriffsrichtlinien als IP-Adressen dargestellt, und Dienste werden entweder mit Domänennamen & IP-Adressen zusammen mit TCP/UDP-Ports wie Port 80 für HTTP und 443 für HTTPS usw. definiert. Da es verschiedene Arten von Kunden gibt – menschliche Benutzer, die über PCs/Laptops/Mobile, Client-Anwendungen, IoT-Geräte und verschiedene menschliche Benutzerkategorien auf Dienste zugreifen – wurde ein Segmentierungsansatz entwickelt, bei dem jedes Segment verschiedene Arten von Kunden repräsentiert. Jedem Segment wird ein eigenes Subnetz oder ein eigener IP-Adressbereich zugewiesen. So können Sie Zugriffskontrollen für verschiedene Arten von Clients definieren. Obwohl es einige Herausforderungen bei der Definition der Zugriffskontrollen für verschiedene Clients löste, führte es eine weitere Reihe von Komplexitäten ein – die Segmentverwaltung. Schnell erkannten viele Unternehmen die Explosion der Segmente. Unternehmen erkannten die Notwendigkeit, verschiedene Segmente für die Definition differenzierter QoS, die Auswahl von WAN-Verbindungen und verschiedene Arten von Sicherheitszugangskontrollen zu schaffen. Eine weitere große Herausforderung bei der Segmentierung ist das „Arbeiten von überall„. Das heißt, die IP-Adresse des Benutzers ändert sich ständig, je nachdem, von wo aus der Benutzer arbeitet. In diesem Fall wird die Zuordnung des Benutzers zu einem Segment schnell zu einer großen Herausforderung. Benutzer, die von ausgewiesenen Büros, von zu Hause, von Cafés, von einem anderen Büro oder von Partnerbüros aus arbeiten, werden gleich behandelt, unabhängig davon, von wo aus der Benutzer arbeitet. Identitätsbewusstes SASE vereinfacht die Segmentverwaltung, indem es die Erstellung von Segmenten zur Unterscheidung von Kunden überflüssig macht, zumindest für menschliche Benutzer. Allerdings können Sie die Segmente für Kunden wie IoT-Geräte nicht vollständig abschaffen. Identitätsbewusstes SASE ist auch für die „Digitale Forensik“ erforderlich. Wenn es zu einer Datenverletzung kommt, ist es wichtig zu wissen, was während des Angriffs passiert ist, um die Vorgehensweise der Angreifer und die ausgenutzten Schwachstellen zu verstehen und die Gesamtauswirkungen zu ermitteln. Laut dem „2022 Verizon Data Breach Report“ sind 82% der Datenschutzverletzungen auf das menschliche Element zurückzuführen. Daher ist die Identität jeder Verbindung/Sitzung äußerst wichtig, um die Zugriffsmuster, die besuchten Websites, die vom Benutzer verwendeten Geräte und Anwendungen zu verstehen, die zur ersten Infektion geführt haben. Das kann dann weiter dabei helfen, die seitlichen Angriffe herauszufinden, die letztendlich zu dem Einbruch führen. Zusammenfassend lässt sich sagen, dass das Identitätsbewusstsein in SASE dabei hilft:

  • Definition von differenzierten Zugriffsrichtlinien über Firewall, SWG, CASB und ZTNA für verschiedene Benutzer
  • Definition von differenzierten Netzwerkrichtlinien über QoS, Routing für verschiedene Benutzer
  • Digitale Forensik
  • Analyse des Benutzerverhaltens

Identität in der SASE-Politik

SASE-Komponenten kontrollieren den Zugang zu verschiedenen Diensten/Seiten mit unterschiedlicher Granularität. Firewall der SASE-Kontrollzugänge auf den L3/L4-Schichten. SWG kontrolliert den Zugriff auf der Ebene der URLs. ZTNA und CASB kontrollieren den Zugang auf der Ebene der APIs. SWG, ZTNA und CASB mit DLP können den Zugriff auf der Datenebene kontrollieren. Alle diese Kontrollen sind erforderlich, wenn der Benutzer einer der Selektoren ist, und zwar aus den oben erläuterten Gründen und um die von der NIST festgelegten Richtlinien für Zero Trust zu erfüllen. Jede Zugriffskontrollpolitik enthält eine Reihe von Regeln, meist geordnete Regeln. Diese Regeln werden für jede Verkehrssitzung überprüft. Wenn die Regel zutrifft, werden die in der entsprechenden Regel angegebenen Aktionen ausgeführt. Typische Aktionen sind das Zulassen des Datenverkehrs, das Verweigern des Datenverkehrs oder die Überwachung und Protokollierung des Datenverkehrs. Jede Regel wird mit einer Reihe von Attributen abgeglichen. Jede Regel wird mit den Werten dieser Attribute angegeben. Diese Attribute umfassen üblicherweise 5-Tupel (Quell-IP, Ziel-IP, Protokoll, Quell- und Ziel-Port), Zonen und Standorte. Bei einer neuen Verkehrssitzung werden Werte aus dem Paket und dem Kontext (Zone, Ort) extrahiert und mit den Werten der Regelattribute abgeglichen. Wenn sie übereinstimmen, gilt die Regel als erfüllt. Bei SASE mit Identitätsbewusstsein umfassen die Attribute für den Regelabgleich auch Benutzerattribute. Bei den Benutzerattributen kann es sich um einzelne Benutzernamen, Benutzergruppen, Benutzerrollen, Namen von Client-Zertifikatssubjekten oder alternative Namen von Zertifikatssubjekten handeln. Der Richtlinienabgleich umfasst den Abgleich mit dem Benutzerkontext für identitätsbasierte SASE. Ein typischer Richtlinienabgleich für eine neue Verkehrssitzung sieht folgendermaßen aus:

  • Extrahieren Sie 5 Tupel (Quell-IP-Adresse, Ziel-IP-Adresse, IP-Protokoll, Quell-Port und Ziel-Port) aus dem Paket.
  • Ermitteln Sie die Quellzone und den Ort, von dem die Datenverkehrssitzung ausging.
  • Ermitteln Sie die Informationen des Benutzers (Name, Benutzergruppe und Benutzerrolle), der die Datenverkehrssitzung initiiert hat.
  • Ermitteln Sie den Zustand des Geräts, von dem die Datenverkehrssitzung ausging.
  • Gehen Sie die Regeln von oben nach unten durch, indem Sie die oben extrahierten Informationen mit den Attributwerten der Regel abgleichen. Wenn es eine Übereinstimmung gibt, führen Sie die in der Regel angegebene Aktion aus. Wenn nicht, gehen Sie zur nächsten Regel über.
  • Wenn es keine passende Regel gibt, ergreifen Sie die für diese Richtlinientabellenebene konfigurierte Aktion.

Benutzeridentifizierung und -authentifizierung

Da ein Benutzer identifiziert werden muss, bevor die Richtlinien für Verkehrssitzungen überprüft werden, stellen sich einige Fragen:

  • Wie authentifiziert SASE die Benutzer?
  • Wie identifiziert SASE den Benutzer, wenn es den Datenverkehr empfängt?

Bevor wir dazu übergehen, sollten wir einige Überlegungen anstellen, um die sich SASE-Lösungen kümmern sollen. SASE muss die folgenden Arten von Kunden berücksichtigen:

  • Menschliche Benutzer, die mit Browsern auf Dienste zugreifen
  • Menschliche Benutzer, die über Nicht-Browser-Anwendungen auf Dienste zugreifen
  • Nicht-Browser-Anwendungen, die ohne menschliches Zutun auf Dienste zugreifen können
  • Nicht-Browser-Anwendungen mit CA-Zertifikatspinning
  • IoT-Geräte, die auf Dienste zugreifen

Das bedeutet, dass SASE-Lösungen nicht davon ausgehen können, dass es immer menschliche Benutzer gibt, die die Verkehrssitzungen initiieren. Es kann sich um programmatische Einheiten und Geräte handeln, die die Verkehrssitzungen initiieren. Von SASE wird erwartet, dass es beide Arten von Kunden bedient, und daher unterstützen SASE-Lösungen mehrere Authentifizierungsmethoden. SASE muss die folgenden Herausforderungen für die Benutzererfahrung berücksichtigen:

  • Eine Benutzererfahrung, bei der menschlichen Benutzern keine oder weniger Popup-Fenster für die Eingabe von Benutzerdaten angezeigt werden
  • Benutzererfahrung, bei der menschliche Benutzer darüber informiert werden, warum ein bestimmter Zugang verweigert wird
  • Benutzer verwenden ihre eigenen Geräte für den Zugriff auf Dienste
  • Benutzer, die vom Arbeitgeber verwaltete Geräte für den Zugriff auf Dienste verwenden
  • Einheitliche Erfahrung für Benutzer, egal ob sie von zu Hause oder vom Büro aus arbeiten

Angesichts der oben genannten Anforderungen und Auswirkungen implementieren SASE-Lösungen verschiedene Authentifizierungsmodi. Die meisten der von SASE-Lösungen unterstützten Authentifizierungsmodi sind hier aufgeführt.

  • Reverse-Proxy-Authentifizierung
  • Weiterleitungs-Proxy-Authentifizierung
  • Portalbasierte Authentifizierung
  • Tunnel-Authentifizierung
  • Client-Zertifikat-Authentifizierung
  • Authentifizierung mit API-Schlüssel

Sobald sich die Clients über die oben genannten Verfahren bei SASE authentifizieren, muss SASE über eine Möglichkeit verfügen, die vom Benutzer initiierten Datenverkehrssitzungen dem richtigen Benutzer zuzuordnen. Es werden zwei Ansätze zur Identitätszuordnung verwendet. Sie sind:

  • Token-Zuordnung: SASE-Lösungen identifizieren den Benutzer anhand von Authentifizierungs-/Identitäts-/Bearer-Token in den Anfrage-Headern von HTTP/HTTPS-Verkehrssitzungen. Die Kunden erhalten Token als Teil der Authentifizierung und diese werden von den Kunden in den Verkehrssitzungen vorgelegt.
  • Repräsentative IP-Zuordnung: Bei diesem Ansatz repräsentiert die IP-Adresse den Benutzer. SASE-Lösungen verwenden die Quell-IP-Adresse der Traffic-Sitzung, um den Benutzer zu identifizieren. Wenn sich ein Benutzer zum ersten Mal erfolgreich bei der SASE authentifiziert, speichert die SASE die IP-Adresse dieses Benutzers. Alle Datenverkehrssitzungen, die zu einem späteren Zeitpunkt von dieser IP-Adresse ausgehen, werden dann dem Benutzer zugeordnet.

Token sind nur für HTTP/HTTPS-Verkehrssitzungen gültig. Da die Token in jeder HTTP-Sitzung entweder direkt oder indirekt über Cookies vorhanden sind, gilt sie als sicherer als die ‚Repräsentative IP‘. Für Nicht-HTTP/HTTPS-Verkehrssitzungen wird das Mapping ‚Repräsentative IP‘ von SASE-Lösungen verwendet. Beachten Sie, dass die Zuordnungsmethode ‚Repräsentative IP‘ einige Herausforderungen mit sich bringt, da die IP-Adresse von allen Anwendungen auf dem Rechner verwendet wird. Das heißt, auch wenn ein Browser-Benutzer bei der SASE-Lösung authentifiziert ist, hat nicht nur der Browser, sondern auch alle anderen Client-Anwendungen, die auf dem Rechner laufen, den gleichen Zugriff. Bei Mehrbenutzersystemen erhalten alle Benutzer dieses Systems Zugriff, selbst wenn sich ein Benutzer erfolgreich bei der SASE-Lösung authentifiziert. Noch gefährlicher wird es, wenn sich das System, das zur Authentifizierung beim SASE-System verwendet wird, hinter einem NAT-Gerät befindet. Alle Benutzer hinter dieser NAT-IP-Adresse erhalten dann Zugriff. Daher ist es besonders wichtig, die Funktion ‚Repräsentative IP‘ nur dann zu verwenden, wenn es notwendig ist, und zu versuchen, diese Zuordnung nur auf Nicht-HTTP/HTTPS-Sitzungen zu beschränken. Da das Token (über den Proxy-Autorisierungs-Header oder Autorisierungs-Header oder über ein Cookie) Teil jeder HTTP-Anfrage ist, kann nur die Client-Anwendung, die mit der SASE-Lösung authentifiziert ist, das Token senden. Von anderen webbasierten Client-Anwendungen, die Zugang benötigen, wird erwartet, dass sie sich gegenüber der SASE-Lösung authentifizieren, um Zugang zu erhalten. Aufgrund der Sicherheitsvorteile wird dringend empfohlen, die Token-Zuordnung für alle HTTP/HTTPS-Sitzungen zu verwenden.

Benutzerauthentifizierung und -identifizierung durch verschiedene SASE-Komponenten

Viele SASE-Komponenten, die Sicherheit für webbasierte Anwendungen/Dienste bieten, neigen dazu, Benutzer über Token in HTTP-Anfrage-Headern, Client-Zertifikate oder API-Schlüssel zu identifizieren und mit Verkehrssitzungen zu verknüpfen. In den folgenden Abschnitten finden Sie eine Zuordnung der relevanten und besten Authentifizierungsmodi zu verschiedenen SASE-Komponenten.

ZTNA

ZTNA soll, wie in diesem Blog beschrieben, die Unternehmensanwendungen vor bösartigen und infizierten Clients schützen. ZTNA bietet durch Front-End-Anwendungsdienste die folgenden Funktionen.

  • TLS/SSL-Sicherheit für Nicht-TLS/SSL-Anwendungen und für Anwendungen, die keine starken Verschlüsselungsalgorithmen unterstützen
  • RBAC / Least Privilege-Zugriffsunterstützung für Anwendungen, die kein RBAC unterstützen, und für Anwendungen, die RBAC der zweiten Ebene erfordern
  • Verwaltung von Zugriffsrechten mit einer weiteren MFA-Ebene
  • Lastausgleich des Datenverkehrs über mehrere Anwendungsinstanzen
  • WAF und Schutz vor Bedrohungen auf API-Ebene für Anwendungen

ZTNA wird zunehmend zu einer Notwendigkeit, da es den Anwendungsdiensten die Sicherheitsverantwortung abnimmt. Zu den daraus resultierenden Vorteilen gehören eine höhere Produktivität bei der Entwicklung von Unternehmensanwendungen, eine einheitliche Sicherheitskonfiguration für mehrere Anwendungsdienste und eine geringere Angriffsfläche. ZTNA ist hauptsächlich für die Sicherung webbasierter Anwendungen gedacht. Anwendungsentwickler erstellen nicht nur neue Anwendungen mit Webprotokollen, sondern auch bestehende Anwendungen werden webifiziert, um von den Innovationen der Webprotokolle zu profitieren. Selbst die traditionellen Verwaltungsprotokolle wie SSH werden mit Projekten wie Apache Guacamole webifiziert. Allerdings wird es immer auch Nicht-Web-Anwendungen geben. Eine Firewall als Teil von SASE bietet Zugriffskontrolle und Schutz vor Bedrohungen für die vom Unternehmen instanziierten Nicht-Webdienste. Weitere Informationen finden Sie im Abschnitt über die Firewall. Wie erhält ZTNA Zugriff auf den Datenverkehr? ZTNA erhält auf zwei Arten Zugriff auf den Datenverkehr – über die DNS-Methode und die transparente Proxy-Methode. Administratoren von Unternehmensanwendungen konfigurieren die autorisierenden Domänenserver so, dass sie auf die ZTNA für die Anwendungen verweisen. Das heißt, Administratoren konfigurieren DNS-Server so, dass sie auf DNS-Anfragen zu FQDNs von Anwendungen mit ZTNA-IP-Adressen antworten. Bei der transparenten Proxy-Methode wird davon ausgegangen, dass sich die ZTNA in der Leitung des Datenverkehrs befindet, oder dass eine Entität in der Leitung des Datenverkehrs den Datenverkehr abfängt und an die ZTNA weiterleitet. Anwendungsadministratoren konfigurieren ZTNA auch mit TLS/SSL-Zertifikat/privaten Schlüsselpaaren im Namen von Anwendungsdiensten. Wie authentifiziert ZTNA Benutzer und ordnet Verkehrssitzungen den Benutzern zu? ZTNA unterstützt Reverse-Proxy-Authentifizierung, Client-Zertifikate und API-Schlüssel-Authentifizierungsmodi, um verschiedene Arten von Clients zu authentifizieren – menschliche Benutzer ebenso wie programmatische Entitäten. Es funktioniert folgendermaßen:

  • ZTNA beendet die TLS/SSL-Verbindung
  • Wenn das Client-Zertifikat ausgehandelt wird, validiert es das Client-Zertifikat. Wenn es gültig ist, extrahiert es den Subject-Namen und das SAN (Subject Alt Name) des Zertifikats. Das sind die Identitäten der Client-Benutzer. Wenn eine Benutzergruppe oder eine Rolle bereitgestellt wird, extrahiert es die Gruppen- und Rolleninformationen aus der bereitgestellten Datenbank.
  • Wenn der Client den API-Schlüssel vorlegt, verweist er auf die interne (bereitgestellte) Datenbank, um die Benutzeridentität zu extrahieren. Wenn eine Benutzergruppe oder eine Rolle bereitgestellt wird, extrahiert es die Gruppen- und Rolleninformationen aus der bereitgestellten Datenbank.
  • Wenn der HTTP-Anfrage ein Authentifizierungs-/Identitäts-Token zugeordnet ist, bedeutet dies, dass der Benutzer zuvor authentifiziert wurde. Es bedeutet auch, dass der Benutzerkontext (Benutzername, Benutzergruppe und ggf. Benutzerrolle) der ZTNA bekannt ist.
  • Wenn das Token ungültig ist oder kein Token vorhanden ist, wird der Benutzer aufgefordert, sich über OIDC zu identifizieren und zu authentifizieren. Der OIDC-Broker der ZTNA kann seinerseits verschiedene Authentifizierungsprotokolle verwenden, damit sich der Benutzer bei den Authentifizierungsdiensten des Unternehmens authentifizieren kann. Für privilegierte Konten führt ZTNA seine eigene MFA durch, um sicherzustellen, dass der Benutzer tatsächlich ein echter Benutzer ist.
  • Wenn der Benutzer erfolgreich authentifiziert wurde, richtet die OIDC-Komponente der ZTNA das Identitäts-Token ein. Es notiert auch die Benutzerinformationen (Benutzername, Benutzergruppe, falls vorhanden, und Benutzerrolle, falls vorhanden)
  • ZTNA stellt dann eine Verbindung zu einer der Anwendungsdienstinstanzen her.
  • Es führt benutzerbasierte Zugriffskontrollentscheidungen pro HTTP-Transaktion durch.
  • Wenn ZTNA für den erweiterten Schutz vor Bedrohungen konfiguriert ist, wird der Datenverkehr auch auf Exploits, Malware und sensible Datenlecks überprüft.

Ein Benutzer wird nur einmal zur Eingabe seiner Anmeldedaten aufgefordert, bis der Identitäts-Token abgelaufen ist. Aufgrund der „same-origin“-Politik der Clients präsentieren sie bei HTTP-Transaktionen mit Anwendungsdiensten immer das richtige Identitäts-Token. Wenn das Identitäts-Token gültig ist, würde ZTNA diese Information verwenden, um die Sitzung dem richtigen Benutzer zuzuordnen.

SWG und CASB

Die SWG-Komponente schützt die Benutzer vor dem Besuch von Malware, Phishing und unsicheren Websites. Außerdem schützt es Client-Anwendungen davor, nach einer Infektion C&C-Botnet-Seiten zu kontaktieren. Darüber hinaus bietet SWG eine Möglichkeit, den Zugang zu verschiedenen Websites je nach Rolle des Benutzers im Unternehmen und der Gruppe, der er angehört, zu differenzieren. SWG zeichnet auch die Metadaten der Datenverkehrssitzung zusammen mit den Benutzerinformationen auf, die bei verschiedenen Analysen und der digitalen Forensik helfen können. Die CASB-Komponente schützt die Unternehmensdaten, die von SaaS-Anbietern verwaltet werden, indem sie sicherstellt, dass nur die richtigen Benutzer auf die Daten zugreifen und sie ändern können, indem sie eine Zugriffskontrolle auf API-Ebene für verschiedene SaaS-Anwendungen verwendet. Genau wie SWG zeichnet CASB auch die API-Metadaten mit den Benutzerinformationen für verschiedene Analysen und digitale Forensik auf. Sowohl die SWG- als auch die CASB-Komponenten erfordern eine Inspektion des HTTP/HTTPS-Verkehrs, der von den Benutzern zu Internet-Sites geht. SWG und CASB beenden Client-Verbindungen, fangen SSL-Verbindungen ab, wenn dies erlaubt ist, und führen eine tiefer gehende Inhaltsprüfung durch, um Malware zu erkennen und zu verhindern und um das Entweichen sensibler Daten zu verhindern. Wie erhalten SWG und CASB Zugriff auf den Datenverkehr? SWG & CASB Proxy erhalten über zwei Methoden Zugriff auf den Datenverkehr – Proxy/PAC-Methode und transparente Methode. Bei der Proxy/PAC-Methode werden die Client-Rechner/Anwendungen entweder manuell mit Proxy-Einstellungen konfiguriert oder die Client-Anwendungen konfigurieren sich automatisch über die automatische Erkennung von Proxys. Sobald die Client-Anwendungen die Proxys kennen, verwenden sie die Methode HTTP CONNECT, um die Datensitzungen zu tunneln, bei denen es sich normalerweise um HTTP- und HTTPS-Transaktionen handeln würde. HTTP CONNECT URI gibt das beabsichtigte Ziel der internen HTTP- und HTTPS-Transaktionen an. Der Proxy verwendet diese URL, um die Verbindung zur Zielsite herzustellen. Proxies führen alle Zugriffskontroll- und Bedrohungsschutzdienste aus, bevor sie die Daten von Clients und Servern und umgekehrt durchlassen. Bei der transparenten Proxy-Methode wissen die Clients nichts von den Proxys. Man geht davon aus, dass sich Proxys in der Leitung des Datenverkehrs befinden, um den Datenverkehr mitzubekommen. Wie authentifiziert der SWG/CASB-Proxy Benutzer und ordnet Verkehrssitzungen Benutzern zu? Wenn die Proxy/PAC-Methode verwendet wird, um den SWG/CASB-Proxy zu erreichen, dann erhalten die Proxys die Möglichkeit, die Benutzer als Teil der HTTP CONNECT-Transaktion zu authentifizieren. Dies wird als „Forward-Proxy-Authentifizierung“ bezeichnet. Die auf HTTP CONNECT basierende Forward-Proxy-Authentifizierung wird hier sehr gut beschrieben. Obwohl dieser Link die NTLM-Authentifizierung beschreibt, ist ein ähnlicher Ablauf auch für die Kerberos-Authentifizierung anwendbar. Da HTTP CONNECT jeder HTTP/HTTPS-Verkehrssitzung vorausgeht, ist der Benutzer dem Proxy bei jeder Sitzung bekannt. Ein Vorteil dieser Methode ist, dass die meisten nativen Client-Anwendungen zusätzlich zu den Browser-Anwendungen auch die Proxy-Einstellungen anerkennen und sich bei den Proxies authentifizieren können, wodurch die meisten Anwendungsfälle für den Internetzugang abgedeckt werden. Bei der transparenten Proxy-Methode gibt es keine HTTP CONNECT-Transaktion. Daher ist eine Forward-Proxy-Authentifizierung nicht möglich. Jede Benutzerauthentifizierung muss mit regulären HTTP-Authentifizierungsschemata erfolgen, z.B. durch Umleitung der HTTP-Anfrage an das SASE-Portal, das wiederum OIDC- und SAML-Methoden zur Authentifizierung von Benutzern verwendet. Diese Art der Authentifizierung wird als „portalbasierte Authentifizierung“ bezeichnet. Sobald sich der Benutzer erfolgreich anmeldet, kann das Portal das Cookie setzen, das jedoch für den Proxy nicht sichtbar ist, wenn der Benutzer aufgrund der Same-Origin-Policy in Browsern auf Internetseiten surft. Aufgrund dieser Herausforderung erstellt das Portal nach der erfolgreichen Anmeldung des Benutzers die Zuordnung zwischen dem Benutzernamen und der Quell-IP-Adresse der Benutzerauthentifizierungssitzung und informiert den Proxy über diese Zuordnung. Der Proxy verwendet diese Zuordnung zu einem späteren Zeitpunkt, um die Verkehrssitzungen dem Benutzer zuzuordnen. Wenn keine Zuordnung vorhanden ist, leitet der Proxy den Datenverkehr zur Anmeldung an das Portal weiter. Diese „Zuordnung“ wird „Repräsentative IP-Zuordnung“ genannt. Wie bereits beschrieben, sollte diese Mapping-Methode mit Bedacht eingesetzt werden, da sie den Zugang zu unbeabsichtigten Parteien öffnen könnte. Transparente Proxy-Methoden hängen davon ab, dass die eingehenden HTTP-Transaktionen umgeleitet werden. Das bedeutet, dass er den klaren Datenverkehr über SSL-Abhörung abfangen muss. Es gibt Fälle, in denen das Abfangen von SSL/TLS nicht erlaubt oder nicht möglich ist. Da eine Umleitung in diesen Fällen nicht möglich ist, wird erwartet, dass sich der Benutzer über andere Mechanismen bei SASE authentifiziert, z. B. über eine proaktive Authentifizierung mit dem Portal oder über ‚Tunnelauthentifizierung‘.

Firewall und L3/L4-basierte Funktionen

Die Firewall und die damit verbundenen NAT-, Routing- und QoS-Funktionen arbeiten mit Paketen auf der L3/L4-Ebene. Diese Funktionen müssen in Systemen untergebracht werden, die sich in der Hauptverkehrslinie befinden. Häufiger sind SASE-Systeme mit diesen Funktionen Gateways für den Datenverkehr, der von Standorten und Remote-Benutzern kommt. Da die Firewall alle Arten von Protokollen jenseits von HTTP und HTTPS im Hinblick auf Zugriffskontrolle, Reverse-Proxy und Forward-Proxy behandelt, sind On-Demand-Portal-Authentifizierungsmechanismen nicht möglich. Für die Benutzerauthentifizierung werden hauptsächlich zwei Modi verwendet: Explizite Portalauthentifizierung und Tunnelauthentifizierung. Im expliziten Portalauthentifizierungsmodus wird von den Benutzern erwartet, dass sie sich beim SASE-Portal authentifizieren, indem sie den Browser auf das SASE-Portal richten. Das SASE-Portal authentifiziert zusammen mit OIDC die Benutzer. Auch in diesem Fall verwendet SASE die Methode der ‚repräsentativen IP‘-Zuordnung. Das SASE-Portal sendet bei erfolgreicher Benutzerauthentifizierung die Zuordnung von IP-Adresse und Benutzer an die Firewall. Firewall- und L3/L4-Funktionen verwenden diese Zuordnungsdatensätze, um die Verkehrssitzungen mit den Benutzern zu verknüpfen. Der Tunnel-Authentifizierungsmodus erfordert eine spezielle Software, die auf den Client-Geräten installiert werden muss. Kunden machen Tunnelsitzungen mit SASE proaktiv. Ein Teil dieses Tunnels wird mit der SASE authentifiziert. Wenn IPSec-basierte Tunnel verwendet werden, wird die Tunnelauthentifizierung von der Komponente SASE/IKEv2 übernommen. Die SASE/IKEv2-Komponente gibt den Benutzer (Initiator-ID) und die Zuordnung der virtuellen IP-Adresse an die SASE-Sicherheits- und Netzwerkdienste weiter. Firewall- und L3/L4-Funktionen verwenden die Zuordnungsmethode ‚Repräsentative IP‘, um die Verkehrssitzungen dem Benutzer zuzuordnen. Auch wenn diese beiden Authentifizierungsmodi hier explizit erwähnt werden, kann die Zuordnung von IP-Adresse zu Benutzer auch von Proxys kommen, wenn sich ein Benutzer bei Proxys im Modus ‚Reverse Proxy‘ oder ‚Forward Proxy‘ authentifiziert. Ein Punkt, den Sie hier beachten sollten, ist, dass eine Benutzerauthentifizierung erwartet wird, wenn die benutzerspezifischen Regeln wirksam sein sollen. Wenn der Benutzer nicht authentifiziert ist, geht die Logik der Richtlinienübereinstimmung davon aus, dass der Benutzer unbekannt ist. Aus diesem Grund werden benutzerbasierte Richtlinien auf der Firewall- und L3/L4-Ebene als opportunistisch betrachtet. Um die Benutzer zur proaktiven Anmeldung anzuregen/zu erinnern, generieren SASE-Lösungen in der Regel Browser-Benachrichtigungen, die die Benutzer darüber informieren, dass sie sich beim SASE-Portal anmelden müssen.

Einheitliche SASE und Identität

Unified SASE wurde hier besprochen, und in diesem Beitrag wurden verschiedene Vorteile genannt, die Unternehmen durch „Unified SASE“-Angebote erhalten. Wenn die SASE aus verschiedenen einzelnen Komponenten aufgebaut ist, kann es sein, dass die Benutzerauthentifizierung mehrfach erfolgt, was für den Benutzer nicht gerade angenehm ist. Mit ‚Unified SASE‘ wird erwartet, dass die Benutzer nur einmal für die gesamte SASE authentifiziert werden. Dies ist ein zusätzlicher Vorteil von ‚Unified SASE‘. Unified SASE-Angebote fügen Benutzerinformationen zu relevanten Protokollnachrichten auf einheitliche und umfassende Weise zu einer gemeinsamen Observability-Plattform hinzu. Es hilft bei verschiedenen Analysen und der Erkennung von Anomalien durch die Überwachung des Benutzerverhaltens über SDWAN- und Sicherheitsdienste hinweg.

Zusammenfassung

Der Ansatz der Mikro-Segmentierung ist notwendig, aber die Ausweitung der Mikro-Segmentierung zur Kategorisierung verschiedener Benutzer ist keine skalierbare Lösung. SASE-Lösungen ermöglichen zunehmend die identitätsbasierte Definition und Durchsetzung von Richtlinien. SASE-Lösungen tun dies, indem sie die Benutzer authentifizieren und dann die Verkehrssitzungen den Benutzern zuordnen. SASE-Lösungen bieten verschiedene Möglichkeiten für die Authentifizierung von Benutzern bei SASE. Dieser Beitrag beschreibt einige der Methoden. Aryaka begann die Reise der ‚identitätsbewussten SASE‘. Die Aryaka SWG-Lösung unterstützt die Durchsetzung von benutzerspezifischen Richtlinien. Erfahren Sie hier mehr über die Aryaka SWG-Lösung: https://www.aryaka.com/secure-web-gateway/

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