Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame PCSE avalia. Leia de cima a baixo ou pule para uma seção.
Workloads GKE precisam acessar APIs do GCP sem gerenciar chaves de contas de serviço.
Habilite e configure o Workload Identity no cluster GKE. Mapeie Contas de Serviço do Kubernetes (KSA) para Contas de Serviço do Google (GSA).
Por quê: Elimina o risco de vazamento de chaves de contas de serviço usando credenciais de curta duração, automaticamente rotacionadas, derivadas de tokens KSA.
Forneça acesso a aplicativos web internos de qualquer rede com base na identidade do usuário e postura do dispositivo, sem uma VPN.
Use o Identity-Aware Proxy (IAP) com o Access Context Manager. Defina níveis de acesso baseados em IP, estado do dispositivo (via Verificação de Endpoint) e identidade do usuário.
Por quê: Move o controle de acesso do perímetro da rede para usuários e dispositivos individuais, aplicando princípios de confiança zero.
Um pipeline de CI/CD (ex: GitHub Actions, GitLab) precisa acessar recursos do GCP sem credenciais de longa duração.
Use Workload Identity Federation. Crie um pool de provedores para o IdP externo (ex: GitHub OIDC) e configure condições de atributos para restringir o acesso a repositórios ou branches específicos.
Por quê: Autenticação sem chave para workloads externas. O sistema externo fornece seu próprio token, que é trocado por um token GCP de curta duração.
Aplique políticas de segurança do IAM em toda a organização, como impedir a criação de chaves de conta de serviço ou restringir concessões de IAM a domínios específicos.
Use restrições da Política da Organização como `iam.disableServiceAccountKeyCreation` e `iam.allowedPolicyMemberDomains`.
Por quê: As Políticas da Organização são herdadas e não podem ser sobrescritas por proprietários de projetos, garantindo uma postura de segurança consistente.
Um usuário precisa de acesso administrativo temporário, auditável e aprovado a um ambiente de produção para um incidente.
Use o Privileged Access Manager (PAM) para acesso just-in-time (JIT). O usuário solicita uma função específica por um tempo limitado, que passa por um fluxo de trabalho de aprovação.
Por quê: Elimina privilégios permanentes, um grande risco de segurança. O acesso é limitado no tempo, justificado e totalmente auditado.
Múltiplas equipes compartilham um cluster GKE. Cada equipe deve gerenciar recursos apenas dentro de seu próprio namespace.
Conceda a função IAM `roles/container.clusterViewer` no nível do projeto. Use Kubernetes RBAC `Role` e `RoleBinding` dentro de cada namespace para conceder permissões específicas (ex: editar, visualizar).
Por quê: Separa a autenticação em nível de cluster (IAM) da autorização em nível de namespace (Kubernetes RBAC), fornecendo controle multi-tenant e de granularidade fina.
APIs devem ser chamadas usando credenciais de curta duração em vez de chaves estáticas.
Use a personificação de conta de serviço. Conceda a um principal a função `roles/iam.serviceAccountTokenCreator` em uma conta de serviço de destino para gerar tokens de acesso OAuth 2.0 de curta duração.
Por quê: Evita a distribuição e o gerenciamento de chaves de longa duração. Os tokens expiram automaticamente (padrão de 1 hora), reduzindo o risco em caso de comprometimento.
Um contratado precisa de acesso a recursos específicos, mas o acesso deve expirar automaticamente após 30 dias.
Conceda a função IAM necessária com uma Condição IAM baseada em tempo, ex: `request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`.
Por quê: Automatiza a revogação de acesso, evitando a limpeza manual e garantindo que o acesso não seja prolongado inadvertidamente.
Permita que apenas imagens de contêiner que foram assinadas pelo pipeline de CI/CD sejam implantadas em clusters GKE de produção.
Implemente a Autorização Binária. Crie uma atestação no pipeline de CI para assinar imagens. Configure uma política de Autorização Binária no cluster GKE para exigir esta atestação.
Por quê: Aplica uma cadeia de suprimentos de software segura, impedindo que imagens não verificadas ou adulteradas sejam executadas em produção.
Conceda permissões a recursos com base em suas tags atribuídas, não em nomes de recursos individuais.
Use Condições IAM com expressões de tags de recurso, como `resource.matchTag("123456789/env", "prod")`.
Por quê: Permite controle de acesso baseado em atributos (ABAC) escalável. As permissões são dinâmicas e aplicadas automaticamente à medida que os recursos são marcados com tags.
Permita que um projeto de serviço implante VMs em um projeto host de Shared VPC sem conceder direitos de administrador de rede.
No projeto host, conceda à conta de serviço do projeto de serviço a função `roles/compute.networkUser` na(s) sub-rede(s) específica(s) que ela precisa usar.
Por quê: Segue o princípio do privilégio mínimo. Projetos de serviço podem usar a rede, mas não podem modificá-la (ex: alterar regras de firewall), que permanece gerenciada centralmente.
Um usuário com `storage.admin` não consegue criar um bucket. Você precisa identificar a causa raiz.
Verifique se há uma Política de Negação do IAM em um nível superior (pasta, organização) que negue a permissão `storage.buckets.create`.
Por quê: As políticas de negação do IAM sempre sobrepõem quaisquer políticas de permissão. Esta é uma ferramenta poderosa para impor limites de segurança não negociáveis.
Habilite SSO para usuários do Active Directory on-premises acessarem o console do Google Cloud.
Use o Google Cloud Directory Sync (GCDS) para sincronizar identidades com o Cloud Identity. Configure a federação (SAML) entre o Cloud Identity e o AD FS (ou outro IdP).
Por quê: Mantém o AD como a fonte da verdade para identidades, enquanto fornece uma experiência SSO federada e sem interrupções para os usuários.
Criptografe dados no GCP, mas as chaves de criptografia nunca devem sair do HSM on-premises.
Use o Cloud External Key Manager (EKM). Isso permite que os serviços do GCP usem chaves de um sistema de gerenciamento de chaves externo para operações CMEK.
Por quê: Fornece controle máximo e atende a requisitos rigorosos de soberania de dados, mantendo o material da chave fora do Google Cloud.
Encontre e classifique automaticamente dados sensíveis (PII, PHI) em todos os ativos do Cloud Storage e BigQuery.
Configure varreduras de descoberta do Cloud Data Loss Prevention (DLP). Os resultados podem preencher automaticamente o Data Catalog com tags.
Por quê: Fornece um inventário e classificação automatizados de dados, que são a base para políticas de governança e proteção de dados.
Uma equipe de análise precisa consultar dados que contêm PII, mas não deve ver os valores sensíveis brutos. A integridade referencial deve ser mantida.
Use um modelo de desidentificação do Cloud DLP com criptografia determinística ou hashing criptográfico.
Por quê: Transforma dados sensíveis em pseudônimos. Métodos determinísticos garantem que a mesma entrada sempre produza a mesma saída, permitindo junções e agregações.
Uma estrutura de conformidade (ex: para serviços financeiros) exige que as chaves de criptografia sejam protegidas por um HSM certificado FIPS 140-2 Nível 3.
Use o Cloud KMS com um nível de proteção HSM. Isso cria chaves dentro de um Hardware Security Module gerenciado.
Por quê: Atende aos requisitos de conformidade de alto nível usando hardware dedicado e certificado para gerenciamento de chaves sem gerenciar os HSMs físicos.
Garanta que novos recursos (ex: buckets do GCS, conjuntos de dados do BigQuery) sejam sempre criptografados com chaves gerenciadas pelo cliente (CMEK), e não com chaves gerenciadas pelo Google.
Aplique a Política da Organização `constraints/gcp.restrictNonCmekServices`.
Por quê: Fornece um controle preventivo que força serviços específicos a usar CMEK, garantindo uma postura consistente de proteção de dados.
Os dados devem ser armazenados em um estado imutável (WORM - Write-Once-Read-Many) por um período de retenção específico por razões legais ou de conformidade.
Configure um bucket do Cloud Storage com uma política de retenção e habilite o Bucket Lock.
Por quê: O Bucket Lock torna a política de retenção irreversível, garantindo que os objetos não possam ser excluídos ou modificados, mesmo por administradores, até o término do período de retenção.
Credenciais de banco de dados de aplicativos armazenadas como segredos devem ser rotacionadas automaticamente sem causar tempo de inatividade do aplicativo.
Use o Secret Manager com rotação automática configurada. A rotação dispara uma Cloud Function que atualiza a senha no banco de dados e cria uma nova versão do segredo.
Por quê: A rotação automatizada e gerenciada reduz o risco de comprometimento de credenciais. Os aplicativos referenciam a versão `latest` para obter o novo segredo de forma transparente.
Uma workload processa dados altamente sensíveis, e os dados devem permanecer criptografados mesmo em memória (em uso).
Use Computação Confidencial implantando a workload em VMs Confidenciais.
Por quê: Fornece criptografia de memória baseada em hardware, protegendo os dados do hypervisor e de outras VMs. Use atestação para verificar a integridade do ambiente.
Restrinja o acesso a colunas sensíveis específicas em uma tabela do BigQuery sem criar visualizações separadas.
Use a segurança em nível de coluna do BigQuery. Aplique tags de política do Data Catalog a colunas sensíveis e conceda a função "Fine-Grained Reader" nessas tags de política a usuários/grupos autorizados.
Por quê: Impõe acesso granular diretamente na tabela, o que é mais escalável e gerenciável do que manter várias visualizações autorizadas.
Proteja dados sensíveis em um bucket do GCS mesmo que as permissões do IAM estejam mal configuradas e concedam acesso público.
Criptografe objetos com uma Chave de Criptografia Gerenciada pelo Cliente (CMEK) e controle rigorosamente o acesso a essa chave no Cloud KMS.
Por quê: Cria um sistema de duas chaves. Um invasor precisa de permissões tanto para o objeto GCS QUANTO para a chave KMS para descriptografar os dados, fornecendo defesa em profundidade.
Evite a exclusão imediata acidental ou maliciosa de chaves críticas do Cloud KMS.
Ao criar a chave, configure a propriedade `destroy_scheduled_duration` para um valor como 30 dias.
Por quê: Impõe um período de espera antes que uma chave seja destruída permanentemente, fornecendo uma janela para recuperação de exclusões acidentais.
Um requisito legal para provar que um arquivo no Cloud Storage não foi alterado desde que foi enviado.
Após o download, recalcule o hash MD5 ou CRC32C do arquivo e compare-o com o hash armazenado nos metadados do objeto do Cloud Storage.
Por quê: Fornece prova criptográfica da integridade do objeto. O Cloud Storage calcula e armazena automaticamente esses hashes no upload.
Impeça que dados sejam copiados de um projeto sensível para um bucket público, mesmo por um usuário com a função `owner`.
Coloque o projeto sensível dentro de um perímetro de VPC Service Controls. Isso restringe o movimento de dados para outros projetos fora do perímetro.
Por quê: O VPC Service Controls atua como um firewall centrado em dados que substitui as permissões do IAM para saída de dados, fornecendo uma defesa poderosa contra a exfiltração.
Proteja um aplicativo web público contra ataques DDoS volumétricos e exploits web comuns (ex: SQLi, XSS).
Coloque o aplicativo atrás de um Global External HTTP(S) Load Balancer e anexe uma política de segurança do Cloud Armor com regras WAF pré-configuradas.
Por quê: O balanceador de carga absorve ataques DDoS na borda do Google. O Cloud Armor fornece um Web Application Firewall gerenciado para bloquear as 10 principais ameaças do OWASP.
Um Dedicated Interconnect é usado para conectividade on-prem para GCP, mas o tráfego deve ser criptografado para conformidade.
Configure um túnel VPN HA sobre os anexos VLAN do Cloud Interconnect.
Por quê: Combina a alta largura de banda e baixa latência de uma conexão dedicada com a criptografia IPsec de uma VPN.
Sistemas on-premises precisam chamar APIs do Google (ex: BigQuery, GCS) sem atravessar a internet pública.
Configure o Private Google Access para hosts on-premises. Use o Cloud Interconnect ou VPN, e configure o DNS para resolver `*.googleapis.com` para o intervalo VIP restrito.
Por quê: Mantém o tráfego para os serviços do Google na rede privada do Google, aprimorando a segurança e potencialmente reduzindo os custos de saída.
Aplique mTLS (mutual TLS) para todas as comunicações serviço-a-serviço dentro de um cluster GKE.
Implante o Anthos Service Mesh (ou Istio) e habilite a autenticação de peer mTLS estrita para os namespaces relevantes.
Por quê: Criptografa e autentica automaticamente todo o tráfego dentro da malha, alcançando um modelo de rede de confiança zero sem alterações no código do aplicativo.
Uma VPC de consumidor precisa acessar privadamente um serviço (ex: uma API interna) em execução em uma VPC de produtor sem usar peering ou IPs públicos.
O produtor publica o serviço usando o Private Service Connect. O consumidor cria um endpoint em sua VPC que roteia privadamente para o serviço.
Por quê: Desacopla a conectividade de rede do acesso ao serviço. É a maneira moderna e escalável de fornecer acesso privado a serviços entre VPCs e organizações.
Implante um cluster GKE onde os nós não têm IPs públicos e o plano de controle não é exposto à internet.
Crie um cluster GKE Privado. Habilite o Private Google Access na sub-rede para o acesso dos nós às APIs do GCP. Configure redes autorizadas do mestre para restringir o acesso ao plano de controle a IPs específicos (ex: rede corporativa).
Por quê: Reduz significativamente a superfície de ataque do cluster, removendo endpoints públicos para nós e para o plano de controle.
Em um cluster GKE, pods para um serviço `frontend` devem ter permissão para se comunicar apenas com pods para um serviço `backend`, e nada mais.
Crie recursos de Kubernetes NetworkPolicy. Aplique uma política de entrada aos pods `backend` que permite tráfego apenas de pods `frontend`, com base em rótulos de pod.
Por quê: Fornece firewalling em nível de pod dentro do cluster, permitindo um modelo de rede de privilégio mínimo para microsserviços.
VMs sem IPs externos precisam acessar a internet. Todo o tráfego de saída deve se originar de um pequeno conjunto de endereços IP previsíveis para allowlisting por terceiros.
Configure o Cloud NAT para a sub-rede contendo as VMs.
Por quê: Fornece tradução de endereços de rede gerenciada para tráfego de saída para a internet de instâncias privadas, com registro centralizado e alocação de IP.
Aplique uma regra de firewall base em toda a organização, como negar todo o SSH da internet, que não pode ser sobrescrita por equipes de projeto.
Crie uma Política de Firewall Hierárquica no nível da organização ou pasta com uma regra de negação para a porta 22 de `0.0.0.0/0` com alta prioridade.
Por quê: As políticas hierárquicas são avaliadas antes das regras em nível de VPC, permitindo que as equipes de segurança centrais apliquem barreiras de segurança de rede não negociáveis.
Resolva nomes de host internos dentro de uma VPC sem vazar consultas para servidores DNS públicos.
Configure uma zona gerenciada privada do Cloud DNS para seus domínios internos e associe-a à sua VPC.
Por quê: Fornece DNS autoritativo para recursos internos dentro da rede VPC, melhorando a segurança e a capacidade de gerenciamento.
Quando o Security Command Center detecta uma ameaça (ex: criptomineração), isole automaticamente a VM afetada.
Configure o SCC para publicar descobertas em um tópico do Pub/Sub. Acione uma Cloud Function que recebe a descoberta e modifica as tags de rede da VM para aplicar uma regra de firewall de "quarentena" pré-configurada.
Por quê: Permite uma resposta a incidentes automatizada e quase em tempo real, reduzindo o tempo que um invasor tem no ambiente.
Colete logs de auditoria de todos os projetos da organização e armazene-os por 7 anos em um formato imutável para conformidade.
Crie um sink de logs em nível de organização para um bucket do Cloud Storage. Configure o bucket de destino com uma política de retenção de 7 anos e Bucket Lock.
Por quê: Um sink agregado centraliza os logs. O Bucket Lock garante que os logs sejam à prova de adulteração e atendam a requisitos rigorosos de retenção de conformidade.
Uma VM é suspeita de estar comprometida. Ela deve ser desconectada imediatamente, mas as evidências devem ser preservadas para análise forense.
Pare a instância da VM (para interromper a atividade) e crie imediatamente um snapshot de seu disco persistente. Em seguida, isole-a com regras de firewall.
Por quê: Parar a instância contém a ameaça, enquanto o snapshot cria uma cópia pontual do disco para análise sem risco de adulteração de evidências.
Detecte quando uma conta de serviço está sendo usada de uma localização geográfica incomum ou está realizando atividades anormais.
Habilite o nível Premium do Security Command Center, que inclui o Event Threat Detection. Este serviço analisa logs em busca de comportamento anômalo.
Por quê: Usa a inteligência de ameaças e o aprendizado de máquina do Google para detectar ameaças difíceis de encontrar com alertas baseados em regras, como credenciais comprometidas.
Uma equipe de segurança central precisa analisar e correlacionar sinais de segurança de sistemas GCP, AWS e on-premises em uma única plataforma.
Ingira todos os logs e telemetria relevantes no Chronicle Security Operations (SIEM).
Por quê: O Chronicle é um SIEM nativo da nuvem projetado para análise em escala de petabytes, com parsers e regras de detecção integradas para ambientes multi-cloud e híbridos.
Detecte quando recursos do GCP gerenciados pelo Terraform são modificados manualmente via console, criando desvio de configuração.
Configure um feed do Cloud Asset Inventory para enviar notificações de mudança de ativos em tempo real para um tópico do Pub/Sub. Um serviço pode então comparar essas mudanças com o estado do Terraform.
Por quê: Fornece visibilidade em tempo real de todas as mudanças de recursos, permitindo a detecção automatizada de modificações fora de banda.
Uma organização tem milhares de descobertas do SCC e precisa focar naquelas que representam o risco mais imediato para ativos críticos.
Use a Simulação de Caminho de Ataque no SCC Premium. Defina ativos de alto valor e a simulação identificará e priorizará as descobertas que formam um caminho direto para esses ativos.
Por quê: Passa da priorização baseada em vulnerabilidades para a priorização baseada em risco. Destaca combinações perigosas de descobertas que um invasor poderia explorar.
Detecte atividade maliciosa dentro de um contêiner GKE em execução, como um shell inesperado ou uma conexão de reverse shell.
Habilite a Detecção de Ameaças em Contêineres no Security Command Center.
Por quê: Fornece visibilidade em tempo de execução do comportamento do contêiner, detectando ameaças que a varredura de vulnerabilidades (que ocorre antes da execução) não consegue ver.
Uma investigação forense de rede requer a captura e análise do conteúdo completo dos pacotes de tráfego entre duas VMs específicas.
Configure o Packet Mirroring para clonar o tráfego das VMs de origem e enviá-lo para uma VM coletora executando ferramentas de inspeção como Wireshark ou Zeek.
Por quê: Fornece captura completa de pacotes para análise profunda, ao contrário dos VPC Flow Logs que contêm apenas metadados.
Impeça que configurações Terraform inseguras (ex: buckets GCS públicos) sejam implantadas.
Integre uma ferramenta de teste de segurança de análise estática (SAST) como `tfsec` ou Checkov no pipeline de CI/CD. Falhe o build se violações de segurança forem encontradas.
Por quê: Implementa a segurança "shift-left" capturando configurações incorretas antes que sejam implantadas, reduzindo a necessidade de remediação reativa.
Uma empresa deve garantir que, por razões de conformidade, certos dados e processamento só possam ocorrer em regiões da UE.
Aplique a restrição da Política da Organização `gcp.resourceLocations`, permitindo apenas regiões da UE especificadas.
Por quê: Este é um controle técnico e preventivo que impõe a residência de dados no nível de criação de recursos, o que é exigido por regulamentações como o GDPR.
Uma instituição financeira exige que os engenheiros de suporte do Google obtenham aprovação explícita e com prazo antes de acessar seus dados para um caso de suporte.
Habilite o Access Approval e configure os aprovadores. Todas as solicitações de acesso do Google gerarão uma solicitação que deve ser aprovada.
Por quê: Fornece controle pelo cliente sobre o acesso administrativo do Google, um requisito chave para indústrias altamente regulamentadas.
Um auditor precisa verificar exatamente quais ações o pessoal do Google realizou quando recebeu acesso ao seu ambiente.
Habilite e revise os logs do Access Transparency. Esses logs fornecem um feed quase em tempo real das ações realizadas pela equipe do Google.
Por quê: Fornece um trilho de auditoria imutável das ações dos administradores do Google, dando visibilidade e suportando os requisitos de conformidade.
Monitore continuamente o ambiente GCP para configurações que violem um padrão de conformidade específico, como PCI DSS ou HIPAA.
Use o Security Health Analytics no Security Command Center, com o padrão de conformidade relevante habilitado no painel.
Por quê: Automatiza verificações de conformidade contra benchmarks da indústria, fornecendo visibilidade contínua e gerando descobertas para quaisquer configurações incorretas detectadas.
Um auditor solicita o relatório SOC 2 Tipo II do Google e a Atestação de Conformidade PCI DSS.
Use o Gerenciador de Relatórios de Conformidade no console do Google Cloud para acessar e baixar relatórios de auditoria e certificações.
Por quê: Fornece um portal de autoatendimento para os clientes obterem a documentação de conformidade necessária para apoiar seus próprios processos de auditoria.
Uma agência governamental dos EUA precisa implantar uma workload que atenda aos requisitos de conformidade FedRAMP High.
Implante o aplicativo em um ambiente Assured Workloads configurado para o regime de conformidade FedRAMP High.
Por quê: O Assured Workloads aplica automaticamente os controles e guardrails necessários (ex: localização de dados, restrições de acesso de pessoal) para ajudar a atender a padrões de conformidade específicos.