Un cliente escribe para decir que alguien modificó el precio de sus productos y que él no fue. La pregunta es sencilla: quién lo hizo y cuándo. La respuesta, en la mayoría de los proyectos pequeños, es que no hay forma de saberlo.
No porque falten registros. Suele haber gigabytes de ellos, llenos de líneas sobre peticiones atendidas y consultas ejecutadas. Lo que falta es el registro de que alguien cambió un precio, con su nombre y su hora, y eso no aparece por defecto en ningún sistema.
Este artículo trata de esa diferencia, que es la más útil de todo el tema y la que casi nunca se explica.
Dos cosas distintas que se llaman igual
La palabra registro se usa para dos propósitos que tienen requisitos opuestos, y mezclarlos es la razón de que muchos sistemas tengan mucho volumen y poca respuesta.
Los registros técnicos existen para diagnosticar fallos. Interesan cuando algo se rompe, sirven durante unos días y después dejan de tener valor. Su público es quien está depurando.
Los registros de auditoría existen para reconstruir quién hizo qué. Interesan meses después, ante una disputa, una sospecha o una obligación legal. Su público es alguien que investiga un hecho concreto.
De ahí salen políticas distintas: los primeros se guardan poco tiempo y en gran volumen; los segundos, poco volumen y mucho tiempo, y nunca deberían poder modificarse. Tratarlos con la misma regla produce o una factura enorme o la ausencia del dato que hará falta.
Qué debe registrarse siempre
La lista corta de eventos que conviene tener en cualquier proyecto con usuarios es más breve de lo que parece, y cada punto responde a una pregunta que se acaba haciendo tarde o temprano.
- Inicios de sesión, con éxito y fallidos. Los fallidos en serie son la señal más temprana de que alguien está probando credenciales.
- Cambios de credenciales y de correo. Es el movimiento clásico de quien acaba de tomar una cuenta ajena: asegurar el acceso antes de actuar.
- Cambios de permisos. Quién ascendió a quién y cuándo. Sin esto, un privilegio concedido indebidamente es indistinguible de uno legítimo.
- Operaciones sobre datos sensibles. Precios, facturación, datos personales, cualquier cosa cuya alteración tenga consecuencias.
- Borrados. Es el evento que más se echa de menos, porque el propio dato ya no está para contar su historia.
- Exportaciones masivas. Descargarse la base de clientes es una operación legítima y también la forma habitual en que la información sale de una empresa.
Todos comparten una característica: no son fallos. Son operaciones normales que el sistema permite, y por eso ningún registro de errores las captura.
Qué debe contener cada entrada
Un registro de auditoría sirve o no sirve según si permite responder una pregunta completa sin tener que buscar en otro sitio.
Las piezas son cinco: quién, qué hizo, sobre qué, cuándo y desde dónde. Con eso basta para reconstruir un hecho; sin alguna de ellas, la investigación se detiene.
Conviene además guardar el valor anterior y el nuevo cuando se trata de una modificación. Saber que alguien cambió un precio es útil; saber que lo cambió de cien a uno es lo que resuelve la conversación con el cliente.
Precio actualizado correctamente no permite responder nada.
El usuario 412 cambió el precio del producto 88 de 100 a 1, el 14 de marzo a las 09:12, desde esta dirección responde la pregunta entera y cierra el asunto.
La hora merece una nota: conviene guardarla siempre en horario universal y con la zona explícita. Cruzar registros de varios sistemas con husos distintos es una de esas tareas que consumen una tarde entera por un detalle que costaba nada.
Qué no debe registrarse nunca
Hay información que no puede acabar en un registro, y el motivo es directo: los registros se copian, se envían a servicios de terceros y los consulta gente que no tendría acceso a los datos originales.
Nunca deben aparecer contraseñas, ni siquiera en un intento fallido. Tampoco tokens de sesión ni claves de API, porque quien lea el registro obtiene acceso inmediato. Ni números completos de tarjetas. Ni el contenido de documentos de identidad o datos de salud.
El caso que más sorprende es el de los cuerpos completos de peticiones. Guardar la petición entera para depurar parece prudente y significa, en la práctica, almacenar cada contraseña que se envió a la pantalla de registro.
La forma de evitarlo no es la disciplina individual sino una lista de campos que se enmascaran automáticamente antes de escribir. Si el filtro está en el sistema, deja de depender de que alguien se acuerde.
Registrar datos personales tiene reglas
Si el proyecto tiene usuarios en Europa, o simplemente aspira a tratar bien sus datos, los registros entran dentro del alcance de la normativa de protección de datos, y eso tiene consecuencias concretas.
La primera es que una dirección de red asociada a una persona es un dato personal, así que un registro de accesos no es un fichero técnico neutro: es un fichero con datos personales, con su base legal y su plazo de conservación.
La segunda es que conservar indefinidamente no es una opción neutral. Debe haber un plazo justificado, y pasado ese plazo los registros deben eliminarse.
Y la tercera, la que más fricción genera, es que el derecho al borrado convive mal con registros que deben ser inalterables. La salida habitual es guardar en el registro de auditoría un identificador interno en lugar de datos identificativos, de forma que la persona se pueda desvincular sin destruir la trazabilidad de los hechos.
Los registros solo sirven si alguien los mira
Un archivo que se escribe y nunca se lee da una sensación de control sin aportar ninguno. Y mirarlos todos los días no es realista en un equipo pequeño.
Lo que sí funciona es convertir unos pocos casos en avisos automáticos. No muchos: tres o cuatro que indiquen algo que realmente exija atención.
Los que más rinden son una serie de inicios fallidos sobre la misma cuenta, un cambio de permisos sobre una cuenta con privilegios, una exportación masiva de datos y un acceso desde una ubicación inesperada en un equipo que siempre trabaja desde el mismo sitio.
El resto se consulta solo cuando hay un motivo. Su valor no está en la vigilancia continua, sino en que el dato exista el día que alguien pregunte.
Escribirlos de forma que se puedan buscar
Hay una decisión de formato que parece menor y determina si los registros sirven de algo el día que hay que usarlos: si son frases sueltas o datos estructurados.
Una línea escrita como texto libre se lee bien cuando son diez. Cuando son cien mil y hay que encontrar todas las operaciones de un usuario concreto en un rango de fechas, el texto libre obliga a inventar búsquedas frágiles que fallan en cuanto alguien cambia la redacción del mensaje.
La alternativa es escribir cada entrada como un objeto con campos siempre iguales. Un campo para el actor, otro para la acción, otro para el recurso, otro para la marca de tiempo. Cuesta lo mismo escribirlo así y convierte una búsqueda desesperada en una consulta de una línea.
Conviene además que los nombres de los campos sean idénticos en todo el sistema. Si una parte escribe el identificador de usuario con un nombre y otra con otro, cruzar ambos exige recordar la diferencia justo cuando nadie tiene tiempo para eso.
Y hay un campo que rinde más de lo que cuesta: un identificador único por operación, que viaje con ella y aparezca en todas las entradas que genera. Es lo único que permite seguir una acción completa cuando pasó por varias piezas del sistema y falló a mitad de camino.
Cuando el incidente ya ocurrió
Los registros se justifican el día que hay que reconstruir algo, y ahí el orden de los pasos evita destruir justo lo que se necesita.
- Primero copia, después investiga. Guarda una copia de los registros del periodo relevante antes de tocar nada. Si la política de retención los borra a mitad de la investigación, no hay vuelta atrás.
- Fija la ventana de tiempo antes de leer. Empezar a leer sin acotar lleva a perderse. Un rango concreto, aunque sea amplio, ordena la búsqueda.
- Empieza por las cuentas, no por los datos. Casi siempre la pregunta útil es qué hizo esta cuenta, no qué le pasó a este registro.
- Anota lo que vas encontrando y a qué hora. Una investigación sin notas se repite tres veces, y las conclusiones cambian según el cansancio.
Si el resultado es que faltaba el dato que habría resuelto la pregunta, esa es la mejor información que deja el incidente: apunta exactamente qué evento hay que empezar a registrar, y esa lista escrita en caliente vale más que cualquier plan general.
Que no se puedan borrar es parte del diseño
Hay una propiedad que distingue un registro de auditoría real de una simple tabla de eventos: quien opera el sistema no debería poder alterarlo sin dejar rastro.
La razón es evidente cuando se piensa en para qué existe. Si la persona investigada puede editar el registro que la implica, el registro no prueba nada. Y en un proyecto pequeño, esa persona suele ser la que tiene todos los accesos.
No hace falta una solución sofisticada. Enviar los eventos de auditoría a un destino distinto, con credenciales que solo permiten escribir y no borrar, cubre la mayor parte del riesgo. Varios servicios de almacenamiento ofrecen además un modo donde lo escrito no se puede modificar durante un plazo.
La regla práctica: la aplicación escribe, nadie edita, y el borrado ocurre solo por la política de retención, automáticamente y al cumplirse el plazo.
Qué se le escapa a una IA con esto
Pedir que se añadan registros a una aplicación produce, con bastante fiabilidad, registros técnicos: entradas de depuración, errores capturados, tiempos de respuesta. Todo correcto y ninguno responde a quién hizo qué.
La razón es que la petición se interpreta como diagnóstico, que es el uso más común de la palabra. Nadie mencionó que hiciera falta reconstruir hechos meses después.
La frase que cambia la respuesta es pedir registro de auditoría y enumerar las operaciones que importan en ese proyecto concreto. Con eso aparece lo que hace falta: quién, qué, sobre qué, cuándo, valor anterior y nuevo.
Conviene añadir siempre dos condiciones explícitas, porque no se deducen solas: que los campos sensibles se enmascaren antes de escribir, y que exista un plazo de retención en lugar de guardar para siempre. Sin la primera, el registro se convierte en una filtración esperando ocurrir; sin la segunda, en una factura que crece sin que nadie la mire.