Descargar - K2BTools
Anuncio
Manual de usuario K2BAudit
Versión 3.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 _______________ 8
Seleccionar Transacciones a Auditar __________________________________9
Seleccionar Atributos a Auditar _____________________________________10
Reorganización de K2B AUDIT ______________________________________10
Configuración ___________________________________________________12
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
Remove Query Data ______________________________________________27
Personalización y Configuraciones Avanzadas ______________________ 29
K2BAudit Analyzer personalización _______________________ 29
Configuración de conversión de logs _________________________________29
Seguridad ______________________________________________________30
Paneles de explotación ____________________________________________30
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
Por defecto 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
SQL Server __________________________________________ 39
2
Anexo 2: K2B Audit Analizer ___________________________________ 41
Transacciones de auditoria _____________________________ 41
Anexo 3: Extensión de la auditoría _______________________________ 42
3
DESCRIPCIÓN GENERAL
K2BAudit es una extensión para GeneXus XEV1/XEv2 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 y 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)
• Consolidar el xpz que se encuentra en
$(GeneXusXEv1InstalationDir)/Packages/K2BTools/Audit/K2BAuditAnalyz
er.xpz si no usa K2BTools. Si usa K2BTools le recomendamos consolidar el
archivo
$(GeneXusXEv1InstalationDir)/Packages/K2BTools/Audit/K2BAuditAnalyz
erK2BTools.xpz
• Configurar el modelo según las características de su instalación (generador,
base de datos, etc.)
• Configurar la propiedad del modelo Translation Type en RunTime para
habilitar que K2BAuditAnalyzser sea multilenguaje.
• Crear la base de auditoría (ejemplo de nombre: K2BAudit DataBase),
especificar, generar y compilar la aplicación.
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.
8
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.
Para habilitar varias transacciones a la vez, acceda a la opción en el menú
K2BAudit / Select Transactions to Audit.
9
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.
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.
10
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.
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)
12
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
K2BSaveAuditUserAfterConnect 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.
Para ello abra el procedimiento K2BSaveAuditUserAfterConnect y setee el usuario en
la parte donde indica “SetUserCode” mediante la variable User.
Luego deberá editar las propiedades del generador usado para que en el After
Connect invoque al K2BSaveAuditUserAfterConnect
Configuración de información de UTL
En SqLServer y Oracle, 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 o
K2BBeforeCommitOracle según cuál sea el dbms utilizado.
13
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.
La primera vez que se accede se cuentan con dos usuarios predefinidos con
diferentes permisos:
Administrador: Puede acceder a todas las opciones de auditoría, de explotación y
de manejo de logs, y también configurar toda la seguridad del sistema. (usuario:
administrator, password: administrator)
AuditUser: Solamente puede acceder a la explotación de la auditoría, pero no puede
administrar logs, ni configurar seguridad. (usuario: audituser, password: audituser)
Para acceder a la aplicación el usuario deberá loguearse.
16
Una vez logueado se accederá a la siguiente pantalla.
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
17
fecha/hora en la que finalizó su ejecución.
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 y Oracle.
Para habilitar esto asegurarse que el rol AuditStandardOperation tenga permisos
para realizar la actividad AuditQuery.ViewByUtl
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.
27
Personalización, y
configuraciones Avanzadas
28
PERSONALIZACIÓN Y CONFIGURACIONES AVANZADAS
K2BAudit Analyzer personalización
La aplicación K2BAuditAnalyzer puede ser personalizada, para adaptarla a las
necesidades del usuario. Acá 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.
29
•
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.
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
K2BAuditAnalyzer viene con un esquema de seguridad implementado por defecto. En
caso de querer personalizarlo pueden modificar el procedimiento
k2bisauthorizedactivitylist, para que implemente la seguridad que usted desee.
En tal caso será posible también borrar la estructura de seguridad manejada por el
sistema, esto es User, Role, UserRole, Activity, RoleActivity, Entity.
Si se tiene las K2btools instaladas puede usar el menú K2BTools Fast StartRemove
Security.
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.
30
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.
Por defecto
34
Nombre de los triggers a nivel de tabla
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,
35
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
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.
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>
GRANT SELECT ON V_$MYSTAT TO <usuario>
38
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:
C:\ProgramFiles\ARTech\GeneXus\GeneXusXEv1\Packages\K2BTools\Audit\Or
acle\
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: @” C:\Program
Files\ARTech\GeneXus\GeneXusXEv1\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
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.
41
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";
42
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:
43
// 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)
44
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 + ", ''), ']]]]><
