Vereinheitlichte SASE-Rolle Cyber-Bedrohungsjagd

Warum Proxies in SASE?

Vorbei sind die Zeiten, in denen die Sicherheit auf Paketebene als ausreichend angesehen wurde. Da die Angriffe immer raffinierter werden, ist eine tiefgehende Inhaltskontrolle für verschiedene Arten von Schutzmaßnahmen unerlässlich. Identitätsbewusster Zugriff ist aufgrund verteilter Mitarbeiter und verteilter Anwendungen eine wichtige Voraussetzung. In diesem Blogbeitrag werden die Anforderungen an den identitätsbasierten Zugriff im Detail erläutert. Eine tiefgreifende Inhaltskontrolle und ein identitätsbewusster Zugriff auf der Ebene von APIs/Anwendungsressourcen erfordert die Beendigung von Client-Verbindungen, eine Inhaltskontrolle zur Erkennung von Bedrohungen und Zugriffskontrolle sowie die Herstellung von Verbindungen über Proxys. Daher implementieren viele SASE-Lösungen Sicherheit durch Proxys.

Proxy-Typen

Sie haben vielleicht schon von den verschiedenen Arten von Proxys gehört – Forward, Reverse und Transparent. Die Hauptfunktionen aller Arten von Proxys sind gleich. Die wichtigsten Funktionen sind hier aufgeführt.

  • Halten Sie den Verkehr aufrecht
  • Beenden Sie Client-Verbindungen.
  • Authentifizieren Sie Clients.
  • Benutzeridentität abrufen.
  • Stellen Sie Verbindungen zu Servern her.
  • TLS-Entschlüsselung und -Verschlüsselung
  • Prüfen Sie die IP- und Domain-Reputation.
  • Führen Sie identitätsbasierte Zugriffskontrollen durch.
  • Führen Sie CASB-Funktionen aus.
  • Prüfen Sie auf Datenverlust und verhindern Sie ihn.
  • Führen Sie die Funktion zur Erkennung und Verhinderung von Eindringlingen aus.
  • Führen Sie die Funktion der Web Application Firewall aus.
  • Suchen Sie nach Malware und Exploit-Indikatoren im Datenverkehr und handeln Sie.

Wie sie sich voneinander unterscheiden, hängt von den folgenden Faktoren ab:

  • Erfassen von Datenverkehr für Bedrohungsprüfung und Zugriffskontrolle
  • Authentifizierung der Benutzer und Identifizierung der Benutzer

Transparenter Proxy-Typ

Bei diesem Typ wissen Clients und Server nichts von der Anwesenheit von Proxys. Diese Proxys erfassen den Datenverkehr von den Netzwerk-Routern, über die der Datenverkehr läuft. Es liegt in der Verantwortung der Netzwerkadministratoren, dafür zu sorgen, dass der Datenverkehr von Bürobenutzern und der von WFH-Benutzern über die Routing-Einheiten des Unternehmens geleitet wird. Um sicherzustellen, dass der Datenverkehr von WFH-Benutzern über die Router des Unternehmens läuft, ist es üblich, VPN-Clients für die Verbindung zu Unternehmensnetzwerken zu verwenden. Im Falle von SD-WAN enden VPN-Tunnel an VPN-Konzentratoren am nächstgelegenen PoP-Standort. Die Benutzerauthentifizierung und die entsprechende Benutzeridentifizierung erfolgt über

  • Explizites Portal
  • On-Demand-Portal
  • VPN-Tunnel einrichten
  • TLS-Client-Zertifikat

