Google PCNE: Conectividade Privada para o Google e Serviços Gerenciados — 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 conectividade privada com o Google e serviços gerenciados abrange padrões que permitem que as cargas de trabalho se comuniquem com as APIs do Google, redes de produtores gerenciadas pelo Google e serviços de terceiros sem usar IPs públicos. Os objetivos são reduzir o risco de exfiltração de dados, simplificar a conformidade e melhorar a previsibilidade, mantendo o tráfego em caminhos privados. Os componentes essenciais incluem o Private Google Access (e endpoints restritos), o Private Services Access (para IPs privados para serviços gerenciados pelo Google), o Private Service Connect (para publicação e consumo de serviços privados no modelo produtor-consumidor, incluindo APIs do Google), o VPC Service Controls (para criação de perímetros de dados), o Cloud NAT (para saída privada para a internet pública) e o mapeamento de DNS para seleção determinística de endpoints.

O sucesso do design depende de três decisões:

Qual mecanismo de acesso privado corresponde ao serviço e ao modelo de segurança (PGA vs. PSC para APIs do Google, PSA vs. PSC para serviços gerenciados ou de parceiros).
Como o DNS deve resolver nomes de serviço para destinos privados sem interromper serviços não suportados.
Como as políticas de roteamento e de perímetro interagem para que o tráfego permaneça privado de ponta a ponta em caso de falha ou alteração.

Os modos de falha geralmente derivam da seleção de rota, da ordem de resolução do DNS, do escopo regional dos endpoints ou de regras de perímetro que negam chamadas silenciosamente. Valide cada camada: resolução de nomes, rota, firewall, integridade do endpoint e política de serviço.

Private Google Access, endpoints restritos e seleção de endpoints

O Private Google Access (PGA) permite que VMs e nós do GKE sem IPs externos alcancem as APIs e serviços do Google usando os VIPs anycast do Google através do gateway de internet padrão da VPC, e não pelo Cloud NAT. Ele é habilitado por sub-rede.

Endpoints:
- private.googleapis.com (199.36.153.8/30): superfície completa das APIs do Google.
- restricted.googleapis.com (199.36.153.4/30): subconjunto de APIs compatíveis com o VPC Service Controls. Use este endpoint quando você impõe perímetros de serviço.
Abordagens de mapeamento de DNS:
- Manter os nomes públicos padrão e permitir que os clientes acessem o DNS público. Isso funciona se você permitir a saída (egress) via Cloud NAT, mas enfraquece os controles de exfiltração de dados.
- Sobrescrever nomes de host de API específicos em uma zona privada do Cloud DNS para googleapis.com com CNAMEs para restricted.googleapis.com (ou private.googleapis.com) para forçar a resolução privada por serviço. Exemplo: crie uma zona privada googleapis.com e adicione um CNAME de storage.googleapis.com para restricted.googleapis.com.
Considerações de roteamento:
- O PGA exige uma rota para o gateway de internet padrão. Se você enviar 0.0.0.0/0 para um NGFW de terceiros, adicione rotas de host explícitas para que os VIPs da API do Google usem o gateway de internet padrão:

undefined

Modo de falha: se essas rotas de host estiverem ausentes, as instâncias sem IPs externos não conseguirão alcançar as APIs quando o próximo salto (next-hop) de 0.0.0.0/0 for uma instância de firewall.
Configuração da sub-rede:

undefined

Trade-offs:

restricted.googleapis.com reduz o risco de exfiltração, mas algumas APIs não estão disponíveis.
O tráfego do PGA ignora o Cloud NAT, portanto, os logs do NAT não o registrarão. Use os VPC Flow Logs na sub-rede.

Para clientes on-premises, você pode fornecer acesso privado às APIs do Google anunciando os prefixos 199.36.153.4/30 e/ou 199.36.153.8/30 para o ambiente on-premises via Cloud VPN/Interconnect, com o próximo salto (next hop) sendo o gateway de internet padrão na VPC, ou expondo endpoints do PSC (veja abaixo) e mapeando o DNS on-premises para esses endpoints.

Acesso a Serviços Privados (PSA) e Private Service Connect (PSC)

