Der verschlüsselte Traffic mit Transport Layer Security (TLS) macht den Großteil des Webtraffics aus. Da Bedrohungsakteure diese verschlüsselten Kanäle häufig nutzen, um böswillige Aktivitäten zu verbergen, ist es wichtig, diesen Traffic zu prüfen, bevor er sein Ziel erreicht.
Secure Web Proxy bietet einen integrierten TLS-Prüfdienst, mit dem Sie HTTPS-Traffic abfangen und entschlüsseln können. Durch die Sichtbarkeit der verschlüsselten Anfrage kann Secure Web Proxy erweiterte Sicherheitsrichtlinien anwenden, z. B. URL-Filterung für den vollständigen Anfragepfad und HTTP-Header-Prüfung, um Ihre Umgebung vor Bedrohungen zu schützen, die in verschlüsselten Tunneln verborgen sind.
Funktionsweise
Bei der TLS-Prüfung werden zwei separate verschlüsselte Verbindungen hergestellt, wobei Secure Web Proxy als sicherer Vermittler fungiert.
Client-Handshake: Wenn ein Client versucht, eine Verbindung zu einer externen Website wie
www.example.comherzustellen, fängt Secure Web Proxy die Anfrage ab.Zertifikatsgenerierung: Secure Web Proxy generiert in Echtzeit ein temporäres Zertifikat für
www.example.com. Je nach konfiguriertem Modus für die Zertifikatsausstellung fordert der Proxy Blattzertifikate entweder direkt vom CA Service für jede Domain an oder signiert sie lokal mit einem im Cache gespeicherten Zwischen-CA-Zertifikat aus dem CA-Pool.Vertrauensvalidierung: Der Client erhält dann dieses temporäre Zertifikat.
Prüfpunkt: Der Traffic wird in der Secure Web Proxy Instanz entschlüsselt. In dieser Phase werden Sicherheitsrichtlinien auf die HTTP-Daten im Klartext angewendet.
Server-Handshake: Secure Web Proxy initiiert dann eine zweite TLS Verbindung zum tatsächlichen Zielserver. Der Traffic wird neu verschlüsselt und an die Zieladresse gesendet.
Wichtige Features
Der Secure Web Proxy-TLS-Prüfdienst bietet ein flexibles, skalierbares Framework für die Verwaltung von verschlüsseltem Traffic mit den folgenden Funktionen:
Integrierte private Vertrauenswürdigkeit: Die integrierte Integration mit CA Service bietet ein hochverfügbares, von Google verwaltetes Repository für Ihre privaten Zertifizierungsstellen.
Flexible Root of Trust: Verwenden Sie eine vorhandene lokale Root-Zertifizierungsstelle (CA), um untergeordnete Zertifizierungsstellen zu signieren, die in CA Service gehostet werden. Sie können dann direkt in CA Service ein völlig neues Root-Zertifikat generieren und verwalten.
Spezifische Entschlüsselung: Mit
SessionMatcherkönnen Sie genau festlegen, welcher Traffic entschlüsselt werden soll. Sie können die TLS-Prüfung anhand der folgenden Parameter auslösen:- Domainnamen von Websites: Verwenden Sie reguläre Ausdrücke und Domainlisten, um bestimmte Websites abzugleichen.
- Netzwerkkriterien: Legen Sie bestimmte Quell-IP-Adressbereiche oder CIDR-Blöcke (Classless
Inter-Domain Routing) wie
10.0.0.0/24fest, um Netzwerkgrenzen zu definieren. - Boolesche Logik: Kombinieren Sie mehrere Bedingungen wie eine Quell-IP-Adresse und eine Ziel-URL, um hochspezifische Sicherheitsregeln zu erstellen.
Skalierbare Richtlinienarchitektur:
Dedizierte Richtlinien: Weisen Sie jeder Secure Web Proxy-Richtlinie eine eindeutige TLS-Prüfungsrichtlinie und einen eindeutigen CA-Pool zu, um eine strikte Isolation zu erreichen.
Gemeinsame Richtlinien: Vereinfachen Sie die Richtlinienverwaltung, indem Sie eine einzelne TLS- Prüfungskonfiguration für mehrere Proxy-Richtlinien freigeben.
Vollständige URI-Sichtbarkeit (Uniform Resource Identifier): Prüfen Sie den gesamten URI (einschließlich Domain, Pfad und Abfragestrings wie
www.example.com/downloads/malware.exe) und nicht nur den Domainnamen.Präzise Zugriffssteuerung: Verwenden Sie die TLS-Prüfung, um Richtlinien für bestimmte Pfade einer Website zu erzwingen. Sie können beispielsweise den Zugriff auf
www.example.com/documentationzulassen, aberwww.example.com/uploadsblockieren.Unterstützung für Zwischenzertifizierungsstellen: Reduzieren Sie die Nutzungsgebühren für CA Service, indem Sie eine einzelne Zwischenzertifizierungsstelle lokal im Cache speichern, um Blattzertifikate zu signieren, anstatt Anfragen pro Domain direkt an CA Service zu senden. Weitere Informationen finden Sie unter Modi für die Zertifikatsausstellung.
Rolle der Zertifizierungsstellen in der TLS-Prüfung
Um verschlüsselten Traffic zu prüfen, fungiert Secure Web Proxy als vertrauenswürdiger Vermittler. Dabei wird ein koordinierter Prozess zwischen dem Proxy, dem CA Service und dem Clientgerät ausgeführt.
Anforderungen an das Vertrauen des Clients
Die TLS-Prüfung ist für Umgebungen konzipiert, in denen eine Organisation die administrative Kontrolle über die Clientgeräte hat, z. B. verwaltete Laptops, Server oder virtuelle Maschinen (VMs).
- Privater Vertrauensanker: Da Secure Web Proxy Zertifikate präsentiert, die von Ihrer internen Zertifizierungsstelle und nicht von einer öffentlichen Zertifizierungsstelle signiert wurden, vertrauen Clients der Verbindung nur, wenn Ihre private Stammzertifizierungsstelle vorinstalliert ist.
- Administrativer Bereich: Verbindungen von nicht verwalteter Hardware lösen in der Regel
Warnungen vom Typ
Insecure connectionaus, da diese Geräte nicht über den spezifischen Vertrauensanker Ihrer Organisation verfügen.
Fehler beim Abfangen behandeln
Auch auf verwalteten Geräten können bestimmte Verbindungen aufgrund von Certificate Pinning nicht abgefangen werden. Certificate Pinning tritt auf, wenn eine Anwendung so codiert ist, dass sie nur einen bestimmten öffentlichen Schlüssel oder eine bestimmte öffentliche CA-Kette akzeptiert.
- Beispiele für Certificate Pinning: Zu den gängigen Diensten, die Pinning verwenden, gehören Windows- und macOS-Systemupdates, Google Chrome-Updates und bestimmte mobile Anwendungen mit hoher Sicherheit.
- Ergebnis von Certificate Pinning: Wenn Secure Web Proxy sein signiertes Zertifikat präsentiert, erkennt die Anwendung, dass das Zertifikat nicht ihren fest codierten Erwartungen entspricht, und beendet die Verbindung.
Abhilfe und präzise Steuerung
Um Dienstunterbrechungen für angeheftete Anwendungen zu vermeiden oder die Privatsphäre für sensible Websites zu wahren, können Sie das Attribut SessionMatcher verwenden, um die Prüfung zu umgehen. Sie können die Prüfung anhand der folgenden Parameter einschränken oder überspringen:
- Zielattribute: bestimmte vollqualifizierte Domainnamen (FQDNs).
- Quellattribute: sichere Tags, Dienstkonten oder IP-Adressen.
- Benutzerdefinierte Logik: Verwenden Sie boolesche Ausdrücke, um bestimmten Traffic auszuschließen, während Sie den Rest der Umgebung prüfen.
Modi für die Zertifikatsausstellung
Secure Web Proxy unterstützt zwei Modi zum Bereitstellen der Zertifikate, die zum Entschlüsseln von Traffic während der TLS-Prüfung verwendet werden. Die Wahl hängt von Ihren Anforderungen an Kosten, Leistung und Audit-Logging ab.
Weitere Informationen finden Sie unter Lokale Zwischenzertifizierungsstelle zum Signieren konfigurieren.
Lokale Zwischenzertifizierungsstelle zum Signieren
Wenn Sie certificateIssuanceMode auf LOCAL_INTERMEDIATE_CA_SIGNING festlegen, fordert Secure Web Proxy ein einzelnes Zwischenzertifizierungsstellen-Zertifikat aus Ihrem CA-Pool an. Der Proxy speichert diese Zwischenzertifizierungsstelle im Cache und signiert die einzelnen Blattzertifikate lokal für die erforderlichen Domains.
Die Funktionen des Modus für die Zertifikatsausstellung mit lokaler Zwischenzertifizierungsstelle zum Signieren sind wie folgt:
Niedrigere CA Service-Kosten: Anfragen an CA Service sind auf den Aktualisierungszyklus der Zwischenzertifizierungsstelle beschränkt (in der Regel einmal pro Tag) und erfolgen nicht für jede Domain. Dadurch sinken die Transaktionskosten.
Geringere Beobachtbarkeit: Einzelne Blattzertifikate, die von Ihrem Proxy signiert werden lokal nicht in den Audit-Logs von CA Service erfasst.
Direkte Bereitstellung von Blattzertifikaten
Wenn Sie certificateIssuanceMode auf DIRECT_LEAF_PROVISIONING festlegen, kommuniziert Secure Web Proxy für jede eindeutige Domain direkt mit Ihrem CA Service-Pool, um ein Blattzertifikat anzufordern.
Die Funktionen des Modus für die Zertifikatsausstellung mit direkter Bereitstellung von Blattzertifikaten sind wie folgt:
Höhere Beobachtbarkeit: Jede generierte Zertifikatsanfrage wird in den Audit-Logs von CA Service erfasst, sodass Sie alle Aktivitäten zur Zertifikatsgenerierung verfolgen und prüfen können.
Höhere CA Service-Kosten: Da Anfragen für jede Domain an CA Service gesendet werden, können bei Umgebungen mit mehreren eindeutigen Domains oder Proxy Aufgaben höhere Transaktionsgebühren anfallen.
Methoden zur Konfiguration der Zertifizierungsstelle
Um die TLS-Prüfung zu aktivieren, richten Sie Ihre Zertifizierungsstelle (CA) mit einer der folgenden Methoden ein:
Untergeordnete Zertifizierungsstelle in CA Service: Verwenden Sie eine vorhandene externe Stamm Zertifizierungsstelle, um eine untergeordnete Zertifizierungsstelle zu signieren, die in CA Service gespeichert ist Google Cloud.
Externe Stammzertifizierungsstelle: Verwenden Sie eine externe Stammzertifizierungsstelle, um Zertifikate zu signieren, die zur Laufzeit über untergeordnete Zertifizierungsstellen generiert werden.
Von Google verwaltete Stammzertifizierungsstelle: Generieren Sie direkt in CA Service ein neues Root-Zertifikat, um Ihre untergeordneten Zertifizierungsstellen zu signieren.
Weitere Informationen zu diesen Methoden finden Sie unter Untergeordneten CA-Pool erstellen.