Der mit Transport Layer Security (TLS) verschlüsselte Traffic macht den Großteil des Webtraffics aus. Da Bedrohungsakteure diese verschlüsselten Kanäle häufig verwenden, um schädliche 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 Einsicht in die verschlüsselte 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.Zertifikatgenerierung: Secure Web Proxy generiert in Echtzeit ein temporäres Zertifikat für
www.example.com. Je nach konfiguriertem Zertifikatsausstellungsmodus fordert der Proxy entweder untergeordnete Zertifikate direkt vom CA Service für jede Domain an oder signiert sie lokal mit einem im Cache gespeicherten Zwischenzertifikat der Zertifizierungsstelle aus dem CA-Pool.Vertrauensvalidierung: Der Client erhält dann dieses temporäre Zertifikat.
Prüfpunkt: Der Traffic wird innerhalb der Secure Web Proxy-Instanz entschlüsselt. In dieser Phase werden Sicherheitsrichtlinien auf die Nur-Text-HTTP-Daten angewendet.
Server-Handshake: Secure Web Proxy initiiert dann eine zweite TLS-Verbindung zum eigentlichen Zielserver. Der Traffic wird neu verschlüsselt und an die Zieladresse gesendet.
Wichtige Features
Der TLS-Prüfdienst von Secure Web Proxy bietet ein flexibles, skalierbares Framework für die Verwaltung von verschlüsseltem Traffic mit den folgenden Funktionen:
Integrierte private Vertrauensstellung: Die integrierte Einbindung in 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. Anschließend können Sie ein komplett neues Root-Zertifikat direkt in CA Service generieren und verwalten.
Spezifische Entschlüsselung: Verwenden Sie
SessionMatcher, um genau zu definieren, welcher Traffic entschlüsselt werden soll. Sie können die TLS-Prüfung anhand der folgenden Parameter auslösen:- Website-Domainnamen: Bestimmte Websites werden mithilfe von regulären Ausdrücken und Domainlisten abgeglichen.
- Netzwerkkriterien: Sie können bestimmte Quell-IP-Adressbereiche oder CIDR-Blöcke (Classless Inter-Domain Routing) wie
10.0.0.0/24als Ziel festlegen, um Netzwerkgrenzen zu definieren. - Boolesche Logik: Kombinieren Sie mehrere Bedingungen, z. B. eine Quell-IP und eine Ziel-URL, um sehr spezifische Sicherheitsregeln zu erstellen.
Skalierbare Richtlinienarchitektur:
Dedizierte Richtlinien: Weisen Sie jeder Secure Web Proxy-Richtlinie eine eindeutige TLS-Prüfungsrichtlinie und einen 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 Sichtbarkeit des Uniform Resource Identifier (URI): 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: Mit der TLS-Prüfung können Sie Richtlinien für bestimmte Pfade einer Website 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 untergeordnete Zertifikate zu signieren, anstatt domänenspezifische Anfragen direkt an CA Service zu senden. Weitere Informationen finden Sie unter Modi für die Zertifikatsausstellung.
Rolle von Zertifizierungsstellen bei der TLS-Prüfung
Zur Prüfung von verschlüsseltem Traffic fungiert Secure Web Proxy als vertrauenswürdige Mittelsperson. Dies umfasst einen koordinierten Prozess zwischen dem Proxy, dem CA Service und dem Clientgerät.
Anforderungen an die Vertrauenswürdigkeit von 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).
Vertrauen in Agentencontainer: Wenn Sie ausgehenden Webtraffic von containerisierten KI-Agenten weiterleiten, z. B. in Cloud Run oder der Google Kubernetes Engine (GKE), müssen Sie das Stamm-CA-Zertifikat aus Ihrem CA-Pool oder Ihrer privaten Public-Key-Infrastruktur (PKI) exportieren und in den Trust Store für Zertifikate des Containers einfügen. Sie können beispielsweise entweder Ihre Containerlaufzeit konfigurieren oder die Umgebungsvariable
AGENT_GATEWAY_ROOT_CERTIFICATESoderSSL_CERT_FILEfestlegen. Weitere Informationen zum Konfigurieren der Root-Zertifizierungsstelle finden Sie unter TLS-Prüfung einrichten im Abschnitt „Secure Web Proxy als Agent-Gateway bereitstellen“.Privater Trust-Anchor: 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.
Verwaltungsbereich: Verbindungen von nicht verwalteter Hardware lösen in der Regel
Insecure connection-Warnungen aus, da diese Geräte nicht über den spezifischen Trust-Anchor Ihrer Organisation verfügen.
Fehler beim Abfangen beheben
Selbst auf verwalteten Geräten können bestimmte Verbindungen aufgrund von Zertifikat-Pinning nicht abgefangen werden. Das Certificate Pinning erfolgt, wenn eine Anwendung so hartcodiert 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 hohen Sicherheitsanforderungen.
- Ergebnis des Zertifikat-Pinnings: Wenn Secure Web Proxy sein signiertes Zertifikat präsentiert, erkennt die Anwendung, dass das Zertifikat nicht den hartcodierten Erwartungen entspricht, und beendet die Verbindung.
Aussetzung von Maßnahmen und präzise Kontrolle
Um Dienstunterbrechungen für angeheftete Anwendungen zu verhindern oder die Privatsphäre für vertrauliche 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 voll qualifizierte 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 der 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 konfigurieren.
Signieren von lokalen Zwischenzertifizierungsstellen
Wenn Sie certificateIssuanceMode auf LOCAL_INTERMEDIATE_CA_SIGNING setzen, fordert Secure Web Proxy ein einzelnes Zwischen-CA-Zertifikat von Ihrem CA-Pool an. Der Proxy speichert diese Zwischenzertifizierungsstelle im Cache und signiert die einzelnen untergeordneten Zertifikate lokal für die erforderlichen Domains.
Der Modus für die Ausstellung von Signaturzertifikaten durch eine lokale Zwischenzertifizierungsstelle bietet folgende Funktionen:
Niedrigere CA Service-Kosten: Anfragen an CA Service sind auf den Aktualisierungszyklus der Zwischenzertifizierungsstelle (normalerweise einmal pro Tag) beschränkt und erfolgen nicht für jede Domain. Dies führt zu niedrigeren Transaktionskosten.
Eingeschränkte Beobachtbarkeit: Einzelne untergeordnete Zertifikate, die Ihr Proxy lokal signiert, werden nicht in den Audit-Logs von CA Service aufgezeichnet.
Direkte Leaf-Bereitstellung
Wenn Sie certificateIssuanceMode auf DIRECT_LEAF_PROVISIONING setzen, kommuniziert Secure Web Proxy für jede eindeutige Domain direkt mit Ihrem CA Service-Pool, um ein untergeordnetes Zertifikat anzufordern.
Der Modus für die direkte Zertifikatsausstellung für Blattzertifikate bietet folgende Funktionen:
Bessere Beobachtbarkeit: Jede generierte Zertifikatsanfrage wird in den Audit-Logs von CA Service aufgezeichnet, 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, kann dieser Prozess in Umgebungen mit mehreren eindeutigen Domains oder Proxy-Aufgaben zu höheren Transaktionsgebühren führen.
Konfigurationsmethoden für Zertifizierungsstellen
Wenn Sie die TLS-Prüfung aktivieren möchten, richten Sie Ihre Zertifizierungsstelle mit einer der folgenden Methoden ein:
Untergeordnete Zertifizierungsstelle in CA Service: Verwenden Sie eine vorhandene externe Stammzertifizierungsstelle, um eine untergeordnete Zertifizierungsstelle zu signieren, die in Google Cloudgespeichert ist.
Externe Stammzertifizierungsstelle: Verwenden Sie eine externe Stammzertifizierungsstelle, um Zertifikate zu signieren, die zur Laufzeit über untergeordnete Zertifizierungsstellen generiert werden.
Von Google verwaltete Root-Zertifizierungsstelle: Generieren Sie ein neues Root-Zertifikat direkt in CA Service, um Ihre untergeordneten Zertifizierungsstellen zu signieren.
Weitere Informationen zu diesen Methoden finden Sie unter Untergeordneten CA-Pool erstellen.