ATLAS MANUAL DE USUARIO SERVICIO DE AUDITORIA

Transcripción

1 ATLAS MANUAL DE USUARIO SERVICIO DE AUDITORIA Versión 1.3 Área de Aplicaciones Especiales y Arquitectura de Software

2 Hoja de Control Título Documento de Referencia Responsable Manual de Usuario Servicio de Auditoría NORMATIVA ATLAS Área de Aplicaciones Especiales y Arquitectura de Software Versión 1.3 Fecha Versión 27/02/2012 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 1.0 Versión inicial del documento Área de Integración y Arquitectura de Aplicaciones 26/05/ Apartado El atributo atlas.audit.console_output se parametriza por entorno. Nuevo apartado para nuevo parámetro auditoria.desactivar. 1.2 Se han modificado los estilos de los apartados y eliminado algún error tipográfico Área de Integración y Arquitectura de Aplicaciones Área de Aplicaciones Especiales y Arquitectura de Software 02/11/ /02/ Se modifica el nombre del Area Área de Aplicaciones Especiales y Arquitectura de Software 21/09/ de 14

3 Índice 1 INTRODUCCIÓN AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS DESCRIPCIÓN INSTALACIÓN Y CONFIGURACIÓN INSTALACIÓN Inclusión de dependencia en fichero pom.xml CONFIGURACIÓN Configuración fichero applicationcontext-database.xml Configuración fichero environment.properties USO DEL SERVICIO DE AUDITORIA CLASE AUDITABLEIMPL COMPROBACION DE QUE LAS TRAZAS SE INSERTAN CORRECTAMENTE RECOMENDACIONES Y BUENAS PRACTICAS ENLACES RELACIONADOS de 14

4 1 INTRODUCCIÓN Los Sistemas de Información de la Comunidad de Madrid en algunos casos tratan datos de carácter personal que son especialmente protegidos por la Agencia de Protección de Datos. En estos casos es obligado que se recoja información sobre los accesos realizados a dichos datos. El de Atlas se encarga de auditar los accesos mencionados anteriormente. Para ello es necesario que la aplicación indique cuáles son aquellos datos susceptibles de ser auditados, basándose en los mecanismos que ofrecen los framework s Spring e Hibernate. El intercepta todas las operaciones de base de datos que se realizan a través de Hibernate y deja el registro de la auditoria en el esquema TRAZ a través del paquete de base de datos ATLAS.PACK.LOG. 1.1 Audiencia objetivo Este documento está dirigido a desarrolladores de proyectos java para ICM en los que se desee incorporar una auditoria de los datos de ciertas tablas. Esta auditoria incluye información sobre todos los movimientos realizados en las tablas auditadas. 1.2 Conocimientos Previos Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes tecnologías: - Spring Framework. - Hibernate - Bases de datos Oracle 4 de 14

5 2 DESCRIPCIÓN El de Atlas esta diseñado para evitar al desarrollador la labor de auditar los datos sensibles que se almacenan en su aplicación. De esta forma y bajo una configuración sencilla el programador tendrá que marcar sus entidades de Hibernate como entidades auditables y el se encargará de recuperar la información necesaria para su inserción en base de datos. A la hora de indicar qué entidades son susceptibles de ser auditadas, el programador se encuentra con 2 opciones: Utilización de la anotación AtlasAuditable Heredando de la clase AuditableImpl Aunque las dos alternativas son válidas se recomienda el uso de la primera. La utilización de la segunda debe ser consensuada previamente con ICM. Posteriormente en el apartado Uso del Servicio de Auditoría se indicará como utilizar cada una de las alternativas. A continuación se muestra una tabla con los datos que se pueden pasar al de Atlas para que queden reflejados en el registro de auditoria de seguridad. Los campos tienen un tamaño máximo, en caso de superar dicho tamaño el campo será truncado. Atención Sólo los campos codaplicacion y cdtpaccesologico son necesarios, el resto de campos son opcionales. Propiedad Descripción Tamaño Max codaplicacion Código con el que se da el alta del proyecto en POAPS. 12 dsfichlogico Nombre del fichero inscrito en el registro de la APD 40 cdtpaccesologico cdproceso Tipo de Acceso al fichero lógico. I -> Individual M -> Acceso Masivo Valor que identifica la operativa que desencadena la generación de la traza. Ej. ALTSINDC, APLS0011 etc. Este código debe ser el mismo que: se defina en el Análisis Funcional se implemente en la Plantilla de Requerimientos SGUR para la identificación de Etiqueta Fichero de 14

