Descargar - K2BTools

Comentarios

Transcripción

Descargar - K2BTools
Manual de usuario K2BAudit
Versión 4.0
Índice
DESCRIPCIÓN GENERAL ________________________________________ 4
Esquema general ______________________________________ 4
Generación de la Auditoría ______________________________ 5
Análisis de Auditoría ___________________________________ 5
Instalación y autorización ______________________________________ 6
K2B AUDIT EN TRES PASOS _____________________________________ 7
1. Instalar K2B AUDIT ANALYZER _________________________ 8
2. Aplicar K2B AUDIT a la KB de la aplicación _______________ 9
Seleccionar Transacciones a Auditar __________________________________9
Seleccionar Atributos a Auditar _____________________________________11
Reorganización de K2B AUDIT ______________________________________11
Configuración ___________________________________________________13
3. Explotación con K2B AUDIT ANALYZER __________________ 16
Introducción ____________________________________________________16
Transformación de Logs __________________________________________17
Analizar la Auditoría ______________________________________________19
Analyze By Utl __________________________________________________26
Estadísticas ____________________________________________________27
Remove Query Data ______________________________________________28
Personalización y Configuraciones Avanzadas ______________________ 30
K2BAudit Analyzer personalización _______________________ 30
Configuración de conversión de logs _________________________________30
Seguridad ______________________________________________________31
Paneles de explotación ____________________________________________31
Eliminación de registros viejos______________________________________31
Configuraciones generador: ____________________________ 32
Configuraciones avanzadas ____________________________ 33
Seleccion de DBMS ______________________________________________33
Nombre de los procedimientos______________________________________33
Nombre de los triggers ___________________________________________34
Nombre de los triggers a nivel de tabla _______________________________34
Actualización de descripción de atributos _____________________________35
Selección de atributos a auditar ____________________________________35
Anexo 1: Configuración Auditoría en el DBMS ______________________ 38
MySQL _____________________________________________ 38
Oracle _____________________________________________ 38
Permisos de Usuario _____________________________________________38
Carga de paquete________________________________________________39
2
SQL Server __________________________________________ 39
DB2 _______________________________________________ 41
PostgreSQL _________________________________________ 41
Anexo 2: K2B Audit Analizer ___________________________________ 42
Transacciones de auditoria _____________________________ 42
Anexo 3: Extensión de la auditoría _______________________________ 43
3
DESCRIPCIÓN GENERAL
K2BAudit es una extensión para GeneXus XEV1 XEv2 y XEV3 que permite auditar las
tablas de una KB mediante el uso de triggers los cuales registran todas las
operaciones que los usuarios realizan.
La auditoría se encuentra implementada para MySQL, Oracle y SQL Server,
PostgreSQL y DB2 for ISeries para los generadores java y .net. Se ofrece además
la posibilidad de extenderla por parte del usuario para otros DBMS que se requieran.
En esta documentación se presentarán las características generales de la auditoria y
las características particulares de cada DBMS y generador.
Esquema general
K2BAudit está compuesto por tres componentes:
•
K2B Audit Extension: Extensión GeneXus, que posibilita generar los
elementos necesarios en su base de conocimiento, para auditar su aplicación.
•
Audit Data Base: Base de datos de auditoría, donde se almacenan los logs
de cambios realizados en la base de datos de la aplicación.
•
K2B Audit Analyzer: Aplicación que permite analizar los datos auditados.
4
La solución consta de lo siguiente:
Generación de la Auditoría
En la KB de la aplicación que se desea auditar, mediante la extensión K2BAudit, se
permite seleccionar qué transacciones son las candidatas a auditar. En base a esto,
se generan y ejecutan automáticamente los programas necesarios para crear los
triggers en la base de datos de la aplicación, los cuales registran cada cambio
realizado (insert, update, delete) en la Audit DataBase.
La información que se registra en cada cambio consiste en el “valor anterior” y
“valor posterior” de cada uno de los atributos que pertenecen a la tabla auditada.
Los únicos atributos que se excluyen de la auditoría son los campos blobs.
En la aplicación generada, existirá además un objeto que permitirá auditar o
deshabilitar la auditoría de las tablas seleccionadas en tiempo de ejecución.
Análisis de Auditoría
Para analizar los cambios registrados en sus datos, se cuenta con una aplicación
K2B Audit Analyzer que se encarga de brindar herramientas para explotar de
diferentes formas esa información.
Auditando más que su aplicación
Dado que los triggers se encuentran en la base de datos de la aplicación, no solo es
auditada la base de conocimiento a la que se le aplica la auditoría sino que también
cualquier aplicación, o usuario de la base de datos que realice operaciones sobre esa
base, como se muestra en el siguiente diagrama.
5
Ventajas de la arquitectura
Mediante esta arquitectura K2BAudit no afecta el trabajo de los desarrolladores. No
hay que codificar código extra dependiendo si una tabla está auditada o no. Esto
posibilita también la incorporación de K2BAudit en cualquier momento del desarrollo
y para DBMS que no manejan logs nativos.
El usuario que se audita en la auditoría es el usuario de la aplicación, no el de la base
de datos, permitiendo así identificar al usuario que realmente produjo los cambios.
INSTALACIÓN Y AUTORIZACIÓN
Para instalar la versión de K2BAudit, se debe ejecutar el setup y seleccionar el
directorio en donde está instalado GeneXus. Esto genera una nueva opción en el
menú de GeneXus “K2BAudit” donde tendrá las opciones para trabajar con la
auditoría.
Una vez finalizada la instalación, puede autorizar la versión completa, o la puede
utilizar sin autorización (modo “Free”) donde podrá auditar hasta 5 tablas.
Para autorizar el producto, puede ir al menú K2BAudit dentro de GeneXus y
seleccionar la opción Authorize K2BAudit. Allí en la opción Licence Manager, podrá
solicitar licencias de K2BAudit como cualquier producto GeneXus.
Nota: En caso de que no aparezca la opción K2BAudit en el Licence Manager, desde
el menú de K2BAudit ejecutar la opción Open LicenceManager Folder y ejecutar el
archivo k2btools.reg.
6
K2B AUDIT EN TRES PASOS
El primer paso es instalar K2BAudit
Analyzer el cual crea las estructuras
necesarias para almacenar los logs, y
contiene la aplicación para explotarlos
luego.
El segundo paso consiste en aplicar
K2BAudit a la KB que se desea auditar, lo
cual genera todo lo necesario para crear
automáticamente los triggers en la
aplicación que son los que generarán los
logs en la “K2B Audit DB”
Finalmente, todo cambio realizado en su
base de datos, ya sea desde la aplicación o
en forma directa, estará generando logs de
auditoría. Cuando lo desee podrá analizar
todo esos datos mediante
K2BAuditAnalyzer.
Veamos en detalle cada uno de estos pasos:
7
1. Instalar K2B AUDIT ANALYZER
K2BAuditAnalyzer es una aplicación que contiene las estructuras donde se
materializarán los logs de auditoría y un conjunto de potentes consultas para su
análisis.
Actualmente esta aplicación es provista como una base
de conocimiento GeneXus, para que el desarrollador la
genere en su ambiente y eventualmente pueda
extenderla o adaptarla a sus necesidades.
La instalación de K2BAudit Analyzer consiste en instalar
la base de conocimiento de la aplicación, generar su
base de datos (base de datos de auditoría) y generar
sus programas.
Pasos de instalación:
• Crear una KB nueva (por ejemplo: K2BAuditAnalyzer)
• Ir al menú K2BAudit de GeneXus y seleccionar la opción Get
K2BAuditAnalyzer.
•
•
Seguir las instrucciones que se describen en la página del wiki.
•
Configurar el modelo según las características de su instalación (generador,
base de datos, etc.)
Crear la base de auditoría (ejemplo de nombre: K2BAudit DataBase),
especificar, generar y compilar la aplicación.
o Nota: Para PostgreSQL, la base de datos debe ser la misma que la
aplicación, pero con nombre de esquema K2BAudit.
•
8
De esta forma queda pronta la aplicación K2BAudit Analyzer en su ambiente
(generador, base de datos) para recibir los datos auditados desde sus aplicaciones y
para explotarlos.
2. Aplicar K2B AUDIT a la KB de la aplicación
Este paso consiste en preparar a su aplicación para que comience a generar la
auditoría. Para ello, desde el ambiente de desarrollo (KB de la aplicación) podrá
seleccionar las transacciones a auditar y crear/reorganizar los triggers en su base
de datos, los cuales se encargarán de generar los logs en la base de datos Audit DB.
Seleccionar Transacciones a Auditar
Existen dos maneras de habilitar la auditoría para una transacción en el ambiente de
desarrollo: por medio de una propiedad de la transacción o mediante un panel que
permite seleccionar varias transacciones a la vez.
Para habilitar la auditoría en una transacción debe configurar en las propiedades de
la transacción: HasAudit = true.
9
Para habilitar varias transacciones a la vez, acceda a la opción en el menú
K2BAudit / Select Transactions to Audit.
Esto permitirá mediante un panel, seleccionar las transacciones a auditar. Una vez
finalizada la selección, se debe presionar el botón audit para que se salve la
propiedad audit asociada a las transacciones.
Las transacciones a auditar también se podrán configurar luego en tiempo de
ejecución.
10
Seleccionar Atributos a Auditar
A partir de la versión 3.0 es posible seleccionar para cada transacción cuáles son los
atributos que se van a auditar. Para esto a nivel de atributo dentro de la transacción,
se cuenta con una propiedad de nombre “Audit Attribute”. . La misma será
visualizada en los atributos que forman parte de la tabla base de la transacción
asociada.
Reorganización de K2B AUDIT
Una vez seleccionadas las transacciones a auditar, el siguiente paso es generar la
auditoría en su base de datos.
La reorganización de auditoría de su KB es la encargada de crear los triggers de
creación de logs, en las tablas de su base de datos seleccionadas en el paso anterior.
Para disparar la reorganización de auditoría,
estando dentro de la KB de su aplicación, acceda
al menú K2B Audit -> Reorganize
11
La opción Reorganize de K2bAudit, hace lo siguiente: comprueba que los objetos
básicos de auditoría provistos por K2BAudit existan (en caso contrario los consolida
automáticamente), genera los objetos GX que crean los triggers a sus tablas, los
genera en el lenguaje y base de datos de su aplicación y los ejecuta.
Una vez ejecutada esa opción ya sus tablas quedan con los triggers creados para la
generación de auditoría.
Notar que en su KB, quedarán los objetos GeneXus usados en el Reorganize de
K2BAudit. Éstos quedan ubicados dentro de la KB, debajo de cada transacción a
auditar. También queda generado un procedimiento GX “K2BAuditReorganize” que
invoca a los procedimientos de creación de triggers de cada transacción.
Estos procedimientos no son necesarios ejecutarlos manualmente, se generan y
ejecutan cada vez que se ejecute la opción “Reorganize”
K2BAudit genera también un procedimiento, K2BDropAllTriggers, que incluye
sentencias SQL para eliminar los triggers creados por la auditoría.
Si desea eliminar los triggers, ejecute este procedimiento.
----------------------------------------------------------------------------------------Nota: Antes de correr la reorganización verifique que el DBMS utilizado este
configurado correctamente. Para esto en Preference ir a K2BAudit Settings
Desde ahí verificar que la generación para la plataforma escogida este en true. Se
recomienda en caso de generar K2BAudit para una única plataforma, poner esa
únicamente en true y el resto en false.
-------------------------------------------------------------------------------------------
12
Configuración
Hay un conjunto de configuraciones que es necesario realizar la primera vez que se
aplica K2bAudit a una KB.
Configuración de Data Store de K2BAuditAnalizer
En su KB encontrará un data store llamado K2BAudit que es el que se usa para
generar los logs de las tablas. En este data store debe configurar los datos de
conexión a la base de datos en la cual se almacenará la auditoria. (K2BAuditAnalizer)
Configuración del usuario de la aplicación
Una parte importante de la auditoría es la obtención del usuario que está ejecutando
la aplicación.
Cuando los triggers se disparan, éstos saben cuál es el usuario de la base de datos
que los disparó (el usuario que se definió en las propiedades del modelo GeneXus)
pero no qué usuario de la aplicación lo hizo (la persona que accede a la aplicación
con un nombre de usuario específico).
Para solucionar esto, K2BAudit ofrece el procedimiento que le permitirá especificar
cómo obtener el usuario de su aplicación, y que lo grabará en la base de datos,
para que luego los triggers puedan obtener dicho usuario
Existe un procedimiento por DBMS. Deberá abrir el correspondiente al que usted está
usando.
13
Para que se almacene el usuario deberá modificar el procedimiento en la parte que
dice “SetUserCode” asignando a la variable &User el valor correspondiente al
usuario de la aplicación.
Luego deberá editar las propiedades del generador usado para que en el After
Connect invoque al procedimiento.
Ejemplo si se tiene SQLServer como DBMS utilice el procedimiento
K2BSaveAuditUserSQLServer
Configuración de información de UTL
En SqLServer, Oracle y PostgreSQL será posible conocer en qué utl se realizaron los
cambios en la base y qué otros cambios fueron realizados en la misma. Además
será posible conocer cuál fue el objeto GeneXus que hizo commit. Para esto es
necesario setear en las propiedad del modelo BeforeCommit el proc
K2BBeforeCommitSQLServer,
K2BBeforeCommitOracle
o
K2BBeforeCommitPostgreSQL según cuál sea el dbms utilizado.
Configuraciones básicas según generador
Si se está usando .net existe una configuración adicional que debe ser realizada.
Para esto ir a la parte Configuraciones Generador.
Configuraciones básicas según DBMS
Según el DBMS seleccionado, se deberán seguir los pasos en el anexo para cada uno
de los dbmss en los que está soportada la auditoría. Para esto ir al Anexo 1, a la
parte de configuración del dbms utilizado.
14
Configuración de las transacciones a Auditar en ejecución
Luego que la auditoría se está ejecutando en su aplicación, se puede variar las
tablas a auditar en ejecución. Para ello se cuenta el web panel WWAuditTable,
donde se podrá habilitar/deshabilitar la auditoría.
AuditSelected: Audita las tablas seleccionadas.
Disable Audit: Desabilita la auditoría de las tablas seleccionadas.
AuditAll: Audita todas las tablas.
DisableAll: Elimina la auditoría de todas las tablas.
15
3. Explotación con K2B AUDIT ANALYZER
Introducción
Luego de haber usado su aplicación con los triggers generados, ya se puede
explotar esa información mediante el K2BAudit Analyzer. (el proceso de instalación
se describió al principio del manual)
K2BAuditAnalyzer permite:
- Consultar la auditoría de diferentes formas
- Configurar filtros basado en los datos de su aplicación, para esas consultas.
- Manejar los logs generados: transformarlos, borrarlos, etc.
- Configurar la seguridad de acceso a sus diferentes opciones.
Para acceder a la aplicación deberá hacerlo accediendo al objeto K2BAuditQueryMain
16
Antes de poder consultar los datos auditados con toda la potencia de las consultas,
se deben transformar los logs.
Transformación de Logs
Los datos de auditoría se graban en formatos planos (“crudos”) como forma de
optimizar la performance, por lo que necesitan una transformación para ser
explotados en forma eficiente. Mediante la opción “Transform Logs” se dispara esta
transformación. (AuditQueryLoad).
Este proceso se ejecuta de manera sometida. En la pantalla se visualizará la
fecha/hora en la que se comenzó a ejecutar el último proceso de transformación y la
fecha/hora en la que finalizó su ejecución.
17
Cuando se selecciona “run” se dispara el proceso.
Al ejecutarlo el status va a pasar de No Executing a Executing.
Mediante el botón de “Check Execution” se puede chequear si la ejecución finalizó o
no. Debajo se puede ver información acerca de la conversión, relacionada con todos
los procesos que están convirtiendo y cuántos registros lleva convertidos cada uno.
El estado se actualizará cada vez que se de click en Check Execution.
18
Transformación de Logs como tarea programada
Este mismo procedimiento de transformación se puede ejecutar por línea de
comandos. de forma de poder configurarlo como una tarea programada. Esto
permite ejecutarlo cada determinado tiempo, al final del día, etc.
El procedimiento a programar en la tarea se llama “AuditQueryLoadDaemon”
•
•
•
Si el generador usado es C#, se debe ejecutar el archivo
AuditQueryLoadDaemon.exe
Si el generador es Java hay que ejecutar la siguiente línea: java –cp
../lib/gxclassR.jar:../lib/DriverDBMSCorrespondiente.jar
auditqueryloaddaemon.
Si se está en ambiente Windows, hay que remplazar el : por ;.
En la ejecución en forma batch, el programa mostrará mensajes cada treinta
segundos indicando cuál es el estado de la ejecución y al finalizar se visualizará un
resumen de cuánto tiempo demoró la conversión y la cantidad de registros que
fueron convertidos.
Una vez transformado los logs, se está listo para analizar los datos de auditoría.
Analizar la Auditoría
Para el análisis de la auditoría se proveen las siguientes consultas:
Analize by operation (WWAuditQuery)
El análisis por operación permite ver los registros que han sufrido modificaciones
por los filtros básicos: período, usuario, operación, entidad y tabla.
Período: Es un desde/hasta sobre la fecha de modificación del registro.
Usuario: Es el usuario de la aplicación que modificó el registro
Operación: Es la operación que se realizó sobre el mismo: Insert, Update, Delete
Entidad: Es un conjunto de transacciones con valor semántico común. En este caso
por entidad se agrupan todas las tablas que pertenecen a la misma transacción.
(ejemplo Cliente, Direcciones de Clientes, etc.)
19
Cada operación que se realizó sobre tablas auditadas se puede ver como una línea
en este WW. Se puede obtener más detalle ingresando al View de cada línea, donde
se podrá visualizar datos generales de la modificación (General), qué atributos se
modificaron (Attributes), modificaciones anteriores y posteriores a la que se está
analizando (Related Records).
Datos Generales
Atributos Modificados
20
La llave indica los atributos que son clave de la tabla. El bullet azul indica que el
atributo no ha sido modificado, y el bullet rojo indica que se modificó el atributo.
Asociado al registro auditado, se cuenta con el tab related records, allí se muestran
todas las modificaciones realizadas sobre el registro que se está analizando.
21
22
En la primera grilla se indican las modificaciones anteriores (<), la modificación que
se está analizando (=) y las posteriores (>). Si se da clic sobre el display, en la
grilla inferior se muestra para cada modificación, que atributos se modificaron y
cómo.
Analyze by Application Data
La consulta anterior nos permite dado un período, usuario, tabla u operación,
analizar todas las modificaciones que se realizaron, permitiendo además especificar
atributo por atributo su valor anterior y posterior.
Existe otro tipo de consultas donde se necesita partir de algún dato específico de la
aplicación (por ejemplo: un nro. de factura, un código de producto, un número de
funcionario) obtener qué atributos asociados a esa factura, ese producto o ese
funcionario se modificaron y cómo.
Este tipo de consultas, donde se debe filtrar por datos que dependen de cada
aplicación y de cada tabla, se resuelven con la opción “Analyze by Application Data”
Para tener en esa consulta, filtros por datos de su aplicación, se deben configurar los
mismos para cada tabla en la opción “Configure Application Data”.
23
Configure Application Data
Ingresando a esta opción, para cada tabla se podrá configurar los atributos por los
cuales se desea filtrar en la consulta “Analyze by Application Data”, cada vez que se
consulte las modificaciones sobre esa tabla.
Se selecciona la tabla en el combo de “filters” y se seleccionan todos los atributos
que se deseen que intervengan como filtros cada vez que esa tabla sea consultada
por el “Analyze by Application Data”.
Una vez finalizada la selección, oprima “save”.
En este caso hemos seleccionado como filtro para la tabla Invoice, el atributo
InvoiceCode. De esta forma vamos luego a poder buscar por InvoiceCode las
modificaciones que se realizaron, cuándo, quién, que atributos se modificó, etc.
Analize by Application Data
Luego de realizar la configuración anterior, al acceder a esta consulta se podrá
realizar lo siguiente:
Lo primero a ingresar en la consulta
es la entidad que se quiere consultar,
para ello elija mediante el prompt, y
cliquee en Select Entity.
24
Una vez definida la entidad a analizar, se presentarán todos los filtros posibles para
consultar, los filtros básicos: Tabla, Periodo, operación, usuario, más los filtros
específicos para esa entidad según se configuró en la opción anterior.
Si queremos saber quiénes modificaron determinada factura es posible colocar el
código de esa factura en el filtro InvoiceCode y así obtener todas estas
modificaciones.
Seleccionando uno de los campos con la lupa es posible visualizar los cambios
especificados por atributos que fueron realizados en esa modificación.
25
En los filtros en el grupo Attribute Change es posible seleccionar todos los cambios
que modificaron determinado atributo. Para esto donde dice Table hay que tener
instanciada la tabla por la que se van a seleccionar los atributos.
Un caso de uso es poder obtener los registros de quienes modificaron el campo
precio de un producto. Esto se resuelve filtrando como se muestra en la siguiente
pantalla.
Analyze By Utl
En la explotación en cada lugar donde se visualicen registros auditados
aparecerá un ícono con una base de datos y un check, en el cual se podrán visualizar
qué otros cambios se hicieron en la utl que modificó el registro.
26
Allí se visualizará en una grilla todos los cambios que se hicieron en dicha utl
y en el cabezal se mencionará cuál fue el objeto que hizo commit y a qué hora.
La visualización de la UTL está disponible solo para SqlServer, Oracle y PostgreSQL.
Estadísticas
Gracias a la información que almacena K2BAudit, también es posible acceder a datos
estadísticos sobre el uso de la aplicación. Por ejemplo cuales son las tablas auditadas
que más se modifican, cuál es el usuario que hizo más modificaciones y cómo es la
evolución de dichas modificaciones en el tiempo. Este es un ejemplo de una pantalla
a la que es posible acceder ejecutando el objeto TopMod, el cual puede ser
personalizado para realizar las consultas estadísticas que se deseen.
27
Remove Query Data
Si se quieren eliminar registros de la auditoria, se puede seleccionar la opción del
menú Remove Query Data, que dada una fecha, elimina todos los registros
anteriores a dicha fecha.
Existe otro proceso para ejecutar bajo la línea de comandos que permite eliminar la
auditoría del año anterior. Este procedimiento tiene como nombre
PurgeLastYearAuditQuery y borra la auditoría que tiene más de un año.
28
Personalización, y
configuraciones Avanzadas
29
PERSONALIZACIÓN Y CONFIGURACIONES AVANZADAS
K2BAudit Analyzer personalización
La aplicación K2BAuditAnalyzer puede ser personalizada, para adaptarla a las
necesidades del usuario. En esta sección analizaremos algunos ejemplos de
personalizaciones que se pueden hacer en la aplicación
Configuración de conversión de logs
A partir de K2BAudit 3.0 es posible configurar la forma en que se ejecutará la
conversión de registros de auditoría. Para esto se cuenta con una tabla donde se
permitirá parametrizar la ejecución de este proceso.
Los parámetros que se pueden configurar son:
• ConcurrentProcess: Cantidad de procesos que realizarán la conversión. Por
defecto se ejecuta un solo proceso.
•
LimitRows: Cantidad máxima de registros que se convertirán en una
ejecución. Si se coloca el valor 0 no hay ningún límite.
•
RowToProcess: Cada cuantos registros convertidos se hace commit.
•
XmlParseLimit: Puede darse la posibilidad de que la conversión del xml de
auditoría quede en loop. En tal caso la conversión se detendrá en el valor del
parámetro y desplegará un mensaje de error en los logs de conversión.
Además de esto cada proceso que ejecute la conversión tendrá un log asociado.
El mismo podrá visualizarse en la opción de menú Log Conversions.
30
Allí se podrá visualizar para cada conversión cuándo se ejecutó y de la misma
cuántos registros fueron convertidos. En caso de error, se podrá acceder al detalle
para visualizar cuáles fueron los errores.
Seguridad
A partir de la versión 4.0 K2BAuditAnalyzer no viene con una seguridad configurada
por defecto. La recomendación es que sea utilizado el GAM (GeneXus Access
Manager), pero también es posible personalizar la seguridad para adaptarla a el
sistema de seguridad que maneje el desarrollador. Más información en
http://wiki.k2btools.com/k2btools/servlet/hwikibypageid?20262
Paneles de explotación
Los paneles de explotación pueden ser también personalizados.
En este caso AnalyzeByOperation es el objeto WWAuditQuery.
AnalyzeByApplication y ConfigureApplicationData, se pueden personalizar utilizando
los objetos que poseen el mismo nombre.
Eliminación de registros viejos
Es posible personalizar y realizar procedimientos para la eliminación de registros de
auditoría viejos. Para esto, es posible tomar como base el procedimiento
purgeLastYerAuditQuery.
31
Configuraciones generador:
La primera vez que se aplica K2BAudit, si se está en ambiente .Net, se va a dar el
siguiente error.
k2bauditmodeldbms.cs(97,56): error CS0117: 'GeneXus.Data.ADO.GxDataStore' does not contain a definition for
'Jdbcdriverurl'
k2bauditmodeldbms.cs(101,56): error CS0117: 'GeneXus.Data.ADO.GxDataStore' does not contain a definition for
'Jdbcdriverurl'
k2bauditmodeldbms.cs(105,56): error CS0117: 'GeneXus.Data.ADO.GxDataStore' does not contain a definition for
'Jdbcdriverurl'
Para esto, abrir el objeto K2BAuditModelDBMS y comentar todo el código que
comienza en java if (true){ hasta } como se muestra en la siguiente imagen:
Luego de hacer esto puede abrir el objeto K2BAuditReorganize y seleccionar la
opción run, para que se vuelva a ejecutar el programa de reorganización.
32
Configuraciones avanzadas
En esta parte del manual se explicarán configuraciones avanzadas que son posibles
realizar dentro de la auditoría.
Seleccion de DBMS
Por defecto, K2BAudit en la generación de código genera la auditoría para los DBMS
que soporta, haciendo que los procedimientos Audit<Table>CreateMetadata tengan
el código para todos los dbmss.
Esto es posible restringirlo para que solo se genere la auditoría para el dbms
particular que se está utilizando o los dbms que se van a utilizar.
Para seleccionar el o los DBMS que desea, vaya a Preferences /K2BAudit. Ahí, en el
conjunto de propiedades Platforms podrá seleccionar la o las plataformas para las
cuales generará la auditoría.
Nombre de los procedimientos
Es posible renombrar los procedimientos que la auditoría genera para las
transacciones.
33
La propiedad Create Metadata Name, del conjunto Naming, permite generar los
procedimientos con el nombre deseado. Todo nombre de procedimiento debe incluir
OBLIGATORIAMENTE el tag <Table>, si este no se encuentra presente la auditoría
no podrá ser generada.
Nombre de los triggers
El conjunto de propiedades Naming también posee propiedades para renombrar los
triggers de INSERT, UPDATE y DELETE. Esta propiedad permite usar los nombres que
desee en lugar de los ofrecidos por defecto por K2BAudit. Al igual que con la
propiedad Create Metadata Name, el tag <Table> es OBLIGATORIO.
Nombre de los triggers a nivel de tabla
34
Hay momentos en los cuales se quiere personalizar el nombre de los triggers para
cada tabla sobre la cual serán creados. Esta es una situación que se puede dar
cuando el nombre de los triggers supera el largo permitido por el DBMS.
Para cambiar el nombre de los triggers, se cuenta con un conjunto de propiedades a
nivel de tablas que permiten hacer esto.
De clic sobre la tabla, y en el grupo de propiedades K2b Tools verá el subgrupo
Audit. Ahí se muestra los nombres que serán usados para los triggers de INSERT,
UPDATE y DELETE. Puede cambiar estos nombres por los que dese y K2BAudit los
usará al momento de generar la auditoría.
Actualización de descripción de atributos
Por defecto, desde la versión 3.0 de K2BAudit, en la reorganización de auditoría se
ejecuta un procedimiento que se encarga de actualizar las descripciones de los
atributos en la explotación de auditoría. Está funcionalidad puede ser deshabilitada
en el settings de K2BAudit
Esto se hace colocando el valor de la propiedad SetDescriptionsToAttributes en false.
Selección de atributos a auditar
A partir de la versión 3.0 se puede configurar qué atributos se pueden auditar y
cuáles no. Dado que esta configuración es realizada a nivel de transaction attribute,
puede suceder que la transacción no tenga todos los atributos que están presentes
en la tabla, ¿qué pasa con esos atributos?. Por defecto aquellos atributos que no
35
estén presentes en la transacción serán auditados pero este comportamiento puede
ser cambiado haciendo modificaciones en la propiedad Not In Transaction Attributes,
seteando su valor a Do Not Audit.
36
Anexos
37
ANEXO 1: CONFIGURACIÓN AUDITORÍA EN EL DBMS
MySQL
Por restricciones de MySQL, el usuario con el cual se crean los triggers tiene que
tener SUPER PRIVILEGE.
Para lograr esto hay darle todos los privilegios al usuario que va a crear los triggers
(usuario con el que la aplicación se conecta al dbms).
GRANT ALL PRIVILEGES ON *.* TO <usuarioParaCrearTriggers>@localhost
IDENTIFIED BY ‘<password>’
Para esto
1. Loguerse al MYSQL comnad line con root
2. Ejecutar: GRANT ALL PRIVILEGES ON *.* TO
<usuarioParaCrearTriggers>@localhost IDENTIFIED BY ‘<password>’
En caso de que al ejecutar la reorganización de la metadata de cómo error “Invalid
User information for handle” es posible verificar si los super privileges fueron bien
seteados utilizando las siguientes sentencias:
USE MYSQL
Select Host, User, super_priv from user;
El usuario que crea los triggers no debe tener denegado ningún privilegio.
Además se deberá crear el stored procedure cuyo código se encuentra en
Packages\K2BTools\Audit\MYSQL\ K2BAuditProcedures.sql
Debe ser ejecutando dentro de la base de datos de la aplicación auditada.
Oracle
Permisos de Usuario
Conectado como SysDBA Dar permisos de selección al usuario de la base de datos
por el que se conecta la aplicación en las tablas V_$SeSSION y V__$MYSTAT. Para
resolver esto seguir los siguientes pasos
•
•
•
Abrir SQLPlus de Oracle
conn /as sysdba;
GRANT SELECT ON V_$SESSION TO <usuario>
38
•
GRANT SELECT ON V_$MYSTAT TO <usuario>
Carga de paquete
Para determinar el usuario en Oracle, K2BAudit utiliza un package en el cual carga
los datos del usuario de la aplicación.
Antes de ejecutar la creación de triggers deberá ejecutar el siguiente código que se
encuentra en:
Packages\K2BTools\Audit\Oracle\Audk2b.sql dentro del directorio de
instalación de GeneXus.
Para hacer esta ejecución se pueden seguir los siguientes pasos:
•
•
•
•
Abrir el SQLPlus de Oracle
Ejecutar connect
Colocar el nombre de usuario y contraseña del usuario de la aplicación según
oracle lo va pidiendo. (el usuario que se conecta a la aplicación auditada)
Escribir: @” <GenexusInstallDir>\Packages\K2BTools\Audit\Oracle\
Audk2b.sql”
En caso de que de error en la compilación del paquete se puede ver el error
usando el comando Show Errors.
SQL Server
El usuario de SQL Server con el cual se crearán los triggers deberá tener permisos
para crearlos.
Para esto hay que establecerle al usuario el Server Role sysadmin.
En logins seleccionar el usuario utilizado ir a properties y ahí marcar la opción
sysadmin.
39
40
Además a partir de la versión 4.0 se deberán crear los stored procedures que se
encuentran dentro del directorio de instalación GeneXus en
Packages\K2BTools\Audit\SqlServer\K2BAuditProcedures.sql
Dichos stores procedures deberán ser creados dentro de la base de datos de la
aplicación.
DB2
Crear los store procedure GetAudit y SetAudit. El código de estos store procedures se
encuetran en el directorio \Packages\K2BTools\Audit\DB2 y su nombre es
K2BAuditProcedures. Sustituir todas las apariciones de K2BTools por el nombre de la
base de datos de la aplicación.
Ejemplo: Si la base de datos se llama AppKB, el procedure GetAudit tendría los
siguientes dos cambios
• CREATE PROCEDURE AppKB.SETAUDIT ( en lugar de K2BTools.SETAUDIT)
• SPECIFIC AppKB.SETAUDIT (en lugar de K2BTools.SETAUDIT)
En la KB que se va a auditar, abrir el procedimiento K2BAuditModelDBMS, eliminar el
código y dejar únicamente:
&AuditModelDBMS = “DB2”
PostgreSQL
Para poder utilizar K2BAudit con PostgreSQL se deberán realizar las siguientes
configuraciones:
Dentro de la carpeta Data del directorio donde está instalado PostgreSQL agregar la
siguiente entrada al final del archivo postgresql.conf
genaudit.usuario = ''
genaudit.ip
= ''
Una vez hecho esto, crear el stored procedures que se encuentra en
Packages\K2BTools\Audit\PostgreSQL\K2BAuditProcedures.sql dentro del directorio
de instalación de GeneXus.
41
ANEXO 2: K2B AUDIT ANALIZER
La KB de Explotación contiene las transacciones en las cuales se grabarán los datos
de auditoría y los datos que hayan sido procesados para su explotación.
Transacciones de auditoria
Las siguientes son las transacciones de auditoría:
Transacción
AuditLoad
AuditTable
AuditEntity
AuditEntityTable
AuditQuery
AuditQueryLog
AuditUser
AuditAttribute
AuditTableAttribute
Descripción
Es dónde los triggers registran la información de cada
operación que el usuario realiza. Se almacena aquí la
fecha, tabla, operación y para los atributos
modificados, los valores anterior y posterior.
Para cada tabla auditada, guarda el código de los
triggers asociados.
Almacena información de la entidad auditada
Establece la relación entre las tablas auditadas y la
entidad auditada.
Los datos de AuditLoad se cargan aquí cuando se
ejecuta la transformación para explotación.
Guarda la información que genera el programa de
conversión de datos, última fecha de ejecución,
estado y errores en el caso de que hayan ocurrido.
Almacena datos del usuario que realiza las
operaciones.
Almacena los atributos que se modifican en las
operaciones
Es el nexo entre los atributos y las tablas a las cuales
pertenecen.
42
ANEXO 3: EXTENSIÓN DE LA AUDITORÍA
K2BAudit ofrece la posibilidad de generar auditoría para un DBMS adicional a los que
ya soporta. Para esto se ofrece el dkt CreateTriggersForOther.dkt que se encuentra
en el directorio {$dirInstalacionGenexusX}\Packages\K2BTools\Audit\Templates.
Es en este dkt que puede agregar el código necesario para generar los triggers para
el nuevo DBMS.
En este anexo se mostrará un ejemplo de cómo hacer esto basándose en el dkt de
creación de triggers para MySQL.
El código de los dkts puede separarse en dos grandes partes: código compartido y
código específico.
El código compartido es código que en todos los dkts es igual, dividiéndose en:
1. Código del cabezal; acá se referencia los assemblies usados, los namespaces
que se importan y los parámetros que el dkt recibe.
2. Definición de variables básicas: acá define y carga variables básicas como
nombre de la tabla que se esta auditando, la operación que se esta realizando
(INSERT, UPDATE o DELETE), nombre de la base de datos, nombre del
usuario, etc.
// Cabezal
<%@ Template Language="C#" TargetLanguage="GX" Description="Generates
SQL Server Triggers" %>
<%@ Assembly Name="Artech.Genexus.Common" %>
<%@ Assembly Name="Artech.Architecture.Common" %>
<%@ Assembly Name="Artech.Udm.Framework" %>
<%@ Assembly Name="Artech.Common.Properties" %>
<%@ Import Namespace="Artech.Genexus.Common" %>
<%@ Import Namespace="Artech.Genexus.Common.Objects" %>
<%@ Import Namespace="Artech.Genexus.Common.Parts" %>
<%@ Import Namespace="Artech.Architecture.Common.Services" %>
<%@ Import Namespace="System.Collections.Generic" %>
<%@ Property Name="Table" Type="Table" %>
<%@ Property Name="MaxAttLength" Type="System.Int32" %>
<%@ Property Name="MaxTableLength" Type="System.Int32" %>
<%@ Property Name="Mode" Type="String" %>
<%@ Property Name="TriggerName" Type="String" %>
<%@ Property Name="EntityName" Type="String" %>
//Definición de variables básicas
<%
string tableName = Table.Name;
string operation = "";
if (Mode == "INS")
operation = "INSERT";
else if (Mode == "UPD")
operation = "UPDATE";
43
else
operation
= "DELETE";
string bdTableName = "";
if (Table.Name.Length > MaxTableLength)
bdTableName = Table.Name.Substring(0, MaxTableLength);
else
bdTableName = Table.Name;
string userNameVar = "userName";
string auditRecordKeyVar = "auditRecordKey";
string auditValueVar = "auditValue";
string dbName = "<AuditDB>"; // Esto K2BAudit lo sustituye
automaticamente
string GXUserId = "GXUserId";
%>
Como se menciono anteriormente, este es el código que es común a todos los dkts.
A continuación de este comienza el código específico del DBMS para el cual se esta
creando el dkt.
El código debería seguir el siguiente esquema:
DEFINICION TRIGGER AFTER/BEFORE OPERACIÓN PARA TABLA
VARIABLES
nombreDeUsuario;
valoresDePK;
valoresDeAtts;
CUERPO DEL TRIGGER
Generar XML para la PK, cargando valores nuevos en caso de INSERT o
UPDATE o viejos en caso de DELETE;
Generar XML para los Atts, cargando valores nuevos en caso de INSERT o
UPDATE o viejos en caso de UPDATE o DELETE descartando atributos no auditables
(formulas, binarios, bitmaps);
Grabación del XML en la tabla de auditoria;
FIN DEL TRIGGER;
Particularmente, para MySQL el código seria:
44
// Definición del TRIGGER
CREATE TRIGGER <%= TriggerName %> AFTER <%= operation %> ON <%=
bdTableName %>
FOR EACH ROW BEGIN
// Declaración de Variables
DECLARE <%=userNameVar%> CHARACTER(90);
DECLARE <%=auditRecordKeyVar%> MEDIUMTEXT;
DECLARE <%=auditValueVar%> MEDIUMTEXT;
<%
// Se empieza a armar el XML para la PK
string firstParameter = "'<Attributes>',";
string attributeMethodForRecordKey = "NEW";
// Si el modo es DLT se cargan los valores viejos
if (Mode == "DLT")
attributeMethodForRecordKey = "OLD";
// Se recorren los atributos de la PK
foreach (TableAttribute att in
Table.TableStructure.PrimaryKey)
{
string attName = GetAttName(att.Name, MaxAttLength);
%>
SELECT
CONCAT(<%=firstParameter%>'<Attribute><Name><%=att.Name%></Name><Value>
<![CDATA[',
<%=attributeMethodForRecordKey%>.<%=attName%>,']]]]><![CDATA[></Value><
/Attribute>') INTO <%=auditRecordKeyVar%>;
<%
firstParameter = auditRecordKeyVar + ",";
}
%>
SELECT CONCAT(<%=firstParameter%>'</Attributes>') INTO
<%=auditRecordKeyVar%>;
<%
// Se arma el XML para los atributos
firstParameter = "'<Attributes>',";
foreach (TableAttribute att in
Table.TableStructure.Attributes)
{
// Si es binario o bitmap se lo descarta
if (att.Attribute.Type == eDBType.BINARY ||
att.Attribute.Type == eDBType.BITMAP)
continue;
// Si es formula se lo descarta
if (att.IsFormula)
continue;
string attributeName = GetAttName(att.Name,
MaxAttLength);
string oldValueCode = "";
string newValueCode = "";
string keyTag = "";
// Se establece si el att forma parte de la PK
if (att.IsKey)
45
keyTag = "<Key>True</Key>";
//Si se esta en INSERT o UPDATE se carga el nuevo
valor del att
if ((Mode == "INS") || (Mode == "UPD"))
newValueCode = "<New><![CDATA[', IFNULL(NEW." +
attributeName + ", ''), ']]]]><![CDATA[></New>";
// Si se esta en UPDATE o DELETE se carga el viejo
valor del att
if ((Mode == "UPD") || (Mode == "DLT"))
oldValueCode = "<Old><![CDATA[', IFNULL(OLD." +
attributeName + ", ''), ']]]]><![CDATA[></Old>";
%>
SELECT
CONCAT(<%=firstParameter%>'<Attribute><Name><%=att.Name%></Name><%=keyT
ag%><%=oldValueCode%><%=newValueCode%></Attribute>') INTO
<%=auditValueVar%>;
<%
firstParameter = auditValueVar + ", ";
}
%>
SELECT CONCAT(<%=firstParameter%>'</Attributes>') INTO
<%=auditValueVar%>;
// Se obtiene el usuario de la aplicación
SELECT @<%=GXUserId%> INTO <%=userNameVar%>;
// Se gaurda la información en la tabla de auditoria
INSERT INTO <%=dbName%>.auditload (ALId, ALDateTime,
ALApplicationUser, ALOperation, ALEntity, ALTable, ALRecordKey,
ALValue) Values (Null, Now(), <%=userNameVar%>, '<%=Mode%>',
'<%=EntityName%>', '<%=tableName%>', <%=auditRecordKeyVar%>,
<%=auditValueVar%>);
END;
46

Documentos relacionados