Como usar um ID externo ao conceder acesso aos seus recursos da AWS a terceiros - AWS Identity and Access Management

Como usar um ID externo ao conceder acesso aos seus recursos da AWS a terceiros

Às vezes, é necessário oferecer acesso a terceiros para os recursos da AWS (delegar acesso). Um aspecto importante desse cenário é o ID externo, informação opcional que você usa em uma política de confiança da função do IAM para designar quem pode assumir a função.

Importante

A AWS não trata o ID externo como um segredo. Depois de criar um segredo, como um par de chaves de acesso ou uma senha na AWS, você não poderá visualizá-las novamente. O ID externo de uma função pode ser visto por qualquer pessoa com permissão para visualizar a função.

Para exigir que o terceiro forneça um ID externo ao assumir uma função, atualize a política de confiança da função com o ID externo de sua escolha.

Para fornecer um ID externo quando você assumir uma função, use a AWS CLI ou a API da AWS para assumir essa função. Para obter mais informações, consulte a operação da API STS AssumeRole ou a operação da CLI assume-role STS.

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.

Não dê à Example Corp acesso a um usuário do IAM e suas credenciais de longo prazo na sua conta da AWS. Em vez disso, use uma função do IAM e suas credenciais de segurança temporárias. Uma função do IAM fornece um mecanismo que permite o acesso de terceiros aos recursos da AWS sem a necessidade de compartilhar credenciais de longo prazo (por exemplo, uma chave de acesso do usuário do IAM).

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 Example Corp. Após estabelecer este relacionamento, um membro da conta da Example Corp pode chamar a API AssumeRole do AWS STS para obter credenciais de segurança temporárias. Os membros da Example Corp podem usar as credenciais para acessar recursos da AWS na sua conta.

nota

Para obter mais informações sobre AssumeRole e outras APIs da AWS que você pode chamar para obter credenciais de segurança temporárias, consulte Solicitar credenciais de segurança temporárias.

Veja aqui um detalhamento desse cenário:

  1. Contrate a Example Corp, para que eles criem um identificador de clientes exclusivo para você. Eles fornecerão o ID de cliente exclusivo e o número da conta da AWS deles. Essas informações são necessárias para criar uma função do IAM na próxima etapa.

    nota

    A Example Corp pode usar qualquer valor de string que desejar para o ExternalId, desde que seja exclusivo para cada cliente. Pode ser o número da conta de um cliente ou até mesmo uma string aleatória de caracteres, desde que dois clientes não tenham o mesmo valor. Isso não deve ser um "segredo". A Example Corp deve fornecer o valor do ExternalId para cada cliente. O essencial é que ele deve ser gerado pela Example Corp e não por seus clientes.

  2. Faça login na AWS e crie uma função do IAM que dê à Example Corp acesso aos seus recursos. Como qualquer função do IAM, a função tem duas políticas, uma política de permissões e uma política de confiança. A política de confiança da função especifica quem pode assumir a função. Em nosso cenário de exemplo, a política especifica o número de conta da AWS da Example Corp como Principal. Isso permite que as identidades dessa conta assumam a função. Além disso, você adiciona um elemento Condition à política de confiança. Esse elemento Condition testa a chave de contexto ExternalId para garantir que ela corresponda ao ID do cliente exclusivo da Example Corp. Por exemplo:

    "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
  3. A política de permissões da função especifica o que a função permite que alguém faça. Por exemplo, especifique que a função permita que alguém gerencie apenas o Amazon EC2 e os recursos do Amazon RDS, mas não os seus usuários ou grupos do IAM. Em nosso cenário de exemplo, use a política de permissões para dar acesso somente leitura à Example Corp a todos os recursos na sua conta.

  4. Depois de criar a função, forneça o nome de recurso da Amazon (ARN) da função à Example Corp.

  5. Quando a Example Corp precisar acessar seus recursos da AWS, alguém da empresa chama a API sts:AssumeRole da AWS. A chamada inclui o ARN da função a ser assumida e o parâmetro ExternalId que corresponde ao ID do cliente.

Se a solicitação vier de alguém que estiver usando a conta da AWS da Example Corp, e se o ARN da função e o ID externo estiverem corretos, a solicitação será bem-sucedida. Nesse caso, ela fornecerá credenciais de segurança temporárias que a Example Corp poderá usar para acessar os recursos da AWS permitidos pela sua função.

Em outras palavras, quando uma política de função incluir um ID externo, qualquer pessoa que desejar assumir a função deverá ser especificada como um principal na função e deverá incluir o ID externo correto.

Por que usar um ID externo?

Em termos abstratos, o ID externo permite que o usuário que está assumindo a função assegure as circunstâncias nas quais elas operam. Também oferece uma forma para o proprietário da conta permitir que a função seja assumida apenas em determinadas circunstâncias. A função principal do ID externo é abordar e impedir o problema "confused deputy".

