*Por Natalian Silva
O vazamento de milhares de chaves de acesso da Amazon Web Services (AWS) chama atenção não apenas pela exposição das credenciais, mas pelo que acontece antes e depois dela. Para entender a dimensão do problema, é necessário separar conceitos como identidade, autenticação, autorização e privilégio, além de observar como as empresas administram essas estruturas ao longo do tempo. A computação em nuvem permite que servidores, armazenamento, bancos de dados, redes e outros recursos tecnológicos sejam utilizados sob demanda pela internet. Em vez de manter toda essa infraestrutura fisicamente dentro da empresa, organizações recorrem a provedores como Amazon Web Services, Microsoft Azure e Google Cloud. Esses ambientes podem armazenar desde arquivos e cópias de segurança até sistemas financeiros, bases de clientes, aplicações críticas, plataformas de inteligência artificial e outros componentes essenciais para a operação de uma empresa. Recursos também podem ser criados, alterados e ampliados rapidamente por meio de comandos e processos automatizados.
Essa flexibilidade mudou a lógica da segurança digital. Durante muitos anos, o modelo tradicional esteve associado à ideia de um perímetro protegido, com servidores dentro de um datacenter e firewalls separando o ambiente interno do externo. Na nuvem, pessoas, aplicações, scripts, ferramentas de desenvolvimento e processos automatizados podem administrar recursos remotamente. Com isso, a segurança passa a depender cada vez mais da identidade apresentada ao sistema e das permissões atribuídas a ela.
O modelo de responsabilidade compartilhada ajuda a entender essa divisão. O provedor é responsável pela proteção da infraestrutura que sustenta os serviços de nuvem, incluindo datacenters, redes físicas, hardware e determinadas camadas tecnológicas. O cliente, por outro lado, continua responsável pela configuração do próprio ambiente. Isso inclui definir quem pode acessar os recursos, quais permissões cada identidade possui, onde as credenciais são armazenadas e quais mecanismos de monitoramento e resposta a incidentes estão ativos. A utilização de um grande provedor, portanto, não transfere para ele toda a responsabilidade pela segurança. Se uma empresa cria uma credencial, a coloca em um repositório público e a mantém ativa durante anos, a falha está ligada à forma como aquele acesso foi administrado, mesmo que a infraestrutura do provedor não tenha sido comprometida.
Identidade é a representação de uma pessoa, aplicação, máquina, serviço ou processo dentro de um sistema. Autenticação é o mecanismo utilizado para comprovar essa identidade. Autorização define o que ela poderá fazer depois de autenticada. Um funcionário pode acessar um sistema utilizando usuário, senha e autenticação multifator. Uma aplicação pode utilizar uma chave, certificado ou credencial temporária. Depois disso, políticas de acesso determinam se aquela identidade poderá apenas consultar informações ou se também poderá modificar bancos de dados, criar servidores, administrar usuários ou controlar uma conta inteira.
Essa diferença é importante para entender o caso envolvendo as credenciais da AWS. Uma chave permite autenticar uma identidade em determinadas chamadas programáticas, mas o impacto de seu vazamento depende dos privilégios associados a ela. Uma chave com permissões restritas e validade curta representa um risco diferente de uma credencial permanente ligada ao usuário root ou a uma conta com privilégios administrativos.
Credencial de acesso é um conceito amplo. Senhas, passkeys, certificados, tokens de sessão e chaves de acesso são exemplos de mecanismos usados para autenticar uma identidade. Na AWS, uma access key destinada ao acesso programático possui duas partes: o Access Key ID, que funciona como identificador, e a Secret Access Key, que deve permanecer confidencial. As duas são utilizadas para autenticar requisições realizadas por APIs, ferramentas de linha de comando e kits de desenvolvimento. Esse tipo de chave não deve ser confundido com a senha utilizada para entrar no console da AWS, nem com chaves de criptografia ou chaves SSH. Apesar de todos esses mecanismos serem chamados de chaves, suas funções são diferentes.
Também existem diferenças entre credenciais permanentes e temporárias. Chaves vinculadas a usuários IAM ou ao usuário root podem continuar válidas até serem desativadas ou excluídas. Credenciais temporárias, geralmente emitidas por meio de roles e do AWS Security Token Service, expiram após um período determinado. Por esse motivo, a AWS recomenda o uso de roles e credenciais temporárias sempre que possível.
Uma forma simples de visualizar essa estrutura é pensar em um crachá. A credencial identifica quem está tentando acessar determinado ambiente. As políticas de acesso definem quais portas esse crachá consegue abrir. Se uma credencial vazada permite acesso somente a um recurso específico, o alcance do incidente tende a ser menor. Se a mesma credencial permite administrar usuários, modificar permissões, criar novos acessos e controlar toda a infraestrutura, o vazamento passa a representar um risco estrutural. É aí que entra o princípio do menor privilégio: cada identidade deve possuir apenas as permissões necessárias para executar sua função e somente durante o período necessário. A exposição da credencial pode iniciar o incidente, mas o excesso de privilégios determina até onde ele pode chegar. O cenário se torna mais grave quando quatro elementos aparecem simultaneamente: credencial exposta, privilégios excessivos, validade prolongada e ausência de monitoramento.
Muitas chaves de acesso existem porque aplicações, scripts, pipelines de desenvolvimento, ferramentas de integração e processos automatizados precisam se comunicar diretamente com serviços de nuvem. São as chamadas identidades não humanas, ou NHI, sigla em inglês para Non-Human Identities. O avanço da automação e da inteligência artificial aumentou rapidamente o número dessas identidades. Em alguns ambientes, uma organização pode ter mais identidades associadas a máquinas e aplicações do que funcionários.
O problema aparece quando essas credenciais são administradas de forma informal e acabam inseridas em códigos, arquivos de configuração, variáveis de ambiente, imagens de contêineres ou conjuntos de dados utilizados no desenvolvimento de sistemas e modelos de inteligência artificial. Sem inventário, proprietário, finalidade, prazo de validade e revisão periódica, torna-se difícil responder a perguntas básicas: quem criou determinada credencial, qual aplicação depende dela, que recursos ela pode acessar e o que acontece se ela for revogada. Essa falta de visibilidade ajuda a explicar por que credenciais antigas podem continuar funcionando mesmo depois de terem sido expostas.
Identidades não humanas também nem sempre seguem processos equivalentes aos aplicados aos funcionários. Uma pessoa costuma passar por processos de admissão, mudança de função e desligamento. No caso de uma aplicação, um projeto pode terminar ou um fornecedor pode deixar de participar da operação sem que as credenciais associadas sejam eliminadas. Por isso, identidades não humanas também precisam ter responsáveis, finalidade documentada e ciclo de vida definido.
Um levantamento da Truffle Security analisou 431.875 ocorrências públicas de credenciais da AWS encontradas entre agosto de 2022 e agosto de 2026 em históricos de código, conjuntos de dados do Hugging Face, imagens de contêineres, registros de integração contínua e outros artefatos. Após a remoção das duplicidades, foram identificadas 64.024 chaves únicas relacionadas a 50.654 contas. Em uma nova verificação realizada em agosto de 2026 sobre 10.616 pares completos, 88% ainda conseguiam autenticar.
Entre as chaves ativas relacionadas a empresas, 768 ofereciam controle total sobre contas corporativas. Desse total, 526 eram credenciais root e 242 estavam vinculadas a usuários IAM com a política AdministratorAccess. O levantamento também encontrou 130 chaves root ainda ativas em contas centrais utilizadas para gerenciamento de organizações, situação que poderia ampliar o alcance de um comprometimento para diferentes contas subordinadas.
A idade das credenciais também chama atenção. Entre 2.903 chaves cuja data de criação pôde ser verificada, a idade mediana era de 1.831 dias, aproximadamente cinco anos. Em 86% desses casos, não havia indicação de que uma chave mais recente tivesse substituído a credencial exposta. A chave mais antiga ainda ativa tinha 17,4 anos.
Os dados não indicam que a infraestrutura central da Amazon Web Services tenha sido invadida para a obtenção dessas chaves. As credenciais foram encontradas em locais publicamente acessíveis e, em muitos casos, estavam relacionadas a práticas inseguras de armazenamento, desenvolvimento e compartilhamento de código e dados. Essa distinção é importante porque revela outro problema: a superfície de exposição das credenciais deixou de estar concentrada em um único ambiente.
Uma chave inserida em um repositório pode continuar disponível no histórico mesmo depois de o arquivo original ser apagado. Ela também pode ser copiada para imagens, pacotes, conjuntos de dados ou outras estruturas utilizadas por equipes e sistemas automatizados. Apagar uma linha de código, portanto, não significa revogar a credencial. Se uma chave comprometida continua válida, um invasor pode utilizá-la para se apresentar ao ambiente como uma identidade legítima.
A chave, por si só, não determina o alcance do ataque. O problema está nas permissões concedidas à identidade associada. Se a credencial permanecer ativa e está vinculada a privilégios administrativos, um invasor pode utilizar as permissões existentes para acessar ou apagar dados, criar recursos, alterar políticas, gerar novas credenciais, interromper serviços ou criar mecanismos de permanência no ambiente.
As credenciais root representam um risco ainda maior. O usuário root possui acesso amplo aos serviços, recursos e informações de cobrança de uma conta AWS. Por isso, a própria AWS recomenda que não sejam criadas access keys para esse usuário. A existência de centenas de chaves root expostas e ainda funcionais mostra como controles básicos de identidade podem permanecer ausentes mesmo em ambientes utilizados para operações relevantes.
Os impactos também não se limitam ao vazamento de informações. Recursos computacionais podem ser usados para mineração de criptomoedas ou hospedagem de infraestrutura maliciosa, enquanto alterações de sistemas podem provocar indisponibilidade, afetar backups ou gerar custos elevados. Segundo o levantamento, somente 9,5% das contas cuja configuração de orçamento pôde ser consultada tinham algum alerta de gastos configurado.
Uma chave não é necessariamente insegura apenas por ser antiga. O problema surge quando ela permanece ativa durante anos sem uma justificativa clara, revisão de privilégios, rotação, substituição ou acompanhamento. Credenciais permanentes podem sobreviver ao projeto que levou à sua criação, à aplicação que foi desativada e até às equipes originalmente responsáveis por elas.
Como determinados sistemas podem depender dessas credenciais, existe também uma resistência em revogá-las por medo de provocar interrupções. Aos poucos, surge uma espécie de dívida de identidade: acessos que continuam ativos porque ninguém consegue determinar com segurança para que ainda servem. A simples rotação periódica não elimina todo o risco. Trocar uma chave permanente reduz sua janela de exposição, mas continua exigindo armazenamento e distribuição de um segredo de longa duração. Sempre que houver alternativa, a redução estrutural desse risco passa pela substituição de credenciais permanentes por roles e credenciais temporárias, com validade curta e permissões limitadas ao contexto em que serão utilizadas.
Em ambientes de nuvem, uma pessoa pode administrar recursos a partir de outro país, uma aplicação pode consultar bancos de dados automaticamente, um pipeline pode criar infraestrutura em segundos e um agente de inteligência artificial pode executar ações em nome de uma organização. Em todos esses casos existe um elemento em comum: uma identidade recebe autorização para fazer alguma coisa.
Controles de rede continuam sendo necessários, mas já não bastam. É preciso saber quais identidades existem, quem responde por elas, quais mecanismos utilizam para autenticação, quais privilégios possuem e quais relações de confiança podem explorar. Essa lógica vale tanto para pessoas quanto para aplicações, máquinas e agentes automatizados. Uma máquina não muda de emprego ou tira férias, mas a aplicação que ela representa pode ser substituída, o projeto pode ser encerrado e sua credencial pode acabar copiada para diversos ambientes.
Quando uma credencial é publicada, inclusive em históricos de alteração de código, ela deve ser tratada como comprometida. Remover a chave do arquivo ou apagar o repositório não elimina cópias que possam ter sido feitas anteriormente. O primeiro passo é desativar ou revogar a credencial e preservar os registros necessários para uma investigação. Depois, é preciso analisar a atividade relacionada àquela identidade, procurando acessos incomuns, mudanças de privilégio, criação de novos usuários ou credenciais e possíveis mecanismos utilizados para manter acesso ao ambiente.
Também é necessário identificar outros locais onde a mesma credencial possa ter sido armazenada e verificar quais sistemas dependiam dela. Existe um equilíbrio operacional nessa resposta. Uma revogação feita sem conhecer as dependências pode interromper sistemas importantes. Ao mesmo tempo, manter ativa uma chave que já foi exposta significa continuar confiando em uma credencial que deixou de ser secreta.
A redução desse risco começa pela visibilidade. Usuários, roles, chaves, tokens, secrets e identidades não humanas precisam ter responsáveis definidos, finalidade documentada, ambiente associado e prazo para revisão ou expiração. Credenciais root também devem receber atenção específica. Access keys associadas ao usuário root devem ser removidas e tarefas administrativas precisam utilizar mecanismos de acesso mais controlados.
Outro ponto é a adoção de credenciais temporárias. Roles e mecanismos de federação podem reduzir a dependência de segredos permanentes, já que essas credenciais deixam de funcionar automaticamente ao final de sua validade. O princípio do menor privilégio também deve ser aplicado de forma contínua. Permissões precisam ser revistas com base no uso real, eliminando acessos desnecessários. Uma aplicação não deveria permanecer com AdministratorAccess apenas porque essa configuração facilitou seu desenvolvimento no início do projeto.
A detecção de segredos também precisa fazer parte do processo de desenvolvimento. Ferramentas de secret scanning podem ser integradas a commits, pipelines, logs, imagens de contêineres, pacotes, conjuntos de dados e repositórios para identificar credenciais expostas e impedir que novas chaves sejam incluídas no código.
Monitoramento é outro ponto importante. Criação de usuários e chaves, alterações de privilégio, acessos a dados, mudanças de região e crescimento inesperado do consumo podem indicar comportamento anormal. Alertas de orçamento ajudam a identificar aumentos de custos provocados por uso indevido da infraestrutura, mas precisam fazer parte de uma estratégia mais ampla de monitoramento de identidade e resposta a incidentes.
Aplicações, serviços, automações e agentes de inteligência artificial também precisam entrar formalmente nos processos de criação, revisão e revogação de acessos. Identidades não humanas não podem ser tratadas como uma exceção à governança utilizada pela empresa.
O vazamento de uma credencial pode iniciar um incidente, mas as práticas de governança determinam sua dimensão. Quando credenciais possuem validade curta, privilégios limitados e monitoramento adequado, o impacto de uma exposição pode ser reduzido. Quando continuam funcionando durante anos e carregam permissões administrativas, uma falha inicialmente pequena pode comprometer uma parcela significativa da infraestrutura digital de uma empresa.
Os dados sobre as chaves AWS expostas não mostram apenas problemas de armazenamento de segredos. Eles apontam falhas no ciclo de vida dos acessos, excesso de privilégios, falta de visibilidade sobre identidades não humanas e dificuldade para eliminar credenciais cuja necessidade já não pode ser claramente justificada.
A computação em nuvem ampliou a velocidade e a flexibilidade das operações, mas também multiplicou a quantidade de identidades, integrações e credenciais que precisam ser administradas. Nesse cenário, uma sequência de caracteres deixada em um repositório público pode se transformar em uma porta de entrada para sistemas, dados e recursos de uma organização.
O perímetro de segurança não desapareceu com a nuvem. Ele se tornou mais distribuído e cada vez mais dependente de identidade. Proteger ambientes de cloud exige não apenas ferramentas de infraestrutura e controles de rede, mas mecanismos capazes de responder continuamente a três perguntas: quem ou o que possui acesso, por qual motivo e por quanto tempo.
O princípio do menor privilégio pode determinar se o vazamento de uma credencial termina em um acesso limitado ou evolui para um comprometimento de grandes proporções.
*Natalian Silva é cofundadora da IAM Brasil e do CEC IAM Academy.
Fontes consultadas: Truffle Security — 768 Leaked Corporate AWS Keys Held Full Admin Rights; TecMundo — AWS: chaves de acesso vazadas dão controle total sobre contas corporativas na nuvem; AWS — O que é cloud computing?; AWS IAM — Gerenciamento de access keys para usuários IAM; AWS IAM — Credenciais de segurança; AWS IAM — Boas práticas de segurança; AWS — Modelo de responsabilidade compartilhada; AWS IAM — Boas práticas para o usuário root.
