Configurações Incorretas Comuns na Nuvem

Configurações incorretas são a principal causa de violações de dados na nuvem. Diferentemente das vulnerabilidades tradicionais em ambientes locais, que exigem a exploração de falhas de software, as configurações incorretas na nuvem geralmente são causadas pela própria organização e podem ser facilmente exploradas por qualquer pessoa na internet.

Depósitos S3 com acesso público de leitura expõem todos os dados armazenados à internet. Atacantes procuram depósitos abertos usando ferramentas como GrayhatWarfare. Prevenção: ative o bloqueio de acesso público do S3 no nível da conta, habilite a propriedade de objetos do S3 e audite regularmente as políticas dos depósitos.

Grupos de segurança com 0.0.0.0/0 na porta 22 (SSH), 3389 (RDP) ou em portas administrativas criam superfícies de ataque enormes. Restrinja as regras de entrada a intervalos CIDR específicos. Utilize o AWS Systems Manager Session Manager em vez de SSH aberto.

Compartilhar acidentalmente snapshots RDS de forma pública expõe todo o conteúdo do banco de dados. Os snapshots automatizados são privados por padrão, mas os compartilhamentos manuais podem expor dados sensíveis. Audite a visibilidade dos snapshots com describe-db-snapshots --include-public.

Desenvolvedores enviam chaves de acesso da AWS, senhas de bancos de dados e tokens de API para repositórios Git. Atacantes examinam GitHub e GitLab com ferramentas como TruffleHog e GitLeaks. Prevenção: utilize gerenciadores de segredos, ganchos de pré-envio do git-secrets e verificação de segredos em toda a organização.

Sem o CloudTrail ativado em todas as regiões, as chamadas de API não são registradas. Atacantes exploram lacunas nos registros para agir sem serem detectados. Ative o CloudTrail em toda a organização e envie os registros para um depósito S3 de uma conta de segurança separada, utilizando o S3 Object Lock para proteção contra adulteração.

O IMDSv1 permite que qualquer processo em uma instância EC2 consulte o serviço de metadados sem autenticação, possibilitando ataques SSRF para roubar credenciais da instância. Aplique o IMDSv2 (com token obrigatório) em todas as instâncias para exigir autenticação orientada por sessão.

Os grupos de segurança normalmente permitem todo o tráfego de saída. Isso possibilita a exfiltração de dados e a comunicação C2 a partir de instâncias comprometidas. Utilize filtragem de saída por meio de grupos de segurança, NACLs ou um dispositivo de firewall para restringir as conexões de saída a destinos conhecidos.

Painéis do Kubernetes, clusters do Elasticsearch, instâncias do MongoDB e cadernos Jupyter deixados expostos sem autenticação em IPs públicos são comprometidos regularmente. Toda interface de gerenciamento deve exigir autenticação e ser restringida pela rede.

Somente os eventos de dados do S3 e os eventos de gerenciamento do CloudTrail não registram ações no nível de objeto, como GetObject e PutObject. Ative o registro de acesso do servidor S3 e os eventos de dados do S3 no CloudTrail para depósitos sensíveis, a fim de detectar tentativas de exfiltração de dados.

As regras do AWS Config com correção automática, por meio de documentos de automação do SSM ou do Lambda, podem corrigir violações automaticamente: tornar depósitos privados, fechar regras de grupos de segurança ou colocar credenciais em quarentena, reduzindo o tempo de exposição de dias para minutos.

Qual é o principal risco de manter o IMDSv1 ativado em instâncias EC2?

Configurações incorretas na nuvem — depósitos públicos, grupos de segurança permissivos, credenciais codificadas diretamente no código e registros ausentes — são a causa mais comum de violações na nuvem. A verificação automatizada, as proteções obrigatórias e o monitoramento contínuo são medidas defensivas essenciais.