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 pontual de desenvolvimento. O risco, porém, cresce significativamente quando essa credencial permanece válida após a exposição e continua esquecida durante meses ou até anos.
Uma pesquisa da Truffle Security identificou milhares de credenciais AWS disponibilizadas publicamente que ainda podiam ser usadas para autenticação. O levantamento reforça que apagar uma chave de um repositório não elimina automaticamente a ameaça. Se a credencial não for revogada ou substituída, ela pode continuar funcionando mesmo depois de removida do local original.
Durante a investigação, foram encontradas 64.024 chaves AWS únicas. Em uma etapa mais detalhada, realizada em 10 de agosto de 2026, os pesquisadores analisaram novamente 10.616 conjuntos completos de credenciais. Aproximadamente 88% ainda conseguiam autenticar-se nos ambientes correspondentes.
Esse resultado mostra que o problema não envolve somente chaves antigas, abandonadas ou já desativadas. Uma parcela expressiva das credenciais expostas continuava tecnicamente operacional e poderia ser utilizada para acessar serviços, aplicações, dados e recursos corporativos hospedados na nuvem.
O risco depende das permissões associadas
Uma AWS Access Key não é apenas uma sequência de caracteres. Ela representa uma identidade técnica usada por aplicações, scripts, ferramentas de automação e serviços para acessar a infraestrutura da AWS. O alcance dessa identidade é definido pelas políticas configuradas no Identity and Access Management, o IAM.
Por isso, identificar uma credencial vazada é apenas o começo da investigação. O ponto central é descobrir quais ações podem ser executadas com ela. Uma chave limitada a consultar determinados objetos pode causar um impacto restrito. Já uma credencial com privilégios administrativos pode permitir alterações de infraestrutura, acesso a informações sensíveis, criação de novos usuários e movimentação dentro do ambiente.
A pesquisa encontrou centenas de credenciais associadas a níveis elevados de privilégio. Foram identificadas 526 root access keys e 242 credenciais vinculadas a usuários IAM com a política AdministratorAccess. Ao todo, 768 casos apresentavam capacidades administrativas relevantes.
As chaves root são especialmente perigosas porque estão ligadas diretamente à conta AWS e possuem poderes amplos sobre sua configuração. Na prática, uma credencial desse tipo pode permitir mudanças críticas, dificultar a investigação de incidentes e ampliar rapidamente o controle de um invasor sobre a conta.
Rotação de credenciais ainda é negligenciada
O tempo de permanência das chaves expostas revela uma falha recorrente nos processos de segurança. Algumas credenciais permaneceram utilizáveis por mais de cinco anos, indicando que muitas organizações não possuem mecanismos consistentes para expiração, rotação e revogação.
A rotação periódica reduz a janela de oportunidade para exploração. Quando uma chave é substituída regularmente, mesmo que seja publicada por engano, sua validade tende a ser limitada. O problema é que muitas equipes ainda tratam a rotação como uma tarefa manual, dependente de lembretes ou da percepção de um profissional.
Esse modelo é frágil. Credenciais usadas por pipelines, aplicações e integrações podem permanecer ativas porque ninguém quer interromper um serviço em produção. Sem inventário, documentação e automação, a equipe frequentemente deixa de saber onde uma chave é utilizada e quais sistemas seriam afetados por sua substituição.
O vazamento de secrets não acontece apenas em repositórios
O GitHub continua sendo uma fonte importante de exposição, mas está longe de ser o único lugar onde segredos aparecem. Tokens e chaves também podem ser encontrados em imagens de contêiner, arquivos de configuração, artefatos de compilação, backups, logs, notebooks de ciência de dados e pacotes distribuídos internamente.
Ambientes de inteligência artificial ampliaram essa superfície. Plataformas de compartilhamento de modelos, conjuntos de dados e notebooks podem conter variáveis de ambiente, tokens de APIs e credenciais inseridas durante testes. Quando esses arquivos são publicados sem uma revisão adequada, o segredo pode tornar-se acessível a qualquer pessoa.
Além disso, um segredo removido posteriormente pode continuar presente no histórico de versões, em forks, caches, espelhos e cópias locais. Por essa razão, a exclusão visual do arquivo não deve ser confundida com a eliminação da credencial.
Apagar o segredo publicado não resolve o incidente
Quando uma chave é descoberta em um repositório público, a primeira providência deve ser revogá-la ou desativá-la. Depois, a organização precisa emitir uma nova credencial com escopo reduzido, avaliar os registros de uso e verificar se houve atividade suspeita.
A análise deve incluir logs do CloudTrail, alterações no IAM, criação de usuários, modificações em grupos de segurança, acesso a buckets, execução de instâncias e movimentações incomuns de dados. Mesmo que não existam sinais imediatos de abuso, a credencial deve ser considerada comprometida.
Também é importante identificar a origem do vazamento. O segredo foi inserido por um desenvolvedor? Veio de uma variável mal configurada? Estava presente em uma imagem de contêiner? Foi incluído em um log? Sem corrigir a causa, a mesma falha pode gerar novos incidentes.
Como reduzir a exposição
A medida mais segura é diminuir a dependência de credenciais permanentes. Sempre que possível, aplicações devem utilizar funções IAM, perfis de instância, identidades federadas e tokens temporários. Esses mecanismos reduzem a necessidade de armazenar chaves fixas em código ou arquivos de configuração.
Quando uma credencial permanente for inevitável, ela deve ter permissões mínimas, prazo definido, proprietário identificado e rotação automatizada. A autenticação multifator deve proteger as contas administrativas, enquanto o acesso root precisa ser excepcional e monitorado.
Ferramentas de detecção de secrets podem ser integradas ao ciclo de desenvolvimento para examinar commits, pull requests, imagens e artefatos antes da publicação. Entretanto, a automação não substitui controles de identidade: encontrar uma chave é útil, mas revogá-la rapidamente é essencial.
Secrets Management precisa acompanhar o DevSecOps
O gerenciamento de segredos deve fazer parte de todo o ciclo de vida do software. As equipes precisam definir como os segredos são criados, armazenados, distribuídos, utilizados, rotacionados e eliminados.
Cofres de segredos, políticas de acesso baseadas em função, registros de auditoria e alertas de uso anormal ajudam a controlar esse processo. Variáveis sensíveis não devem ser armazenadas diretamente no código, em arquivos de configuração compartilhados ou em sistemas de tickets.
Também é necessário estabelecer responsabilidades claras. O time de desenvolvimento deve saber como consumir uma credencial com segurança; a equipe de operações precisa acompanhar sua validade; e a área de segurança deve verificar permissões, exposição e comportamento de uso.
O problema é uma dívida de identidade
A permanência de credenciais expostas por anos demonstra mais do que um erro isolado. Ela revela uma dívida de identidade: usuários técnicos antigos, permissões excessivas, chaves sem proprietário, contas de serviço abandonadas e processos de desligamento incompletos.
Essa dívida se acumula silenciosamente. Quanto maior o ambiente, mais difícil se torna identificar quais credenciais ainda são necessárias, quem as utiliza e quais privilégios podem ser removidos.
Para reduzir esse risco, as organizações devem manter um inventário atualizado de identidades humanas e não humanas, revisar permissões periodicamente e eliminar contas e chaves sem uso. A segurança da nuvem depende tanto da proteção dos dados quanto da governança das identidades que conseguem alcançá-los.
Recomendações para as organizações
– Revogar imediatamente qualquer credencial encontrada em fonte pública.
– Investigar o histórico de uso antes e depois da exposição.
– Substituir chaves permanentes por identidades temporárias sempre que possível.
– Aplicar o princípio do menor privilégio no IAM.
– Bloquear o uso cotidiano da conta root.
– Automatizar a rotação e a expiração de credenciais.
– Monitorar repositórios, contêineres, notebooks, logs e artefatos de CI/CD.
– Utilizar cofres centralizados para armazenar secrets.
– Integrar scanners de credenciais ao processo de desenvolvimento.
– Treinar as equipes para reconhecer e comunicar vazamentos rapidamente.
A existência de milhares de credenciais AWS expostas e ainda ativas mostra que o vazamento é apenas o primeiro estágio do problema. O perigo real está no tempo durante o qual a chave permanece válida, nas permissões que ela carrega e na ausência de monitoramento sobre sua utilização. Organizações que combinam identidades temporárias, menor privilégio, rotação automatizada e resposta rápida conseguem reduzir drasticamente a possibilidade de um erro de desenvolvimento transformar-se em um comprometimento amplo da nuvem.