Identitätsbewusst realisieren SASE

Warum Identitätsbewusstsein in SASE?

Mein vorheriger Blog auf SASE entschlüsseln sprach über Identitätsbewusstsein in verschiedenen Sicherheitskomponenten von SASE. In diesem Beitrag werden die verschiedenen Methoden zur identitätsbewussten Realisierung beschrieben SASE.

Zugriffskontrollen in der traditionellen perimeterzentrierten Sicherheit werden mithilfe von IP-Adressen und Diensten definiert. Clients werden in Zugriffsrichtlinien als IP-Adressen dargestellt und Dienste werden entweder mit Domänennamen und IP-Adressen definiert TCP/UDP-Ports wie Port 80 für HTTP und 443 für HTTPS usw. Da es verschiedene Arten von Clients gibt – menschliche Benutzer, die über PCs/Laptops/Mobilgeräte auf Dienste zugreifen, Client-Anwendungen, IoT-Geräte und verschiedene Kategorien menschlicher Benutzer, wird ein Segmentierungsansatz verwendet Jedes Segment, das verschiedene Arten von Kunden darstellt, wird erfunden. Jedes Segment erhält ein eigenes Subnetz oder einen eigenen IP-Adressbereich. Dadurch ist es möglich, Zugriffskontrollen für verschiedene Arten von Clients zu definieren.

Obwohl einige Herausforderungen bei der Definition der Zugriffskontrollen für verschiedene Clients angegangen wurden, führte es zu weiteren Komplexitäten: Segmentmanagement. Schnell bemerkten viele Unternehmen die Explosion der Segmente. Organisationen begannen, die Notwendigkeit zu erkennen, verschiedene Segmente zur Definition von Differenzierung zu schaffen QoS, WAN Linkauswahl und verschiedene Arten von Sicherheitszugriffskontrollen.

Eine weitere große Herausforderung bei der Segmentierung hängt mit „von überall aus arbeiten.“ 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 Benutzerzuordnung zu einem Segment schnell zu einer großen Herausforderung. Benutzer, die in bestimmten Büros, von zu Hause, in 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ätsbewusst SASE Vereinfacht die Segmentverwaltung, indem zumindest für menschliche Benutzer die Erstellung von Segmenten zur Differenzierung von Kunden entfällt. Allerdings können Sie Segmente für Clients wie IoT-Geräte möglicherweise nicht vollständig entfernen.

Identitätsbewusst SASE ist auch für „Digitale Forensik“ erforderlich. Bei einer Datenschutzverletzung 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 der"Verizon-Datenschutzbericht 2022„Bei 82 % der Datenschutzverletzungen war der Mensch beteiligt. Daher ist die Identität jeder Verbindung/Sitzung äußerst wichtig, um die Zugriffsmuster, besuchten Websites, Geräte und Anwendungen des Benutzers zu verstehen, die zur ersten Infektion geführt haben. Dies kann dann weiter dabei helfen, die seitlichen Angriffe herauszufinden, die letztendlich zu der Sicherheitsverletzung führen.

Zusammenfassend lässt sich sagen, dass Identitätsbewusstsein in SASE hilft bei:

• Definieren differenzierter Zugriffsrichtlinien für Firewall, SWG, CASB und ZTNA für verschiedene Benutzer
• Definieren differenzierter Netzwerkrichtlinien übergreifend QoS, Routing für verschiedene Benutzer
• Digitale Forensik
• Analyse des Benutzerverhaltens

Identität in SASE Politik durchzulesen

SASE Komponenten Kontrollieren Sie den Zugriff auf verschiedene Dienste/Sites mit unterschiedlicher Granularität. Firewall von SASE Kontrollieren Sie den Zugriff auf den L3/L4-Ebenen. SWG kontrolliert den Zugriff auf der Ebene von URLS. ZTNA und CASB Kontrollieren Sie den Zugriff auf der Ebene von APIs. SWG, ZTNA und CASB Mit DLP kann der Zugriff auf Datenebene gesteuert werden. Alle diese Kontrollen sind aus den oben erläuterten Gründen und zur Einhaltung der vom NIST festgelegten Zero-Trust-Richtlinien erforderlich, wobei der Benutzer einer der Selektoren ist.

