IAM Groups na AWS: Por Que Você Não Deve Anexar Políticas Diretamente a Usuários

Se você já precisou revogar acesso de um desenvolvedor que saiu da empresa e descobriu que ele tinha políticas anexadas diretamente ao usuário — espalhadas por dezenas de permissões individuais — você entende exatamente por que IAM Groups existem. Gerenciar permissões usuário a usuário não escala, e o custo disso aparece sempre no pior momento.

TL;DR — IAM Groups vs. Políticas Diretas em Usuários

Critério	Política Direta no Usuário	IAM Group
Escalabilidade	Não escala — cada usuário precisa de atualização individual	Escala — uma mudança no grupo afeta todos os membros
Auditoria	Difícil — permissões fragmentadas por usuário	Centralizada — políticas visíveis no grupo
Onboarding	Manual e propenso a erro	Adicionar ao grupo aplica todas as permissões automaticamente
Offboarding	Requer auditoria de cada política anexada	Remover do grupo revoga as permissões do grupo imediatamente
Limite de políticas	10 políticas gerenciadas por usuário	10 políticas gerenciadas por grupo
Princípio do menor privilégio	Difícil de manter consistente	Mais fácil de padronizar por função

Como IAM Groups Funcionam na Prática

Um IAM Group não é uma identidade — ele não pode assumir roles, não tem credenciais e não aparece como principal em políticas de recursos. É um mecanismo de agrupamento: você anexa políticas ao grupo, e cada usuário membro herda essas permissões no momento da avaliação de autorização.

Quando um usuário faz uma chamada de API, o IAM avalia as permissões efetivas combinando políticas anexadas diretamente ao usuário com políticas herdadas de todos os grupos dos quais ele é membro. Um usuário pode pertencer a até 10 grupos simultaneamente. Essa avaliação é aditiva — exceto quando um Explicit Deny está presente, que sempre prevalece independentemente de qualquer Allow em qualquer política.

graph TD A["Usuário faz chamada de API"] --> B["IAM coleta todas as políticas"] B --> C["Políticas diretas do usuário"] B --> D["Políticas dos grupos do usuário"] C --> E["Avaliação consolidada"] D --> E E --> F{"Explicit Deny presente?"} F -->|"Sim"| G["❌ NEGADO — Explicit Deny"] F -->|"Não"| H{"Algum Allow presente?"} H -->|"Sim"| I["✅ AUTORIZADO"] H -->|"Não"| J["❌ NEGADO — Implicit Deny"]

Usuário faz chamada de API: A solicitação chega ao IAM para avaliação de autorização.
Coleta de políticas: O IAM agrega políticas anexadas diretamente ao usuário e políticas de todos os grupos dos quais ele é membro.
Avaliação de Explicit Deny: Se qualquer política contém um Deny explícito para a ação, a solicitação é negada imediatamente — independentemente de qualquer Allow.
Avaliação de Allow: Se ao menos uma política permite a ação e não há Deny explícito, a solicitação é autorizada.
Negação implícita: Se nenhuma política permite a ação, o IAM nega por padrão (implicit deny).

Por Que Políticas Diretas em Usuários Criam Problemas Reais

O problema não é técnico — é operacional. Políticas anexadas diretamente a usuários funcionam perfeitamente no início. O caos aparece quando a equipe cresce ou quando você precisa auditar quem tem acesso a quê.

Imagine um time de 15 desenvolvedores, cada um com políticas ligeiramente diferentes porque foram criadas em momentos distintos, por pessoas distintas. Quando uma nova política de segurança exige remover acesso a uma ação específica do S3, você precisa atualizar 15 usuários individualmente — e torcer para não ter esquecido nenhum. Com um grupo 'Developers', você atualiza uma política, uma vez.

Pensar em IAM Groups é como pensar em perfis de acesso por função, não por pessoa. A pessoa muda; a função permanece.

