Administradores en la sombra

Un administrador declarado es quien figura con un rol de administración en la lista que mantiene la oficina de tecnología. Un administrador en la sombra es una identidad que no está en esa lista, pero cuyos permisos efectivos incluyen acciones de gestión de permisos sobre un ámbito amplio: la cuenta entera, la suscripción o el proyecto. Con esa acción puede asignarse roles, adjuntar políticas o crear credenciales, así que tiene, en la práctica, el poder que quiera.

Dos condiciones definen el hallazgo, y las dos importan. La acción tiene que ser de gestión de permisos, no de lectura, y el ámbito tiene que ser amplio. La misma acción acotada a la propia identidad, como rotar sus propias llaves, no concede poder sobre nadie más.

ls sombras
cat sombras/administradores-declarados.txt

Los informes CIEM llevan un catálogo de las acciones que, en cada nube, equivalen a poder sobre otros: en AWS, las que adjuntan o crean políticas y modifican la confianza de un rol; en Azure, la que escribe asignaciones de roles; en Google Cloud, las que modifican la política de acceso de un proyecto o emiten un token de una cuenta de servicio. No hace falta memorizarlas: se lee el catálogo del informe y se cruza con los permisos efectivos.

Abre el catálogo y la tabla de permisos efectivos sensibles. Busca la identidad de Azure que no figura como administradora declarada pero tiene la acción sensible de esa nube.

cat sombras/catalogo-de-acciones-sensibles.txt
cat sombras/permisos-efectivos-sensibles.csv

Para contar los hallazgos hay que filtrar con dos columnas: quién no es administrador declarado y qué recurso alcanza la acción. Una fila con acción sensible, sin declaración y con un ámbito que cubre toda la cuenta es un administrador en la sombra. Una fila con acción sensible, sin declaración y con un ámbito limitado a sí misma, no lo es.

Los administradores declarados quedan fuera del conteo: ya están en la lista y se revisan por otro camino.

Un informe que marca todo como crítico se deja de leer. Por eso el analista confirma el alcance antes de declarar un hallazgo. En la tabla hay una identidad no declarada con una acción de las del catálogo, y aun así no entra en el conteo, porque el recurso alcanzado es solo su propio usuario.

Busca la fila cuyo recurso_alcanzado limita la acción a la propia identidad.

Encontrar una sombra no autoriza a quitarle el permiso de inmediato. Detrás hay, casi siempre, una razón legítima: una canalización de despliegue que necesita crear políticas, o un equipo de soporte al que se le dio un rol de más por comodidad. El camino prudente empieza por preguntar a quien la administra qué función cumple y qué alternativa más estrecha sirve, y termina con el cambio hecho por una ventana aprobada.