Sugerencias para las Auditorías pgAudit de PostgreSQL

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