<h2>IAM Avançado: SCP, Permission Boundaries e Attribute-Based Access</h2>
<h3>O que é IAM Avançado e por que importa</h3>
<p>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.</p>
<p>Nesta jornada, você aprenderá não apenas <em>como</em> implementar essas ferramentas, mas <em>quando</em> e <em>por quê</em> usá-las. Vamos começar do zero, mas com profundidade técnica que o levará a cenários reais em produção.</p>
<h2>Service Control Policies (SCP)</h2>
<h3>Entendendo o escopo e propósito</h3>
<p>Service Control Policies são mecanismos de permissão que funcionam no nível de <strong>contas AWS e Organizational Units (OUs)</strong>, 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.</p>
<p>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.</p>
<p><strong>Exemplo prático: Bloqueando ações críticas</strong></p>
<pre><code class="language-json">{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"logs:DeleteLogGroup",
"logs:DeleteLogStream"
],
"Resource": "*"
}
]
}</code></pre>
<p>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.</p>
<h3>Implementação com AWS Organizations</h3>
<p>SCPs precisam estar habilitadas no nível de organização. Use a AWS CLI ou Console para ativar a política de tipo <code>SERVICE_CONTROL_POLICY</code> e anexá-la a OUs específicas.</p>
<pre><code class="language-bash"># 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</code></pre>
<p>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.</p>
<h2>Permission Boundaries</h2>
<h3>Criando limites de permissão granulares</h3>
<p>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.</p>
<p>O mecanismo é simples mas poderoso: a permissão final = intersecção de (políticas de permissão) ∩ (permission boundary). Se uma política concede <code>s3:*</code> mas o boundary bloqueia tudo exceto <code>s3:GetObject</code>, o usuário consegue apenas ler objetos S3.</p>
<p><strong>Exemplo prático: Boundary para desenvolvedores</strong></p>
<pre><code class="language-json">{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"rds:*",
"logs:*",
"cloudwatch:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ec2:ModifyInstanceAttribute",
"rds:DeleteDBInstance",
"iam:*"
],
"Resource": "*"
}
]
}</code></pre>
<p>Agora, ao criar uma função para um desenvolvedor, anexe essa boundary:</p>
<pre><code class="language-bash">aws iam create-role \
--role-name DevTeamRole \
--assume-role-policy-document file://trust-policy.json \
--permissions-boundary arn:aws:iam::123456789012:policy/DeveloperBoundary</code></pre>
<p>Mesmo que você adicione uma política que concede <code>iam:CreateUser</code>, o boundary bloqueará. Permission Boundaries são perfeitas para self-service em ambientes DevOps — desenvolvedores ganham autonomia dentro de limites seguros.</p>
<h2>Attribute-Based Access Control (ABAC)</h2>
<h3>Tokens de atributo e decisões dinâmicas</h3>
<p>ABAC é um paradigma onde permissões são baseadas em <strong>atributos</strong> — 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 <code>department=Finance</code> podem acessar buckets S3 com a tag <code>confidentiality=Finance</code>".</p>
<p>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.</p>
<p><strong>Exemplo prático: ABAC com tags de sessão</strong></p>
<pre><code class="language-json">{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::company-data/*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/Department": "${aws:ResourceTag/Department}"
}
}
}
]
}</code></pre>
<p>Aqui, um usuário (com uma tag <code>Department</code>) consegue acessar objetos S3 apenas se tiverem a mesma tag de departamento. Para implementar:</p>
<pre><code class="language-bash"># 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}]'</code></pre>
<p>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.</p>
<h2>Arquitetura Integrada: Do Conceito à Prática</h2>
<h3>Cenário real de implementação</h3>
<p>Considere uma empresa fintech com 20 contas AWS em 4 regiões. A segurança exige:</p>
<ol>
<li>Nenhuma conta pode desabilitar CloudTrail (SCP)</li>
<li>Desenvolvedores podem provisionar recursos, mas não deletar bancos de dados críticos (Permission Boundary)</li>
<li>Equipes acessam dados apenas de seus departamentos (ABAC)</li>
</ol>
<p>A hierarquia fica assim:</p>
<pre><code>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</code></pre>
<p>Quando um desenvolvedor de Finance tenta acessar um bucket Engineering, a sequência é:</p>
<ol>
<li>Verifica SCP (passa — não é CloudTrail)</li>
<li>Verifica Permission Boundary (passa — S3 é permitido)</li>
<li>Verifica Identity Policy + ABAC (falha — tags não combinam)</li>
<li>Acesso negado</li>
</ol>
<p>Essa arquitetura escala e é auditável. Use CloudTrail para rastrear decisões de acesso e ajuste atributos conforme necessário.</p>
<h2>Conclusão</h2>
<p>Dominar IAM avançado significa entender que <strong>segurança não é um sistema único, mas camadas</strong>. 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.</p>
<h2>Referências</h2>
<ul>
<li><a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html" target="_blank" rel="noopener noreferrer">AWS IAM Policies and Permissions</a></li>
<li><a href="https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html" target="_blank" rel="noopener noreferrer">Service Control Policies - AWS Organizations</a></li>
<li><a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html" target="_blank" rel="noopener noreferrer">Managing Permissions with Permission Boundaries</a></li>
<li><a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html" target="_blank" rel="noopener noreferrer">ABAC with AWS IAM</a></li>
<li><a href="https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html" target="_blank" rel="noopener noreferrer">AWS Well-Architected Security Pillar</a></li>
</ul>