gem-netsec-cloud-armor

Ative o Google Cloud Shell

O Google Cloud Shell é uma máquina virtual com ferramentas de desenvolvimento. Ele conta com um diretório principal permanente de 5 GB e é executado no Google Cloud. O Google Cloud Shell permite acesso de linha de comando aos seus recursos do GCP.

1. No Console do GCP, na barra de ferramentas superior direita, clique no botão Abrir o Cloud Shell.

   

2. Clique em Continue (continuar):

   

Demora alguns minutos para provisionar e conectar-se ao ambiente. Quando você está conectado, você já está autenticado e o projeto é definido como seu PROJECT_ID . Por exemplo:

gcloud é a ferramenta de linha de comando do Google Cloud Platform. Ele vem pré-instalado no Cloud Shell e aceita preenchimento com tabulação.

É possível listar o nome da conta ativa com este comando:

gcloud auth list

Saída:

ACTIVE: *
ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net
To set the active account, run:
    $ gcloud config set account `ACCOUNT`
	

É possível listar o ID de projeto com este comando:

gcloud config list project
	

Saída:

[core]
project = <project_ID>
	

Exemplo de saída:

[core]
project = qwiklabs-gcp-44776a13dea667a6
	

Visão geral

Neste laboratório, você vai conhecer os recursos de bloqueio geográfico do Cloud Armor. Você vai criar uma política de segurança do Cloud Armor e implementar regras para negar e permitir o tráfego com base na localização geográfica para observar o comportamento do Cloud Armor. Este laboratório proporciona uma experiência prática com a proteção dos seus aplicativos do Google Cloud usando o Cloud Armor.

Tarefa 1: Preparação e configuração inicial

Nesta tarefa, você vai preparar o ambiente, incluindo a ativação das APIs necessárias e a criação de um serviço de back-end.

1. Defina o ID do projeto.

   gcloud config set project {{{ project_0.project_id | "PROJECT_ID" }}} Observação:
   esse comando define seu projeto ativo. Todos os comandos "gcloud" subsequentes serão executados neste projeto.

2. Defina sua região padrão como .

   gcloud config set compute/region {{{ project_0.default_region | "REGION" }}} Observação:
   esse comando define a região padrão de computação. Os recursos serão criados nessa região.

3. Defina sua zona padrão como .

   gcloud config set compute/zone {{{ project_0.default_zone | "ZONE" }}} Observação:
   esse comando define a zona de computação padrão. Os recursos serão criados nessa zona dentro da região especificada.

4. Ative as APIs necessárias.

   gcloud services enable compute.googleapis.com container.googleapis.com iap.googleapis.com Observação:
   esse comando ativa as APIs Compute Engine, Kubernetes Engine e Identity-Aware Proxy, que são necessárias para este laboratório.

Tarefa 2: Criar a rede VPC e a sub-rede

Crie uma rede VPC chamada test-vpc com as sub-redes test-subnet-us e test-subnet-eu. Essa VPC vai hospedar as instâncias usadas para teste.

1. Crie a rede VPC test-vpc.

   gcloud compute networks create test-vpc --subnet-mode=custom Observação:
   esse comando cria uma nova rede VPC com modo de sub-rede personalizado, oferecendo flexibilidade na definição de sub-redes.

2. Crie uma sub-rede test-subnet-us na rede test-vpc na região especificada. Use o intervalo de IP 10.10.10.0/24.

   gcloud compute networks subnets create test-subnet-us --network=test-vpc --region={{{ project_0.default_region | "REGION" }}} --range=10.10.10.0/24 Observação:
   esse comando cria uma sub-rede na rede VPC especificada com o intervalo de endereços IP "10.10.10.0/24".

3. Crie uma sub-rede test-subnet-eu na rede test-vpc na região europe-west1. Use o intervalo de IP 10.20.20.0/24.

   gcloud compute networks subnets create test-subnet-eu \ --network=test-vpc \ --region=europe-west1 \ --range=10.20.20.0/24 Observação:
   esse comando cria uma sub-rede na rede VPC especificada com o intervalo de endereços IP "10.20.20.0/24".

4. Adicione uma regra de firewall para o IAP.

   gcloud compute firewall-rules create allow-iap-ssh \ --direction=INGRESS \ --priority=1000 \ --network=test-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20 \ --target-tags=iap-gce Observação:
   esse comando cria uma regra de firewall para permitir o acesso do IAP a instâncias com a tag "iap-gce".

5. Crie uma regra de firewall para permitir o tráfego HTTP para o back-end.

   gcloud compute firewall-rules create allow-http \ --direction=INGRESS \ --priority=1500 \ --network=test-vpc \ --allow=tcp:80,tcp:443 \ --source-ranges=0.0.0.0/0 \ --target-tags=http-server,https-server Observação:
   esse comando cria uma regra de firewall que permite o tráfego HTTP e HTTPS de qualquer origem para instâncias com as tags "http-server" e "https-server".

