External ID y el diputado confundido

Cuando permite que un tercero asuma un rol en su cuenta, puede surgir un riesgo de seguridad denominado problema del delegado confundido. El ID externo es el control sencillo, pero fundamental, que lo evita. Este patrón aparece en el examen cuando un proveedor de SaaS necesita acceso a su cuenta de AWS.

Un delegado confundido es una entidad de confianza (el delegado) a la que se engaña para que utilice su autoridad en nombre de un atacante. En AWS, un servicio de terceros tiene permiso para asumir roles en las cuentas de muchos clientes; si nada vincula la solicitud con la relación legítima con el cliente, un atacante podría engañarlo para que asumiera su rol.

Imagine un servicio SaaS de monitorización que asume un rol en la cuenta de cada cliente. El SaaS utiliza una identidad de AWS para todos. Si un atacante que también es cliente adivina el ARN de su rol, podría convencer al SaaS de asumir su rol, ya que el SaaS es la entidad principal de confianza. El ID de cuenta por sí solo no basta para impedirlo.

El ID externo es un valor único y secreto que el proveedor asigna a su relación. Debe incluirlo en la política de confianza del rol como condición, y el proveedor debe proporcionar exactamente el mismo valor al llamar a AssumeRole. Como el atacante no conoce su ID externo, no puede engañar al proveedor para que asuma su rol.

Esta política de confianza requiere el ID externo correspondiente. AssumeRole solo se ejecuta correctamente cuando el proveedor proporciona el mismo valor, lo que neutraliza el ataque del delegado confundido.

Es fundamental que el proveedor, y no el cliente, genere y controle el ID externo. Esto evita que los clientes colaboren para reutilizar el mismo valor. Las directrices de AWS son explícitas: como tercero, debe asignar a cada cliente un ID externo único y exigirlo en cada asunción.

El ID externo no está pensado para ser un secreto como una contraseña; puede aparecer en las instrucciones de configuración. Su valor de seguridad proviene de ser único para cada cliente y estar controlado por el proveedor, de modo que un atacante no pueda hacer que el delegado utilice el valor del cliente equivocado. Trátelo como un token contra la suplantación de identidad, no como una credencial.

El ID externo controla quién puede asumir el rol, pero aún debe delimitar qué puede hacer el rol mediante políticas de permisos estrictas. Incluso un proveedor autorizado correctamente solo debe recibir los permisos mínimos necesarios. Combine el ID externo, una entidad principal específica y permisos de mínimo privilegio para acceder de forma segura como tercero.

El patrón del delegado confundido también se aplica a los servicios de AWS que actúan en su nombre. La confianza entre servicios suele utilizar claves de condición como aws:SourceArn y aws:SourceAccount en las políticas de recursos para garantizar que el servicio llamador actúa en nombre de su recurso: es la misma idea defensiva con una aplicación diferente.

Siempre que una pregunta describa a un tercero o SaaS asumiendo un rol entre cuentas, la respuesta segura casi siempre incluye un ID externo en la política de confianza. Si el escenario es entre servicios, busque en su lugar condiciones aws:SourceArn/aws:SourceAccount. Reconocer la pista le orienta directamente hacia el control adecuado.

El problema del delegado confundido permite que un atacante engañe a un tercero de confianza para que utilice indebidamente su acceso. El ID externo, único para cada cliente y controlado por el proveedor, lo impide al exigir un valor coincidente en AssumeRole. Para los servicios de AWS, utilice aws:SourceArn y aws:SourceAccount. Combine siempre estos controles con permisos de mínimo privilegio.

Compruebe sus conocimientos sobre el concepto de delegado confundido.

El problema del delegado confundido surge cuando se engaña a un tercero de confianza para que utilice indebidamente su acceso entre cuentas. El ID externo, único para cada cliente y controlado por el proveedor, lo evita mediante una condición de política de confianza sobre sts:ExternalId. Para la confianza entre servicios de AWS, utilice aws:SourceArn y aws:SourceAccount, siempre aplicando el mínimo privilegio.