Optimizando los registros de auditoría

K2BAudit permite auditar todos los cambios realizados sobre las tablas críticas de sistemas desarrollados con GeneXus. En algunos casos, el volumen de cambios provoca que el registro de auditoría crezca más de lo deseable. Esto trae varios problemas, asociados a la facilidad de búsqueda en la base de datos para encontrar los registros relevantes, la performance de la explotación de estos datos, y espacio en disco utilizado por la base de datos de auditoría.

Para mitigar este problema, K2BTools ofrece mecanismos para disminuir el tamaño de este registro.

Primer paso: ¿Cuáles tablas debemos auditar?

Un enfoque habitual cuando se inicia el uso de K2BAudit es intentar auditar todas las tablas de la aplicación. Esto sin dudas lleva a registros de auditoría voluminosos, ya que cualquier operación realizada en el sistema deja su traza en el registro.

En algunos contextos, esto puede ser necesario dada la estructura de la base de datos y los requerimientos de la aplicación.

En muchos casos, sin embargo, pueden encontrarse tablas que no precisan ser auditadas. Por ejemplo aquellas tablas que almacenan información redundante, o cuyo contenido claramente no es crítico para el funcionamiento del sistema.

Por lo tanto, una buena práctica es comenzar analizando qué tablas auditar, considerando factores como los siguientes:

1. ¿Hay requerimientos que indiquen que se debe incluir auditoría para esta tabla?
2. ¿Qué volumen de operaciones esperamos para la tabla?
3. Auditar esta tabla, ¿puede auxiliar en el análisis de un incidente que nos lleve a los registros de auditoría?

En el fondo, es un análisis costo/beneficio donde el costo está asociado al espacio en disco consumido por los registros de auditoría, y el beneficio es la posibilidad de explotar los datos auditados.

Para reflejar este análisis en K2BAudit, debe usarse la propiedad “Has Audit” de la transacción asociada.

Para hacer una configuración masiva, puede usarse la opción de menú “K2BAudit -> Select Transactions To Audit”.

Segundo paso: ¿Cuáles atributos debemos auditar?

Una vez terminado el paso anterior, contamos con un conjunto de tablas que sabemos deben ser auditadas. El segundo paso es parecido al anterior, ahora considerando los atributos dentro de las tablas seleccionadas.

Nuevamente, la propuesta es analizar caso a caso los atributos de las tablas a auditar, para ver la conveniencia de auditar el valor del atributo en cada operación. Algunas preguntas que podemos realizar en esta etapa son:

1. ¿Es requerido, o útil, auditar el valor de este atributo?
2. ¿Cuál es el espacio en disco que estimamos ocupará este atributo?
3. El atributo, ¿es redundante?

En función de este análisis podremos decidir si vale la pena auditar el atributo. Para reflejar esto en K2BAudit podemos usar la propiedad “Audit Attribute”.

Tercer paso: ¿Qué operaciones debemos auditar?

El tercer paso no está orientado a la estructura de la base de datos, sino a las operaciones hechas sobre esta estructura. Sucede que en muchos casos no es necesario auditar todas las operaciones sobre la tabla, sino sólo aquellas que son significativas.

En las últimas versiones de K2BAudit, la configuración de fábrica evita algunas operaciones no significativas: las operaciones “update” que no provocan cambios en los datos auditados no son registradas (si es necesario, puede cambiarse esta configuración).

Más allá de esta optimización, el desarrollador puede determinar en muchos casos que algunas operaciones no deben ser auditadas. Algunos criterios pueden estar asociados a:

1. Tablas donde las modificaciones pueden ser realizadas por procesos automáticos o manualmente por el usuario. Muchas veces sólo vale la pena auditar las operaciones manuales. Por ejemplo, si se tiene una tabla de “Asientos Contables”, podrían auditarse sólo las operaciones manuales sobre la tabla, pero no los asientos generados por el sistema.
2. Tablas donde sólo se interesa auditar operaciones sobre registros que cumplan determinada condición. Por ejemplo, auditar sólo los productos con un precio mayor a un umbral determinado, o auditar las compras para productos de determinado tipo.

Para esto, puede usarse la auditoría condicional.  Usando esta funcionalidad, el desarrollador puede definir condiciones que determinarán si una determinada operación debe ser auditada o no dependiendo de los datos involucrados en la operación. Para configurar esto, se deben utilizar las propiedades Audit <Insert|Update|Delete>Condition que aparecen en la transacción GeneXus.

Propiedades auditoría condicional

Si se agrega un valor a esta propiedad, la operación es auditada únicamente cuando se cumple la condición. Para operaciones de update es posible referenciar a los valores anteriores y posteriores de cada modificación. Por más información sobre el uso de auditoría condicional puede leer aquí

Conclusión

Manejar grandes volúmenes de registros de auditoría puede generar complicaciones. K2BAudit ofrece soluciones para mitigar este problema, disminuyendo la demanda de espacio en disco de estos registros.

En caso de dudas, o comentarios, estamos disponibles en support@k2btools.com.