IAM Avançado: SCP, Permission Boundaries e Attribute-Based Access
O que é IAM Avançado e por que importa
Controle de acesso é um dos pilares da segurança em arquiteturas cloud. Enquanto políticas de permissão básicas funcionam para cenários simples, organizações crescem, equipes se diversificam e a necessidade de controles granulares se torna crítica. IAM Avançado na AWS combina três mecanismos complementares: Service Control Policies (SCP), Permission Boundaries e Attribute-Based Access Control (ABAC). Cada um resolve um problema específico e, quando combinados corretamente, criam uma camada de defesa robusta chamada de "layered security" ou defesa em profundidade.
Nesta jornada, você aprenderá não apenas como implementar essas ferramentas, mas quando e por quê usá-las. Vamos começar do zero, mas com profundidade técnica que o levará a cenários reais em produção.
Service Control Policies (SCP)
Entendendo o escopo e propósito
Service Control Policies são mecanismos de permissão que funcionam no nível de contas AWS e Organizational Units (OUs), não no nível de usuários ou funções individuais. Diferentemente das políticas de permissão tradicionais (Identity-Based Policies), SCPs atuam como um "teto" — definem o máximo de permissões que uma conta ou OU pode ter, independentemente do que qualquer política de usuário específico conceda.
Imagine uma organização com 50 contas AWS. O CISO quer garantir que nenhuma conta, sob nenhuma circunstância, possa desabilitar CloudTrail ou deletar logs. Uma SCP aplicada à raiz da organização garantirá isso. Um desenvolvedor pode ter permissão de administrador em sua conta, mas a SCP bloqueará essas ações perigosas.
Exemplo prático: Bloqueando ações críticas
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"logs:DeleteLogGroup",
"logs:DeleteLogStream"
],
"Resource": "*"
}
]
}
Esta política, quando anexada a uma OU, nega permanentemente qualquer tentativa de parar logging ou deletar logs, criando conformidade garantida. SCPs não concedem permissões — apenas restringem o que é permitido.
Implementação com AWS Organizations
SCPs precisam estar habilitadas no nível de organização. Use a AWS CLI ou Console para ativar a política de tipo SERVICE_CONTROL_POLICY e anexá-la a OUs específicas.
# Habilitar SCP (feito uma única vez)
aws organizations enable-policy-type \
--root-id r-xxxxx \
--policy-type SERVICE_CONTROL_POLICY
# Criar e anexar política a uma OU
aws organizations create-policy \
--content file://restrict-ec2.json \
--description "Bloqueia EC2 fora de regiões permitidas" \
--type SERVICE_CONTROL_POLICY
aws organizations attach-policy \
--policy-id p-xxxxx \
--target-id ou-xxxxx
SCPs são ideais para conformidade regulatória (PCI-DSS, HIPAA) e governança global. O custo cognitivo baixo e o impacto alto as tornam essenciais em ambientes corporativos.
Permission Boundaries
Criando limites de permissão granulares
Permission Boundaries definem o máximo de permissões que um usuário IAM ou função pode obter. Diferentemente de SCPs, elas funcionam no nível de identidade individual e permitem políticas mais específicas. Você pode ter um Permission Boundary que permite acesso a S3, EC2 e RDS, e qualquer política adicional anexada àquele usuário será "intersectada" com esse boundary.
O mecanismo é simples mas poderoso: a permissão final = intersecção de (políticas de permissão) ∩ (permission boundary). Se uma política concede s3:* mas o boundary bloqueia tudo exceto s3:GetObject, o usuário consegue apenas ler objetos S3.
Exemplo prático: Boundary para desenvolvedores
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"rds:*",
"logs:*",
"cloudwatch:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ec2:ModifyInstanceAttribute",
"rds:DeleteDBInstance",
"iam:*"
],
"Resource": "*"
}
]
}
Agora, ao criar uma função para um desenvolvedor, anexe essa boundary:
aws iam create-role \
--role-name DevTeamRole \
--assume-role-policy-document file://trust-policy.json \
--permissions-boundary arn:aws:iam::123456789012:policy/DeveloperBoundary
Mesmo que você adicione uma política que concede iam:CreateUser, o boundary bloqueará. Permission Boundaries são perfeitas para self-service em ambientes DevOps — desenvolvedores ganham autonomia dentro de limites seguros.
Attribute-Based Access Control (ABAC)
Tokens de atributo e decisões dinâmicas
ABAC é um paradigma onde permissões são baseadas em atributos — chave-valor associados a usuários, recursos e ambientes. Ao invés de criar políticas específicas para cada usuário, você cria regras baseadas em atributos. Exemplo: "usuários com o atributo department=Finance podem acessar buckets S3 com a tag confidentiality=Finance".
Isso reduz drasticamente a complexidade em organizações grandes. Se você tem 500 funcionários, criar 500 políticas específicas é insustentável. Com ABAC, você cria uma política genérica que funciona para todos os departamentos.
Exemplo prático: ABAC com tags de sessão
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::company-data/*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/Department": "${aws:ResourceTag/Department}"
}
}
}
]
}
Aqui, um usuário (com uma tag Department) consegue acessar objetos S3 apenas se tiverem a mesma tag de departamento. Para implementar:
# Criar usuário com tag
aws iam create-user --user-name alice
aws iam tag-user \
--user-name alice \
--tags Key=Department,Value=Finance Key=CostCenter,Value=12345
# Taggear recurso S3
aws s3api put-object-tagging \
--bucket company-data \
--key finance-report.xlsx \
--tagging 'TagSet=[{Key=Department,Value=Finance}]'
ABAC escala naturalmente. Adicione um novo departamento, atribua tags, e as políticas já funcionam. Combine com SCP e Permission Boundaries para defesa em múltiplas camadas: SCP governa globalmente, Permission Boundaries limitam por função, ABAC oferece granularidade por atributo.
Arquitetura Integrada: Do Conceito à Prática
Cenário real de implementação
Considere uma empresa fintech com 20 contas AWS em 4 regiões. A segurança exige:
1. Nenhuma conta pode desabilitar CloudTrail (SCP)
2. Desenvolvedores podem provisionar recursos, mas não deletar bancos de dados críticos (Permission Boundary)
3. Equipes acessam dados apenas de seus departamentos (ABAC)
A hierarquia fica assim:
Organization (raiz)
├── SCP: DenyDisableCloudTrail
├── OU: Finance
│ ├── Account: Finance-Prod
│ └── Account: Finance-Dev
│ └── Role: FinanceDeveloper
│ ├── Permission Boundary: DevBoundary
│ └── Policy Identity: S3AccessPolicy (com ABAC)
└── OU: Engineering
└── Account: Eng-Prod
Quando um desenvolvedor de Finance tenta acessar um bucket Engineering, a sequência é:
1. Verifica SCP (passa — não é CloudTrail)
2. Verifica Permission Boundary (passa — S3 é permitido)
3. Verifica Identity Policy + ABAC (falha — tags não combinam)
4. Acesso negado
Essa arquitetura escala e é auditável. Use CloudTrail para rastrear decisões de acesso e ajuste atributos conforme necessário.
Conclusão
Dominar IAM avançado significa entender que segurança não é um sistema único, mas camadas. SCPs protegem a organização contra erros catastróficos. Permission Boundaries fornecem guardrails para equipes de plataforma. ABAC oferece granularidade sem complexidade exponencial. Juntas, essas três tecnologias criam um modelo de confiança zero dentro da AWS que é escalável, auditável e mantível. Comece com SCP em produção (geralmente o ganho é imediato), evolua para Permission Boundaries em ambientes DevOps, e implemente ABAC quando sua organização atingir centenas de recursos.