“Gestión de Registros y Respaldos en el Contexto Hospitalario”

Presentación del tema: "“Gestión de Registros y Respaldos en el Contexto Hospitalario”"— Transcripción de la presentación:

1 “Gestión de Registros y Respaldos en el Contexto Hospitalario”
Estudiantes: Martín Calabria Gonzalo Perretti Tribunal: Supervisores: Responsables: Andrés Aguirre Lorena Etcheverry Antonio Mauttone María Eugenia Corti Ariel Sabiguero Julio Carrau Gustavo Perez

2 Agenda Presentación Marco Conceptual Sistemas de Respaldo
Sistemas de Registros Gestión del Proyecto Demo Extensiones y Trabajo a Futuro Conclusiones Presentación El contexto donde se realizo el proyecto. Describiremos el problema de los clientes y que se pretende solucionar. Objetivos que nos planteamos al estudiar el problema. Marco Conceptual Que envolvía al proyecto, tanto tecnologías como perfiles y estándares Sistema de Respaldos y Registros Estudio de la situación actual de las herramientas que atacan el problema planteado. Solución que implementada para cumplir los objetivos establecidos. Gestión del Proyecto Breve descripción de la utilización de los tiempos durante el desarrollo del proyecto. Demo Expondremos el sistema desarrollado y sus funcionalidades. Extensiones y Trabajos Futuros Mencionaremos mejoras que se le pueden realizar al trabajo realizado. Conclusiones Del trabajo realizado, de las lecciones aprendidas y la experiencia personal luego de finalizado el proyecto

3 Contexto Hospital de Clínicas Dr Manuel Quintela
DPI (División de Procesamiento de la Información) Facultad de Ingeniería UdelaR INCO (Instituto de Computación) DPI: Administración y funcionamiento de todo la infraestructura informática del HC. Mejora continua de los niveles de calidad y eficacia de las distintas áreas de actividad del Hospital mediante el uso de tecnologías de la información.

4 Objetivos Sistema Registros Sistema Respaldos
Investigación de estándares relativos al registro de eventos Creación de un mecanismo de registro de eventos que opere dentro del Hospital, respetando los estándares y perfiles de seguridad existentes Creación de una interfaz para disponer de una auditoría efectiva de los eventos registrados Sistema Respaldos Actualización de los mecanismos de respaldo existentes en el Hospital. Estudio de herramientas de respaldos existentes, elección de la que mejor se adecua a la infraestructura del Hospital. Sistema Registros: Standards seguridad y formato de registros vinculados al área de la salud . Creación de un sistema para operar en el HC y que respete dichos estándares. Implementación de una interfaz para disponer de una auditoría de los eventos registrados. Sistema Respaldos: Actualmente solo se respaldo Windows usando VSS, pero también poseen servidores Linux que están desprotegidos.

5 Descripción del Problema (1/2)
¿Cuál es la importancia del registro y auditoría de eventos? ¿Cómo se puede implementar? ¿Cuáles deben ser las características de la solución implantada? ¿Qué beneficios brinda? ¿Qué problemas se deben enfrentar? ¿Cual es la importancia del respaldo de información? ¿Qué herramientas permiten automatizarlo? Importancia: Determinar si existen fallas de seguridad y manipulación no autorizada de datos del paciente. Rastrear acciones y realizar seguimiento de usuarios. Implementación: Estado del arte de Herramientas existentes y como integrarlas. Características: Beneficios: Automatización del registro de eventos en una red de computadores. Qué usuarios y sistemas se benefician. Problemas: Integración con otros sistemas, integración de las herramientas. Transporte de mensajes y seguridad. Respaldos: Qué info es necesario respaldar (archivos de usuarios, base de datos, etc), en dónde se encuentra y hacia dónde se respaldara (cinta, disco, etc). Herramientas de automatización que faciliten la tarea, por ejemplo permitiendo planificar respaldos con cierta periodicidad.

6 Descripción del Problema (2/2)
Carencia de un mecanismo que permita registrar y auditar eventos de manera: Remota Centralizada Segura Eficiente Estandarizada Necesidad de actualizar el mecanismo de respaldo a un sistema: Multiplataforma Centralizado Que facilite la ejecución y restauración de respaldos Remota Que permita ser utilizado por todos las nodos de la red hospitalaria. Los administradores puedan realizar la auditoria desde donde deseen. Centralizada. Ofreciendo un servidor que recepciones los eventos y permita la auditoria de los mismos ya que tenerlos separados complica tarea de administrador y auditor. No es suficiente monitorear logs de equipos por separado ya que los eventos se pueden relacionar. Segura. Implementado mecanismos de seguridad en el punto de acceso y en el servidor, respaldar la información. Eficiente. Sobre todo disponibilidad del sistema. Estandarizada. Basada en estándares de auditoría y seguridad facilita la tarea del personal. Único formato de log para todos los sistemas. Multiplataforma. Permita respaldar clientes Windows y Linux Centralizado. Disponer de un grupo reducido de servidores de respaldo para aumentar la productividad de los administradores. Facilite la Ejecución. Programador de tareas e interfaz grafica para realizar la administración del sistema. 6

7 Marco Conceptual - Perfil de Seguridad
Dominios IHE: Frameworks Técnicos Definen implementación de estándares Perfiles CT ATNA - Objetivos Auditoría de seguridad Control de acceso Local Comunicación entre nodos y repositorio de auditoría utilizando claves asimétricas Repositorio de auditoría centralizado Integridad de datos manejados IHE promueve utilización de estándares para lograr eficiencia y seguridad en la interoperabilidad de sistemas. IHE define dominios, los cuales se especializan en determinada área, identificando problemas de integración. Cada dominio tiene frameworks técnicos y perfiles que detallan una solución. Framework Técnico -> Detalla implementación de estándares, sirven para el testeo de dichas implementaciones. Los perfiles facilitan los aspectos de seguridad y interoperabilidad en el desarrollo del sistema . Define cómo un estándar puede ser implementado para satisfacer las necesidades hospitalarias. CT permite que los relojes de las pcs estén sincronizados y nos asegura que las fechas de creación de los logs en los distintos sistemas . ATNA Perfil de integración que define medidas de seguridad para proveer confidencialidad e integridad de los datos del paciente. Sirve como guía para la implementación de políticas de seguridad y privacidad. Solo unos pocos eventos son relevantes para auditar (los de bajo nivel no se tienen en cuenta).

8 Marco Conceptual - Estándares Investigados
WS-Security X.509 SSL IETF RFC 3881 HL7 DICOM XHTML WC3-XML CSS Syslog SOAP WSDL

9 Marco Conceptual - Mensaje de Auditoría (1/2)
Define la información que deberá contener un mensaje para su correcta auditoría Dos formatos de mensaje Mensaje de auditoría provisional IHE Radiología Mensaje de auditoría IETF con vocabulario DICOM-IHE Formato IETF RFC 3881 Identificación del Evento Información de las Fuentes Información de los Participantes Datos de los Pacientes Existen diversos formatos para el mensaje de auditoría, incluso se podría definir uno de acuerdo a las necesidades del hospital, pero no es lo correcto si queremos estandarizar la solución. Para lograr esto se utilizará alguno de los formatos definidos por el perfil ATNA. Estos son dos, el formato provisional IHE, que ya no tiene soporte, y el formato definido por IETF, HL7 y otros. Este formato se define en el documento RFC 3881 y tiene como objetivo establecer aquellos datos necesarios para lograr una correcta auditoria de seguridad. Fue definido en colaboración con HL7, DICOM y otros. DICOM aporta el vocabulario para los eventos. IHE recomienda este esquema ya que es extensible y permite representar la mayoría de los eventos requeridos. Aquellos que no puedan ser representados utilizando este esquema no deberían ser auditados. Las categorías de eventos son referentes a : Seguridad (identificación, autenticación), Cuidado del Paciente (qué, quién, cuándo, dónde), Administrativos (manejo de usuarios, roles).

10 Marco Conceptual - Mensaje de Auditoría (2/2)
EventDateTime en formato ISO.

11 Estado del Arte – Registro de Eventos
Windows Event Log Formato de registro fijo y no compatible con ATNA Cota máxima en tamaño de archivo de registro Registra eventos de infraestructura. Software Syslog Cota máxima en tamaño de mensaje de auditoría (1KB) Interfaz de auditoría no adecuada Limitaciones requerimientos de seguridad de ATNA OHF Eclipse Proporciona comunicación con servidor Syslog Implementa formato RFC 3881 Windows Event Log únicamente permite codificar eventos en C/C++, mientras que el HC maneja sistemas java. El formato es poco adecuado porque no permite incluir toda la info necesaria, y el contenido variable no sigue ningún formato estructurado lo cual dificulta mucho la implementación de búsquedas. La interfaz de auditoría permite filtrar por severidad, facilidad e identificador de evento. Syslog es un protocolo cliente servidor para envío de mensajes en redes IP. La cota máxima surge del hecho que syslog fue diseñado para registrar eventos puntuales como errores o fallas.

12 Estado del Arte - Sistema de Respaldos (1/5)
Requerimientos: Herramienta de código abierto Multiplataforma, principalmente GNU/Linux y Windows Permitir respaldar archivos de bases de datos en uso Interfaz gráfica para facilitar administración del sistema Otras Características Encriptación y compresión de datos Tipos de respaldo Planificador de tareas Respaldo de permisos de archivos Respaldo de archivos abiertos Buena documentación - Largo de los archivos

13 Estado del Arte – Sistema de Respaldos (2/5)
Bacula No AMANDA BackupPC Areca Backup Int. Gráfica Linux Windows Programa Acronis BackUp & Recovery EMC Legato NetWorker Prop. Código Abierto Resultados: Bacula cumple con todas las características especificas. Areca y BackupPC no respaldan bases de datos. AMANDA no poseen interfaz gráfica.

14 Estado del Arte – Sistema de Respaldos (3/5)
Características Bacula (1/2) 5 componentes: Director, Cliente, Almacenamiento, Consola y Monitor Servidor disponible únicamente para Linux Catálogo para almacenar la información de los archivos Tipos de respaldo: Completo, Incremental y Diferencial Encriptación de datos con claves asimétricas y comunicación sobre TLS Compresión de datos (Gzip) Integridad de datos (MD5, SHA1) Interfaz gráfica gnome, y varias interfaces web disponibles 1) 3 configurables -> Director (Consola, Monitor), Cliente, Almacenamiento. 2) Cátodo -> Bases postgresql, mysql, sqlite. 3) Tipo respaldo sintético en desarrollo. 4) Integridad de datos mediante MD5, SHA1 5) Compresión 0 – 9. 6) Webacula – Bweb - Brestore – Bat - bgnome-console

15 Estado del Arte – Sistema de Respaldos (4/5)
Características Bacula (2/2) Maneja nombres de archivos de largo arbitrario. Respaldo y restauración de ACLs de archivos. Respaldo de Base de Datos en Uso. Respalda sobre cinta, disco, usb, dvd. Programador de tareas con ejecución simultanea. Soporte para archivos mayores a 2G y arquitecturas de 64 bits. ACL para usuarios. Extensa documentación. Regeneración de la base de datos a partir de los volumenes.

16 Estado del Arte – Sistema de Respaldos (5/5)
Arquitectura Bacula Director -> Conoce los componentes, se autentica contra el resto, gestiona la lógica de los procesos de backup, non root (Catalogo -> MySQL, PostgreSQL y SQLite, guarda atributos e info de los respaldos) Cliente -> Encarga de empaquetar los archivos, envía la información directamente al almacenamiento, define que directores pueden respaldarlo, root Almacenamiento -> Maneja los dispositivos de almacenamiento e indica que directores pueden usarlo, non root Consola -> Propósito interactuar con el director -> bconsole, Webapps(Webmin, webacula, bweb, etc) o Gui (Bat, brestore) Monitor -> Permite al administrador o usuario visualizar el estado actual. Password de identificación encriptados.

17 Sistema Registros - Requerimientos
Repositorio de registros de eventos centralizado Formato único para el registro de evento Punto de acceso mediante servicios web Interfaz remota para auditoría Transporte confiable Autenticación del nodo y usuario emisor Sincronización del tiempo Documentación en formato ISO Repositorio centralizado para facilitar tareas de administración y auditoría de eventos. Por otro lado se tiene más seguridad con este esquema que con uno distribuido ya que el log reside en un único equipo. Deben tomarse las medidas de seguridad correspondientes (comentar un poco). El formato único debe seleccionarse de entre los posibles candidatos, realizando extensiones si fuera necesario. Esto ayuda al auditor en caso que desee ver los registros en formato xml y no a través de la interfaz de auditoría. Transporte confiable desde el cliente al servidor, esto requiere implementar seguridad en el cliente. También se implementó para comunicarse con syslog. La documentación incluye análisis, diseño, implementación, guías de instalación y configuración, y manuales de usuario.

18 Sistema Registros - Características (1/2)
Sistema de Registro de Eventos Soporte para formato IETF RFC 3881 Almacenamiento en base de datos Seguridad en el punto de acceso Mecanismo de trabajo asíncrono Interfaz de administración web Alertas vía mail Configuración del limite de almacenamiento Envío seguro a servidor syslog (TCP + SSL) Se brinda soporte para formato RFC 3881 mediante la implementación de una biblioteca, la cual es utilizada por el sistema. Se diseña un esquema de base de datos para almacenar todos los campos del evento y permitir realizar búsquedas por los mismos. Se implementó el mecanismo de seguridad bidireccional utilizando certificados, tal como especifica ws-security. El asincronismo permite que el sistema cliente pueda continuar con el procesamiento y obtener la respuesta mediante un hilo dedicado. La implementación se detalla en aspectos tecnológicos. La interfaz de administración incluye seguridad y control de acceso. Permite configurar todos los aspectos del sistema. Las alertas por mail pueden configurarse por severidad, facilidad y origen del evento. El limite de almacenamiento indica el tiempo que permanecerán los eventos almacenados en la base de datos. Esto es configurable, puede ser desde minutos a años. Los eventos se categorizan según su severidad.

19 Sistema Registros - Características (2/2)
Sistema de Auditoría de Eventos Visualización de eventos formato IETF Interfaz web Control de acceso Reportes Estadísticas Monitoreo Performance (paginado, filtros, ajax) Registro de Actividad

20 Sistema Registros - Tecnologías
Servidores Glassfish Tomcat PostgreSQL Syslog Watcher OpenDS Desarrollo Java EE 5 Generador Genexus Java ICEFaces Facelets Interacción Metro Hibernate JMS Ajax Otras Quartz Reportes iText Jxl Se decidió utilizar glassfish por los siguientes motivos: cumple estándar java EE completamente, posee interfaz de administración de calidad, menor tiempo de arranque y despliegue de aplicaciones. Jboss posee más documentación y es más utilizado, incluso el hospital tiene preferencia por él, por lo tanto se adapto una versión del aplicativo para que corra en Jboss Para esto se tomó como estrategía definir los aspectos configurables del sistema en archivos xml y no mediante programación (utilizando anotaciones). Mencionar sistemas operativos: Win XP, Vista, 7 y Linux Debian Lenny 5.

21 Sistema Registros - Tecnologías
Aspectos tecnológicos y seguridad Uso del contenedor EJB en la capa de servicios Mecanismo de registro asíncrono (JMS) Mecanismo de eliminación de eventos por prioridad Cacheo de recursos Mecanismo de autenticación “plug-in” Faces + JSF brinda servicio contra : Inyección SQL Cross site scripting

22 Sistema Registros - Arquitectura
La arquitectura es SOA dado el requerimiento de utilizar servicios web, ya que el hospital apunta a este mecanismo de comunicación e interoperabilidad (conectathon). Que sea distribuida favorece la performance y flexibilidad al momento de realizar cambios. Dependiendo del hardware disponible se debe seleccionar el escenario de deploy que mejor se ajuste.

23 Sistema Registros - Distribución
Los sistemas externos se comunican con el servicio web autenticándose contra el mismo. Esto ayuda a prevenir ataques de denegación de servicio. Cada sistema externo podrá mantener su archivo de log, pero deberá codificar el envío de aquellos eventos que se definan cómo necesarios. Los eventos son encolados para liberar al servicio web, aumentando la disponibilidad del mismo. Las interfaces tienen seguridad mediante SSL y utilizan un mecanismo de autenticación de usuario dinámico, es decir se puede cambiar de uno a otro en tiempo de ejecución, ej de base de datos a LDAP. Este diagrama muestra el máximo nivel de distribución posible, pero podrían encontrarse todos los módulos en un mismo servidor. Esto debe ser evaluado según la frecuencia de mensajes esperada y el hardware disponible. Es posible pasar de un motor de base de datos a otro en tiempo de ejecución ya que los mismos se configuran en el servidor de aplicaciones mediante datasources. En el diagrama alta envío confiable a servidor syslog y alertas mail.

24 Sistema Registros – Módulos Complementarios
Biblioteca para generación de mensajes Genera e interpreta mensajes en formato RFC 3881 Válida mensajes a partir de un esquema XML. Biblioteca para comunicación Lógica para comunicación con servicio web Asincronismo Configurable mediante archivos Biblioteca Genexus Encapsula la lógica de armado y envío del mensaje Facilita la tarea al desarrollador

25 Sistema Registros - Procesamiento del evento
Valida nodo emisor Valida mensaje Sistema Externo Sistema Registros Servidor Correo Servidor LDAP Verifica usuario Servidor Syslog Base de Datos Valida nodo emisor Interfaz Auditoría Auditor

26 Escenario de Pruebas Objetivos Ambiente
Ejecución de los sistemas en un ambiente de pruebas dentro del Hospital. Validación de la solución por parte del cliente Ambiente 2 Máquinas Virtuales con Debian Lenny 1 Máquina Virtual con Windows XP Windows 7 El caso de estudio se realizó usando 3 equipos de la red que actuaron como clientes. Un 4to fue utilizado como servidor de registros, teniendo una distribución mínima de los componentes. La información de los pacientes se tomaron de la base de datos del índice de pacientes, aplicando un algoritmo para mezclar las tuplas de manera de preservar la privacidad de los pacientes.

27 Caso de Estudio - Sistema Registros
Distribución de componentes Sistema Registro Eventos y Sistema de Auditoría en Debian Índice de Pacientes en Windows* Servidor LDAP y Syslog en Windows Ambas maquinas virtuales conectadas en red Ejecución Simulación de registro de eventos desde Índice de Pacientes

28 Caso de Estudio - Sistema de Respaldos
Ambiente utilizado Director, Almacenamiento, Catálogo y Cliente en Debian Cliente en Windows XP Ambas máquinas virtuales conectadas en red. Ejecución Respaldo de ACL en Debian Respaldo de Base de Datos en Windows

29 29

30 Gestión del Proyecto Tarea Inicio Fin Investigación Registros
07/05/2009 15/07/2009 Desarrollo - Versión 1.0 16/07/2009 05/12/2009 Desarrollo - Versión 2.0 06/12/2009 15/05/2009 Investigación Respaldos 15/11/2010 15/03/2010 Documentación Final y Presentación 01/04/2010 06/09/2010 Dos versiones del sistema, la primera incluye la lógica del sistema de registros y parte de la interfaz de auditoría. En la segunda se finaliza la interfaz de auditoría, se implementa la interfaz de administración y se corrigen los errores de la primer versión. Los tiempos incluyen implantación y testeo básico en el hospital. La tarea de desarrollo incluye: relevamiento, análisis, diseño, implementación, testing, implantación y ejecución del caso de estudio. El alcance del proyecto se debió ajustar y se decidió mantener pese a que los plazos se extenderían, ya que es un sistema de importancia para el hospital. Señalar las tareas solapadas y cómo se dividió el trabajo para llegar a tiempo.

31 Extensiones y Trabajo a Futuro
Sistema de Registros Lograr interoperabilidad con framework WSO2 PHP Mejorar reportes y estadísticas. Probar TLS con servidor syslog Correlación de eventos Algoritmos para limite de almacenamiento Sistema de Respaldos Respaldar bases de datos en Linux Utilizar certificados para los respaldos Implementar interfaz grafica para respaldar y restaurar archivos en clientes Windows. Sistema Respaldos: Bases de Datos en Linux -> Bacula no tiene soporte nativo, pero la comunidad ha desarrollado script ejecutables por el programa para realizar la tareas. Bacula utiliza la interfaz grafica Bat, pero la versión existente es antigua y no funciona en Windows obligando al usuario a realizar la consola para realizar sus respaldos y actualizaciones.

32 Conclusiones (1/2) Sistema Registros Sistema Respaldos
Prototipo de sistema de registro de eventos Prototipo de interfaz de auditoría de eventos Integración de ambos con sistemas del Hospital Sistema Respaldos Elección herramienta que mejor se adapta a la infraestructura del hospital. Creación ambiente de prueba en Windows y Linux Elaboración documentación detallada para la utilización de la herramienta.

33 Conclusiones (2/2) Experiencia adquirida
Estudio y utilización de estándares facilitan el desarrollo. Investigación, manejo e integración de tecnologías de punta brindan herramientas para una mejor inserción laboral. Relacionamiento y trabajo junto al cliente Implementación Genexus Implantación Caso de estudio Estudio de estándares facilitan el desarrollo. 1. Elimina el trabajo de definir que información necesitamos registrar en cada evento. 2. Asegura compatibilidad con otros sistemas que los cumplan.

34 GRACIAS

35 “Gestión de Registros y Respaldos en el Contexto Hospitalario”
Estudiantes: Martín Calabria Gonzalo Perretti Tribunal: Supervisores: Responsables: Andrés Aguirre Lorena Etcheverry Antonio Mauttone María Eugenia Corti Ariel Sabiguero Julio Carrau Gustavo Perez 35 35