🔑

IAM Avançado: Policies JSON, STS e Organizations

⏱ 14 min de leitura·+75 XP

No CLF-C02 você aprendeu o que é IAM. No SAA-C03, espera-se que você leia uma policy JSON e responda se ela é restritiva demais, permissiva demais, ou incompleta. Também espera-se entender cross-account access, STS, Organizations e Identity Center — o tripé de identidade em ambientes multi-conta.

Onde isso entra no exame

📘 Domain 1 — Design Secure Architectures· 30%

Identidade é o maior bloco do domínio mais pesado. Espere pelo menos 8–10 questões envolvendo: leitura de policies JSON, cross-account via Role Assumption, SCPs em Organizations, trust policies, least privilege.

Anatomia de uma IAM Policy JSON

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnly",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/DataReader" },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-data-bucket",
        "arn:aws:s3:::my-data-bucket/*"
      ],
      "Condition": {
        "Bool": { "aws:MultiFactorAuthPresent": "true" },
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

Elemento	Função
Version	Sempre "2012-10-17" (versão mais recente da policy language)
Sid	Statement ID — label opcional para identificar
Effect	"Allow" ou "Deny"
Principal	QUEM pode fazer a ação (obrigatório em resource policies; proibido em identity policies)
Action	O QUE pode fazer (s3:GetObject, ec2:*, iam:PassRole)
Resource	EM QUAIS recursos (ARN específico, wildcard, array)
Condition	SOB QUAIS condições (MFA, IP, região, tag, etc.)

Identity-based vs Resource-based policies

Aspecto	Identity-based	Resource-based
Attached a	User, Group, Role	Recurso (S3 bucket, SQS queue, SNS topic, KMS key, Lambda)
Define	O que esta identidade pode fazer	Quem pode usar este recurso
Principal element	❌ Proibido	✅ Obrigatório
Cross-account	Não concede acesso de outra conta	Pode conceder (ex: S3 bucket policy)
Uso típico	Policies padrão, permissões de roles	Bucket policies, KMS keys, SQS cross-account

💡

Regra de avaliação: uma ação é permitida se há Allow em qualquer policy aplicável (identity OU resource) E não há Deny explícito. Qualquer Deny explícito em qualquer policy bloqueia tudo.

Ordem de avaliação — a árvore de decisão IAM

🗺️ Como a AWS decide se uma ação é permitida


  Requisição recebida
         │
         ▼
  ┌───────────────────┐
  │ Há Deny explícito │───── Sim ──► ❌ NEGADO
  │ em QUALQUER       │
  │ policy aplicável? │
  └─────────┬─────────┘
            │ Não
            ▼
  ┌───────────────────┐
  │ SCP da conta      │───── Nega ──► ❌ NEGADO
  │ permite a ação?   │
  └─────────┬─────────┘
            │ Permite
            ▼
  ┌───────────────────┐
  │ Há Allow em       │───── Não ───► ❌ NEGADO (implicit deny)
  │ identity OU       │
  │ resource policy?  │
  └─────────┬─────────┘
            │ Sim
            ▼
  ┌───────────────────┐
  │ Permission        │───── Nega ──► ❌ NEGADO
  │ boundary permite? │
  │ (se houver)       │
  └─────────┬─────────┘
            │ Permite
            ▼
       ✅ PERMITIDO

STS — Security Token Service

STS emite credenciais temporárias (Access Key ID + Secret + Session Token) para IAM Roles. É o mecanismo por trás de cross-account, federated login e EC2 Instance Profiles.

API STS	Uso
AssumeRole	Role → Role (cross-account, escalação de privilégio)
AssumeRoleWithSAML	Identity Provider SAML 2.0 (AD FS, Okta enterprise)
AssumeRoleWithWebIdentity	OpenID Connect (Google, Facebook, Cognito)
GetSessionToken	Gerar credenciais temporárias para IAM User (geralmente com MFA)
GetFederationToken	Broker emite credenciais para app customizado
DecodeAuthorizationMessage	Decodificar mensagens de negação encriptadas

💡

Duração: tokens temporários duram de 15 min a 12 horas (configurável por role). Quando expiram, você re-assume. Isso é mais seguro que IAM User access keys (perpetuais até rotação manual).

Cross-Account Access — o pattern mais cobrado

🗺️ Cross-account via AssumeRole


   Conta A (Producer)              Conta B (Owner)
   ─────────────────              ───────────────
                                  ┌─────────────────┐
   ┌──────────────┐               │ Role: DataAccess │
   │ Lambda       │               │ Trust Policy:    │
   │ Function     │──sts:Assume──►│  Principal: A    │
   └──────────────┘               │ Perm Policy:     │
         ▲                        │  s3:GetObject    │
         │                        │  em bucket-B     │
   Credenciais                    └─────────────────┘
   temporárias                              │
         │                                  ▼
         └──── usa token para ──────► S3 Bucket (B)

Passos:

Na conta B: crie uma IAM Role “DataAccess” com permission policy (ex: S3 GetObject).
Trust policy da Role: Principal: arn:aws:iam::111122223333:root (conta A inteira) ou ARN específico da Role/User de A.
Na conta A: Role/User precisa ter permissão sts:AssumeRole para o ARN da Role da conta B.
Em runtime, conta A chama sts:AssumeRole, recebe credenciais temporárias, usa para operar em B.

json

// Trust policy em Conta B — Role "DataAccess"
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:role/LambdaRole" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-secret-id" }
    }
  }]
}

