Primeiro post do Nível Avançado da série AWS IAM. Aqui entramos em controle em escala. Começamos por um recurso poderoso e frequentemente mal compreendido: as permission boundaries. Entender bem esse conceito é o que permite dar autonomia às equipes sem perder o controle da segurança.
📚 O que você vai aprender neste post:
- O que é uma permission boundary e o que ela NÃO faz;
- Por que a permissão efetiva é uma interseção;
- Um exemplo prático de delegação segura, com policies;
- A diferença entre boundary, SCP e policy de permissão.
O que é uma permission boundary?
Uma permission boundary é uma política que define o teto máximo de permissões que uma identidade (usuário ou role) pode ter. Ela não concede permissões — ela limita o que as políticas anexadas podem efetivamente permitir.
Pense nela como um guarda-chuva: por mais permissões que você anexe por baixo, nada ultrapassa a borda do guarda-chuva. É crucial entender essa natureza dupla: uma identidade precisa de dois conjuntos de permissões alinhados — a policy que concede E a boundary que permite aquele teto.
Permissão efetiva = interseção
Uma ação só é permitida se for autorizada tanto pela policy de permissão quanto pela boundary. Exemplo: se a policy concede acesso a S3 e EC2, mas a boundary só permite S3, o resultado efetivo é apenas S3. A boundary nunca adiciona permissões — ela só pode restringir.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*" ], "Resource": "*" } ] }
Essa boundary diz: “não importa o que suas policies concedam, esta identidade nunca poderá agir além de S3 e CloudWatch”.
🛠️ Mão na massa: delegação segura
O cenário clássico: você quer que os desenvolvedores criem suas próprias roles para as aplicações deles, sem que possam criar uma role de administrador total (o que seria uma escalada de privilégio). A receita:
- Você cria uma boundary padrão (ex.:
boundary-devs) com o teto permitido para as aplicações. - Concede ao desenvolvedor permissão para criar roles — mas com uma condição que exige que toda role criada tenha aquela boundary anexada.
A condição na policy do desenvolvedor é assim:
{ "Effect": "Allow", "Action": "iam:CreateRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/boundary-devs" } } }
Resultado: o dev tem autonomia para criar roles, mas mesmo que tente conceder permissões amplas, a boundary limita o teto. Autonomia com controle — exatamente o equilíbrio que se busca em escala.
Boundary x outros controles
- Permission boundary — limita o teto de uma identidade específica.
- Service Control Policies (SCPs) — limitam o teto de contas inteiras em uma organização (tema do nível especialista).
- Policies de permissão — concedem acesso dentro desses tetos.
Na prática, os três atuam em camadas: a SCP define o máximo da conta, a boundary define o máximo da identidade, e a policy concede dentro disso. Uma ação só passa se sobreviver a todas as camadas — e a nenhum Deny explícito.
💡 Resumo dos pontos-chave
A permission boundary é um teto, não uma concessão. A permissão efetiva é a interseção entre policy e boundary. Use-a para delegação segura: exigir a boundary na criação de roles dá autonomia às equipes sem abrir brecha para escalada de privilégio.
Boundary não é firewall de rede
Um mal-entendido frequente é confundir permission boundary com controles de rede. A boundary atua exclusivamente no plano de identidade e autorização — ela decide quais chamadas de API a identidade pode fazer. Ela não filtra tráfego, não substitui security groups nem VPC endpoints. Segurança sólida na AWS combina as duas dimensões: controle de identidade (IAM, boundaries, SCPs) e controle de rede (VPC, security groups, endpoints privados).
Outro cuidado: como a boundary limita o teto, esquecer de incluir uma ação legítima nela causa “Access Denied” mesmo quando a policy de permissão está correta. Ao depurar, lembre-se de checar a boundary — ela é uma das camadas silenciosas que veremos com detalhe no nível especialista.
O que a boundary não alcança
Um detalhe que evita surpresas: permission boundaries se aplicam a usuários e roles que você cria, mas não se aplicam a service-linked roles (aquelas roles especiais que certos serviços da AWS criam e gerenciam para si). Além disso, a boundary limita apenas ações baseadas em identidade; ela não restringe o que uma resource-based policy pode conceder a um principal externo. Conhecer essas fronteiras evita a falsa sensação de que “a boundary cobre tudo”.
Por isso as boundaries funcionam melhor como parte de uma estratégia em camadas — junto de SCPs, políticas bem escritas e controles de rede — e não como um mecanismo único de contenção.
Testando o efeito da boundary
Antes de confiar cegamente em uma boundary, valide o efeito dela no IAM Policy Simulator, que já considera boundaries na simulação. Um erro clássico é anexar uma boundary muito restritiva a uma role que também precisa gerenciar IAM (como uma role de automação de deploy): se a boundary não incluir as ações de iam: necessárias, a role deixa de conseguir criar ou ajustar recursos, e o “Access Denied” resultante costuma confundir. Simular antes de aplicar transforma essa dor de cabeça em um teste de dois minutos.
No próximo post
Vamos ao acesso cross-account com roles: como compartilhar recursos entre contas AWS diferentes de forma segura, sem duplicar usuários nem trocar chaves. Até lá!
Informações sobre o autor
Dennis Silva atua com Segurança da Informação e Cibersegurança há +18 anos e iniciou sua carreira em uma das Big Four em auditoria de sistemas.
Atualmente, atua como Consultor de Cibersegurança no time de Professional Services da AWS na América Latina (Brasil), função que exerce há mais de 4 anos, com foco no atendimento a instituições financeiras.
Trabalhou como Coordenador de Segurança da Informação na maior empresa de desenvolvimento de software na América Latina. Anteriormente, atuou como consultor de Segurança da Informação, com foco em identificar e avaliar os riscos inerentes ao negócio e validar os controles existentes por meio de testes de invasão em infraestrutura interna/externa, aplicações Web e ERPs como SAP e TOTVS.
Foi responsável pela implementação da certificação ISO/IEC 27001:2013 na maior empresa de desenvolvimento de software da América Latina, potencializando a principal oferta de comercialização de software como serviço (SaaS) em datacenter próprio.