ID Externo e o Deputado Confuso

Quando permite que um terceiro assuma uma função em sua conta, pode surgir um risco de segurança chamado problema do agente confuso. O identificador externo é o controle simples, mas essencial, que o impede. Esse padrão aparece na prova sempre que um fornecedor de SaaS precisa acessar sua conta da AWS.

Um agente confuso é uma entidade confiável (o agente) que é enganada e levada a usar sua autoridade em nome de um invasor. Na AWS, um serviço de terceiros tem permissão para assumir funções em muitas contas de clientes; um invasor poderia enganá-lo e fazê-lo assumir sua função se nada vinculasse a solicitação ao relacionamento legítimo com o cliente.

Imagine um SaaS de monitoramento que assume uma função em cada conta de cliente. O SaaS usa uma única identidade da AWS para todos. Se um invasor que também é cliente descobrir o ARN da sua função, poderá persuadir o SaaS a assumir sua função, pois o SaaS é a entidade principal confiável. O ID da conta, por si só, não basta para impedir isso.

O identificador externo é um valor exclusivo e secreto que o fornecedor atribui ao seu relacionamento. Você o coloca na política de confiança da função como uma condição, e o fornecedor deve fornecer exatamente o mesmo valor ao chamar AssumeRole. Como o invasor não conhece seu identificador externo, não consegue enganar o fornecedor para que assuma sua função.

Esta política de confiança exige o identificador externo correspondente. AssumeRole só é executado com sucesso quando o fornecedor envia o valor idêntico, impedindo o ataque do agente confuso.

É fundamental que o fornecedor, e não o cliente, gere e controle o identificador externo. Isso impede que clientes colaborem para reutilizar o mesmo valor. A orientação da AWS é explícita: como terceiro, você deve atribuir a cada cliente um identificador externo exclusivo e exigi-lo em todas as assunções.

O identificador externo não foi concebido para ser secreto como uma senha; ele pode aparecer nas instruções de configuração. Seu valor de segurança vem de ser exclusivo por cliente e controlado pelo fornecedor, impedindo que um invasor faça o agente usar o valor do cliente errado. Trate-o como um token contra a personificação, não como uma credencial.

O identificador externo controla quem pode assumir, mas ainda é preciso delimitar o que a função pode fazer com políticas de permissões rigorosas. Mesmo um fornecedor corretamente autorizado deve receber apenas as permissões mínimas necessárias. Combine identificador externo, entidade principal específica e permissões de menor privilégio para obter acesso seguro de terceiros.

O padrão do agente confuso também se aplica aos serviços da AWS que atuam em seu nome. A confiança entre serviços costuma usar chaves de condição como aws:SourceArn e aws:SourceAccount em políticas de recursos para garantir que o serviço chamador esteja atuando em favor do recurso de sua propriedade — a mesma ideia defensiva em um contexto diferente.

Sempre que uma questão descreve um terceiro ou SaaS assumindo uma função entre contas, a resposta segura quase sempre envolve um identificador externo na política de confiança. Se o cenário for entre serviços, procure condições aws:SourceArn/aws:SourceAccount. Reconhecer essa pista indica diretamente o controle correto.

O problema do agente confuso permite que um invasor engane um terceiro confiável para que use seu acesso de forma indevida. O identificador externo, exclusivo por cliente e controlado pelo fornecedor, impede isso ao exigir um valor correspondente em AssumeRole. Para serviços da AWS, use aws:SourceArn e aws:SourceAccount. Sempre combine esses controles com permissões de menor privilégio.

Teste seus conhecimentos sobre o conceito de agente confuso.

O problema do agente confuso surge quando um terceiro confiável é enganado e levado a usar indevidamente seu acesso entre contas. O identificador externo, exclusivo por cliente e controlado pelo fornecedor, impede isso por meio de uma condição na política de confiança baseada em sts:ExternalId. Para a confiança entre serviços da AWS, use aws:SourceArn e aws:SourceAccount, sempre aplicando o menor privilégio.