Uma chave de acesso AWS vazada pode comprometer toda a conta: veja o que blinda de verdade

Uma chave de acesso AWS vazada pode comprometer toda a conta: veja o que blinda de verdade

Um access key exposto por engano no GitHub não é só um incidente de código: o estrago depende da política IAM anexada a ele. Veja o que muda na arquitetura quando a defesa vira IAM Roles, Secrets Manager e least privilege.

Nota da redação: este artigo cita alguns detalhes técnicos específicos (uso de IMDSv2 nas instance profiles do EC2 com renovação automática, ferramentas de análise de acesso da AWS, serviços de detecção de ameaças e a recomendação de hook de pre-commit ou etapa de CI/CD para scanner de segredos) que não constam na fonte original usada como base e não puderam ser confirmados em documentação oficial da AWS no momento da apuração. São pontos de apoio ao argumento central, não a tese do artigo, mas recomendamos checar a documentação oficial da AWS antes de se basear neles.

Um require("aws-sdk") com a chave dentro do código

Cenário comum: uma aplicação Node.js fala com o Amazon S3 e, para funcionar rápido, alguém escreve algo como:

const AWS = require("aws-sdk");
const s3 = new AWS.S3({
  accessKeyId: "AKIA...",
  secretAccessKey: "wJalr...",
  region: "ap-south-1"
});

Funciona localmente, passa num code review apressado e vai parar num repositório público no GitHub. É o cenário que o post do AWS Builder Center, publicado em 31 de outubro de 2026 por shelke prathamesh sambhaji, usa para abrir a discussão sobre credenciais vazadas. Apagar o arquivo depois não resolve nada.

A chave continua no histórico do Git, em forks, em caches de scanners automatizados que varrem o GitHub atrás de padrões como AKIA e aws_secret_access_key. Segundo a fonte, a equipe de resposta a incidentes da AWS (Customer Incident Response Team) aponta credenciais expostas como uma das portas de entrada mais recorrentes nos incidentes que investiga. O que o atacante consegue fazer depois depende de uma coisa só: a política IAM anexada àquela credencial.

O problema não é o código, é a identidade

Chave de acesso de usuário IAM é credencial de longo prazo: não expira sozinha, precisa ser rotacionada manualmente, e se ninguém revogar, continua válida indefinidamente. Isso empilha três riscos: permissão excessiva concedida "pra funcionar logo", rotação difícil porque a chave está espalhada em vários deploys, e acesso de longa duração sem data de validade.

Em resumo: o vazamento é só o gatilho. O estrago real é decidido pela política de permissão anexada à credencial no momento em que ela foi comprometida. Uma chave com s3:GetObject escopado a um bucket é um incidente administrável; a mesma chave com AdministratorAccess é a conta inteira na mão de outra pessoa.

IAM Roles em vez de chave fixa: o que muda por serviço

A recomendação da fonte é parar de distribuir credenciais de longo prazo para workloads e usar roles com credenciais temporárias via STS. Cada serviço de computação tem seu mecanismo próprio:

Nenhum desses caminhos exige guardar accessKeyId e secretAccessKey em qualquer lugar do código. O SDK (@aws-sdk/client-s3, por exemplo) obtém a credencial temporária automaticamente a partir do ambiente de execução, sem que o código precise declarar accessKeyId ou secretAccessKey, e a renova antes de expirar.

Em conta única isso resolve metade do problema

O recorte do post é de aplicação isolada. Em ambiente multi-conta, o raciocínio se repete em outra camada: role de aplicação sem chave fixa não resolve sozinha o desenho de permissões entre contas, é preciso também controlar quem pode criar novas credenciais de longo prazo e para onde cada identidade pode assumir outras roles. Isso foge do escopo do post original, mas é uma extensão natural do mesmo princípio.

Para cargas fora da AWS (on-premises, outro provedor) que ainda precisam de credencial AWS, existem mecanismos da própria AWS pensados para evitar chave fixa nesse cenário, mas como a fonte não descreve esse mecanismo em detalhe, vale checar a documentação oficial antes de adotar.

Secrets que não são chave AWS

