Cómo utilizar un ID externo al otorgar acceso a los recursos de AWS a terceros - AWS Identity and Access Management

Cómo utilizar un ID externo al otorgar acceso a los recursos de AWS a terceros

A veces, debe otorgar acceso a terceros a sus recursos de AWS (delegar el acceso). Un aspecto importante de esta situación es el ID externo, una información opcional que puede utilizar en una política de confianza del rol de IAM para señalar quién puede asumir el rol.

importante

AWS no trate el ID externo como un secreto. Después de crear un secreto como un par de claves de acceso o una contraseña en AWS, no puede verlos de nuevo. Cualquier usuario con permiso para ver el rol puede ver el ID externo de dicho rol.

Para requerir que el tercero proporcione un ID externo al asumir un rol, actualice la política de confianza del rol con el ID externo de su elección.

Para proporcionar un ID externo cuando asuma un rol, utilice la AWS CLI o la API de AWS para asumir ese rol. Para obtener más información, consulte la operación de la API AssumeRole o la operación de la CLI assume-role.

Por ejemplo, digamos que decide contratar a una compañía externa denominada Example Corp para monitorizar su cuenta de AWS y ayudarle a optimizar los costos. A fin de realizar un seguimiento de su gasto diario, Example Corp necesita acceder a los recursos de AWS. Example Corp también monitoriza muchas otras cuentas de AWS para otros clientes.

No conceda a Example Corp acceso a un usuario de IAM y sus credenciales a largo plazo en su cuenta de AWS. En su lugar, utilice un rol de IAM y sus credenciales de seguridad temporales. Un rol de IAM proporciona un mecanismo para permitir que un tercero acceda a sus recursos de AWS sin necesidad de compartir credenciales a largo plazo (por ejemplo, una clave de acceso del usuario de IAM).

Puede utilizar un rol de IAM para establecer una relación de confianza entre su cuenta de AWS y la cuenta de Example Corp. Después de que se establezca esta relación, un miembro de la cuenta de Example Corp puede llamar a la API AssumeRole de AWS STS para obtener credenciales de seguridad temporales. A continuación, los miembros de Example Corp pueden usar las credenciales para obtener acceso a los recursos de AWS en su cuenta.

nota

Para obtener más información acerca de AssumeRole y de otras operaciones de la API de AWS que puede llamar para obtener credenciales de seguridad temporales, consulte Solicitud de credenciales de seguridad temporales.

A continuación presentamos un desglose más detallado de la situación:

  1. Contrata a Example Corp para que cree un único identificador de cliente para usted. Te proporcionan este identificador de cliente único y su número de AWS cuenta. Usted necesita esta información para crear un rol de IAM en el siguiente paso.

    nota

    Example Corp puede utilizar cualquier valor de cadena que desee para el ExternalId, siempre que sea exclusivo para cada cliente. Puede ser un número de cuenta de cliente o incluso una cadena de caracteres aleatoria, siempre que no haya dos clientes con el mismo valor. No pretende ser un "secreto". Example Corp debe proporcionar el valor ExternalId a cada cliente. Lo que es fundamental, es que el valor lo debe generar Example Corp y no sus clientes.

  2. Puede iniciar sesión en AWS y crear un rol de IAM que otorgue acceso a Example Corp a sus recursos. Como cualquier rol de IAM, el rol tiene dos políticas: una política de permisos y una política de confianza. La política de confianza del rol especifica quién puede asumir el rol. En nuestro caso, la política especifica el número de cuenta de AWS de Example Corp como el Principal. Esto permite que las identidades de la cuenta asuman el rol. Además, se agrega un elemento Condition a la política de confianza. Esta Condition prueba la clave de contexto ExternalId para garantizar que coincide con el ID de cliente único de Example Corp. Por ejemplo:

    "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
  3. La política de permisos del rol especifica qué permite realizar dicho rol. Por ejemplo, podría especificar que el rol permite administrar únicamente los recursos de Amazon EC2 y Amazon RDS, pero no los recursos de usuarios o grupos de IAM. En nuestro escenario de ejemplo, utiliza la política de permisos para ofrecer a Example Corp acceso de solo lectura a todos los recursos de la cuenta.

  4. Después de crear el rol, debe proporcionar el nombre de recurso de Amazon (ARN) del rol a Example Corp.

  5. Cuando Example Corp necesita acceder a los recursos de AWS, un miembro de la compañía llama a la API sts:AssumeRole de AWS. La llamada incluye el ARN de la función que se ha de asumir y el parámetro ExternalId que se corresponde con el ID de cliente.

