Google PCNE: Política de Firewall, Cloud Armor e Segurança de Rede — Guia de estudos

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Network Engineer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A política de firewall, o Cloud Armor e a segurança de rede no Google Cloud, juntos, fornecem controles em camadas para segmentação, redução da superfície de ataque, resiliência a DDoS e observabilidade. Designs eficazes combinam direcionamento com base em identidade, aplicação hierárquica, privilégio mínimo para tráfego de entrada (ingress) e saída (egress), e proteções de borda vinculadas aos balanceadores de carga globais do Google. O sucesso operacional depende do entendimento da avaliação de regras, comportamentos implícitos, escopo de logging e de onde o tráfego realmente se origina para diferentes modos de balanceamento de carga.

Regras de firewall da VPC e direcionamento com base em identidade

As regras de firewall da VPC são stateful e avaliadas por rede, direção e prioridade.

• Direção e regras implícitas:
  • O tráfego de entrada (ingress) é avaliado em relação ao tráfego que entra em uma NIC de VM; o de saída (egress), em relação ao tráfego que sai dela.
  • Existem duas regras implícitas em toda VPC: uma regra implícita de negação total (deny-all) para ingress e uma de permissão total (allow-all) para egress. Elas não podem ser modificadas e não geram logs. A rede padrão (default) também cria várias regras permissivas; VPCs personalizadas (custom) não.
• Prioridade e avaliação:
  • As prioridades variam de 0 a 65535, onde os números mais baixos são avaliados primeiro. A primeira regra correspondente determina totalmente a ação.
  • Se várias regras com a mesma prioridade corresponderem, o intervalo de IP mais específico prevalece; se a especificidade for igual e as ações conflitarem, a negação (deny) prevalece. Evite sobreposições com a mesma prioridade.
• Alvos (targets) e origens (sources):
  • Alvos definem a quais VMs a regra se aplica: tags de rede, contas de serviço (service accounts) de VM ou tags seguras (secure tags). Origens/destinos são CIDRs de IP; para ingress, você também pode especificar contas de serviço ou tags de origem para origens na mesma VPC.
  • Tags de rede são metadados de VM que podem ser definidos por usuários do projeto; são simples, mas menos controladas. Contas de serviço fornecem direcionamento com base em identidade vinculado à identidade da carga de trabalho e ao IAM, sendo mais difíceis de usar indevidamente. Tags seguras (tags do Resource Manager no nível da organização vinculadas via IAM) permitem que as equipes de segurança controlem quais VMs uma regra pode visar, sem permitir que os desenvolvedores autoatribuam tags que contornem a proteção; use-as para uma governança mais forte.
• Logging:
  • Habilite o logging de regras de firewall por regra para capturar conexões permitidas ou negadas que correspondem a essa regra. Negações implícitas não são registradas; se você precisar de logs de negação, adicione uma regra explícita de negação de alta prioridade com o logging ativado.
  • Os logs incluem a referência da regra, a ação, a 5-tupla, os bytes e podem ser exportados para análise forense.

Design e operações:

• Ingress de privilégio mínimo: Prefira a negação por padrão (deny-by-default) usando negações explícitas de alta prioridade e, em seguida, adicione permissões com escopo definido por conta de serviço ou tag segura. Para grupos de instâncias atrás de um balanceador de carga, permita tráfego apenas do balanceador de carga ou dos intervalos de verificação de integridade (health check) que realmente originam o tráfego.
• Egress de privilégio mínimo: Substitua a permissão implícita por uma regra explícita de negação total (deny-all) para egress de alta prioridade, mais permissões direcionadas (para intervalos de NAT, IPs de parceiros ou APIs do Google via Private Google Access). Tenha cuidado para não interromper os fluxos de retorno; a natureza stateful permite respostas a conexões permitidas sem regras extras.
• Direcionamento com base em identidade:
  • Use contas de serviço para uma política de “quem pode se comunicar”, independentemente da mobilidade de IPs.
  • Use tags seguras para impedir que desenvolvedores autoapliquem tags de rede permissivas.
