CSPM: as 12 configurações erradas mais comuns na AWS, Azure e Google Cloud

No modelo de responsabilidade compartilhada, o provedor de nuvem protege a infraestrutura física e os serviços base, e o cliente é responsável por como configura e usa esses serviços. É nessa segunda parte que mora a maioria dos incidentes. Um dos vazamentos mais conhecidos da história da nuvem combinou um firewall de aplicação mal configurado, uma falha de SSRF e um papel com permissão ampla demais para ler buckets, expondo dados de mais de 100 milhões de pessoas.

CSPM (Cloud Security Posture Management) é a prática de avaliar continuamente essas configurações. Abaixo estão as doze falhas que mais aparecem, com o que verificar em cada provedor.

1. Armazenamento de objetos público

Buckets S3, contêineres do Azure Blob e buckets do Cloud Storage acessíveis por qualquer pessoa na internet.

• AWS: ative o bloqueio de acesso público no nível da conta, não só do bucket.
• Azure: desative o acesso anônimo a blobs na conta de armazenamento.
• GCP: use a prevenção de acesso público em nível de organização.

2. Identidades com permissão excessiva

Políticas com "Action": "*" ou "Resource": "*", papéis de proprietário atribuídos a contas de serviço, usuários com acesso administrativo que nunca usam.

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

Troque por ações e recursos específicos e use as ferramentas de análise de acesso do provedor para remover permissões não usadas nos últimos 90 dias.

3. Usuários sem MFA e chaves de acesso antigas

Contas humanas sem MFA e chaves de acesso estáticas com mais de 90 dias. Chaves antigas são as que acabam em repositórios. Veja o que fazer quando uma vaza no Git.

4. Banco de dados acessível pela internet

Instâncias RDS, Azure SQL ou Cloud SQL com IP público e regra de firewall aberta. Bancos devem ficar em sub-redes privadas, acessados por bastion, VPN ou conexão privada.

5. Security groups e firewalls abertos para o mundo

Portas 22 (SSH), 3389 (RDP), 5432, 3306, 6379 e 9200 abertas para 0.0.0.0/0. Use acesso via gerenciador de sessões do provedor em vez de SSH exposto.

6. Trilhas de auditoria desligadas

CloudTrail, Activity Log e Cloud Audit Logs desativados, sem retenção adequada ou sem proteção contra exclusão. Sem esses logs, não dá para investigar um incidente nem cumprir o prazo de comunicação da LGPD.

7. Criptografia em repouso desativada

Volumes, snapshots, bancos e backups sem criptografia, ou com chaves gerenciadas sem rotação. Hoje a maioria dos serviços criptografa por padrão, mas recursos antigos e snapshots compartilhados escapam.

8. Snapshots e imagens compartilhados publicamente

Snapshots de disco e de banco marcados como públicos por engano, muitas vezes com cópia completa de produção.

9. Acesso a metadados da instância sem proteção

Na AWS, o IMDSv1 permite que uma falha de SSRF na aplicação leia credenciais temporárias da instância. Exija IMDSv2 em todas as instâncias. SSRF agora faz parte da categoria de controle de acesso quebrado no OWASP Top 10 2025.

10. Clusters Kubernetes com API pública e RBAC amplo

Plano de controle exposto, cluster-admin atribuído a contas de serviço, pods privilegiados. Veja o checklist de Kubernetes.

11. Funções serverless com variáveis sensíveis em texto claro

Credenciais de banco e chaves de API em variáveis de ambiente de funções, visíveis para quem tem leitura no console. Use o gerenciador de segredos do provedor.

12. Recursos órfãos

Máquinas de teste esquecidas, ambientes de homologação antigos, registros DNS apontando para recursos excluídos (que permitem sequestro de subdomínio). Tudo que não tem dono vira porta de entrada.

CSPM e IaC: prevenir e detectar

A configuração correta deveria nascer no código. A análise de infraestrutura como código avalia Terraform, CloudFormation, Bicep e manifestos Kubernetes no pull request, antes do deploy. Mas nem toda mudança passa pelo código: ajustes manuais no console, recursos criados em incidentes e contas legadas só aparecem no CSPM.

Priorize pelo caminho de ataque

Um CSPM bem configurado encontra centenas de desvios numa conta média. Nem todos importam igualmente. Um bucket público vazio é menos grave do que um bucket privado lido por um papel que está anexado a um container exposto com uma CVE alcançável. Esse encadeamento é o que a análise de caminhos de ataque mostra, e é por onde a correção deve começar.

Priorize nesta ordem:

1. Recursos com dados sensíveis (use DSPM para saber quais são)
2. Recursos expostos à internet
3. Identidades com permissão de escrita ou administração
4. O restante, por severidade e esforço