Im Falle des „Expliziten Portals“ melden sich die Benutzer proaktiv beim Portal an. Der Portaldienst authentifiziert den Benutzer mit Hilfe von Unternehmensauthentifizierungssystemen. Nach erfolgreicher Überprüfung der Benutzerdaten notiert es die IP-Adresse des Benutzers (von der Quell-IP der Verbindung) und informiert die Proxys über die Zuordnung von Benutzer-ID und IP-Adresse. Sobald der Proxy diese Zuordnungen kennt, identifiziert er den Benutzer anhand der IP-Adresse des Datenverkehrs und führt eine identitätsbewusste Richtliniendurchsetzung durch. Wenn der Benutzer eine Sitzung initiiert, ohne sich proaktiv beim Portal zu authentifizieren, kann der Proxy den Benutzer zum Portal umleiten. Da der Zugang zum Portal nach Bedarf erfolgt, wird diese Methode der Authentifizierung auch als On-Demand-Portalauthentifizierung bezeichnet. Beachten Sie bitte, dass die Umleitung des Benutzers zum Portal nur möglich ist, wenn die Verbindung auf HTTP/HTTPS basiert. Im Falle von HTTPS ist die Umleitung erst nach der TLS-Entschlüsselung möglich. Im Falle des Zugriffs auf nicht-unternehmenseigene Dienste/Seiten muss das Serverzertifikat mit einem unternehmenseigenen CA-Zertifikat nachgebildet werden. Wenn es sich bei dem Benutzer nicht um einen menschlichen Benutzer handelt, der den Browser benutzt, hilft die Umleitung auch nicht weiter. Trotz dieser Vorbehalte ist es für den Proxy immer noch ein wirksames Mittel, um den Benutzer zu authentifizieren und zu identifizieren. Wie bereits kurz erwähnt, müssen sich WFH-Benutzer (Work From Home) über einen VPN-Tunnel mit den Unternehmensnetzwerken verbinden, um Teil des Unternehmensnetzwerks zu sein. Der Aufbau eines VPN-Tunnels führt bereits eine Benutzerauthentifizierung durch. VPN-Konzentratoren weisen jedem Client eine eindeutige private IP-Adresse zu. Clients können so konfiguriert werden, dass sie den VPN-Tunnel und damit diese IP-Adresse als Quelle für die meisten Verbindungen verwenden (auch bei deaktiviertem Split-Tunneling). VPN-Konzentratoren sind in der Lage, die dem Client zugewiesene IP-Adresse, die Benutzer-ID (Initiator-ID) und die Zuordnung zu externen Parteien bekannt zu geben. Proxies verwenden diese Zuordnung, um die Sitzungen zu einem Benutzer zu einem späteren Zeitpunkt zu identifizieren, wenn die Clients Sitzungen initiieren. Wenn das Client-Programm, das die TLS-Sitzung aufgebaut hat, über ein TLS-Client-Zertifikat verfügt, kann es zur Authentifizierung und Identifizierung des Benutzers verwendet werden. Dies wird heute nur noch sehr selten in SASE verwendet, ist aber eine der verfügbaren Optionen. Ein großer Vorteil des transparenten Proxy-Typs ist, dass er den gesamten Protokollverkehr erfassen kann, nicht nur HTTP/HTTPS. Ein weiterer großer Vorteil ist, dass keine spezielle Konfiguration auf den Client- oder Server-Rechnern des Unternehmens erforderlich ist. Es gibt nur wenige Nachteile bei dieser Art von Proxys. Da der Benutzer anhand der im Datenverkehr beobachteten IP-Adresse identifiziert wird, werden alle Anwendungen auf dem Computer des Benutzers mit der gleichen Sicherheit behandelt. Wenn es sich um einen Mehrbenutzer-Rechner handelt, erhalten alle Benutzer dieses Rechners dieselbe Sicherheitsbehandlung bzw. dieselben Privilegien. Wenn diese IP-Adresse mehrere Rechner mit NAT verbindet, erhalten alle Rechner hinter dieser NAT-IP-Adresse die gleiche Zugriffs- und Sicherheitsbehandlung. Stellen Sie sich einen Fall vor, in dem der Laptop des Benutzers mit Malware infiziert ist. Malware erhält den gleichen Zugriff wie für diesen Benutzer definiert, da die Malware Teil desselben Rechners ist, von dem aus sich der Benutzer beim Portal anmeldet. Aus diesem Grund sollten transparente Proxy-Typen mit Vorsicht verwendet werden, zumindest für HTTP/HTTPS-Sitzungen. Ein weiterer Nachteil ist, dass für diese Art von Proxys ein VPN-Client auf den Geräten vorhanden sein muss. Obwohl dies für verwaltete Geräte kein Problem darstellt, kann es eine Herausforderung sein, Mitarbeiter davon zu überzeugen, den VPN-Client auf eigenen Geräten zu installieren.

Weiterleitungs-Proxy-Typ