O Acesso a Serviços Privados (Private Services Access - PSA) fornece conectividade de IP privado para redes de produtor gerenciadas pelo Google que hospedam serviços como Cloud SQL (IP privado) e Memorystore. Você aloca um intervalo RFC1918 em sua VPC para o Google usar e estabelece uma conexão de peering com a rede do produtor de serviço.

Padrão de configuração:
- Reserve um intervalo de endereços para o peering de VPC:

undefined

Estabeleça a conexão privada:

undefined

Provisione o serviço gerenciado com IP privado.
Notas operacionais:
- O intervalo deve ser grande o suficiente para todas as instâncias e não deve se sobrepor a intervalos existentes.
- O peering não é transitivo; o tráfego deve se originar da VPC pareada (recursos on-premises podem alcançar através da VPC se o roteamento permitir).
- Alterar ou reduzir o intervalo posteriormente causa interrupções; planeje a capacidade.

O Private Service Connect (PSC) estende a conectividade privada para:

APIs do Google (o consumidor cria endpoints com IPs privados em uma sub-rede, e o DNS mapeia os nomes das APIs para esses IPs).
Serviços de parceiros e SaaS publicados por meio de anexos de serviço (service attachments).
Seus próprios serviços publicados privadamente para outros projetos ou organizações por meio de anexos de serviço (service attachments).

Modelo produtor-consumidor:

O produtor publica um anexo de serviço (service attachment) em uma região, apoiado por um balanceador de carga interno. O produtor pode exigir listas de permissões (allowlists) de projetos/organizações do consumidor e especificar cotas de conexão.
O consumidor cria um endpoint PSC (regra de encaminhamento) na mesma região, visando o anexo de serviço do produtor. O endpoint obtém um IP da sub-rede escolhida.

Restrições de design e trade-offs:

O PSC é regional; implante por região, perto dos consumidores. Use políticas de DNS ou registros ponderados para direcionar clientes próximos e fornecer failover.
Não há transitividade através do PSC; os consumidores não podem encadear serviços por meio de um endpoint.
O IP de origem não é preservado de ponta a ponta através do PSC; projete os controles do lado do produtor com isso em mente (por exemplo, confie na identidade ou na autorização em nível de aplicação).

Modos de falha comuns:

Falhas nas verificações de saúde (health checks) do ILB do produtor fazem com que as conexões PSC sejam recusadas.
Endpoint do consumidor criado em uma região diferente da do anexo de serviço.
Política de negação (deny policy) do produtor ou a falta de um projeto na lista de permissões (allowlist) bloqueia as conexões.
DNS não apontando para o IP do endpoint, ou zonas privadas sobrepostas resolvendo para o destino errado.

VPC Service Controls, perímetros, entrada/saída (ingress/egress) e mapeamento de DNS

O VPC Service Controls (VPC-SC) define perímetros de serviço em torno de recursos gerenciados pelo Google para mitigar a exfiltração de dados. Dentro de um perímetro, as solicitações para serviços protegidos devem se originar de projetos no escopo e satisfazer quaisquer níveis de acesso configurados.

Perímetros:
- Perímetros padrão (standard) protegem projetos que hospedam dados (por exemplo, BigQuery, Cloud Storage).
- Pontes de perímetro (perimeter bridges) permitem interação limitada entre perímetros que, de outra forma, estariam isolados.
- Regras de entrada (ingress) concedem acesso específico de fora do perímetro (por exemplo, de projetos de CI/CD ou monitoramento).
- Regras de saída (egress) restringem quais serviços externos ou projetos dentro do Google Cloud podem ser chamados.
Seleção de endpoint:
- Use

undefined

para limitar as chamadas de API a serviços compatíveis com VPC-SC e evitar chamadas acidentais para endpoints públicos que não são cientes do perímetro.

O PSC para APIs do Google oferece um controle mais forte, mantendo o tráfego em IPs privados e permitindo afinidade regional, mas ainda requer a configuração do perímetro para autorização.
DNS e nomenclatura:
- Implemente DNS split-horizon com zonas privadas do Cloud DNS para que os clientes internos resolvam nomes de API para alvos privados.
- Prefira registros por serviço ou CNAMEs para

