Resumo

Imagine um prédio de escritórios. Nem todo mundo que entra pode abrir todas as salas — a recepcionista tem crachá para o térreo, o financeiro tem crachá para a sala de cofres, um prestador de serviço externo recebe um crachá temporário só para o dia da visita.

IAM (Identity and Access Management) é o sistema de crachás da AWS: ele define quem (uma pessoa, uma aplicação, um serviço) pode fazer o quê (ler um arquivo, apagar um banco, criar uma instância) em quais recursos, dentro da sua conta.

• User: uma identidade fixa, normalmente para uma pessoa ou uma aplicação legada, com credenciais que não expiram sozinhas.
• Role: uma identidade assumível, que gera credenciais temporárias — o crachá de visitante que expira.
• Group: uma forma de organizar Users para aplicar as mesmas permissões a vários de uma vez.
• Policy: o documento (em JSON) que efetivamente diz "Allow" ou "Deny" para uma ação em um recurso.

O princípio que guia tudo isso é o menor privilégio: conceda só o necessário, nunca "por garantia".

---

1. Por que IAM existe (o problema antes da ferramenta)

Sem controle de acesso, qualquer credencial que vazasse (de um funcionário, de um script, de um repositório público) daria acesso total à conta inteira — apagar bancos de produção, criar recursos caríssimos, vazar dados de clientes. IAM existe para que cada identidade tenha exatamente o poder necessário para sua função, nem mais, nem menos, e para que esse poder possa ser auditado, revogado e expirado.

---

2. Users vs Roles vs Groups

2.1 IAM User

Uma identidade com nome próprio dentro da conta, usada tipicamente por uma pessoa que precisa logar no console ou usar a CLI regularmente. Pode ter senha (console) e/ou access keys (programático). É uma credencial de longa duração — continua válida até alguém revogá-la manualmente.

Por isso, users exigem cuidado extra: MFA obrigatório, rotação de chaves, e — cada vez mais — a recomendação da própria AWS é evitar users sempre que uma role resolver o mesmo problema.

2.2 IAM Role

Uma identidade sem credenciais fixas. Em vez de ter senha ou access key, uma role é assumida — quem assume recebe credenciais temporárias (geradas via um serviço chamado STS — Security Token Service), que expiram sozinhas depois de um tempo configurado (de minutos a horas).

Exemplo de fluxo real:

Instância EC2 → assume a role "app-s3-reader"
             → STS gera credenciais temporárias
             → aplicação usa essas credenciais para chamar s3:GetObject
             → credenciais expiram automaticamente após algumas horas

Roles são a opção recomendada para:

• Serviços AWS que precisam acessar outros serviços (EC2 → S3, Lambda → DynamoDB).
• Federação de usuários externos (login corporativo, login social).
• Acesso entre contas (cross-account).

💡 Regra mental para a prova: se a pergunta envolve um serviço AWS (EC2, Lambda, ECS) precisando acessar outro recurso, a resposta quase sempre é "IAM Role", nunca "access key fixa dentro do código".

2.3 IAM Group

Um group não tem permissões próprias "de verdade" — ele é um container de Users. Você anexa policies ao group, e todo user dentro dele herda essas permissões. Serve para não ter que repetir a mesma policy em 30 users individualmente: você cria o group "Financeiro-ReadOnly", anexa a policy uma vez, e adiciona/remove pessoas do group conforme elas entram ou saem da equipe.

⚠️ Pegadinha comum de prova: um group não pode ser referenciado como "Principal" numa resource policy ou numa role trust policy — apenas users, roles e contas/serviços podem assumir esse papel. Group é só um mecanismo de organização de permissões para Users.

---

3. Policies — o coração do IAM

Uma policy é um documento JSON com uma lista de declarações (Statement), cada uma dizendo: para esta ação, neste recurso, o efeito é Allow ou Deny.

