En varios de los proyectos en los que hemos trabajado, los clientes nos han pedido que registremos más acciones de los usuarios en la base de datos. Quieren saber todas las acciones que realizan los usuarios en la aplicación, pero capturar y registrar todas las interacciones humanas puede ser un desafío. Tuvimos que registrar todas las modificaciones de datos realizadas a través del sistema. Este artículo describe algunas de las trampas que encontramos y los enfoques que usamos para superarlas.
Introducción
Trabajo como arquitecto de soluciones en servicios financieros. Es importante llevar un registro del último usuario que modificó una fila. En los casos más sencillos basta con registrar el sello de tiempo de la modificación para tener trazabilidad de cambios Aquí hay un ejemplo simple de una tabla que almacena acuerdos de clientes que incluyen last_changed columnas para usuario y marca de tiempo.
Sin embargo, en algunos casos, esto no es suficiente. A menudo debemos tener una trazabilidad completa (incluidas "imágenes" antes y después de los datos). En algunos casos, también necesitamos auditabilidad (quién, qué, cuándo).
Desafortunadamente, muchos de nuestros sistemas no fueron diseñados para brindar trazabilidad y auditabilidad. Necesitábamos ingeniería inversa estos requisitos de operaciones comerciales en los sistemas.
Trazabilidad
En algunos casos, hemos encontrado que la trazabilidad es fácil de lograr. Mientras que, en otros, nos ha resultado difícil o incluso imposible. Dependiendo de su sistema, la solución puede ser simple. Su acceso a los datos podría permitir una simple inyección de registro de imágenes de antes y después de los datos. Este registro puede implementarse de manera que los resultados se almacenen en una tabla de base de datos en lugar de en un archivo de registro. En algunos productos, logramos esto de una manera directa a través de la persistencia capa. Por ejemplo, esto fue posible con Hibernate .
Aquí puede ver una entrada para cada elemento de la pista de auditoría, además habrá valores de antes y después para cada columna que haya cambiado. Además, en el caso de que se elimine una fila, guardamos esa información con el functioncode indicando eliminar. Hemos optado por utilizar varchar(1) para almacenar el código de la función (C, R, D) especificando el tipo de modificación, en lugar del nombre o descripción de la “operación” (Crear, Actualizar, Eliminar) que se realizó . La instance_key contiene la clave principal del elemento que se agregó, modificó o eliminó, para la trazabilidad.
Sin embargo, puede ser que su capa de acceso a datos no le proporcione la funcionalidad necesaria. Para otros productos, nuestra capa de acceso a datos no lo hizo. En esos casos, la trazabilidad necesitaba cambios complejos. Por ejemplo, es posible que necesite la recuperación y registro de cualquier dato antes de la modificación. Como escribí, esto es posible pero puede ser complejo de implementar. Los desarrolladores tendrían que crear una recuperación de cada fila antes de modificar una fila. No sería posible ejecutar una actualización sin una selección.
¿Cómo se puede evitar la trazabilidad? Una posible solución es asegurarse de conocer la situación inicial de todos los datos, es decir, la situación inicial creada por cualquier dato estático cargado en el sistema. Luego, tendría que registrar todas las modificaciones. En otras palabras, ¿cuáles son todas las imágenes "después" de los datos? De esta forma, sería posible “rodar hacia adelante ” de los datos estáticos cargados. Se aplican todas las actualizaciones realizadas hasta ese momento. Esta es una situación menos que ideal, pero puede ser aceptable.
Se puede usar una tabla simple si la única información disponible es el nuevo valor y no el valor anterior.
Auditabilidad
En algunas situaciones, debemos asegurarnos de que todas las acciones realizadas en el sistema sean totalmente auditables. . ¿Quién inició sesión a qué hora? ¿Qué acciones realizó cada usuario en el sistema, incluida solo la visualización de datos? Esto es importante porque puede ser significativo si un usuario miró un pago.
Para lograr un trazado detallado puede ser difícil mirar solo el acceso a la base de datos. A menudo debemos mirar a un nivel superior y examinar las acciones o servicios realizados. En algunos casos, pudimos rastrear cada llamada de servicio para saber qué hizo un usuario en qué momento. Con un controlador de entrada/salida de servicio web, el registro de solicitudes de servicio fue bastante fácil.
Aquí hay un ejemplo de un registro de auditoría de usuario simple donde registramos la acción que realiza cada usuario. Discuto algunas cuestiones sobre este enfoque en la siguiente sección "Prueba".
A continuación se proporciona una breve descripción de la tabla:
El user_audit La tabla contiene entradas de auditoría de datos que tienen marca de tiempo. La clave principal consta de audit_entry_time sello más el user_id y bank_id más el nombre de la action realizado. Los campos tienen significados que corresponden a sus nombres. La tabla de auditoría almacena el result de la acción, más la class real que ejecutó la acción, sus parameters de entrada y cualquier errors .
Este es otro ejemplo de un registro de auditoría donde registramos las imágenes de antes y después de los datos que se modificaron en una tabla en particular (junto con la acción realizada, las credenciales del usuario y la marca de tiempo).
El audit_trail La tabla contiene entradas de auditoría de imágenes anteriores y posteriores de los datos. La clave principal consta de audit_gen_key esa es una clave generada por la aplicación. Los campos tienen significados que corresponden a sus nombres. El nombre de la tabla de la base de datos para la que se registra esta entrada de seguimiento de auditoría se almacena en modified_table , además, la imagen de "antes" se almacena en prev_value y la imagen "después" en new_value . El module que está realizando la modificación y el funct_type de modificación (Crear, Actualizar, Eliminar) también se almacenan. Finalmente, la información de auditoría del user_id (y bank_id correspondiente ) más la marca de tiempo del cambio (date_last_changed ).
Entonces llegamos a un desafío. Cuando se registra tanto la información de trazabilidad como la información de auditabilidad, el registro se produce dos veces. Desde el punto de vista de una auditoría, esto es molesto. Los auditores deben asegurarse de que la información sea la misma entre estos dos registros.
Prueba
Otro desafío fue garantizar el registro de todas las acciones de los usuarios . Esto suele ser requerido por los auditores en la industria de servicios financieros.
Ahora tenemos un verdadero desafío. Nuestra solución fue garantizar la trazabilidad central y el registro de auditabilidad. Las "interfaces" centrales aseguran que todas las implementaciones de esa interfaz incluyan registro. Fue sencillo asegurarse de que todas las clases apropiadas implementaran la interfaz.
Por supuesto, esto no garantiza el 100% de prueba de registro. Es una fuerte verificación de seguridad que todas las clases apropiadas se registraron según lo requerido.
Conclusión
La ingeniería inversa de la nueva funcionalidad comercial en un sistema existente siempre es un desafío. Este puede ser aún más el caso cuando la funcionalidad implementada va al núcleo.
