Organizando AWS Access Keys por causa do ISMS: migração para autenticação baseada em Role

Este é um texto que resume a experiência de migrar para autenticação baseada em Role ao revisar as Access Keys acumuladas em uma conta AWS durante o processo de resposta à auditoria posterior do ISMS.

Contexto de adoção

• Ao olhar o console do IAM, as Access Keys estavam espalhadas por vários lugares (CI/CD, scripts de deploy, desenvolvimento local etc.), e era difícil rastrear onde e como estavam sendo usadas
• As Access Keys permanecem válidas sem expiração e, se forem comprometidas, os privilégios concedidos ficam expostos exatamente como estão, o que gerava um risco elevado
• A própria AWS também recomenda usar credenciais temporárias (Role/STS) em vez de credenciais de longo prazo (Access Key)

Problema

• Como as chaves eram copiadas e usadas em vários lugares, era difícil responder à pergunta: “se esta chave for comprometida, até onde vai o impacto?”
• Para fazer rotação, era preciso mudar ao mesmo tempo configurações espalhadas, e como vários privilégios para usos diferentes ficavam reunidos em um único IAM User, era difícil aplicar o princípio do menor privilégio
• Na época, um único IAM User para CI/CD concentrava de uma vez permissões de deploy em ECR/S3/SSM/ECS e outras mais

Forma adotada na migração (resumo)

• Assume Role: método de tomar emprestadas temporariamente as permissões de outra Role no momento necessário
• OIDC Web Identity: método de obter uma Role com a identidade de um sistema externo, como GitHub Actions/EKS (=IRSA)
• Instance Profile: método de anexar diretamente uma Role a EC2/Lambda etc. para que o serviço receba permissões automaticamente

Processo real de migração

• Etapa 1: separar, por finalidade, as permissões do IAM User que tinha políticas amplas em Roles diferentes (push/pull no ECR, deploy no ECS, cache no S3 etc.)
• Etapa 2: aplicar OIDC ao GitHub Actions (registrar o Identity Provider → limitar o escopo do repositório com condições na Trust Policy → usar configure-aws-credentials no workflow)

Efeitos

• Remoção de Access Keys do código e dos segredos; como a base passou a ser tokens temporários, mesmo em caso de comprometimento o impacto fica limitado pela expiração
• O esforço de rotação de chaves desapareceu, e o rastreamento de permissões por workflow/tarefa ficou mais claro

Pontos de atenção

• Não definir condições amplas demais na Trust Policy; restringir ao menor escopo possível (org/repo e, se possível, até a branch)
• Não excluir imediatamente as Access Keys existentes; após a migração, deixar um período de desativação/validação antes de removê-las