Jede Zugriffskontrollrichtlinie enthält eine Reihe von Regeln, meist geordnete Regeln. Diese Regeln werden für jede Verkehrssitzung überprüft. Wenn die Regel übereinstimmt, werden die in der übereinstimmenden Regel angegebenen Aktionen ausgeführt. Typische Aktionen umfassen das Zulassen des Datenverkehrs, das Verweigern des Datenverkehrs oder einfach nur das Überwachen und Protokollieren des Datenverkehrs. Der Abgleich jeder Regel erfolgt mit einer Reihe von Attributen. Jede Regel wird mit Werten dieser Attribute angegeben. Zu diesen Attributen gehören traditionell 5-Tupel (Quell-IP, Ziel-IP, Protokoll, Quell-Port und Ziel-Port), Zonen und Standorte. Bei einer neuen Verkehrssitzung werden Werte aus dem Paket und dem Kontext (Zone, Standort) extrahiert und mit den Werten der Regelattribute abgeglichen. Wenn sie übereinstimmen, gilt die Regel als erfüllt.

Mit Identitätsbewusstsein SASEZu den Regelübereinstimmungsattributen gehören Benutzerattribute. Benutzerattribute können eine Reihe einzelner Benutzernamen, Benutzergruppen, Benutzerrollen, Namen von Client-Zertifikatssubjekten oder alternative Namen von Zertifikatssubjekten sein. Der Richtlinienabgleich umfasst den Abgleich mit dem Benutzerkontext für identitätsbasierte Richtlinien SASE.

Der typische Richtlinienabgleich bei einer neuen Datenverkehrssitzung sieht wie folgt aus:

• Extrahieren Sie 5 Tupel (Quell-IP-Adresse, Ziel-IP-Adresse, IP-Protokoll, Quellport und Zielport) aus dem Paket.
• Rufen Sie die Quellzone und den Standort ab, von dem die Datenverkehrssitzung stammt.
• Rufen Sie die Informationen des Benutzers (Name, Benutzergruppe und Benutzerrolle) ab, der die Verkehrssitzung initiiert hat.
• Rufen Sie den Gerätestatus des Computers ab, von dem die Datenverkehrssitzung ihren Ursprung hat.
• Gehen Sie die Regeln der Richtlinie von oben nach unten durch, indem Sie die oben extrahierten Informationen mit Regel-Matching-Attributwerten abgleichen. Wenn es eine Übereinstimmung gibt, ergreifen Sie die in dieser Regel angegebenen Maßnahmen. Wenn nicht, fahren Sie mit der nächsten Regel fort.
• Wenn keine passende Regel vorhanden ist, ergreifen Sie die für diese Richtlinientabellenebene konfigurierten Maßnahmen.

Benutzeridentifikation und -authentifizierung

Da ein Benutzer identifiziert werden muss, bevor Richtlinienprüfungen für die Verkehrssitzungen durchgeführt werden, stellen sich einige Fragen:

• Wie funktioniert SASE die Benutzer authentifizieren?
• Wie funktioniert SASE Identifizieren Sie den Benutzer, wenn er den Datenverkehr empfängt?

Bevor wir dorthin gehen, werfen wir einen Blick auf einige Überlegungen SASE-Lösungen soll sich darum kümmern. SASE muss die folgenden Arten von Kunden berücksichtigen:

• Menschliche Benutzer, die Browser verwenden, um auf Dienste zuzugreifen
• Menschliche Benutzer, die Nicht-Browser-Anwendungen verwenden, um auf Dienste zuzugreifen
• Nicht-Browser-Anwendungen, die ohne menschliches Eingreifen funktionieren, um auf Dienste zuzugreifen
• Nicht-Browser-Anwendungen mit CA-Zertifikat-Pinning
• IoT-Geräte greifen auf Dienste zu

Die Implikation ist das SASE Lösungen können nicht davon ausgehen, dass es immer menschliche Benutzer gibt, die die Verkehrssitzungen initiieren. Es können programmatische Entitäten und Geräte vorhanden sein, die die Verkehrssitzungen initiieren. SASE Es wird erwartet, dass beide Arten von Kunden bedient werden SASE Lösungen unterstützen mehrere Authentifizierungsmethoden.