6 dsproceso cenprop cendir Descripción de la operativa que desencadena la generación de la traza Ej. Alta de interviniente, Consulta de empleado con sindicato Código de Centro Directivo, Órgano Judicial, Departamento, etc al que pertenecen los datos sobre los que se realiza el proceso. Código de Centro Directivo, Órgano Judicial, Departamento, etc., al que pertenece el usuario que realiza el acceso a los datos de Nivel Alto. En el supuesto de que el valor de este atributo no esté embebido en el código de la aplicación se deberá proceder del siguiente modo: 1. Definir el código en la fase de Análisis Funcional 2. Incluir en este atributo el valor genérico definido en la fase de análisis o el correspondiente al Centro Directivo Propietario. En el segundo caso, el Responsable Funcional que revise la trazabilidad debe saber que el control habilitado para identificar usuarios que acceden a datos de otros centros no estará disponible en SGUR dsoserv Observaciones 255 Algunos parámetros que se indican en el registro de la auditoria son constantes para toda la aplicación, entonces se pueden definir en el bean auditconstants tal y como se indicará posteriormente. Hay que tener en cuenta por otra parte que habrá aplicaciones que accedan a modelos de datos ya existentes en los cuales hay implementado un mecanismo de triggers para el registro de la auditoria (mecanismo utilizado en otros frameworks). Por lo tanto es posible configurar el Servicio de Auditoría de Atlas para que de forma transparente puedan seguirse utilizando dichos triggers y el Servicio de Auditoría sea capaz de auditar solamente las consultas ya que estas no son auditadas a través de los triggers. 6 de 14

7 3 INSTALACIÓN Y CONFIGURACIÓN Los arquetipos no incluyen este servicio instalado por defecto. Por lo tanto aquellas aplicaciones que lo requieran tienen que realizar los siguientes pasos para poder utilizar el servicio correctamente: 3.1 INSTALACIÓN Inclusión de dependencia en fichero pom.xml Añadir en nuestro fichero pom.xml en la etiqueta <dependencies> la siguiente dependencia: pom.xml <dependency> <groupid>atlasfrm</groupid> <artifactid>atlasfrm-auditoria-lib</artifactid> <version>${atlasfrm-auditoria-lib.version}</version> </dependency> Nota Si hemos partido de un arquetipo web, esta dependencia ya se encuentra comentada en el fichero pom.xml del módulo padre, es suficiente con descomentarla. 7 de 14

8 3.2 CONFIGURACIÓN Configuración fichero applicationcontext-database.xml Debemos definir en el fichero applicationcontext-database.xml un nuevo bean con las constantes por defecto que se utilizarán para la auditoría. A este bean se le puede incluir como propiedad cualquiera de las propiedades de la tabla de propiedades del registro de auditoria. (En el caso de los test en necesario incluirlo también en el applicationcontext-database-test.xml ) A continuación se muestra un ejemplo de definición de este bean. applicationcontext-database.xml <bean id="auditconstants" class="atlas.audit.properties.auditconstants"> <property name="codaplicacion" value="ejpl"/> <property name="cdtpaccesologico" value="i"/> </bean> Dentro del bean sessionfactory de Hibernate obligatoriamente se definirá la propiedad de configurationclass con el valor atlas.audit.hibernate.cfg.annotationconfiguration. Existe además un parámetro que se le puede pasar a la configuración del sessionfactory para cambiar el comportamiento de la auditoria: atlas.audit.triggers: Existen bases de datos anteriores al framework Atlas en las que la auditoria se realiza a través de triggers de base de datos (no utilizando Hibernate). En este caso (en el que existen triggers para auditoria de altas, bajas y modificaciones) este parámetro deberá tener el valor true, para que solo se auditen las consultas (en Oracle no existen triggers para consultas). Nota El parametro atlas.audit.triggers no debe modificarse en el fichero applicationcontext-database.xml. En su lugar se modificará el atributo auditoria.desactivar en environment.properties. A continuación se muestra un ejemplo de configuración del bean sessionfactory en el que se marcan en rojo aquellos cambios necesarios para que funcione el. applicationcontext-database.xml 8 de 14

