Google PCA: Segurança, Conformidade e Arquitetura de Proteção de Dados — Guia de estudos

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Visão Geral

Segurança, conformidade e proteção de dados no Google Cloud são construídas sobre responsabilidade compartilhada e defesa em profundidade. O Google protege a infraestrutura subjacente, enquanto você projeta identidades, redes, aplicações e o tratamento de dados de forma segura. Adote o Zero Trust como um modelo orientador: nunca confie implicitamente na rede, verifique continuamente a identidade e o contexto e aplique estritamente o princípio do menor privilégio. Projete para o comprometimento: presuma que credenciais podem vazar, endpoints podem ser sondados e serviços internos podem ser mal utilizados. Compense com múltiplos controles (preventivos, detectivos e responsivos), criptografia forte e gerenciamento de chaves, monitoramento robusto e resposta a incidentes praticada.

Concessões (trade-offs) são inevitáveis. Controles mais fortes podem aumentar a latência, a complexidade operacional e os custos. Sua arquitetura deve ponderar explicitamente os riscos em relação à usabilidade e ao desempenho, preservando a conformidade comprovável e a prontidão para forense.

Arquitetura de Identidade e Acesso

• Princípios e modelo

  • Menor privilégio por padrão: conceda o menor conjunto de permissões necessário para concluir uma tarefa e prefira papéis predefinidos ou papéis personalizados em vez de papéis primitivos (Owner, Editor, Viewer).
  • Separação de funções: divida os papéis entre construtores (CI/CD), implantadores, operadores e segurança. Use contas de quebra de vidro (break-glass) com controles fortes e registros para emergências.
  • Aplicação do Zero Trust: use o acesso sensível ao contexto para verificar usuário, dispositivo, localização e risco; exija MFA forte; e avalie continuamente o contexto da sessão.
  • Política da organização e IAM Deny: codifique barreiras de proteção (por exemplo, proibir a criação de chaves de conta de serviço, restringir o compartilhamento de domínio) e use políticas de negação (deny policies) para impor limites não negociáveis.

• Implementação do IAM e estratégia de contas de serviço

  • Estabeleça um modelo de acesso orientado por hierarquia: as pastas refletem linhas de negócio ou ambientes (prod, non-prod); os projetos isolam o blast radius e o faturamento; as contas de serviço (SAs) representam as cargas de trabalho.
  • Uma carga de trabalho, uma conta de serviço: evite compartilhar SAs entre serviços não relacionados. Vincule as permissões ao escopo de implantação (projeto) e ao escopo do recurso.
  • Prefira credenciais de curta duração por meio da personificação de conta de serviço (Service Account Impersonation) e do Workload Identity Federation. Desative as chaves de conta de serviço gerenciadas pelo usuário; se inevitável, isole o uso, rotacione com frequência e monitore com registros de auditoria.
  • Use limites de acesso (Access Boundaries) para restringir o que uma SA personificada pode acessar no momento da solicitação (por exemplo, limitar caminhos de objetos do GCS), contendo o blast radius mesmo que uma SA privilegiada seja mal utilizada.
  • IAM condicional: aplique condições no nível do recurso (horário, IP, atributos do principal) para restringir o acesso. Exemplo: proibir o acesso à produção, exceto a partir de faixas de IP corporativas e durante as janelas de mudança.

• Modos de falha e concessões (trade-offs)

  • Papéis com privilégios excessivos (por exemplo, Editor no escopo do projeto) aumentam o risco; prefira papéis granulares e valide por meio de analisadores de política.
  • A proliferação de chaves de conta de serviço em CI/CD e scripts locais é um vetor de violação comum; com a personificação, algumas ferramentas legadas podem precisar de adaptação.
  • As políticas do IAM Deny são poderosas, mas podem ser difíceis de solucionar; prepare e teste as mudanças em ambientes de não produção com dry runs explícitos.

Exemplo (personificação sem criar chaves):

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

Proteção de Dados e Criptografia

• Cloud KMS e modelos de gerenciamento de chaves
  • A criptografia nativa em repouso (at rest) é o padrão. Para controle adicional, use Chaves de Criptografia Gerenciadas pelo Cliente (CMEK) com serviços como BigQuery, Cloud Storage, discos do Compute Engine, Pub/Sub e volumes persistentes do GKE.
  • Projete uma hierarquia de chaves por ambiente e domínio de dados. Use keyrings separados por localidade e chaves separadas por aplicação ou conjunto de dados para limitar o raio de impacto.
  • Rotação: habilite a rotação agendada e descontinue as versões mais antigas das chaves de forma gradual com criptografia de envelope para as aplicações. Valide a compatibilidade do consumidor antes de aumentar a frequência de rotação.
  • O External Key Manager (EKM) e o External Key Access (EKA) posicionam as chaves fora do Google Cloud para controle regulatório. Os trade-offs incluem latência adicional e dependência da disponibilidade de HSMs externos; planeje operações em modo degradado.
  • Aplique o princípio de menor privilégio do IAM nas CryptoKeys. Use logs de auditoria no nível da chave como evidência de acesso.

