Codelab do Secure Web Proxy (SWP) do Cloud

1. Introdução

Proxy da Web seguro do Cloud

O Cloud SWP é um serviço que prioriza a nuvem e fornece um proxy da Web seguro para ajudar a proteger o tráfego da Web de saída (HTTP/S). Configure seus clientes para usar explicitamente o Cloud SWP como um proxy. As solicitações da Web podem ter origem nas seguintes fontes:

• Instâncias de máquina virtual (VM)
• Contêineres
• Um ambiente sem servidor que usa um conector sem servidor
• Cargas de trabalho no peering de VPC
• Workloads fora do Google Cloud conectados pelo Cloud VPN ou pelo Cloud Interconnect

O SWP na nuvem permite políticas flexíveis e granulares com base em identidades com priorização da nuvem e aplicativos da Web.

Vantagens

Confira abaixo alguns exemplos de benefícios que o SWP na nuvem pode oferecer a uma organização:

Migração para o Google Cloud

O Cloud SWP ajuda você a migrar para o Google Cloud enquanto mantém as políticas e os requisitos de segurança atuais para o tráfego de saída da Web. Você pode evitar o uso de soluções de terceiros que exigem outro console de gerenciamento ou a edição manual de arquivos de configuração.

Acesso a serviços da Web externos confiáveis

Com o SWP do Cloud, é possível aplicar políticas de acesso granulares ao tráfego da Web de saída para proteger sua rede. Você cria e identifica identidades de carga de trabalho ou aplicativo e aplica políticas.

Acesso monitorado a serviços da Web não confiáveis

Use o SWP do Cloud para fornecer acesso monitorado a serviços da Web não confiáveis. O SWP do Cloud identifica o tráfego que não está em conformidade com a política e o registra no Cloud Logging (Logging). Assim, você pode monitorar o uso da Internet, descobrir ameaças à sua rede e responder a elas.

Controles de política granulares para APIs do Google

É possível usar o SWP do Cloud para fornecer políticas granulares para as APIs do Google. Por exemplo, é possível definir políticas no nível do bucket/objeto usando a Common Expression Language (CEL).

Recursos compatíveis

O Cloud SWP é compatível com os seguintes recursos:

Serviço de proxy explícito

Os clientes precisam ser configurados explicitamente para usar o servidor proxy. O proxy do SWP do Cloud isola os clientes da Internet criando novas conexões TCP em nome deles.

Como fazer o escalonamento automático de proxies Envoy do Cloud SWP

Oferece suporte ao ajuste automático do tamanho do pool de proxy do Envoy e da capacidade do pool em uma região, o que permite um desempenho consistente durante períodos de alta demanda com o menor custo.

Políticas de acesso de saída modulares

O Cloud SWP é compatível com as seguintes políticas de saída:

• Identidade de origem baseada em tags seguras, contas de serviço ou endereços IP.
• Destinos com base em URLs e nomes de host.
• Solicitações baseadas em métodos, cabeçalhos ou URLs. Os URLs podem ser especificados usando listas, caracteres curinga ou padrões.
• Criptografia de ponta a ponta: os túneis cliente-proxy podem transitar por TLS. O Cloud SWP também aceita HTTP/S CONNECT para conexões TLS de ponta a ponta iniciadas pelo cliente com o servidor de destino.

Integração simplificada do Cloud NAT

O Cloud NAT provisiona automaticamente mais endereços IP públicos quando o conjunto de proxies que atendem ao tráfego do Cloud SWP aumenta.

Endereços IP públicos estáticos manuais também são uma opção para quem quer ter IPs de saída conhecidos.

Integração dos Registros de auditoria do Cloud e do pacote de operações do Google Cloud

Os Registros de Auditoria do Cloud e o pacote de operações do Google Cloud registram atividades administrativas e solicitações de acesso a recursos relacionados ao SWP do Cloud. Eles também registram métricas e registros de transações para solicitações processadas pelo proxy.

Inspeção de TLS

O Secure Web Proxy oferece um serviço de inspeção TLS que permite interceptar o tráfego TLS, inspecionar a solicitação criptografada e aplicar políticas de segurança.