• Armadilhas comuns e modos de falha:
  • Identidade de origem do balanceador de carga: Para balanceadores de carga HTTP(S) externos, os back-ends veem conexões dos proxies do Google Front End (GFE), não dos IPs dos clientes. Use o Cloud Armor para permitir/negar IPs de clientes; use o firewall da VPC para permitir os intervalos de egress do GFE e de verificação de integridade. Para Network Load Balancers TCP/UDP, os back-ends veem o IP do cliente; as listas de permissão (allowlists) de IPs de clientes no firewall se aplicam diretamente.
  • Falta de logs de negação: Negações de regras implícitas não são registradas. Adicione uma regra de negação explícita com o logging ativado para observar o tráfego bloqueado.
  • Bypass do NAT: Se uma VM tiver um IP externo, ela o usará para o tráfego de egress e contornará o Cloud NAT. Remova o IP externo para forçar o uso do NAT.
  • Diagnóstico de regra não correspondente: Confirme a direção, a identidade do alvo (tag/conta de serviço/tag segura), a prioridade e os filtros de origem. Se os logs não mostrarem correspondência, o tráfego não está atingindo a regra que você espera.

Exemplo curto, permissão de ingress com base em identidade e com logging:

• Alvo (target): conta de serviço (service account) sa: web-backend@project.iam.gserviceaccount.com
• Intervalos de origem (source): intervalos de proxy do GFE + verificações de integridade do Google
• Prioridade: 100
• Ação: permitir (allow) tcp:80,443
• Logging: ativado

Política de firewall hierárquica, segmentação e perímetros de serviço

As políticas de firewall hierárquicas impõem regras em toda a organização ou pasta antes de quaisquer regras no nível da VPC. Use-as para garantir barreiras de proteção (guardrails) (por exemplo, “negar toda a entrada da internet para VMs sem balanceamento de carga” ou “negar RDP/SSH de 0.0.0.0/0”). Regras de VPC de nível inferior não podem sobrepor uma negação (deny) de organização/pasta que já correspondeu.

Estratégia de segmentação:

• Segmentação de entrada (Ingress):
  • Política de organização/pasta: negações (denies) de alta prioridade para portas de risco e uma negação padrão, exceto para pontos de entrada autorizados. Permita os intervalos de verificação de integridade (health check) do Google onde for necessário.
  • Regras de VPC: permissões (allows) específicas da carga de trabalho, direcionadas por conta de serviço ou tag segura. Para serviços internos, use o Private Service Connect ou o balanceamento de carga interno para acesso leste-oeste (east-west) com regras restritas.
• Segmentação de saída (Egress):
  • Substitua a permissão de saída implícita (allow-all egress) por uma negação de saída total (deny-all egress) de alta prioridade no escopo da organização/pasta ou da VPC e, em seguida, abra apenas o que for necessário:
    • Saída para a internet via Cloud NAT ou firewalls de saída aprovados.
    • APIs do Google via Private Google Access e endpoints private.googleapis.com ou restricted.googleapis.com. O endpoint restrito funciona em conjunto com o VPC Service Controls para evitar a exfiltração de dados para identidades ou projetos não autorizados.
    • Para designs que direcionam 0.0.0.0/0 através de um firewall de terceiros, mas ainda exigem acesso direto às APIs do Google sem hairpinning, adicione rotas estáticas para os blocos VIP das APIs do Google para o gateway de internet padrão e habilite o Private Google Access nas sub-redes. Isso preserva os controles de segurança ao mesmo tempo que reduz a latência e a dependência do dispositivo de terceiros para serviços primários (first‑party).

Interações com perímetros de serviço:

• O VPC Service Controls define perímetros ao redor de projetos e APIs do Google compatíveis para mitigar a exfiltração de dados. Quando os perímetros estão habilitados:
  • Prefira restricted.googleapis.com para que as chamadas de API permaneçam dentro do contexto do perímetro.
  • Garanta que o DNS aponte os domínios relevantes para os endpoints restritos ou privados e que as rotas não façam backhaul para dispositivos de saída não confiáveis.
  • Combine a política de perímetro com listas de permissão (allowlists) do firewall de saída para evitar vazamentos acidentais para endpoints fora do perímetro.

