O problema de "confused deputy" - AWS Identity and Access Management

O problema de "confused deputy"

O problema do substituto confuso é um problema de segurança em que uma entidade que não tem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executar a ação. Para evitar isso, a AWS fornece ferramentas que ajudam você a proteger sua conta se você fornecer acesso aos recursos na sua conta a terceiros (conhecido como entre contas) ou a outros serviços da AWS (conhecido como entre serviços).

Às vezes, poderá ser necessário conceder acesso aos recursos da AWS a terceiros (delegar acesso). Por exemplo, suponha que você decida contratar uma empresa terceirizada chamada Example Corp para monitorar sua conta da AWS e ajudar a otimizar os custos. Para rastrear seus gastos diários, a Example Corp precisa de acesso aos seus recursos da AWS. A Example Corp também monitora muitas outras contas da AWS para outros clientes. Você pode usar uma função do IAM para estabelecer uma relação de confiança entre sua conta da AWS e a conta da Exemplo Corp. Um aspecto importante desse cenário é o ID externo, uma informação opcional que você pode usar em uma política de confiança de função do IAM para designar quem pode assumir a função. A função principal do ID externo é abordar e impedir o problema "confused deputy".

Na AWS, a personificação entre serviços pode resultar no problema do substituto confuso. A personificação entre serviços pode ocorrer quando um serviço (o serviço de chamada) chama outro serviço (o serviço chamado). O serviço de chamada pode ser manipulado de modo a usar suas permissões para atuar nos recursos de outro cliente de uma forma na qual ele não deveria ter permissão para acessar.

Prevenção de substituto confuso entre contas

O diagrama a seguir ilustra o problema do substituto confuso entre contas.


                A descrição de um problema confused deputy.

Este cenário supõe o seguinte:

  • AWS1 é a sua conta da AWS.

  • AWS1:ExampleRole é uma função em sua conta. Esta política de confiança da função confia na Example Corp especificando a conta da AWS da Example Corp como a conta que pode assumir a função.

Veja o que acontece:

  1. Ao começar a usar o serviço da Exemplo Corp, você fornece o ARN AWS1:ExampleRole à Exemplo Corp.

  2. A Example Corp usa esse ARN da função para obter credenciais de segurança temporárias para acessar recursos na sua conta da AWS. Dessa forma, confie na Example Corp como um "substituto" que pode agir em seu nome.

  3. Outro cliente da AWS também começa a usar os serviços da Exemplo Corp e também fornece o ARN AWS1:ExampleRole para a Exemplo Corp usar. Provavelmente, o outro cliente soube ou adivinhou o AWS1:ExampleRole, que não é um segredo.

  4. Quando o outro cliente pede à Exemplo Corp que acesse os recursos da AWS (o que ele afirma ser) em sua conta, a Exemplo Corp usa AWSAWS1: ExampleRole para acessar os recursos da sua conta.

Dessa forma, o outro cliente pode obter acesso não autorizado aos seus recursos. Como esse outro cliente foi capaz de burlar a Example Corp para agir involuntariamente em seus recursos, a Example Corp agora é um "confused deputy."

A Example Corp pode abordar o problema do substituto confuso exigindo que você inclua a verificação de condição ExternalId na política de confiança da função. A Example Corp gera um único valor de ExternalId para cada cliente e usa esse valor em sua solicitação para assumir a função. O valor de ExternalId deve ser exclusivo entre os clientes da Example Corp e controlado pela Example Corp, não por seus clientes. É por isso que ele é fornecido pela Example Corp e não é criado por você. Isso impede que a Example Corp seja um substituto confuso e conceda acesso a recursos da AWS de outra conta.

Em nosso cenário, imagine que seu identificador exclusivo da Example Corp seja 12345 e que o identificador do outro cliente seja 67890. Esses identificadores são simplificados para esse cenário. Em geral, esses identificadores são GUIDs. Supondo que esses identificadores sejam exclusivos entre os clientes da Example Corp, eles são valores confidenciais próprios para o ID externo.

A Example Corp atribui o valor do ID externo "12345" a você. É necessário adicionar um elemento Condition à política de confiança da função que exige que o valor do sts:ExternalId seja 12345, como:

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "Example Corp's AWS Account ID" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "12345" } } } }

O elemento Condition (Condição) dessa política só permite que a Example Corp assuma o perfil quando a chamada de API AssumeRole incluir o valor do ID externo 12345. A Example Corp garante que sempre que assumir uma função em nome de um cliente, incluirá o valor do ID externo desse cliente em uma chamada AssumeRole. Mesmo que outro cliente forneça seu ARN à Example Corp, ele não poderá controlar o ID externo que a Example Corp inclui em sua solicitação para a AWS. Isso ajuda a evitar que um cliente não autorizado tenha acesso aos seus recursos.

O diagrama a seguir ilustra isso.


                Como mitigar um problema confused deputy.
  1. Como antes, ao começar a usar o serviço da Exemplo Corp, você fornece o ARN AWS1:ExampleRole à Exemplo Corp.

  2. Quando a Exemplo Corp usa esse ARN de perfil para assumir o perfil AWS1:ExampleRole, ela inclui o ID externo (12345) na chamada de API AssumeRole. O ID externo corresponde à política de confiança da função, portanto, a chamada de API AssumeRole tem êxito e a Exemplo Corp obtém credenciais de segurança temporárias para acessar recursos na sua conta da AWS.

  3. Outro cliente da AWS também começa a usar os serviços da Exemplo Corp e, assim como antes, esse cliente também fornece o ARN AWS1:ExampleRole para a Exemplo Corp usar.

  4. Mas, desta vez, quando a Exemplo Corp tenta assumir o perfil AWS1:ExampleRole, ela fornece o ID externo associado a outro cliente (67890). O outro cliente não tem como alterar isso. A Example Corp faz isso porque a solicitação para usar o perfil veio de outro cliente, portanto, 67890 indica a circunstância em que a Example Corp está atuando. Como você adicionou uma condição com seu próprio ID externo (12345) à política de confiança de AWS1:ExampleRole, a chamada de API AssumeRole não vai funcionar. O outro cliente será impedido de obter o acesso não autorizado aos recursos na sua conta (indicado pelo "X" vermelho no diagrama).

O ID externo ajuda a prevenir que qualquer outro cliente engane a Example Corp a acessar seus recursos involuntariamente.

Prevenção do problema do substituto confuso entre serviços

Recomendamos o uso das chaves de contexto de condição global aws:SourceArn e aws:SourceAccount em políticas baseadas em recursos para limitar as permissões que um serviço tem a um recurso específico. Use aws:SourceArn se quiser que apenas um recurso seja associado ao acesso entre serviços. Use aws:SourceAccount se quiser permitir que qualquer recurso nessa conta seja associado ao uso entre serviços.

A maneira mais eficaz de se proteger do problema do substituto confuso é usar a chave de contexto de condição global aws:SourceArn com o ARN completo do recurso em suas políticas baseadas em recursos. Se você não souber o ARN completo do recurso ou estiver especificando vários recursos, use a chave de condição de contexto global aws:SourceArn com curingas (*) para as partes desconhecidas do ARN. Por exemplo, arn:aws:servicename:*:123456789012:*.

Se o valor de aws:SourceArn não contiver o ID da conta, como um ARN de bucket do Amazon S3, você deverá usar ambas as chaves de contexto de condição global para limitar as permissões.

Prevenção do problema do substituto confuso entre serviços para AWS Security Token Service

Muitos serviços da AWS exigem que você use funções para permitir que o serviço acesse recursos de outro serviço em seu nome. A função de serviço é uma função que um serviço assume para realizar ações em seu nome. Uma função requer duas políticas: uma política de confiança de função que especifica qual entidade principal tem permissão para assumir a função e uma política de permissões que especifica o que pode ser feito com a função. Uma política de confiança de função é o único tipo de política baseada em recursos no IAM. Outros serviços da AWS têm políticas baseadas em recursos, como uma política de bucket do Amazon S3.

Quando um serviço assume uma função em seu nome, a entidade principal de serviço deve ter permissão para executar a ação sts:AssumeRole na política de confiança de função. Quando um serviço chama sts:AssumeRole, o AWS STS retorna um conjunto de credenciais temporárias de segurança usado pela entidade principal de serviço para acessar os recursos permitidos pela política de permissões da função. Quando um serviço assume uma função em sua conta, você pode incluir as chaves de contexto de condição global aws:SourceAccount e aws:SourceArn em sua política de confiança de função para limitar o acesso à função apenas a solicitações geradas pelos recursos esperados.

Por exemplo, no Incident Manager do AWS Systems Manager, você deve escolher uma função para permitir que o Incident Manager execute um documento de automação do Systems Manager em seu nome. O documento de automação pode incluir planos de resposta automatizados para incidentes iniciados por alarmes do CloudWatch ou eventos EventBridge. No exemplo de política de confiança de função a seguir, você pode usar a chave de condição aws:SourceArn para restringir o acesso à função de serviço com base no ARN do registro de incidente. Somente registros de incidentes criados com base no recurso do plano de resposta myresponseplan são capazes de usar essa função.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "Service": "ssm-incidents.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*" } } } }