1. Einführung
Cloud Secure Web Proxy
Cloud SWP ist ein Cloud-basierter Dienst, der einen sicheren Webproxy bereitstellt, mit dem Sie ausgehenden Web-Traffic (HTTP/S) schützen können. Sie konfigurieren Ihre Clients so, dass sie Cloud SWP explizit als Proxy verwenden. Die Webanfragen können von den folgenden Quellen stammen:
- VM-Instanzen
- Container
- Eine serverlose Umgebung, die einen serverlosen Connector verwendet
- Arbeitslasten über VPC-Peering
- Arbeitslasten außerhalb von Google Cloud, die über Cloud VPN oder Cloud Interconnect verbunden sind
Cloud SWP ermöglicht flexible und detaillierte Richtlinien basierend auf Cloud-First-Identitäten und Webanwendungen.
Vorteile
Hier sind einige Beispiele für die Vorteile, die Cloud SWP für eine Organisation bieten kann:
Migration zu Google Cloud
Mit Cloud SWP können Sie zu Google Cloud migrieren und gleichzeitig Ihre vorhandenen Sicherheitsrichtlinien und Anforderungen für ausgehenden Web-Traffic beibehalten. Sie können Drittanbieterlösungen vermeiden, für die eine weitere Verwaltungskonsole oder das manuelle Bearbeiten von Konfigurationsdateien erforderlich ist.
Zugriff auf vertrauenswürdige externe Webdienste
Mit Cloud SWP können Sie detaillierte Zugriffsrichtlinien auf Ihren ausgehenden Webtraffic anwenden, um Ihr Netzwerk zu schützen. Sie erstellen und identifizieren Workload- oder Anwendungsidentitäten und wenden dann Richtlinien an.
Überwachter Zugriff auf nicht vertrauenswürdige Webdienste
Mit Cloud SWP können Sie überwachten Zugriff auf nicht vertrauenswürdige Webdienste ermöglichen. Cloud SWP identifiziert Traffic, der nicht der Richtlinie entspricht, und protokolliert ihn in Cloud Logging (Logging). Sie können dann die Internetnutzung überwachen, Bedrohungen für Ihr Netzwerk erkennen und auf Bedrohungen reagieren.
Detaillierte Richtliniensteuerung für Google APIs
Mit Cloud SWP können Sie detaillierte Richtlinien für Google-APIs bereitstellen. Sie können beispielsweise Richtlinien auf Bucket- oder Objektebene mit der Common Expression Language (CEL) festlegen.
Unterstützte Features
Cloud SWP unterstützt die folgenden Funktionen:
Expliziter Proxy-Dienst
Clients müssen explizit für die Verwendung des Proxyservers konfiguriert werden. Der Cloud SWP-Proxy isoliert Clients vom Internet, indem er in ihrem Namen neue TCP-Verbindungen herstellt.
Cloud SWP-Envoy-Proxys automatisch skalieren
Unterstützt die automatische Anpassung der Envoy-Proxy-Poolgröße und der Poolkapazität in einer Region, was für eine konsistente Leistung in Zeiten hoher Nachfrage zu den niedrigsten Kosten sorgt.
Modulare Richtlinien für ausgehenden Zugriff
Cloud SWP unterstützt insbesondere die folgenden Richtlinien für ausgehenden Traffic:
- Quellidentität basierend auf sicheren Tags, Dienstkonten oder IP-Adressen.
- Ziele basierend auf URLs und Hostnamen.
- Anfragen basierend auf Methoden, Headern oder URLs. URLs können über Listen, Platzhalter oder Muster angegeben werden.
- Ende-zu-Ende-Verschlüsselung: Client-Proxy-Tunnel können über TLS übertragen werden. Cloud SWP unterstützt auch HTTP/S CONNECT für clientseitig initiierte End-to-End-TLS-Verbindungen zum Zielserver.
Vereinfachte Cloud NAT-Integration
Cloud NAT stellt automatisch zusätzliche öffentliche IP-Adressen bereit, wenn die Anzahl der Proxys, die Cloud SWP-Traffic verarbeiten, zunimmt.
Manuelle statische öffentliche IP-Adressen sind auch eine Option für Nutzer, die bekannte Ausgangs-IPs haben möchten.
Einbindung von Cloud-Audit-Logs und der Operations-Suite von Google Cloud
In Cloud-Audit-Logs und der Operations-Suite von Google Cloud werden administrative Aktivitäten und Zugriffsanfragen für Cloud SWP-bezogene Ressourcen aufgezeichnet. Außerdem werden Messwerte und Transaktionsprotokolle für Anfragen erfasst, die vom Proxy verarbeitet werden.
TLS-Prüfung
Secure Web Proxy bietet einen TLS-Prüfdienst, mit dem Sie TLS-Traffic abfangen, die verschlüsselte Anfrage prüfen und Sicherheitsrichtlinien erzwingen können.
- Enge Integration mit Certificate Authority Service (CAS), einem hochverfügbaren und skalierbaren Repository für private CAs.
- Bei Bedarf können Sie Ihren eigenen Root of Trust verwenden. Sie können auch eine vorhandene Stamm-CA verwenden, um untergeordnete CAs zu signieren, die von CAS verwaltet werden. Sie können auch ein neues Root-Zertifikat in CAS generieren.
- Detaillierte Entschlüsselungskriterien mit SessionMatcher und ApplicationMatcher in Secure Web Proxy-Richtlinienregeln. Zu diesen Kriterien gehören übereinstimmende Hosts in URL-Listen, regulären Ausdrücken, IP-Adressbereichen und ähnlichen Ausdrücken. Bei Bedarf können Kriterien mit booleschen Ausdrücken kombiniert werden.
- Jede Secure Web Proxy-Richtlinie kann mit einer eigenen TLS-Prüfungsrichtlinie und einem eigenen CA-Pool konfiguriert werden. Alternativ können mehrere Secure Web Proxy-Richtlinien eine einzelne TLS-Prüfungsrichtlinie gemeinsam nutzen.
Lerninhalte
- Cloud SWP bereitstellen und verwalten
Voraussetzungen
- Kenntnisse in der Bereitstellung von Instanzen und der Konfiguration von Netzwerkkomponenten
- VPC-Firewallkonfiguration
2. Testumgebung
In diesem Codelab wird eine einzelne VPC verwendet. Eine Computeressource in dieser Umgebung verlässt das Netzwerk über das Cloud SWP, wie im Diagramm unten zu sehen ist.
In diesem Lab haben wir zwei VMs für Arbeitslasten.
Client A wird so konfiguriert, dass alle HTTP-/HTTPS-Anfragen an den Cloud-SWP gesendet werden.
Client B wird NICHT so konfiguriert, dass HTTP-/HTTPS-Anfragen explizit an den Cloud SWP gesendet werden. Stattdessen wird Cloud NAT für internetgebundenen Traffic verwendet.
3. Hinweis
Für das Codelab ist ein einzelnes Projekt erforderlich.
Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist.
export project_id=`gcloud config list --format="value(core.project)"` export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"` export region=us-west1 export zone=us-west1-a export prefix=codelab-swp export member="serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com"
4. APIs aktivieren
APIs aktivieren, um die Produkte zu verwenden
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. VPC-Netzwerk, Subnetz und Nur-Proxy-Subnetz erstellen
VPC-Netzwerk
Erstellen Sie das VPC-Netzwerk „codelab-swp-vpc“:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Subnetz
Erstellen Sie die entsprechenden Subnetze in der ausgewählten Region:
gcloud compute networks subnets create $prefix-vpc-subnet \ --range=10.10.10.0/24 --network=$prefix-vpc --region=$region
Nur-Proxy-Subnetz
Erstellen Sie ein Nur-Proxy-Subnetz in der ausgewählten Region:
gcloud compute networks subnets create $prefix-proxy-only-subnet --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$region --network=$prefix-vpc --range=172.16.0.0/23
6. Firewallregeln erstellen
Damit IAP eine Verbindung zu Ihren VM-Instanzen herstellen kann, erstellen Sie eine Firewallregel, die:
- Gilt für alle VM-Instanzen, die über IAP zugänglich sein sollen.
- Lässt eingehenden Traffic aus dem IP-Bereich 35.235.240.0/20 zu. Dieser Bereich enthält alle IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.
Über Cloud Shell:
gcloud compute firewall-rules create $prefix-allow-iap-proxy \ --direction=INGRESS \ --priority=1000 \ --network=$prefix-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
7. Cloud Router und Cloud NAT erstellen
Cloud Router für Cloud NAT erstellen
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
Erstellen Sie ein Cloud NAT-Gateway für Client B.
gcloud compute routers nats create $prefix-nat-gw-$region \ --router=$prefix-cr \ --router-region=$region \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges
8. Gateway-Sicherheitsrichtlinie erstellen
Erstellen Sie eine YAML-Datei, die relevante Informationen für die Richtlinie enthält:
cat > /tmp/policy.yaml << EOF
description: Policy to allow .com traffic, then (/index.html), and finally TLS.
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
EOF
Führen Sie den gcloud-Befehl aus, um die Richtlinie aus der YAML-Datei zu erstellen:
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. Regel für Gateway-Sicherheitsrichtlinie erstellen
Erstellen Sie eine YAML-Datei mit den Regeln. Diese Regeln werden in der Common Expression Language (CEL) dargestellt. In diesem Lab wird eine einfache Regel verwendet, mit der Traffic zu .com-Domains zugelassen und alle anderen blockiert werden:
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
EOF
Jetzt können wir die Regel an die Gateway-Sicherheitsrichtlinie binden:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
10. Zertifikat erstellen und in Cloud Certificate Manager hochladen
Erstellen Sie ein Zertifikat zum Beenden des Arbeitslast-Traffics:
openssl req -x509 -newkey rsa:2048 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -subj '/CN=www.codelab-swp.com' -nodes -addext \ "subjectAltName = DNS:www.codelab-swp.com"
Laden Sie das Zertifikat in Cloud Certificate Manager hoch, damit das SWP in der Sicherheitsgateway-Richtlinie darauf verweisen kann.
gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem
11. SWP-Gateway erstellen
Erstellen Sie die YAML-Datei für das SWP-Gateway, um auf die vorherigen Informationen wie Zertifikat, Gateway-Sicherheitsrichtlinie, Netzwerk und Subnetz zu verweisen.
cat > /tmp/gateway.yaml << EOF
name: projects/${project_id}/locations/${region}/gateways/${prefix}-gateway
type: SECURE_WEB_GATEWAY
addresses: [10.10.10.50]
ports: [443]
certificateUrls: [projects/${project_id}/locations/${region}/certificates/${prefix}-cert]
gatewaySecurityPolicy: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
network: projects/${project_id}/global/networks/${prefix}-vpc
subnetwork: projects/${project_id}/regions/${region}/subnetworks/${prefix}-vpc-subnet
EOF
Erstellen Sie das Gateway:
gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}
Prüfen Sie, ob das Gateway erstellt wurde:
gcloud network-services gateways describe ${prefix}-swp --location ${region}
12. Compute-Instanzen erstellen
Da Cloud SWP ein expliziter Proxy ist, müssen wir die Proxy-IP für den Arbeitslasttraffic explizit angeben. Für den Client A der Compute-Instanz wird die Umgebungsvariable festgelegt. ClientB wird das nicht tun.
Erstellen Sie die Compute-Instanzen „ClientA“ und „ClientB“:
gcloud compute instances create clienta \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.10 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update sudo echo http_proxy=https://10.10.10.50:443/ >> /etc/environment sudo echo https_proxy=https://10.10.10.50:443/ >> /etc/environment '
gcloud compute instances create clientb \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.200 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update '
13. Sitzungsabgleich testen
Stellen Sie eine SSH-Verbindung zur Compute Engine-VM „clienta“ her, die Sie kürzlich erstellt haben. Auf dieser VM ist die Umgebungsvariable für die Verwendung von Cloud SWP festgelegt.
Über Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Führen Sie einige Webabfragen aus, um die Funktionalität zu prüfen. Wir benötigen „-proxy-insecure“, da wir für dieses Lab ein selbst signiertes Zertifikat erstellt haben:
curl https://google.com --proxy-insecure
Erwartete Ausgabe:
davidtu@clienta:~$ curl https://google.com --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
Wie Sie sehen, war die Anfrage erfolgreich. Da die Website zu https://www.google.com weiterleitet, ist eine 301-Weiterleitung zu erwarten.
Wenn Sie den folgenden Befehl ausführen, erhalten Sie ausführliche Protokolle mit Details zur Verbindung:
curl https://google.com --proxy-insecure -v
Einige Ausgaben werden hervorgehoben, um die Details der Proxyverbindung, Zertifikate und das Ziel zu zeigen.
davidtu@clienta:~$ curl https://google.com --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to google.com:443 > CONNECT google.com:443 HTTP/1.1 > Host: google.com:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 200 OK < date: Mon, 12 Dec 2022 19:22:04 GMT < * Proxy replied 200 to CONNECT request * CONNECT phase completed! ...
Sie können auch andere .com-Domains ausprobieren, um die Funktionalität zu testen.
Sehen wir uns nun einige andere Domains an, die nicht auf .com enden, um das standardmäßige Blockierungsverhalten zu überprüfen:
curl https://wikipedia.org --proxy-insecure
Erwartete Ausgabe:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Sehen Sie sich auch die ausführliche Ausgabelogging an und bestätigen Sie, dass Cloud SWP diesen Traffic blockiert:
curl https://wikipedia.org --proxy-insecure -v
davidtu@clienta:~$ curl https://wikipedia.org --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to wikipedia.org:443 > CONNECT wikipedia.org:443 HTTP/1.1 > Host: wikipedia.org:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 403 Forbidden < content-length: 13 < content-type: text/plain < date: Mon, 12 Dec 2022 19:35:09 GMT < connection: close < * Received HTTP code 403 from proxy after CONNECT * CONNECT phase completed! * Closing connection 0 curl: (56) Received HTTP code 403 from proxy after CONNECT
Sie können auch andere Domains ausprobieren, um das Verhalten zu überprüfen.
Beenden Sie die SSH-Sitzung zu „clienta“ und stellen Sie eine neue SSH-Verbindung zu „clientb“ her.
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Führen Sie einige curl-Befehle aus, um das Verhalten zu prüfen:
curl https://google.com
Das sollte wie erwartet funktionieren:
davidtu@clientb:~$ curl https://google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
Testen mit einer .org-Domain:
curl https://wikipedia.org
Das funktioniert wie erwartet, da clientb Cloud SWP nicht nutzt:
davidtu@clientb:~$ curl https://wikipedia.org <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.wikipedia.org/">here</a>.</p> </body></html>
Testen Sie das explizite Senden von Traffic über Cloud SWP:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Wir sehen, dass dieser Traffic über die Cloud SWP-Richtlinie abgelehnt wird:
davidtu@clientb:~$ curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure curl: (56) Received HTTP code 403 from proxy after CONNECT
Wie Sie bestätigt haben, wird Traffic, der Cloud SWP nutzt, anhand der konfigurierten Sicherheitsrichtlinie erzwungen. Traffic, der für .com bestimmt ist, ist zulässig. Alle anderen Ziele werden abgelehnt.
Beenden Sie clientb.
14. Regel der Gateway-Sicherheitsrichtlinie für ApplicationMatching aktualisieren
Wir aktualisieren die Regel, damit sie mit Details auf Anwendungsebene übereinstimmt. Wir erstellen eine Regel, die den Anfragepfad prüft und ihn nur zulässt, wenn er mit „index.html“ übereinstimmt.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
EOF
Jetzt können wir die aktualisierte Regel an die Gateway-Sicherheitsrichtlinie binden:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
15. ApplicationMatcher-Regel testen
Stellen Sie eine SSH-Verbindung zur Compute-VM „clienta“ her. Auf dieser VM ist die Umgebungsvariable für die Verwendung von Cloud SWP festgelegt.
Über Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Führen Sie einige Webabfragen aus, um die Funktionalität zu prüfen. Wir benötigen „-proxy-insecure“, da wir für dieses Lab ein selbst signiertes Zertifikat erstellt haben:
curl http://google.com --proxy-insecure
Beachten Sie, dass diese Abfrage fehlschlägt, obwohl sie zuvor erfolgreich war.
Access denied
Jeder Anfragepfad außer „index.html“ sollte mit einem 403-Fehler blockiert werden. Sie können das gern weiter testen.
Ändern Sie die Abfrage so, dass sie den Pfad „/index.html“ enthält.
curl http://google.com/index.html --proxy-insecure
Diese Anfrage sollte erfolgreich sein:
davidtu@clienta:~$ curl http://google.com/index.html --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
Wir erwarten eine 301-Weiterleitung, da die Website zu http://www.google.com/index.html weiterleitet.
Beachten Sie, dass es sich um eine HTTP-Anfrage handelt. Als Nächstes müssen Sie SWP aktivieren, damit die TLS-Prüfung möglich ist.
Führen Sie als Nächstes dieselbe Abfrage über TLS aus:
curl -k https://google.com/index.html --proxy-insecure
Erwartete Ausgabe:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Diese Anfrage sollte fehlschlagen, da SWP nicht für die TLS-Prüfung konfiguriert ist und den Pfad nicht anhand der ApplicationMatcher-Regel auswerten kann.
Beenden Sie Clenta.
16. TLS-Prüfung aktivieren
Ohne TLS-Prüfung wird „applicationMatcher“ nicht mit HTTPS-Traffic abgeglichen.
Mit „applicationMatcher“ kann nach Folgendem gefiltert werden:
- Zuordnung der Anfrageheader
- Anfragemethode
- Host für Anfragen
- Anfragepfad
- Abfrage der Anfrage
- Schema der Anfrage
- Vollständige Anfrage-URL
- User-Agent anfordern
Dienstkonto erstellen
Dieses Dienstkonto hat die Berechtigung, Zertifikate für die SWP-TLS-Prüfung zu generieren.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Prüfen, ob CAS aktiviert ist
gcloud services enable privateca.googleapis.com
CA-Pool erstellen
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
Stamm-CA erstellen
CA, die zum Signieren von Zertifikaten verwendet wird.
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
Datei für die Zertifikatsausstellungsrichtlinie erstellen
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
YAML-Datei für die TLS-Prüfung erstellen
cat > /tmp/tls-inspection-policy.yaml << EOF caPool: projects/$project_id/locations/$region/caPools/$prefix-ca-pool name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-inspection EOF
TLS-Prüfungsrichtlinie erstellen
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
CA-Pool aktualisieren, um die Zertifikatsausstellungsrichtlinie zu verwenden
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
Berechtigungen gewähren
So kann Ihr Dienstkonto den CA-Pool zum Generieren von Zertifikaten verwenden.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
YAML-Datei der Richtlinie aktualisieren, um die TLS-Prüfung einzuschließen
cat > /tmp/policy.yaml << EOF
description: some policy description
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
tlsInspectionPolicy: projects/${project_id}/locations/${region}/tlsInspectionPolicies/${prefix}-tls-inspection
EOF
Führen Sie den Befehl aus, um die aktualisierte Richtlinie anzuwenden.
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
Regeln aktualisieren, um die TLS-Prüfung einzubeziehen
Geben Sie als Nächstes an, für welche Regeln das Flag „enabtlsInspectionEnabled: true“ für die TLS-Prüfung gelten soll.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
tlsInspectionEnabled: true
EOF
Führen Sie den Befehl aus, um die aktualisierte Regel anzuwenden.
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
17. TLS-Prüfung testen
Stellen Sie eine SSH-Verbindung zur Compute-VM „clienta“ her. Auf dieser VM ist die Umgebungsvariable für die Verwendung von Cloud SWP festgelegt.
Über Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Führen Sie die vorherige Webabfrage aus, um zu prüfen, ob SWP die TLS-Prüfung durchführt, um den Pfad abzurufen.
curl -k https://google.com/index.html --proxy-insecure
Diesmal sollte es funktionieren, da SWP den ApplicationMatcher auswerten kann.
Erwartete Ausgabe:
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
Wir haben Cloud SWP erfolgreich eingerichtet, um TLS zu prüfen und die applicationMatcher-Logik zu bewerten.
Beenden Sie clienta.
18. Bereinigungsschritte
Entfernen Sie in Cloud Shell das SWP-Gateway, die Sicherheitsrichtlinie, die Zertifikate, die Instanzen, Cloud NAT und den Cloud Router:
gcloud -q network-services gateways delete ${prefix}-swp --location=${region}
gcloud -q network-security gateway-security-policies rules delete rule-com --location=${region} --gateway-security-policy=${prefix}-policy
gcloud -q network-security gateway-security-policies delete ${prefix}-policy --location=${region}
gcloud -q certificate-manager certificates delete ${prefix}-cert --location=${region}
gcloud -q network-security tls-inspection-policies delete $prefix-tls-inspection --location=$region
gcloud -q privateca roots disable $prefix-root-ca --pool=$prefix-ca-pool --location=$region
gcloud -q privateca roots delete $prefix-root-ca --pool=$prefix-ca-pool --location=$region --ignore-active-certificates --skip-grace-period
gcloud -q privateca pools delete $prefix-ca-pool --location=$region
gcloud -q compute instances delete clienta --zone=$zone
gcloud -q compute instances delete clientb --zone=$zone
gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region
gcloud -q compute routers delete `gcloud compute routers list --regions=$region --format="value(NAME)" | grep -e swg-autogen -e codelab-swp` --region=$region
Entfernen Sie die Subnetze, Firewallregeln und VPCs:
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks subnets delete $prefix-proxy-only-subnet \
--region=$region
gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy
gcloud -q compute networks delete $prefix-vpc
19. Glückwunsch!
Herzlichen Glückwunsch zum Abschluss des Codelabs. Sie haben Cloud Secure Web Proxy in Google Cloud erfolgreich konfiguriert und bereitgestellt.
Behandelte Themen
- Cloud SWP und die Vorteile