Milhares de credenciais AWS vazadas continuam ativas – algumas há mais de cinco anos
Uma chave de acesso da Amazon Web Services publicada acidentalmente em um repositório, notebook, imagem de contêiner ou registro de integração contínua pode parecer apenas uma falha operacional. O risco, porém, aumenta consideravelmente quando essa credencial permanece válida após a exposição – e pior ainda quando continua esquecida durante anos.
Uma pesquisa da Truffle Security identificou milhares de credenciais AWS expostas publicamente que ainda permitiam autenticação. O levantamento reforça que remover uma chave de um arquivo ou apagar um commit não elimina o problema. Se a credencial não for revogada ou substituída, a identidade associada permanece disponível para uso indevido.
Foram encontradas 64.024 chaves AWS únicas. Em uma análise mais aprofundada, realizada em 10 de agosto de 2026 sobre 10.616 conjuntos completos de credenciais, aproximadamente 88% ainda conseguiam se autenticar. O resultado indica que muitas das chaves não eram apenas registros antigos sem utilidade: continuavam tecnicamente funcionais e poderiam permitir acesso a aplicações, dados, serviços e infraestrutura corporativa.
O verdadeiro risco está nas permissões
Uma AWS Access Key não é apenas uma combinação de letras e números. Ela representa uma identidade técnica usada por aplicações, scripts e serviços para acessar recursos da nuvem. Seu potencial de ação depende das políticas atribuídas no IAM, o Identity and Access Management da AWS.
Por isso, a descoberta de uma credencial exposta deve ser seguida por uma análise de privilégios. Uma chave limitada a uma única tarefa pode gerar impacto restrito. Já uma credencial associada a permissões administrativas pode permitir alterar configurações, copiar dados, criar novos usuários, desativar mecanismos de segurança e ampliar o controle sobre o ambiente.
A pesquisa encontrou 526 root access keys e outras 242 credenciais ligadas a usuários IAM com a política AdministratorAccess. Ao todo, foram identificados 768 casos com capacidade administrativa significativa. Chaves root são especialmente críticas porque estão diretamente relacionadas à conta AWS e possuem privilégios muito amplos.
Na prática, uma credencial desse tipo pode funcionar como uma chave mestra esquecida em um local público. Mesmo que nenhum abuso seja detectado imediatamente, sua simples permanência ativa aumenta a janela de oportunidade para criminosos.
Por que credenciais permanecem válidas por tanto tempo?
A persistência dessas chaves revela uma deficiência recorrente nos processos de segurança. Em muitas organizações, a rotação de credenciais ainda depende de procedimentos manuais, documentação incompleta e responsabilidade pouco definida entre desenvolvimento, operações e segurança.
Também é comum que uma chave seja criada para uma tarefa temporária e posteriormente passe a ser utilizada por diferentes sistemas. Quando isso acontece, ninguém quer desativá-la por medo de interromper aplicações críticas. O resultado é uma dependência crescente de credenciais permanentes, difíceis de rastrear e perigosas de manter.
Outro problema é a falsa sensação de segurança provocada pela remoção do segredo do código-fonte. Apagar o arquivo atual não elimina cópias existentes no histórico do Git, em forks, caches, backups, logs ou sistemas de CI/CD. Uma vez exposta, a credencial deve ser considerada comprometida, mesmo que o conteúdo deixe de estar visível.
O vazamento não acontece apenas no GitHub
Repositórios públicos continuam sendo uma fonte relevante de exposição, mas estão longe de ser o único caminho. Segredos podem aparecer em notebooks utilizados para testes, imagens de contêiner, artefatos de compilação, registros de erro, scripts de automação e arquivos de configuração enviados por engano.
O crescimento das plataformas de inteligência artificial também amplia essa superfície. Projetos de machine learning frequentemente compartilham notebooks, conjuntos de dados, arquivos de configuração e exemplos de código. Uma chave inserida em um desses materiais pode ser copiada rapidamente e permanecer disponível mesmo depois de uma correção.
Ambientes de desenvolvimento colaborativo apresentam risco semelhante. Um segredo incluído em uma mensagem de commit, em um pacote publicado ou em um log de execução pode escapar dos controles tradicionais, principalmente quando as equipes utilizam ferramentas diferentes para desenvolver, testar e distribuir aplicações.
O caso da CISA mostra que o risco é concreto
Incidentes envolvendo órgãos públicos e empresas demonstram que credenciais expostas não constituem um problema apenas teórico. Quando uma chave válida é encontrada, o invasor pode testar seu alcance, enumerar recursos, identificar bancos de dados, procurar outras credenciais e estabelecer novas formas de persistência.
Mesmo que a conta não seja imediatamente comprometida, o acesso pode ser utilizado para realizar reconhecimento silencioso. A partir daí, o atacante pode explorar permissões excessivas, falhas de configuração ou relações de confiança entre contas e serviços.
Além do roubo de dados, o abuso de credenciais AWS pode gerar custos inesperados. Um invasor pode criar instâncias para mineração de criptomoedas, aumentar recursos computacionais, transferir grandes volumes de informação ou utilizar a conta como ponto de partida para atacar terceiros.
Como as organizações devem reagir
A primeira medida diante de uma exposição é revogar a credencial, e não apenas removê-la do local onde foi encontrada. A organização deve identificar todas as contas, chaves e serviços relacionados, verificar os registros de uso e procurar sinais de atividade suspeita.
Também é necessário determinar quando ocorreu a exposição e quais operações foram executadas desde então. Logs do CloudTrail, registros de autenticação, alterações no IAM e eventos de faturamento podem ajudar a descobrir se a chave foi utilizada por terceiros.
A resposta deve incluir a revisão das permissões. Mesmo quando a credencial não apresenta sinais de abuso, a organização precisa confirmar se o acesso concedido era realmente necessário. Privilégios amplos devem ser substituídos por permissões específicas, alinhadas à função de cada aplicação.
Outra recomendação é ativar autenticação multifator para acessos humanos e evitar o uso de usuários IAM permanentes sempre que possível. Para workloads, devem ser priorizadas funções IAM e mecanismos de identidade temporária, reduzindo a necessidade de armazenar chaves de longa duração.
Secrets Management precisa acompanhar o DevSecOps
O gerenciamento de segredos não pode ser tratado como uma atividade isolada da equipe de segurança. Ele deve fazer parte de todo o ciclo DevSecOps, desde a criação do código até sua implantação e manutenção.
Ferramentas de detecção podem examinar commits, solicitações de alteração, imagens de contêiner e artefatos de build em busca de padrões associados a chaves e tokens. Entretanto, a automação deve ser acompanhada por processos claros: alertas precisam gerar responsáveis, prazos e ações de remediação.
Os segredos devem ser armazenados em cofres próprios, com criptografia, controle de acesso, auditoria e rotação automatizada. Variáveis protegidas em pipelines são preferíveis à inclusão de credenciais em arquivos do projeto, mas também exigem governança e monitoramento.
A solução passa por reduzir credenciais permanentes
A estratégia mais segura é diminuir a dependência de chaves estáticas. Credenciais temporárias, federação de identidade, funções IAM e autenticação baseada em workload reduzem o período em que um segredo pode ser explorado.
Quando uma chave permanente ainda for indispensável, ela deve ter finalidade bem definida, permissões mínimas, data de expiração e rotação programada. A organização também precisa manter um inventário atualizado, indicando quem criou a credencial, qual sistema a utiliza e quando ela deve ser substituída.
O problema revelado pela pesquisa é, em última análise, uma dívida de identidade. Ambientes cloud podem ter boas ferramentas de proteção, mas continuam vulneráveis quando identidades antigas, excessivamente privilegiadas e sem proprietário permanecem ativas.
A exposição pública deve ser encarada como um incidente de segurança desde o primeiro momento. Detectar o vazamento é importante, mas revogar rapidamente, investigar o uso, limitar privilégios e impedir a recorrência são medidas indispensáveis para reduzir o impacto. Sem esse conjunto de ações, uma chave esquecida pode continuar sendo uma porta aberta para a infraestrutura por meses ou até anos.