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

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Faz parte do Google Associate Cloud 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 segurança, a conformidade e a proteção de dados no Google Cloud baseiam-se em um modelo de responsabilidade compartilhada e em uma abordagem de segurança por padrão e defesa em profundidade. O Google protege a infraestrutura física, os serviços fundamentais e a criptografia padrão, enquanto você protege a identidade e o acesso, a classificação e retenção de dados, as configurações de aplicativos e os processos operacionais. Projete para o menor privilégio em toda a hierarquia de recursos, use grupos em vez de indivíduos, prefira identidades gerenciadas e credenciais de curta duração, e adicione controles em camadas para que a falha de um único controle não resulte em um comprometimento. Crie observabilidade e fluxos de trabalho de resposta desde o início para que a postura possa ser medida e melhorada continuamente.

Fundamentos de Identidade e Acesso

• Responsabilidade compartilhada e menor privilégio

  • Organize os projetos sob uma única organização com pastas que espelhem os limites de confiança. Aplique restrições da Organization Policy para impor padrões seguros (por exemplo, não permitir IPs públicos, restringir locais, impedir a criação de chaves de contas de serviço).
  • Conceda papéis do IAM a Google Groups, não a usuários, e prefira papéis predefinidos em vez de papéis básicos. Revise regularmente as vinculações de papéis e remova as permissões não utilizadas.
  • Habilite a auditabilidade e a atribuição. Para acesso de administrador ao SO de VMs, use o OS Login com chaves SSH por usuário; conceda aos grupos os papéis roles/compute.osLogin ou roles/compute.osAdminLogin. Exemplo:
    • gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE
    • gcloud projects add-iam-policy-binding PROJECT_ID --member='group:ops@example.com' --role='roles/compute.osAdminLogin'
  • Modos de falha comuns: conceder papéis de proprietário (owner) ou editor a usuários, usar chaves SSH para todo o projeto e criar chaves de contas de serviço de longa duração.

• Proteção de acesso a aplicativos com BeyondCorp e Identity-Aware Proxy (IAP)

  • O IAP encerra o acesso ciente de identidade na borda do Google para aplicativos HTTPS e para encaminhamento TCP (SSH/RDP), eliminando a necessidade de expor aplicativos ou bastions à internet. Combine com políticas de acesso sensíveis ao contexto (Access Context Manager) para exigir a postura do dispositivo, faixas de IP ou grupos de usuários.
  • Benefícios: autenticação/autorização (authN/Z) centralizada, atribuição forte, superfície de ataque reduzida e política de firewall simplificada (negar tráfego de entrada, exceto do load balancer/IAP).
  • Desvantagens: uma configuração incorreta pode bloquear o acesso dos administradores; mantenha um caminho de emergência (break-glass) (proprietário de projeto restrito, acesso ao console fora da banda - out-of-band). Alguns protocolos legados ou serviços não HTTP podem exigir o encaminhamento TCP do IAP ou controles alternativos.

• Contas de serviço e identidade de carga de trabalho (workload identity)

  • Prefira anexar contas de serviço ao Compute Engine, GKE com Workload Identity, Cloud Run e Cloud Functions para que as cargas de trabalho (workloads) obtenham tokens de curta duração automaticamente. Evite incorporar chaves; desabilite a criação de chaves de contas de serviço com a org policy. Defina o escopo do IAM em contas de serviço de forma restrita (princípio do menor privilégio).
  • Modos de falha: conceder o papel roles/iam.serviceAccountUser de forma ampla, o que permite a representação (impersonation); contas de serviço com privilégios excessivos que se tornam alvos para movimento lateral.

Proteção de Dados e Gerenciamento de Chaves