O problema confused deputy

Para continuar o exemplo anterior, a Example Corp exige acesso a determinados recursos da sua conta da AWS. Mas, além de você, a Example Corp tem outros clientes e precisa de uma maneira de acessar os recursos da AWS de cada cliente. Em vez de pedir para seus clientes suas chaves de acesso da conta da AWS, que são segredos que nunca devem ser compartilhados, a Example Corp solicita um ARN da função de cada cliente. Mas outro cliente da Example Corp pode adivinhar ou obter seu ARN da função. Esse cliente poderá usar seu ARN da função para obter acesso aos seus recursos da AWS por meio da Example Corp. Essa forma de escalonamento de permissão é conhecida como problema confused deputy.

O diagrama a seguir ilustra o problema confused deputy.


          A descrição de um problema confused deputy.

Este diagrama supõe o seguinte:

  • AWS1 é sua conta da AWS.

  • AWS1: ExampleRole é uma função na 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. Quando começa a usar o serviço da Example Corp, forneça o ARN de AWS1: ExampleRole para a Example 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 Example Corp e também fornece o ARN AWS1: ExampleRole para a Example Corp usar. Provavelmente, o outro cliente soube ou adivinhou o AWS1: ExampleRole, que não é um segredo.

  4. Quando o outro cliente pede à Example Corp para acessar os recursos da AWS (o que ele diz ser) em sua conta, a Example Corp usa AWS1: ExampleRole para acessar os recursos na 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."

Como o ID externo impede o problema confused deputy?

Aborde o problema confused deputy, incluindo a verificação de condição ExternalId na política de confiança da função. A empresa "deputy" insere um valor do ID externo exclusivo para cada cliente em uma solicitação das credenciais da AWS. O ID externo é um valor do ID do cliente que deve ser exclusivo entre os clientes da Example Corp e que não possa ser controlado por eles. É por isso que ele é fornecido pela Example Corp e não é criado por você. Isso ajuda a evitar que um cliente se passe por outro cliente com sucesso. A Example Corp sempre insere o ID externo atribuído ao cliente, por isso você nunca verá uma solicitação vinda da Example Corp com um ID externo, exceto o seu.

Em nosso cenário, imagine que o identificador exclusivo da Example Corp para você seja "12345" e seu identificador para o 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 dá o valor do ID externo "12345" para 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", "Action": "sts:AssumeRole", "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "12345"}} } }

O elemento Condição nesta política permite que a Example Corp assuma a função somente quando a chamada de API do 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, como exibido no diagrama a seguir.


          Como mitigar um problema confused deputy.
  1. Assim como antes, quando usar o serviço da Example Corp, forneça o ARN AWS1: ExampleRole à Example Corp.

  2. Quando a Example Corp usar esse ARN da função para assumir a função AWS1: ExampleRole, ela incluirá o seu 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 Example 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 Example Corp e, assim como antes, esse cliente também fornece o ARN AWS1: ExampleRole para a Example Corp usar.

  4. Mas, desta vez, quando a Example Corp tenta assumir a função 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 a função 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, haverá falha da chamada de API AssumeRole. 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 evitar que qualquer outro cliente engane a Example Corp ao acessar seus recursos; ele mitigará o problema confused deputy.

Quando devo usar um ID externo?

Use um ID externo nas seguintes situações:

  • Você é proprietário de uma conta da AWS e configurou uma função para um terceiro que acessa outras contas da AWS além da sua. Você deve solicitar um ID externo ao terceiro que ele inclui quando assume a sua função. Depois, você verifica o ID externo na política de confiança da sua função. Isso garante que o terceiro externo possa assumir sua função somente quando estiver agindo em seu nome.

  • Você está na posição de assumir funções em nome de clientes diferentes, como a Example Corp em nosso cenário anterior. Você deve atribuir um ID externo exclusivo para cada cliente e instruí-los a adicionar o ID externo à política de confiança de sua função. Certifique-se de sempre incluir o ID externo correto em suas solicitações para assumir funções.

    Provavelmente, você já tem um identificador exclusivo para cada um de seus clientes e esse ID exclusivo será suficiente para ser usado como ID externo. O ID externo não é um valor especial que você precisa criar, explicitamente, ou rastrear, separadamente, apenas para essa finalidade.

    Sempre especifique o ID externo em suas chamadas de API AssumeRole. Quando um cliente oferecer a você um ARN da função, teste se você poderá assumir a função com e sem o ID externo correto. Se você assumir a função sem o ID externo correto, não armazene o ARN da função do cliente em seu sistema. Aguarde até que o cliente tenha atualizado a política de confiança de função para exigir o ID externo correto. Dessa forma, você ajudará seus clientes a agir da forma correta, mantendo-os protegidos contra o problema confused deputy.