Quarentena de chaves da AWS não equivale a revogação, aponta Truffle Security

Segundo a Truffle Security, quando uma chave AWS vaza, a AWS pode anexar ao usuário IAM dono dela uma política de quarentena. Ela é só uma lista de ações negadas e deixa a chave ativa. Subir uma nova instância EC2 está na lista. Ler um secret ou apagar um banco, não. Se o usuário já tem permissão para essas ações, ela continua valendo.

A AWS lançou três versões da política: a original em 2020, a V2 em 2021 e a V3 em 2024. Anexar a original não dá as restrições da V2 ou da V3. No conjunto analisado, 738 chaves tinham uma política antiga sem a V3. V2 e V3 negam s3:GetObject, mas não s3:GetObjectVersion, que permite baixar uma versão específica do objeto, inclusive a atual, se o ID da versão for informado. Também ficam de fora sts:AssumeRole, ssm:SendCommand, ssm:StartSession, leitura de tabelas DynamoDB, compartilhamento de snapshots RDS e EBS, Lambda GetFunction e kms:Decrypt. A própria Truffle ressalva que não testou essas operações e que políticas customizadas e outros controles alteram o acesso efetivo.

Em campo, a Truffle achou 929 chaves ainda autenticando com quarentena listada, em 909 contas. Em 894 delas, as políticas continham permissões perigosas fora da lista de negação. A idade mediana das chaves era de 3,6 anos, a mais velha tinha 12,3 anos e 231 tinham ao menos cinco anos.

O tema conecta com a cobertura anterior sobre as mesmas pesquisas da Truffle. Em 24 de agosto de 2026, o CEVIU noticiou "Alerta Crítico: Centenas de Chaves AWS Vazadas Oferecem Acesso Total a Contas Corporativas", sobre chaves antes expostas que seguiam ativas. Em 5 de outubro de 2026, em "Meio milhão de credenciais expostas e sem revogação, aponta análise", o foco eram credenciais válidas em repositórios públicos do GitHub. Agora a análise olha o que acontece depois da detecção pela AWS: a quarentena existe, mas cobre só parte das ações e não revoga a chave.

Para quem opera ambientes AWS, a leitura é que ver a quarentena anexada a um usuário IAM não encerra o incidente. Faz sentido tratar a chave como comprometida, rotacionar ou desativar, e revisar o que o usuário podia fazer, inclusive acesso a secrets, SSM e versões de objetos S3. Vale conferir também quais usuários têm só a política original ou a V2.