Pular para o conteúdo
AWS Security10 min de leituraAtualizado em 30 de maio de 2026

Segurança IAM na AWS: boas práticas para reduzir permissões excessivas

IAM é onde os incidentes em nuvem mais começam. Veja como aplicar menor privilégio, controlar credenciais e revisar acessos de forma sustentável.

Identidade é o novo perímetro. Na AWS, a maioria dos caminhos de ataque relevantes passa por permissões amplas demais: uma role com acesso administrativo usada por uma aplicação, uma access key antiga vazada em um repositório ou um usuário com políticas acumuladas que ninguém revisou. Quando o IAM está frouxo, um único ponto de entrada vira comprometimento de toda a conta.

Este guia mostra como estruturar o IAM com menor privilégio de forma prática, sem travar a operação. O objetivo é reduzir o raio de impacto de qualquer credencial comprometida e tornar o acesso auditável, em vez de buscar uma configuração perfeita e impossível de manter.

Menor privilégio na prática

Menor privilégio significa conceder apenas as permissões necessárias para uma tarefa específica e nada além. Na prática, isso começa por evitar políticas como AdministratorAccess em uso cotidiano e por preferir roles temporárias a credenciais de longa duração. Aplicações em EC2, ECS ou Lambda devem assumir roles, nunca carregar access keys embutidas.

Use condições para restringir o contexto de uso. Um exemplo comum é exigir MFA para ações sensíveis ou limitar uma role a uma origem de rede ou a uma tag específica. Condições bem aplicadas reduzem o valor de uma credencial roubada, porque ela só funciona dentro do contexto esperado.

Trecho de política exigindo MFA para ações sensíveis
"Condition": {
  "BoolIfExists": { "aws:MultiFactorAuthPresent": "true" }
}

Credenciais, MFA e federação

Access keys de longa duração são o ativo mais perigoso do IAM. Elas vazam em repositórios, logs e imagens de contêiner e não expiram sozinhas. Prefira o IAM Identity Center para acesso humano federado, com sessões temporárias, e roles para acesso de máquina. Quando uma access key for inevitável, faça rotação periódica e monitore o último uso.

MFA deve ser obrigatório para a conta root e para todo acesso humano com privilégio. A conta root não deve ter access keys e só deve ser usada para tarefas que exigem o root, com MFA forte e credenciais guardadas de forma segura.

Revisão contínua de permissões

Permissões só crescem se ninguém as revisar. Use o IAM Access Analyzer para identificar acessos externos não intencionais e o histórico de last accessed para encontrar permissões concedidas e nunca usadas. Políticas que nunca foram exercidas são candidatas naturais a remoção.

  • Prefira políticas gerenciadas pela organização a inline espalhadas
  • Use permission boundaries para limitar o teto de quem cria roles
  • Aplique SCPs na organização para vedar ações perigosas em toda a estrutura
  • Trate wildcards em Action e Resource como exceção justificada, não padrão

Checklist prático

  • Habilitar MFA na conta root e remover access keys do root
  • Exigir MFA para acesso humano com privilégio
  • Substituir usuários com access keys por federação via IAM Identity Center
  • Fazer aplicações assumirem roles em vez de carregar access keys
  • Eliminar uso cotidiano de AdministratorAccess
  • Aplicar permission boundaries para quem cria identidades
  • Definir SCPs para vedar ações perigosas na organização
  • Rever permissões com last accessed e remover o que nunca foi usado
  • Rodar IAM Access Analyzer para detectar acesso externo não intencional
  • Rotacionar e monitorar access keys que ainda existam

Boas práticas

  • Modele acessos por papel e função, não por pessoa individual
  • Use condições (MFA, origem, tag) para restringir o contexto das roles
  • Prefira sessões temporárias a credenciais de longa duração
  • Documente o motivo de qualquer permissão ampla que precise existir
  • Versione e revise políticas como código, com aprovação
  • Monitore criação de usuários, chaves e mudanças de política no CloudTrail

Erros comuns

  • Aplicações usando access keys embutidas

    A chave vaza em repositório ou imagem e dá acesso persistente difícil de detectar.

  • AdministratorAccess para tarefas do dia a dia

    Qualquer comprometimento vira controle total da conta.

  • Conta root com access keys ativas

    Expõe o nível mais alto de privilégio, sem possibilidade de limitar por política.

  • Wildcards em Action e Resource como padrão

    Concede muito mais do que o necessário e dificulta a auditoria.

  • Permissões nunca revisadas

    Acúmulo de acessos esquecidos amplia o raio de impacto de qualquer incidente.

Quando procurar apoio especializado

Revisar IAM em uma organização com muitas contas e roles acumuladas exige método e contexto. A GUARDIASEC conduz essa revisão dentro do serviço de Segurança AWS e Cloud Security, mapeando caminhos de escalonamento de privilégio e priorizando as correções que mais reduzem risco.

Perguntas frequentes

Qual a diferença entre usuário IAM e role IAM?

Um usuário IAM tem credenciais de longa duração e representa uma identidade fixa. Uma role não tem credenciais permanentes: ela é assumida temporariamente e gera credenciais de curta duração. Para acesso de máquina e para acesso humano federado, roles são mais seguras porque limitam a janela de uso de qualquer credencial.

Preciso do IAM Identity Center mesmo em conta única?

Ele agrega valor principalmente quando há várias contas e vários usuários, oferecendo acesso federado com sessões temporárias e ponto central de gestão. Em uma conta única e pequena pode ser exagero, mas a partir do momento em que existem múltiplas pessoas e contas, ele reduz bastante o uso de credenciais de longa duração.

Como começo a aplicar menor privilégio sem quebrar a operação?

Comece observando o uso real com o histórico de last accessed e o Access Analyzer, em vez de cortar permissões no escuro. Reduza primeiro os casos mais perigosos, como AdministratorAccess e access keys de root, e avance gradualmente por papel, validando que cada ajuste não interrompe um fluxo legítimo.

SCP substitui as políticas de IAM?

Não. SCPs definem o teto de permissões para contas dentro de uma organização, mas não concedem acesso por si só. As políticas de IAM continuam necessárias para conceder permissões dentro desse teto. Os dois mecanismos trabalham juntos: SCP veda, IAM concede.

Próximo passo

Vamos avaliar os riscos do seu ambiente?

Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.