⚠️

ExternalId:quando um 3rd party (ex: SaaS de monitoramento) assume sua role, use ExternalId para evitar “confused deputy”. O 3rd party fornece um ID único que você coloca na trust policy — sem ele, o AssumeRole falha.

AWS Organizations

🗺️ Estrutura de Organizations


         Management Account (billing, root da Org)
                     │
        ┌────────────┼────────────┐
        │            │            │
        ▼            ▼            ▼
     [ OU: Prod ] [ OU: Dev ] [ OU: Security ]
        │            │            │
      ┌─┴─┐        ┌─┴─┐        ┌─┴──┐
   Acc1 Acc2    Acc3 Acc4    LogArchive
                                AuditAccount

Componentes:

• Management Account — dona da Organization, paga a fatura consolidada
• Member Accounts — contas invitadas ou criadas dentro
• Organizational Units (OUs) — agrupam contas por função (Prod, Dev, Security)
• Service Control Policies (SCPs) — guardrails aplicados a OU/conta
• Consolidated Billing — fatura única, soma de volume para descontos
• RI/Savings Plans sharing — RIs compradas em uma conta beneficiam outras

Service Control Policies (SCPs)

SCPs definem o teto de permissões de uma conta. Não concedem nada — apenas restringem o que IAM permissions da conta podem fazer.

json

// SCP: impedir que qualquer conta na OU saia de us-east-1 e sa-east-1
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOtherRegions",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["us-east-1", "sa-east-1"]
      }
    }
  }]
}

🚨

Atenção: SCPs NÃO se aplicam à Management Account — ela é imune por design. Nunca rode workloads de produção lá.

IAM Identity Center (ex-AWS SSO)

Single Sign-On centralizado para múltiplas contas AWS. Usuários autenticam uma vez (via AD, Okta ou Identity Store interno) e recebem um portal com acesso pré-configurado a contas/roles.

Componente	Função
Identity Source	AWS nativo, Active Directory (AD Connector ou Managed AD), ou external IdP (Okta, Azure AD)
Permission Set	Coleção de policies que vira uma Role IAM em cada conta
Account Assignment	Usuário/grupo + Permission Set + Conta
User Portal	URL única (d-xxx.awsapps.com/start) — login e lista de contas/roles

Identity Federation

Tipo	Protocolo	Uso
Enterprise (SAML)	SAML 2.0	AD FS, corporate IdP
Web Identity	OIDC (OpenID Connect)	Google, Facebook, Apple (via Cognito)
Amazon Cognito	User pools + Identity pools	Usuários finais de apps mobile/web
Custom broker	STS GetFederationToken	Legacy apps com lógica customizada

Permission Boundaries

Permission Boundary é uma policy anexada a uma IAM Role/User que define o máximo de permissões que ela pode ter, independente do que suas policies conceda. Usada em delegated administration — o admin pode criar Roles, mas elas nunca passam do limite do boundary.

💡

Regra: permissão efetiva = policies ∩ permission boundary ∩ SCPs. Qualquer um bloqueia, bloqueia tudo.