Trade-offs:

• Negações no nível da organização simplificam o gerenciamento de riscos, mas podem bloquear experimentos legítimos se o controle de alterações for lento; delegue exceções usando tags seguras e fluxos de trabalho de solicitação documentados.
• Negações de saída agressivas reduzem o raio de impacto (blast radius), mas exigem descoberta de serviço robusta e controle de alterações para evitar interrupções.

Cloud Armor, WAF e proteções de borda globais

O Cloud Armor vincula políticas de segurança a load balancers externos de Proxy HTTP(S) e Proxy TCP/SSL para proteger na borda.

• Regras de WAF:
  • Use regras pré-configuradas para o OWASP Top 10 e CVEs comuns, e regras personalizadas usando uma linguagem de expressão para corresponder a cabeçalhos, IPs, países, URIs e muito mais.
  • Anexe por serviço de backend e ordene as regras por prioridade. As ações incluem permitir (allow), negar (deny) com respostas específicas ou redirecionar para HTTP(S).
• Limitação de taxa (Rate limiting):
  • Aplique cotas por chave (por exemplo, por IP do cliente, cabeçalho ou cookie) com janelas deslizantes e controles de burst. Banimentos baseados em taxa adicionam automaticamente negações temporárias para fontes abusivas.
• Proteção Adaptativa (Adaptive Protection):
  • A detecção de anomalias orientada por ML aprende os padrões normais de solicitação e identifica ataques de DDoS L7 ou abuso. Ele pode sugerir ou gerar automaticamente regras candidatas; implante-as primeiro no modo de pré-visualização (preview).
• Modo de pré-visualização (Preview):
  • Avalie novas regras sem impactar o tráfego. Os resultados da pré-visualização são registrados em log, permitindo ajustes de baixo risco. Mude para o modo de aplicação (enforced) após a verificação.

Defesa contra DDoS e controles de load balancer global:

• A borda anycast global do Google absorve ataques volumétricos L3/L4; validação SYN/ACK, tratamento de pacotes malformados e capacidade de borda com autoescalonamento são integrados à plataforma para Proxy HTTP(S) e TCP/SSL externos.
• Combine com o Cloud Armor para mitigar inundações L7 (floods), credential stuffing e abuso de aplicação.
• Aplique políticas de TLS, cifras modernas e, quando necessário, mTLS de cliente no load balancer. Para requisitos de IPv6, use um load balancer global externo de Proxy HTTP(S) ou TCP/SSL com VIPs IPv6.
• Para adicionar IPs de clientes específicos a uma lista de permissão (allowlisting) para uma aplicação com balanceamento de carga:
  • Se estiver usando HTTP(S), prefira as listas de permissão (allowlists) do Cloud Armor baseadas no IP do cliente e mantenha as regras de firewall do backend limitadas às fontes do GFE e de verificação de integridade (health check).
  • Se estiver usando um Network Load Balancer TCP/UDP, os backends veem o IP real do cliente; aplique as listas de permissão (allowlists) do firewall da VPC diretamente às instâncias de destino (por tag segura ou conta de serviço) e inclua os IPs de verificação de integridade do Google.

Cuidados operacionais:

• As regras são avaliadas na borda; listas de permissão (allowlists) incorretas podem causar interrupções globais instantaneamente. Use o modo de pré-visualização (preview) e implantações graduais (staged rollouts), e monitore os logs do Cloud Armor e as métricas do load balancer.
• As necessidades de afinidade de sessão variam: para protocolos mistos (por exemplo, HTTP e TFTP do mesmo cliente para o mesmo pool de backend), a afinidade por IP do cliente no load balancer preserva a persistência (stickiness) entre as portas.

Visibilidade, inspeção e resposta a incidentes

Observabilidade:

• Os VPC Flow Logs fornecem registros de fluxo de 5 tuplas amostrados por sub-rede com amostragem, enriquecimento de metadados e intervalos de agregação configuráveis. Use-os para criar uma linha de base de desempenho (baselining) e para detecção de anomalias.
• O registro de regras de firewall (firewall rule logging) captura as permissões (allows) e negações (denies) por conexão para as regras específicas com o registro ativado; crie regras de negação explícitas para registrar bloqueios que, de outra forma, seriam tratados por negações implícitas.
• Os logs de requisição e os resultados de pré-visualização (preview) do Cloud Armor mostram as correspondências de regras, as decisões de ação e os resultados da limitação de taxa (rate-limiting) na borda.

Inspeção e detecção:

• O Packet Mirroring copia o tráfego para um coletor na mesma região para inspeção profunda de pacotes (deep packet inspection) ou IDS. Limite o escopo do espelhamento por sub-rede, tag ou conta de serviço para reduzir a sobrecarga (overhead). O espelhamento de pacotes é fora da banda (out-of-band) e não bloqueia o tráfego; use-o com o Cloud IDS ou sensores de terceiros.
• A inspeção L7 em linha (inline) requer um padrão de appliance com 2 NICs e o roteamento do tráfego através dele. Projete para roteamento simétrico e alta disponibilidade (HA); considere os domínios de falha regionais e possíveis gargalos de throughput. Dispositivos em linha aumentam o raio de impacto (blast radius) em caso de falha; implante grupos de instâncias gerenciadas (managed instance groups) e padrões de failover de rota com verificação de integridade (health-checked) quando aplicável.

Práticas de resposta a incidentes:

• Centralize os logs em um projeto de segurança, crie detecções para picos repentinos de negações (deny spikes), criação de novas regras de alta prioridade ou acionadores de limite de taxa do Cloud Armor. Use o BigQuery ou integrações com SIEM para investigação.
• Garanta o princípio do menor privilégio (least-privilege) no IAM: o papel de Network Admin é insuficiente para modificar políticas de firewall em uma VPC Compartilhada (Shared VPC), onde o papel de Security Admin é necessário; segregue as funções entre as equipes de rede e de segurança.
• Quando precisar de acesso de emergência (break-glass) via SSH e as chaves não estiverem pré-provisionadas, use gcloud compute ssh a partir do Cloud Shell para enviar uma chave efêmera através dos metadados da instância, se permitido pelo IAM e pelas configurações de metadados da instância.
• Para solucionar cenários de “sem logs”: verifique a regra e a direção, lembre-se de que negações implícitas não geram logs e verifique as políticas hierárquicas que podem ter correspondido antes.

Cenário de Problema Prático

A Contoso Retail opera uma plataforma web de múltiplas camadas (multi-tier) no Google Cloud. O tráfego de frontend é atendido por um balanceador de carga HTTP(S) externo global; as VMs de aplicação rodam em várias regiões sem IPs externos. O tráfego de saída (egress) deve fazer um hairpin através de um NGFW de terceiros, exceto para as APIs do Google (BigQuery e Pub/Sub). A equipe de segurança deseja barreiras de proteção (guardrails) em toda a organização, listas de permissão de IP de cliente (allowlists) para um piloto com um parceiro e risco mínimo ao testar um cliente suspeito de ser malicioso.

Abordagem:

1. Estabelecer barreiras de proteção (guardrails) hierárquicas

   • Crie uma política de firewall hierárquica no nível da organização que negue todo o tráfego de entrada (ingress) de 0.0.0.0/0 para alvos de VM que não possuam a tag segura env=public-entry, e negue portas administrativas (SSH, RDP) vindas da internet.
   • Justificativa: Impede a exposição insegura globalmente; os desenvolvedores não podem autoatribuir a tag segura devido às permissões do IAM sobre as tags.

2. Direcionamento de workloads com base em identidade

   • Atribua contas de serviço (service accounts) distintas para as camadas de frontend, aplicação e banco de dados. Referencie essas contas de serviço em regras de firewall no nível da VPC para permitir apenas os fluxos leste-oeste (east-west) necessários (por exemplo, frontend→app tcp:443, app→db tcp:5432).
   • Justificativa: Vincula a política à identidade do workload e resiste ao uso indevido acidental de tags.

