Segundo post do Nível Avançado da série AWS IAM. Ambientes reais raramente têm uma única conta AWS. Hoje você vai aprender a compartilhar acesso entre contas da forma certa: com roles e credenciais temporárias — o padrão que sustenta arquiteturas multi-conta seguras.
📚 O que você vai aprender neste post:
- Por que usar múltiplas contas AWS;
- Um exemplo prático de AssumeRole entre contas (as duas pontas);
- Como assumir a role pela CLI;
- O papel do External ID contra o “confused deputy”;
- Quando usar policies baseadas em recurso.
Por que múltiplas contas?
Separar ambientes em contas distintas (produção, desenvolvimento, segurança, faturamento) é uma prática recomendada pela AWS: isola riscos, simplifica a cobrança, cria limites naturais de segurança e reduz o raio de impacto (blast radius) de um incidente. Se a conta de desenvolvimento for comprometida, produção permanece intacta.
Mas isso cria uma necessidade: como uma identidade da conta A acessa um recurso na conta B? A resposta errada é criar usuários e chaves em cada conta (multiplicando segredos). A resposta certa é o acesso cross-account via AssumeRole.
🛠️ Mão na massa: AssumeRole entre contas
Cenário: a conta A (111111111111) precisa ler um bucket na conta B (222222222222). Passo a passo:
1) Na conta B, crie uma role (AcessoLeituraS3) cuja trust policy confia na conta A:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "id-secreto-combinado" } } } ] }
2) Na conta A, a identidade precisa de permissão para chamar o AssumeRole na role da conta B:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/AcessoLeituraS3" } ] }
3) Assuma a role pela CLI e use as credenciais temporárias retornadas:
aws sts assume-role \ --role-arn arn:aws:iam::222222222222:role/AcessoLeituraS3 \ --role-session-name minha-sessao \ --external-id id-secreto-combinado
O STS devolve um Access Key ID, um Secret e um Session Token temporários, válidos na conta B. Simples, auditável e sem chaves permanentes.
O papel do External ID
Note o sts:ExternalId nos exemplos. Ele é fundamental quando você concede acesso a terceiros (como um fornecedor SaaS de monitoramento), pois previne o chamado “confused deputy” — um ataque em que um terceiro legítimo é induzido, por um cliente malicioso, a usar seu acesso para atingir a conta de outra vítima. O External ID é um segredo combinado que amarra a confiança àquele cliente específico. Sempre exija um em cenários com parceiros externos.
Policies baseadas em recurso: uma alternativa
Para alguns serviços (S3, SQS, SNS, KMS, Lambda), você pode conceder acesso cross-account diretamente na policy do recurso, sem assumir role. Por exemplo, uma bucket policy no S3 pode permitir que a conta A leia objetos. A diferença prática: com AssumeRole, a identidade “vira” alguém da conta B temporariamente; com resource-based policy, ela age como si mesma, da conta A, e o recurso é que a autoriza. Escolha conforme o serviço e o padrão de acesso desejado.
⚠️ Erros comuns
- Conceder acesso a terceiros sem External ID — abre espaço para o “confused deputy”.
- Confiar na conta inteira (
:root) quando bastaria uma role específica — amplo demais. - Criar usuários espelho em cada conta — exatamente o que o cross-account evita.
- Esquecer que são necessárias as duas pontas — a trust policy na B e a permissão de AssumeRole na A.
💡 Resumo dos pontos-chave
Compartilhe acesso entre contas com AssumeRole (trust policy na conta dona + permissão de AssumeRole na conta que acessa), não com usuários duplicados. Use External ID com terceiros. Para certos serviços, resource-based policies são uma alternativa direta. Tudo com credenciais temporárias e auditável.
Encadeamento de roles e duração da sessão
Em arquiteturas multi-conta, é comum “encadear” roles: uma identidade assume uma role na conta B e, a partir dela, assume outra na conta C. A AWS permite isso (role chaining), mas há um detalhe importante — ao encadear, a duração máxima da sessão é limitada a uma hora, independentemente do valor configurado na role. Planeje seus fluxos considerando essa expiração para evitar interrupções em processos longos.
Também é boa prática nomear as sessões com --role-session-name significativos (como o nome de quem assumiu), pois esse nome aparece no CloudTrail. Em uma auditoria, poder ver “quem” estava por trás de uma sessão assumida faz toda a diferença na hora de rastrear uma ação.
Restringindo à sua organização
Em ambientes com AWS Organizations, uma condição poderosa é a aws:PrincipalOrgID. Com ela, uma resource-based policy pode liberar acesso a “qualquer conta da minha organização” sem listar cada ID de conta manualmente — e, o melhor, sem correr o risco de expor o recurso a contas de fora. É a forma elegante de compartilhar recursos internamente à medida que novas contas entram na organização.
Some a isso a delegação de administração (delegated administrator) para tirar carga da conta de gerenciamento, e você tem um modelo cross-account que escala com segurança conforme a empresa cresce.
No próximo post
Fecharemos o Nível Avançado com federação de identidades e o IAM Identity Center — como dar acesso a pessoas usando o diretório corporativo, sem criar usuários IAM. 🚀
Informações sobre o autor
Dennis Silva atua com Segurança da Informação e Cibersegurança há +18 anos e iniciou sua carreira em uma das Big Four em auditoria de sistemas.
Atualmente, atua como Consultor de Cibersegurança no time de Professional Services da AWS na América Latina (Brasil), função que exerce há mais de 4 anos, com foco no atendimento a instituições financeiras.
Trabalhou como Coordenador de Segurança da Informação na maior empresa de desenvolvimento de software na América Latina. Anteriormente, atuou como consultor de Segurança da Informação, com foco em identificar e avaliar os riscos inerentes ao negócio e validar os controles existentes por meio de testes de invasão em infraestrutura interna/externa, aplicações Web e ERPs como SAP e TOTVS.
Foi responsável pela implementação da certificação ISO/IEC 27001:2013 na maior empresa de desenvolvimento de software da América Latina, potencializando a principal oferta de comercialização de software como serviço (SaaS) em datacenter próprio.