Tarefa 3: Implementar um serviço de back-end com verificações de integridade

Nesta tarefa, você vai implementar verificações de integridade e criar um serviço de back-end.

1. Crie uma verificação de integridade.

   gcloud compute health-checks create http health-check-http \ --port=80 Observação:
   esse comando cria uma verificação de integridade HTTP na porta 80.

2. Crie um serviço de back-end.

   gcloud compute backend-services create backend-service \ --health-checks=health-check-http \ --global Observação:
   esse comando cria um serviço de back-end global usando a verificação de integridade criada na etapa anterior.

Tarefa 4: Criar o modelo de instância e o grupo gerenciado de instâncias

Primeiro, crie um modelo de instância, que é um projeto para suas VMs. Em seguida, use esse modelo para criar um grupo gerenciado de instâncias (MIG). O MIG vai gerenciar as VMs automaticamente, oferecendo recursos de recuperação e escalonamento automáticos.

1. Crie um modelo de instância.

   gcloud compute instance-templates create backend-template \ --machine-type=e2-medium \ --image-family=debian-11 \ --image-project=debian-cloud \ --subnet=test-subnet-us \ --tags=http-server,https-server,iap-gce \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install -y apache2 php libapache2-mod-php a2ensite default-ssl a2enmod ssl systemctl restart apache2 rm /var/www/html/index.html echo "

   String de consulta:

   " > /var/www/html/index.php systemctl restart apache2' Observação:
   esse comando cria um modelo de instância que define a configuração das VMs de back-end.

2. Crie um grupo gerenciado de instâncias.

   gcloud compute instance-groups managed create backend-mig \ --base-instance-name=backend-vm \ --size=2 \ --template=backend-template \ --zone={{{ project_0.default_zone | "ZONE" }}} Observação:
   esse comando cria um grupo gerenciado de instâncias (MIG) com um tamanho inicial de duas VMs.

3. Adicione o grupo gerenciado de instâncias ao serviço de back-end.

   gcloud compute backend-services add-backend backend-service \ --instance-group=backend-mig \ --instance-group-zone={{{ project_0.default_zone | "ZONE" }}} \ --global Observação:
   esse comando adiciona o grupo gerenciado de instâncias como um back-end ao "backend-service".

4. Crie uma verificação de integridade.

   gcloud compute health-checks create http http-health-check \ --request-path=/ Observação:
   esse comando cria uma verificação de integridade que envia solicitações para o caminho raiz ("/").

5. Aplique a verificação de integridade ao serviço de back-end.

   gcloud compute backend-services update backend-service \ --health-checks=http-health-check \ --global Observação:
   esse comando associa a verificação de integridade ao "backend-service".

Tarefa 5: Criar a configuração do front-end

A configuração do front-end é o que seus usuários vão usar para interagir. Isso envolve um mapa de URLs, um proxy, um endereço IP global e uma regra de encaminhamento.

1. Crie um mapa de URLs.

   gcloud compute url-maps create url-map \ --default-service=backend-service Observação:
   esse comando cria um mapa de URLs que roteia todo o tráfego para o "backend-service".

2. Crie um proxy HTTP global.

   gcloud compute target-http-proxies create http-proxy \ --url-map=url-map Observação:
   esse comando cria um proxy HTTP global usando o mapa de URLs criado na etapa anterior.

3. Crie um endereço IP estático global.

   gcloud compute addresses create global-ip-address --global Observação:
   esse comando cria um endereço IP estático acessível globalmente.

4. Crie uma regra de encaminhamento global.

   gcloud compute forwarding-rules create http-forwarding-rule \ --address=$(gcloud compute addresses describe global-ip-address \ --global --format='value(address)') \ --global \ --target-http-proxy=http-proxy \ --ports=80 Observação:
   esse comando cria uma regra de encaminhamento global para direcionar o tráfego ao proxy HTTP usando o endereço IP criado.

Tarefa 6: Implementar o bloqueio geográfico com o Cloud Armor

Agora você vai criar uma política de segurança do Cloud Armor e implementar uma regra para negar tráfego de uma região específica. As regras do Cloud Armor são processadas em ordem crescente de prioridade. Um número de prioridade menor significa que a regra é avaliada primeiro.

1. Crie uma política de segurança do Cloud Armor.

   gcloud compute security-policies create "geoblocking-policy" \ --description="Blocks traffic from specific countries" Observação:
   esse comando cria uma política de segurança do Cloud Armor chamada "geoblocking-policy".