Exemplo (CMEK com rotação):

• gcloud kms keyrings create app-ring –location=us-central1

• gcloud kms keys create data-key –keyring=app-ring –location=us-central1 –purpose=encryption –rotation-period=90d

• Criptografia em nível de aplicação

  • Use criptografia de envelope (por exemplo, Tink) para criptografar campos sensíveis na camada de aplicação, permitindo acesso seletivo e isolamento de dados de locatários (tenants). Derive chaves por locatário (per-tenant) para minimizar o impacto entre locatários (cross-tenant).
  • Valide a integridade (AEAD) para prevenir adulteração e ataques de repetição (replay).

• Secret Manager e ciclo de vida de secrets

  • Armazene credenciais, tokens e chaves de API como secrets versionados; nunca em imagens, Git ou metadados de instância. Conceda permissões IAM no nível do secret ou do projeto para a conta de serviço (service account) de tempo de execução.
  • Rotação: automatize usando Cloud Functions/Cloud Run acionados por Pub/Sub para criar uma nova versão, atualizar dependentes e revogar versões antigas. Prefira substituir senhas de banco de dados de longa duração por autenticação de banco de dados baseada em IAM ou tokens de curta duração.
  • Segurança da configuração: separe configurações que não são secrets (ConfigMap, variáveis de ambiente) dos secrets. Evite a exposição de secrets em logs e mensagens de erro.

Exemplo (adicionar nova versão de um secret):

• gcloud secrets versions add db-password –data-file=password.txt –secret=db-password

• Hardening de computação e computação confidencial

  • Shielded VMs: habilite a inicialização segura (secure boot), vTPM e o monitoramento de integridade para proteger contra bootkits e rootkits. Imponha via política da organização e valide em pipelines de CI/CD.
  • Confidential VMs: a criptografia de memória padrão protege dados em uso com alterações mínimas de configuração; avalie o impacto no desempenho para cargas de trabalho (workloads) de alta taxa de transferência e uso intensivo de criptografia.
  • Imagens com hardening: comece com imagens base otimizadas pelo Google ou com hardening CIS; gerencie a aplicação de patches com o OS Config e desabilite pacotes e portas desnecessários.

Segurança de Rede e de Borda (Edge)

• Segmentação de rede e controle de egresso (egress)

  • Segmente por camada (tier) e sensibilidade usando VPCs, sub-redes e políticas de firewall hierárquicas separadas. Combine tags de firewall com reconhecimento de identidade com restrições de serviço a serviço (por exemplo, GKE NetworkPolicy) para impor controles leste-oeste (east-west).
  • Controle o egresso com Cloud NAT, políticas de DNS e Private Google Access restrito para minimizar a exfiltração de dados. Use listas de permissão (allowlists) de egresso explícitas e inspeção por proxy onde for justificado.

• VPC Service Controls (VPC SC)

  • Crie perímetros de serviço ao redor de projetos que hospedam dados no escopo para mitigar a exfiltração a partir de APIs gerenciadas pelo Google (GCS, BigQuery, Secret Manager, Pub/Sub, etc.).
  • Níveis de acesso: defina condições de contexto (identidade do usuário, faixas de IP, postura do dispositivo) que devem ser satisfeitas para acessar os serviços dentro do perímetro.
  • Use pontes de perímetro (perimeter bridges) para fluxos de trabalho controlados entre múltiplos perímetros e regras de egresso para restringir destinos. Teste com o modo de simulação (dry-run) para evitar a quebra de pipelines.
  • Limitações: não protege o tráfego para IPs do Compute Engine diretamente; complemente com controles de firewall e de egresso. Algumas ferramentas e padrões híbridos podem exigir contas de serviço (service accounts) cientes do perímetro e Private Service Connect para VIPs restritos.