3. Permissões de entrada (ingress) para backends com balanceamento de carga

   • Nas VMs da aplicação, crie uma regra de permissão de entrada (ingress allow) de alta prioridade direcionada pela conta de serviço da aplicação, com os intervalos de origem (source ranges) iguais aos dos proxies do Google Front End e dos intervalos de verificação de integridade (health check) do Google; ative o registro de logs.
   • Justificativa: Para HTTP(S) L7, os backends devem aceitar apenas conexões dos IPs do GFE e das verificações de integridade; as listas de permissão de IP do cliente (client IP allowlists) são aplicadas na borda.

4. Política de borda do Cloud Armor

   • Anexe uma política do Cloud Armor ao serviço de backend do balanceador de carga HTTP(S) externo:
     • Adicione uma regra de lista de permissão (allowlist) para o IP do cliente parceiro.
     • Ative as regras de WAF pré-configuradas para o OWASP Top 10.
     • Configure um limite de taxa (rate limit) baseado no IP do cliente com limiares conservadores.
   • Justificativa: Aplica restrições de origem do cliente e proteções na camada de aplicação onde o IP do cliente é visível e antes que o tráfego chegue à VPC.

5. Proteção adaptativa e testes seguros

   • Ative a Proteção Adaptativa (Adaptive Protection) e crie uma regra de negação (deny) para o IP do cliente suspeito em modo de pré-visualização (preview mode).
   • Justificativa: O modo de pré-visualização (preview) permite a verificação do comportamento sem impactar os usuários reais; os logs confirmam se o cliente é malicioso antes de aplicar a regra.

6. Segmentação de saída (egress) com o Private Google Access

   • Mantenha uma rota 0.0.0.0/0 para o NGFW de terceiros. Adicione rotas estáticas personalizadas para os VIPs das APIs do Google para o gateway de internet padrão e ative o Private Google Access nas sub-redes. Adicione uma regra explícita de negação total (deny-all) de saída (egress) de alta prioridade, seguida por permissões específicas para o próximo salto (next-hop) do NGFW e para as APIs do Google; ative o registro de logs.
   • Justificativa: Força a saída geral para a internet através do NGFW, ao mesmo tempo que permite que o BigQuery e o Pub/Sub sejam alcançados de forma privada, sem o hairpinning desnecessário.

7. Controles de NAT e IP externo

   • Use o Cloud NAT para instâncias que precisam de saída para a internet, mas não têm IPs externos. Audite e remova quaisquer IPs externos em instâncias de computação que devem usar o NAT.
   • Justificativa: Evita o desvio do NAT (NAT bypass) e preserva uma postura de saída única.

8. Inspeção e monitoramento

   • Ative o Packet Mirroring em cada região para a camada de aplicação, direcionando para a conta de serviço da aplicação, e envie o tráfego espelhado para um coletor de IDS regional. Ative os VPC Flow Logs e o registro de regras de firewall para as regras principais; exporte os logs do Cloud Armor e da VPC para um projeto de segurança central e para o BigQuery.
   • Justificativa: Fornece visibilidade profunda para caça a ameaças (threat hunting) e linhas de base de desempenho (performance baselines) sem latência no caminho do tráfego (in-path).

9. Operações prontas para incidentes

   • Crie alertas para picos de negações no Cloud Armor, logs de negação do firewall ou alterações nas políticas hierárquicas. Documente um procedimento de acesso de emergência (break-glass) via SSH usando gcloud compute ssh do Cloud Shell para acesso de emergência controlado.
   • Justificativa: Detecta abusos ativos rapidamente e preserva um caminho operacional seguro para remediação.

10. Segurança em mudanças e rollback

• Prepare as alterações do Cloud Armor em modo de pré-visualização (preview) e, em seguida, aplique-as. Para alterações de firewall, use prioridades de menor risco e projetos canário (canary) antes de propagar para a política no nível da organização.
• Justificativa: Minimiza a chance de interrupções globais por erros de política, mantendo uma postura de segurança forte.

← Arquitetura de VPC · Todos os domínios · Conectividade Híbrida →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Google →