Mais de 9,3 mil chaves da AWS vazadas continuavam ativas anos depois — 768 davam controle total a contas corporativas

Uma credencial publicada em um repositório não significa necessariamente que ela ainda seja perigosa. O risco se torna concreto quando a chave não foi revogada, continua autenticando e mantém permissões relevantes. Na investigação, essas três condições apareciam juntas com frequência.

Centenas de chaves corporativas davam controle administrativo total

Entre as chaves ativas associadas a contas corporativas, 817 foram atribuídas a empresas. O grupo incluía:

• 526 chaves de contas raiz da AWS;
• 242 chaves de usuários do IAM vinculadas à política AdministratorAccess;
• 768 chaves, no total, que ofereciam controle administrativo completo de uma conta corporativa da AWS.

As credenciais raiz representam o nível mais alto de controle disponível para um cliente da AWS. Já uma identidade do IAM com AdministratorAccess pode operar em praticamente todos os serviços da plataforma, com permissões amplas.

Uma chave válida com qualquer um desses níveis de privilégio pode abrir caminho para a tomada da conta, o acesso não autorizado a dados, a criação de recursos e o abuso da infraestrutura para gerar cobranças elevadas.

O problema, portanto, não é apenas de higiene no código-fonte. Também envolve permissões e gestão do ciclo de vida das credenciais. Apagar uma chave de um arquivo público não protege a conta se alguém já copiou o segredo: é necessário revogá-lo ou substituí-lo.

Hugging Face foi a maior fonte individual

O Hugging Face respondeu por 8.482 exposições de credenciais da AWS, tornando-se a maior fonte individual identificada no levantamento. Segundo a Truffle Security, 17,9% dessas credenciais eram chaves raiz.

O resultado faz parte de uma análise mais ampla de dados públicos do Hugging Face. A empresa afirmou ter examinado 7,6 petabytes de datasets públicos e encontrado credenciais ativas em milhares deles. O levantamento mostra como segredos podem continuar presentes fora dos repositórios de software tradicionais e ser incorporados a dados distribuídos publicamente.

Para as equipes de segurança, a conclusão é direta: verificar apenas os repositórios atuais não basta. Históricos do Git, artefatos de compilação, imagens de contêineres, registros, datasets publicados e saídas de pipelines de CI também podem preservar credenciais depois que os desenvolvedores acreditam tê-las removido.

As chaves tinham anos e quase nunca eram substituídas

A idade mediana das credenciais era de aproximadamente 1.831 dias, ou cerca de cinco anos. A chave mais antiga tinha 17,4 anos. Apenas 13,7% das entradas tinham uma chave mais nova associada, um indício de que a maioria não havia passado por um processo regular de rotação.

Chaves de longa duração ampliam o período em que uma credencial pode ser usada de forma indevida e dificultam a identificação de seus responsáveis. Elas também podem sobreviver a mudanças de funcionários, migrações de aplicações, limpezas de repositórios e trocas de equipes.

Na prática, a idade deve ser tratada como um sinal de risco. Uma chave exposta há vários anos não deve ser presumida como obsoleta. Ela precisa ser verificada, revogada e investigada — a menos que o responsável consiga comprovar que já não é válida.

Poucas contas tinham monitoramento de orçamento

A Truffle Security conseguiu ler informações de 2.754 contas, mas apenas 262 tinham alertas de orçamento da AWS ativados.

Alertas de orçamento não substituem a revogação de credenciais nem a detecção de ameaças. Ainda assim, eles podem funcionar como um aviso inicial quando uma chave exposta é usada para criar recursos caros, como em operações de mineração de criptomoedas ou outros abusos da nuvem.

Sem uma notificação que chegue a alguém capaz de agir, gastos anormais podem continuar mesmo depois que uma conta foi comprometida.

O que as notificações da AWS resolvem — e o que não resolvem

O levantamento descreve mecanismos da AWS capazes de identificar chaves de acesso divulgadas, notificar os clientes afetados e aplicar restrições ou medidas de quarentena. Porém, o fato de tantas chaves testadas continuarem válidas indica que a detecção ou o aviso nem sempre levaram a uma revogação e uma rotação rápidas por parte dos clientes.

Detectar o vazamento é apenas o primeiro passo. Uma resposta completa precisa identificar o responsável pela credencial, determinar a quais recursos ela tem acesso, verificar se houve uso indevido e invalidar a chave.

A Truffle Security caracteriza sua validação como somente leitura: os pesquisadores verificaram a autenticação e metadados de permissões ou da conta, sem alterar recursos dos clientes. Essa descrição é atribuída à própria Truffle Security e não é confirmada de forma independente por todas as fontes disponíveis.

O que fazer depois de um vazamento de chave da AWS

1. Revogue ou substitua a chave imediatamente

Exclua ou desative qualquer credencial exposta publicamente e só emita uma substituta se o acesso ainda for necessário. Remover o segredo do repositório, apagar o arquivo ou reescrever o histórico do Git não invalida cópias que já possam ter sido feitas.

2. Elimine as chaves de acesso da conta raiz

As chaves da conta raiz da AWS não devem ser usadas no acesso programático cotidiano. Exclua essas chaves e transfira as cargas de trabalho para identidades controladas, com permissões limitadas.

3. Verifique permissões e responsáveis

Descubra a qual conta, usuário, serviço e conjunto de recursos a credencial estava vinculada. Priorize chaves com privilégios raiz, AdministratorAccess, acesso amplo a dados ou autorização para criar infraestrutura.

4. Investigue antes e depois da revogação

Analise registros de autenticação, eventos do CloudTrail, alterações no IAM, recursos criados recentemente e cobranças em busca de atividades suspeitas. Revogar a chave impede novos usos da credencial exposta, mas não mostra se ela já foi utilizada.

5. Troque chaves permanentes por identidades de curta duração

Sempre que possível, use funções do IAM e identidades de carga de trabalho com validade curta, em vez de chaves de acesso permanentes. Permissões de menor privilégio reduzem o impacto potencial de um vazamento.

6. Configure alertas de orçamento e um fluxo de resposta

Ative alertas do AWS Budgets e o monitoramento de anomalias de custo. As notificações devem ser encaminhadas a contatos capazes de responder rapidamente. O monitoramento financeiro é uma barreira adicional — não substitui a varredura de segredos, a rotação de credenciais e a revisão de acessos.

A lição mais ampla para a segurança na nuvem

A descoberta mais importante não foi apenas a quantidade bruta de segredos. Foi a combinação de exposição pública, validade prolongada, privilégios elevados, idade extrema e monitoramento insuficiente.

Repositórios, datasets e outros armazenamentos públicos podem preservar credenciais muito depois de uma organização esquecer onde elas foram usadas. E uma chave copiada continua sendo uma porta de entrada até ser explicitamente revogada.

Para as equipes que administram ambientes em nuvem, a postura mais segura é simples: trate toda credencial da AWS exposta como comprometida, confirme o que ela pode acessar, revogue-a ou substitua-a imediatamente e migre de chaves duradouras para identidades de curta duração e com o menor privilégio possível.