• Proteção de borda (edge) e de aplicação

  • Cloud Armor: defenda aplicações HTTP(S) por trás do balanceador de carga externo global com mitigação de DDoS L3/L4/L7, listas de permissão/negação de IP (allow/deny lists), controles baseados em geolocalização e limitação de taxa (rate limiting).
  • Regras de WAF: aplique regras gerenciadas pré-configuradas e assinaturas personalizadas para o OWASP Top 10; ajuste para reduzir falsos positivos. Anexe por serviço de backend para personalizar políticas por versão de API ou componente da aplicação.
  • Proteção de API: posicione o API Gateway ou Apigee na frente das APIs para autenticação, cotas, validação de esquema (schema) e detecção de ameaças; integre o Cloud Armor para aplicação na borda (edge); considere o reCAPTCHA Enterprise e controles de bots quando apropriado.
  • Trade-offs: uma inspeção mais profunda pode adicionar latência e ruído operacional. Organize as regras em modo de pré-visualização (preview), monitore os logs e aplique-as progressivamente.

Operações de Segurança, Monitoramento e Conformidade

• Security Command Center (SCC) e detecção de ameaças

  • O SCC agrega o inventário de ativos e as descobertas entre projetos e organizações. Use-o para estabelecer uma linha de base da postura de segurança (buckets públicos, regras de firewall abertas), monitorar desvios e impulsionar fluxos de trabalho de remediação.
  • A detecção de ameaças Premium inclui Event Threat Detection, VM Threat Detection e Container Threat Detection para identificar malware, criptomineração e comportamento anômalo.
  • Integre as descobertas com pipelines de emissão de tickets e SOAR; defina políticas de supressão/exceção com expiração para evitar a fadiga de alertas.

• Vulnerabilidade e segurança de artefatos

  • Use o Artifact Analysis para escanear imagens de contêiner em busca de CVEs; aplique políticas no momento da implantação com o Binary Authorization e atestados assinados da CI.
  • Gerenciamento de patches via OS Config; monitore janelas de exposição e automatize lançamentos com canaries.

• Logs de auditoria, privacidade e evidências

  • Os Cloud Audit Logs fornecem logs de Admin Activity e System Event por padrão; os logs de Data Access podem ser habilitados por serviço e são cobráveis. Roteie os logs para o BigQuery para análise e para o Cloud Storage para retenção imutável e retenção legal (legal hold).
  • Classificação de dados: use o Cloud DLP para descobrir e classificar PII, aplicar rótulos e tags e mapear para níveis de proteção (CMEK, VPC SC, Confidential VMs).
  • Privacidade e residência de dados: restrinja localidades via política da organização; alinhe as localidades do CMEK e do armazenamento com os requisitos regulatórios.
  • Retenções legais (legal holds) e retenção: habilite políticas de retenção e holds em buckets; use o Object Versioning quando necessário. Documente a cadeia de custódia para imagens forenses e logs para produzir evidências defensáveis.

• Resposta a incidentes e prontidão forense

  • Prepare runbooks, caminhos de acesso e automação. Garanta que os respondentes tenham acesso de privilégio mínimo e que a auditoria esteja habilitada em toda a organização, pastas e projetos.
  • Contenção: isole instâncias removendo-as de balanceadores de carga, aplicando regras de firewall de negação de saída (egress) ou movendo projetos para políticas de organização mais rígidas; desative contas de serviço comprometidas e rotacione segredos e chaves.
  • Análise forense: faça snapshots de discos e exporte imagens para análise offline; preserve logs por meio de exportações. Use o espelhamento de pacotes (packet mirroring) quando aplicável. Evite modificar evidências; trabalhe a partir de cópias.
  • Recuperação: reconstrua a partir de imagens confiáveis, restaure segredos e valide com testes de fumaça (smoke tests) e de segurança. Conduza revisões pós-incidente e incorpore as lições aprendidas em guardrails e detecções.

Cenário de Problema Prático

A NimbusPay, uma SaaS de fintech, precisa processar dados marcados como PCI em microsserviços multilocatário (multi-tenant) no Google Cloud, garantir a residência de dados na UE, proteger contra ataques na camada de API e produzir evidências auditáveis dos controles. Eles lançarão uma nova API v2, mantendo a v1 ativa sob o mesmo hostname.

Abordagem:

1. Particionar projetos e identidades

• Crie projetos separados por ambiente e por camadas de microsserviços (ingestão, processamento, relatórios). Atribua uma conta de serviço de carga de trabalho (workload) exclusiva por serviço. Justificativa: isola o raio de impacto (blast radius) e mapeia o privilégio mínimo para cargas de trabalho distintas.

2. Aplicar Zero Trust e privilégio mínimo

• Conceda papéis predefinidos/personalizados para contas de serviço e grupos de DevOps; aplique o IAM condicional para restringir o acesso à produção a IPs e horários corporativos. Justificativa: reduz o movimento lateral e alterações acidentais.