Si la solicitud proviene de alguien que utiliza la cuenta de AWS de Example Corp y si el ARN de rol y el ID externo son correcto, la solicitud se realiza correctamente. A continuación, proporciona credenciales de seguridad temporales que Example Corp puede utilizar para obtener acceso a los recursos de AWS que permite su rol.

En otras palabras, cuando una política de roles incluye un ID externo, cualquiera que desee asumir el rol debe ser principal en el rol y debe incluir el ID externo correcto.

¿Por qué usar un ID externo?

En términos abstractos, el ID externo permite al usuario que asume el rol afirmar las circunstancias en las que opera. También ofrece al propietario de la cuenta una forma de permitir asumir el rol únicamente en circunstancias específicas. La función principal del ID externo es abordar y prevenir el problema del "suplente confuso".

El problema del suplente confuso

Para seguir con el ejemplo anterior, Example Corp necesita acceder a determinados recursos de la cuenta de AWS. Sin embargo, además de usted Example Corp tiene otros clientes y necesita una forma para acceder a los recursos de AWS de cada cliente. En lugar de pedir a sus clientes las claves de acceso de sus cuenta de AWS, que son secretos que no deben compartirse nunca, Example Corp solicita un ARN de rol para cada cliente. Pero otro cliente de Example Corp podría averiguar u obtener su ARN de rol. Posteriormente, este cliente podría usar el ARN de su rol para obtener acceso a sus recursos de AWS a través de Example Corp. Esta forma de escalado de permisos se conoce como el problema del suplente confuso.

En el diagrama siguiente se muestra el problema del suplente confuso.


          Descripción del problema de suplente confuso.

Este diagrama se basa en los siguientes supuestos:

  • AWS1 es la cuenta de AWS.

  • AWS1:ExampleRole es un rol de la cuenta. La política de confianza del rol confía en Example Corp especificando la cuenta de AWS de Example Corp como la que puede asumir el rol.

Y ocurre lo siguiente:

  1. Al empezar a utilizar el servicio de Example Corp, usted proporciona el ARN de AWS1:ExampleRole a Example Corp.

  2. Example Corp utiliza dicho ARN del rol para obtener credenciales de seguridad temporales para acceder a los recursos de la cuenta de AWS. De esta forma, confía en Example Corp como "suplente" que puede actuar en su nombre.

  3. Otro cliente de AWS también ha empezado a utilizar los servicios de Example Corp y también ofrece el ARN de AWS1: ExampleRole para que lo utilice Example Corp. Probablemente el otro cliente ha averiguado o adivinado la AWS1:ExampleRole, que no es un secreto.

  4. Cuando el otro cliente solicita a Example Corp obtener acceso a los recursos de AWS en (la que parece ser) su cuenta, Example Corp utiliza AWS1:ExampleRole para obtener acceso a los recursos de la cuenta.

Este es el modo en que el otro cliente podría acceder de nuevo sin autorización a sus recursos. Dado que este otro cliente ha engañado a Example Corp para actuar en los recursos de forma accidental, Example Corp se ha convertido en un "suplente confuso".

¿Cómo evita un ID externo el problema del suplente confuso?

Deberá abordar el problema del suplente confuso incluyendo la verificación de la condición ExternalId en la política de confianza del rol. La compañía "suplente" inserta un único valor de ID externo para cada cliente en la solicitud de credenciales de AWS. El ID externo es un valor de ID del cliente que debe ser único para cada cliente de Example Corp y que está fuera del control de los clientes de Example Corp. Este es el motivo por el que lo recibe de Example Corp y que no crea el suyo propio. Esto ayuda a impedir que un cliente suplante con éxito a otro cliente. Example Corp siempre inserta el ID externo del cliente asignado, por lo que no debería ver una solicitud de Example Corp con ningún ID externo que no sea el suyo propio.

