Integrar serviços na nuvem é uma necessidade arquitetural básica. Se a sua empresa contrata uma plataforma SaaS de monitoramento financeiro ou de auditoria de segurança, essa plataforma precisará ler os dados de dentro da sua conta AWS. A maneira correta e recomendada pela Amazon de conceder esse acesso é através de uma Cross-Account Role (Função de Conta Cruzada) no AWS IAM.
Você cria uma Role na sua conta e diz: “Eu confio na conta AWS do serviço SaaS para assumir esta função”.
Parece perfeitamente seguro, certo? O problema é que, se você configurar apenas isso, a sua infraestrutura acaba de se tornar vulnerável a um dos ataques mais engenhosos e silenciosos da computação em nuvem: o problema do Delegado Confuso (Confused Deputy Problem).
Neste artigo, vamos dissecar como invasores exploram permissões mal configuradas e como blindar as políticas de confiança do seu IAM.
1. Anatomia do Ataque: Como um “Delegado” Fica Confuso
Para entender a falha, precisamos olhar para a arquitetura do ataque passo a passo. Imagine o seguinte cenário:
- A Integração: Sua empresa (Conta A) contrata o SaaS de Monitoramento (Conta B). O SaaS pede para você criar uma Role com permissão de leitura no seu Amazon S3 e fornecer o ARN dessa Role (ex:
arn:aws:iam::111111111111:role/SaaSAccessRole). - A Política Vulnerável: Na Política de Confiança (Trust Policy) dessa Role, você coloca a conta do SaaS como
Principal. - O Invasor: Um Hacker também cria uma conta de cliente no mesmo SaaS de Monitoramento.
- O Golpe: No painel do SaaS, o Hacker insere o ARN da sua Role.
- A Confusão: O SaaS (agindo como um delegado) obedece ao Hacker, chama a API
sts:AssumeRolena sua conta e consegue acessar os seus buckets do S3. Ele então exibe os seus dados sigilosos no painel do Hacker.
O SaaS de Monitoramento foi enganado (confuso). Ele tinha permissão genuína para acessar a sua conta, mas foi manipulado para fazer isso em nome de um ator malicioso.
2. A Solução para Terceiros: O Poder do sts:ExternalId
A Amazon criou uma vacina específica para evitar que serviços de terceiros sejam usados contra você: a chave de condição sts:ExternalId.
O ExternalId funciona como um identificador único ou “segredo compartilhado” que o serviço SaaS gera exclusivamente para o seu Tenant (seu ambiente logado na plataforma deles). Quando você cria a sua Cross-Account Role, você deve exigir que o SaaS envie esse ID no momento em que ele tentar assumir a função.
Ao adicionar essa condição na sua Trust Policy, se o Hacker tentar usar o seu ARN no painel dele, o SaaS tentará assumir a sua Role enviando o ExternalId do Hacker. A AWS rejeitará a requisição imediatamente, pois os IDs não batem.
Como fica a política de confiança blindada:
JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::CONTA_DO_SAAS:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "ID_UNICO_GERADO_PELO_SAAS_PARA_VOCE"
}
}
}
]
}
3. Quando o Delegado Confuso é a Própria AWS
O Confused Deputy não acontece apenas com empresas SaaS. Ele também acontece entre os próprios serviços da AWS.
Imagine que você configurou o Amazon EventBridge para acionar uma função AWS Lambda. Você precisa dar uma Role ao EventBridge para que ele possa invocar o seu Lambda. Se você simplesmente disser “Eu confio no serviço events.amazonaws.com”, qualquer outra pessoa na AWS (em outra conta mundial) poderia configurar uma regra no EventBridge dela apontando para o ARN do seu Lambda.
Como os serviços da AWS não usam ExternalId, a Amazon introduziu duas chaves de condição críticas para proteger a comunicação serviço-a-serviço:
aws:SourceAccount: Exige que a requisição venha especificamente do ID da sua conta AWS.aws:SourceArn: Exige que o recurso exato (ex: a regra específica do EventBridge) seja o acionador.
4. O Guia de Bolso da Proteção Cross-Account
Para nunca mais errar na hora de liberar acessos, siga este quadro comparativo na estruturação das suas políticas:
| Cenário de Acesso | O “Delegado” (Quem assume a Role) | Proteção Obrigatória (Condition Key) |
| SaaS / Terceiros | Uma conta AWS externa (ex: Datadog, Snowflake) | sts:ExternalId |
| Serviços AWS Internos | Um serviço gerenciado (ex: EventBridge, CloudWatch) | aws:SourceArn e/ou aws:SourceAccount |
| Outra Conta Própria | Uma conta dentro do seu próprio AWS Organizations | Nenhuma condição extra (se o acesso for restrito a usuários do seu SSO) |
Conclusão
A segurança na nuvem moderna não é comprometida quebrando criptografias complexas; ela é violada através de configurações de identidade e acesso (IAM) mal elaboradas.
O problema do AWS Confused Deputy é o exemplo perfeito de que não basta confiar no mensageiro; é preciso validar em nome de quem ele está agindo. A partir de hoje, sempre que for integrar um serviço de terceiros à sua conta da AWS, exija um ExternalId. Se o fornecedor disser que não suporta esse recurso, recuse a integração: o risco para a sua infraestrutura é simplesmente alto demais.
