Embed Size (px)
Citation preview
Manual de usuario K2BAudit
Versión 3.5
2
Í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 ______________________________________30
Configuraciones generador: ____________________________ 31
Configuraciones avanzadas ____________________________ 32
Seleccion de DBMS ______________________________________________32
Nombre de los procedimientos______________________________________32
Nombre de los triggers ___________________________________________33
Nombre de los triggers a nivel de tabla _______________________________33
Actualización de descripción de atributos _____________________________34
Selección de atributos a auditar ____________________________________34
Anexo 1: Configuración Auditoría en el DBMS ______________________ 37
MySQL _____________________________________________ 37
Oracle _____________________________________________ 37
Permisos de Usuario _____________________________________________37
Carga de paquete ________________________________________________38
SQL Server __________________________________________ 38
3
DB2 _______________________________________________ 40
Anexo 2: K2B Audit Analizer ___________________________________ 41
Transacciones de auditoria _____________________________ 41
Anexo 3: Extensión de la auditoría _______________________________ 42
4
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 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.
5
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.
6
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.
7
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:
8
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
$(GeneXusXEv2InstalationDir)/Packages/K2BTools/Audit/K2BAuditAnalyzer.xpz si no usa K2BTools. Si usa K2BTools le recomendamos consolidar el archivo $(GeneXusXEv2InstalationDir)/Packages/K2BTools/Audit/K2BAuditAnalyzerK2BTools.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.
9
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.
10
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.
11
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
12
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í acceder 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.
-------------------------------------------------------------------------------------------
13
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 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
14
Para el caso de tener DB2 como DBMS, utilice el procedimiento K2BSaveAuditUserAfterConnectDB2.
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.
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.
15
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.
16
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.
17
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
18
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.
19
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.)
20
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
21
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.
22
23
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”.
24
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.
25
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.
26
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.
27
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.
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. 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.
• 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 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 Start�Remove 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.
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.
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\Oracle\ 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
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”
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 Descripción
AuditLoad 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.
AuditTable Para cada tabla auditada, guarda el código de los triggers asociados.
AuditEntity Almacena información de la entidad auditada AuditEntityTable Establece la relación entre las tablas auditadas y la
entidad auditada. AuditQuery Los datos de AuditLoad se cargan aquí cuando se
ejecuta la transformación para explotación. AuditQueryLog 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.
AuditUser Almacena datos del usuario que realiza las operaciones.
AuditAttribute Almacena los atributos que se modifican en las operaciones
AuditTableAttribute 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%>,']]]]><
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 + ", ''), ']]]]><