3. Remover chaves estáticas de contas de serviço

• Desabilite chaves de SA gerenciadas pelo usuário via política da organização. Use a representação de conta de serviço (Service Account Impersonation) para CI/CD e operações; aplique Access Boundaries limitando os caminhos do GCS por locatário (tenant). Justificativa: elimina um vetor frequente de vazamento de credenciais e restringe o acesso a dados mesmo que os tokens sejam roubados.

4. Proteger dados com CMEK e controles regionais

• Crie keyrings e chaves do Cloud KMS nas regiões europe-west; habilite o CMEK para datasets do BigQuery, buckets do GCS e Persistent Disks. Configure a rotação agendada e o monitoramento de versão. Justificativa: controle criptográfico comprovável alinhado à residência na UE e ao PCI.

5. Adotar criptografia na camada de aplicação para dados de cartão

• Use criptografia de envelope (Tink AEAD) com chaves de dados por locatário (tenant) encapsuladas pelo CMEK; armazene apenas o texto cifrado nos bancos de dados. Justificativa: proteção em nível de campo e escopo minimizado durante a triagem de incidentes.

6. Centralizar segredos e rotacioná-los automaticamente

• Armazene credenciais de banco de dados e tokens de API no Secret Manager com IAM por serviço. Implemente trabalhos de rotação acionados por Pub/Sub que criam novas versões e atualizam as implantações. Onde possível, mude para a autenticação de banco de dados do IAM para o Cloud SQL. Justificativa: ciclo de vida de segredos auditável com tempo de inatividade (downtime) mínimo.

7. Segmentar redes e controlar o tráfego de saída (egress)

• Use políticas de firewall hierárquicas para impor fluxos web→API→DB; negue web→DB diretamente. Habilite o Cloud NAT com listas de permissão de saída (egress) e o Private Google Access (restrito) para as APIs do Google. Justificativa: restringe o movimento leste-oeste e bloqueia a exfiltração não autorizada.

8. Envolver serviços de dados com VPC Service Controls

• Coloque os projetos do BigQuery, GCS e Secret Manager em um perímetro de serviço; defina níveis de acesso que exijam IP corporativo e dispositivos gerenciados. Teste com o modo de simulação (dry-run) e depois aplique. Justificativa: mitiga a exfiltração de dados por meio de tokens roubados ou clientes mal configurados.

9. Proteger a borda e as APIs

• Posicione o balanceador de carga HTTPS global na frente com regras gerenciadas e limitação de taxa do Cloud Armor. Use o roteamento baseado em caminho para separar /v1 e /v2 para serviços de backend distintos e aplique políticas de WAF personalizadas por versão. Integre o Apigee para autenticação, cotas e validação de esquema. Justificativa: proteção de API em camadas, transição suave de v1→v2 e falsos positivos minimizados.

10. Fortalecer (Harden) a computação e atestar artefatos

• Habilite Shielded VMs e Confidential VMs para os nós de processamento; adote imagens de base fortalecidas pelo CIS (CIS-hardened). Escaneie imagens no Artifact Registry, exija atestados assinados com o Binary Authorization para o GKE. Justificativa: protege a cadeia de inicialização (boot) e os dados em uso, e impõe confiança na cadeia de suprimentos (supply-chain).

11. Monitorar a postura e as ameaças com o SCC

• Habilite o SCC Premium para detectar configurações de risco e ameaças em tempo de execução; integre com o sistema de tickets para SLAs. Suprima riscos aceitos com datas de expiração. Justificativa: garantia contínua e sinal acionável.

12. Registrar, reter e produzir evidências

• Roteie os logs de Admin Activity, Data Access e VPC Flow Logs para o BigQuery e o Cloud Storage com políticas de retenção e retenções legais (legal holds). Marque os datasets com rótulos de residência e sensibilidade. Justificativa: suporta investigações e auditorias externas com acesso de escopo definido.

13. Preparar a resposta a incidentes e a análise forense

• Crie runbooks para isolar serviços comprometidos movendo projetos para uma pasta de quarentena com políticas mais rígidas, desabilitando SAs implicadas e fazendo snapshots de discos para análise offline. Justificativa: contenção rápida com preservação de evidências.

Comandos curtos que apoiam o lançamento:

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

Com esses passos, a NimbusPay alcança uma proteção em camadas (identidade, criptografia, rede e borda), conformidade verificável, evolução controlada da API sob um único hostname e prontidão para detectar, conter e se recuperar de incidentes.

← Redes · Todos os domínios · Confiabilidade →

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

Navegar Google →