1. Introduction
Proxy Web sécurisé Cloud
Cloud SWP est un service cloud-first qui fournit un proxy Web sécurisé pour vous aider à sécuriser le trafic Web de sortie (HTTP/S). Configurez vos clients pour qu'ils utilisent explicitement Cloud SWP comme proxy. Les requêtes Web peuvent provenir des sources suivantes :
- Instances de machines virtuelles (VM)
- Conteneurs
- Un environnement sans serveur qui utilise un connecteur sans serveur
- Charges de travail sur l'appairage de VPC
- Charges de travail en dehors de Google Cloud connectées par Cloud VPN ou Cloud Interconnect
Cloud SWP permet de créer des stratégies flexibles et précises basées sur les identités cloud-first et les applications Web.
Avantages
Voici quelques exemples d'avantages que Cloud SWP peut offrir à une organisation :
Migration vers Google Cloud
Cloud SWP vous aide à migrer vers Google Cloud tout en conservant les règles et les exigences de sécurité existantes concernant le trafic Web sortant. Vous pouvez éviter d'utiliser des solutions tierces qui nécessitent une autre console de gestion ou la modification manuelle des fichiers de configuration.
Accès aux services Web externes de confiance
Le proxy Web sécurisé Cloud vous permet d'appliquer des règles précises de contrôle des accès à votre trafic Web de sortie afin de sécuriser votre réseau. Vous créez et identifiez des identités de charge de travail ou d'application, puis vous appliquez des règles.
Accès surveillé aux services Web non fiables
Vous pouvez utiliser Cloud SWP pour fournir un accès surveillé aux services Web non approuvés. Cloud SWP identifie le trafic non conforme aux règles et l'enregistre dans Cloud Logging (Logging). Vous pouvez ensuite surveiller l'utilisation d'Internet, détecter les menaces affectant votre réseau et y répondre.
Contrôles précis des règles pour les API Google
Vous pouvez utiliser Cloud SWP pour fournir des règles précises pour les API Google. Par exemple, vous pouvez définir des règles au niveau du bucket/de l'objet à l'aide du langage CEL (Common Expression Language).
Fonctionnalités disponibles
Cloud SWP est compatible avec les fonctionnalités suivantes :
Service proxy explicite
Les clients doivent être explicitement configurés pour utiliser le serveur proxy. Le proxy Cloud SWP isole les clients d'Internet en créant de nouvelles connexions TCP en leur nom.
Autoscaling des proxys Envoy Cloud SWP
Permet d'ajuster automatiquement la taille du pool de proxys Envoy et la capacité du pool dans une région, ce qui permet d'obtenir des performances constantes pendant les périodes de forte demande au moindre coût.
Règles d'accès de sortie modulaires
Cloud SWP est compatible avec les règles de sortie suivantes :
- Identité source basée sur des tags sécurisés, des comptes de service ou des adresses IP.
- Destinations basées sur des URL et des noms d'hôte.
- Requêtes basées sur des méthodes, des en-têtes ou des URL. Les URL peuvent être spécifiées à l'aide de listes, de caractères génériques ou de modèles.
- Chiffrement de bout en bout : les tunnels client-proxy peuvent transiter sur TLS. Cloud SWP est également compatible avec HTTP/S CONNECT pour les connexions TLS de bout en bout initiées par le client au serveur de destination.
Intégration simplifiée de Cloud NAT
Cloud NAT provisionne automatiquement des adresses IP publiques supplémentaires lorsque l'ensemble des proxys qui diffusent le trafic Cloud SWP augmente.
Il est également possible de définir manuellement des adresses IP publiques statiques pour ceux qui souhaitent disposer d'adresses IP de sortie connues.
Intégration de Cloud Audit Logs et de la suite Google Cloud Operations
Cloud Audit Logs et la suite Google Cloud Operations enregistrent les activités d'administration et les demandes d'accès pour les ressources liées à Cloud SWP. Ils enregistrent également les métriques et les journaux de transactions pour les requêtes traitées par le proxy.
Inspection TLS
Le proxy Web sécurisé propose un service d'inspection TLS qui vous permet d'intercepter le trafic TLS, d'inspecter les requêtes chiffrées et d'appliquer des règles de sécurité.
- Intégration étroite à Certificate Authority Service (CAS), qui est un dépôt hautement disponible et évolutif pour les autorités de certification privées.
- La possibilité d'utiliser votre propre racine de confiance si nécessaire. Vous pouvez également utiliser une autorité de certification racine existante pour signer les autorités de certification subordonnées détenues par CAS. Si vous préférez, vous pouvez générer un nouveau certificat racine dans CAS.
- Critères de déchiffrement précis à l'aide de SessionMatcher et ApplicationMatcher dans les règles de stratégie de proxy Web sécurisé. Ce critère inclut les hôtes correspondants présents dans les listes d'URL, les expressions régulières, les plages d'adresses IP et les expressions similaires. Si nécessaire, les critères peuvent être combinés avec des expressions booléennes.
- Chaque règle de proxy Web sécurisé peut être configurée avec sa propre règle d'inspection TLS et son propre pool d'autorités de certification. Vous pouvez également partager une même règle d'inspection TLS entre plusieurs règles de proxy Web sécurisé.
Points abordés
- Déployer et gérer Cloud SWP
Prérequis
- Connaissances sur le déploiement d'instances et la configuration de composants réseau
- Connaissances sur la configuration des pare-feu VPC
2. Environnement de test
Cet atelier de programmation utilisera un seul VPC. Une ressource de calcul dans cet environnement sortira à l'aide du Cloud SWP, comme indiqué dans le diagramme ci-dessous.
Dans cet atelier, nous aurons deux VM de charge de travail.
Le client A sera configuré pour envoyer toutes les requêtes HTTP/HTTPS au Cloud SWP.
Le client B ne sera pas configuré pour envoyer explicitement des requêtes HTTP/HTTPS au Cloud SWP, mais utilisera plutôt Cloud NAT pour le trafic destiné à Internet.
3. Avant de commencer
L'atelier de programmation nécessite un seul projet.
Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré.
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. Activer les API
Activer les API pour utiliser les produits
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. Créer un réseau VPC, un sous-réseau et un sous-réseau proxy réservé
Réseau VPC
Créez le VPC codelab-swp-vpc :
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Sous-réseau
Créez les sous-réseaux respectifs dans la région sélectionnée :
gcloud compute networks subnets create $prefix-vpc-subnet \ --range=10.10.10.0/24 --network=$prefix-vpc --region=$region
Sous-réseau proxy réservé
Créez un sous-réseau proxy réservé dans la région sélectionnée :
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. Créer des règles de pare-feu
Pour permettre à IAP de se connecter à vos instances de VM, créez une règle de pare-feu qui :
- S'applique à toutes les instances de VM auxquelles vous souhaitez être accessible à l'aide d'IAP.
- Autorise le trafic entrant à partir de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise pour le transfert TCP.
Depuis 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. Créer un routeur Cloud Router et Cloud NAT
Créez un routeur Cloud Router pour Cloud NAT.
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
Créez une passerelle Cloud NAT pour le 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. Créer une règle de sécurité de passerelle
Créez un fichier YAML contenant les informations pertinentes pour la règle :
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
Exécutez la commande gcloud pour créer la règle à partir du fichier YAML :
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. Créer une règle de stratégie de sécurité de passerelle
Créez un fichier YAML contenant les règles. Ces règles sont représentées en CEL (Common Expression Language). Cet atelier utilisera une règle simple qui autorisera le trafic vers les domaines .com et bloquera tous les autres :
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
Nous pouvons maintenant associer la règle à la stratégie de sécurité de la passerelle :
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
10. Créer un certificat et l'importer dans le gestionnaire de certificats Cloud
Créez un certificat pour mettre fin au trafic de charge de travail :
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"
Importez le certificat dans le gestionnaire de certificats Cloud afin que le SWP puisse y faire référence dans la règle de passerelle de sécurité.
gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem
11. Créer la passerelle SWP
Créez le fichier YAML pour la passerelle SWP afin de référencer les informations précédentes, telles que le certificat, la règle de sécurité de la passerelle, le réseau et le sous-réseau.
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
Créez la passerelle :
gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}
Vérifiez que la passerelle a été créée :
gcloud network-services gateways describe ${prefix}-swp --location ${region}
12. Créer des instances de calcul
Étant donné que Cloud SWP est un proxy explicite, nous devons spécifier explicitement l'adresse IP du proxy pour le trafic de charge de travail. La variable d'environnement sera définie sur le client A de l'instance de calcul. ClientB ne le fera pas.
Créez les instances de calcul ClientA et 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. Tester la mise en correspondance des sessions
Connectez-vous en SSH à la VM de calcul "clienta" récemment créée. Cette VM a la variable d'environnement définie pour utiliser Cloud SWP.
Depuis Cloud Shell :
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Exécutez quelques requêtes Web pour valider la fonctionnalité. Nous avons besoin de l'indicateur "--proxy-insecure" car nous avons créé un certificat autosigné pour cet atelier :
curl https://google.com --proxy-insecure
Résultat attendu :
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>
Comme vous pouvez le voir, la demande a été "acceptée". Nous nous attendons à voir une redirection 301, car le site Web redirige vers https://www.google.com.
L'exécution de la commande suivante fournit des journaux détaillés sur la connexion :
curl https://google.com --proxy-insecure -v
Voici quelques exemples de résultats pour afficher les détails de la connexion au proxy, les certificats et la destination.
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! ...
N'hésitez pas à essayer d'autres domaines .com pour vérifier le fonctionnement.
Essayons maintenant d'autres domaines non .com pour vérifier le comportement de blocage par défaut :
curl https://wikipedia.org --proxy-insecure
Résultat attendu :
curl: (56) Received HTTP code 403 from proxy after CONNECT
De même, examinez la journalisation détaillée des sorties et vérifiez que Cloud SWP bloque ce trafic :
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
N'hésitez pas à essayer d'autres domaines pour vérifier le comportement.
Quittez la session SSH vers "clienta" et établissez une nouvelle connexion SSH vers "clientb".
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Exécutez quelques commandes curl pour vérifier le comportement :
curl https://google.com
La VM clientb devrait fonctionner comme prévu :
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>
Tester sur un domaine .org :
curl https://wikipedia.org
Cela fonctionne comme prévu, car clientb n'utilise pas Cloud SWP :
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>
Testez l'envoi de trafic de manière explicite via Cloud SWP :
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Nous constatons que ce trafic est refusé par la règle Cloud SWP :
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
Comme vous l'avez vérifié, le trafic utilisant Cloud SWP est appliqué à la stratégie de sécurité configurée. Le trafic destiné à .com est autorisé, et toutes les autres destinations sont refusées.
Quittez clientb.
14. Mettre à jour une règle de stratégie de sécurité de passerelle pour ApplicationMatching
Modifions la règle pour qu'elle corresponde aux détails au niveau de l'application. Nous allons créer une règle pour examiner le chemin de la requête et l'autoriser uniquement s'il correspond à index.html.
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
Nous pouvons maintenant associer la règle mise à jour à la stratégie de sécurité de la passerelle :
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
15. Tester la règle ApplicationMatcher
Connectez-vous en SSH à une VM de calcul client. Cette VM a la variable d'environnement définie pour utiliser Cloud SWP.
Depuis Cloud Shell :
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Exécutez quelques requêtes Web pour valider la fonctionnalité. Nous avons besoin de l'indicateur "--proxy-insecure" car nous avons créé un certificat autosigné pour cet atelier :
curl http://google.com --proxy-insecure
Notez que cette requête échouera alors qu'elle fonctionnait auparavant.
Access denied
Tout chemin d'accès à une requête autre que "index.html" doit être bloqué avec un code 403. N'hésitez pas à tester davantage cette fonctionnalité.
Modifiez la requête pour inclure le chemin d'accès /index.html.
curl http://google.com/index.html --proxy-insecure
Cette requête devrait aboutir :
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>
Nous nous attendons à voir une redirection 301, car le site Web redirige vers http://www.google.com/index.html.
Notez qu'il s'agit d'une requête HTTP. Vous devrez ensuite activer SWP pour bénéficier des fonctionnalités d'inspection TLS.
Exécutez ensuite la même requête, mais sur TLS :
curl -k https://google.com/index.html --proxy-insecure
Résultat attendu :
curl: (56) Received HTTP code 403 from proxy after CONNECT
Cette requête devrait échouer, car SWP n'est pas configuré pour inspecter le protocole TLS et ne peut pas évaluer le chemin par rapport à la règle applicationMatcher.
Quittez clenta.
16. Activer l'inspection TLS
Sans inspection TLS, applicationMatcher ne correspondra pas au trafic HTTPS.
"applicationMatcher" permet de filtrer les éléments suivants :
- Carte des en-têtes de requête
- Mode de requête
- Demander à devenir hôte
- Chemin de requête
- Requête
- Schéma de la requête
- URL complète de la demande
- Demander l'user-agent
Créer un compte de service
Ce compte de service sera autorisé à générer des certificats pour l'inspection TLS SWP.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Vérifier que CAS est activé
gcloud services enable privateca.googleapis.com
Créer un pool d'autorités de certification
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
Créer une autorité de certification racine
Autorité de certification utilisée pour la signature des certificats.
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
Créer un fichier de règles d'émission de certificats
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
Créer un fichier YAML d'inspection TLS
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
Créer une règle d'inspection TLS
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
Mettre à jour le pool d'autorités de certification pour utiliser la règle d'émission de certificat
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
Octroyer des autorisations
Cela permet à votre compte de service d'utiliser le pool d'autorités de certification pour générer des certificats.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
Mettre à jour le fichier YAML de la règle pour inclure l'inspection TLS
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
Exécutez la commande pour appliquer la règle mise à jour.
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
Mettre à jour les règles pour inclure l'inspection TLS
Ensuite, spécifiez les règles pour lesquelles l'inspection TLS doit être activée à l'aide de l'indicateur "enabtlsInspectionEnabled: true".
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
Exécutez la commande pour appliquer la règle modifiée.
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
17. Tester l'inspection TLS
Connectez-vous en SSH à une VM de calcul client. Cette VM a la variable d'environnement définie pour utiliser Cloud SWP.
Depuis Cloud Shell :
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Exécutez la requête Web précédente pour vérifier si SWP effectue une inspection TLS afin de récupérer le chemin d'accès.
curl -k https://google.com/index.html --proxy-insecure
Cette fois, l'opération devrait aboutir, car SWP peut évaluer ApplicationMatcher.
Résultat attendu :
<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>
Nous avons correctement configuré Cloud SWP pour inspecter le protocole TLS et évaluer la logique applicationMatcher.
Quittez clienta.
18. Étapes de nettoyage
Dans Cloud Shell, supprimez la passerelle SWP, la règle de sécurité, les certificats, les instances, Cloud NAT et 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
Supprimez les sous-réseaux, les règles de pare-feu et les VPC :
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. Félicitations !
Bravo ! Vous avez terminé cet atelier de programmation. Vous avez configuré et déployé Cloud Secure Web Proxy sur Google Cloud.
Points abordés
- Proxy Web sécurisé Cloud et ses avantages