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, supongamos 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, un identificador 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.
Algunos servicios de AWS (servicios de llamadas) utilizan la entidad principal de su servicio de AWS para acceder a los recursos de AWS de otros servicios de AWS (servicios llamados). En algunas de estas interacciones de servicios, puede configurar los servicios de llamadas para que se comuniquen con los recursos de un servicio llamado en otra Cuenta de AWS. Por ejemplo, la configuración de AWS CloudTrail para escribir en un bucket central de Amazon S3 que se encuentra en otra Cuenta de AWS. Al servicio de llamadas, CloudTrail, se le concede acceso a su bucket S3 según la política del bucket S3 al agregar una declaración de permiso para cloudtrail.amazonaws.com.
Cuando la entidad principal de un servicio de llamadas de AWS accede a un recurso de un servicio llamado, la política de recursos del servicio llamado solo autoriza a la entidad principal del servicio de AWS, y no a la persona que configuró el servicio de llamadas. Por ejemplo, un bucket de Amazon S3 que confía sin condiciones en la entidad principal del servicio de CloudTrail podría recibir los registros de CloudTrail de las Cuentas de AWS que configure un administrador de confianza, pero también los registros de CloudTrail de una persona no autorizada en su Cuenta de AWS, si conoce el nombre del bucket de Amazon S3.
El problema del suplente confuso surge cuando una persona utiliza la confianza de la entidad principal de un servicio de AWS para obtener acceso a recursos a los que no debía tener acceso.
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:
-
Al empezar a utilizar el servicio de Example Corp, usted proporciona el ARN de AWS1:ExampleRole a Example Corp.
-
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.
-
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.
-
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.

-
Como anteriormente, al empezar a utilizar el servicio de Example Corp, usted proporciona el ARN de AWS1:ExampleRole a Example Corp.
-
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.
-
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.
-
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
En el siguiente diagrama, se muestra el problema del suplente confuso entre servicios mediante el ejemplo de interacción entre CloudTrail y Amazon S3, en el que una persona no autorizada escribe los registros de CloudTrail en un bucket de Amazon S3 al que no está autorizada a acceder.

Para evitar que una persona no autorizada utilice la confianza de una entidad principal de AWS para acceder a sus recursos, las entidades principales del servicio de AWS incluyen información sobre el recurso de AWS, la Cuenta de AWS y la organización de AWS en nombre de la que actúan.
Esta información está disponible en valores clave de condición global que se pueden utilizar en una política de recursos o en una política de control de recursos para las solicitudes realizadas por las entidades principales del servicio de AWS. Le recomendamos que utiliceaws:SourceArn, aws:SourceAccount, aws:SourceAccount o aws:SourceOrgPaths en sus políticas de recursos siempre que se conceda permiso a una entidad principal del servicio de AWS para acceder a uno de sus recursos. Estas claves de condición le permiten comprobar en sus políticas de recursos o políticas de control de recursos que las entidades principales del servicio de AWS que acceden a sus recursos lo hacen en nombre de los recursos de AWS, las Cuentas de AWS o AWS Organizations previstos.
-
Use
aws:SourceArn
para permitir que una entidad principal del servicio de AWS acceda a sus recursos en nombre de un recurso específico, como una ruta de AWS CloudTrail específica o una flota de AppStream. -
Use
aws:SourceAccount
para permitir que una entidad principal del servicio de AWS acceda a sus recursos en nombre de un usuario de Cuenta de AWS específico. -
Use
aws:SourceOrgID
para permitir que una entidad principal del servicio de AWS acceda a sus recursos en nombre de un usuario de AWS Organizations específico. -
Use
aws:SourceOrgPaths
para permitir que la entidad principal del servicio de AWS acceda a sus recursos en nombre de una ruta de AWS Organizations específica.
En el siguiente diagrama, se muestra el escenario del suplente confuso entre servicios cuando un recurso se configura con la clave contextual de condición global aws:SourceAccount
y una persona no autorizada de otra cuenta intenta acceder a recursos de AWS a los que no debe tener acceso.

