🔐

IAM: Identidade, Grupos, Roles e Policies

⏱ 12 min de leitura·+60 XP

IAM (Identity and Access Management) é o núcleo de tudo na AWS. Cada chamada de API — criar EC2, ler S3, modificar DNS — passa por uma verificação IAM. Entender IAM bem é a diferença entre uma arquitetura segura e um vazamento de dados que custa milhões. É também um dos tópicos mais cobrados do CLF-C02.

Onde isso entra no exame

📘 Domain 2 — Security and Compliance· 30%

IAM é o maior sub-tópico do domínio 2. Espera-se que você saiba: diferença entre Users, Groups e Roles; como funciona uma Policy (JSON: Effect/Action/Resource); quando usar Roles vs Users; boas práticas (MFA, root protection, least privilege); e o papel do STS em credenciais temporárias.

A hierarquia IAM

🗺️ Identidades, permissões e o fluxo de avaliação


                      ┌──────────────────────┐
                      │   ROOT USER          │  ← criada com a conta
                      │   (dono absoluto)    │    NUNCA usar no dia-a-dia
                      └──────────────────────┘
                                 │
            ┌────────────────────┼───────────────────┐
            │                    │                   │
            ▼                    ▼                   ▼
   ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
   │   IAM USER   │     │  IAM GROUP   │     │   IAM ROLE   │
   │  (pessoa)    │     │ (coleção de  │     │ (serviço ou  │
   │              │     │   users)     │     │  acesso temp)│
   └──────────────┘     └──────────────┘     └──────────────┘
          │                     │                   │
          └─────────┬───────────┴───────────────────┘
                    │
                    ▼
            ┌──────────────────┐
            │   POLICY (JSON)  │   Effect + Action + Resource
            │  Allow / Deny    │   (opcional: Condition)
            └──────────────────┘

Os 4 componentes centrais

Componente	O que é	Uso típico
IAM User	Identidade permanente (nome + credenciais)	Funcionário acessando o console ou CLI
IAM Group	Coleção lógica de Users	Agrupar permissões por função: "Devs", "Ops", "FinOps"
IAM Role	Identidade assumida temporariamente	Serviço AWS (EC2→S3) ou acesso cross-account
IAM Policy	Documento JSON definindo permissões	Anexada a Users/Groups/Roles para conceder Allow/Deny

Anatomia de uma Policy JSON

Toda permissão IAM é expressa como um documento JSON. Os campos essenciais:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PermitirLeituraS3Bucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::meu-bucket",
        "arn:aws:s3:::meu-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

• Version: sempre 2012-10-17 (versão da linguagem)
• Effect: Allow ou Deny
• Action: operação da API — formato serviço:Operação
• Resource: ARN do recurso (ou * para "todos")
• Condition: opcional — restringe quando a permissão aplica (IP, data, tag, MFA)

Regra de ouro: Explicit Deny > Explicit Allow > Default Deny

🗺️ Fluxo de avaliação IAM


     Request API
         │
         ▼
   ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
   │  Há Deny    │ sim │  Negar      │     │             │
   │  explícito? │────▶│  (para)     │     │             │
   └─────────────┘     └─────────────┘     │             │
         │ não                              │             │
         ▼                                  │             │
   ┌─────────────┐     ┌─────────────┐     │             │
   │  Há Allow   │ sim │  Permitir   │     │             │
   │  explícito? │────▶│  (permite)  │     │             │
   └─────────────┘     └─────────────┘     │             │
         │ não                              │             │
         ▼                                  │             │
   ┌─────────────┐                          │             │
   │  Default    │                          │             │
   │  Deny       │                          │             │
   └─────────────┘                          │             │

Toda chamada começa negada por padrão. Você precisa de pelo menos um Allow em alguma policy aplicável. Mas um Deny explícito em QUALQUER policy sempre vence — é uma ferramenta poderosa para bloquear ações mesmo que outra policy permita.

Tipos de Policies

Tipo	Descrição	Exemplo
AWS Managed	Criada e mantida pela AWS	AmazonS3ReadOnlyAccess, AdministratorAccess
Customer Managed	Você cria, reutiliza entre entidades	ReadOnlyCompanyBuckets
Inline	Embutida em um único User/Group/Role	Ad hoc, não reutilizável
Identity-based	Anexada a User/Group/Role (quem pode fazer o quê)	A maioria das policies
Resource-based	Anexada a um recurso (quem pode acessar ele)	Bucket policy do S3, policy do KMS
Permission boundary	Teto máximo de permissões para um User/Role	Usada por times FinOps/Security
SCP (Service Control Policy)	Limite em nível de Organization	Bloqueia ações em todas as contas-filhas

User vs Role — a diferença que mais cai

Aspecto	IAM User	IAM Role
Duração	Permanente	Temporária (sessão com tempo limite)
Credenciais	Access key + secret longevas	Tokens STS renovados automaticamente
Para quem	Pessoa específica	Serviço, aplicação ou usuário federado
Risco	Chave vazada = acesso indefinido	Token vazado = válido por minutos/horas
Boa prática	Minimizar (preferir IAM Identity Center)	Preferir sempre que possível

💡

Regra mental: toda vez que um serviço AWS precisa acessar outro serviço AWS, use Role. Toda vez que uma pessoa precisa acesso temporário ou federado, use Role via STS. Use Users apenas para humanos com acesso contínuo (e mesmo assim, IAM Identity Center é melhor).

