Dinámica El framework RADical J2EE sin complicaciones. Biblioteca Técnica: audit logs Control declarativo de trazas de auditoria con Dinámica

Transcripción

1 Biblioteca Técnica: audit logs Control declarativo de trazas de auditoria con Dinámica Última actualización: Requiere framework v2.1.4 release 2008/09 en adelante Contenido Sumario...2 Requerimientos...2 Descargas...2 Incorporando traza de auditoría a un Action...3 Antes de comenzar - soporte de base de datos...3 Configuración del Action...3 Interacción con base de datos...6 Administración de la auditoria...7 Descripción del mecanismo genérico...9 Biblioteca técnica Página 1 de 9

2 Sumario Este documento explica como de manera declarativa se pueden grabar trazas de auditoria completas, usando facilidades del framework Dinámica. Unos simples parámetros de configuración en el archivo config.xml de un Action permiten dejar información útil para el seguimiento en una tabla específica del esquema de seguridad. Adicionalmente, la consola administrativa de seguridad que incluye Dinámica permite revisar estas trazas usando filtros de búsqueda flexibles, y los resultados pueden ser exportados a PDF o Excel. Incluye también un reporte especial de tipo histograma estadístico, que permite comparar la cantidad de operaciones de cierto tipo realizadas por cada usuario. La traza que se genera es multi-aplicación, como todo el esquema de seguridad. El soporte de Dinámica para la generación y manejo de trazas de auditoria es completo y fácil de implementar, viene listo para usarse de fábrica. Requerimientos Se asume que tiene experiencia básica con Dinámica, Tomcat, Eclipse y Java, y específicamente con aplicaciones seguras en Dinámica. Lo mejor para practicar el uso de trazas de auditoria es crear un esquema de seguridad limpio usando los últimos scripts de seguridad, y las últimas versiones del Admin y de los templates del framework. Luego es simple cuestión de montar un template y modificar el config.xml de uno de los Actions para que deje la traza de seguridad, suponiendo que se trata de una aplicación segura, de lo contrario no funcionará. Descargas El paquete de seguridad de Dinámica: El último repositorio de Dinámica: Biblioteca técnica Página 2 de 9

3 Incorporando traza de auditoría a un Action Antes de comenzar - soporte de base de datos Su esquema de seguridad debe contener la secuencia seq_auditlog y la tabla s_auditlog, si está usando un esquema anterior a septiembre del 2008, existe un PATCH para actualizar su esquema, si parte de cero, los scripts actuales de seguridad ya contienen todo lo necesario. La estructura de la tabla es esta: CREATE TABLE "security".s_auditlog ( auditlog_id bigint NOT NULL, -- ID del registro de auditoria operation character varying(50) NOT NULL, -- Operación realizada area character varying(50) NOT NULL, -- Descripción de la tabla afectada target_table character varying(50) NOT NULL, -- Nombre de la tabla userlogin character varying(25) NOT NULL, -- Identificación del Usuario extra_info character varying(1000) NOT NULL, -- Descripción de la operación realizada op_date date NOT NULL, -- Fecha de ejecución de la operación op_time character varying(15) NOT NULL, -- Hora de ejecución de la operación en formato 24hrs pkey integer NOT NULL, -- Clave primaria del registro context_alias character varying(20), -- Alias de seguridad del contexto o aplicación web CONSTRAINT auditlog_pkey PRIMARY KEY (auditlog_id) ) Básicamente se almacena qué operación, quien, cuándo y sobre que elemento se llevo a cabo. En cuanto a la operación, es importante distinguir en qué aplicación se ejecuto, y además el framework permite indicar dos campos más, cuyo contenido es definido por el programador de acuerdo a como quiere registrar la operación: target_table para indicar la tabla afectada, esto es para tener una referencia directa hacia la base de datos, y area, que puede servir para indicar en qué modulo se ejecutó la operación, algo como Resoluciones, Ordenes de Compra, Clientes, etc. Es algo más de negocio que target_table. El campo extra_info. Configuración del Action Dado un Action para el cual se quiere dejar una traza de auditoría, se debe modicar su config.xml para añadir algunos elementos específicos de la auditoría, y también para indicarle que su clase Transaction no será dinamica.generictransaction ni dinamica.generictablemanager, sino esta: Biblioteca técnica Página 3 de 9

4 dinamica.audit.auditabletransaction Esta clase extiende a GenericTableManager, por lo tanto sirve para sustituir a ambas. Si tiene una clase Transaction particular y quiere añadir el soporte de auditoría, extienda a esta nueva clase, es lo mismo que extender a GenericTransacion o GenericTableManager. En el ejemplo que sigue vamos a añadir una traza a un Action que ejecuta un INSERT en una tabla de la base de datos. En amarillo se resalta lo que se añade al config.xml. <?xml version='1.0' encoding='iso '?> <config> <summary> Producto - Insertar registro </summary> <log>false</log> Usualmente se usan los campos que vienen en el request, pero podría ser un recordset distinto, configurado en el config.xml. <!--soporte de auditoria--> <audit> <!--de donde saca los datos, por defecto es "_request"--> <recordset></recordset> <!--que campos extrae para el registro descriptivo--> <cols> <colname>productname</colname> </cols> <!--datos informativos--> <table>products</table> <oper>añadir</oper> <area>productos</area> Aquí indicamos lo que estamos haciendo y en qué área del negocio. Esto va dentro del campo extra_info, algo que identifique el registro afectado. <!-- query para obtener el ID generado o nombre de la columna que contiene el pkey, si es query, el alias del campo debe ser "id" --> <pkey>select currval('demo.seq_product') as id</pkey> </audit> <!--fin soporte auditoria--> Como es un INSERT necesitamos obtener el ID generado para su PKEY usando un SELECT especial, si fuera un UPDATE o DELETE ya vendría como parte del request. Biblioteca técnica Página 4 de 9

