Anatomia de uma policy
Lição 3 · Módulo 1 — Átomos do IAM
Policies são JSON
Uma policy é um documento JSON. Parece intimidante na primeira vez, mas tem só 6 campos principais. Conhecendo cada um, você lê qualquer policy da AWS.
1234567891011121314151617
{ "Version": "2012-10-17", "Statement": [ { "Sid": "PermitirLeituraDoBucketRelatorios", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::relatorios", "arn:aws:s3:::relatorios/*" ] } ]} Os campos em detalhe
Vamos dissecar cada campo, o que ele significa, quais valores aceita e armadilhas comuns. Se precisar de uma consulta rápida depois, veja a página de referência.
Version
Obrigatório
É a versão da linguagem de policies da AWS, não da sua policy.
Use sempre "2012-10-17" — a versão mais nova, que todas as features modernas
(como variáveis ${aws:username}) requerem.
A versão antiga "2008-10-17" existe por compatibilidade; nunca
escreva uma policy nova com ela.
Id
OpcionalIdentificador único da policy inteira. Só aparece em algumas resource-based policies (ex.: SQS, SNS). Ignorado em identity-based policies. Na prática, raro.
Statement
ObrigatórioO coração da policy: uma lista de statements, cada um com sua combinação de Effect/Action/Resource/Condition. Pode ser um único objeto ou um array.
Regra importante: cada statement é avaliado independentemente. O resultado final da policy é a combinação de todos — não há ordem nem prioridade. Um Deny em qualquer statement vence todos os Allows.
Sid
OpcionalStatement ID — um rótulo legível para você. Não afeta a avaliação, mas aparece em logs e facilita o debugging ("qual statement permitiu/negou essa ação?"). Deve ser único dentro da mesma policy. Use letras e números, sem espaços.
Effect
Obrigatório
Só aceita dois valores: "Allow" ou "Deny".
Nada além disso — escrever "allow" (minúsculo) ou "Permit"
é erro de sintaxe.
Dica: Deny sempre vence. Se um statement com Deny casa com a request, a request é negada, mesmo que 100 outros statements tenham Allow.
Principal / NotPrincipal
Só em resource-basedDefine quem pode fazer a ação. Identity-based policies não têm Principal — o principal é implicitamente a identidade a que a policy está anexada.
Tipos de valor:
"AWS": "arn:aws:iam::111:user/alice"— um IAM User/Role específico."AWS": "arn:aws:iam::111:root"— qualquer identidade da conta 111."Service": "lambda.amazonaws.com"— um serviço AWS."Federated": "accounts.google.com"— um provedor de identidade federado."*"— qualquer principal (incluindo anônimo). Perigoso.
Action / NotAction
Obrigatório Action define o que está sendo permitido/negado. String única ou array.
Formato servico:Operacao, sempre em PascalCase: s3:GetObject,
ec2:StartInstances.
Wildcards:
"s3:*"— todas as ações do S3."s3:Get*"— todas as ações que começam com Get."*"— todas as ações de todos os serviços. Admin total.
NotAction é o oposto: "todas as ações exceto estas".
Raramente é o que você realmente quer — veja o alerta abaixo.
Aprofundamos Action na próxima lição.
Resource / NotResource
Obrigatório em identity-based
Define sobre o quê a ação se aplica. Valor é um ARN ou lista de ARNs.
Aceita * como wildcard.
Em resource-based policies, o campo é opcional — o recurso é implicitamente aquele onde a policy está anexada (ex.: o bucket).
Aprofundamos ARNs e padrões de Resource na próxima lição.
Condition
OpcionalAdiciona uma quarta dimensão à policy: sob quais circunstâncias. Permite exigir MFA, restringir IP de origem, limitar região, comparar tags e muito mais.
Estrutura: "Condition": { operador: { context-key: valor } }.
Cobrimos a fundo na Lição 12.
O que é obrigatório?
| Campo | Identity-based | Resource-based |
|---|---|---|
| Version | ✅ obrigatório | ✅ obrigatório |
| Id | — ignorado | ⭕ opcional |
| Statement | ✅ obrigatório | ✅ obrigatório |
| Sid | ⭕ opcional | ⭕ opcional |
| Effect | ✅ obrigatório | ✅ obrigatório |
| Principal | — proibido | ✅ obrigatório |
| Action | ✅ obrigatório* | ✅ obrigatório* |
| Resource | ✅ obrigatório* | ⭕ opcional (implícito) |
| Condition | ⭕ opcional | ⭕ opcional |
* Action/NotAction e Resource/NotResource — exatamente um dos dois deve estar presente.
Deny por padrão
Princípio fundamental: se nada permite, o resultado é Deny. Você não precisa
escrever Deny para bloquear; só precisa não escrever Allow.
Deny explícito existe para sobrepor um Allow —
e sempre vence.
Esse é o coração do modelo de avaliação IAM — que vamos detalhar no Módulo 2.
Teste rápido
Uma policy tem Allow s3:GetObject em * e outra tem Deny s3:GetObject em * (mesmo principal). Qual é o resultado de uma chamada s3:GetObject?
Uma policy tem apenas Allow s3:PutObject. O que acontece com uma chamada s3:GetObject?
Resumo
Decore o esqueleto Version → Statement → [Sid, Effect, Action, Resource].
Todo o resto são variações e extensões. A próxima lição foca em como
Action e Resource funcionam de verdade, com wildcards e ARNs.
Para consulta rápida de todos os campos em um único lugar, veja a página de referência.
Referência Well-Architected
Esta lição é pré-requisito para todas as boas práticas de gestão de permissões do Well-Architected Framework: você não escreve boas policies sem dominar a anatomia do documento.
Referências
Terminou esta lição?
Seu progresso fica salvo apenas neste navegador.