SASE muss die folgenden Herausforderungen für die Benutzererfahrung berücksichtigen:

• Benutzererfahrung, bei der menschlichen Benutzern keine oder weniger Popup-Bildschirme zur Erfassung von Benutzeranmeldeinformationen angezeigt werden
• Benutzererfahrung, bei der menschliche Benutzer darüber informiert werden, warum ein bestimmter Zugriff verweigert wird
• Benutzer verwenden ihre eigenen Geräte für den Zugriff auf Dienste
• Benutzer, die vom Arbeitgeber verwaltete Geräte verwenden, um auf Dienste zuzugreifen
• Einheitliches Erlebnis für Benutzer, egal ob sie von zu Hause oder im Büro arbeiten

Mit den oben genannten Anforderungen und Implikationen, SASE Lösungen implementieren verschiedene Authentifizierungsmodi. Die meisten Authentifizierungsmodi werden von unterstützt SASE Lösungen finden Sie hier.

• Reverse-Proxy-Authentifizierung
• Proxy-Authentifizierung weiterleiten
• Portalbasierte Authentifizierung
• Tunnelauthentifizierung
• Client-Zertifikatsauthentifizierung
• API-Schlüsselbasierte Authentifizierung

Sobald sich Clients authentifizieren SASE über die oben genannten, SASE muss über eine Möglichkeit verfügen, die vom Benutzer initiierten Verkehrssitzungen dem richtigen Benutzer zuzuordnen. Es werden zwei Identifikations-Mapping-Ansätze verwendet. Sie sind:

• Token-Zuordnung: SASE Lösungen identifizieren den Benutzer anhand des Authentifizierungs-/Identitäts-/Bearer-Tokens in Anforderungsheadern von HTTP/HTTPS-Verkehrssitzungen. Clients erhalten im Rahmen der Authentifizierung Token und diese werden von Clients in den Verkehrssitzungen präsentiert.
• Repräsentative IP-Zuordnung: Bei diesem Ansatz steht die IP-Adresse für den Benutzer. SASE Lösungen verwenden die Quell-IP-Adresse der Verkehrssitzung, um den Benutzer zu identifizieren. Wenn sich ein Benutzer zum ersten Mal mit dem authentifiziert SASE erfolgreich, SASE zeichnet die Benutzer-IP-Adresse für diesen Benutzer auf. Alle späteren Verkehrssitzungen, die von dieser IP-Adresse ausgehen, werden dann dem Benutzer zugeordnet.

Token sind nur für HTTP/HTTPS-Verkehrssitzungen gültig. Da 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 die Zuordnung „Repräsentative IP“ von verwendet SASE Lösungen. Beachten Sie, dass die Zuordnungsmethode „Repräsentative IP“ einige Herausforderungen mit sich bringt, da die IP-Adresse von allen Anwendungen im Gerät verwendet wird. Das heißt, auch wenn ein Browserbenutzer beim authentifiziert ist SASE Lösung haben nicht nur der Browser, sondern auch alle anderen Client-Anwendungen, die auf dem Computer ausgeführt werden, denselben Zugriff. Bei Mehrbenutzersystemen erhalten alle Benutzer dieses Systems Zugriff, auch wenn sich ein Benutzer erfolgreich beim System authentifiziert SASE Lösung. Noch gefährlicher ist es, wenn das System zur Authentifizierung verwendet wird SASE Das System befindet sich hinter einem NAT-Gerät. Alle Benutzer hinter dieser NAT-IP-Adresse erhalten Zugriff. Daher ist es besonders wichtig, die Funktion „Repräsentative IP“ nur bei Bedarf zu verwenden und diese Zuordnung nur auf Nicht-HTTP/HTTPS-Sitzungen zu beschränken.

