Me llamo Noel, estoy cursando la maestría de Software Libre en la ciudad de Sucre - Bolivia.
Mi trabajo se basa en el "Diseño del modelo de bases de datos relacionales *auditables*". Título aún no bien definido. He podido ver que las implementaciones con controles de auditoría y seguridad en las bases de datos relacionales no se encuentran debidamente formalizados y estandarizados, ocasionando complejidad y deficiencia en la ejecución de procesos de auditoría. Sería deseable contar con un modelo uniforme (estándar) de bases de datos en cuanto a su implementación de controles de auditoría. Por ello, pretendo diseñar una propuesta (convenciones, buenas prácticas, modelo; aún no defino el término) de estándar abierto de diseño del modelo de base de datos relacionales con controles de auditoría y seguridad que permita realizar el control de registros de modificaciones, adiciones y eliminaciones de datos en las bases de datos relacionales. En consecuencia, he estado viendo muchos artículos y alternativas actuales, tal es el caso de CianAudit y pgAudit de PostgreSQL. Específicamente pgAudit, la cual es una alternativa nueva muy poderosa pero personalmente al usarla creo que hay mucho que mejorar (al menos en la parte de DML), así como en las otras alternativas. Por ejemplo, en cuanto al DML, CianAudit y PgAudit tienen un comportamiento similar, ambos almacenan la información de auditoría en una sola tabla en un esquema nuevo dentro de la misma base de datos. En donde puedo notar: - Al momento de obtener un backup de toda la base de datos, va a ser exponencialmente grande en cuanto a su tamaño en disco, a pesar de que es posible obtener backups por esquema. - Al encontrase el esquema de auditoría dentro de la misma base de datos, el espacio en disco aumenta exponencialmente, ya que esa tabla será la más grande en tamaño en disco de todas las tablas. - Al almacenar un nuevo registro por cada campo de una tabla, si una tabla tiene 15 columnas, entonces se tendrían 15 inserciones en la tabla de auditoria. - Al almacenar en una sola tabla, una tupla por cada cambio en campo modficado de cualquier tabla, es más costoso el procesamiento interno en caso de reconstrucción de la información para rollback o ejecución de un delete from <table> sin condición. Para lo arriba expuesto, yo podría recomendar: - Al momento de generar la auditoría que sea en una nueva base de datos. Para mayor seguridad y menor tamaño de los backups total de la base de datos. - Que la base de datos de auditoría esté en otro disco, separado al de la base de datos en producción. Para mayor seguridad y ayudar a que el disco de producción no se llene más rápido. - Que se tenga al menos una partición exclusiva para auditoría. Para mayor seguridad y modularizar más los datos. - En la base de datos de auditoría, tener una tabla casi idéntica a la de producción, con todos los campos que tiene cada tabla (o los que se especifique), pero que tenga su propio identificador o clave primaria de auditoría y adicionarle en la tabla de auditoría campos adicionales de auditoría (acción sql, fecha, usuario, ip, y otros que ya se consideran). Ayuda a tener los datos mejor organizado y facilitaría la reconstrucción de información. - Que sólo el usuario postgres y otro específicos de auditoría tenga acceso a la base de datos de auditoría. y.... demás controles de roles y cifrado que puedan implementarse. Son algunas ideas que pueden considerarse en las auditorías de PostgreSQL (pgAudit), que inicialmente podría ser una configuración adicional. Espero sus opiniones y retro alimentación. :) Noel Vaca Moreno
