Registro de auditoría en una app: cómo saber quién cambió un dato y por qué
Un registro de auditoría permite reconstruir una acción importante: quién la hizo, cuándo, sobre qué dato, desde qué contexto y con qué resultado. Sirve para investigar un importe inesperado, una dirección modificada, una aprobación revocada o una exportación sensible sin depender de la memoria del equipo.
Lo esencial, antes de empezar
- Un historial de negocio y un log técnico tienen propósitos, audiencias y retenciones diferentes.
- Registra eventos a partir de preguntas concretas, no cada pulsación.
- El propio registro necesita control de acceso, integridad, retención y alertas de fallo.
- La aceptación se demuestra reconstruyendo casos humanos, automáticos y fallidos de extremo a extremo.
Empieza por las preguntas que el negocio necesita responder
- ¿Quién cambió los datos de pago de un proveedor?
- ¿Cuál era el valor anterior y cuándo se aprobó?
- ¿Actuó una persona o una integración?
- ¿Quién exportó información sensible?
- ¿Por qué se reabrió un expediente cerrado?
- ¿Se intentó una acción que el sistema rechazó?
OWASP distingue los rastros de auditoría de negocio de los registros de seguridad y operación en su Logging Cheat Sheet. Un identificador de correlación puede conectarlos, pero no convierte errores de infraestructura en un historial comprensible para operaciones.
Da a cada evento contexto suficiente
| Campo | Ejemplo hipotético |
|---|---|
| Fecha y hora | 2026-10-24T10:18:42Z |
| Actor | usuario 842 o integración erp-sync |
| Acción | actualizar, aprobar, exportar, eliminar |
| Objeto | pedido 5812, campo direccion_entrega |
| Antes y después | valor resumido o protegido |
| Resultado | correcto, rechazado, parcial |
| Motivo | código o comentario obligatorio |
| Origen y correlación | panel, API o tarea; identificador de operación |
NIST resume el contenido de un registro en tipo, momento, lugar u origen, resultado e identidad. El actor debe ser una persona o servicio concreto. Si soporte actúa en nombre de otra persona, conserva identidad original, actor efectivo y motivo autorizado; una cuenta compartida llamada admin destruye la atribución.
Elige eventos por consecuencia y utilidad
- Altas, bajas y cambios de usuarios, roles y permisos.
- Datos maestros, información de pago y límites.
- Aprobaciones, rechazos, anulaciones y cambios de estado.
- Importaciones, exportaciones y acceso administrativo sensible.
- Configuración y acciones restringidas, incluidas las fallidas.
Microsoft Business Central permite seleccionar tablas y campos, y advierte de impacto en rendimiento y tamaño en su guía para auditar cambios. Un registro de solo lectura con filtros por usuario, acción y fecha facilita la consulta, pero no define por sí mismo qué conviene guardar. La matriz de finalidad, contenido, audiencia y retención evita registrar demasiado o demasiado poco.
No conviertas el historial en otra base de datos sensible
Contraseñas, tokens, identificadores de sesión, documentos completos y datos personales innecesarios no deben copiarse al log. A veces basta registrar que un campo cambió. En otros casos, como un límite de crédito, el valor anterior y posterior puede ser esencial. Decide según la pregunta que justificó el evento.
Protege y supervisa el propio registro
- Escritura desde el servidor, no desde datos libres del navegador.
- Lectura restringida por función y finalidad.
- Detección de alteración o almacenamiento inmutable donde el riesgo lo justifique.
- Tiempo sincronizado y zonas horarias interpretables.
- Copias y exportaciones controladas.
- Alerta cuando la escritura de auditoría deja de funcionar.
- Retención definida y borrado al finalizarla.
Consultar o exportar el historial también puede producir un evento. Define si una operación crítica debe detenerse cuando no puede registrarse o si puede continuar con una alerta; esa decisión depende del impacto y debe aparecer en requisitos.
Acepta la función reconstruyendo un caso completo
Ejecuta un escenario: una persona crea un pedido, otra cambia el importe, una integración añade la factura y una tercera anula. Comprueba orden, actor, resultado, motivo y correlación. Añade cambio masivo, reintento, zona horaria diferente, fallo a mitad, usuario desactivado y fallo del servicio de auditoría.
- 01
Pregunta
Define qué decisión o incidente se debe reconstruir.
- 02
Evento
Elige acción, objeto, actor y datos mínimos.
- 03
Acceso
Asigna quién puede ver y exportar.
- 04
Retención
Fija duración y borrado por finalidad.
- 05
Prueba
Documenta escenario y evidencia esperada.
NAS Solutions puede incorporar esta trazabilidad al diseño de una app a medida y conectarla con roles e integraciones. Inclúyela desde el MVP con criterios de aceptación: el objetivo es reconstruir decisiones importantes, no acumular archivos de log.
Diseña la consulta y la entrega para una investigación real
Guardar eventos no basta si encontrar una secuencia exige descargar millones de filas. La vista de investigación debe combinar intervalo temporal, tipo de objeto, identificador, actor, acción, resultado y correlación. Permite seguir una operación entre interfaz, API y tarea automática, mostrando horas en una zona comprensible sin perder la marca temporal original.
Una exportación necesita el mismo control que la consulta: finalidad, persona autorizada, alcance, fecha y registro de descarga. El archivo debe incluir diccionario de campos y criterios aplicados para que otra persona pueda interpretarlo. Evita que un filtro amplio exponga datos ajenos al incidente o que una hoja editable se presente como evidencia inalterada.
| Elemento | Qué debe permitir comprobar |
|---|---|
| Catálogo de eventos | Finalidad, campos, actor y resultado de cada tipo |
| Matriz de acceso | Quién consulta, exporta y administra |
| Política de retención | Duración, motivo y borrado verificable |
| Casos de aceptación | Reconstrucción humana, automática, masiva y fallida |
| Procedimiento de incidencia | Qué ocurre si falta un evento o falla la escritura |
Asigna un propietario funcional y otro técnico. El primero decide qué preguntas siguen siendo relevantes; el segundo supervisa capacidad, errores e integridad. Revisa ambos después de cambios de proceso, nuevas integraciones o incidentes: un catálogo estático se vuelve incompleto aunque la aplicación continúe generando registros.
Fuentes y referencias
Documentación oficial y referencias de mercado consultadas para verificar los puntos que cambian con el tiempo.