undefined

em vez de usar um curinga para todo o

undefined

, o que pode quebrar serviços que devem permanecer públicos.

Para o PSC, publique registros A apontando para o IP de cada endpoint. Use zonas separadas por ambiente para evitar o consumo acidental entre ambientes.

Armadilhas:

Usar o Cloud NAT para alcançar o

undefined

público pode contornar a intenção do VPC-SC, a menos que as regras do perímetro restrinjam explicitamente a saída (egress); combine o NAT com DNS restrito ou PSC.

Algumas APIs têm múltiplos hostnames (por exemplo, endpoints JSON vs. XML); garanta que seu mapeamento de DNS cubra todos os nomes que seus clientes usam.
A má configuração do perímetro falha em modo fechado (fails closed); monitore os logs do Access Transparency e do VPC-SC para detectar negações.

Padrões de saída, acesso híbrido e solução de problemas

Padrões de saída para workloads privados:

Apenas APIs do Google: Habilite o PGA e mapeie o DNS para restricted.googleapis.com, ou implante o PSC para APIs do Google e mapeie o DNS para os IPs do endpoint.
Internet e SaaS: Use o Cloud NAT para instâncias sem IPs externos. Dimensione o NAT para o pico de conexões e portas simultâneas; monitore o esgotamento de portas.
Misto com um NGFW de terceiros: Mantenha o NGFW como padrão, mas adicione rotas de host específicas para os VIPs anycast das APIs do Google para garantir que o PGA contorne o firewall. Para destinos que não são do Google, envie para o NGFW ou Cloud NAT conforme a política.

Clientes híbridos (on-premises ou em outras nuvens):

Para consumir APIs do Google de forma privada:
- Opção A: Private Google Access para on-premises anunciando 199.36.153.4/30 e/ou 199.36.153.8/30 do Cloud Router para o ambiente on-premises com o next hop sendo o gateway de internet padrão na VPC; mapeie o DNS on-premises para restricted/private.googleapis.com conforme necessário.
- Opção B: Endpoints do PSC para APIs do Google em sua VPC; exponha-os através do Cloud VPN/Interconnect roteando para os IPs do endpoint e mapeando o DNS on-premises adequadamente.
Para alcançar serviços gerenciados pelo Google com IPs privados (via PSA), estabeleça conectividade com a VPC (Cloud VPN/Interconnect), garanta que os intervalos RFC1918 não se sobreponham, propague as rotas e permita as regras de firewall.

Solução de problemas e verificação:

DNS: Use dig ou nslookup no hostname da API a partir de um cliente e verifique se ele resolve para o endereço privado pretendido (IP do endpoint do PSC) ou para os VIPs anycast restricted/private. Verifique a ordem da política do Cloud DNS e as zonas privadas na VPC.
Roteamento: Use gcloud compute routes list e confirme que a rota mais específica corresponde ao next hop pretendido (gateway de internet padrão para VIPs do PGA, interno para PSC).
Firewall: Verifique se as regras de egresso permitem TCP 443 para os IPs de destino. Para producers com balanceamento de carga por trás do PSC, verifique se os intervalos de origem da verificação de integridade (health check) são permitidos.
PGA: Confirme se a configuração da sub-rede está habilitada e se as rotas de host para 199.36.153.4/30 e/ou 199.36.153.8/30 existem caso uma rota padrão personalizada esteja em vigor.
PSA: Use gcloud services vpc-peerings list para confirmar se o peering de servicenetworking está ATIVO e se o intervalo alocado está correto e não está em uso em outro lugar.
PSC: No lado do consumer, descreva o endpoint para ver o status da conexão; no lado do producer, verifique as conexões pendentes ou rejeitadas e a saúde do ILB. Verifique a lista de permissões (allowlist) de consumers do service attachment.
Cloud NAT: Use os logs e métricas do NAT para confirmar as traduções e verifique a alocação ou o esgotamento de portas. Se uma instância tiver um IP externo, ela ignora o NAT por padrão (by design).

Cenário de Problema Prático