Outro ponto que passa despercebido: o limite de 10 políticas gerenciadas por entidade IAM se aplica tanto a usuários quanto a grupos. Mas quando você fragmenta permissões diretamente em usuários, tende a criar políticas inline ad hoc para contornar limites — e políticas inline são invisíveis para o IAM Access Analyzer por padrão e mais difíceis de auditar sistematicamente.

Estrutura Recomendada de IAM Groups por Função

A abordagem mais eficaz é modelar grupos por função operacional, não por projeto ou time. Funções mudam menos frequentemente do que estruturas de time, e permissões por função são mais fáceis de auditar e justificar em revisões de segurança.

graph LR U1["joao.silva"] --> G1["Grupo: Developers"] U2["maria.souza"] --> G1 U2 --> G2["Grupo: Ops"] U3["carlos.admin"] --> G3["Grupo: Admins"] U4["auditora"] --> G4["Grupo: ReadOnly"] G1 --> P1["Política: CodeCommit
Política: ECR Read/Write"] G2 --> P2["Política: EC2 Ops
Política: ECS Deploy"] G3 --> P3["Política: AdministratorAccess
(com restrições explícitas)"] G4 --> P4["Política: ReadOnlyAccess"]

Developers: Permissões de leitura e escrita em serviços de desenvolvimento — CodeCommit, CodeBuild, ECR, logs do CloudWatch. Sem acesso a produção diretamente.
Ops: Acesso operacional a EC2, ECS, RDS em ambientes de produção. Sem permissões de criação de infraestrutura.
Admins: Acesso amplo, mas ainda com restrições explícitas — por exemplo, sem permissão para deletar CloudTrail logs ou modificar políticas de SCP.
ReadOnly: Acesso de leitura transversal para auditores, stakeholders e ferramentas de monitoramento.
Um usuário pode pertencer a múltiplos grupos — um tech lead pode estar em 'Developers' e 'Ops' simultaneamente.

Criando e Gerenciando IAM Groups via AWS CLI

Os comandos abaixo cobrem o ciclo completo: criação do grupo, anexação de política, adição de usuário e verificação de membros. Execute na ordem apresentada para um onboarding completo.

1. Criar o grupo:

aws iam create-group \
  --group-name Developers

2. Anexar uma política gerenciada ao grupo:

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AWSCodeCommitPowerUser

3. Adicionar um usuário ao grupo:

aws iam add-user-to-group \
  --group-name Developers \
  --user-name joao.silva

4. Verificar membros do grupo:

aws iam get-group \
  --group-name Developers

5. Listar políticas anexadas ao grupo:

aws iam list-attached-group-policies \
  --group-name Developers

6. Remover usuário do grupo (offboarding):

aws iam remove-user-from-group \
  --group-name Developers \
  --user-name joao.silva

Criando uma Política Customizada e Anexando ao Grupo

Quando as políticas gerenciadas pela AWS não cobrem exatamente o que você precisa, crie uma política customizada. O exemplo abaixo concede acesso de leitura a um bucket S3 específico — escopo mínimo, sem wildcards desnecessários.

🔽 Clique para expandir — política IAM customizada para o grupo Developers

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3ReadArtifacts",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::minha-empresa-artifacts",
        "arn:aws:s3:::minha-empresa-artifacts/*"
      ]
    }
  ]
}

Para criar e anexar essa política ao grupo via CLI:

aws iam create-policy \
  --policy-name DevelopersS3ReadArtifacts \
  --policy-document file://developers-s3-policy.json

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::123456789012:policy/DevelopersS3ReadArtifacts

