Privilegios nuevos sin respaldo

Un rol crítico llega a una cuenta de dos maneras. La directa: alguien con permiso escribe «esta cuenta recibe este rol». La indirecta: alguien añade la cuenta a un grupo que ya tiene el rol, y la cuenta lo hereda sin que quede una asignación a su nombre. Una caza que mira solo la primera se pierde la segunda, y la segunda es la más cómoda para quien no quiere dejar una asignación visible.

La búsqueda cubre las dos y las cruza con lo aprobado. Para cada privilegio nuevo: ¿hay un ticket que lo respalda, para esa cuenta, ese rol y esa fecha?

Ejecuta roles_criticos, asignaciones_rol y cambios_aprobados para ver el camino directo y lo que lo respalda. Después ejecuta membresias_grupo y roles_de_grupo para ver el camino indirecto: qué altas hubo, con qué ticket y qué rol da cada grupo.

Una pertenencia importa cuando el grupo da un rol crítico. Un alta a un grupo que da un rol de lectura de facturación no es lo mismo que un alta a uno que da administración de usuarios.

Para el informe no basta saber qué cuenta ganó el privilegio: hay que decir por dónde. El grupo es el punto donde se corrige, quitando a la cuenta de él, y también el punto donde se revisan las demás altas que el mismo grupo recibió. Los demás miembros del grupo no son sospechosos por serlo: cada uno tiene su propia pregunta y su propio ticket, y la tabla ya los muestra.

Vuelve a membresias_grupo y fíjate en el nombre del grupo de esa alta.

En asignaciones_rol hay una asignación directa del rol de administración sin ticket en el momento de hacerse: la de la noche del 15 de septiembre. En cambios_aprobados aparece un ticket de la mañana siguiente que la cubre, con un motivo de guardia nocturna y la aprobación posterior del jefe de TI.

La caza no se queda con la primera impresión. Un ticket posterior no es sospechoso por sí mismo, pero tampoco se acepta sin mirarlo: se comprueba que cubra la misma cuenta, el mismo rol y que sea de una fecha cercana, y se anota como explicada.

El alta sin ticket la hizo una cuenta de administración con permiso para hacerlo. Que sea una cuenta legítima no cierra la caza, la abre: una cuenta válida puede estar siendo usada por alguien que no es su dueño. La forma de comprobarlo es el siguiente cruce: los inicios de sesión de esa cuenta cerca de la hora del alta, contra sus inicios habituales.

Ejecuta inicios_admin y compara el origen y el dispositivo de cada inicio con los demás. No se concluye quién fue: se afirma qué se observó y se deja una pista para la caza de inicios fuera de patrón.