• Criptografia, Cloud KMS, CMEK e criptografia de envelope

  • O Google criptografa todos os dados em repouso e em trânsito por padrão. Para controle adicional e segregação de funções, use Customer-Managed Encryption Keys (CMEK) no Cloud KMS. Muitos serviços (BigQuery, Cloud Storage, Pub/Sub, discos do Compute Engine) suportam CMEK; os serviços usam criptografia de envelope, onde sua CMEK envolve as DEKs (Data Encryption Keys) por objeto ou por bloco (chunk).
  • Planeje a hierarquia de chaves: key rings por região, chaves criptográficas por domínio de dados e rotação a cada 90–365 dias com base no risco. Exemplo de rotação:
    • gcloud kms keys update KEY_NAME --keyring=KR --location=REGION --rotation-period=90d --next-rotation-time=YYYY-MM-DDT00:00:00Z
  • Controle de acesso: conceda a contas de serviço o papel Cloud KMS CryptoKey Encrypter/Decrypter apenas nas chaves necessárias. Monitore com os logs de uso do Cloud KMS.
  • Modos de falha e desvantagens: desabilitar ou excluir uma CMEK torna os dados dependentes ilegíveis; planeje runbooks de incidentes, verifique o IAM duas vezes antes da rotação e mantenha a disponibilidade das chaves entre as implantações. Considere o External Key Manager se precisar manter as chaves fora do Google Cloud; leve em conta a latência adicional e o risco de dependência externa.

• Secret Manager e eliminação de credenciais codificadas (hard-coded)

  • Armazene chaves de API, senhas de banco de dados e tokens no Secret Manager com versionamento automático e acesso baseado em IAM. Integre a rotação via Cloud Scheduler → Pub/Sub → Cloud Functions/Run, que atualiza o sistema de origem (upstream) e grava uma nova versão do segredo. Os aplicativos buscam os segredos na inicialização ou sob demanda e os armazenam em cache minimamente.
  • Melhores práticas: nunca confirme (commit) segredos no código ou em imagens; evite imprimir segredos em logs; conceda o papel roles/secretmanager.secretAccessor a identidades de carga de trabalho (workload identities); use labels para marcar a sensibilidade.
  • Modos de falha: incorporar segredos em variáveis de ambiente que são registradas em logs durante falhas (crashes); esquecer de atualizar os aplicativos dependentes (downstream) após a rotação; IAM amplo em segredos.

• Classificação, retenção e privacidade de dados

  • Classifique os dados (públicos, internos, confidenciais, regulamentados) e marque os ativos com labels. Use a segurança em nível de coluna e as políticas de acesso em nível de linha do BigQuery para um controle refinado. Para descoberta e mascaramento, use o Sensitive Data Protection (DLP).
  • Implemente a retenção: ciclo de vida de objetos do Cloud Storage (transições de classe baseadas na idade, exclusão), políticas de retenção de bucket com bloqueios (holds) e TTLs de tabela ou partição do BigQuery. Alinhe a retenção às necessidades legais; uma retenção mais longa aumenta o risco e o custo.
  • Privacidade e residência de dados: restrinja os locais dos recursos com as org policies; escolha armazenamento multirregional vs. regional com base nos requisitos de soberania e latência. Produza evidências com logs de auditoria e dashboards de postura do SCC.

Segurança de Rede e de Borda

• Defesa em profundidade para redes

  • Use regras de firewall da VPC com uma postura de negação por padrão; permita apenas as faixas de origem e portas necessárias. Prefira o Private Google Access e o Private Service Connect para manter o tráfego de API fora da internet pública. Habilite os VPC Flow Logs e o Firewall Rules Logging; revise os padrões de egresso regularmente.
  • Para controle de saída, negue todo o tráfego de egresso e, em seguida, permita explicitamente os destinos necessários por meio de um proxy de egresso por FQDN ou NAT mais proxy. Monitore os logs do Cloud NAT e configure o logging de DNS.

• VPC Service Controls (VPC SC), perímetros de serviço e níveis de acesso

  • Envolva as APIs do Google compatíveis (por exemplo, BigQuery, Storage, Pub/Sub) em perímetros de serviço para mitigar riscos de exfiltração de dados, mesmo que as credenciais sejam comprometidas. Use o Access Context Manager para definir níveis de acesso por grupo de usuários, IP ou postura do dispositivo, permitindo políticas sensíveis ao contexto.
  • Configure regras de egresso para integrações legítimas entre perímetros e pontes de perímetro (perimeter bridges) quando necessário. Teste com o modo dry-run do VPC SC para identificar possíveis quebras antes da aplicação.
  • Modos de falha: bloqueio não intencional de CI/CD ou jobs entre projetos, falha em integrações de terceiros ou desenvolvedores contornando as regras com dispositivos não gerenciados. Documente as exceções e revise-as regularmente.

