Intermediário

Same-account vs cross-account

Lição 11 · Módulo 3 — Modelo de avaliação

O detalhe que quase ninguém sabe

A avaliação IAM funciona diferente quando o principal e o recurso estão na mesma conta versus em contas diferentes. Esse é o detalhe que causa mais confusão em arquiteturas multi-conta.

Same-account: união

Quando principal e recurso estão na mesma conta, a AWS faz união: basta que a identity policy OU a resource policy conceda a permissão.

Exemplo: bucket meu-bucket na conta 111. Alice (IAM User na 111) acessa.

  • Se a identity policy da Alice permite s3:GetObject no bucket → Allow.
  • Se a bucket policy permite Alice → Allow.
  • Se ambas permitem → Allow (óbvio).
  • Se nenhuma permite → Implicit Deny.

Cross-account: interseção

Quando o recurso está em outra conta, a AWS exige que as duas lados autorizem. Interseção, não união.

Exemplo: bucket bucket-prod na conta 222. Bob (IAM User na conta 111) acessa.

  • A identity policy do Bob (na 111) precisa permitir s3:GetObject no bucket.
  • E a bucket policy (na 222) precisa permitir Bob.
  • Falta qualquer um dos dois → Deny.

Padrões cross-account

Existem três padrões comuns de acesso cross-account:

1. AssumeRole

recomendado

Bob assume uma role na conta 222 e usa as credenciais temporárias para acessar o bucket. Dois lados: a trust policy da role (na 222) permite o Bob assumi-la, e a identity policy do Bob (na 111) permite chamar sts:AssumeRole.

2. Resource policy com principal externo

limitado

A bucket policy na 222 lista o Bob da 111 como Principal e permite s3:GetObject. O Bob na 111 também precisa ter permissão em sua identity policy. Funciona para S3, SQS, SNS, KMS, Lambda, Secrets Manager — mas não para todos os serviços.

3. Resource sharing via RAM

organização

O AWS Resource Access Manager compartilha recursos suportados (subnets, Transit Gateway, License Manager…) entre contas sem policies manuais.

Confused deputy

No padrão 2 (resource policy), um risco clássico é o confused deputy: um serviço AWS na sua conta é "enganado" a usar sua autoridade em nome de um terceiro.

Mitigação: use a condition aws:SourceAccount ou aws:SourceArn na trust policy, garantindo que apenas o recurso específico do terceiro pode acionar a role. Para integrações com terceiros, adicione sts:ExternalId.

JSON
1
2
3
4
5
6
"Condition": {
  "StringEquals": {
    "aws:SourceAccount": "444455556666",
    "sts:ExternalId": "f9b3d2e1-unique-per-customer"
  }
}

Teste rápido

Conta A tem uma role 'ReadOnly'. Um user da conta B tem permissão sts:AssumeRole na sua identity policy, mas a trust policy da role em A não lista a conta B. Resultado ao tentar assumir?

Resumo

Same-account: união (basta um lado permitir). Cross-account: interseção (os dois precisam permitir). Em arquiteturas multi-conta, sempre pense nos dois lados. Use ExternalId e SourceAccount para prevenir confused deputy.

Referência Well-Architected

Esta lição está alinhada com a boa prática Analyze public and cross-account access do Well-Architected Framework.

Referências

Terminou esta lição?

Seu progresso fica salvo apenas neste navegador.