O problema real com permissões IAM em escala
Manter o princípio de privilégio mínimo — conceder apenas as permissões estritamente necessárias — é fácil de defender em teoria, mas difícil de sustentar na prática. Quando equipes sobem aplicações na AWS, é comum conceder permissões mais amplas do que o necessário para agilizar a entrega, com a intenção de ajustar depois. Esse “depois” raramente acontece.
Com o tempo, permissões se acumulam. Papéis do AWS Identity and Access Management (IAM) que precisavam de acesso amplo no início do projeto continuam com essas permissões muito depois de deixarem de ser necessárias. Alguns papéis chegam a cair em desuso completo. E revisões manuais não escalam — elas viram um backlog que cresce mais rápido do que qualquer equipe consegue resolver.
A AWS publicou uma solução que trata esse problema de forma sistemática, conectando o AWS IAM Access Analyzer diretamente ao pipeline de CI/CD para automatizar a remediação. Vale entender como ela funciona.
O que o IAM Access Analyzer já faz — e onde ele para
O IAM Access Analyzer já resolve bem a parte de detecção: ele identifica permissões não utilizadas em papéis e usuários IAM, aponta ações que nunca foram executadas, serviços que nunca foram acessados e papéis que nunca foram assumidos. Para cada achado, ele gera uma política recomendada com as permissões em excesso removidas.
O problema está no passo seguinte. Um engenheiro de segurança pode ajustar um papel diretamente no console hoje — mas se esse papel estiver definido em um template do AWS CloudFormation ou em uma stack do AWS Cloud Development Kit (AWS CDK), o próximo deploy restaura as permissões originais. A correção precisa acontecer onde o papel foi definido, e nem todo papel tem a mesma origem.
Alguns papéis são gerenciados por infraestrutura como código (IaC). Outros foram criados manualmente pelo console. E alguns simplesmente não estão sendo usados. Cada cenário exige uma estratégia de remediação diferente.
Visão geral da solução automatizada
A solução proposta pela AWS conecta quatro capacidades: o IAM Access Analyzer para detecção e recomendações de política, o CloudTrail para identificar a origem de cada papel, o Amazon Bedrock para gerar código CDK e explicações em linguagem natural, e o pipeline de CI/CD existente para executar a remediação.
O fluxo funciona assim: um evento agendado no Amazon EventBridge dispara diariamente uma função AWS Lambda orquestradora. Essa função consulta os achados ativos do IAM Access Analyzer, usa o CloudTrail para determinar como cada papel foi criado e, com base nessa classificação, roteia cada achado para um dos três caminhos de remediação.
Os três caminhos de remediação
Papéis gerenciados por IaC — Pull Request automático
Quando o CloudTrail indica que um papel foi criado via CloudFormation ou CDK, a automação identifica o repositório de origem (a partir de uma tag Repository definida no deploy) e abre um pull request nesse repositório. O PR inclui o código CDK gerado pelo Amazon Bedrock implementando exatamente a política recomendada pelo IAM Access Analyzer, um diff mostrando quais permissões estão sendo removidas, e uma explicação em linguagem natural do que muda e por quê.
A equipe dona do papel revisa o PR pelo processo normal de code review. Após o merge, a correção é implantada de forma consistente por todo o pipeline de CI/CD existente. A correção passa a ser permanente — não um ajuste pontual que some no próximo deploy.
Papéis criados manualmente — Issue com orientação
Papéis criados pelo console da AWS ou pela AWS Command Line Interface (AWS CLI) não têm uma representação em código que possa ser atualizada programaticamente. Para esses casos, a automação cria uma issue no sistema de rastreamento de tarefas da equipe contendo a política recomendada pelo IAM Access Analyzer, um diff das mudanças, a explicação gerada pelo Amazon Bedrock e um guia passo a passo para importar o papel para IaC.
Isso oferece um caminho imediato de remediação enquanto incentiva a adoção de IaC a longo prazo.
Papéis sem uso — Desativação controlada
Para papéis que nunca foram assumidos, a automação adota uma abordagem conservadora. Em vez de deletar diretamente, ela cria uma issue recomendando um fluxo de desativação em três etapas: anexar uma política de negação total (deny-all) ao papel, monitorar por 30 dias para confirmar que nenhuma carga de trabalho depende dele, e então deletar.
Essa cautela é proposital. Deletar um papel é irreversível — você perde a política de confiança, as políticas anexadas e qualquer referência em políticas baseadas em recursos. A etapa de desativação suave serve como rede de segurança: se algo quebrar durante o período de monitoramento, remover a política deny-all restaura o acesso imediatamente.
Detalhes técnicos relevantes
Filtragem por exclusões
Antes de processar qualquer achado, a função Lambda carrega uma configuração de exclusões para evitar que a automação tente remediar papéis que legitimamente precisam de permissões amplas. O exemplo abaixo mostra a estrutura dessa configuração:
{
"excluded_roles": [
"arn:aws:iam::123456789012:role/BreakGlassRole",
"arn:aws:iam::123456789012:role/ServiceLinkedRole"
],
"excluded_permissions": [
"iam:*",
"sts:AssumeRole"
],
"excluded_by_tag": {
"NoRemediation": ["true"],
"CriticalService": ["true"]
},
"min_unused_days": 30
}O parâmetro min_unused_days evita falsos positivos com cargas de trabalho sazonais: um papel que executou um job trimestral há 25 dias não vai gerar um achado.
Atribuição de origem via CloudTrail
A função Lambda consulta o evento CreateRole no CloudTrail para classificar a origem de cada papel. Um papel criado via IaC tem o principal de serviço cloudformation.amazonaws.com como identidade. Um papel criado manualmente mostra o tipo IAMUser com agente de usuário console.amazonaws.com ou aws-cli/2.x.x. Essa distinção determina qual dos três caminhos de remediação será seguido.
Geração de código com Amazon Bedrock
Para papéis gerenciados por IaC, a função Lambda recupera a política recomendada pelo IAM Access Analyzer e envia ao Amazon Bedrock para gerar o código CDK em Python. É uma divisão clara de responsabilidades: o IAM Access Analyzer decide o que a política deve conter, e o Amazon Bedrock cuida de como isso se traduz em código CDK pronto para produção.
O código gerado passa por uma etapa de validação antes de entrar em qualquer PR: a função Lambda compila o Python para verificar erros de sintaxe e confirma que os padrões CDK necessários estão presentes. Se a validação falhar, o achado é registrado como erro em vez de gerar um PR com código quebrado.
A solução usa o modelo Anthropic Claude Sonnet no Amazon Bedrock para geração de código (onde precisão é crítica) e o Claude Haiku para as explicações em linguagem natural (onde velocidade e custo importam mais). Os IDs dos modelos são variáveis de ambiente configuráveis.
Suporte a múltiplas contas
A solução funciona tanto em modo de conta única quanto em modo organizacional. No modo organizacional, um analisador ORGANIZATION_UNUSED_ACCESS implantado em uma conta administradora delegada gera achados de todas as contas-membro. A função Lambda extrai o ID da conta do Nome de Recurso da Amazon (ARN) de cada achado e usa um papel entre contas para consultar o CloudTrail e as APIs do IAM na conta de origem.
Controles operacionais e escalabilidade
Na primeira execução em ambientes grandes, o volume de achados pode ser significativo — especialmente com um analisador organizacional. Dois controles de limitação evitam sobrecarregar as equipes: max_findings_per_run (padrão: 50) limita o total de achados de permissões não usadas processados por execução da Lambda, e MAX_UNUSED_ROLE_ISSUES (padrão: 10) limita as issues de papéis sem uso por execução. Os achados restantes são processados na próxima execução agendada.
Para papéis sensíveis — com permissões administrativas ou acesso a dados críticos — é possível configurar o campo approval_required_for_tags nas exclusões. Papéis com essas tags geram issues para revisão manual em vez de PRs automáticos, independentemente de serem gerenciados por IaC.
Após cada execução, a função Lambda publica métricas no Amazon CloudWatch: total de achados processados, papéis classificados como IaC, criados manualmente ou sem uso, PRs e issues criados, e erros de processamento. Acompanhar a proporção entre papéis IaC e manuais ao longo do tempo é um indicador natural da maturidade de governança do ambiente.
Modo dry-run e implantação
Antes de criar PRs e issues reais, é possível executar a automação em modo dry-run configurando "dry_run": true na configuração de CI/CD ou definindo a variável de ambiente CI_CD_PLATFORM como dryrun. Nesse modo, a função processa os achados e classifica os papéis, mas apenas registra o que criaria — sem fazer chamadas reais às APIs do repositório. É o ponto de partida recomendado para validar a acurácia da classificação e ajustar as exclusões antes de ir ao ar.
A solução é distribuída como dois stacks CDK. O repositório GitHub com o código-fonte completo inclui os stacks, templates de configuração e instruções detalhadas de implantação para GitHub e GitLab, além do guia para configuração organizacional entre contas.
Considerações de custo
A solução utiliza Lambda (custo mínimo com execução diária), CloudTrail (geralmente já habilitado), IAM Access Analyzer (cobrado por papel ou usuário IAM analisado por mês para o analisador de acesso não utilizado) e Amazon Bedrock (pagamento por token para geração de código e explicações). O uso de tokens do Amazon Bedrock é a maior variável de custo, escalando com o número de achados processados por dia e a complexidade de cada política. Em implantações organizacionais, o custo do IAM Access Analyzer escala com o número de papéis analisados em todas as contas-membro.
Conclusão
A solução apresentada pela AWS transforma a remediação de permissões IAM de uma tarefa periódica de compliance em uma prática operacional contínua. Ao conectar os achados do IAM Access Analyzer ao pipeline de CI/CD, a correção de permissões excessivas passa a fazer parte do fluxo normal de revisão de código — o mesmo processo que as equipes já seguem.
A abordagem em três caminhos é realista: papéis IaC recebem PRs com código pronto para produção, papéis criados manualmente recebem issues acionáveis com orientação para migrar para IaC, e papéis sem uso seguem um plano de desativação controlada que protege contra interrupções acidentais. Com o tempo, a proporção de papéis gerenciados por código aumenta e a remediação se torna cada vez mais automatizada.
A recomendação é começar com um piloto: escolher 10 a 20 papéis de não-produção, rodar em modo dry-run, revisar os resultados de classificação, ajustar as exclusões e só então habilitar a remediação real. O código-fonte completo está disponível no repositório GitHub.
Fonte
Operationalizing least privilege: Automate IAM remediation through your CI/CD pipeline (https://aws.amazon.com/blogs/security/operationalizing-least-privilege-automate-iam-remediation-through-your-ci-cd-pipeline/)
Leave a Reply