Forward Proxies sind für Client-Geräte gedacht, die mit externen Diensten/Seiten kommunizieren. Client-Anwendungen sind so konfiguriert, dass sie über einen Forward Proxy mit externen Diensten kommunizieren. Client-Anwendungen werden mit dem FQDN/IP des Proxys und dem Port konfiguriert, auf dem die Proxys lauschen. Im Falle eines transparenten Proxys haben Quell- und Ziel-IP-Adresse der Sitzung niemals eine Proxy-IP-Adresse. Im Falle eines Forward-Proxys gehen die Verbindungen vom Client zur Proxy-IP-Adresse und die Verbindung zum Server erfolgt von der Proxy-IP-Adresse aus. PAC-Dateien werden zur Konfiguration von Client-Anwendungen wie Browsern mit Proxy-Einstellungen verwendet. Die PAC-Datei ermöglicht die Auswahl der Weiterleitung des Datenverkehrs an verschiedene Proxys auf der Grundlage der Ziel-Dienstdomänen. PAC-Dateien werden über Systemverwaltungslösungen oder über den WPAD-Dienst (Web Proxy Auto Discovery) an die Client-Browser verteilt. Client-Anwendungen mit den Proxy-Einstellungen kommunizieren immer mit dem Proxy. Auf diese Weise erfassen Forward Proxies den Datenverkehr. Im Falle von TLS-Verbindungen wie HTTPS beginnt jede TCP-Verbindung mit der Transaktion „HTTP CONNECT“. Diese Transaktion findet nur zwischen dem Client und dem Proxy statt. Nach dieser HTTP CONNECT-Transaktion werden die Daten zwischen Client und Server durch den Proxy vermittelt. Die Transaktion „HTTP CONNECT“ hat ein Host-Header-Feld, dessen Wert vom Proxy verwendet wird, um den endgültigen Ziel-FQDN und -Port zu bestimmen. Im Falle von HTTP2.0 beginnt jede Stream-Verbindung mit der Transaktion „HTTP CONNECT“. Wie Sie vielleicht schon bemerkt haben, muss der Datenverkehr nicht an die Enterprise-Router gesendet werden, damit der Proxy den Datenverkehr erfassen kann. Das heißt, der Datenverkehr geht direkt an den Proxy. Auf diese Weise ist es netzwerkunabhängig. Forward Proxies können die Benutzer auch über die Header proxy-authenticate und proxy-authorization authentifizieren und identifizieren. Bei TLS-Verbindungen werden diese Header in der Antwort bzw. in der Anfrage bei HTTP CONNECT-Transaktionen gesendet. Beachten Sie, dass TLS-Verbindungen für die Authentifizierung und Identifizierung des Benutzers nicht entschlüsselt werden müssen. Es ist keine Portal-Authentifizierung erforderlich. Ein weiterer Vorteil ist, dass viele Browser und Client-Anwendungen Kerberos als Teil der Proxy-Authentifizierung unterstützen. Damit kann sich jeder Benutzer, der sich auf seinem Gerät anmeldet, automatisch mit dem Proxy authentifizieren, ohne dass zusätzliche Anmelde-Popups erscheinen (auch bekannt als SSO). Die Verwendung des Forward-Proxy-Typs für Clients, die mit externen Diensten kommunizieren, hat mehrere Vorteile. Einige davon sind unten aufgeführt.

  • Die Authentifizierung und Identifizierung von Benutzern ist deterministisch. Wenn der Benutzer beim transparenten Proxy-Typ vergisst, sich proaktiv beim Portal zu authentifizieren, ist eine Umleitung zur Benutzerauthentifizierung beim On-Demand-Portal oder Captive Portal erst nach der TLS-Entschlüsselung möglich. Einige Unternehmen erlauben keine TLS-Entschlüsselung für Websites, die personenbezogene Daten sammeln. Wenn Websites das Zertifikats-Pinning einführen, wird nicht erwartet, dass transparente Proxys das Zertifikat nachahmen, so dass eine TLS-Entschlüsselung nicht möglich ist. In diesen Fällen kann der Benutzer nicht ermittelt werden, um eine identitätsbewusste Durchsetzung von Richtlinien zu ermöglichen. Da die Proxy-Authentifizierung vor dem TLS-Austausch stattfindet, ist die Benutzerauthentifizierung und -identifizierung beim Forward-Proxy-Typ deterministisch.
  • Wie bereits erwähnt, ist der Forward Proxy netzwerkunabhängig und kann mit jedem Netzwerk arbeiten, solange die Client-Anwendungen mit Proxy-Einstellungen konfiguriert sind. Ein VPN-Client auf den Geräten ist nicht erforderlich, selbst wenn die Benutzer von zu Hause aus arbeiten.
  • Da viele Client-Anwendungen Kerberos unterstützen, kann der Benutzer SSO nutzen.
  • Encrypted Client Hello (ECH) in TLS 1.3+ wird in der Branche immer beliebter. Wenn ECH eingeführt wird, ist SNI nicht sichtbar und daher kann der transparente Proxy-Typ nicht einmal grundlegende URL-Filterung und Zugriffskontrolle durchführen. Beim Forward-Proxy-Typ kennt der Proxy aufgrund der HTTP CONNECT-Transaktion den Ziel-FQDN, auch wenn ECH verwendet wird. Das heißt, der Forward-Proxy-Typ ist ECH-sicher.
  • Es gibt kein IP-Whitelisting. Jede Client-Anwendung muss sich separat beim Proxy authentifizieren und ist daher sehr sicher.