IAM Identity Center (antes AWS SSO)

A forma moderna de gerenciar identidades humanas na AWS. Em vez de criar IAM Users um por um, você conecta seu provedor de identidade (Google Workspace, Azure AD, Okta) ao IAM Identity Center, que:

• Faz login único (SSO) entre todas as contas da sua Organization
• Gerencia permissões por conjuntos de permissões (permission sets)
• Elimina a necessidade de IAM Users permanentes em cada conta
• Revoga acesso instantaneamente quando alguém sai da empresa (só desativa no IdP)

Multi-Factor Authentication (MFA)

MFA adiciona um segundo fator (código TOTP de app como Google Authenticator, ou hardware token) ao login. Proteções recomendadas:

• Root account — obrigatório MFA de hardware ou virtual
• Usuários privilegiados (Administrators, Billing) — obrigatório
• Todos os IAM Users com console access — fortemente recomendado
• Pode ser exigido via policy com aws:MultiFactorAuthPresent": "true"

As ~6 coisas que SÓ a root pode fazer

• Fechar a conta AWS
• Mudar o endereço de email da conta
• Mudar o plano de suporte (Basic, Developer, Business, Enterprise)
• Restaurar permissões IAM que foram completamente revogadas
• Gerenciar configurações de faturamento raízes
• Registrar-se em GovCloud

🚨

A root não é para o dia a dia. Crie um IAM User com AdministratorAccess para uso diário, habilite MFA na root, guarde a credencial em cofre físico e só a use nas ~6 tarefas acima.

Princípio do menor privilégio (Least Privilege)

Conceda apenas as permissões necessárias para a tarefa, nem mais, nem menos. Implementação prática:

Passo	Ferramenta
Começar negando tudo	Default Deny — padrão AWS
Conceder por grupos, não usuários	IAM Groups
Revisar permissões não usadas	IAM Access Analyzer
Validar policies antes de aplicar	IAM Access Analyzer — policy validation
Limitar dano de comprometimento	Permission Boundaries + SCPs

Cenários de decisão

📋 Aplicação rodando em EC2 precisa ler do bucket S3

✓ EC2 Instance Role

Sem access keys hardcoded, credenciais rotacionadas automaticamente pelo STS, acesso auditável via CloudTrail.

Alt: Access keys em variáveis de ambiente — Má prática — qualquer dump de memória ou process list expõe

📋 Desenvolvedor precisa acesso a duas contas AWS (dev e prod)

✓ IAM Identity Center + permission sets

Login único, acesso granular por conta, revogação instantânea ao sair da empresa. Elimina IAM Users duplicados em cada conta.

📋 Parceiro externo precisa acessar um bucket S3 específico

✓ Cross-account Role + Bucket Policy

Parceiro tem sua própria conta AWS. Você cria uma Role confiando na conta dele; ele assume via STS. Sem compartilhar credenciais.

📋 Funcionário que saiu da empresa tinha acesso AWS

✓ IAM Identity Center: desativa no IdP → propaga tudo

Em vez de caçar Users em N contas, uma desativação no provedor de identidade revoga acesso em toda Organization.

Prática: criar um usuário e anexar policy

bash

# Criar um grupo
aws iam create-group --group-name Devs

# Anexar policy gerenciada ao grupo
aws iam attach-group-policy \
  --group-name Devs \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Criar usuário
aws iam create-user --user-name alice

# Adicionar ao grupo
aws iam add-user-to-group --user-name alice --group-name Devs

# Habilitar MFA
aws iam create-virtual-mfa-device --virtual-mfa-device-name alice-mfa \
  --outfile qr.png --bootstrap-method QRCodePNG

⚠️

Armadilha do exame: "IAM é regional ou global?" — Global. IAM não tem seletor de Região. Usuários, Roles, Policies criados valem para toda a conta em qualquer Região.

Perguntas típicas (Q&A)

❓ Um IAM User tem 3 policies: uma Allow s3:*, uma Allow ec2:*, e uma Deny s3:DeleteBucket. O user pode deletar buckets?

Não. Explicit Deny sempre vence, mesmo em face de múltiplos Allows. Essa é a regra mais cobrada em questões de policy evaluation.

❓ Qual é o tempo máximo padrão de uma sessão STS assumindo uma Role?

1 hora (3600s) por padrão. Pode ser estendido até 12h via configuração da Role. Para IAM Identity Center, o padrão é 8h (configurável).

❓ Diferença entre IAM Policy e S3 Bucket Policy?

IAM Policy é identity-based — anexa a quem pode fazer. Bucket Policy é resource-based — anexa ao bucket definindo quem pode acessar. Útil para conceder acesso cross-account sem criar IAM User lá.

❓ Como dar permissão a um usuário externo (sem conta AWS) para acessar recursos?

Via identity federation: SAML 2.0 (Okta, Azure AD), OIDC (Google, Cognito), ou AWS IAM Identity Center. Eles recebem credenciais temporárias via STS após autenticação no provedor externo.

✅

Take-aways:IAM tem 4 componentes — Users, Groups, Roles, Policies. Policies JSON definem Effect/Action/Resource/Condition. Deny > Allow > Default Deny. Roles > Users sempre que possível. MFA obrigatório na root e em privilegiados. Least privilege + Access Analyzer. IAM é global. STS gera credenciais temporárias para Roles. Identity Center > IAM Users para acesso humano em Organizations.

🧩

Quiz rápido

3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito