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. Além dos fundamentos de credenciais e MFA, ele trata dos caminhos de escalonamento de privilégio que transformam uma permissão aparentemente inofensiva em acesso total, e de como revisar tudo isso de forma sustentável. 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.
"Condition": {
"BoolIfExists": { "aws:MultiFactorAuthPresent": "true" }
}Prefira negar de forma explícita as ações que nunca deveriam acontecer, porque um Deny sempre vence um Allow. Uma política de negação para desativar trilhas de auditoria, apagar chaves KMS ou alterar controles da organização protege o ambiente mesmo que outra política conceda a permissão por engano.
Caminhos de escalonamento de privilégio
Menor privilégio não é só evitar o AdministratorAccess. Algumas permissões isoladas parecem inofensivas, mas permitem que uma identidade limitada se torne administradora. Conhecer esses caminhos é o que diferencia uma política que parece restrita de uma que de fato contém o risco. A ideia aqui é defensiva: saber onde eles estão para fechá-los, não para explorá-los.
- Anexar políticas a si mesmo, como iam:AttachUserPolicy ou iam:PutUserPolicy, permite conceder qualquer permissão
- iam:CreatePolicyVersion e SetDefaultPolicyVersion deixam reescrever uma política já anexada
- iam:PassRole combinado com criar recursos (Lambda, EC2, ECS) permite herdar uma role mais poderosa
- iam:CreateAccessKey sobre outro usuário gera credenciais de uma identidade com mais acesso
- Atualizar a política de confiança de uma role admin permite assumi-la a partir de uma identidade sua
O padrão comum a todos esses casos é a permissão de alterar a própria autorização ou de repassar uma role privilegiada. Restrinja as ações do namespace iam e o uso de iam:PassRole com condições que limitam quais roles podem ser repassadas. O IAM Access Analyzer, tanto na validação quanto na geração de políticas a partir do uso real, ajuda a encontrar concessões amplas demais antes que virem um caminho de escalonamento.
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
Detectar o abuso, não só preveni-lo
Prevenção e detecção andam juntas. Configure alertas no CloudTrail para eventos que costumam marcar escalonamento ou preparação de acesso persistente: criação de access keys, anexação de políticas, mudança de política de confiança de role, uso da conta root e falhas repetidas de AssumeRole. Um caminho de escalonamento fechado é o ideal, mas um alerta rápido é o que reduz o tempo de resposta quando algo passa.
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
- Restringir ações do namespace iam e condicionar iam:PassRole às roles esperadas
- Negar de forma explícita ações que nunca deveriam ocorrer, como desativar auditoria
- 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
- Alertar no CloudTrail sobre criação de chaves e mudanças de política
- 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
O que é o IAM na AWS e por que ele é crítico para a segurança?
O IAM (Identity and Access Management) é o serviço que controla quem pode fazer o quê na sua conta AWS, por meio de usuários, grupos, roles e políticas. Ele é crítico porque a maioria dos incidentes graves em nuvem passa por identidade: uma credencial vazada ou uma permissão ampla demais abre caminho para acesso indevido e escalonamento de privilégio. Por isso, aplicar o princípio do menor privilégio no IAM é uma das medidas de maior impacto para reduzir risco em AWS.
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.
O que é iam:PassRole e por que ele exige cuidado?
O iam:PassRole é a permissão de entregar uma role a um serviço da AWS, como associar uma role a uma função Lambda ou a uma instância EC2. O cuidado é que, se uma identidade pode repassar uma role mais poderosa e criar o recurso que a usa, ela herda o acesso daquela role, um caminho clássico de escalonamento. A defesa é condicionar o PassRole para permitir apenas as roles esperadas de cada serviço, em vez de deixá-lo aberto com wildcard.
Como identifico caminhos de escalonamento de privilégio no IAM?
Revise as permissões do namespace iam e do sts:AssumeRole procurando quem pode alterar a própria autorização ou repassar roles privilegiadas. O IAM Access Analyzer ajuda a validar políticas e a apontar concessões amplas demais, e o histórico de last accessed mostra o que nunca foi usado. Em ambientes maiores, uma revisão estruturada que mapeia esses caminhos costuma render mais do que olhar política por política de forma isolada.
Guias relacionados
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.