Nem todo segredo de aplicação é credencial AWS: senha de banco, chave de API de terceiro, token de webhook. Para esses, o AWS Secrets Manager busca o valor em runtime em vez de deixá-lo num .env versionado:

const { SecretsManagerClient, GetSecretValueCommand } = require("@aws-sdk/client-secrets-manager");
const client = new SecretsManagerClient({ region: "ap-south-1" });

async function getSecret() {
  const response = await client.send(
    new GetSecretValueCommand({ SecretId: "production/database" })
  );
  return JSON.parse(response.SecretString);
}

A aplicação ainda precisa de uma role com permissão secretsmanager:GetSecretValue escopada ao ARN do segredo, não a secretsmanager:*. A fonte também cita que o Secrets Manager pode suportar rotação automatizada para segredos compatíveis, com fluxo de rotação configurado, o que ajuda principalmente no caso de senha de RDS e outros segredos que precisam trocar periodicamente sem intervenção manual.

Least privilege na prática, não no discurso

A diferença entre uma política permissiva e uma restrita fica visível lado a lado:

{ "Effect": "Allow", "Action": "s3:*", "Resource": "*" }

contra

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-app-bucket/uploads/*"
}

A segunda não impede vazamento, mas limita o raio de explosão se ele acontecer. Ferramentas de análise de acesso da AWS ajudam a enxugar política existente sem depender só de tentativa e erro ao escrever JSON na mão, mas vale validar na documentação oficial o alcance exato de cada uma antes de assumir o que ela cobre.

Quando a chave já vazou

Apagar o commit não é resposta a incidente. A sequência que a fonte recomenda, e que vale ter documentada antes de precisar dela, é:

1. Desativar ou revogar a chave exposta imediatamente, sem esperar confirmação de uso indevido.
2. Revisar eventos de CloudTrail da identidade comprometida, procurando chamadas fora do padrão normal.
3. Checar criação inesperada de usuários IAM, roles, políticas ou infraestrutura (instâncias EC2 para mineração, por exemplo).
4. Remover o segredo do repositório e do histórico do Git.
5. Rotacionar qualquer outra credencial que possa ter sido exposta junto.
6. Substituir a chave fixa por role e credencial temporária, para o mesmo incidente não se repetir com uma chave nova.

Serviços de detecção de ameaças da AWS podem complementar esse processo automatizando parte da sinalização de uso anômalo, mas vale confirmar o escopo exato de cada um na documentação oficial antes de montar o processo de resposta em torno deles.

O que entra no pipeline antes do merge

A prevenção mais barata não é revisão manual de código, é scanner automatizado no pipeline. A fonte recomenda genericamente escanear repositórios atrás de segredos expostos antes que cheguem ao remoto, seja via hook de pre-commit, seja via etapa de build no pipeline de CI/CD; o mecanismo específico varia conforme a ferramenta escolhida, e vale checar a documentação de cada uma antes de adotar. Nenhuma camada substitui a outra: scanner pega o que já foi escrito errado, role sem chave fixa evita que exista chave pra vazar.

Onde a prática emperra

Nem toda aplicação legada migra para role da noite para o dia. Workload de terceiro que só aceita accessKeyId/secretAccessKey, script batch fora da AWS sem suporte a mecanismos de credencial temporária, ou SaaS que exige chave estática para integração são situações reais onde a chave de longo prazo ainda é necessária. Nesses casos, o paliativo é tratar a chave como o segredo mais sensível que existe: dentro do Secrets Manager, com rotação programada, política escopada a uma única ação e um único recurso, e alarme de CloudTrail disparando no primeiro uso fora do IP esperado.

Fonte

Fonte 1: AWS Builder Center, "Your AWS Credentials Are More Dangerous Than You Think: One Leaked Key Can Expose Your Cloud", por shelke prathamesh sambhaji, publicado em 31 de outubro de 2026 (https://builder.aws.com/content/3LREP8VyVaeZM2kKsxbd7SzEPAb/your-aws-credentials-are-more-dangerous-than-you-think-one-leaked-key-can-expose-your-cloud).

Fonte: AWS Builder Center