Duas camadas, propósitos diferentes
O erro de modelagem mais comum é tratar Service Control Policy (SCP) e identity-based policy como o mesmo controle em escopos diferentes. Não são. SCP nunca concede nada: ela define o teto do que qualquer identidade dentro da conta ou da OU consegue fazer, ainda que a identity policy dessa identidade permita mais. Conceder é trabalho da identity policy — é o único dos dois mecanismos que de fato dá permissão a um principal.
A tabela e o fluxo de avaliação abaixo cobrem o mecanismo inteiro, incluindo a terceira camada, por identidade: Permission Boundaries.
SCP vs. identity policy, lado a lado
Service Control Policy (SCP)
- Aplicada no AWS Organizations — conta, OU ou a organização inteira
- Nunca concede: só restringe, mesmo diante de
AdministratorAccess - Não alcança a conta de management da organização, por padrão
- Não alcança o root user — SCP limita identidade IAM, e o root não é uma
- Editada por quem administra o Organizations, em geral um time central de plataforma
Identity-based Policy
- Anexada direto a um usuário, grupo ou role do IAM
- Concede: é o único dos dois que permite uma ação de fato
- Pode ser managed (da AWS ou do cliente) ou inline
- Continua sujeita a Permission Boundaries, se a identidade tiver uma anexada
- Editada por quem administra o IAM daquela conta
A regra que resume tudo: SCP e permission boundary respondem “qual é o teto?”; identity policy responde “o que foi concedido?”. O efetivo é sempre a interseção entre teto e concessão, nunca a união.
Ordem de avaliação — como a AWS chega em allow ou deny
Para cada requisição a AWS avalia todas as políticas aplicáveis, e o resultado é deny por padrão: só passa o que tiver allow explícito em todas as camadas que se aplicam e nenhum deny explícito em nenhuma delas.
- 1
SCP da organização, se a conta estiver numa AWS Organization
Precisa conter um allow para a ação, explícito ou por wildcard. Sem isso é deny implícito, ainda que a identity policy permita. Não se aplica à conta de management nem ao root user.
- 2
Resource-based policy, se o recurso tiver uma — bucket policy do S3, por exemplo
Um allow aqui pode conceder acesso mesmo entre contas distintas, independentemente da identity policy do principal.
- 3
Permission boundary, se a identidade tiver uma anexada
Define o teto daquela identidade em particular. A identity policy só vale dentro da interseção com a boundary.
- 4
Identity-based policy, anexada ao usuário, grupo ou role
É a concessão. Sem allow explícito aqui não há acesso, por mais permissivas que sejam as outras camadas.
- 5
Session policy, se a sessão veio de um AssumeRole com policy inline
Camada final e opcional, para apertar ainda mais uma sessão temporária específica.
Deny explícito em qualquer camada sempre vence. Não existe combinação de allows que passe por cima dele.
Um exemplo concreto
| Camada | Conteúdo | Efeito |
|---|---|---|
| SCP (OU “Production”) | Deny em toda ação iam:*, exceto para a role de break-glass | Bloqueia iam:* para todo mundo, inclusive quem é admin |
| Permission Boundary | Allow só em s3:* e ec2:Describe* | Teto: S3 completo e leitura de EC2, ainda que a identity policy peça mais |
| Identity policy (a role da pessoa desenvolvedora) | Allow em s3:*, ec2:* e iam:CreateUser | Sobra s3:*. ec2:* cai na interseção com a boundary, e iam:CreateUser é bloqueado pela SCP |
Fontes de dados
| Documento | Link |
|---|---|
| Service Control Policies (SCPs) | docs.aws.amazon.com |
| Policy Evaluation Logic | docs.aws.amazon.com |
| Permission Boundaries | docs.aws.amazon.com |