Existe uma guerra fria que acontece diariamente em quase todas as empresas que operam na nuvem. De um lado, os Desenvolvedores, que precisam de agilidade para testar novas arquiteturas Serverless, criar funções Lambda, filas SQS e bancos de dados. Do outro, a equipe de Segurança (SecOps), que tem pavor de vazamento de dados e bloqueia qualquer tentativa de autonomia, exigindo que toda infraestrutura seja solicitada via abertura de chamados (tickets).
O resultado desse conflito? A inovação trava.
Para tentar resolver isso, muitas empresas cometem um erro fatal: acabam concedendo a permissão de AdministratorAccess para os desenvolvedores em contas de desenvolvimento, rezando para que nada dê errado.
Neste artigo, vamos apresentar a solução definitiva da AWS para esse impasse: o IAM Permissions Boundary (Limite de Permissões). Vamos entender como você pode dar autonomia para o seu time criar infraestrutura, garantindo matematicamente que eles nunca conseguirão explodir a segurança da conta.
1. A Ilusão do Acesso Restrito (O Problema da Escalada)
Imagine que a sua equipe de segurança decida dar um “meio-termo” para o desenvolvedor sênior. Eles criam uma política que permite que ele gerencie o AWS Lambda e crie novas funções (Roles) no IAM exclusivamente para essas Lambdas, mas negam o acesso ao Amazon RDS (onde estão os dados sensíveis dos clientes).
Parece seguro. O desenvolvedor não tem acesso ao banco de dados.
O problema é que, se você der a alguém a permissão irrestrita de iam:CreateRole e iam:PutRolePolicy, você acabou de dar a essa pessoa acesso de Administrador.
Como a escalada de privilégios acontece:
- O desenvolvedor cria uma nova Role (ex:
RoleMaliciosa). - Ele anexa a política de
AdministratorAccessa essa nova Role. - Ele configura um script simples no AWS Lambda para assumir essa
RoleMaliciosa. - O script agora tem acesso total à conta e faz o download de todo o banco de dados RDS.
Dar o poder de criar identidades (Roles) sem impor limites é a maior vulnerabilidade de governança na nuvem.
2. O Que É o IAM Permissions Boundary?
Para resolver o problema da escalada de privilégios, a Amazon introduziu o Permissions Boundary. Ele não é uma política que concede acesso; ele é uma política avançada que define o teto máximo (o limite absoluto) de permissões que uma identidade pode ter.
Quando você anexa um Permissions Boundary a um desenvolvedor ou a uma Role, as permissões efetivas passam a ser a interseção (apenas o que coincide) entre o que a política de identidade permite e o que o limite permite.
Se a política do desenvolvedor diz “Permitir Tudo”, mas o Boundary diz “Apenas EC2 e S3”, o desenvolvedor só terá acesso ao EC2 e ao S3. Qualquer tentativa de acessar o RDS será bloqueada.
3. A Matemática da Segurança na AWS
Para visualizar como o motor do IAM avalia essa configuração, confira o cenário onde um desenvolvedor tenta criar uma Role com mais poder do que deveria:
| Ação Solicitada | Política da Role (Identity-Based) | Limite Imposto (Permissions Boundary) | Permissão Efetiva (Resultado) |
| Ler bucket S3 | Permitido | Permitido | Permitido |
| Invocar Lambda | Permitido | Permitido | Permitido |
| Deletar RDS (Banco) | Permitido | Negado/Não Listado | Bloqueado (Access Denied) |
O limite de permissões sobrepõe qualquer política de acesso. Não importa se o desenvolvedor anexou a política de AdministratorAccess à Role; o Boundary atuará como um campo de força.
4. Implementação: Forçando o Uso do Limite
O verdadeiro truque ninja da delegação segura é permitir que os desenvolvedores criem suas próprias Roles, desde que eles apliquem o seu Permissions Boundary a elas.
Você, como administrador de segurança, cria uma política de Boundary chamada CorporateBoundary (que bloqueia RDS, CloudTrail, Billing, etc.).
Em seguida, você dá ao desenvolvedor a permissão de iam:CreateRole, mas usa a chave de condição iam:PermissionsBoundary para forçá-lo a usar o seu limite. Se ele tentar criar uma Role sem anexar o Boundary corporativo, a AWS bloqueará a criação.
Exemplo prático de política para o Desenvolvedor:
JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PermitirCriacaoDeRolesComLimite",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::111122223333:role/app-*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/CorporateBoundary"
}
}
}
]
}
Nesse cenário, o desenvolvedor ganha total autonomia. Ele não precisa mais abrir tickets para criar Lambdas ou as Roles associadas a elas. A inovação flui rapidamente, e a equipe de segurança tem a garantia matemática de que nenhuma Role criada nesse processo terá acesso aos dados críticos da empresa.
Conclusão
A segurança moderna não pode ser um gargalo para o desenvolvimento. O conceito de Zero Trust não significa impedir as pessoas de trabalharem, mas sim fornecer as “ferramentas certas dentro de um cercadinho inquebrável”.
Ao utilizar o IAM Permissions Boundary, sua empresa elimina o perigo mortal das políticas de AdministratorAccess nas mãos erradas, descentraliza a criação de infraestrutura e acaba de vez com os gargalos operacionais entre Devs e SecOps. O desenvolvimento ganha velocidade, e a segurança ganha paz de espírito.
