Ataques de confianza entre cuentas de AWS: cómo el encadenamiento de roles llega a los activos más valiosos

Por el equipo de Pathbreak · 11 de agosto de 2026 · 6 min de lectura

El AWS multicuenta es la forma recomendada de gestionar un patrimonio grande, y los roles de IAM entre cuentas son lo que lo mantiene unido. Una cuenta de seguridad lee los logs de cada cuenta de carga de trabajo. Una cuenta de servicios compartidos despliega en otras. Un proveedor asume un rol para ejecutar su producto. Todo eso es confianza entre cuentas funcionando según el diseño.

También es el mapa que sigue un atacante. Aterriza en una cuenta, busca un rol que puedas asumir en la siguiente y repite. Este artículo cubre cómo se abusa de la confianza entre cuentas, cómo el encadenamiento de roles llega a los activos más valiosos y cómo romper la ruta con un solo cambio.

Cómo funciona la confianza entre cuentas

Cada rol de IAM tiene dos políticas. La política de permisos dice qué puede hacer el rol. La política de confianza, la política de assume-role, dice quién está autorizado a convertirse en él. Para pasar a un rol, un principal llama a sts:AssumeRole y obtiene credenciales temporales, siempre que la política de confianza del rol destino permita a ese principal y el llamante tenga permiso sts:AssumeRole.

La política de confianza controla quién puede entrar, por eso la seguridad entre cuentas depende de con cuánta precisión nombres a los principales que permites.

Dónde falla la confianza

Principales comodín en las políticas de confianza

La política de confianza más peligrosa y más malinterpretada es un principal comodín. Una instrucción que permite "Principal": { "AWS": "*" } con "Action": "sts:AssumeRole" no significa cualquier identidad de tu cuenta. Abre el rol a todas las cuentas de AWS del mundo. Hay un segundo requisito, la identidad llamante también debe tener permiso sts:AssumeRole sobre el rol, pero por eso el comodín es un riesgo práctico: un atacante se concede ese permiso a sí mismo en su propia cuenta de AWS, de modo que aporta el segundo requisito gratis. Los equipos leen el comodín como "todos los de mi equipo" y lo publican. Lo que publicaron es un rol que cualquier atacante puede asumir desde una cuenta que controla. En un rol con permisos significativos, eso regala todo lo que el rol puede hacer. Si de verdad necesitas un principal amplio, acótalo con una Condition como aws:PrincipalAccount o aws:PrincipalOrgID, y mejor aún, nombra los ARN exactos de los roles que pretendes confiar.

El confused deputy en los roles de terceros

Cuando permites que un proveedor SaaS asuma un rol en tu cuenta, ese proveedor usa una cuenta de AWS para dar servicio a muchos clientes. Si tu política de confianza solo nombra la cuenta del proveedor, otro de los clientes del proveedor podría inducirlo a asumir tu rol. La solución es un external ID, un secreto compartido en la condición, o una condición aws:SourceArn o aws:SourceAccount que ate la asunción a tu relación específica. Un rol de terceros sin uno es una exposición clásica de confused deputy.

Encadenamiento de roles entre cuentas

Un solo salto rara vez llega al objetivo, así que las rutas reales se encadenan. El atacante asume un rol en la cuenta de dev, que resulta ser de confianza para un rol en la cuenta de servicios compartidos, que puede asumir un rol en producción, que puede leer las credenciales de la base de datos en Secrets Manager. Cuatro llamadas legítimas de sts:AssumeRole, y un punto de apoyo en la cuenta menos importante se ha convertido en acceso a los datos más importantes.

Lo que hace peligroso el encadenamiento es que cada salto está autorizado, no se explota nada, y las credenciales son temporales y esperadas. Para CloudTrail parece roles haciendo su trabajo. La única forma de ver el peligro es mirar toda la cadena a la vez y preguntar dónde termina, en lugar de juzgar cada relación de confianza por su cuenta.

AWS sí añade fricción. Las sesiones de rol encadenadas están limitadas a una hora y no pueden renovarse encadenando más. Eso limita la vida de la sesión, pero no cierra la ruta.

Por qué los límites de cuenta parecen más seguros de lo que son

Los equipos tratan el límite de la cuenta como un límite de seguridad, y es uno bueno para el radio de impacto. El problema es que los roles entre cuentas se perforan a propósito a través de él, y cada uno lo revisa de forma aislada quien sea dueño de esa cuenta, así que nadie revisa la cadena en su conjunto. La cómoda relación de confianza del equipo de dev y el rol compartido del equipo de plataforma son cada uno razonables, y juntos forman una ruta que ninguno de los dos equipos puede ver desde donde está. La revisión aislada pasa por alto las rutas entre cuentas por la misma razón que pasa por alto la escalada de IAM. El riesgo está en cómo se conectan los roles, y revisar un rol cada vez nunca lo muestra.

Herramientas que lo mapean

Las herramientas basadas en grafos ayudan. PMapper y Cartography pueden modelar roles y relaciones de confianza entre cuentas, y AWS IAM Access Analyzer informa del acceso externo a tus roles, incluida la confianza entre cuentas que quizá hayas olvidado. Estas te dan enlaces candidatos. La pregunta que queda es cuáles de esas cadenas candidatas se resuelven, todos los saltos, todas las condiciones, todas las políticas de permisos en vigor, hacia algo que te importe. Un enlace de confianza que no lleva a nada sensible es ruido, y una cadena de cuatro saltos hasta tus datos de producción es la que necesitas corregir.

Cómo romper la cadena

Como con cualquier ruta, cortar un enlace basta. Reemplaza los principales de cuenta raíz en las políticas de confianza por ARN de rol exactos. Exige un external ID o una condición aws:SourceArn en cada rol de terceros. Elimina la confianza entre cuentas que ya no sirve a ningún propósito, los roles de proveedor inactivos son un hallazgo común. Donde puedas, usa service control policies para impedir que clases enteras de cuenta asuman roles sensibles. Después alerta sobre las llamadas de AssumeRole hacia roles críticos desde orígenes inesperados.

La decisión de criterio es qué enlace cortar. El enlace correcto corta la ruta del atacante sin tocar nada legítimo, y el equivocado rompe un pipeline. Eso requiere saber a dónde lleva cada cadena.

Cómo lo aborda Pathbreak

Pathbreak construye el grafo de confianza completo entre tus cuentas de AWS y lo trata como un único espacio conectado, como lo hace un atacante. Resuelve cada salto de AssumeRole contra las políticas de confianza, las políticas de permisos y las condiciones reales, y después confirma qué cadenas llegan a los activos más valiosos, como los datos de producción, las copias de seguridad o la gestión de la organización. Funciona en modo de solo lectura, de modo que mapear tu confianza nunca la toca.

Por cada cadena que se resuelve, Pathbreak muestra los saltos y señala el único enlace de confianza que la rompe, normalmente una política de confianza demasiado amplia o un rol de proveedor olvidado. Puedes ver las cadenas que cubrimos en la página de rutas de ataque, la mecánica en cómo funciona y cómo gestionamos el acceso de privilegio mínimo en la página de Confianza y Seguridad. Para ver cómo aplica el mismo razonamiento dentro de una sola cuenta, consulta nuestro artículo sobre la escalada de privilegios de AWS IAM.

Preguntas frecuentes