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). Vous configurez vos clients pour utiliser explicitement Cloud SWP en tant que proxy. Les requêtes Web peuvent provenir des sources suivantes:
- Instances de machines virtuelles (VM)
- Conteneurs
- Environnement sans serveur utilisant 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 d'élaborer des règles flexibles et précises basées sur des identités et des applications Web cloud-first.
Avantages
Vous trouverez ci-dessous quelques exemples d'avantages que Cloud SWP peut offrir à une entreprise:
Migration vers Google Cloud
Cloud SWP vous aide à migrer vers Google Cloud tout en conservant vos règles de sécurité et vos exigences existantes pour le trafic Web de sortie. Vous pouvez éviter d'utiliser des solutions tierces qui nécessitent une autre console de gestion ou de modifier manuellement les fichiers de configuration.
Accès à des services Web externes de confiance
Cloud SWP vous permet d'appliquer des règles d'accès précises à votre trafic Web de sortie afin de sécuriser votre réseau. Vous créez et identifiez des identités d'application ou de charge de travail, puis vous appliquez des règles.
Accès surveillé aux services Web non approuvés
Vous pouvez utiliser Cloud SWP pour fournir un accès surveillé à des services Web non approuvés. Cloud SWP identifie le trafic non conforme à la stratégie et le consigne dans Cloud Logging (Logging). Vous pouvez ainsi surveiller l'utilisation d'Internet, détecter les menaces qui pèsent sur votre réseau et réagir en conséquence.
Contrôles précis des règles pour les API Google
Vous pouvez utiliser Cloud SWP afin de fournir des règles précises pour les API Google. Par exemple, vous pouvez définir des stratégies au niveau du bucket ou 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 des connexions TCP pour le compte du client.
Autoscaling des proxys Cloud SWP Envoy
Accepte l'ajustement automatique de la taille et de la capacité du pool de proxy Envoy dans une région, ce qui permet de bénéficier de performances constantes lors des périodes de forte demande pour un coût minimal.
Règles d'accès de sortie modulaires
Cloud SWP est spécifiquement compatible avec les règles de sortie suivantes:
- Identité de la 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 par TLS. Cloud SWP est également compatible avec HTTP/S CONNECT pour les connexions TLS de bout en bout déclenchées par le client vers le serveur de destination.
Intégration simplifiée de Cloud NAT
Cloud NAT provisionne automatiquement des adresses IP publiques supplémentaires lorsque l'ensemble de proxys qui diffusent le trafic Cloud SWP augmente.
Vous pouvez également utiliser des adresses IP publiques statiques manuelles si vous souhaitez 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 associées à Cloud SWP. Ils enregistrent également des métriques et des journaux de transactions pour les requêtes traitées par le proxy.
Inspection TLS
Le proxy Web sécurisé offre un service d'inspection TLS qui vous permet d'intercepter le trafic TLS, d'inspecter la requête chiffrée et d'appliquer des règles de sécurité.
- Une intégration étroite avec Certificate Authority Service (CAS), un dépôt hautement disponible et évolutif pour les autorités de certification privées.
- Possibilité d'utiliser votre propre racine de confiance si nécessaire. Vous pouvez également utiliser une autorité de certification racine existante pour signer des autorités de certification subordonnées détenues par des autorités de certification. Si vous le souhaitez, vous pouvez générer un nouveau certificat racine dans les autorités de certification.
- Critères de déchiffrement précis à l'aide de SessionMatcher et ApplicationMatcher dans les règles de stratégie du proxy Web sécurisé. Ces critères incluent 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. Plusieurs règles de proxy Web sécurisé peuvent également partager une même règle d'inspection TLS.
Points abordés
- Découvrez comment déployer et gérer Cloud SWP.
Prérequis
- Vous disposez des connaissances nécessaires sur le déploiement d'instances et la configuration des composants réseau.
- Connaissances de la configuration d'un 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 de Cloud SWP, comme illustré dans le schéma ci-dessous.
Dans cet atelier, nous avons 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 à Cloud SWP. Il utilisera plutôt Cloud NAT pour le trafic 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 autoriser IAP à 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 rendre accessibles à l'aide d'IAP.
- Autorise le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP utilisées par IAP 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éer 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 dans le langage CEL (Common Expression Language). Dans cet atelier, vous allez utiliser 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 lier 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 interrompre le trafic des charges 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 le référencer dans la stratégie 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 Compute
Étant donné que Cloud SWP est un proxy explicite, nous devons spécifier explicitement l'adresse IP du proxy pour le trafic des charges de travail. La variable d'environnement sera définie pour le clientA de l'instance Compute. ClientB ne fonctionne 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
Se connecter en SSH à "clienta" Compute Engine récemment créée. La variable d'environnement de cette VM est définie pour utiliser Cloud SWP.
Depuis Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Exécuter des requêtes Web pour valider le fonctionnement L'utilisation d'un proxy non sécurisé est obligatoire, 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 constater, la requête a abouti. Il est normal que nous voyions 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 contenant des détails sur la connexion:
curl https://google.com --proxy-insecure -v
Mise en surbrillance de certaines sorties pour montrer 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 en vérifier le bon fonctionnement.
Essayons maintenant avec d'autres domaines autres que .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 et confirmez 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 en vérifier le comportement.
Quittez la session SSH pour "clienta". et établir une nouvelle connexion SSH à « clientb ».
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Exécutez des commandes curl pour vérifier le comportement:
curl https://google.com
Cela devrait fonctionner comme prévu sur la VM clientb:
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 par rapport à un domaine d'organisation:
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 explicite de trafic via Cloud SWP:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Nous constatons que ce trafic est refusé via 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 exploitant Cloud SWP est appliqué à la règle de sécurité configurée. Le trafic destiné à .com est autorisé, et toutes les autres destinations sont refusées.
Quittez le clientb.
14. Mettre à jour une règle de stratégie de sécurité de la passerelle pour ApplicationMatching
Mettons à jour 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 lier 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. Test de la règle ApplicationMatcher
Connectez-vous en SSH à la VM de calcul cliente. La variable d'environnement de cette VM est définie pour utiliser Cloud SWP.
Depuis Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Exécuter des requêtes Web pour valider le fonctionnement L'utilisation d'un proxy non sécurisé est obligatoire, car nous avons créé un certificat autosigné pour cet atelier:
curl http://google.com --proxy-insecure
Notez que cette requête échouera lorsqu'elle aura précédemment été transmise.
Access denied
Tout chemin de requête autre que "index.html" devrait être bloqué par une erreur 403. N'hésitez pas à tester cela de plus près.
Modifier la requête pour inclure le chemin d'accès /index.html
curl http://google.com/index.html --proxy-insecure
Cette demande doit être traitée:
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>
Il est normal qu'une redirection 301 s'affiche, car le site Web redirige l'utilisateur vers l'adresse http://www.google.com/index.html.
Notez qu'il s'agit d'une requête HTTP. Ensuite, vous devrez activer SWP pour disposer de fonctionnalités d'inspection TLS.
Exécutez ensuite la même requête, mais via 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 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 peut pas établir de correspondance avec le trafic HTTPS.
"applicationMatcher" permet de filtrer les éléments suivants:
- Mappage des en-têtes de requête
- Méthode de la requête
- Demander l'hôte
- Chemin de requête
- Requête de requête
- Schéma de requête
- URL de requête complète
- User-agent de requête
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
Assurez-vous 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 du certificat.
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 stratégie 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 stratégie d'émission de certificats
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 des règles 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 "Appliquer la stratégie 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
Spécifiez ensuite les règles pour lesquelles l'inspection TLS doit être définie sur "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 mise à jour
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 à la VM de calcul cliente. La variable d'environnement de cette VM est 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 pour récupérer le chemin d'accès
curl -k https://google.com/index.html --proxy-insecure
Cette fois-ci, l'opération devrait fonctionner, 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 terminé la configuration de Cloud SWP pour inspecter TLS et évaluer la logique applicationMatcher.
Quittez le clienta.
18. Étapes de nettoyage
Dans Cloud Shell, supprimez la passerelle SWP, la stratégie 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 micrologiciel 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 terminé de configurer et de déployer le proxy Web sécurisé Cloud sur Google Cloud.
Points abordés
- Cloud SWP et ses avantages