• Integração completa com o Certificate Authority Service (CAS), um repositório altamente disponível e escalonável para CAs particulares.
• A capacidade de usar sua própria raiz de confiança, se necessário. Também é possível usar uma CA raiz para assinar ACs subordinadas mantidas por CAS. Se preferir, gere um novo certificado raiz no CAS.
• Critérios de descriptografia granular usando SessionMatcher e ApplicationMatcher nas regras de política do Secure Web Proxy. Isso inclui hosts correspondentes presentes em listas de URLs, expressões regulares, intervalos de endereços IP e expressões semelhantes. Se necessário, os critérios podem ser combinados com expressões booleanas.
• Cada política do Secure Web Proxy pode ser configurada com uma política de inspeção TLS e um pool de CAs próprios. Como alternativa, várias políticas do Secure Web Proxy podem compartilhar uma única política de inspeção TLS.

O que você vai aprender

• Como implantar e gerenciar o SWP da nuvem.

O que é necessário

• Conhecimento sobre como implantar instâncias e configurar componentes de rede
• Conhecimento sobre configuração de firewall da VPC

2. Ambiente de teste

Este codelab vai usar uma única VPC. Um recurso de computação nesse ambiente vai fazer o encaminhamento de saída usando o SWP do Cloud, conforme mostrado no diagrama abaixo.

Neste laboratório, vamos ter duas VMs de carga de trabalho.

O cliente A será configurado para enviar todas as solicitações HTTP/HTTPS ao SWP da nuvem.

O cliente B NÃO será configurado para enviar explicitamente solicitações HTTP/HTTPS ao SWP do Cloud, mas usará o Cloud NAT para tráfego vinculado à Internet.

Observação:o Cloud SWP é compatível com VPC compartilhada, cargas de trabalho em VPCs com peering e cargas de trabalho fora do Google Cloud conectadas pelo Cloud VPN ou Cloud Interconnect.

3. Antes de começar

O codelab exige um único projeto.

No Cloud Shell, verifique se o ID do projeto está configurado.

Observação: é possível conseguir o ID da organização usando o Console do Cloud ou gcloud projects get-ancestors [project-id].

Observação: se você já trabalhou com o GCP e tem o gcloud instalado, atualizado e autenticado no seu projeto, use seu computador local em vez do Google Cloud Shell neste laboratório. A menos que seja especificado, todos os comandos gcloud precisam ser executados em um computador que já tenha o gcloud instalado ou o Cloud Shell.

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-$[e-mail]"

4. Ativar APIs

Ativar as APIs para usar os produtos

gcloud services enable networksecurity.googleapis.com
gcloud services enable certificatemanager.googleapis.com
gcloud services enable networkservices.googleapis.com

5. Criar rede VPC, sub-rede e sub-rede somente proxy

Observação: verifique se a API Compute Engine está ativada. Se você receber uma mensagem de erro ao executar os comandos abaixo ou não tiver certeza, execute gcloud services enable compute.googleapis.com e tente de novo.

Rede VPC

Crie a VPC codelab-swp-vpc:

gcloud compute networks create $prefix-vpc --subnet-mode=custom 

Sub-rede

Crie as respectivas sub-redes na região selecionada:

gcloud compute networks subnets create $prefix-vpc-subnet \
   --range=10.10.10.0/24 --network=$prefix-vpc --region=$region

Sub-rede somente proxy

Crie uma sub-rede somente proxy na região selecionada:

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. Criar regras de firewall

Para permitir que o IAP se conecte às suas instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias de VM que você quer acessar usando o IAP.
• Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o encaminhamento de TCP.

No 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. Criar Cloud Router e Cloud NAT

Crie um Cloud Router para o Cloud NAT.

gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc

Crie um gateway do Cloud NAT para o cliente 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. Criar uma política de segurança de gateway

Crie um arquivo YAML com informações relevantes para a política:

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

Execute o comando gcloud para criar a política com base no arquivo YAML:

gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}

9. Criar uma regra de política de segurança do gateway

Crie um arquivo YAML que contenha as regras. Essas regras são representadas na Common Expression Language (CEL). Este laboratório usa uma regra simples que permite o tráfego para domínios .com e bloqueia todos os outros:

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