9 <!-- Hibernate SessionFactory Definition --> <bean id="sessionfactory" class="org.springframework.orm.hibernate3.annotation.annotationsessionfactorybean"> <description> Bean que representa a la factoria de hibernate para crear sesiones con base de datos </description> <property name="configurationclass"> <value>atlas.audit.hibernate.cfg.annotationconfiguration</value> </property> <property name="schemaupdate"> <value>false</value> </property> <property name="annotatedclasses"> <list> <value>atlas.core.bo.calendar.impl.festivoimpl</value> </list> </property> <property name="hibernateproperties"> <props> <prop key="hibernate.dialect">${hibernate.dialect}</prop> <prop key="hibernate.show_sql">true</prop> <prop key="hibernate.format_sql">false</prop> <prop key="hibernate.use_sql_comments">false</prop> <prop key="atlas.audit.triggers">false</prop> <prop key="atlas.audit.console_output"> ${auditoria.desactivar}</prop> </props> </property> <property name="datasource" ref="datasource" /> </bean> Nota Si hemos partido de un arquetipo web, en el fichero applicationcontext-database.xml ya se encuentran realizadas estas configuraciones, aunque se encuentran comentadas. Es suficiente con descomentarlas Configuración fichero environment.properties En el fichero environment.properties se puede configurar el siguiente parámetro: auditoria.desactivar: Cuando este parámetro toma valor true, el modulo de auditoría no ejecutará las llamadas a los procedimientos de base de datos que dejan la información en el modelo de datos de SGUR. En vez de eso enviará una traza a consola con la información de la traza. La traza vendrá a nivel INFO. Además saldrá una traza de error en la que se indica que este parámetro no debe llegar al entorno de producción. Este parámetro se debe utilizar en los casos en los que el proveedor está desarrollando en sus instalaciones y no tiene el modelo de datos de SGUR. 9 de 14

10 4 USO DEL SERVICIO DE AUDITORIA En el desarrollo de nuestra aplicación y a la hora de crear nuestras entidades es cuando tenemos que identificar aquellas susceptibles de ser auditadas e indicárselo al. Esto se puede hacer de dos formas distintas: Anotando la entidad mediante la Haciendo que la entidad extienda de la clase AuditableImpl A continuación se explican las 2 opciones y los casos de uso recomendados para cada una. 4.1 Al anotar una entidad indicamos que esa entidad va a ser auditada por el Servicio de Auditoria, esto es, cualquier operación sobre BBDD en la que esté involucrada esta tabla, se creará el correspondiente registro de auditoria en la tabla del esquema TRAZ. A la se le pueden pasar los parámetros indicados en la tabla de propiedades del. Cogerá los valores por defecto definidos en el bean auditconstant y sobrescribirá aquellos específicos de esta entidad que se definan en la etiqueta. Ejemplo de una entidad anotada con AtlasAuditable Import = de Provincias", cdproceso="proc01", dsproceso="proceso DE LOCALIZACION CLIENTE") public class SucaProvincia implements java.io.serializable{ } private SucaProvinciaId id; private String dsprov; private BigDecimal nmprov; private BigDecimal prefijotf; private String matricula; private String matricula2; private Set<SucaMunicipio> sucamunicipios = new HashSet<SucaMunicipio>(0);. Es necesario verificar que nuestras clases susceptibles de auditoría están en la lista de clases anotadas dentro del parámetro annotatedclasses del fichero en applicationcontext-database.xml: 10 de 14

