Identidades que pueden ampliarse solas

Leer una política por lo que hace hoy no basta: hay que leerla también por lo que permite llegar a hacer. Un permiso que cambia las propias reglas de acceso —adjuntar una política a una identidad, crear una nueva identidad con más poder, asumir un rol más amplio, o dejar que otro recurso actúe con un rol potente— abre una ruta de escalada. La identidad no necesita tener administración; le basta con poder concedérsela. Por eso el permiso de repartir o modificar permisos se trata como lo que es: equivalente a tener todo lo que podría repartirse.

Un permiso que puede ampliar permisos vale, en la práctica, tanto como el permiso más alto al que da acceso.

El rol que Cobalto usa para desplegar la aplicación parece acotado: su nombre y su descripción hablan de publicar versiones. Pero entre sus permisos hay uno que le deja adjuntar políticas a las identidades, incluido a sí mismo. Con eso, el rol de despliegue puede adjuntarse la política de administración completa y pasar de "publicar versiones" a "hacer cualquier cosa en la cuenta" en un paso. Quien comprometa ese rol —una credencial del sistema de despliegue, un fallo en la canalización— no hereda despliegues, hereda la cuenta. Es un permiso de más que no se ve leyendo lo que el rol hace a diario, solo leyendo lo que puede concederse.

Un rol que puede adjuntarse la política de administración no es un rol acotado, aunque todo lo demás en él lo parezca.

En Azure la escalada aparece con otro nombre pero la misma forma. Una cuenta de servicio de Cobalto tiene asignado el rol de administración de acceso de usuarios: no es propietario y no toca datos, pero puede repartir asignaciones de rol a cualquier identidad sobre cualquier recurso. Es decir, puede concederse a sí misma el rol de propietario cuando quiera. Un rol que no accede a nada pero reparte accesos es exactamente la trampa de la escalada: su peligro no está en lo que hace, sino en lo que puede dejar que se haga. Se cierra quitando la capacidad de repartir permisos a quien no administra permisos como su trabajo.

Repartir asignaciones de rol es administrar la cuenta entera por un camino lateral, aunque el rol no toque ni un dato.

Cerrar estas rutas no es recortar lo que el rol hace, sino quitarle la capacidad de ampliarse. Al rol de despliegue de Cobalto se le retira el permiso de adjuntar políticas —si de verdad necesita tocar alguna identidad, se acota a una concreta y a políticas concretas, nunca a adjuntar cualquiera a cualquiera—. A la cuenta de servicio de Azure se le quita el rol que reparte asignaciones. La administración de permisos se concentra en unas pocas identidades cuyo trabajo es justo ese, con segundo factor y vigiladas, y se separa de las identidades que solo operan. Así, comprometer un rol operativo ya no abre un camino hacia administración.

Separar quién opera de quién reparte permisos es lo que impide que un rol de trabajo se convierta en administrador por la puerta de atrás.

Abre el laboratorio de escalada de Cobalto. Entre las identidades, encuentra la que puede adjuntarse o concederse permisos de administración pese a parecer acotada, y lee el informe de la revisión, que cierra con el código de la sala.