2. Adicione uma regra para permitir o tráfego dos Estados Unidos (EUA).

   gcloud compute security-policies rules create 1000 \ --security-policy="geoblocking-policy" \ --description="Allow traffic from US" \ --expression="origin.region_code == 'US'" \ --action=allow Observação:
   esse comando cria uma regra que permite o tráfego dos Estados Unidos. Essa regra tem um número de prioridade alto (1000), então ela é avaliada depois das regras de negação. É uma prática recomendada permitir explicitamente o tráfego das regiões que você quer atender, mas para o bloqueio geográfico, isso não é estritamente necessário, a menos que você esteja implementando uma política de "negar tudo, permitir específico". A prioridade é essencial para a posição da regra na política.

3. Adicione uma regra para negar o tráfego da Bélgica (BE).

   gcloud compute security-policies rules create 10 \ --security-policy="geoblocking-policy" \ --description="Deny traffic from Belgium" \ --expression="origin.region_code == 'BE'" \ --action=deny-403 Observação:
   esse comando bloqueia o tráfego da Bélgica antes que as regras de permissão sejam consideradas. A ação "deny-403" retorna um erro HTTP 403 Forbidden. A expressão "origin.region_code" corresponde ao tráfego originário da Bélgica.

4. Anexe a política de segurança ao serviço de back-end.

   gcloud compute backend-services update backend-service \ --security-policy="geoblocking-policy" \ --global Observação:
   esse comando anexa a política de segurança ao serviço de back-end, aplicando as regras da política a todo o tráfego direcionado ao serviço de back-end.

Tarefa 7: Testar o bloqueio geográfico usando recursos regionais

Agora você vai testar a política de segurança do Cloud Armor para avaliar o bloqueio geográfico de vários locais.

1. Crie uma instância do Compute Engine chamada test-vm-us na test-subnet-us.

   gcloud compute instances create test-vm-us \ --subnet=test-subnet-us \ --machine-type=e2-medium \ --tags=iap-gce \ --zone={{{ project_0.default_zone | "ZONE" }}} Observação:
   esse comando cria uma instância do Compute Engine na sub-rede especificada.

2. Crie uma instância do Compute Engine chamada test-vm-europe na test-subnet-eu.

   gcloud compute instances create test-vm-europe \ --subnet=test-subnet-eu \ --machine-type=e2-medium \ --tags=iap-gce \ --zone=europe-west1-b Observação:
   esse comando cria uma instância do Compute Engine na sub-rede especificada.

3. Consiga o endereço IP do serviço de back-end.

   BACKEND_IP=$(gcloud compute addresses describe global-ip-address --global --format='value(address)') && echo $BACKEND_IP Observação:
   esse comando recupera o endereço IP associado ao serviço de back-end, que será usado para testar o bloqueio geográfico.

4. Nas etapas a seguir, você verá um comando SSH semelhante ao abaixo.

   Do you want to continue (Y/n)? Y Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Observação:
   a comunicação SSH inicial vai alertar você sobre uma nova conexão de host e perguntar se você quer inserir uma senha longa. Para este exercício do laboratório, não é necessário usar uma senha longa. Pressione a tecla Enter para confirmar.

5. Teste a regra de negação em uma instância do GCE nos EUA.

   gcloud compute ssh test-vm-us \ --zone={{{ project_0.default_zone | "ZONE" }}} \ --tunnel-through-iap \ --command "curl -v $BACKEND_IP" Observação:
   esse comando se conecta à instância dos EUA via SSH e usa "curl" para testar a política de bloqueio geográfico. Uma resposta 200 OK indica que a solicitação está sendo feita dos EUA.

   RESPOSTA ESPERADA

   GET / HTTP/1.1 Host: 34.144.245.10 User-Agent: curl/7.88.1 Accept: */* HTTP/1.1 200 OK Date: Wed, 06 Aug 2025 04:02:08 GMT Server: Apache/2.4.62 (Debian) Content-Length: 65 Content-Type: text/html; charset=UTF-8 Via: 1.1 google

6. Teste a regra de negação em uma instância do GCE na Europa.

   gcloud compute ssh test-vm-europe \ --zone=europe-west1-b \ --tunnel-through-iap \ --command "curl -v $BACKEND_IP" Observação:
   esse comando faz a conexão com a instância europeia via SSH e usa "curl" para testar a política de bloqueio geográfico. É esperado um erro 403 Forbidden.

   RESPOSTA ESPERADA

   GET / HTTP/1.1 Host: 34.144.245.10 User-Agent: curl/7.88.1 Accept: */* HTTP/1.1 403 Forbidden Content-Length: 134 Content-Type: text/html; charset=UTF-8 Date: Wed, 06 Aug 2025 04:02:36 GMT

Parabéns!

Você configurou o Cloud Armor para implementar o bloqueio geográfico. Você aprendeu a criar e aplicar políticas de segurança e a definir regras com base na origem geográfica. Este laboratório fornece uma base para proteger seus aplicativos do Google Cloud com o Cloud Armor.

Outros recursos

• Documentação do Cloud Armor
• Políticas de segurança do Cloud Armor

Manual atualizado em 6 de agosto de 2025

Laboratório testado em 6 de agosto de 2025