El uso de las claves de condición global aws:SourceArn
, aws:SourceAccount
, aws:SourceOrgID
y aws:SourceOrgPaths
en una política le ayuda a garantizar que las entidades principales del servicio accedan a sus recursos en su nombre. Recomendamos utilizar estas claves de condición siempre que se conceda acceso a uno de sus recursos a una entidad principal del servicio de AWS.
nota
Algunas interacciones de Servicio de AWS tienen controles adicionales para evitar problemas de suplente confuso entre servicios que ponen a prueba el acceso de los usuarios a un recurso. Por ejemplo, cuando se concede una clave de KMS a un Servicio de AWS, AWS KMS utiliza el contexto de cifrado asociado al recurso y la concesión de clave para evitar problemas de suplente confuso entre servicios.
Consulte la documentación de los servicios que utiliza para obtener más información sobre los mecanismos específicos de cada servicio que pueden ayudar a evitar los riesgos de suplente confuso entre servicios y sobre si aws:SourceArn
, aws:SourceAccount
, aws:SourceOrgID
y aws:SourceOrgPaths
son compatibles.
Protección del suplente confuso entre servicios con políticas basadas en recursos
La siguiente política de ejemplo concede a la entidad principal del servicio de cloudtrail.amazonaws.com
acceso al bucket de Amazon S3, arn:aws:s3:::amzn-s3-demo-bucket1, solo cuando la entidad principal del servicio actúa en nombre de Cuenta de AWS 111122223333.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CloudTrailAclCheck",
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1
",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
},
{
"Sid": "AWSCloudTrailWrite",
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/[optionalPrefix]/Logs/myAccountID/*
",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
Esta política de bucket de ejemplo concede a la entidad principal del servicio de appstream.amazonaws.com
acceso al script de powershell examplefile.psh en s3://amzn-s3-demo-bucket2 solo cuando actúa en nombre de la flota de Amazon AppStream especificada, especificando el ARN de la flota con aws:SourceArn
.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"appstream.amazonaws.com"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket2/examplefile.psh
",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333
:fleet/ExampleFleetName
"
}
}
}
]
}
Protección del suplente confuso entre servicios con políticas de control de recursos
Puede utilizar las políticas de control de recursos (RCP) para aplicar controles de suplente confuso entre servicios a los recursos compatibles de Servicios de AWS. Las RCP le permiten aplicar de forma centralizada controles de suplente confuso entre servicios a sus recursos. Puede utilizar claves de condición como aws:SourceOrgId
y aws:SourceOrgPaths
con las RCP adjuntas a su AWS Organizations, unidades organizativas (OU) o Cuentas de AWS dentro de su organización sin agregar declaraciones a políticas basadas en recursos específicos. Para obtener más información acerca de las RCP y los servicios compatibles, consulte Políticas de control de recursos (RCP) en la Guía del usuario de AWS Organizations.
En el siguiente ejemplo, la RCP deniega a las entidades principales del servicio de AWS el acceso a los buckets de Amazon S3 de sus cuentas miembro cuando aws:SourceOrgID
no es igual a o-ExampleOrg. Debe haber un permiso correspondiente en la política basada en recursos del bucket de Amazon S3 para permitir que las entidades principales del servicio de AWS tengan un SourceOrgID igual a o-ExampleOrg.
Esta política aplica el control solo a las solicitudes de las entidades principales del servicio ("Bool":
{"aws:PrincipalIsAWSService": "true"}
) que tienen la clave aws:SourceAccount
("Null": {"aws:SourceAccount":
"false"}
), de modo que las integraciones de servicios que no requieren el uso de la clave de condición y las llamadas de las entidades principales no se ven afectadas. Si la clave de condición aws:SourceAccount
está presente en el contexto de la solicitud, se evaluará la condición nula como verdadera, lo que provocará que se aplique aws:SourceOrgID
. Puede utilizar aws:SourceAccount
en lugar de aws:SourceOrgID
en el operador de la condición nula para que el control siga siendo válido si la solicitud se origina en una cuenta que no pertenece a una organización.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RCPEnforceConfusedDeputyProtectionForS3",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:*"
],
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceOrgID": "o-ExampleOrg
"
},
"Null": {
"aws:SourceAccount": "false"
},
"Bool": {
"aws:PrincipalIsAWSService": "true"
}
}
}
]
}