Segurança IAM AWS: 3 Passos para Blindar o Ataque “Confused Deputy”

Quando falamos sobre segurança IAM AWS, a maioria das empresas foca no básico: ativar o MFA (Múltiplo Fator de Autenticação), rotacionar chaves de acesso e aplicar o princípio do menor privilégio aos desenvolvedores. No entanto, existe uma vulnerabilidade silenciosa, de nível arquitetural, que costuma passar despercebida até mesmo por equipes de engenharia sêniores: o ataque do “Confused Deputy” (O Representante Confuso).

Essa falha não envolve o roubo de senhas ou o vazamento de chaves no GitHub. Trata-se de uma exploração de confiança entre os próprios serviços internos da Amazon.

Neste artigo, vamos dissecar como um invasor pode usar um serviço legítimo da AWS contra você e, mais importante, como aplicar a configuração definitiva nas suas Trust Policies para blindar sua conta de uma vez por todas.

1. O Que É o Ataque do “Confused Deputy”?

Em segurança da informação, o problema do Confused Deputy ocorre quando uma entidade que não tem permissão para realizar uma ação consegue enganar uma entidade mais privilegiada (o representante) para que ela realize a ação em seu lugar.

Pense nisso como um golpe no mundo físico: um golpista falsifica um crachá de diretor e pede para o segurança do prédio (o representante) abrir o cofre. O segurança tem a chave e a permissão. Ele abre o cofre porque confia no crachá, sem saber que está agindo em nome de um agente malicioso.

2. Como a Invasão Acontece na Prática na AWS?

Na AWS, os “representantes” são os próprios serviços (como o Amazon EventBridge, AWS CloudTrail ou AWS Config).

Imagine o seguinte cenário de uso real e perigoso:

• Você cria uma função Lambda para limpar dados sensíveis do banco de dados.
• Você cria uma IAM Role permitindo que o Amazon EventBridge assuma essa Role para disparar o Lambda todos os dias à meia-noite.
• A sua Política de Confiança (Trust Policy) diz: “Eu confio no serviço events.amazonaws.com para assumir esta Role”.

Onde está a falha? Você disse que confia no EventBridge, mas não especificou qual EventBridge.

Um invasor, utilizando uma conta da AWS completamente diferente da sua (a conta do atacante), pode criar uma regra no EventBridge dele. Na hora de configurar o alvo, ele cola o ARN (Amazon Resource Name) da sua IAM Role (que pode ter sido adivinhado ou descoberto via engenharia social).

O EventBridge do atacante tenta assumir a sua Role. A AWS verifica a sua política, vê que o serviço events.amazonaws.com tem permissão, e autoriza. O atacante acaba de disparar o seu Lambda e apagar o seu banco de dados, usando a sua própria infraestrutura como ponte.

3. Como Blindar Suas Roles (A Solução Definitiva)

Para elevar a sua segurança IAM AWS e fechar essa brecha de escalonamento de privilégios cruzados (Cross-Account), você deve utilizar as Chaves de Condição Globais da AWS diretamente na Política de Confiança (Trust Policy) da sua Role.

Você precisa ensinar a AWS a verificar não apenas quem está pedindo o acesso, mas de onde esse pedido se originou. Aplique estes dois parâmetros restritivos:

• aws:SourceAccount: Garante que o serviço da AWS só possa assumir a Role se o recurso que fez a chamada pertencer ao ID da sua própria conta.
• aws:SourceArn: É ainda mais granular. Garante que apenas um recurso específico (ex: uma regra exata do seu EventBridge) possa invocar o serviço.

Veja como fica a política de confiança blindada (JSON):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:events:us-east-1:123456789012:rule/MinhaRegraLegitima"
        }
      }
    }
  ]
}

Ao adicionar o bloco Condition, se o EventBridge da conta do atacante tentar assumir sua Role, a AWS bloqueará a ação imediatamente com um erro de Acesso Negado (Access Denied), pois o ID da conta de origem não baterá com o especificado na sua política.

Conclusão

A flexibilidade de integração entre os serviços da Amazon é o que torna a nuvem tão poderosa, mas essa mesma integração exige um rigor de governança altíssimo. O ataque do Confused Deputy é um lembrete severo de que confiar em um serviço não é o mesmo que confiar na origem da solicitação.

Revise suas IAM Roles hoje mesmo. Qualquer Role que tenha um Service Principal (como EventBridge, S3, Config, etc.) configurado para fazer sts:AssumeRole precisa ter as chaves aws:SourceAccount e aws:SourceArn configuradas em sua Política de Confiança. É uma linha de código que separa uma arquitetura vulnerável de uma arquitetura resiliente e madura.