O checklist que usamos para conduzir um security assessment em GCP

A maior parte dos assessments malfeitos começa direto no Security Command Center, exportando findings antes de saber o que compõe a organização. O primeiro passo real é o inventário: listar todas as pastas, projetos e organizações vinculadas via Resource Manager, incluindo projetos órfãos fora de qualquer pasta e projetos de billing account diferentes da esperada. Sem esse mapa, findings de projetos esquecidos nunca entram na análise — e são normalmente os mais desprotegidos.

Com o inventário fechado, o próximo bloco é IAM na camada de organização: Org Policies ativas versus as recomendadas pelo Google (restrição de contas externas, desativação de chaves de service account, exigência de OS Login), bindings de papéis primitivos (Owner, Editor, Viewer) atribuídos a usuários humanos, e service accounts com papéis herdados no nível da organização em vez de escopo no projeto. Esse nível concentra o maior risco por bind único — um Owner de organização mal atribuído derruba qualquer controle abaixo dele.

Em seguida vem o Security Command Center propriamente dito, mas com um filtro antes da leitura: ativar o nível Premium ou Enterprise se ainda não estiver, confirmar que todos os módulos relevantes estão habilitados (Security Health Analytics, Web Security Scanner, Event Threat Detection) e só então exportar findings — agrupando por categoria e recurso afetado, nunca por contagem bruta. Um assessment que reporta '7.929 findings' sem raiz causal não entrega decisão, entrega ansiedade.

A quarta frente é rede: VPCs com firewall rules 0.0.0.0/0 abertas para portas de administração, ausência de VPC Service Controls em perímetros que processam dados sensíveis, Cloud NAT mal configurado expondo egress desnecessário, e Private Google Access desabilitado forçando tráfego por IP público onde não precisa. Cruzar isso com o inventário de dados classificados pelo Cloud DLP mostra exatamente onde o perímetro de rede e o perímetro de dado divergem.

Dados pessoais e criptografia formam a quinta frente, obrigatória em qualquer ambiente sujeito à LGPD: descoberta via Cloud DLP em buckets e datasets do BigQuery, verificação de CMEK via Cloud KMS nos serviços que armazenam dado classificado, política de retenção configurada em nível de bucket e dataset, e Audit Logs de acesso a dados (Data Access logs) habilitados — esses últimos vêm desligados por padrão e raramente alguém percebe até precisar deles numa investigação.

A sexta frente é identidade e chaves: inventário de todas as service account keys estáticas, idade de cada chave, uso real nos últimos 30 dias via Policy Analyzer, e um plano de migração para Workload Identity Federation nos pipelines externos e identidades de workload no GKE. Chave estática sem uso nos últimos 30 dias é candidata a remoção imediata, não a rotação.

O assessment termina com um roadmap, não com um PDF de achados. Cada finding vira uma linha com raiz causal, esforço estimado, responsável e critério de verificação reproduzível — o mesmo padrão que usamos para mapear controles LGPD. Um roadmap que não pode ser auditado por outra pessoa em quinze minutos não é um roadmap, é uma opinião documentada.