1. Einführung
Cloud Secure Web Proxy
Cloud SWP ist ein Cloud-First-Dienst, der einen sicheren Web-Proxy zum Schutz des ausgehenden Webtraffics (HTTP/S) bereitstellt. Sie konfigurieren Ihre Clients so, dass sie Cloud SWP explizit als Proxy verwenden. Die Webanfragen können aus den folgenden Quellen stammen:
- VM-Instanzen
- Container
- 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
Im Folgenden finden Sie einige Beispiele für Vorteile, die Cloud SWP einer Organisation bieten könnte:
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 vermeiden, Lösungen von Drittanbietern zu verwenden, die eine weitere Verwaltungskonsole erfordern oder Konfigurationsdateien manuell bearbeiten.
Zugriff auf vertrauenswürdige externe Webdienste
Mit Cloud SWP können Sie detaillierte Zugriffsrichtlinien auf Ihren ausgehenden Web-Traffic anwenden und so Ihr Netzwerk schützen. Sie erstellen und identifizieren Arbeitslast- oder Anwendungsidentitäten und wenden dann Richtlinien an.
Überwachter Zugriff auf nicht vertrauenswürdige Webdienste
Sie können Cloud SWP verwenden, um überwachten Zugriff auf nicht vertrauenswürdige Webdienste bereitzustellen. Cloud SWP identifiziert Traffic, der nicht der Richtlinie entspricht, und protokolliert ihn in Cloud Logging (Logging). So können Sie die Internetnutzung im Blick behalten, 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-/Objektebene mithilfe 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 neue TCP-Verbindungen für den Client erstellt.
Autoscaling von Cloud SWP-Envoy-Proxys
Unterstützt die automatische Anpassung der Envoy-Proxy-Poolgröße und der Poolkapazität in einer Region. Dadurch wird eine konsistente Leistung zu den geringsten Kosten in Zeiten hoher Nachfrage ermöglicht.
Modulare Richtlinien für ausgehenden Zugriff
Cloud SWP unterstützt speziell die folgenden Richtlinien für ausgehenden Traffic:
- Quellidentität, basierend auf sicheren Tags, Dienstkonten oder IP-Adressen.
- Ziele basierend auf URLs und Hostnamen.
- Anfragen, die auf Methoden, Headern oder URLs basieren. URLs können mithilfe von Listen, Platzhaltern oder Mustern 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 client-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 bereitstellen, zunimmt.
Manuelle statische öffentliche IP-Adressen sind auch eine Option für Nutzer, die bekannte ausgehende IP-Adressen benötigen.
Einbindung von Cloud-Audit-Logs und der Operations-Suite von Google Cloud
Mit Cloud-Audit-Logs und der Operations-Suite von Google Cloud werden Verwaltungsaktivitäten und Zugriffsanfragen für Cloud SWP-Ressourcen aufgezeichnet. Sie zeichnen auch Messwerte und Transaktionslogs für Anfragen auf, die vom Proxy verarbeitet werden.
TLS-Prüfung
Secure Web Proxy bietet einen TLS-Prüfungsdienst, mit dem Sie TLS-Traffic abfangen, die verschlüsselte Anfrage prüfen und Sicherheitsrichtlinien erzwingen können.
- Die enge Einbindung in den Certificate Authority Service (CAS) ist ein hochverfügbares und skalierbares Repository für private Zertifizierungsstellen.
- Die Möglichkeit, bei Bedarf Ihre eigene Root of Trust zu verwenden. Sie können auch eine vorhandene Stamm-CA zum Signieren für untergeordnete Zertifizierungsstellen verwenden, die einer Zertifizierungsstelle gehören. Wenn Sie möchten, können Sie in CAS ein neues Root-Zertifikat generieren.
- Detaillierte Entschlüsselungskriterien mithilfe von SessionMatcher und ApplicationMatcher in den Richtlinienregeln von Secure Web Proxy. Dazu 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 Zertifizierungsstellenpool konfiguriert werden. Alternativ können mehrere Secure Web Proxy-Richtlinien eine einzige TLS-Prüfungsrichtlinie gemeinsam nutzen.
Lerninhalte
- Cloud SWP bereitstellen und verwalten
Voraussetzungen
- Kenntnisse der Bereitstellung von Instanzen und der Konfiguration von Netzwerkkomponenten
- Kenntnisse zur Konfiguration von VPC-Firewalls
2. Testumgebung
In diesem Codelab wird eine einzelne VPC verwendet. Eine Rechenressource in dieser Umgebung wird über Cloud SWP ausgehende Daten senden, wie im folgenden Diagramm dargestellt.
In diesem Lab haben wir zwei Arbeitslast-VMs.
Client A wird so konfiguriert, dass alle HTTP-/HTTPS-Anfragen an Cloud SWP gesendet werden.
Client B wird NICHT so konfiguriert, dass HTTP-/HTTPS-Anfragen explizit an Cloud SWP gesendet werden. Stattdessen wird Cloud NAT für Traffic über das Internet verwendet.
3. Hinweis
Für 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 die VPC 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, müssen Sie eine Firewallregel erstellen, die:
- Gilt für alle VM-Instanzen, die mit 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.
In 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 erstellen und Cloud NAT
Erstellen Sie einen Cloud Router für Cloud NAT.
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, die die Regeln enthält. Diese Regeln werden in der Common Expression Language (CEL) dargestellt. In diesem Lab wird eine einfache Regel verwendet, die Traffic zu .com-Domains zulässt und alle anderen blockiert:
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 Sie 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, um Arbeitslast-Traffic zu beenden:
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 den Cloud-Zertifikatmanager hoch, damit der SWP in der Richtlinie des Sicherheitsgateways 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 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-Adresse für den Arbeitslasttraffic explizit angeben. Für die Compute-Instanz clientA wird die Umgebungsvariable festgelegt. ClientB nicht.
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
SSH-Verbindung zu „clienta“ herstellen kürzlich erstellte Compute-VM. Für diese VM ist die Umgebungsvariable auf die Verwendung von Cloud SWP festgelegt.
In Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Führen Sie einige Webabfragen aus, um die Funktionalität zu prüfen. Der Wert „-proxy-insecure“ ist erforderlich, 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>
Die Anfrage war „erfolgreich“. Es ist zu erwarten, dass eine 301-Weiterleitung angezeigt wird, da die Website zu https://www.google.com weiterleitet.
Wenn Sie den folgenden Befehl ausführen, erhalten Sie ausführliche Logs mit Details zur Verbindung:
curl https://google.com --proxy-insecure -v
Einige Ausgaben werden hervorgehoben, um die Details der Proxy-Verbindung, die Zertifikate und das Ziel anzuzeigen.
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 gerne auch andere .com-Domains ausprobieren, um die Funktionalität zu überprüfen.
Probieren wir nun einige andere Domains ohne .com aus, um das standardmäßige Blockierverhalten zu überprüfen:
curl https://wikipedia.org --proxy-insecure
Erwartete Ausgabe:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Sehen Sie sich das ausführliche Ausgabe-Logging an und vergewissern Sie sich, 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.
SSH-Sitzung für „clienta“ beenden und eine neue SSH-Verbindung zu "clientb" herstellen.
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
Dies 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>
Test mit einer Organisationsdomain:
curl https://wikipedia.org
Das funktioniert wie erwartet, da das Client 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, ob Traffic explizit über Cloud SWP gesendet wird:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Wir sehen, dass dieser Traffic von der 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 überprüft haben, wird Traffic, der Cloud SWP nutzt, anhand der konfigurierten Sicherheitsrichtlinie erzwungen. An „.com“ gerichteter Traffic ist zulässig und alle anderen Ziele werden abgelehnt.
Beenden Sie Clientb.
14. Regel der Gateway-Sicherheitsrichtlinie für ApplicationMatching aktualisieren
Wir aktualisieren die Regel, um sie mit den Details auf Anwendungsebene abzugleichen. 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 Sie 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 zu einer clientseitigen Compute-VM her. Für diese VM ist die Umgebungsvariable auf die Verwendung von Cloud SWP festgelegt.
In Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Führen Sie einige Webabfragen aus, um die Funktionalität zu prüfen. Der Wert „-proxy-insecure“ ist erforderlich, 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, wenn sie zuvor übergeben wurde.
Access denied
Beliebiger Anfragepfad außer „index.html“ sollte mit einem 403-Fehler blockiert werden. Sie können dies gerne 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>
Es wird erwartet, dass eine 301-Weiterleitung angezeigt wird, da die Website zu http://www.google.com/index.html weiterleitet.
Beachten Sie, dass dies eine HTTP-Anfrage ist. Als Nächstes müssen Sie SWP aktivieren, um die TLS-Prüfungsfunktionen zu nutzen.
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 Prüfung von TLS konfiguriert ist und der Pfad nicht anhand der „applicationMatcher“-Regel ausgewertet werden kann.
Schließen Sie Centa.
16. TLS-Prüfung aktivieren
Ohne TLS-Prüfung gleicht ApplicationMatcher keinen HTTPS-Traffic ab.
"applicationMatcher" ermöglicht das Filtern nach folgenden Elementen:
- Zuordnung von Anfrageheadern
- Anfragemethode
- Host der Anfrage
- Anfragepfad
- Anfrage stellen
- Anfrageschema
- Vollständige Anfrage-URL
- User-Agent anfordern
Dienstkonto erstellen
Dieses Dienstkonto ist berechtigt, Zertifikate für die SWP-TLS-Prüfung zu generieren.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Achten Sie darauf, dass 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
Root-Zertifizierungsstelle erstellen
Für die Zertifikatssignierung verwendete Zertifizierungsstelle.
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
Richtliniendatei für die Zertifikatsausstellung erstellen
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
YAML-Datei für 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 Richtlinie zur Zertifikatsausstellung zu verwenden
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
Berechtigungen gewähren
Dadurch 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
Richtlinien-YAML-Datei mit TLS-Prüfung aktualisieren
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 „Anwenden der aktualisierten Richtlinie“ aus
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
Regeln aktualisieren, um die TLS-Prüfung einzuschließen
Geben Sie als Nächstes an, für welche Regeln die TLS-Prüfung „enabtlsInspectionEnabled: true“ verwendet werden soll melden.
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 zu einer clientseitigen Compute-VM her. Für diese VM ist die Umgebungsvariable auf die Verwendung von Cloud SWP festgelegt.
In Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Führen Sie die vorherige Webabfrage aus, um zu prüfen, ob SWP eine TLS-Prüfung zum Abrufen des Pfads durchführt
curl -k https://google.com/index.html --proxy-insecure
Dieses Mal sollte er erfolgreich sein, 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, Zertifikate, Instanzen, Cloud NAT und 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, FW-Regeln 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 erfolgreich in Google Cloud konfiguriert und bereitgestellt.
Behandelte Themen
- Cloud SWP und die Vorteile