Problema del suplente confuso

El problema del suplente confuso es un problema de seguridad en el que una entidad que no tiene permiso para realizar una acción puede obligar a una entidad con más privilegios a realizar la acción. Para evitarlo, AWS proporciona herramientas que lo ayudan a proteger su cuenta si proporciona acceso a terceros (conocido como entre cuentas) u otros servicios de AWS (conocido como entre servicios) a los recursos de su cuenta.

A veces, es posible que deba otorgar acceso a terceros a sus recursos de AWS (delegar el acceso). Por ejemplo, digamos que decide contratar a una empresa externa denominada Example Corp para supervisar su Cuenta de AWS y ayudarlo 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 Cuentas de AWS para otros clientes. Puede utilizar un rol de IAM para establecer una relación de confianza entre su Cuenta de AWS y la cuenta de Example Corp. 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. La función principal del ID externo es abordar y prevenir el problema del suplente confuso.

En AWS, la suplantación entre servicios puede resultar en el problema del suplente confuso. La suplantación entre servicios puede producirse cuando un servicio (el servicio que lleva a cabo las llamadas) llama a otro servicio (el servicio al que se llama). El servicio que lleva a cabo las llamadas se puede manipular para utilizar sus permisos a fin de actuar en función de los recursos de otro cliente de una manera en la que no debe tener permiso para acceder.

Prevención del suplente confuso entre cuentas

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

Este escenario presupone lo siguiente:

• AWS1 es su cuenta de 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 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 el 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".

Example Corp puede abordar el problema del suplente confuso al solicitarle que incluya la verificación de la condición ExternalId en la política de confianza del rol. Example Corp genera un único valor de ExternalId para cada cliente y utiliza ese valor en su solicitud para asumir el rol. El valor de ExternalId debe ser único entre los clientes de Example Corp y tiene que estar controlado por Example Corp, no por sus clientes. Este es el motivo por el que lo recibe de Example Corp y que no crea el suyo propio. Esto evita que Example Corp sea un suplente confuso y conceda acceso a los recursos de AWS de otra cuenta.

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",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}

El elemento Condition (Condición) de 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 acceda a los recursos.

El siguiente diagrama ilustra este ejemplo.

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 confianza del rol, por lo que la llamada AssumeRole a la API funciona y Example Corp obtiene las credenciales de seguridad temporales para acceder a los recursos de la cuenta de 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 sus recursos.

Prevención del suplente confuso entre servicios

Le recomendamos que utilice las claves de contexto de condición global aws:SourceArn, aws:SourceAccount, aws:SourceOrgID o aws:SourceOrgPaths en las políticas basadas en recursos a fin de limitar los permisos que un servicio tiene para un recurso específico. Utilice aws:SourceArn para asociar solo un recurso al acceso entre servicios. Utilice aws:SourceAccount para permitir que cualquier recurso de esa cuenta se asocie al uso entre servicios. Utilice aws:SourceOrgID para permitir que cualquier recurso de cuentas dentro de una organización se asocie al uso entre servicios. Utilice aws:SourceOrgPaths para asociar cualquier recurso de cuentas dentro de una ruta de AWS Organizations al uso entre servicios. Para obtener más información acerca de las rutas de acceso, consulte Comprender la ruta de la entidad de AWS Organizations.

La forma más granular de protegerse contra el problema del suplente confuso es utilizar la clave de contexto de condición global aws:SourceArn con el ARN completo del recurso en sus políticas basadas en recursos. Si no conoce el ARN completo del recurso o si está especificando varios recursos, utilice la clave de condición de contexto global aws:SourceArn con comodines (*) para las partes desconocidas del ARN. Por ejemplo, arn:aws:servicename:*:123456789012:*.

Si el valor de aws:SourceArn no contiene el ID de cuenta, como un ARN de bucket de Amazon S3, debe utilizar aws:SourceAccount y aws:SourceArn para limitar los permisos.

Para protegerse contra el problema del suplente confuso a gran escala, utilice la clave de contexto de condición global aws:SourceOrgID o aws:SourceOrgPathscon el identificador de organización o la ruta de organización del recurso en sus políticas basadas en recursos. Las políticas que incluyan la clave aws:SourceOrgID o aws:SourceOrgPaths incluirán automáticamente las cuentas correctas y no requerirán una actualización manual cuando se agregan, quitan o mueven cuentas en la organización.

En el caso de las políticas de confianza de roles no vinculadas a servicios, todos los servicios de la política de confianza han realizado la acción iam:PassRole para comprobar que el rol está en la misma cuenta que el servicio de llamadas. Como resultado, no es necesario utilizar aws:SourceAccount, aws:SourceOrgID o aws:SourceOrgPaths con esas políticas de confianza. El uso de aws:SourceArn en una política de confianza permite especificar los recursos para los que se puede asumir una función, como el ARN de una función de Lambda. Algunos Servicios de AWS usan aws:SourceAccount y aws:SourceArn en políticas de confianza para funciones recién creadas, pero no es necesario usar las claves para las funciones existentes en su cuenta.

nota

Servicios de AWS que se integran con AWS Key Management Service mediante el uso de concesiones de claves de KMS no admiten las claves de condición aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, o aws:SourceOrgPaths. El uso de estas claves de condición en una política de claves de KMS provocará un comportamiento inesperado si la clave también la utiliza Servicios de AWS mediante concesiones de claves de KMS.

Prevención del suplente confuso entre servicios para AWS Security Token Service

Muchos servicios de AWS requieren que utilice roles para permitir que el servicio obtenga acceso a los recursos de otros servicios en su nombre. Un rol que asume un servicio para realizar acciones en su nombre se denomina rol de servicio. Un rol requiere dos políticas: una política de confianza de rol que especifica la entidad principal que puede asumir el rol y una política de permisos que especifica qué se puede hacer con el rol. Una política de confianza de rol es el único tipo de política basada en recursos de IAM. Otros Servicios de AWS tienen políticas basadas en recursos, como una política de bucket de Amazon S3.

Cuando un servicio asume un rol en su nombre, se debe permitir que la entidad principal del servicio realice la acción sts:AssumeRole en la política de confianza de rol. Cuando un servicio llama a sts:AssumeRole, AWS STS devuelve un conjunto de credenciales de seguridad temporales que la entidad principal del servicio utiliza para obtener acceso a los recursos permitidos por la política de permisos del rol. Cuando un servicio asume un rol en su cuenta, puede incluir las claves de contexto de condición global aws:SourceArn y aws:SourceAccount, aws:SourceOrgID y aws:SourceOrgPaths en la política de confianza de rol para limitar el acceso al rol a solo las solicitudes generadas por los recursos esperados.

Por ejemplo, en AWS Systems Manager Incident Manager, debe elegir un rol para permitir a Incident Manager ejecutar un documento de automatización de Systems Manager en su nombre. El documento de automatización puede incluir planes de respuesta automatizados para incidentes iniciados por alarmas de CloudWatch o eventos de EventBridge. En el siguiente ejemplo de política de confianza de rol, puede utilizar la clave de condición aws:SourceArn para restringir el acceso al rol de servicio en función del ARN del registro de incidentes. Solo los registros de incidentes creados a partir del recurso del plan de respuesta myresponseplan pueden utilizar este rol.

{
  "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/*"
      }
    }
  }
}

nota

No todas las integraciones de servicios con AWS STS son compatibles con las claves de condición aws:SourceArn, aws:SourceAccount, aws:SourceOrgID o aws:SourceOrgPaths. El uso de estas claves en las políticas de confianza de IAM con integraciones no compatibles puede provocar un comportamiento inesperado.