Cenários de decisão

📋 Empresa tem 20 contas AWS e quer política única proibindo criação de recursos fora das regiões BR

✓ Organizations + SCP com aws:RequestedRegion

SCP aplicada na OU cobre todas as contas automaticamente. Tentativa de criar recurso em outra região falha antes mesmo de chegar no IAM. Usar IAM policies em cada conta seria impossível de manter.

📋 Lambda em Conta A precisa ler objeto em S3 da Conta B

✓ Opção 1: Bucket Policy (B) permite ARN da Lambda Role (A). Opção 2: IAM Role em B com trust da Lambda Role (A).

Opção 1 é mais simples (só modificar bucket policy). Opção 2 é melhor se Lambda precisa de várias actions em B ou cross-region. SAA-C03 testa ambos — leia o cenário.

📋 Dev team quer criar seus próprios IAM Roles, mas você quer garantir que nenhuma role criada tenha mais que S3:* e DynamoDB:*

✓ Permission Boundary obrigatório para todas as Roles criadas pelo team

Você concede iam:CreateRole CONDICIONADO a um boundary específico. Mesmo se o dev tentar attach AdministratorAccess, o boundary limita as permissões efetivas.

📋 Empresa usa Okta como IdP. Quer que cada funcionário acesse a AWS sem ter IAM User

✓ IAM Identity Center + Okta como external Identity Source

Sem credenciais permanentes. Usuários vêm do Okta (MFA, onboarding/offboarding automático). Identity Center mapeia grupos Okta em Permission Sets nas contas AWS.

Exemplos de CLI

bash

# Assumir role cross-account
aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/DataAccess \
  --role-session-name my-session \
  --external-id unique-secret-id

# Listar OUs e contas de uma Organization
aws organizations list-organizational-units-for-parent \
  --parent-id r-examplerootid
aws organizations list-accounts

# Attach SCP a uma OU
aws organizations attach-policy \
  --policy-id p-examplepolicy \
  --target-id ou-exampleou

# Simular avaliação de IAM policy
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/MyRole \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/file.txt

⚠️

Pegadinhas clássicas do SAA-C03:

• Principal só existe em resource-based policies (bucket policy, KMS key policy). Em identity policies é proibido.
• Deny explícito vence qualquer Allow — sempre.
• SCP não concede — só restringe.
• IAM Instance Profile é o container que injeta Role credentials em EC2 — não é a Role em si.
• PassRole: dar permissão para alguém criar um serviço que USE uma Role exige iam:PassRole.

Perguntas típicas (Q&A)

❓ Como garantir que um recurso só é acessível se MFA estiver ativo?

Adicionar Condition aws:MultiFactorAuthPresent: true na policy (ou Deny explícito se false). Muitas empresas restringem ações sensíveis (ex: deletar RDS, criar IAM User) apenas com MFA.

❓ Qual a diferença entre IAM Role e IAM User?

User = identidade permanente com credenciais de longo prazo (access keys, senha). Role = identidade assumível que emite credenciais temporárias via STS. Best practice moderna: use Roles sempre; Users só quando realmente necessário (ex: integração externa legada).

❓ Como proteger a Management Account de uma Organization?

MFA em root, bloquear/excluir access keys do root, não rodar workloads lá, usar CloudTrail + GuardDuty com alertas, limitar IAM Users, delegar administration para conta separada (delegated admin for services).

❓ Qual a ordem de avaliação quando uma requisição envolve S3 de outra conta?

Deny explícito (em qualquer policy) → SCP da Org → Resource policy (bucket policy) → Identity policy (IAM) → Permission boundary → Session policy. Qualquer Deny bloqueia. Para Allow, precisa ter Allow em pelo menos uma das policies aplicáveis.

✅

Take-aways: Policy JSON tem 7 elementos-chave (Version, Sid, Effect, Principal, Action, Resource, Condition). Identity vs Resource policies diferem em onde ficam anexadas e se precisam de Principal. STS emite credenciais temporárias (AssumeRole é a estrela). Organizations + SCPs = guardrails multi-conta. Identity Center = SSO corporativo. Permission Boundary = teto para roles delegadas. Cross-account = AssumeRole ou resource-based policy com Principal.

🧩

Quiz rápido

3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito