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 um perfil do IAM para estabelecer uma relação de confiança entre sua Conta da AWS e a conta da Example 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 imitaçã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.

Este cenário supõe o seguinte:

Veja o que acontece:

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 a função 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.

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ções globais aws:SourceArn, aws:SourceAccount, aws:SourceOrgID ou aws:SourceOrgPaths em políticas baseadas em recursos para limitar as permissões de um serviço para um determinado recurso. Use aws:SourceArn se quiser associar apenas um recurso ao acesso entre serviços. Use aws:SourceAccount se quiser permitir que qualquer recurso nessa conta seja associado ao uso entre serviços. Use aws:SourceOrgID se quiser permitir que qualquer recurso de qualquer conta de uma organização seja associado ao uso entre serviços. Use aws:SourceOrgPaths se quiser associar qualquer recurso das contas em um caminho do AWS Organizations seja associado ao uso entre serviços. Para obter mais informações sobre como usar e entender os caminhos, consulte Entender o caminho da entidade do AWS Organizations.

A maneira mais granular de se proteger contra o problema de "confused deputy" é usar a chave de contexto de condição global aws:SourceArn com o ARN completo do recurso nas 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 do aws:SourceArn não contiver o ID da conta, como um ARN de bucket do Amazon S3, você deverá usar ambos, a aws:SourceAccount e o aws:SourceArn para limitar as permissões.

Para se proteger do problema de "confused deputy" em grande escala, use a chave de contexto de condição global aws:SourceOrgID ou aws:SourceOrgPaths com o ID ou o caminho da organização do recurso nas políticas baseadas em recursos. As políticas que incluem a chave aws:SourceOrgID ou aws:SourceOrgPaths incluem automaticamente as contas corretas e você não tem que atualizar manualmente as políticas quando adiciona, remove ou move contas na organização.

Para políticas de confiança de função não vinculadas a serviços, cada serviço na política de confiança executou a ação iam:PassRole para verificar se a função está na mesma conta do serviço chamador. Por isso, não é necessário usar aws:SourceAccount, aws:SourceOrgID ou aws:SourceOrgPaths com essas políticas de confiança. O uso de aws:SourceArn em uma política de confiança permite especificar recursos dos quais uma função pode ser assumida, como o ARN de uma função do Lambda. Alguns Serviços da AWS usam aws:SourceAccount e aws:SourceArn em políticas de confiança para perfis recém-criados, mas o uso das chaves não é necessário para os perfis já existentes na conta.

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 um perfil na sua conta, você pode incluir as chaves de contexto de condições globais aws:SourceArn, aws:SourceAccount, aws:SourceOrgID ou aws:SourceOrgPaths na política de confiança do perfil para limitar o acesso ao perfil apenas às solicitações que forem geradas pelos recursos esperados.

Por exemplo, em AWS Systems Manager Incident Manager, você deve escolher um perfil que permita 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/*"
      }
    }
  }
}