¿Está pensando en un diseño de base de datos para el registro de auditoría? Recuerda lo que les pasó a Hansel y Gretel:pensaron que dejar un simple rastro de migas de pan era una buena forma de seguir sus pasos.
Cuando diseñamos un modelo de datos, estamos capacitados para aplicar la filosofía de que ahora es todo lo que existe . Por ejemplo, si diseñamos un esquema para almacenar precios de un catálogo de productos, podemos pensar que la base de datos solo necesita decirnos el precio de cada producto en el momento presente. Pero si quisiéramos saber si se modificaron los precios y, de ser así, cuándo y cómo se produjeron esas modificaciones, estaríamos en aprietos. Por supuesto, podríamos diseñar la base de datos específicamente para mantener un registro cronológico de los cambios, comúnmente conocido como seguimiento de auditoría o registro de auditoría.
El registro de auditoría permite que una base de datos tenga una "memoria" de eventos pasados. Continuando con el ejemplo de la lista de precios, un registro de auditoría adecuado permitirá que la base de datos nos diga exactamente cuándo se actualizó un precio, cuál era el precio antes de que se actualizara, quién lo actualizó y desde dónde.
Soluciones de registro de auditoría de base de datos
Sería genial si la base de datos pudiera mantener una instantánea de su estado para cada cambio que ocurra en sus datos. De esta forma, podría volver a cualquier punto en el tiempo y ver cómo estaban los datos en ese momento preciso como si estuviera rebobinando una película. Pero esa forma de generar registros de auditoría es obviamente imposible; el volumen de información resultante y el tiempo que llevaría generar los registros sería demasiado alto.
Las estrategias de registro de auditoría se basan en la generación de registros de auditoría solo para los datos que se pueden eliminar o modificar. Cualquier alteración en ellos debe ser auditada para revertir los cambios, consultar los datos en las tablas de historial o rastrear actividades sospechosas.
Existen varias técnicas populares de registro de auditoría, pero ninguna de ellas sirve para todos los propósitos. Los más efectivos suelen ser costosos, consumen muchos recursos o degradan el rendimiento. Otros son más baratos en términos de recursos pero están incompletos, son difíciles de mantener o requieren un sacrificio en la calidad del diseño. La estrategia que elija dependerá de los requisitos de la aplicación y los límites de rendimiento, los recursos y los principios de diseño que debe respetar.
Soluciones de registro listas para usar
Estas soluciones de registro de auditoría funcionan interceptando todos los comandos enviados a la base de datos y generando un registro de cambios en un repositorio separado. Dichos programas ofrecen múltiples opciones de configuración e informes para rastrear las acciones del usuario. Pueden registrar todas las acciones y consultas enviadas a una base de datos, incluso cuando provienen de usuarios con los privilegios más altos. Estas herramientas están optimizadas para minimizar el impacto en el rendimiento, pero esto a menudo tiene un costo monetario.
El precio de las soluciones de seguimiento de auditoría dedicadas puede estar justificado si está manejando información altamente confidencial (como registros médicos) donde cualquier alteración de los datos debe ser perfectamente monitoreada y auditable y el seguimiento de auditoría debe ser inalterable. Pero cuando los requisitos de registro de auditoría no son tan estrictos, el costo de una solución de registro dedicada puede ser excesivo.
Las herramientas de monitoreo nativas que ofrecen los sistemas de bases de datos relacionales (RDBMS) también se pueden usar para generar registros de auditoría. Las opciones de personalización permiten filtrar qué eventos se registran, para no generar información innecesaria o sobrecargar el motor de la base de datos con operaciones de registro que luego no se utilizarán. Los logs así generados permiten un seguimiento detallado de las operaciones ejecutadas sobre las mesas. Sin embargo, no son útiles para consultar tablas de historial, ya que solo registran eventos.
La opción más económica para mantener un registro de auditoría es diseñar específicamente su base de datos para el registro de auditoría. Esta técnica se basa en tablas de registro que se completan con activadores o mecanismos específicos de la aplicación que actualiza la base de datos. No existe un enfoque universalmente aceptado para el diseño de la base de datos de registro de auditoría, pero existen varias estrategias de uso común, cada una de las cuales tiene sus pros y sus contras.
Técnicas de diseño de registro de auditoría de base de datos
Versión de filas para el registro de auditoría en su lugar
Una forma de mantener un seguimiento de auditoría para una tabla es agregar un campo que indique el número de versión de cada registro. Las inserciones en la tabla se guardan con un número de versión inicial. Cualquier modificación o eliminación en realidad se convierte en operaciones de inserción, donde se generan nuevos registros con los datos actualizados y el número de versión se incrementa en uno. Puede ver un ejemplo de este diseño de registro de auditoría en el lugar a continuación:
Nota:Los diseños de tablas con versiones de filas incrustadas no se pueden vincular mediante relaciones de clave externa.
Además del número de versión, se deben agregar algunos campos adicionales a la tabla para determinar el origen y la causa de cada cambio realizado en un registro:
- La fecha/hora en que se registró el cambio.
- El usuario y la aplicación.
- La acción realizada (insertar, actualizar, eliminar), etc. Para que la pista de auditoría sea efectiva, la tabla solo debe admitir inserciones (no se deben permitir actualizaciones ni eliminaciones). La tabla también requiere necesariamente una clave primaria sustituta, ya que cualquier otra combinación de campos estará sujeta a repetición.
Para acceder a los datos de la tabla actualizada a través de consultas, debe crear una vista que devuelva solo la última versión de cada registro. Luego, debe reemplazar el nombre de la tabla con el nombre de la vista en todas las consultas, excepto en aquellas destinadas específicamente a ver la cronología de los registros.
La ventaja de esta opción de control de versiones es que no requiere el uso de tablas adicionales para generar la pista de auditoría. Además, solo se agregan unos pocos campos a las tablas auditadas. Pero tiene una gran desventaja:lo obligará a cometer algunos de los errores de diseño de bases de datos más comunes. Estos incluyen no usar integridad referencial o claves primarias naturales cuando es necesario hacerlo, lo que hace imposible aplicar los principios básicos del diseño de diagramas entidad-relación. Puede visitar estos recursos útiles sobre errores de diseño de bases de datos, para que se le advierta sobre qué otras prácticas debe evitar.
Mesas de sombra
Otra opción de seguimiento de auditoría es generar una tabla sombra para cada tabla que necesita ser auditada. Las tablas sombra contienen los mismos campos que las tablas que auditan, además de los campos de auditoría específicos (los mismos que se mencionan para la técnica de control de versiones de filas).
Las tablas ocultas replican los mismos campos que las tablas que auditan, además de los campos específicos para fines de auditoría.
Para generar pistas de auditoría en tablas sombra, la opción más segura es crear disparadores de inserción, actualización y eliminación, que para cada registro afectado en la tabla original generen un registro en la tabla de auditoría. Los activadores deben tener acceso a toda la información de auditoría que necesita registrar en la tabla paralela. Tendrá que usar la funcionalidad específica del motor de la base de datos para obtener datos como la fecha y hora actual, el usuario registrado, el nombre de la aplicación y la ubicación (dirección de red o nombre de la computadora) donde se originó la operación.
Si el uso de disparadores no es una opción, la lógica para generar los registros de auditoría debe ser parte de la pila de la aplicación, en una capa idealmente ubicada justo antes de la capa de persistencia de datos, para que pueda interceptar todas las operaciones dirigidas a la base de datos.
Este tipo de tabla de registro solo debe permitir la inserción de registros; si permiten modificar o borrar, la pista de auditoría ya no cumpliría su función. Las tablas también deben usar claves primarias sustitutas, ya que las dependencias y relaciones de las tablas originales no se les pueden aplicar.
Si la tabla para la que ha creado una pista de auditoría tiene tablas de las que depende, estas también deberían tener tablas paralelas correspondientes. Esto es para que la pista de auditoría no quede huérfana si se realizan cambios en las otras tablas.
Las tablas de sombra son convenientes por su simplicidad y porque no afectan la integridad del modelo de datos; las pistas de auditoría permanecen en tablas separadas y son fáciles de consultar. El inconveniente es que el esquema no es flexible:cualquier cambio en la estructura de la tabla principal debe reflejarse en la tabla sombra correspondiente, lo que dificulta el mantenimiento del modelo. Además, si es necesario aplicar el registro de auditoría a una gran cantidad de tablas, la cantidad de tablas paralelas también será alta, lo que dificultará aún más el mantenimiento del esquema.
Tablas genéricas para registro de auditoría
Una tercera opción es crear tablas genéricas para registros de auditoría. Tales tablas permiten el registro de cualquier otra tabla en el esquema. Solo se requieren dos tablas para esta técnica:
Una tabla de encabezado que registra:
- La fecha y hora del cambio.
- El nombre de la tabla.
- La clave de la fila afectada.
- Los datos del usuario.
- El tipo de operación realizada.
Una tabla de detalles que registra:
- Los nombres de cada campo afectado.
- Los valores de campo antes de la modificación.
- Los valores de campo después de la modificación. (Puede omitir esto si es necesario, ya que puede obtenerse consultando el siguiente registro en la pista de auditoría o el registro correspondiente en la tabla auditada).
El uso de tablas de registro de auditoría genéricas limita los tipos de datos que se pueden auditar.
La ventaja de esta estrategia de registro de auditoría es que no requiere ninguna otra tabla además de las dos mencionadas anteriormente. Además, en él se almacenan registros únicamente de los campos que se ven afectados por una operación. Esto significa que no es necesario replicar una fila completa de una tabla cuando solo se modifica un campo. Además, esta técnica le permite mantener un registro de tantas tablas como desee, sin saturar el esquema con una gran cantidad de tablas adicionales.
La desventaja es que los campos que almacenan los valores deben ser de un solo tipo y lo suficientemente anchos para almacenar incluso el mayor de los campos de las tablas para las que desea generar un registro de auditoría. Lo más común es utilizar campos de tipo VARCHAR que aceptan una gran cantidad de caracteres.
Si, por ejemplo, necesita generar un registro de auditoría para una tabla que tiene un campo VARCHAR de 8000 caracteres, el campo que almacena los valores en la tabla de auditoría también debe tener 8000 caracteres. Esto es cierto incluso si solo almacena un número entero en ese campo. Por otro lado, si su tabla tiene campos de tipos de datos complejos, como imágenes, datos binarios, BLOB, etc., deberá serializar su contenido para que pueda almacenarse en los campos VARCHAR de las tablas de registro.
Elija sabiamente el diseño del registro de auditoría de su base de datos
Hemos visto varias alternativas para generar registros de auditoría, pero ninguna de ellas es realmente óptima. Debe adoptar una estrategia de registro que no afecte sustancialmente el rendimiento de su base de datos, que no la haga crecer excesivamente y que pueda cumplir con sus requisitos de trazabilidad. Si solo desea almacenar registros para algunas tablas, las tablas sombra pueden ser la opción más conveniente. Si desea flexibilidad para registrar cualquier tabla, las tablas de registro genéricas pueden ser las mejores.
¿Ha descubierto otra forma de mantener un registro de auditoría para sus bases de datos? Compártalo en la sección de comentarios a continuación. ¡Sus compañeros diseñadores de bases de datos estarán muy agradecidos!