• Cloud Armor, proteção contra DDoS e regras de WAF

  • A borda global do Google fornece proteção contra DDoS L3/L4 sempre ativa. O Cloud Armor adiciona proteções L7 para balanceadores de carga HTTP(S) externos, incluindo limitação de taxa (rate limiting), acesso baseado em geolocalização/IP, expressões personalizadas e conjuntos de regras de WAF pré-configurados.

  • Exemplo para criar e anexar um WAF básico:

undefined

-

undefined

- Anexe a política ao serviço de backend do seu balanceador de carga HTTPS.

• Melhores práticas: inicie as regras em modo de pré-visualização (preview) para reduzir falsos positivos, adicione regras de permissão (allow) para tráfego conhecido e seguro e habilite a proteção adaptativa, se elegível. Trade-offs: o Cloud Armor atua em balanceadores de carga HTTP(S) e baseados em proxy; balanceadores de carga de rede e LBs internos exigem outros controles.

Operações de Segurança e Conformidade

• Security Command Center (SCC) e gerenciamento de postura

  • Use o SCC como o plano de controle para visibilidade de riscos. O nível Standard agrega descobertas de configurações incorretas e dados de vulnerabilidade; o nível Premium adiciona detecções de ameaças (por exemplo, Event Threat Detection, VM and Container Threat Detection) e insights sobre caminhos de ataque.
  • Faça a triagem das descobertas por severidade, atribua responsáveis e acompanhe até a resolução. Exporte as descobertas para o BigQuery ou Pub/Sub para integração com SIEM e para evidências. Meça continuamente a postura em relação às políticas da organização e configure alertas sobre regressões.

• Shielded VM, secure boot, vTPM, monitoramento de integridade e reforço de segurança do SO

  • Habilite os recursos da Shielded VM para bloquear rootkits e adulteração do boot: Secure Boot, vTPM e Integrity Monitoring para detectar alterações em bootloaders e no kernel. Alguns kernels personalizados ou módulos não assinados podem falhar no Secure Boot; valide as imagens antes de habilitar.
  • Reforce a segurança do SO com o OS Config para conformidade de patches, baselines alinhados ao CIS, pacotes mínimos, SSH sem senha e registro de eventos de sudo e auth. Prefira o encaminhamento TCP do IAP para SSH e restrinja o ingresso a 0.0.0.0/0.

• Logs para forense, triagem, contenção e remediação de incidentes

  • Logs para habilitar a análise forense: logs de auditoria de Admin Activity e Data Access, VPC Flow Logs, Firewall Rules Logging, logs do Cloud DNS, logs do balanceador de carga e logs de acesso do Cloud KMS e do Secret Manager. Exporte para um projeto de log centralizado e para o BigQuery com retenção e controles de acesso apropriados.
  • Playbook de triagem e contenção:
    • Valide os indicadores com as descobertas do SCC e logs correlacionados.
    • Contenha revogando tokens suspeitos, desabilitando contas de serviço comprometidas, adicionando regras de firewall de negação ou isolando temporariamente instâncias com tags.
    • Preserve as evidências: crie snapshots de discos, exporte logs, capture a memória se necessário usando ferramentas aprovadas e registre a cadeia de custódia.
    • Remedeie: rotacione segredos e chaves, aplique patches em vulnerabilidades, reconstrua a partir de imagens sabidamente boas, adicione detecções para prevenir recorrência e realize uma revisão pós-incidente para fortalecer os controles.

Cenário de Problema Prático

A Nimbus Finance executa cargas de trabalho web e de API por trás de balanceadores de carga HTTP(S) externos, processa dados regulamentados no BigQuery e no Cloud Storage e permite que os engenheiros tenham acesso administrativo remoto. Um exercício recente de red-team demonstrou riscos de exfiltração de dados por meio de credenciais comprometidas e movimento lateral. A equipe de operações deve reforçar a segurança do acesso, proteger os dados e melhorar a detecção sem interromper a entrega.

1. Impor o OS Login com atribuição de administrador

• Passos: Habilitar o OS Login em todo o projeto; adicionar compute.osAdminLogin ao grupo de engenheiros; remover as chaves SSH de todo o projeto.
• Justificativa: Chaves SSH por usuário e concessões de papéis baseadas no IAM fornecem atribuição clara e revogação simples. Eliminar chaves compartilhadas reduz o movimento lateral.