Agora podemos vincular a regra à política de segurança do gateway:

gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy

10. Criar um certificado e fazer upload dele para o Gerenciador de certificados do Cloud

Crie um certificado para encerrar o tráfego de carga de trabalho:

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"

Faça upload do certificado no Gerenciador de certificados do Cloud para que o SWP possa fazer referência a ele na política de gateway de segurança.

gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem

11. Criar o gateway SWP

Crie o arquivo YAML para o gateway SWP referenciar as informações anteriores, como certificado, política de segurança do gateway, rede e sub-rede.

Observação: o endereço é configurado manualmente neste arquivo YAML para 10.10.10.50. Esse é o endereço que o SWP vai usar, e todas as cargas de trabalho vão definir explicitamente o tráfego HTTP/HTTPS para esse endereço:

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

Crie o gateway:

gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}

Confirme se o gateway foi criado:

gcloud network-services gateways describe ${prefix}-swp --location ${region}

12. Criar instâncias de computação

Observação: por motivos de segurança, este codelab pressupõe que o Identity-Aware Proxy para encaminhamento de TCP está ativado para permitir o acesso SSH sem atribuir endereços IP públicos às instâncias. Configure antes de continuar.

Como o Cloud SWP é um proxy explícito, precisamos especificar explicitamente o IP do proxy para o tráfego da carga de trabalho. O clienteA da instância de computação terá a variável de ambiente definida. O ClientB não vai.

Crie as instâncias de computação ClientA e 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. Teste da correspondência de sessão

Use SSH para acessar a VM de computação "clienta" criada recentemente. Essa VM tem a variável de ambiente definida para usar o SWP do Cloud.

No Cloud Shell:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Execute algumas consultas na Web para validar a funcionalidade. Usamos "--proxy-insecure" porque criamos um certificado autoassinado para este laboratório:

curl https://google.com --proxy-insecure

Saída esperada:

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>

Como você pode ver, a solicitação foi "bem-sucedida". É esperado que um redirecionamento 301 seja exibido, já que o site está redirecionando para https://www.google.com.

Executar o comando a seguir fornece registros detalhados com detalhes sobre a conexão:

curl https://google.com --proxy-insecure -v

Destacando algumas saídas para mostrar os detalhes da conexão de proxy, os certificados e o destino.

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!
...

Tente outros domínios .com para verificar a funcionalidade.

Agora vamos testar outros domínios que não sejam .com para verificar o comportamento de bloqueio padrão:

curl https://wikipedia.org --proxy-insecure

Saída esperada:

curl: (56) Received HTTP code 403 from proxy after CONNECT

Da mesma forma, analise o registro detalhado de saída e confirme se o SWP do Cloud está bloqueando esse tráfego:

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

Você também pode testar outros domínios para verificar o comportamento.

Saia da sessão SSH para "clienta" e inicie uma nova conexão SSH para "clientb".

gcloud compute ssh clientb --zone=$zone --tunnel-through-iap

Execute alguns comandos curl para verificar o comportamento:

curl https://google.com

Isso deve funcionar como esperado na 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>

Como testar em um domínio da organização:

curl https://wikipedia.org

Isso funciona como esperado, já que o clientb não está usando o SWP do Cloud:

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>

Teste o envio de tráfego explicitamente pelo Cloud SWP:

curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure 

Notamos que esse tráfego é negado pela política de SWP da nuvem:

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

Como você verificou, o tráfego que usa o SWP do Cloud está sendo aplicado à política de segurança configurada. O tráfego destinado a .com é permitido, e todos os outros destinos são negados.

Saia do clientb.

14. Atualizar uma regra da política de segurança do gateway para ApplicationMatching

Vamos atualizar a regra para corresponder aos detalhes no nível do aplicativo. Vamos criar uma regra para analisar o caminho da solicitação e permitir apenas se ele corresponder a 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

Agora podemos vincular a regra atualizada à política de segurança do gateway:

gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy

15. Como testar a regra ApplicationMatcher

Conecte-se por SSH a uma VM de computação clienta. Essa VM tem a variável de ambiente definida para usar o SWP do Cloud.

No Cloud Shell:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Execute algumas consultas na Web para validar a funcionalidade. Usamos "--proxy-insecure" porque criamos um certificado autoassinado para este laboratório:

curl http://google.com --proxy-insecure

Essa consulta vai falhar quando tiver sido aprovada antes.

Access denied

Qualquer caminho de solicitação além de "index.html" deve ser bloqueado com um erro 403. Teste mais.

Modifique a consulta para incluir o caminho /index.html

curl http://google.com/index.html --proxy-insecure

Esta solicitação precisa ser bem-sucedida:

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>

É esperado que um redirecionamento 301 seja exibido, já que o site está redirecionando para http://www.google.com/index.html.

Observe que esta é uma solicitação HTTP. Em seguida, você precisa ativar o SWP para ter recursos de inspeção de TLS.

Em seguida, execute a mesma consulta, mas por TLS:

curl -k https://google.com/index.html --proxy-insecure

Saída esperada:

curl: (56) Received HTTP code 403 from proxy after CONNECT

Essa solicitação vai falhar porque o SWP não está configurado para inspecionar o TLS e não pode avaliar o caminho em relação à regra applicationMatcher.

Saia do clenta.

16. ativar inspeção TLS

Sem a inspeção TLS, o applicationMatcher não vai corresponder ao tráfego HTTPS.

O "applicationMatcher" permite filtrar o seguinte:

• Mapa de cabeçalhos de solicitação
• Método de solicitação
• Host de solicitação
• Caminho da solicitação
• Consulta de solicitação
• Scheme da solicitação
• URL completo da solicitação
• Solicitar useragent

Criar a conta de serviço

Essa conta de serviço terá permissões para gerar certificados para a inspeção TLS do SWP.

gcloud beta services identity create \
    --service=networksecurity.googleapis.com \
    --project=$project_id

Verificar se o CAS está ativado

gcloud services enable privateca.googleapis.com

Criar um pool de CA

gcloud privateca pools create $prefix-ca-pool \
    --tier=devops \
    --project=$project_id \
    --location=$region 

Criar CA raiz

CA usada para assinatura de certificado.

gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \
  --location=$region \
  --auto-enable \
  --subject="CN=my-swp-ca, O=SWP LLC"

Criar um arquivo de política de emissão de certificado

cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
  caOptions:
    isCa: false
  keyUsage:
    extendedKeyUsage:
      serverAuth: true
EOF

Criar arquivo YAML de inspeção de 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

Criar política de inspeção de TLS

gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
    --source=/tmp/tls-inspection-policy.yaml \
    --location=$region

Atualizar o pool de ACs para usar a política de emissão de certificados

gcloud privateca pools update $prefix-ca-pool    --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region

Conceder permissões

Isso permite que sua conta de serviço use o pool de ACs para gerar certificados.

gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
    --member=$member \
    --role='roles/privateca.certificateManager' \
    --location=$region

Atualizar o YAML da política para incluir a inspeção de 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

Execute o comando para aplicar a política atualizada.

gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}

Atualizar regras para incluir inspeção de TLS

Em seguida, especifique quais regras devem ter a flag "enabtlsInspectionEnabled: true" da inspeção TLS.

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

Execute o comando para aplicar a regra atualizada.

gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy

17. Testar a inspeção de TLS

Conecte-se por SSH a uma VM de computação clienta. Essa VM tem a variável de ambiente definida para usar o SWP do Cloud.

No Cloud Shell:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Execute a consulta da Web anterior para verificar se o SWP está realizando a inspeção TLS para recuperar o caminho.

curl -k https://google.com/index.html --proxy-insecure

Desta vez, ele vai funcionar porque o SWP pode avaliar o ApplicationMatcher.

Saída esperada:

<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>

Configuramos o Cloud SWP para inspecionar o TLS e avaliar a lógica do applicationMatcher.

Saia do clienta.

18. Etapas de limpeza

No Cloud Shell, remova o gateway do SWP, a política de segurança, os certificados, as instâncias, o Cloud NAT e o 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

Remova as sub-redes, as regras de firewall e as 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. Parabéns!

Parabéns por concluir o codelab. Você configurou e implantou o Secure Web Proxy no Google Cloud.

O que aprendemos

• Proxy da Web seguro do Cloud e os benefícios!