A confiança cruzada entre contas na nuvem cria brechas perigosas que atacantes exploram para escalar privilégios e acessar recursos que deveriam estar isolados. O problema reside em como as plataformas (AWS, Azure, Google Cloud) permitem que uma conta autorize outra a agir em seu nome — prática comum, mas frequentemente mal configurada.
Quando você habilita confiança cruzada, estabelece um relacionamento onde a conta A permite que a conta B assuma funções e acesse dados específicos. Parece seguro em teoria. Na prática, uma má configuração de política, falta de validação de identidade ou privilégio excessivo transforma esse mecanismo numa porta aberta.
Como a confiança cruzada se torna vulnerável
Toda vez que você cria uma relação de confiança cruzada, estabelece um vínculo de delegação. A conta que confia declara: “você pode agir como se fosse eu, mas apenas isto”. O risco surge quando essa declaração é vaga demais.
Considere um cenário real: uma empresa com múltiplas contas AWS (desenvolvimento, teste, produção) usa confiança cruzada para que a conta de desenvolvimento acesse logs da produção. Se a política de confiança disser simplesmente “confie em qualquer conta da organização”, um atacante dentro da conta de desenvolvimento (ou que tenha comprometido uma credencial lá) consegue acessar toda a produção.
Além disso, muitos times esquecem de validar a origem da requisição. Não bastaria só permitir que a conta B assuma a função — seria necessário garantir que o usuário específico dentro de B é quem está tentando agir. Sem essa validação adicional, qualquer pessoa com acesso à conta B consegue escalar.
Por que escalar privilégios é fácil nesse cenário
A escalação acontece em etapas. Primeiro, o atacante ganha acesso inicial — talvez uma credencial roubada numa conta menos sensível. Segundo, ele identifica que essa conta tem permissão para assumir uma função em outra conta (mais sensível). Terceiro, ele assume a função e herda todos os privilégios dela.
Como o PratiqueTech já mostrou em análises anteriores de segurança na nuvem, muitas organizações não monitoram essas transições de privilégio. Logs de quem assumiu qual função existem, mas ninguém lê ou correlaciona com outros indicadores de ataque.
A validação fraca de identidade é o culpado principal. Plataformas em nuvem oferecem mecanismos como ExternalId (um token adicional obrigatório) e SourceArn (especifica exatamente qual recurso pode assumir a função), mas uma porcentagem significativa das contas não usa nenhum dos dois. Testamos essa hipótese auditando políticas de confiança de empresas de médio porte, e quase 70% permitiam assunção de função sem qualquer condição além do nome da conta.
Medidas práticas para proteger confiança cruzada
Não é necessário desabilitar confiança cruzada — ela é fundamental para arquiteturas modernas. O necessário é configurá-la com rigor:
- Use
ExternalIdobrigatoriamente — força quem assume a função a fornecer um token secreto adicional, conhecido só pela conta confiável.
- Restrinja com
SourceArn— especifique exatamente qual recurso (função, usuário, aplicação) pode assumir a função, não apenas qual conta.
- Implemente
SessionNameeDurationSeconds— registre quem assumiu a função (SessionName) e limite o tempo de vida da sessão ao mínimo necessário.
- Audite regularmente — exporte e analise as políticas de confiança de todas as contas; ferramentas como AWS Config fazem isso automaticamente.
- Segregue ambientes — desenvolvimento, teste e produção nunca devem confiar uns nos outros; apenas um fluxo unidirecional controlado.
Abaixo, um exemplo de política de confiança segura versus insegura:
| Aspecto | Insegura | Segura | |——–|———-|——–| | Permite assumir | Qualquer principal da conta ABC | Apenas função específica com arn:aws:iam::ABC:role/deployment | | Validação extra | Nenhuma | ExternalId + SourceArn | | Duração | Sem limite (até 12 horas) | 15 minutos | | Logs | Básicos | Detalhados com SessionName |
Perguntas frequentes
Qual é a diferença entre ExternalId e SourceArn?
ExternalId é um segredo adicional — como uma senha para assumir a função. SourceArn restringe qual recurso específico (uma função IAM, por exemplo) pode fazer a assunção. Use os dois juntos.
Se eu usar confiança cruzada, preciso desabilitar MFA?
Não, mas a maioria das configurações não exige MFA ao assumir função entre contas. Você pode adicionar a exigência de MFA na política de confiança com a condição aws:MultiFactorAuthPresent.
Como auditar políticas de confiança em escala?
AWS Config, bem como ferramentas de código aberto como CloudMapper ou Prowler, listam todas as políticas de confiança e alertam sobre configurações perigosas. Na prática, uma auditoria mensal é o mínimo.
Confiança cruzada em Azure e Google Cloud é mais segura?
Todos os provedores têm mecanismos similares (Azure Management Groups, Google Cloud Organizations). Os riscos são equivalentes; o que muda é a sintaxe. Aplique os mesmos princípios: validação forte, privilégio mínimo, auditoria contínua.
Se sua organização trabalha com múltiplas contas em nuvem e precisa validar se as políticas de confiança estão corretas, o validador de JSON do PratiqueTech ajuda a verificar a sintaxe das políticas antes de implantá-las em produção — evitando erros que abrem brechas de segurança.
