Reconstrucción de identidad

La pregunta de alcance de una reconstrucción de identidad no es «qué cuentas usó el intruso» sino «a qué credenciales pudo llegar». Son cosas distintas: un intruso con acceso a un servidor puede haber leído archivos de configuración y variables de entorno sin dejar ninguna sesión en los registros.

Por eso el inventario parte de lo observado y se amplía por exposición: lo que se vio usar, lo que estaba en los equipos tocados y lo que esas cuentas podían dar.

Las cuentas de servicio son el punto ciego habitual: nadie inicia sesión con ellas, casi nadie las rota y su contraseña suele ser anterior a la intrusión por años. Que su última rotación sea más antigua que el primer acceso significa que el intruso, si llegó a leerla, puede seguir usándola.

En la tabla se buscan cuentas de tipo servicio con uso del intruso confirmado y una fecha de rotación que no sea reciente.

El control de la rotación se mide con una fecha de corte: la del primer acceso. Toda cuenta con uso del intruso cuya última rotación sea anterior a esa fecha conserva la credencial que él pudo haber obtenido.

El número no está escrito: sale de comparar la fecha de la última rotación de cada fila con el 13 de enero de 2026.

Las claves de integración, las contraseñas de bases de datos y las llaves de almacenamiento viven en archivos, variables y repositorios. No aparecen en el directorio, así que una rotación de cuentas que solo mira el directorio las deja intactas.

Se anotan con un id propio y con el lugar donde viven, porque rotarlas obliga a cambiar también el sitio donde se usan.

Rotar todo a la vez suena a rigor y suele ser un error: sin orden se rompen servicios, no queda registro de qué se cambió y nadie sabe si falta algo. Con orden, cada paso reduce lo que el intruso podría hacer.

El criterio del orden es lo que permite volver a entrar: primero lo que él mismo creó, luego lo que puede emitir o cambiar credenciales de otros, y después el resto por exposición.