Note que s3:ListBucket precisa do ARN do bucket sem o sufixo /*, enquanto s3:GetObject precisa do ARN com /*. Essa distinção é frequentemente ignorada e resulta em erros de permissão que parecem inconsistentes — o usuário consegue listar mas não baixar, ou vice-versa.

O Erro Clássico: Política Direto no Usuário Que Ninguém Lembra

Aqui está um padrão que aparece em praticamente toda auditoria de conta AWS com mais de dois anos de uso: um usuário tem permissões que ninguém consegue explicar de onde vieram.

O cenário típico: alguém precisava de acesso temporário a um recurso específico, anexou uma política diretamente ao usuário 'para ser rápido', e nunca removeu. Seis meses depois, esse usuário tem acesso a recursos que não deveria — e a política inline não aparece na visão de grupo, então a auditoria não detecta facilmente.

A suposição errada era que 'política temporária no usuário é mais segura porque é isolada'. Na prática, o isolamento dificulta a visibilidade, não aumenta a segurança. A política ficou lá porque ninguém sabia que estava lá.

O diagnóstico correto: use o IAM Access Analyzer e o comando abaixo para listar todas as políticas — gerenciadas e inline — de um usuário específico:

aws iam list-user-policies \
  --user-name joao.silva

aws iam list-attached-user-policies \
  --user-name joao.silva

list-user-policies retorna políticas inline. list-attached-user-policies retorna políticas gerenciadas anexadas diretamente. Se qualquer um desses comandos retornar resultados para um usuário que deveria ter permissões apenas via grupo, você encontrou o problema.

Verificando Permissões Efetivas de um Usuário

Saber quais grupos um usuário pertence não é suficiente para entender suas permissões efetivas — você precisa considerar todas as fontes. O comando abaixo lista os grupos de um usuário, que é o ponto de partida para reconstruir o conjunto de permissões:

aws iam list-groups-for-user \
  --user-name joao.silva

Para uma visão consolidada de permissões efetivas, use o IAM Policy Simulator via console ou API. Ele considera políticas de usuário, grupos, e políticas de recursos relevantes para simular se uma ação específica seria permitida ou negada.

IAM Groups e o Princípio do Menor Privilégio

Grupos facilitam o menor privilégio porque forçam você a pensar em permissões por função, não por pessoa. Quando você cria um grupo 'Developers', precisa definir explicitamente o que um desenvolvedor precisa — e esse exercício naturalmente elimina permissões desnecessárias que seriam adicionadas ad hoc em usuários individuais.

Um detalhe que a documentação não enfatiza: SCPs (Service Control Policies) do AWS Organizations se aplicam antes das políticas IAM na avaliação. Se sua conta está em uma OU com uma SCP restritiva, nem o grupo de Admins terá acesso a ações bloqueadas pela SCP — independentemente do que a política do grupo permita. Sempre verifique SCPs ativas quando permissões parecem corretas no IAM mas ainda falham.

aws organizations list-policies-for-target \
  --target-id ou-xxxx-xxxxxxxx \
  --filter SERVICE_CONTROL_POLICY

Próximos Passos e Recursos Oficiais

IAM Groups são o ponto de partida para gerenciamento de acesso escalável, mas para workloads em produção, considere evoluir para IAM Roles com federação de identidade — especialmente se sua organização usa um provedor de identidade externo como Okta ou Azure AD. Roles eliminam credenciais de longo prazo e são o modelo recomendado pelo AWS Well-Architected Framework para acesso humano à AWS.

Glossário de Termos-Chave

Termo	Definição
IAM Group	Coleção de usuários IAM que compartilham as mesmas políticas anexadas. Não é uma identidade e não pode fazer chamadas de API diretamente.
Política Gerenciada	Política IAM standalone que pode ser anexada a múltiplos usuários, grupos ou roles. Pode ser gerenciada pela AWS ou pelo cliente.
Política Inline	Política embutida diretamente em um usuário, grupo ou role. Existe apenas enquanto a entidade existe e é mais difícil de auditar em escala.
Explicit Deny	Instrução de negação explícita em uma política IAM que prevalece sobre qualquer Allow, independentemente da origem da permissão.
SCP (Service Control Policy)	Política do AWS Organizations que define o limite máximo de permissões para contas em uma OU. Avaliada antes das políticas IAM.

Pesquisar este blog

SW BBANG P