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 proxy. As solicitações da Web podem ser originadas das seguintes fontes:
- Instâncias de máquina virtual (VM)
- Contêineres
- Ambiente sem servidor que usa um conector sem servidor
- Cargas de trabalho em peering de VPC
- Cargas de trabalho fora do Google Cloud conectadas pelo Cloud VPN ou pelo Cloud Interconnect
O Cloud SWP 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 do Cloud oferece a uma organização:
Migração para o Google Cloud
O Cloud SWP ajuda você a migrar para o Google Cloud, mantendo suas políticas e 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 exijam outro console de gerenciamento ou a edição manual dos arquivos de configuração.
Acesso a serviços da Web externos confiáveis
O Cloud SWP permite aplicar políticas de acesso granulares ao tráfego de saída da Web para proteger sua rede. Você cria e identifica identidades de cargas de trabalho ou aplicativos e aplica políticas.
Acesso monitorado a serviços da Web não confiáveis
É possível usar o Cloud SWP para fornecer acesso monitorado a serviços da Web não confiáveis. O Cloud SWP identifica o tráfego que não está em conformidade com a política e o registra no Cloud Logging (Logging). É possível monitorar o uso da Internet, descobrir ameaças à sua rede e responder a ameaças.
Controles de políticas granulares para APIs do Google
É possível usar o Cloud SWP para fornecer políticas granulares para 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 SWP do Cloud oferece suporte aos seguintes recursos:
Serviço de proxy explícito
Os clientes precisam ser explicitamente configurados para usar o servidor proxy. O proxy do Cloud SWP isola os clientes da Internet criando novas conexões TCP em nome deles.
Escalonamento automático de proxies Envoy do Cloud SWP
Oferece suporte ao ajuste automático do tamanho do pool de proxy Envoy e da capacidade do pool em uma região, o que permite um desempenho consistente durante períodos de grande demanda pelo menor custo.
Políticas de acesso de saída modulares
O Cloud SWP é compatível especificamente 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 com base 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 proxy de cliente 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 com o Cloud NAT
O Cloud NAT provisiona automaticamente endereços IP públicos adicionais quando o conjunto de proxies que atendem ao tráfego do SWP do Cloud 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 gravam 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 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 perfeita com o Certificate Authority Service (CAS), que é 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 já existente para assinar as CAs subordinadas mantidas pelo CAS. Se preferir, você pode gerar um novo certificado raiz no CAS.
- Critérios de descriptografia granulares usando o SessionMatcher e o ApplicationMatcher nas regras da política do Secure Web Proxy. Esse critério 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 AC 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 do Cloud.
O que é necessário
- Saber implantar instâncias e configurar componentes de rede.
- Conhecimento de configuração de firewall de VPC
2. Ambiente de teste
Este codelab usará uma única VPC. Um recurso de computação neste ambiente sai usando o SWP do Cloud, como mostra o 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 do Cloud.
O Cliente B NÃO será configurado para enviar solicitações HTTP/HTTPS explicitamente ao SWP do Cloud, mas usará o Cloud NAT para tráfego vinculado à Internet.
3. Antes de começar
O codelab requer um único projeto.
No Cloud Shell, verifique se o ID do projeto está configurado
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. Ativar APIs
Ative 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 uma rede VPC, uma sub-rede e uma sub-rede somente proxy
Rede VPC
Crie a codelab-swp-vpc 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 instâncias de VM, crie uma regra de firewall que:
- Aplica-se a todas as instâncias de VM que você quer disponibilizar usando o IAP.
- Permite tráfego de entrada no intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para encaminhamento de TCP.
No cloudshell:
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
Criar Cloud Router para Cloud NAT.
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
Crie o gateway NAT do Cloud 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 as 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 de gateway
Crie um arquivo yaml que contenha as regras. Essas regras são representadas no Common Expression Language (CEL). Este laboratório usará 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. Crie um certificado e faça o upload no Gerenciador de certificados do Cloud
Crie um certificado para encerrar o tráfego da 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 o upload do certificado no gerenciador de certificados do Cloud para que o SWP possa referenciá-lo na política do 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. Crie o gateway do SWP
Crie o arquivo yaml do gateway SWP para fazer referência às informações anteriores, como certificado, política de segurança do gateway, rede e sub-rede.
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 do Compute
Como o SWP do Cloud é um proxy explícito, precisamos especificar explicitamente o IP do proxy para o tráfego da carga de trabalho. O clientA da instância do Compute terá a variável de ambiente definida. O ClienteB não fará isso.
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. Como testar a correspondência de sessão
Conectar-se via SSH ao "clienta" Compute VM criada recentemente. Esta VM tem a variável de ambiente definida para usar o Cloud SWP.
No cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Execute algumas consultas na Web para validar a funcionalidade. Exigimos –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". Um redirecionamento 301 é esperado, já que o site está redirecionando para https://www.google.com.
A execução do comando a seguir forneceria registros detalhados com detalhes sobre a conexão:
curl https://google.com --proxy-insecure -v
Destaque de 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! ...
Fique à vontade para testar outros domínios .com e verificar a funcionalidade.
Agora vamos testar outros domínios que não são .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, observe 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
Fique à vontade para testar outros domínios também para verificar o comportamento.
Saia da sessão SSH para "clienta". e inicie uma nova conexão SSH com "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 a VM clientb esperada:
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>
Teste em um domínio organizacional:
curl https://wikipedia.org
Isso funciona como esperado, já que o clientb não está utilizando o 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>
Teste o envio do tráfego explicitamente pelo SWP do Cloud:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Vemos que esse tráfego é negado pela política do SWP do Cloud:
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 em relação à política de segurança configurada. O tráfego destinado a .com é permitido e todos os outros destinos são negados.
Saia de clientb.
14. Atualizar uma regra de política de segurança de gateway para ApplicationMatching
Vamos atualizar a regra para corresponder aos detalhes no nível do aplicativo. Criaremos uma regra para examinar o caminho da solicitação e permitir somente 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
Estabeleça uma conexão SSH com a VM do Compute cliente. Esta VM tem a variável de ambiente definida para usar o Cloud SWP.
No cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Execute algumas consultas na Web para validar a funcionalidade. Exigimos –proxy-insecure porque criamos um certificado autoassinado para este laboratório:
curl http://google.com --proxy-insecure
Observe que essa consulta vai falhar quando for transmitida anteriormente.
Access denied
Qualquer caminho de solicitação além de "index.html" será bloqueado com um erro 403. Fique à vontade para fazer mais testes.
Modifique a consulta para incluir o caminho /index.html
curl http://google.com/index.html --proxy-insecure
A 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>
Um redirecionamento 301 é esperado, já que o site está redirecionando para http://www.google.com/index.html.
Observe que esta é uma solicitação HTTP. Em seguida, ative o SWP para ter os recursos de inspeção 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 falhará, já que o SWP não está configurado para inspecionar TLS e não poderá avaliar o caminho em relação à regra applicationMatcher.
Saia de Clenta.
16. ativar inspeção TLS
Sem a inspeção TLS, o applicationMatcher não fará a correspondência com o tráfego HTTPS.
"applicationMatcher" permite filtrar o seguinte:
- Mapa de cabeçalhos de solicitação
- Método de solicitação
- Solicitar host
- Caminho da solicitação
- Solicitar consulta
- Esquema de solicitação
- URL completo da solicitação
- User agent de solicitação
Criar a conta de serviço
Esta 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
Verifique 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 certificados
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
Criar arquivo yaml de inspeção 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 AC 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 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 a inspeção TLS
Em seguida, especifique quais regras precisam ter inspeção TLS "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
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 inspeção TLS
Estabeleça uma conexão SSH com a VM do Compute cliente. Esta VM tem a variável de ambiente definida para usar o Cloud SWP.
No cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Execute a consulta na Web anterior para verificar se o SWP está executando a inspeção TLS para recuperar o caminho
curl -k https://google.com/index.html --proxy-insecure
Desta vez, ela deu certo, já que 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 cliente.
18. Etapas de limpeza
No Cloud Shell, remova o gateway 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, regras de FW e 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 corretamente o Cloud Secure Web Proxy no Google Cloud.
O que aprendemos
- O SWP do Cloud e os benefícios dele.