Quién cambió qué: una pista de auditoría para el host
En un host compartido, la pregunta más dura tras un incidente no es qué se rompió; es quién cambió qué antes de romperse. Atlas escribe una pista de auditoría de las operaciones críticas: actor, acción, hora y resultado, guardada en el host en dos lugares.
Por qué quién hizo qué suele quedar sin respuesta
Las herramientas básicas dispersan la evidencia. El registro de tareas de PVE conoce algunas operaciones, el historial del shell otras, y las ediciones de configuración muchas veces no conocen nada. Reconstruir una tarde significa coser marcas de tiempo entre los tres.
El acceso root compartido lo empeora. Cuando varias personas pueden actuar como root, las acciones dejan de tener autor; los archivos de historial puede editarlos el mismo poder que hizo el cambio.
Y la mayoría de las auditorías llegan en el peor momento: tras un incidente, bajo presión, con la persona que sabe la respuesta siendo quizá la misma que lo causó.
Reconstruir un incidente a mano
Sin pista, la investigación habitual va así:
Leer el registro de tareas de PVE alrededor de la ventana del incidente y anotar lo que aparezca.
Rebuscar en los historiales de shell del host, esperando que nadie usara una cuenta compartida.
Recorrer journalctl en la misma ventana e intentar casar marcas de tiempo.
Comparar las configuraciones actuales con la última copia para hallar ediciones silenciosas.
Preguntar en el chat del equipo quién tocó el host ese día.
Escribir una nota de incidente construida sobre probablemente, y seguir adelante.
Qué deja escrito Atlas
Las operaciones críticas dejan pista mientras ocurren, no un misterio después.
Acciones críticas, registradas
Las operaciones que cambian o ponen en riesgo el sistema, trabajos destructivos de almacenamiento y red, terminaciones de procesos, acciones sensibles a privilegios, se escriben en la pista mientras corren.
Actor, acción, hora, resultado
Cada entrada responde de una vez las cuatro preguntas del incidente: quién lo disparó, qué corrió exactamente, cuándo y si tuvo éxito.
Dos copias, resistentes a manipulación
Las entradas van al journal del sistema, que los usuarios sin root no pueden reescribir, y a un archivo separado. Borrar huellas exige vencer a los dos.
Roles de Proxmox, respetados
Atlas no inventa su propio mundo de permisos. Quién puede hacer qué viene de los usuarios y roles de Proxmox, así la pista corresponde a identidades reales.
Sin secretos en el registro
Contraseñas y tokens jamás se escriben. La pista registra que una acción ocurrió, no las credenciales que la llevaban.
Los hallazgos llegan solos
El centinela Watch avisa por correo de los hallazgos críticos cuando ocurren; la pista se lee antes del incidente, no solo después.
Preguntas frecuentes
- ¿Qué se registra exactamente?
- Operaciones críticas y sensibles a privilegios: cambios destructivos de almacenamiento y red, señales a procesos, acciones a nivel de servicios y similares. Las lecturas rutinarias no hacen ruido en la pista.
- ¿Puede un administrador borrar sus huellas?
- La pista se guarda dos veces: en el journal del sistema, que no se reescribe sin manipulación a nivel root, y en un archivo separado. Editar la historia en silencio deja de ser trivial.
- ¿Se guardan contraseñas o cuerpos de peticiones?
- No. Los secretos jamás se escriben en la pista; las entradas llevan actor, acción, hora y resultado.
- ¿Dónde vive el registro?
- En el propio host, en el journal del sistema más un archivo separado. Nada se envía a un servicio externo.
- ¿Usa las cuentas de Proxmox?
- Sí. Atlas refleja usuarios, grupos y roles de Proxmox en lugar de inventar los suyos; las entradas de auditoría corresponden a las identidades que ya gestiona.
- ¿Registrar ralentiza el host?
- No. Solo se registran las operaciones críticas, no cada clic; la pista ocupa unas pocas líneas por acción arriesgada.
Entradas relacionadas
- Le quité el acceso y sigue dentro: una sesión no es lo mismo que un permiso Quitaste el permiso, incluso desactivaste la cuenta, y esa persona sigue pudiendo hacer cosas. No hay nada roto: quitar el acceso y terminar una sesión son dos acciones distintas.
- Dejar de trabajar como root: la decisión que nadie te obliga a tomar y la que más rinde Trabajar como root no estalla un día. Rompe en silencio dos cosas: a quién señala el registro y dónde se detiene un clic equivocado. La solución no es desactivar root, sino quitarle el trabajo diario.
- El registro de auditoría: la respuesta a "quién lo hizo", no a "qué pasó" La vigilancia dice qué pasó, el registro de auditoría dice quién lo hizo. Su valor aparece los días que esperas que no lleguen, y si ese día no lo tienes, nunca existió.