5 <transaction> <classname>dinamica.audit.auditabletransaction</classname> <validator>true</validator> <transaction>false</transaction> <jdbc-log>false</jdbc-log> </transaction> <query>insert.sql</query> <output> <classname>dinamica.genericoutput</classname> <template>message.htm</template> <set-http-headers>true</set-http-headers> <content-type>text/html</content-type> <expiration>0</expiration> </output> Se debe usar una clase genérica especial, o una propia que extienda a esta clase. </config> Como se puede observar no es necesario escribir nada de código para incorporar soporte de trazas de auditoria, solamente hay que configurar el Action y pensar bien los valores que se pondrán dentro del archivo config.xml, particularmente lo que decida poner como operador o área, ya que eso le añadirá valor de contenido a las trazas de auditoria, haciéndolas mas reveladoras al momento de ejecutar consultas contra esta data. Biblioteca técnica Página 5 de 9

6 Interacción con base de datos La traza se grabará utilizando el pool de conexiones del sistema de seguridad, que está definido en el Filtro de seguridad en web.xml, y debe estar configurado en el archivo /META- INF/context.xml de su aplicación. En muchos casos puede ser el mismo pool de la base de datos del negocio. En general las tablas de seguridad tendrán su propio esquema distinto al negocio (se recomienda) aunque compartan la misma BD, este esquema se define en el archivo web.xml: <context-param> <param-name>security-schema</param-name> <param-value>security</param-value> <description> Default security schema if any is being used; otherwise leave empty </description> </context-param> Si la traza se graba en una BD SQLServer o MySQL, la clase AuditableTransaction necesita saberlo, y es informada mediante un parámetro en web.xml: <context-param> <param-name>audit-sqlserver</param-name> <param-value>false</param-value> <description> Indica si la traza de auditoría se debe grabar usando SQL compatible SQLServer/MySQL </description> </context-param> Por defecto funciona para PostgreSQL, Oracle o MaxDB (bases de datos que usan SEQUENCEs), pero si pone el parámetro en true funcionará con SQLServer. Al usar una conexión de BD y esquema distinto al del negocio, la operación que graba la traza en BD no formará parte de la transacción JDBC del Action, si es que tiene una transacción activada, ya que van por conexiones distintas. La grabación de la traza de auditoría ocurre cuando ya se ejecutó exitosamente el método service() de la transacción, de lo contrario no ocurre. Y podría pasar que el método service() se ejecute bien, pero falle la grabación de la traza, en este caso, si no se usaban transacciones JDBC, las modificaciones hechas por el método service() a la BD no serán revertidas. Biblioteca técnica Página 6 de 9

7 Administración de la auditoria La consola administrativa de seguridad que incluye Dinámica tiene dos módulos para consultar las trazas de auditoria. Uno de los módulos es una consulta con filtro de búsqueda bien completo que permite ubicar las operaciones combinando varios parámetros de búsqueda. El resultado de la consulta puede ser exportado a PDF o Excel. Biblioteca técnica Página 7 de 9

8 El otro módulo es un histograma, un gráfico de una distribución absoluta de operaciones de cierto tipo por usuario, y resulta útil para comparar parámetros de productividad, más que de auditoria necesariamente. Por ejemplo puede servir para visualizar entre dos fechas cuantas planillas u órdenes de compra se han ingresado por transcriptor, mediante una simple manipulación del filtro de búsqueda. El resultado de esta consulta puede ser exportado a PDF para una impresión de calidad. Solo los usuarios autorizados para operar la consola administrativa de seguridad tienen permiso para ejecutar las consultas de auditoria. Biblioteca técnica Página 8 de 9

9 Descripción del mecanismo genérico Desde hace varios años que el framework Dinámica incorporó una interfaz llamada dinamica.iservicewrapper, que permite que una clase Transaction implemente esta interfaz para añadir código que será ejecutado por el Controller antes y después de ejecutar el método service() de la clase Transaction en cuestión. Esta interfaz sirve de base para todo el soporte de auditoria declarativa que viene de fábrica con Dinámica. El diagrama a la derecha es un modelo de la documentación original que hicimos sobre esta facilidad en el año 2005, aun es útil y vigente para entender el mecanismo. El Controller de Dinámica, que intercepta todos los requests y es pieza central y fundamental del framework, se encarga de averiguar si la clase Transaction a ser utiliza en el request en curso implementa esta interfaz. De ser así procede a invocar el método beforeservice(), luego el método service() de la clase Transaction, y por último si no hubo error- ejecuta el método afterservice(). La definición de la interfaz es muy sencilla: public interface IServiceWrapper { } public void beforeservice(recordset inputparams) throws Throwable; public void afterservice(recordset inputparams) throws Throwable; Apoyándonos en este mecanismo, se creó la clase dinamica.audit.auditabletransaction, que pasaría a ubicar el lugar de la clase YourBusinessObject en el diagrama. Su declaración es así: public class AuditableTransaction extends dinamica.generictablemanager implements IServiceWrapper El código fuente de esta clase está contenido en los fuentes del framework, disponibles libremente en dinamica-repository.zip, si quiere ver en detalle la implementación de esta clase. Biblioteca técnica Página 9 de 9