Da das Token (per Proxy-Authorization-Header oder Authorization-Header oder per Cookie) Teil jeder HTTP-Anfrage ist, kann nur die Client-Anwendung verwendet werden, die mit dem authentifiziert ist SASE Die Lösung kann das Token senden. Von anderen webbasierten Clientanwendungen, die Zugriff erfordern, wird erwartet, dass sie sich gegenüber dem authentifizieren SASE Lösung, um Zugriff zu erhalten. Aufgrund der Sicherheitsvorteile wird dringend empfohlen, den Token-Mapping-Ansatz 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-Anforderungsheadern, Client-Zertifikaten oder API-Schlüsseln zu identifizieren und Traffic-Sitzungen zuzuordnen.

Die folgenden Abschnitte bieten eine Zuordnung der relevanten und besten Authentifizierungsmodi zu verschiedenen SASE Komponenten.

ZTNA

ZTNA, wie hier besprochen letzten Blog, soll den Ent schützenerpRise-Anträge aus Maliciouns und infizierte Kunden. 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 Kryptografiealgorithmen 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
• Berechtigungszugriffsverwaltung mit einer weiteren MFA-Ebene
• Lastausgleich des Datenverkehrs über mehrere Anwendungsinstanzen hinweg
• Bedrohungsschutz auf WAF- und API-Ebene für Anwendungen

ZTNA wird zunehmend zu einer Notwendigkeit, da es den Anwendungsdiensten die Sicherheitsverantwortung entzieht. Zu den daraus resultierenden Vorteilen gehört eine Steigerung der Produktivität von EnterpSteigerung der Anwendungsentwicklung, einheitliche Sicherheitskonfiguration für mehrere Anwendungsdienste und 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 zu profitieren, die bei Webprotokollen stattfinden. Sogar die traditionellen Verwaltungsprotokolle wie SSH werden mithilfe von Projekten wie z. B. webifiziert Apache Guacamole. Allerdings wird es immer Nicht-Web-Anwendungen geben. Eine Firewall als Teil von SASE Bietet Zugriffskontrolle und Bedrohungsschutz für EnterpAnstieg instanziierter Nicht-Web-Dienste. Weitere Einzelheiten finden Sie im Abschnitt „Firewall“.

Wie erhält ZTNA Zugriff auf den Datenverkehr?

ZTNA erhält auf zwei Wegen Zugriff auf den Datenverkehr – über den DNS Methode und die transparente Proxy-Methode.

Administratoren von EnterpRise-Anwendungen konfigurieren die autorisierenden Domänenserver so, dass sie auf die ZTNA für die Anwendungen verweisen. Das heißt, Administratoren konfigurieren DNS Server, an die sie mit ZTNA-IP-Adressen antworten können DNS Fragen zur FQ der AnwendungenDNs. Bei der transparenten Proxy-Methode wird erwartet, dass sich ZTNA in der Verkehrslinie befindet, oder es wird erwartet, dass eine Entität in der Verkehrslinie den Verkehr abfängt und an ZTNA sendet. Anwendungsadministratoren konfigurieren ZTNA auch mit TLS/SSL Zertifikat/private Schlüsselpaare im Auftrag von Anwendungsdiensten.

Wie authentifiziert ZTNA Benutzer und ordnet den Benutzern Verkehrssitzungen zu?

ZTNA unterstützt die Authentifizierungsmodi Reverse-Proxy-Authentifizierung, Client-Zertifikat und API-Schlüssel, um verschiedene Arten von Clients zu authentifizieren – menschliche Benutzer sowie programmatische Entitäten. Es funktioniert wie folgt:

• ZTNA beendet das TLS/SSL Verbindung
• Wenn das Client-Zertifikat ausgehandelt wird, wird das Client-Zertifikat validiert. Wenn es gültig ist, werden der Name des Zertifikatssubjekts und der SAN (Subject Alt Name) extrahiert. Das sind Identitäten des Client-Benutzers. Wenn eine Benutzergruppe oder Rolle bereitgestellt wird, werden die Gruppen- und Rolleninformationen aus der bereitgestellten Datenbank extrahiert.
• Wenn der Client den API-Schlüssel vorlegt, verweist er auf die interne Datenbank (bereitgestellt), um die Benutzeridentität zu extrahieren. Wenn eine Benutzergruppe oder Rolle bereitgestellt wird, werden die Gruppen- und Rolleninformationen aus der bereitgestellten Datenbank extrahiert.
• Wenn der HTTP-Anfrage ein Authentifizierungs-/Identitätstoken zugeordnet ist, bedeutet dies, dass der Benutzer zuvor authentifiziert wurde. Dies bedeutet auch, dass der Benutzerkontext (Benutzername, Benutzergruppe und Benutzerrolle, falls vorhanden) 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 von ZTNA kann wiederum verschiedene Authentifizierungsprotokolle verwenden, um dem Benutzer die Authentifizierung bei Ent zu ermöglichenerpAnstieg der Authentifizierungsdienste. 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 von ZTNA das Identitätstoken ein. Außerdem werden die Benutzerinformationen notiert (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 erweiterten Bedrohungsschutz konfiguriert ist, scannt es den Datenverkehr auch auf Exploits, Malware und sensible Datenlecks.

Einem Benutzer wird ein Bildschirm angezeigt, auf dem er Anmeldeinformationen nur einmal eingeben muss, bis das Identitätstoken abgelaufen ist. Aufgrund der Same-Origin-Policy der Clients präsentieren diese in den HTTP-Transaktionen gegenüber Anwendungsdiensten immer das richtige Identitätstoken. Wenn das Identitätstoken gültig ist, würde ZTNA diese Informationen 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. Es schützt Client-Anwendungen außerdem davor, bei einer Infektion C&C-Botnet-Sites zu kontaktieren. Darüber hinaus bietet SWG eine Möglichkeit, differenzierten Zugriff auf verschiedene Websites bereitzustellen, basierend auf der Rolle der Benutzer in der Organisation und der Gruppe, zu der die Benutzer gehören. SWG zeichnet auch die Metadaten der Verkehrssitzung zusammen mit den Benutzerinformationen auf, die bei verschiedenen Analysen und digitaler Forensik hilfreich sein können. CASB Komponente schützt das EnterpAnstiegsdaten gepflegt von SaaS Anbieter, indem sichergestellt wird, dass nur die richtigen Benutzer auf die Daten zugreifen und diese ändern, indem sie die Zugriffskontrolle auf API-Ebene für verschiedene verwenden SaaS um weitere Anwendungsbeispiele zu finden. CASBEbenso wie SWG erfasst es auch die API-Metadaten mit den Benutzerinformationen für verschiedene Analysen und digitale Forensik.

Sowohl SWG als auch CASB Komponenten erfordern eine Überprüfung des HTTP/HTTPS-Verkehrs, der von Benutzern zu Internetseiten gelangt. SWG und CASB Client-Verbindungen beenden, tun SSL Abfangen, sofern zulässig, und Durchführung einer tiefergehenden Inhaltsprüfung, um Malware zu erkennen und zu verhindern und jegliche Lecks sensibler Daten zu verhindern.

Wie funktionieren SWG und CASB Zugriff auf den Verkehr erhalten?

SWG & CASB Der Proxy greift auf den Datenverkehr über zwei Methoden zu: die Proxy/PAC-Methode und die transparente Methode.

Bei der Proxy/PAC-Methode werden Client-Computer/-Anwendungen entweder manuell mit Proxy-Einstellungen konfiguriert oder Client-Anwendungen werden automatisch über die automatische Erkennung von Proxys konfiguriert. Sobald die Clientanwendungen die Proxys kennen, verwenden Clientanwendungen die HTTP CONNECT-Methode, um die Datensitzungen zu tunneln, bei denen es sich normalerweise um HTTP- und HTTPS-Transaktionen handelt. HTTP CONNECT URI gibt das beabsichtigte Ziel der internen HTTP- und HTTPS-Transaktionen an. Der Proxy nutzt dies URL um die Verbindung zur Zielseite herzustellen. Proxys führen sämtliche Zugriffskontroll- und Bedrohungsschutzdienste durch, bevor sie die Weitergabe der Daten von Clients und Servern und umgekehrt zulassen.

Bei der transparenten Proxy-Methode wissen Clients nichts von den Proxys. Es wird erwartet, dass sich Proxys in der Verkehrslinie befinden, um den Verkehr zu kontrollieren.

Wie funktioniert die SWG/CASB Proxy authentifiziert Benutzer und ordnet Verkehrssitzungen Benutzern zu?

Wenn die Proxy-/PAC-Methode zum Erreichen des SWG/ verwendet wirdCASB Proxy, dann erhalten Proxys die Möglichkeit, Benutzer im Rahmen der HTTP CONNECT-Transaktion zu authentifizieren. Dies wird als „Forward-Proxy-Authentifizierung“ bezeichnet. Es wird die HTTP CONNECT-basierte Forward-Proxy-Authentifizierung beschrieben hier sehr gut. Obwohl dieser Link die NTLM-Authentifizierung beschreibt, gilt ein ähnlicher Ablauf auch für die Kerberos-Authentifizierung. Da HTTP CONNECT jeder HTTP/HTTPS-Verkehrssitzung vorausgeht, ist der Benutzer dem Proxy bei jeder Sitzung bekannt. Ein Vorteil dieser Methode besteht darin, dass die meisten nativen Clientanwendungen zusätzlich zu Browseranwendungen auch Proxy-Einstellungen berücksichtigen und sich bei den Proxys authentifizieren können, wodurch die meisten Anwendungsfälle für den Internetzugriff 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 Umleiten der HTTP-Anfrage an SASE Portal, die wiederum OIDC- und SAML-Methoden zur Authentifizierung von Benutzern verwenden. Diese Art der Authentifizierung wird als „Portalbasierte Authentifizierung“ bezeichnet. Sobald sich der Benutzer erfolgreich angemeldet hat, kann das Portal das Cookie setzen. Aufgrund der Same-Origin-Richtlinie in Browsern ist dies jedoch für den Proxy nicht sichtbar, wenn der Benutzer Internetseiten durchsucht. Aufgrund dieser Herausforderung erstellt das Portal nach erfolgreicher Benutzeranmeldung 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 verfügbar ist, leitet der Proxy die Verkehrssitzung zur Anmeldung an das Portal weiter. Diese „Zuordnung“ wird „Repräsentative IP-Zuordnung“ genannt. Wie bereits beschrieben, muss diese Zuordnungsmethode mit Vorsicht verwendet werden, da diese Methode den Zugriff für unbeabsichtigte Parteien ermöglichen könnte.

Transparente Proxy-Methoden basieren auf der Umleitung der eingehenden HTTP-Transaktionen. Das bedeutet, dass es über die SSL-Abhörfunktion auf freien Datenverkehr zugreifen muss. Es gibt Fälle, in denen das Abfangen von SSL/TLS nicht erlaubt oder nicht möglich ist. Da in diesen Fällen eine Umleitung nicht möglich ist, wird erwartet, dass der Benutzer über andere Mechanismen gegenüber SASE authentifiziert wird, beispielsweise über die proaktive Authentifizierung beim Portal oder über die „Tunnelauthentifizierung“.

Firewall- und L3/L4-basierte Funktionen

Firewall und zugehöriges NAT, Routing, QoS Funktionen funktionieren auf Paketen auf der Ebene der L3/L4-Schichten. Diese Funktionen müssen in Systemen vorhanden sein, die in der Verkehrslinie liegen. Öfters, SASE Systeme mit diesen Funktionen sind Gateways für den Datenverkehr von Standorten und Remote-Benutzern.

Da die Firewall in Bezug auf Zugriffskontrolle, Reverse-Proxy und Forward-Proxy alle Arten von Protokollen über HTTP und HTTPS hinaus verarbeitet, sind On-Demand-Portal-Authentifizierungsmechanismen nicht möglich. Zur Authentifizierung der Benutzer werden hauptsächlich zwei Modi verwendet: die explizite Portalauthentifizierung und die Tunnelauthentifizierung.

Im expliziten Portalauthentifizierungsmodus wird von Benutzern erwartet, dass sie sich gegenüber dem Portal authentifizieren SASE Portal, indem Sie den Browser auf das verweisen SASE Portal. Der SASE Das Portal authentifiziert zusammen mit OIDC die Benutzer. Auch in diesem Fall SASE verwendet die Zuordnungsmethode „repräsentative IP“. Der SASE Das Portal sendet nach erfolgreicher Benutzerauthentifizierung die Zuordnung von IP-Adresse und Benutzer an die Firewall. Firewall- und L3/L4-Funktionen verwenden diese Zuordnungsdatensätze, um die Verkehrssitzungen den Benutzern zuzuordnen.

Der Tunnelauthentifizierungsmodus erfordert die Installation spezieller Software auf den Clientgeräten. Clients führen Tunnelsitzungen mit durch SASE proaktiv. Ein Teil dieses Tunnels ist mit dem authentifiziert SASE. Wenn IPSec-basierte Tunnel verwendet werden, übernimmt die Tunnelauthentifizierung die SASE/IKEv2-Komponente. SASEDie /IKEv2-Komponente kündigt die Zuordnung des Benutzers (Initiator-ID) und der virtuellen IP-Adresse an SASE Sicherheits- und Netzwerkdienste. Firewall- und L3/L4-Funktionen verwenden die Zuordnungsmethode „Repräsentative IP“, um die Verkehrssitzungen dem Benutzer zuzuordnen.

Obwohl diese beiden Authentifizierungsmodi hier ausdrücklich erwähnt werden, kann die Zuordnung von IP-Adressen zu Benutzern auch von Proxys erfolgen, wenn sich ein Benutzer bei Proxys in den Modi „Reverse Proxy“ und „Forward Proxy“ authentifiziert.

Hier ist zu beachten, dass eine Benutzerauthentifizierung erwartet wird, wenn benutzerspezifische Regeln wirksam sein sollen. Wenn der Benutzer nicht authentifiziert ist, geht die Richtlinienabgleichslogik davon aus, dass der Benutzer unbekannt ist. Aus diesem Grund gelten benutzerbasierte Richtlinien auf Firewall- und L3/L4-Ebene als opportunistisch. Um die Benutzer zu motivieren/erinnern, sich proaktiv anzumelden, SASE Lösungen neigen dazu, Browserbenachrichtigungen zu generieren, um Benutzer zu informieren, sich anzumelden SASE Portal.

Einheitlicher SASE und Identität

Einheitlicher SASE wurde diskutiert hier, und dieser Beitrag bot verschiedene Vorteile Enterpsteigt von „Unified SASE” Angebote.

Besitzt das SASE aus verschiedenen diskreten Komponenten besteht, kann die Benutzerauthentifizierung mehrmals erfolgen, was keine gute Benutzererfahrung darstellt. Mit „Unified SASEEs wird erwartet, dass Benutzer während des gesamten Vorgangs nur einmal authentifiziert werden SASE. Dies ist ein zusätzlicher Vorteil von „Unified“. SASE. "

Einheitlicher SASE Die Angebote fügen Benutzerinformationen zu relevanten Protokollmeldungen auf einheitliche und umfassende Weise einer gemeinsamen Observability-Plattform hinzu. Es hilft bei verschiedenen Analysen und der Erkennung von Anomalien, indem es das Benutzerverhalten im gesamten SD überwachtWAN und Sicherheitsdienste.

Zusammenfassung

Es ist ein Mikrosegmentierungsansatz erforderlich, aber die Ausweitung der Mikrosegmentierung zur Kategorisierung verschiedener Benutzer ist keine skalierbare Lösung. SASE Lösungen ermöglichen zunehmend eine identitätsbasierte Richtliniendefinition und -durchsetzung. SASE Lösungen tun dies, indem sie die Benutzer authentifizieren und dann Verkehrssitzungen den Benutzern zuordnen. SASE Lösungen bieten Benutzern verschiedene Möglichkeiten zur Authentifizierung SASE. In diesem Beitrag wurden einige der Methoden beschrieben. Aryaka begann die Reise des „Identitätsbewusstseins“. SASE'.  Aryaka Die SWG-Lösung unterstützt die Durchsetzung benutzerspezifischer Richtlinien. Lerne mehr über Aryaka SWG-Lösung hier: https://www.aryaka.com/secure-web-gateway/

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