Exemplo simples — permitir apenas leitura de objetos em um bucket específico:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::meu-bucket-financeiro/*"
    }
  ]
}

Partes principais de cada Statement:

• Effect: Allow ou Deny.
• Action: a(s) operação(ões) permitida(s)/negada(s) (ex: s3:GetObject, ec2:StartInstances).
• Resource: em qual recurso específico (identificado por ARN) essa regra se aplica.
• Condition (opcional): restrições extras — por IP de origem, exigência de MFA, VPC endpoint específico, tags do recurso, horário etc.

Exemplo com condição — só permite a ação se o usuário tiver autenticado com MFA:

{
  "Effect": "Allow",
  "Action": "iam:ChangePassword",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

3.1 Tipos de policy

• Managed policy (AWS managed): mantida pela própria AWS, cobre casos de uso comuns (ex: AmazonS3ReadOnlyAccess). Você não edita, só anexa.
• Managed policy (Customer managed): você cria e mantém, reutilizável em vários users/roles/groups.
• Inline policy: escrita direto "dentro" de um único user/role/group específico — não é reutilizável, e é apagada se o principal for apagado. Usada quando a permissão é tão específica que não faz sentido reaproveitar.
• Resource policy: anexada ao recurso, não à identidade (ex: bucket policy do S3, policy de um SNS topic ou de uma KMS key). Permite controlar acesso "de fora para dentro" — inclusive de outras contas — sem precisar mexer na identidade que está pedindo acesso.

---

4. Como o IAM decide: Allow, Deny ou nada?

Esse é o ponto que mais gera confusão para quem está começando. A lógica de avaliação segue esta ordem:

1. Por padrão, tudo é negado (implicit deny). Se nenhuma policy falar nada sobre uma ação, ela é bloqueada.
2. Se qualquer policy aplicável (identity-based, resource-based, permission boundary, SCP) tiver um Deny explícito para aquela ação, a ação é bloqueada — ponto final, sem exceção.
3. Se não houver Deny explícito, mas houver pelo menos um Allow em alguma policy aplicável, a ação é permitida.
4. Se não houver nem Allow nem Deny explícito, prevalece o padrão do passo 1: negado.

Ou seja: Deny explícito sempre vence. Não importa se um Allow está numa política "mais específica" ou "mais recente" — um único Deny em qualquer lugar aplicável barra a ação.

---

5. Permission boundaries — o teto que ninguém ultrapassa

Um permission boundary é uma policy especial anexada a um user ou role que define o limite máximo de permissões que aquela identidade pode efetivamente ter — mesmo que outras policies anexadas a ela sejam muito mais permissivas.

Analogia: é como dar a um gerente de equipe o poder de criar crachás para sua equipe, mas travando que nenhum crachá criado por ele pode abrir a sala do cofre, não importa o que ele configure.

Uso típico: uma plataforma central permite que times criem suas próprias roles, mas usa permission boundaries para garantir que nenhuma dessas roles, mesmo mal configurada, escale privilégios além do previsto.

⚠️ Não confundir com SCP (Service Control Policy): SCP é do AWS Organizations, aplicado no nível de conta inteira (todos os users e roles daquela conta), enquanto permission boundary é aplicado a uma identidade IAM específica dentro de uma conta.

---

6. Cross-account access (acesso entre contas)

Cenário comum: a Conta A (produção) precisa dar acesso temporário a alguém ou algo da Conta B (ex: pipeline de CI/CD, equipe de auditoria), sem duplicar usuários nem compartilhar credenciais.

Fluxo:

1. Na Conta A, você cria uma role com uma trust policy dizendo "esta role pode ser assumida pela Conta B" (ou por um principal específico dela).
2. Alguém autorizado na Conta B chama sts:AssumeRole apontando para essa role.
3. O STS devolve credenciais temporárias, válidas só pelo tempo configurado, com exatamente as permissões daquela role.

Nenhuma senha ou access key permanente é compartilhada entre as contas — é só uma questão de confiança configurada via trust policy.

---

7. Federação e IAM Identity Center

Nem todo mundo que acessa a AWS precisa de um IAM User criado manualmente. Federação permite que pessoas façam login usando uma identidade que já existe em outro lugar — o diretório corporativo da empresa (via SAML), ou até login social — e recebam credenciais temporárias via STS, sem nunca ter um IAM User "de verdade".

IAM Identity Center (antigo AWS SSO) é o serviço da AWS para centralizar esse login único: uma pessoa loga uma vez e ganha acesso federado a múltiplas contas AWS, cada uma com um conjunto de permissões específico — sem precisar de um user IAM separado em cada conta.

💡 Para a prova: se o cenário menciona "milhares de funcionários" ou "sistema de login corporativo existente" precisando acessar várias contas AWS, pense em federação / IAM Identity Center, não em criar um IAM User para cada pessoa.

---

8. Controle de acesso baseado em tags (ABAC)

Em vez de escrever uma policy nova para cada projeto ou equipe, é possível usar tags em recursos e nas próprias identidades, e escrever policies que dizem, por exemplo: "permita a ação se a tag project do usuário for igual à tag project do recurso". Isso é chamado de ABAC (Attribute-Based Access Control), em contraste com o modelo tradicional de escrever uma policy por recurso/role (RBAC). ABAC escala melhor em ambientes com muitos times e recursos dinâmicos, porque você não precisa reescrever policies a cada novo recurso — só manter a tag certa.

---

9. IAM Access Analyzer

Ferramenta que analisa suas policies (principalmente resource policies, como bucket policies) e aponta acessos não intencionais — por exemplo, um bucket S3 que ficou acessível para outra conta ou publicamente, sem essa ter sido a intenção. Ajuda a validar, antes de publicar uma policy, se ela concede mais acesso do que deveria.

---

10. Boas práticas

• Nunca use o usuário root para tarefas do dia a dia — habilite MFA nele e guarde as credenciais só para emergências administrativas específicas.
• Prefira roles a users com access keys fixas, especialmente para workloads (EC2, Lambda, containers).
• Comece restritivo (deny-by-default é o padrão nativo) e vá abrindo conforme necessário — nunca o contrário.
• Use permission boundaries quando delegar a criação de roles/policies para outros times.
• Habilite MFA para toda ação sensível e para usuários administrativos.
• Use Access Analyzer antes de publicar policies que envolvem acesso externo.
• Prefira federação/IAM Identity Center a criar um IAM User por pessoa em ambientes corporativos.

---

11. Como cai na certificação

• Cenário "aplicação em EC2/Lambda precisa acessar outro serviço AWS sem hardcode de chave" → IAM Role.
• Cenário "acesso temporário entre contas" → role com trust policy + AssumeRole (STS).
• Cenário "Allow numa policy, Deny em outra, mesmo usuário" → Deny sempre vence.
• Cenário "impedir que outro time conceda mais permissão do que deveria, mesmo com policy solta" → permission boundary (dentro da conta) ou SCP (entre contas, via Organizations) — a prova costuma testar se você sabe diferenciar os dois.
• Cenário "login corporativo único para múltiplas contas" → federação / IAM Identity Center, não criação manual de users.
• Cenário "policy anexada a um bucket, não a um usuário" → resource policy.

---

12. Exercícios práticos

1. Escreva o JSON de uma policy que permita dynamodb:GetItem e dynamodb:PutItem apenas na tabela arn:aws:dynamodb:us-east-1:123456789012:table/Pedidos, exigindo MFA.
2. Explique, em uma frase, a diferença entre inline policy e customer managed policy — e quando cada uma faz mais sentido.
3. Desenhe (em texto) o fluxo completo de uma Lambda assumindo uma role para escrever em um bucket S3, incluindo o papel do STS.
4. Escreva a trust policy que a Conta 111111111111 precisaria para permitir que a Conta 222222222222 assuma uma role chamada AuditorRole.
5. Explique por que um IAM Group não pode ser usado como Principal em uma trust policy, e o que usar no lugar.

---

13. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Laboratório Prático

Objetivo: criar uma IAM Role assumível por uma instância EC2, com permissão restrita de leitura em um bucket S3 específico, e validar a lógica de Deny explícito.

Pré-requisitos: uma conta AWS, um bucket S3 já criado com pelo menos um objeto dentro.

Tempo estimado: 20 minutos

Possíveis custos: praticamente nulo (uso mínimo de EC2 t3.micro em free tier, se disponível na conta).

Passos:

1. Crie uma IAM Role do tipo "AWS service" com caso de uso EC2.
2. Anexe a ela uma customer managed policy permitindo apenas s3:GetObject no ARN do bucket criado (não use uma managed policy ampla como AmazonS3FullAccess).
3. Lance uma instância EC2, associando essa role a ela na criação (campo "IAM instance profile").
4. Conecte-se via Session Manager ou SSH e, usando a AWS CLI (sem configurar nenhuma credencial manualmente), rode aws s3 cp s3://seu-bucket/seu-arquivo . — deve funcionar, usando as credenciais temporárias da role.
5. Tente rodar aws s3 rm s3://seu-bucket/seu-arquivo — deve falhar, porque a policy não concede s3:DeleteObject.
6. Adicione à mesma role um Deny explícito para s3:GetObject nesse bucket (mesmo já havendo um Allow implícito de outra policy anexada) e repita o passo 4 — observe que agora a leitura também falha, confirmando que o Deny explícito vence.

Resultado esperado: a instância consegue ler o objeto sem nenhuma credencial fixa configurada, não consegue deletar (permissão nunca concedida), e para de conseguir ler assim que um Deny explícito é adicionado — demonstrando na prática a ordem de avaliação do IAM.

Limpeza dos recursos: termine a instância EC2, remova a role e a policy customer managed criada, para não deixar identidades órfãs na conta.

---

Referências:

• IAM Best Practices: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
• IAM Policy Evaluation Logic: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
• Permission Boundaries: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
• IAM Identity Center: https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
• IAM Access Analyzer: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html