Bitácora de cambios: quién cambió qué y cómo investigar una diferencia
Una fecha y un usuario no explican una diferencia. Necesitas encontrar el cambio, su origen y el resultado que dejó en el negocio.
Hoja de prueba: Bitácora de cambios: investigar una diferencia
Una fecha y un usuario no explican una diferencia. Necesitas encontrar el cambio, su origen y el resultado que dejó en el negocio. Registra datos, resultado esperado, evidencia, responsable y resultado observado.
Empieza por una diferencia que necesites explicar
En una fábrica, compras puede preguntar por qué el costo del pedido cambió después de su autorización. En una empresa de servicios, operación necesita saber quién cerró una orden sin su evidencia. Define esas preguntas antes de pedir «guardar todos los eventos». Un historial inmenso que no permite encontrar el registro o su secuencia tampoco ayuda a resolver el caso.
Dataverse documenta que la auditoría depende de su activación y que algunos registros pueden aparecer con retraso. OWASP recomienda proteger los registros y excluir información sensible innecesaria. La prueba debe comprobar cobertura y disponibilidad reales: una pantalla llamada bitácora no demuestra que cada campo relevante se esté registrando.
Ejemplo ficticio: precio de compra en OC-404
El pedido OC-404 contiene 300 unidades a 12 MXN. Una persona propone cambiar el precio a 14 y finanzas lo autoriza. El importe pasa de 3,600 a 4,200 MXN, antes de impuestos u otros conceptos. La diferencia es 600 MXN. Este ejemplo sintético sirve para reconstruir un cambio; no representa compras ni resultados de un cliente.
El historial esperado muestra el pedido y su versión, precio 12→14, cantidad 300, solicitante, aprobador y motivo. Si un conector ejecuta el cambio, distingue su identidad técnica de la persona o regla que originó la solicitud. «API» como único autor puede ser insuficiente para explicar una decisión comercial; acuerda qué referencia enlazará el cambio con su origen.
| Dato | Para qué sirve | Cuidado necesario |
|---|---|---|
| Registro y versión | Ubicar OC-404 y el estado revisado | No depender solo de un nombre editable |
| Antes y después | Explicar precio 12→14 e importe | Registrar solo campos pertinentes |
| Actor y origen | Distinguir usuario, aplicación y aprobación | No registrar contraseñas ni tokens |
| Hora y referencia relacionada | Ordenar cambio, autorización y reintento | Anotar zona horaria y relojes relevantes |
Comprueba el historial, no solo el cambio
Ejecuta el ensayo con usuarios autorizados y datos ficticios. Busca el registro desde la operación y desde la bitácora. Verifica que un usuario sin permiso no pueda cambiar el historial o consultar información que no necesita. Si los eventos llegan después, mide ese retraso y define cómo se mostrará un resultado todavía pendiente.
| Caso | Resultado esperado | Evidencia |
|---|---|---|
| Precio autorizado 12→14 | Antes, después y aprobación localizables | OC-404 y evento relacionado |
| Intento de cambio sin permiso | Precio sin cambio; intento identificable según alcance acordado | Solicitud rechazada y estado final |
| Cambio hecho por conector | Identidad técnica y referencia de origen distinguibles | Evento y solicitud original |
| Reintento tras perder respuesta | No parece otra decisión comercial independiente | Referencia común y secuencia |
| Usuario intenta editar historial | Edición rechazada con control verificable | Permiso y resultado |
| Campo relevante no tiene auditoría activa | Hueco visible; prueba no aprobada | Configuración y ausencia comprobada |
Decide qué conservar y qué no incluir
No guardes secretos, datos completos de tarjetas ni documentos personales en un registro solo por comodidad. El motivo de un cambio puede contener información sensible si se admite texto libre; revisa permisos y límites de ese campo. Una referencia al documento autorizado puede ser mejor que copiarlo completo en cada evento.
La conservación depende del negocio, almacenamiento y obligaciones aplicables. Define quién consulta, quién administra retención y quién detecta interrupciones del registro. Una bitácora técnica no se convierte automáticamente en evidencia legal suficiente, ni garantiza descubrir toda modificación. Si necesitas una revisión especializada, acota el propósito y el sistema que realmente registra cada acción.
Usa una diferencia para aceptar la herramienta
Pide a una persona que no presenció el ensayo reconstruir qué ocurrió en OC-404. Si necesita interrogar al equipo porque faltan origen o versión, la bitácora todavía no cumple esa tarea. Relaciona la prueba con roles y permisos, las reglas de sincronización y la conexión de tu ERP.
La hoja contiene diez casos para anotar evidencia y responsables. En una consulta gratuita de ciberseguridad, trae una diferencia anonimizada, los campos que necesitas explicar y las opciones de historial de tu sistema. Podemos revisar qué ya puede verificarse y qué parte requiere configuración o una evaluación adicional.
Preguntas frecuentes
Depende de la pregunta que necesites responder y del alcance disponible. Consultas, exportaciones y cambios son acciones distintas. Acuerda cuáles son relevantes y comprueba su cobertura; registrar demasiado también puede añadir datos sensibles y dificultar la investigación.
El historial y la autorización cumplen tareas distintas. Los permisos pueden impedir una acción; la bitácora ayuda a reconstruirla. Necesitas probar ambos y proteger el historial. No lo presentes como una garantía contra cualquier modificación.
Conserva la identidad de la aplicación y una referencia que permita encontrar la solicitud, regla o persona de origen cuando exista. No atribuyas automáticamente la decisión a quien instaló el conector. Define cómo se reconstruye esa cadena.
Primero comprueba que el campo estaba cubierto, la prueba se ejecutó y no hay retraso pendiente. La ausencia puede indicar un hueco de configuración o retención, no que nunca hubo un cambio. Registra el límite en lugar de inventar una conclusión.
Fuentes
- Manage Dataverse auditingMicrosoft
- Logging Cheat SheetOWASP
Última actualización: