Introducción
El sistema de auditoría de Insurance Suite, es unos de los componentes mas complejos y completos de la plataforma, dado que todas las acciones que se realizan dentro de las aplicaciones deben ser auditables para cumplir con las regulaciones a las cuales se encuentran sujetas los organismos aseguradores como puede ser:
- ISO/IEC 27001.
- SOX (Ley Sarbanes-Oxley).
- Auditorías Internas como la de la super intendencia de seguros.
- En el caso de banca seguros, las regulaciones de BCRA. Otros.
- El siguiente gráfico describe los elementos principales del módulo de auditoría de Insurance Suite.
Capacidades de auditoría
El sistema de auditoría es extremadamente flexible y nos permite auditar cualquier componente de la plataforma, los elementos auditables pueden ser cualquier componente de software o configuración de la plataforma, por ejemplo:
- Servicios, clases, reglas.
- Configuración, parámetros, bases de datos.
- Procesos, eventos de los mismos.
- Componentes scheduled.
- Eventos de cambios en la configuración.
- Eventos de cambios en los sistemas de seguridad, parámetros de usuarios y perfiles de acceso.
El sistema de auditoría captura eventos mediante servicios asincrónicos que no interrumpen el normal funcionamiento de las operaciones de la plataforma, de esta manera sin penalizar la performance de la aplicación se puede capturar una gran cantidad de gama de eventos. Estos eventos luego se pueden clasificar en tipos y fuentes de orificación, de esta forma se pueden filtrar y organizar acorde a cualquier tipo de análisis.
Arquitectura
La arquitectura del módulo de auditoría se compone de tres grandes elementos:
- Servicios asincrónicos de captura de eventos y logs de auditoría.
- Servicios de persistencia de eventos.
- Servicios de consulta y explotación de eventos de auditoría.
Estos tres tipos de servicios, se encuentran en capas completamente abstraídas una de otras, lo cual permite tener diferentes tipos de mecanismos de persistencia según la plataforma donde se encuentre la aplicación la cual se describe en el capítulo siguiente. Todo estos servicios responden al siguiente modelo de objetos, tal como lo describe la imagen.
Cada evento de auditoría tendrá los siguientes atributos:
- Un identificador único para toda la plataforma.
- Claves de aplicaciones y canales que generaron dicho evento.
- Nivel de gravedad o importancia del evento generado, los mismos pueden ser configurados a medida para cada instancia.
- Tipo de evento generado, los mismos pueden ser configurados ad-hoc para cada instancia.
- Fecha y hora de generación del evento.
- Usuario que generó dicho evento.
- Clave del tipo de evento, esta última es muy útil para luego la segmentación y búsqueda de eventos desde herramientas de análisis.
- Descripción general del evento.
- Texto arbitrario del evento, con todo el mensaje o suceso, en el mismo se pueden incorporar documentos XML o JSON con mensajes de respuesta de otros componentes, etc.
Almacenamiento de auditoría
Como se mencionó anteriormente, el módulo de auditoría tiene la capacidad de insertar los eventos de la plataforma en más de un modelo de persistencia al mismo tiempo. A continuación se detallan algunos de los mecanismos de persistencia certificados y probados desde el módulo de auditoría.
Base de datos
Este es el sistema de persistencia de eventos por default, los mismos pueden ser dentro de la misma base de datos de la plataforma de Insurance Service Bus o en otra base de datos destinada sólo a almacenar eventos. En este caso el proceso de persistencia es mediante el mecanismo nativo de almacenamiento de datos de la plataforma, con la única diferencia el el mismo es completamente asincrónico, con lo que puede pasar un momento hasta que los eventos son físicamente escritos en las tablas correspondientes. Para aquellas plataformas con grandes volúmenes de datos, se deberán tener en cuenta el espacio que ocuparán las tablas y que la base de datos se encuentre sobre un sistema de persistencia de archivos en RAID donde la capacidad de escritura sea múltiple.
SysLog
Sistema de auditoría de plataformas Unix/Linux. El protocolo de SysLog está completamente descripto en el RFC: RFC 3164 – The BSD Syslog Protocol.
En el siguiente ejemplo se configura la plataforma para enviar toda la información al “Facility”—> “local0” del servicio syslog/rsyslog. En el caso del ejemplo se encuentra en la misma máquina donde está la plataforma corriendo, utilizando UDP en el puerto 514. Para esto se deberá configurar el archivo logging.properties de la plataforma, por ejemplo:
handlers= java.util.logging.ConsoleHandler, com.sysone.isb.syslog.SyslogHandler
.level= FINEST
# Console handler configuration
java.util.logging.ConsoleHandler.level = FINEST
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
# Syslog logger
com.sysone.isb.syslog.SyslogHandler.transport = udp
com.sysone.isb.syslog.SyslogHandler.facility = local0
com.sysone.isb.syslog.SyslogHandler.port = 514
com.sysone.isb.syslog.SyslogHandler.hostname = localhost
Para indicarle a la virtual machine de java que utilice esta configuración específica se deberá iniciar el contenedor con la siguiente configuración.
-Djava.util.logging.config.file=logging.properties
Para configurar Rsyslog / Syslog por ejemplo en Debian o Ubuntu se deberá modificar el archivo /etc/rsyslog.conf
$ModLoad imudp
$UDPServerRun 514
Las reglas de logueo son configuradas en el archivo que se encuentra en el directorio /etc/rsyslog.d, se deberá crear el archivo 60-java.conf y configurar la regla. Por ejemplo.
local0.* /var/log/isb.log
En esta caso toda la auditoría irá al archivo isb.log, para obtener mayor performance en el sistema de auditoría se podrá adicionar el caracter “-” antes del nombre del archivo. Lo que hace este modificador es inhabilitar la sincronización de envío de registros al archivo, en este caso puede pasar un tiempo ante que los eventos sean visibles en el archivo.
local0.* -/var/log/isb.log
En el caso de utilizar opciones avanzadas como puede ser el transporte de TCP para Syslog, se podrá utilizar la siguiente opción.
com.sysone.isb.syslog.SyslogHandler.transport = tcp
Log de Eventos
También la plataforma posee la capacidad de escribir en el sistema de manejo de eventos de Windows. Todos los eventos son escritos en el Log de Aplicaciones. Para mas información ver https://github.com/javabrett/wel4j