A Contoso Research executa análises em duas regiões (us-east1, europe-west1). A segurança exige que nenhuma VM tenha um IP público, que as APIs do Google sejam acessíveis de forma privada e sob os VPC Service Controls, que os usuários on-premises precisem de acesso privado a uma instância do Cloud SQL (IP privado) e que o SaaS de um parceiro seja consumido de forma privada. Um NGFW de terceiros é o next hop de egresso padrão.

Habilitar o Private Google Access e endpoints restritos

Ação: Habilite o Private Google Access em todas as sub-redes de análise. Crie zonas privadas do Cloud DNS para googleapis.com e adicione CNAMEs para as APIs necessárias (BigQuery, Pub/Sub, Cloud Storage) para restricted.googleapis.com. Adicione rotas de host para 199.36.153.4/30 para o gateway de internet padrão em ambas as regiões.
Justificativa: Garante que o tráfego de VM para API permaneça privado, seja compatível com o VPC-SC e contorne o NGFW sem criar um egresso amplo para a internet.

Criar um perímetro do VPC Service Controls

Ação: Coloque os projetos de análise e os projetos de dados dentro de um perímetro de serviço. Adicione níveis de acesso para as redes corporativas da Contoso conforme necessário e permita explicitamente os fluxos entre projetos necessários por meio de regras de ingresso (ingress rules). Evite pontes de perímetro (perimeter bridges), exceto onde estritamente justificado.
Justificativa: Reduz o risco de exfiltração de dados de serviços gerenciados pelo Google e se alinha com o uso de endpoints restritos.

Provisionar o Cloud SQL com Private Services Access

Ação: Aloque um /24 para o PSA, conecte o servicenetworking e crie uma instância do Cloud SQL com IP privado em us-east1. Propague as rotas da VPC para o ambiente on-premises através do Interconnect e permita as regras de firewall.
Justificativa: Fornece alcançabilidade privada RFC1918 tanto para os workloads da VPC quanto para os clientes on-premises, sem exposição pública.

Fornecer acesso privado on-premises às APIs do Google

Ação: Anuncie 199.36.153.4/30 do Cloud Router para o ambiente on-premises, com o next hop sendo o gateway de internet padrão na VPC. No DNS on-premises, mapeie os mesmos hostnames de API para restricted.googleapis.com.
Justificativa: Permite que os clientes on-premises usem o mesmo caminho privado restrito, garantindo a aplicação consistente de políticas e minimizando a variação operacional.

Consumir o SaaS do parceiro via Private Service Connect

Ação: O parceiro compartilha um service attachment regional. Crie endpoints do PSC nas sub-redes de us-east1 e europe-west1, direcionando para o attachment. Publique registros A privados (saas.partner.contoso) apontando para cada endpoint regional; use DNS ponderado (weighted) para preferir o acesso regional.
Justificativa: Mantém o tráfego SaaS em IPs privados com listas de permissão (allowlists) de projetos aplicadas pelo producer, melhora a latência por meio da afinidade regional e evita o egresso público.

Manter o Cloud NAT para egresso de internet não relacionado ao Google

Ação: Implante gateways do Cloud NAT por região, dimensionados para os fluxos de pico. Garanta que a rota padrão ainda aponte para o NGFW, exceto pelas rotas de host específicas para os VIPs restritos.
Justificativa: Permite saída controlada para destinos não relacionados ao Google, garantindo que o tráfego das APIs do Google permaneça privado e que o NGFW mantenha a visibilidade centralizada.

Validar e monitorar

Ação: Para cada tipo de cliente, verifique a resolução de DNS, a seleção de rota e a conectividade TLS. Verifique os logs do VPC-SC em busca de negações, os logs do NAT para egresso não relacionado ao Google e os status de conexão do PSC. Adicione alertas de saúde e disponibilidade para os ILBs por trás do service attachment do parceiro e para o Cloud SQL.
Justificativa: Confirma que o caminho dos dados corresponde ao design pretendido e expõe regressões precocemente, especialmente quando DNS, rotas ou perímetros mudam.

← Cloud DNS · Todos os domínios · Roteamento →

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