2. Controlar o acesso remoto com IAP e acesso sensível ao contexto

• Passos: Colocar a UI de administração por trás de um balanceador de carga HTTPS protegido pelo IAP; exigir associação ao grupo de operações e postura de IP/dispositivo corporativo via Access Context Manager.
• Justificativa: O acesso zero-trust remove a exposição pública e impõe centralmente condições de identidade e dispositivo, reduzindo o risco de phishing e credential stuffing.

3. Implementar o Cloud Armor WAF com aplicação em estágios

• Passos: Criar uma política do Cloud Armor; habilitar regras WAF pré-configuradas para SQLi/XSS em modo de pré-visualização (preview); adicionar uma regra de limitação de taxa para /login; monitorar os logs; em seguida, aplicar.
• Justificativa: O modo de pré-visualização reduz falsos positivos; limites de taxa direcionados mitigam credential stuffing e bots sem prejudicar o tráfego legítimo.

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

• Passos: Criar um perímetro de serviço para os projetos do BigQuery e Cloud Storage; definir regras de egresso para jobs de CI/CD e analytics aprovados; exigir níveis de acesso baseados em grupo e rede.
• Justificativa: Perímetros mitigam a exfiltração de dados usando credenciais válidas, restringindo onde e como os dados protegidos podem ser acessados.

5. Aplicar CMEK com Cloud KMS e agendar a rotação

• Passos: Criar key rings regionais e chaves criptográficas para o BigQuery e Storage; conceder o papel roles/cloudkms.cryptoKeyEncrypterDecrypter apenas para contas de serviço; definir um cronograma de rotação de 180 dias; monitorar os logs de uso de chaves.
• Justificativa: O CMEK impõe a separação de responsabilidades e limites criptográficos controlados; a rotação limita o raio de impacto se uma chave for exposta.

6. Centralizar segredos com o Secret Manager e automatizar a rotação

• Passos: Mover tokens de banco de dados e de terceiros para o Secret Manager; conceder acesso de menor privilégio às cargas de trabalho; implementar um job Cloud Scheduler → Pub/Sub → Cloud Run para rotacionar segredos e criar novas versões.
• Justificativa: Elimina credenciais codificadas no código (hard-coded); o versionamento e a automação garantem uma rotação previsível e auditável com tempo de inatividade mínimo.

7. Fortalecer a segurança do host com Shielded VM e reforço de segurança do SO

• Passos: Habilitar Secure Boot, vTPM e Integrity Monitoring em todas as instâncias do Compute Engine; impor SSH sem senha; usar o OS Config para aplicar patches semanalmente e aplicar baselines do CIS.
• Justificativa: Previne adulteração no nível do boot, detecta desvios de configuração (drift) e reduz a superfície explorável nos nós de computação.

8. Aumentar a observabilidade e o gerenciamento de postura com o SCC

• Passos: Habilitar o SCC Premium em toda a organização; configurar notificações em tempo real para o Pub/Sub; exportar descobertas e logs para o BigQuery; construir dashboards para KPIs chave (descobertas altas abertas, tempo médio para remediar).
• Justificativa: A visibilidade unificada encurta as janelas de detecção-resposta e fornece evidências de conformidade.

9. Preparar e testar um playbook de incidentes

• Passos: Documentar os passos de triagem, contas de emergência (break-glass) privilegiadas e ações de contenção (desabilitar no IAM, isolar com firewall, revogar tokens); praticar trimestralmente; impor a retenção de logs e bloqueios de objetos no projeto de evidências.
• Justificativa: Fluxos de trabalho praticados reduzem erros sob pressão e preservam a integridade forense para análise de causa raiz e relatórios regulatórios.

10. Validar as mudanças e minimizar a interrupção

• Passos: Usar o modo dry run do VPC SC e o modo de pré-visualização (preview) do Cloud Armor para detectar quebras; implementar por ambiente com canaries; manter um plano de rollback e janelas de mudança.
• Justificativa: A implementação controlada mitiga os riscos de disponibilidade decorrentes do reforço da segurança, ao mesmo tempo que alcança a redução desejada no risco de exfiltração e acesso.

← Monitoramento · Todos os domínios · Confiabilidade →

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

Navegar Google →