11 4.2 CLASE AuditableImpl Otra opción para indicar que una entidad desea ser auditada es definir que esta entidad herede de la clase atlas.audit.hibernate.interceptor.auditableimpl. El uso de esta solución debe ser previamente autorizado por ICM. Esta clase esta compuesta por una serie de getters y setters de la información adicional auditable, y todos sus atributos, a excepción de cdclave y cdclavevalor, tienen por defecto los valores configurados en el bean auditconstants (Véase punto Configuración del fichero applicationcontext-database.xml). Este tipo de implementación es la recomendada cuando la etiqueta no nos da la suficiente flexibilidad. Toda clase que extienda de atlas.audit.hibernate.interceptor.auditableimpl debe tener, obligatoriamente, un constructor público sin argumentos. La forma mas común de uso es sobreescribir los métodos de AuditableImpl de los que necesitamos cambiar el comportamiento. A continuación se muestra un ejemplo de definición de entidad que hereda de la clase AuditableImpl: Clase = "SUCA_MUNICIPIO") public class SucaMunicipio extends AuditableImpl implements java.io.serializable public String getcdclave() { return "cdmuni"; public String getcdclavevalor() { return this.getid().getcdmuni(); } } Otro ejemplo de uso de esta entidad añadiéndole la información adicional en ejecución sería la siguiente: Clase ejemplo: SucaMunicipio.java 11 de 14

12 @Test public void testsaveprovincia() SucaProvincia prov=new SucaProvincia("ESP","12","28"); prov.setmatricula("m"); prov.setcdproceso("proc_01"); prov.setdsproceso("proceso TEST SAVE PROVINCIA"); prov.setprefijotf(new BigDecimal(91)); prov.setdsprov("madrid"); gethibernatetemplate().save(prov); } 4.3 COMPROBACION DE QUE LAS TRAZAS SE INSERTAN CORRECTAMENTE Para comprobar que la configuración de auditoria es correcta y que la aplicación esta enviando trazas al esquema de TRAZ deberemos conectarnos con algún cliente de base de datos a nuestro esquema y ejecutar la siguiente consulta para comprobar si obtiene resultados: Consulta a base de datos Select * from dba_traz.traz_log_accesos where cod_aplicacion='nombre-aplicación' order by fcacceso; Donde hay que sustituir nombre-aplicación por lo que contenga el parámetro codaplicacion del bean auditconstants. En caso de no obtener resultados marcar el parámetro atlas.audit.console_output = true para ver en el log de la aplicación las trazas que se están mandando al proceso de base de datos. Si no aparecen dichas trazas, habrá que revisar la configuración de atlas-audit. De persistir el problema póngase en contacto con su administrador de base de datos para que compruebe que el pipe de base de datos de TRAZ este funcionando. 4.4 RECOMENDACIONES Y BUENAS PRACTICAS 1. Entorno de proveedor: Durante el desarrollo de la aplicación en el entorno del proveedor se recomienda el uso del parámetro atlas.audit.console_output = true (vease el punto 3.2) para que el proyecto no emita errores al no poder acceder al catálogo de base de datos TRAZ. Cuando el proyecto pase a un entorno de integración habrá que poner este parámetro a false. 2. Configuración básica: Se recomienda el uso de la en las entidades, que junto con la configuración del bean auditconstants en la base de datos proveerá un comportamiento sencillo de auditoría. 12 de 14

13 3. Uso de triggers: Se debe comprobar si nuestro esquema tiene triggers para auditoría antes de realizar la configuración de este servicio. En caso de tenerlos con añadir el siguiente parámetro bastaría para configurar su uso: atlas.audit.triggers=true (vease el punto 3.2). 13 de 14

14 5 ENLACES RELACIONADOS Producto Lenguaje Java Extensible Markup Language (XML) Spring Framework Spring Security Maven Hibernate URL de 14