Tipos de policy

Até agora vimos policies "anexadas a identidades". Mas existem 6 tipos de policy na AWS, cada uma com um propósito e um efeito distinto na avaliação. Conhecer todos é essencial para entender o fluxograma completo.

Anexadas a identidades (user, group, role). Dizem o que a identidade pode fazer. Podem ser:

• Managed policies (AWS-managed ou customer-managed) — reutilizáveis entre identidades.
• Inline policies — vivem "dentro" de uma identidade específica.

Efeito: concede permissões.

Anexadas a recursos (bucket S3, fila SQS, segredo do Secrets Manager, trust policy de role). Dizem quem pode fazer o quê no recurso. Diferente das identity-based, têm um campo Principal.

Exemplos: S3 bucket policy, Lambda resource policy, KMS key policy, trust policy de roles.

Efeito: concede permissões (inclusive cross-account).

Aplicadas a uma identidade (user ou role). Definem o teto máximo de permissões — mesmo que a identity policy conceda mais, a boundary limita.

Boundaries não concedem. Só restringem. Usadas para delegar criação de roles sem dar admin total.

Efeito: reduz o efetivo ao que está em identity-policy ∩ boundary.

Aplicadas em organizational units dentro do AWS Organizations. Definem o teto máximo de permissões para todas as identidades de todas as contas naquela OU — incluindo o root user.

Efeito: reduz o efetivo. Como boundary, SCPs não concedem.

Passadas na hora de chamar sts:AssumeRole ou GetFederationToken, via parâmetro --policy. Restringem a sessão específica, sem alterar a role em si.

Exemplo: você tem uma role S3Admin, mas ao assumi-la para uma tarefa pontual passa uma session policy que só permite GetObject em um bucket específico.

Efeito: reduz o efetivo a role-permissions ∩ session-policy.

Legado. Existem no S3 (bucket/object ACLs) e não usam JSON. A AWS recomenda não usar ACLs novas — prefira bucket policies e IAM.

Em buckets modernos, ACLs estão desabilitadas por padrão (Bucket owner enforced).

Tipo	Anexada a	Concede?	Restringe?
Identity-based	User, group, role	✅	—
Resource-based	Recurso (bucket, SQS…)	✅	—
Permissions boundary	User ou role	❌	✅
SCP	OU no Organizations	❌	✅
Session policy	Sessão STS	❌	✅
ACL	Bucket/objeto S3 (legado)	✅	—

Identity + Resource concedem. Boundary + SCP + Session restringem. A permissão efetiva é a interseção de todos os limites com a união dos concessores. Próxima lição aprofunda essa intersecção no caso cross-account.

Esta lição dá base para as boas práticas de guardrails e least privilege do Well-Architected Framework, que dependem do uso correto de cada tipo de policy.

• Ver boa prática no Well-Architected Framework

• Policies and permissions in IAM
• Permissions boundaries
• Service control policies (SCPs)