English
Español
Français
Deutsch
日本語
한국어
العربيةAnálisis de rutas de ataque frente a validación de rutas de ataque en AWS
Puntos clave
- El análisis de rutas de ataque enlaza hallazgos individuales en la secuencia de pasos que un atacante podría dar desde un punto de entrada hasta un objetivo. Responde a la pregunta de qué se podría encadenar.
- La validación de rutas de ataque comprueba cada cadena candidata contra la autorización que AWS evaluaría: políticas de identidad, políticas de recursos, políticas de confianza, políticas de control de servicios, límites de permisos y claves de condición. Responde a cuáles de esas cadenas funcionan.
- En AWS las dos respuestas difieren mucho. Una cadena que parece completa en un grafo puede seguir bloqueada por una SCP, un límite de permisos o una clave de condición, y solo resolverlos todos a la vez te dice qué cadenas sobreviven.
- La validación en el plano de control no requiere ejecutar un exploit. Resolver la autorización real en modo de solo lectura da la misma respuesta sin ninguno de los riesgos.
- La priorización depende de la validación. En la cuenta de laboratorio de Pathbreak, 4,942 rutas candidatas se redujeron a una lista ordenada en la que dos cambios eliminaron el 80 por ciento del riesgo.
El análisis de rutas de ataque encuentra las cadenas de permisos, relaciones de confianza y exposiciones que un atacante podría usar para llegar desde un punto de entrada hasta un objetivo en AWS. La validación de rutas de ataque comprueba cada una de esas cadenas contra la autorización que AWS evalúa en cada llamada y se queda con las que funcionan.
En lugar de una lista de 3,000 problemas aislados, el análisis produce cadenas: esta instancia pública tiene este rol, este rol puede pasar aquel rol a Lambda, aquel rol es administrador. La mayoría de las plataformas de seguridad en la nube ofrecen hoy alguna forma de análisis de este tipo, y es una gran mejora respecto a las listas ordenadas por severidad.
La validación es el paso que sigue al análisis. En AWS es una pregunta más difícil de lo que parece, porque en cada decisión intervienen varios tipos de política, y las dos respuestas divergen más de lo que la mayoría de los equipos espera.
Qué hace el análisis de rutas de ataque
iam:PassRole y lambda:CreateFunction en manos del mismo principal, este crea una función, le entrega un rol privilegiado y la función se ejecuta como ese rol. Este artículo la lleva de candidata en el grafo a ruta demostrada.El análisis parte de un inventario: principales, roles, políticas, relaciones de confianza, cómputo, almacenamiento y las aristas de red entre ellos. Construye un grafo y después lo recorre buscando rutas que terminen en algo sensible: un rol de administrador, una base de datos de producción, un bucket con datos de clientes. Cada salto es una técnica conocida. iam:PassRole con lambda:CreateFunction es un salto. sts:AssumeRole hacia una cuenta que confía en ti es un salto. Una URL de función pública es un punto de entrada.
El resultado es un conjunto de rutas candidatas. Son candidatas porque el grafo se construyó a partir de los documentos de política tal como están escritos, y una política de identidad por sí sola no te dice qué decidirá AWS cuando se haga la llamada.
Dónde se detiene el análisis
AWS evalúa cada llamada a la API contra varios documentos a la vez, y cualquiera de ellos puede convertir un permiso en una denegación. Una ruta que existe en el grafo puede quedar bloqueada por cualquiera de estos:
- Políticas de control de servicios. Una SCP en la unidad organizativa puede denegar
lambda:CreateFunctionpara toda la OU, y ninguna política de identidad dentro de ella puede anularlo. - Límites de permisos. Un límite en el principal de origen acota lo que pueden conceder sus políticas de identidad. Si el límite omite
iam:PassRole, el paso del rol falla aunque la política de identidad lo permita. - Políticas de confianza. El rol de destino debe confiar en el servicio o principal del que depende el salto. Un rol que no confía en
lambda.amazonaws.comno se puede pasar a Lambda, tenga lo que tenga quien llama. - Políticas de recursos. El bucket, la clave, la cola o la función al final de la ruta tiene su propia política, y esta puede denegar al principal con el que llegó la cadena.
- Claves de condición.
iam:PassedToService,aws:SourceAccount,aws:PrincipalOrgIDy la comprobación dests:ExternalIdacotan una concesión que parece amplia en la lista de acciones. - Denegaciones explícitas. Una sentencia de denegación en cualquier punto de la evaluación prevalece sobre todos los permisos, y a menudo está en una política distinta de la que leyó el grafo.
Leer cualquiera de estos documentos es fácil. El trabajo está en resolverlos todos juntos, en el orden en que lo hace AWS, para cada paso de cada cadena, y ese paso es lo que separa una ruta candidata de una demostrada. Si te lo saltas, la lista es larga, y una buena parte de ella fallaría en la primera llamada.
Cómo validar una ruta de ataque en la nube en AWS
Tomemos una cadena habitual. Un rol de CI llamado ci-deploy tiene iam:PassRole sobre un rol llamado data-pipeline, además de lambda:CreateFunction y lambda:InvokeFunction. El rol data-pipeline tiene AdministratorAccess. En el grafo, eso es una ruta de dos saltos desde el rol de CI hasta administrador: crear una función con data-pipeline adjunto, invocarla, y el código de la función se ejecuta como administrador.
El análisis marca la ruta como alcanzable. La validación la recorre después una comprobación a la vez:
- ¿La política de identidad de
ci-deploypermiteiam:PassRolesobre el ARN dedata-pipeline, o sobre un comodín que lo cubra? Sí, sobrearn:aws:iam::*:role/data-*. - ¿El paso del rol está acotado por
iam:PassedToService? No hay ninguna condición, así que se acepta cualquier servicio. - ¿La política de confianza de
data-pipelineconfía enlambda.amazonaws.com? Sí, se creó para una canalización basada en Lambda. - ¿Alguna SCP en la OU de la cuenta deniega
lambda:CreateFunctionoiam:PassRole? La OU tiene una SCP, y no deniega ninguna de las dos. - ¿Algún límite de permisos en
ci-deployexcluye alguna de las dos acciones? El rol no tiene límite. - ¿La ejecución de la función llega a algo que importe?
data-pipelinees administrador, así que la respuesta es todo lo que hay en la cuenta y, a través de dos relaciones de confianza entre cuentas, dos cuentas más.
Todas las comprobaciones pasaron, así que la ruta está demostrada. No se creó ninguna función y no se invocó nada. Cada paso resolvió los mismos documentos que resolvería AWS, en el mismo orden, y devolvió la misma decisión. Eso es lo que significa validar en el plano de control. El exploit es un permiso, así que la prueba es el resultado de la autorización.
La solución se deduce del paso dos. El cambio más acotado es añadir iam:PassedToService a la concesión del paso de rol, de modo que solo el servicio previsto pueda recibir el rol, o sustituir el ARN con comodín por el único rol que CI necesita. Tras el cambio, las mismas seis comprobaciones se ejecutan de nuevo y el paso dos falla. La ruta ha desaparecido, y la confirmación queda registrada junto al hallazgo. La entrada del mapa para esta cadena incluye los eventos de CloudTrail y el análisis completo.
¿Es seguro validar rutas de ataque en producción?
Sí, cuando la validación es de solo lectura. Pathbreak se conecta mediante un rol de IAM de solo lectura y de mínimo privilegio que creas tú y que puedes revocar en cualquier momento. Todas las llamadas que hace son lecturas (Get, List y Describe), y la autorización de cada paso se resuelve a partir de los documentos de política que devuelven esas llamadas. No se crea ninguna función, no se asume ningún rol de la ruta y no se cambia ningún recurso, así que las cargas de trabajo de producción siguen funcionando como antes.
La sesión del rol y sus lecturas aparecen en CloudTrail como eventos de administración bajo el rol de Pathbreak, lo que facilita auditar la actividad. Pathbreak lee la configuración, incluidos los lugares donde suelen quedar expuestas credenciales, como los datos de usuario de las instancias, las variables de entorno de las funciones y las salidas de las pilas. No lee el contenido del almacenamiento de objetos ni de las bases de datos.
La validación de solo lectura responde a una pregunta en cada paso: ¿autorizaría AWS esta llamada para esta entidad principal? No prueba el código de las aplicaciones, los exploits contra hosts en ejecución ni si la detección y la respuesta atraparían a un atacante. Eso lo cubre una evaluación manual de seguridad de AWS, y Pathbreak funciona junto a ella. Algunas herramientas validan ejecutando pasos de ataque en el entorno, y esta comparativa explica cuándo encaja cada enfoque.
Por qué la diferencia decide qué arreglas primero
Ordenar las rutas por impacto solo funciona si las rutas son reales. Una lista que mezcla cadenas demostradas con cadenas que una SCP ya bloquea empujará a los equipos hacia trabajo que no cambia nada. En la cuenta de laboratorio de Pathbreak, el análisis produjo 4,942 rutas candidatas. Tras la validación y la ordenación por radio de impacto, un solo Deny en un rol eliminó 3,893 de las 4,087 rutas restantes, y dos cambios juntos eliminaron el 80 por ciento del riesgo de la cuenta. Ese orden solo se hace visible una vez que cada ruta se ha resuelto contra la autorización real.
Cómo lo hace Pathbreak
Pathbreak construye el grafo, razona sobre él para producir cadenas candidatas y después valida cada cadena de extremo a extremo resolviendo la autorización que AWS evaluaría: políticas de identidad y de recursos, políticas de confianza, SCP, límites de permisos y condiciones. El acceso es de solo lectura y no se ejecuta nada. Cada ruta validada se ordena por lo que alcanza y viene con el cambio concreto que la rompe. Cuando el cambio se despliega, la ruta se vuelve a evaluar y el resultado queda registrado, de modo que la solución se confirma con evidencia.
Preguntas frecuentes
¿Qué es el análisis de rutas de ataque?
El análisis de rutas de ataque conecta hallazgos de seguridad individuales en la secuencia de pasos que un atacante podría dar desde un punto de entrada hasta un objetivo, normalmente construyendo un grafo de identidades, permisos y recursos y buscando en él rutas hacia activos sensibles. Pathbreak construye este grafo para AWS y después valida cada ruta que encuentra.
¿Qué es la validación de rutas de ataque?
La validación de rutas de ataque comprueba cada ruta candidata contra la autorización que el proveedor de nube evaluaría en cada paso. En AWS eso significa resolver juntas las políticas de identidad, las políticas de recursos, las políticas de confianza, las políticas de control de servicios, los límites de permisos y las claves de condición, y confirmar que la ruta funciona. Pathbreak valida así las rutas de ataque en AWS, en modo de solo lectura, y registra el resultado de cada salto.
¿Validar significa ejecutar exploits en mi cuenta de AWS?
No. En el plano de control de AWS los movimientos del atacante son llamadas a la API, y cada llamada la permiten o deniegan documentos de política. Resolver esos documentos en modo de solo lectura da la misma decisión que daría AWS, así que una ruta se puede demostrar sin crear, invocar ni cambiar nada. Así es como Pathbreak valida las rutas de ataque en AWS.
¿Puede un CSPM hacer validación de rutas de ataque?
Las herramientas CSPM y CNAPP ofrecen análisis de rutas de ataque sobre un grafo de tu configuración. La validación tal como se describe aquí significa evaluar cada capa de la autorización de AWS en cada paso y confirmar la solución después. Pathbreak hace eso y puede funcionar junto a un CSPM o sustituir a un escáner independiente.
¿Cómo se validan las rutas de ataque en la nube en AWS?
Se construye un grafo de entidades principales, roles, relaciones de confianza y recursos, y se generan cadenas candidatas a partir de él. Para cada paso de una cadena se resuelven juntas la política de identidad, la política de recursos, la política de confianza, la política de control de servicios, el límite de permisos y las claves de condición, en el orden en que AWS las evalúa, y solo se conservan las cadenas en las que todos los pasos están permitidos. Después de aplicar una corrección, se repiten las mismas comprobaciones para confirmar que la ruta ha desaparecido. Pathbreak automatiza estos pasos para AWS.
¿Qué aparece en CloudTrail cuando Pathbreak valida rutas de ataque?
La llamada sts:AssumeRole que inicia cada sesión en el rol de IAM de solo lectura que creaste, y después llamadas de lectura. Las llamadas Get, List y Describe de Pathbreak aparecen en CloudTrail como eventos de administración bajo ese rol. No se crea, invoca ni cambia nada de la ruta, así que la validación no deja eventos de escritura.
¿Qué no cubre la validación de rutas de ataque de solo lectura?
Responde si AWS autorizaría cada paso de una ruta. No prueba el código de las aplicaciones, los exploits contra hosts en ejecución ni si la detección y la respuesta atraparían a un atacante. Eso lo cubre una evaluación manual de seguridad de AWS, y Pathbreak funciona junto a ella.
Descubre qué rutas de ataque de tus cuentas de AWS están demostradas, y el cambio que rompe cada una.
Solicitar una demo Ver la demo