Modelo de Permissões IAM com Políticas, Roles e Permission Boundaries do Zero ao Nível Profissional
_Category: Identity & Access_
Toda a segurança AWS converge para o IAM. Quem (Principal) pode fazer o quê (Action) em qual serviço (Resource) — essa tríade é o alicerce da arquitetura de segurança e o domínio mais cobrado no SCS-C03. Acesso entre contas falhando sem explicação, confusão entre Permission Boundary e SCP, Trust Policy esquecida: vamos desmontar cada armadilha com clareza e exemplos práticos.
---
Os quatro pilares do IAM: Principal, Action, Resource, Condition
O IAM determina permissões combinando quatro elementos. Pense num sistema de controle de acesso predial: cada solicitação passa por um torniquete que verifica quem você é, o que quer fazer, onde quer fazer e sob quais condições.
Principal: quem faz a solicitação. Pode ser um usuário IAM, uma role IAM, um serviço AWS ou uma conta externa. Action: o que está sendo tentado. Chamadas de API como , e . Resource: sobre qual recurso. Identificado pelo ARN — um bucket específico, uma role, uma chave KMS. Condition: em que circunstâncias. Endereço IP, horário, presença de MFA, região, tags e muito mais.
Uma política IAM é um documento JSON que descreve esses quatro elementos dentro de blocos Statement. Cada Statement contém Effect (Allow ou Deny), Principal, Action, Resource e, opcionalmente, Condition. Conhecer as chaves de condição mais comuns acelera muito a leitura dos cenários do exame:
— bloqueio automático por período. A condição é colocada num bloco Allow; quando não satisfeita, aplica-se um Deny implícito. — verifica se MFA foi apresentado. Com credenciais de longo prazo o valor é sempre false, portanto basta um Deny quando o valor for false. — restrição de região. Serviços globais como IAM, CloudFront e Route 53 precisam ser excluídos via NotAction para não quebrarem. — bloqueia em massa contas fora da organização. combinado com — une escopo de VPC e tags obrigatórias com lógica AND.
---
Os seis tipos de política IAM
As políticas que controlam permissões no IAM se dividem em seis categorias, cada uma responsável por uma camada diferente na avaliação. Saber em qual camada cada política atua é fundamental para diagnosticar acessos negados.
| Tipo de Política | Alvo de Aplicação | Função Principal | Acesso Cross-Account | |------------------|-------------------|-----------------|----------------------| | Identity-based Policy | Usuários, grupos e roles IAM | Define o que o principal pode fazer | Não | | Resource-based Policy | Buckets S3, chaves KMS, filas SQS etc. | Define quem pode acessar o recurso | Sim (especifica o Principal) | | Permission Boundary | Usuários ou roles IAM individuais | Limita o teto máximo de permissões | Não | | SCP (Service Control Policy) | OUs e contas do AWS Organizations | Define o limite máximo permitido para toda a conta | Toda a organização | | Session Policy | Sessões temporárias STS | Restrição adicional no nível da sessão | Não | | ACL (Access Control List) | S3 e alguns outros serviços | Controle de acesso legado (não recomendado) | Sim |
Uma analogia para fixar: a Identity-based Policy é a lista de acessos do crachá do colaborador; a Resource-based Policy é a placa na porta da sala de reuniões com "somente estas pessoas podem entrar"; a Permission Boundary é o crachá de trainee com "acesso liberado até o 3.º andar"; o SCP é o regulamento de acesso de toda a empresa; a Session Policy é o crachá temporário de visitante.
A Resource-based Policy é o único mecanismo nativo para permitir acesso cross-account, pois fica no próprio recurso. Tanto o Permission Boundary quanto o SCP apenas reduzem permissões — eles nunca concedem acesso por si sós.
---
Lógica de avaliação de políticas: Deny explícito e ordem de precedência
Quando uma solicitação chega, o AWS coleta todas as políticas relevantes e as avalia numa ordem definida. A regra de ouro é uma só: um Deny explícito, de qualquer política, prevalece sobre qualquer Allow.
A ordem de avaliação é: 1. Deny explícito, 2. SCP (ambientes com Organizations), 3. Permission Boundary, 4. Resource-based Policy, 5. Identity-based Policy. Se nenhuma camada tiver um Allow, o resultado é um Deny implícito.
A diferença entre acesso na mesma conta e entre contas é um ponto crítico do exame:
| Tipo de Acesso | Requisito | |----------------|-----------| | S3 na mesma conta | Identity-based Policy OU Resource-based Policy — basta uma das duas com Allow | | S3 entre contas | Identity-based Policy E Resource-based Policy (bucket policy) — as duas precisam ter Allow |
Mesmo uma role com AdministratorAccess não consegue acessar um bucket de outra conta se a bucket policy não listar explicitamente essa role como Principal permitida. Outra armadilha clássica é o nível do ARN no S3: exige (ARN de objeto). Usar apenas o ARN do bucket resulta em Access Denied.
---
Roles e AssumeRole: credenciais temporárias para acesso entre contas e serviços
Uma IAM Role é o equivalente a um crachá de acesso temporário para outro departamento. O STS (Security Token Service) emite tokens temporários que expiram automaticamente entre 15 minutos e 12 horas.
Toda role precisa de duas políticas distintas:
Trust Policy: define quem pode assumir a role. O campo Principal recebe uma conta AWS, uma role IAM ou um serviço AWS. Permission Policy: define o que quem assumiu a role pode fazer.
Para que o EC2 acesse o S3, a Permission Policy precisa ter permissões de S3 e a Trust Policy precisa ter como Principal. Se o serviço não estiver na Trust Policy, a assunção da role falha antes mesmo de avaliar as permissões.
AssumeRole entre contas: a Trust Policy da role na conta de destino precisa permitir a conta de origem, e a Identity-based Policy do principal na conta de origem precisa incluir . Ambas as condições devem ser atendidas.
Ordem de precedência de credenciais no AWS CLI: variáveis de ambiente, arquivo credentials, perfil config, IMDS (role). Se o EC2 tem uma role associada mas existe um arquivo credentials local, o arquivo prevalece — isso causa comportamentos inesperados em ambientes de produção.
Principais mecanismos de emissão de credenciais temporárias: EC2 Instance Profile (rotação automática via IMDS), Cognito Identity Pool (STS-based, inclusive para usuários convidados), IAM Roles Anywhere (substitui chaves de longo prazo em servidores on-premises usando certificados X.509).
---
Permission Boundary vs SCP: os dois conceitos que mais geram confusão
Permission Boundary e SCP são ambos ferramentas de restrição de permissões, mas atuam em alvos e escopos completamente diferentes. Misturá-los é uma das causas mais frequentes de erros no exame.
| Aspecto | Permission Boundary | SCP | |---------|--------------------|---------| | Alvo | Usuário ou role IAM individual | OU ou conta inteira no AWS Organizations | | Onde configurar | Console IAM (por usuário ou role) | Console do Organizations | | Concede permissão? | Não — apenas define o limite superior | Não — apenas define o máximo permitido | | Cálculo da permissão efetiva | Identity-based Policy intersectado com Permission Boundary | SCP intersectado com Identity-based Policy intersectado com Permission Boundary | | Caso de uso típico | Controlar o teto de permissões de roles criadas pela equipe de desenvolvimento | Restringir regiões ou serviços para toda a organização |
O Permission Boundary é ideal quando você quer dar autonomia para equipes de desenvolvimento criarem suas próprias roles sem risco de escalada de privilégios. O time de segurança define a política de Boundary e usa a condição no para forçar sua aplicação. Mesmo que o desenvolvedor tente criar uma role com AdministratorAccess, o Boundary bloqueia o excesso.
O SCP se aplica a Organizations inteiros ou a OUs específicas. A conta de gerenciamento do Organizations nunca é afetada por SCPs. O SCP não concede permissão alguma — ele apenas define o envelope máximo. Para restrições individuais, use Permission Boundary, não SCP.
!Permission Boundary vs SCP
Federation e IAM Identity Center: integração com identidades externas e SSO
Criar um usuário IAM para cada colaborador é ineficiente e aumenta a superfície de ataque. Integrar o Active Directory ou qualquer IdP externo com a AWS via Federation é a abordagem recomendada.
Federation SAML 2.0: o IdP autentica o usuário e emite um SAML Assertion; o STS valida o assertion e emite credenciais temporárias. Com múltiplas contas, cada uma precisa de configuração individual, o que aumenta a carga operacional.
Federation baseado em OIDC (Web Identity Federation): implementado via Cognito usando . Permite que usuários de aplicativos móveis autenticados via provedores sociais acessem recursos AWS sem possuir uma identidade IAM.
IAM Identity Center (antigo AWS SSO): integrado ao Organizations, centraliza o SSO para centenas de contas com uma única identidade. O AD Connector autentica contra o Active Directory on-premises sem sincronizar dados — funciona como proxy de autenticação.
Ordem de configuração do Identity Center: ativar na conta de gerenciamento do Organizations, escolher a fonte de identidade, criar Permission Sets, atribuir usuários ou grupos a contas. Se um Permission Set incluir uma Customer Managed Policy, essa política precisa existir previamente em cada conta-membro de destino — caso contrário, a atribuição falha.
---
Cenários IAM que mais derrubam candidatos no exame
Veja as armadilhas mais recorrentes nos cenários de prova e como identificá-las rapidamente.
Falha de acesso S3 entre contas: mesmo que a role na conta de carga de trabalho tenha permissões S3, se a bucket policy da conta central não listar o Principal correspondente, o acesso é negado. A bucket policy precisa autorizar explicitamente o ARN da role ou o ID da conta de origem.
Confusão com ARN do usuário root: o usuário root tem o ARN . O ARN representa um usuário IAM comum chamado "roo