Es gibt auch ein paar Nachteile. Es funktioniert nur für HTTP/HTTPS-Verkehr. Obwohl die meisten Client-Anwendungen Proxy-Einstellungen unterstützen, gibt es einige, die dies nicht tun.

Reverse Proxy Typ

Reverse Proxies werden für das Frontend von Serveranwendungen verwendet. Reverse Proxies werden verwendet, um Dienste vor Bedrohungen zu schützen, RBAC bereitzustellen, TLS-Sitzungen zu beenden und auch um die Lastverteilung des Datenverkehrs zwischen mehreren Instanzen von Diensten zu gewährleisten. Reverse-Proxys erfassen den Datenverkehr über DNS-Methoden. Der FQDN jedes Unternehmensdienstes, der für Mitarbeiter oder öffentliche Benutzer zugänglich ist, wird in den DNS-Servern des Unternehmens so konfiguriert, dass er auf die IP-Adressen der Reverse-Proxy-Instanzen zeigt. Jedes Mal, wenn ein Benutzer versucht, eine Verbindung zu den Unternehmensdiensten herzustellen, landet der entsprechende Datenverkehr bei den Reverse Proxies. Reverse Proxies beenden auch HTTPS/HTTP-Sitzungen. Im Rahmen dieses Prozesses authentifizieren sie auch die Benutzer und identifizieren dann die Benutzer der Sitzungen über OIDC, SAMLv2 und SPENGO/Kerberos-Methoden. Bei der Kommunikation von App zu App werden die Benutzer auch über TLS-Zertifikate identifiziert.

SASE-Vollmacht

Für eine Einführung in SASE lesen Sie bitte den Blog-Beitrag Deciphering SASE. Wie Sie vielleicht schon bemerkt haben, wird von SASE-Lösungen erwartet, dass sie umfassende Sicherheit bieten – Sicherung von Kunden, Sicherung von SaaS-Daten und Sicherung von Unternehmensanwendungen. Wie im Blogbeitrag Identity-aware-SASE beschrieben, ist die identitätsbasierte Zugriffskontrolle das Hauptmerkmal von SASE. Obwohl viele Unternehmen mit dem HTTP/HTTPS-Zugang allein auskommen, benötigen einige auch Zugangskontrollen für andere Protokolle. Aufgrund dieser Anforderungen glauben wir, dass der SASE-Proxy für Nicht-HTTP-Verkehr und für Client-Anwendungen, die keine Proxy-Einstellungen unterstützen, transparent sein sollte. Der SASE-Proxy fungiert als Forward Proxy für Client-Anwendungen, die auf Internet- und SaaS-Dienste zugreifen, um eine deterministische, identitätsbasierte Zugriffskontrolle zu ermöglichen und auch um zukunftssicher zu sein, wenn ECH eingeführt wird. Der SASE-Proxy soll auch als Reverse-Proxy fungieren, um Unternehmensanwendungen zu schützen. Diese Konvergenz von mehreren Proxy-Typen ist für eine erfolgreiche SASE-Lösung erforderlich.

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