En nuestro caso, imagine que el identificador único de Example Corp para usted es "12345" y su identificador para el otro cliente es "67890". Estos identificadores están simplificados para este ejemplo. Por lo general, estos identificadores son GUID. Suponiendo que estos identificadores son exclusivos para cada cliente de Example Corp, son valores confidenciales que deben utilizarse para el ID externo.

Example Corp le proporciona el valor de ID externo "12345". A continuación, deberá añadir un elemento Condition a la política de confianza del rol que exige que el valor sts:ExternalId sea 12345, como a continuación:

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

El elemento de condición en esta política permite a Example Corp asumir el rol solo cuando la llamada a la API AssumeRole incluye el valor de ID externo "12345". Example Corp se asegura de que cada vez que se asume un rol en nombre de un cliente, siempre incluye el valor de ID externo del cliente en la llamada a AssumeRole. Incluso aunque otro cliente suministre el ARN a Example Corp, no puede controlar el ID externo que Example Corp incluye en su solicitud a AWS. Esto ayuda a impedir que un cliente no autorizado obtenga acceso a los recursos, tal como se muestra en el diagrama siguiente.


          Cómo mitigar un problema de suplente confuso.
  1. Como anteriormente, al empezar a utilizar el servicio de Example Corp, usted proporciona el ARN de AWS1:ExampleRole a Example Corp.

  2. Cuando Example Corp usa ese ARN del rol para asumir el rol AWS1:ExampleRole, Example Corp incluye el ID externo ("12345") en la llamada a la API AssumeRole. El ID externo coincide con la política de la confianza del rol, por lo que la llamada a la API AssumeRole funciona y Example Corp obtiene las credenciales de seguridad temporales para acceder a los recursos de la cuenta de AWS.

  3. Otro cliente de AWS también ha empezado a utilizar los servicios de Example Corp y, como antes, también proporciona el ARN de AWS1: ExampleRole para que lo utilice Example Corp.

  4. Sin embargo, ahora, cuando Example Corp intenta asumir el rol AWS1:ExampleRole, proporciona el ID externo asociado con el otro cliente ("67890"). El otro cliente no puede cambiarlo. Example Corp lo hace porque la solicitud para utilizar el rol procede de otro cliente, por lo que "67890" indica la circunstancia en la que actúa Example Corp. Dado que ha agregado una condición con su propio ID externo ("12345") a la política de confianza de AWS1:ExampleRole, la llamada a la API AssumeRole provoca un error. Así se evita que el otro cliente obtenga un acceso no autorizado a los recursos de su cuenta (indicado por la "X" roja en el diagrama).

El ID externo ayuda a impedir que cualquier otro cliente engañe a Example Corp para que acceda a los recursos de forma inintencionada, lo que mitiga el problema del suplente confuso.

¿Cuándo debería usar un ID externo?

Utilice un ID externo en las siguientes situaciones:

  • Es un propietario de la cuenta de AWS y ha configurado un rol para un tercero que obtiene acceso a otras cuentas de AWS, además de la suya. Debe pedir a ese tercero un ID externo que incluye cuándo asume su rol. A continuación, busque el ID externo en la política de confianza de su rol. De este modo se garantiza que el tercero puede asumir su rol solo cuando actúa en su nombre.

  • Se encuentra en la posición de asumir roles en nombre de diferentes clientes como Example Corp en nuestra situación anterior. Debe asignar un ID externo único a cada cliente e indicarle que lo agregue a la política de confianza de su rol. A continuación, deberá asegurarse de incluir siempre el ID externo correcto en sus solicitudes para asumir roles.

    Es muy probable que ya tenga un identificador único para cada uno de sus clientes y que este ID único sea suficiente para su uso como ID externo. El ID externo no es un valor especial que deba crear de forma explícita o realizar un seguimiento por separado, solo para este fin.

    Siempre debe especificar el ID externo en las llamadas a la API AssumeRole. Además, cuando un cliente le ofrezca un ARN de rol, pruebe si puede asumir el rol tanto con como sin el ID externo correcto. Si puede asumir el rol sin el ID externo correcto, no almacene el ARN de rol del cliente en su sistema. Espere hasta que el cliente haya actualizado la política de confianza de rol para solicitar el ID externo correcto. De esta forma ayuda a sus clientes a hacer lo correcto, lo que ayuda a mantenerles a ambos protegidos frente al problema del suplente confuso.