Esquema de seguridad para un sistema integrado de información basado en una infraestructura grid

Texto completo

(1)ESQUEMA DE SEGURIDAD PARA UN SISTEMA INTEGRADO DE INFORMACIÓN BASADO EN UNA INFRAESTRUCTURA GRID. JONATHAN JAVIER CÓRDOBA GONZALEZ. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN 2008.

(2) ESQUEMA DE SEGURIDAD PARA UN SISTEMA INTEGRADO DE INFORMACIÓN BASADO EN UNA INFRAESTRUCTURA GRID. JONATHAN JAVIER CÓRDOBA GONZALEZ. Trabajo de Grado Presentado como Requisito para Optar por el Título de Maestría en Ingeniería de Sistemas y Computación. ASESOR JOSÉ EUSEBIO ABASOLO PRIETO, PHD.. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN 2008.

(3) Una vez más se alcanza un nuevo objetivo. Aunque al principio algunas personas se interpusieron para no lograrlo, siempre estuvieron allí mi familia: Mi madre Susana, mi madre Marleny mi padre Víctor, mi hermano Alexander y mi abuelo Álvaro quién nuevamente puso a personas de bien en mi camino para mi ayuda. Entre éstas a mi asesor José Abasolo que sin él haber realizado esta tesis no hubiera sido posible, y a mi tutor Jeimy Cano que sin él no hubiera incursionado en el mundo de la Seguridad Informática. También a la DTI (Uniandes) por permitirme realizarme profesionalmente. Finalmente a mi corazón que se llenó de comprensión y amor en los momentos en los cuales más los necesité..

(4) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Tabla de Contenidos I. II.. Introducción ................................................................................................................ 5 Planteamiento del Problema y Propuesta ................................................................... 8 A. Planteamiento del Problema ................................................................................... 8 1. Descripción del Ambiente de Producción ............................................................. 8 2. Requerimientos de Seguridad del Sistema Integrado de Salud ........................... 8 B. Propuesta de Solución ............................................................................................ 9 III. Marco Teórico ....................................................................................................... 11 A. Kerberos Bibliografía ............................................................................................. 11 B. [1] [2] [3] [4] ........................................................................................................... 11 1. Descripción ........................................................................................................ 11 2. Funcionamiento del Protocolo ........................................................................... 12 3. Limitaciones....................................................................................................... 13 C. Infraestructura de Llave Pública (PKI) y Certificados Digitales [5] ...................... 13 1. Certificados Digitales ......................................................................................... 13 2. PKI .................................................................................................................... 14 D. XACML [6] [7] .................................................................................................... 15 1. Descripción ........................................................................................................ 15 2. Arquitectura y Funcionamiento .......................................................................... 16 E. Bases de Datos Hipocráticas [8] [9] [10] [11] [12] [13] [14] .................................... 17 1. Descripción y Propósito ..................................................................................... 17 2. Arquitectura de las Bases de Datos Hipocráticas .............................................. 19 3. Esquema de Confidencialidad, Autenticación y Autenticidad. ............................ 21 IV. Estado del Arte y Tecnologías Existentes ............................................................. 22 A. Universal Patient Record [15] ................................................................................ 22 B. Red de Diagnóstico Médico Colaborativo a través de una Red P2P [16]............... 22 C. Grid de Información de Salud [17] ..................................................................... 23 D. Sovereing Information Integration (SII) [8] [9] [10] [11] [12] [13] [14] .................. 23 E. Globus Toolkit [18] ................................................................................................ 24 F. Comparación de Arquitecturas y Tecnologías de Integración ................................ 25 V. Análisis de Riesgos de la Infraestructura de Integración ........................................... 27 A. Metodología [19] ................................................................................................... 27 B. Análisis de Riesgos ............................................................................................... 29 1. Caracterización del Sistema .............................................................................. 29 2. Identificación de Amenazas ............................................................................... 30 3. Identificación de Vulnerabilidades ...................................................................... 31 4. Identificación de Controles de Seguridad........................................................... 33 5. Determinación de Niveles de Probabilidad ........................................................ 33 6. Determinación de Niveles de Impacto................................................................ 34 7. Determinación de Niveles de Riesgo ................................................................. 35 8. Recomendaciones de Controles y Conclusiones del Análisis ............................ 37 VI. Propuesta de Solución .......................................................................................... 40. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 1.

(5) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. A. B.. Arquitectura Global de la Solución ........................................................................ 40 Esquema de Autenticación .................................................................................... 41 1. Descripción de la Problemática.......................................................................... 41 2. Descripción de la Solución................................................................................. 41 3. Arquitectura de la Solución ................................................................................ 42 C. Esquema de Autorización .................................................................................. 50 1. Descripción de la Problemática.......................................................................... 50 2. Descripción de la Solución................................................................................. 50 3. Arquitectura de la Solución ................................................................................ 50 VII. Implementación y Resultados ............................................................................... 57 A. Esquema de Autenticación .................................................................................... 57 1. Implementación ................................................................................................. 57 2. Pruebas ............................................................................................................. 58 B. Esquema de Autorización ..................................................................................... 59 1. Implementación ................................................................................................. 59 2. Pruebas ............................................................................................................. 60 VIII. Conclusiones y Trabajo Futuro .............................................................................. 63 A. Conclusiones......................................................................................................... 63 B. Trabajo Futuro....................................................................................................... 65 Bibliografía ....................................................................................................................... 66. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 2.

(6) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Índice de Figuras Figura 1. Secuencia de Mensajes Kerberos [3] ................................................................ 12 Figura 2. Arquitecturas PKI[5] .......................................................................................... 14 Figura 3. Contexto de XACML. [6] ................................................................................... 16 Figura 4. Componentes y flujo de mensajes de XACML. [6] ............................................ 16 Figura 5. Modelo de Lenguaje de Política. [6] .................................................................. 18 Figura 6. Arquitectura Inicial de las Bases de Datos Hipocráticas. [8] ............................ 19 Figura 7. Arquitectura de Autenticación. [14] ................................................................... 21 Figura 8. Metodología de Análisis de Riesgos. [19] ......................................................... 28 Figura 9. Arquitectura Global de Servicios ....................................................................... 40 Figura 10. Arquitectura de Autenticación ......................................................................... 43 Figura 11. Niveles de Autenticación ................................................................................. 45 Figura 12. Diagrama de Componentes Servicio Autenticación......................................... 46 Figura 13. Funcionamiento del Componente KCA ........................................................... 46 Figura 14. Proceso de Autenticación ............................................................................... 48 Figura 15. Primera opción de llamado de servicio de autorización ................................... 51 Figura 16. Segunda opción de llamado de servicio de autorización ................................. 52 Figura 17. Diagrama de Componentes del Servicio de Autorización ................................ 53 Figura 18. Proceso de Autorización ................................................................................. 55 Figura 19. Diagrama de Clases del Esquema de Autenticación ....................................... 57 Figura 20. Diagrama de Clases del Esquema de Autorización......................................... 59. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 3.

(7) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Índice de Tablas Tabla 1. Comparación de Factores de Seguridad entre las Arquitecturas de Integración 26 Tabla 2. Lista de Amenazas con sus fuentes de origen. .................................................. 30 Tabla 3. Identificación de Vulnerabilidades y Riesgos...................................................... 32 Tabla 4. Definición de Niveles de Probabilidad. [19] ........................................................ 33 Tabla 6. Definición de Niveles de Impacto. [19] ............................................................... 34 Tabla 5. Niveles de Probabilidad por cada Riesgo ........................................................... 34 Tabla 7. Niveles de Impacto por cada Riesgo .................................................................. 35 Tabla 8. Definición de Niveles de Riesgo. [19] ................................................................. 36 Tabla 9. Niveles de Clasificación para cada Riesgo del Sistema de Información Integrado ........................................................................................................................................ 36 Tabla 10. Matriz de Riesgos de los Riesgos Identificados. .............................................. 37 Tabla 11. Interfaces del Servicio de Autenticación ........................................................... 49 Tabla 12. Interfaces del Servicio de Autorización............................................................. 56 Tabla 13. Comparación de Rendimiento con Respecto el Número de Usuarios .............. 58 Tabla 14. Resultados de Pruebas Funcionales ................................................................ 60 Tabla 15. Comparación de Rendimiento con Respecto al Número de Reglas ................. 61 Tabla 16. Comparación de Factores de Seguridad entre las Arquitecturas de Integración y la Propuesta de Solución ................................................................................................. 64. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 4.

(8) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. I. Introducción Conforme pasa el tiempo, las organizaciones consideran la información como una parte vital de su negocio, sin la cual no podría llevar a cumplimiento muchos de sus objetivos organizacionales. En el caso de las empresas del sector salud la información de sus pacientes y/o procedimientos médicos se ha constituido como la base de todas sus operaciones. Al principio, éstas consideraban que la información no era valiosa y sumando con la poca cantidad que debían manejar, muchas compañías administraban su información a través de archivos físicos, los cuales consistían en el almacenamiento de grandes cantidades de documentos con una administración documental adecuada. El sistema funcionaba de una manera muy manual, las historias clínicas de los pacientes eran almacenadas en un sitio central que eran administrados por empleados. En este modelo la información posee problemas de seguridad de la información (confidencialidad, integridad y disponibilidad), más específicamente en el campo de la seguridad física, ya que dependía de un sitio físico que ofreciera una solución a estos problemas. En adición, las organizaciones en esos tiempos no tenían en cuenta esos aspectos básicos de seguridad, ya que la información no se consideraba como un activo importante para la organización. Tampoco no existían legislaciones que exigieran la protección adecuada de la información. Aunque este esquema era sencillo de implementar, después de un tiempo, comenzaba a presentar fallas en la administración de la información, tales como la búsqueda de información y aún más importante el almacenamiento de la misma. Debido a estas necesidades y gracias a la evolución de la computación nacieron los sistemas de información, los cuales usaban el poder de procesamiento para la búsqueda de la información y ofrecen un medio de almacenamiento mucho más compacto. Estas características permitieron que los sistemas de información realizar consultas de información del paciente por cualquier persona con acceso al sistema y desde cualquier parte de la clínica o el hospital desde un computador, pues estaban basados en un sistema centralizado y en un esquema cliente-servidor. Gracias a esto, la información logró una importancia significativa para las empresas del sector salud, pues apoyaban de manera más directa sus procesos de negocio visiónales relacionados con la prestación de servicios de salud. Los sistemas de información les permite ofrecer una mejor calidad de los servicios y por lo tanto generar un factor. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 5.

(9) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. diferenciador, pero introdujeron nuevos retos en la seguridad, dado que no solo presentaban problemas de seguridad física sino que también consideraciones de seguridad informática. Como consecuencia a esas falencias en seguridad informática, gobiernos de alrededor del mundo han dictado leyes que exigen a las organizaciones del sector salud una adecuada protección de la privacidad de las personas (registros médicos, como historias clínicas, enfermedades, resultados y entre otros) e imponen fuertes sanciones a las que no cumplan dichas exigencias. Estas exigencias han obligado a la comunidad científica idear soluciones y esquemas de seguridad informática, tales como técnicas de ciframiento, algoritmos de verificación de integridad, esquemas de autenticación, firmas digitales y certificados digitales, los cuales han proveído a problemáticas tales como la Confidencialidad, Integridad, Autenticidad, Autenticación, Autorización y Auditoria. Tales soluciones de seguridad han resultado ser efectivos en ambientes de baja escalabilidad y enfocados en sistemas de información simples. Pero estas arquitecturas de seguridad resultan ser poco eficientes en los sistemas de información actuales, ya que debido a la globalización ha obligado a que las organizaciones una ampliación en la cobertura de sus servicios no solo a nivel local, sino a través de una red organizada de compañías de prestación de servicios de salud. Esta red organizada es llamada un sistema de salud. Tal esquema de prestación de servicios, hacían que cada uno los sistemas de información presentara distintas visiones de un mismo paciente, ya que cada uno de éstos es un ente aislado y por lo tanto no ofrece una información global e integrada en el sistema de salud. Esta necesidad de globalización de la información requirió la creación de mecanismos de integración de datos y que permitieran de sistemas de información llamados sistemas integrados de salud. Los sistemas integrados de salud requirieron un cambio de las arquitecturas de los sistemas de información. Impusieron la creación de nuevas reglas de flujos de información entre cada organización, replicación de datos y definición de estándares de datos. Estos cambios por supuesto significaron un cambio en el escenario de los mecanismos de protección de la seguridad de la información, ya que involucran el flujo de información a través de una red pública como Internet (la cual atenta contra la seguridad de la información que se transporta por ésta) y requieren establecer un esquema de seguridad confiable para todas las organizaciones que conforman el sistema de salud. Debido a lo anterior, nace la necesidad de proponer, diseñar e implementar un esquema de seguridad para dichos sistemas de integración de información. Lo anterior es la motivación principal para el desarrollo de esta propuesta de tesis.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 6.

(10) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. El desarrollo de esta propuesta de tesis contempla un capitulo en el cual se identifica la problemática que se desea afrontar y una descripción de los requerimientos de seguridad que requieren la solución. Luego, se describirá las tecnologías utilizadas para la solución propuesta con el fin de enmarcar al lector con los conocimientos base para el entendimiento de la misma. Después, se realizará una evaluación de las tecnologías de integración de información en términos de seguridad, lo cual ayudará a identificar las necesidades de seguridad no cubiertas por las arquitecturas existentes. Posteriormente, se desarrollará un análisis de riesgos que permitirá tener una base para la elección de controles y justificarlos mediante la evaluación de impacto de riesgos de las infraestructuras existentes. De forma continua, se incluirán en dos capítulos el diseño e implementación de la solución, incluyendo las decisiones de implementación y las ventajas funcionales de tal propuesta. Además, se adiciona una evaluación de rendimiento de la implementación. Por último, se desarrollan las conclusiones que contemplan los aportes realizados a la comunidad y se presenta el trabajo futuro que garantizará una mejora a la propuesta de tesis.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 7.

(11) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. II. Planteamiento del Problema y Propuesta A.. Planteamiento del Problema. Como lo mencionamos anteriormente, la integración de los sistemas de salud acarrea unos nuevos retos en la seguridad informática. En esta sección se pretende revisar estos retos en cada una de las propiedades de la seguridad de un sistema integrado de salud, pero antes se debe describir la naturaleza del sistema.. 1.. Descripción del Ambiente de Producción. Cualquier sector salud en el mundo está compuesto por muchos actores: pacientes, entidades prestadoras de salud (hospitales, clínicas, laboratorios, etc.), entidades integradoras de servicios, entidades de seguros, entidades reguladores y entidades gubernamentales. Dada esta cantidad de entidades y al inicio de los sistemas de información, encontramos que cada entidad posee repositorios independientes, heterogéneos, aislados que contienen información de la prestación de sus servicios, tales como historias clínicas, datos personales de pacientes, información de médicos, información de citas, resultados y entre otros. Debido a la visión global de la prestación de los servicios y a la conformación de un sistema de salud, los sistemas de información requieren suministrar una información globalizada. Lo anterior requiere un sistema de información que integre cada uno de los sistemas de información a nivel semántica y a nivel de datos. Tal sistema de información integrado independiente de la arquitectura o tecnología utilizada requiere una interconexión de cada uno de las fuentes de datos, un mecanismo de localización, un mecanismo de replicación de datos (para mejorar el desempeño), un mecanismo de sincronización de datos y un mecanismo de integración semántica.. 2.. Requerimientos de Seguridad del Sistema Integrado de Salud. Éste sistema de información requiere una serie de planteamientos en las diferentes cualidades de la seguridad informática. Primero, el sistema debe respetar la confidencialidad de los datos que cada entidad maneja y transporta, por lo que requiere que la conexión con el sistema de integración sea cifrado y por lo tanto protegerlo de Internet. Adicionalmente, cada repositorio de información debe almacenar la información en forma confiable y segura. Segundo, el sistema debe garantizar la integridad de los datos, ya sea a nivel local como a nivel de todo el sistema. Es claro que el mayor reto para el sistema integrado es ofrecer. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 8.

(12) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. la Integridad de la información en todas las fuentes de datos para un mismo momento en el tiempo. Tercero, el sistema debe determinar la autenticidad de las transacciones. Esto implica que se debe poder verificar la identidad de cada uno de las entidades del sector salud, certificado a través de un ente confiable y escalable, con lo cual se eviten problemas de suplantación de entidades y por lo tanto robo de información. Cuarto, el sistema integrado deberá contemplar esquemas de autenticación fuerte, como esquemas de autenticación de doble factor (aquellos que combinen dos o más esquemas de autenticación). Este esquema deberá permitir definir los controles de acceso de cada participante en el sistema de forma escalable. Quinto, la privacidad debe ser una característica debido a la sensibilidad de la información que se está manejando (los estados de salud de salud, según la ética de los profesionales de la medicina y las leyes gubernamentales es de carácter privado). Entonces, cada entidad de prestación de servicios de salud debe acogerse a las reglamentaciones y debe garantizar la privacidad de la información de la cual es dueña. Bajo este escenario es necesario mencionar que los repositorios de información deben hacer un manejo adecuado de la privacidad de los datos mediante reglas bien definidas. Por último, el sistema debe ser auditable, debe ser capaz de generar logs de transacciones a través del sistema distribuido de manera escalable y no centralizada. Es preferible que esta generación de logs se haga de manera optimista, es decir que se realice por fuera de las transacciones. Cada uno de estos requerimientos, serán tomados en cuenta para el diseño del sistema integrado de salud. Se desarrollarán componentes arquitectónicos que integren la seguridad como un requerimiento funcional del sistema y no como requerimiento transversal y añadido en etapas posteriores del sistema.. B.. Propuesta de Solución. La propuesta de tesis consiste en la construcción de un esquema de seguridad que satisfaga los requerimientos del sistema integrado de información, no solo para el sector salud, sino para cualquier tipo de negocio que requiera integración de datos. La idea es entonces, diseñar e implementar un esquema de autenticación que sea federado para que no sea susceptible a indisponibilidades de sistema. También se desea que el esquema de autenticación sea fácilmente integrable a los sistemas Grid existentes en la actualidad (especialmente Globus-toolkit). Por otro lado el esquema de autorización debe proveer flexibilidad en la especificación de reglas de control acceso, tales como tipo de usuario, pertenencia a una organización y/o entidad, tipo de entidad de datos y otros tipos de operaciones. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 9.

(13) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Finalmente, las demás características de seguridad son cubiertas por los mecanismos de seguridad implementados por las distintas infraestructuras Grid, ya que la finalidad de esta tesis es complementar las características de seguridad que poseen dichas infraestructuras.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 10.

(14) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. III. A.. Kerberos Bibliografía. B.. [1]. 1.. Marco Teórico. [2] [3] [4]. Descripción. Kerberos es un protocolo de autenticación desarrollado por MIT1 el cual permite a usuarios, dispositivos y otros actores comunicarse entre sí a través de una red no segura con el fin de probar la identidad de cada uno. En otras palabras permite la autenticación de cada actor. Este protocolo funciona bajo un modelo de cliente-servidor en el cual tanto el usuario como el servidor verifican la identidad de cada uno, con lo que se consigue una autenticación mutua. Debido al diseño del protocolo es fuerte a ataques de replicación de mensajes y de pérdida de confidencialidad. Lo que hace interesante el uso de este protocolo es el hecho de ser seguro en cuanto a la protección de la contraseña, ya que no necesita transmitir la contraseña con el servidor de autenticación. Adicionalmente, Kerberos permite implementar sistemas de Single Sign On lo que permite que los usuarios realicen la autenticación solo una vez para poder obtener a todos los recursos autenticados en el sistema. El funcionamiento y la seguridad del protocolo radica principalmente en sus elementos y/o participantes los cuales deben mantener sus relojes sincronizados, y al concepto de tiquetes los cuales hacen posible el proceso de autenticación. En el proceso de autenticación deben intervenir un Authentication Server (Servidor de Autenticación) y un Ticket Granting Server (Servidor de Expedición de Tiquetes).. 1. Massachussets Institute of Technology. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 11.

(15) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. 2.. Funcionamiento del Protocolo. Figura 1. Secuencia de Mensajes Kerberos [3]. En la Figura 1 se puede observar la secuencia de mensajes del protocolo Kerberos que funciona de esta manera: 1. El cliente solicita un tiquete al Authentication Server (AS). 2. El AS verifica la existencia del cliente, si es así, envía una llave de sesión cifrada con la llave del cliente (extraída de la contraseña del cliente que tiene en su base de datos) y envía un Ticket-Granting Ticket (TGT) que será utilizado para comunicarse con el Ticket Granting Server (TGS). 3. Una vez recibido el TGT, el cliente descifra la llave de sesión y envía una petición de solicitud de tiquete para utilizar un servicio al TGS que consta del TGT, el identificador del servicio a utilizar y una estampa de tiempo con el identificador del cliente cifrado con la llave de sesión. 4. El TGS obtiene la información del TGT y envía al cliente un tiquete para comunicarse con el servicio (TS) y la llave de sesión para comunicarse con el servicio cifrado con la llave de sesión. 5. El cliente envía al servicio el TS y una estampa de tiempo con el identificador del cliente cifrado con la llave de sesión de comunicación con el servicio. 6. Finalmente el servicio obtiene la identificación del cliente y la llave de sesión con el cliente del TS. En este punto la comunicación se realiza con esta llave y se ha realizado la autenticación mutua. Como se puede ver el protocolo nunca involucra el intercambio de contraseñas ni de llaves secretas en texto claro, pues solo involucra el intercambio de tiquetes. Además, el solo intercambio de tiquetes permite la funcionalidad del Single Sign On, ya que solo. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 12.

(16) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. basta con digitar la contraseña solo una vez ante el Authentication Server para poder obtener la comunicación con el Ticket Granting Server el que permite la autenticación con cualquier servicio registrado en el sistema.. 3.. Limitaciones. Aunque este protocolo es seguro proveyendo confidencialidad e integridad en el intercambio de mensajes y Single Sign On, posee algunos puntos de falla y limitaciones. En primera medida debido al diseño del protocolo, Kerberos posee un único punto de falla que son los Authentication Server y el Ticket Granting Server, ya que si ninguno de ellos está disponible impedirían la autenticación en el sistema y por lo tanto el ingreso a cualquier servicio. Usualmente, esta limitación debe ser mitigada a través de redundancia de servidores. Otra limitación consiste en la característica de Single Sign On, pues si la contraseña de un usuario es comprometida, se puede obtener acceso a todos los servicios del sistema. Esto se puede mitigar mediante medidas de establecimiento de contraseñas seguras. Finalmente, debido a la arquitectura de Kerberos que centraliza las contraseñas implica que los servidores centrales deben ser sometidos a extrema protección, por tanto que si estos son comprometidos se obtendrá accesos sin restricción a todos los servicios.. C. 1.. Infraestructura de Llave Pública (PKI) y Certificados Digitales [5] Certificados Digitales. Los certificados digitales son un documento digital en el cual un tercero en confianza asegura la vinculación entre la entidad certificadora y el usuario. Este sirve principalmente para realizar validaciones de identidad y autenticación. Los certificados digitales van acompañados por una Llave Pública del usuario al cual pertenece, la cual junto a la Llave Privada del usuario (la cual reside y es custodiada por el usuario) permiten realizar operaciones criptográficas de clave pública y que son comúnmente utilizadas en transacciones electrónicas y/o comercio electrónico. Además de tener asociada una Llave Pública, un certificado digital tiene asociada información del usuario. Para garantizar la validez de un certificado digital, un certificado debe estar firmado digitalmente por un tercero en confianza, con lo que se garantiza la modificación indebida por parte de un usuario malicioso. Usualmente el formato más utilizado para representar un Certificado Digital es el X.509, el cual contiene el nombre de la entidad certificada, un número de serie, una fecha de. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 13.

(17) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. expiración, una copia de la llave pública del titular y la firma digital de la entidad certificadora.. 2.. PKI. Una Infraestructura de Llave Publica (PKI2 por sus signas en ingles) es un sistema necesario para proveer servicios criptográficos y de firmado digital. El propósito de una PKI es el manejo de llaves y certificados mediante los cuales una organización(es) establece un ambiente de comunicación confiable. Los principales objetivos de esta infraestructura son principalmente evitar la repudiación de transacciones, asegurar la autenticidad de los mensajes e identificar quien los origino y garantizar la integridad de las transacciones. Una PKI es implementada a través de una Entidad Certificadora (CA3), la cual es una autoridad reconocida y confiable que se encarga de emitir y administrar Certificados Digitales. La forma como una CA refrenda un Certificado Digital que emite es realizando una Firma Digital con lo que indica que ese certificado es confiable y autentico. Con el fin de flexibilizar la expedición de certificados, en PKI existen caminos de certificación con lo que el Certificado Digital de una CA puede ser expedido por una CA superior, así sucesivamente formando un nivel jerárquico de certificación tal como se muestra en la Figura 2.. Figura 2. Arquitecturas PKI[5]. Por otra parte, los usuarios que usan una PKI obtienen certificados digitales de las CA y verifican los certificados digitales de otros usuarios para poder establecer un vínculo de confianza entre ellos y realizar autenticaciones mutuas. Una vez realizada dicha autenticación mutua, se procede a utilizar algoritmos criptográficos tanto para cifrar la información como para firmarlas digitalmente y asegurar la integridad de la misma.. 2 3. Public Key Infrastructure Certification Authority. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 14.

(18) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Finalmente, para que un sistema y/o usuario confíe en un certificado digital, se deben realizar las siguientes validaciones: 1. El certificado digital debe encontrarse en su periodo de validez, el cual es definido por la entidad certificadora que expidió el certificado. 2. La entidad certificadora que expidió el certificado debe encontrarse en la lista de autoridades de certificación de confianza del sistema y/o usuario que recibe el certificado. 3. El certificado digital no debe estar revocado por la entidad certificadora. Esto se valida realizando una petición a la entidad certificadora para verificar si un certificado está revocado o no.. D. 1.. XACML [6] [7] Descripción. OASIS Extensible Access Control Markup Language (XACML) es un lenguaje que permite expresar políticas de autorización y/o control de acceso en formato XML. XACML nació como necesidad de realizar una estandarización ante la gran variedad de lenguajes propietarios que impedían la transferencia de políticas entre cada una de las aplicaciones. Algunas cualidades de XACML son permitir el uso de atributos arbitrarios en las políticas, control de acceso basado en roles, etiquetas de seguridad, políticas de seguridad basados en tiempos y fechas, políticas de denegación y políticas dinámicas sin la necesidad de modificar las aplicaciones que usan directamente a XAMCL. XACML al momento de ser propuesto y diseñado fueron tenidos en cuenta ciertos requerimientos para un lenguaje de expresión de políticas: 1. Proveer un método de combinar reglas y políticas individuales en un único conjunto de políticas que apliquen a una determinada decisión. 2. Proveer un método flexible de definición de un procedimiento mediante el cual se combinen reglas y políticas. 3. Proveer un mecanismo para el manejo de múltiples sujetos actuando en diferentes contextos. 4. Facilitar un procedimiento para basar la autorización en términos de atributos de los sujetos y los recursos a ser accedidos. También se requiere basar dicha autorización dependiendo del contenido de la información. 5. Ofrecer la capacidad de utilizar operaciones matemáticas y lógicas sobre atributos de los recursos, sujetos y ambiente en el cual se toma una decisión. 6. Proveer un método de identificar rápidamente las políticas que aplican a una determinada acción realizada por un sujeto, los atributos del sujeto, del recurso y de la acción. 7. Facilitar una forma de aislar la escritura de las políticas con el ambiente de la aplicación, con el fin de convertirlas en reglas móviles.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 15.

(19) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. 2.. Arquitectura y Funcionamiento. El diseño de XACML está ideado para hacerlo completamente independiente de la aplicación que lo utilice. Para lograr lo anterior, XACML trabaja con el intercambio de mensajes en XML para recibir peticiones de autorización y para responder dichas peticiones tal como se observa en la Figura 3.. Figura 3. Contexto de XACML. [6]. Entonces, los mensajes de petición deben contener una serie de atributos que pueden ser expresados en formato XPath. Tales atributos hacen referencia a una acción, un sujeto (el que realiza una acción) y un recurso (sobre el cual se realiza la acción); lo anterior implica que tanto como las peticiones como las políticas deben estar definidas en términos de triadas sujeto-recurso-acción. Por otra parte, al interior de XACML se ha considerado una serie de componentes que permiten ofrecer las funcionalidades anteriormente descritas. En la se ilustra el intercambio de mensajes entre cada uno de los componentes y los componentes en sí.. Figura 4. Componentes y flujo de mensajes de XACML. [6]. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 16.

(20) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Los componentes de XACML están compuestos por un Punto de Administración Políticas (PAP4) que se encarga de la creación de políticas; Un Punto Cumplimiento Políticas (PEP5) que se encarga de recibir y responder las peticiones; Un Punto Información de Políticas (PIP6) que se encarga de dar información sobre los atributos una política determinada; y Un Punto de Decisión de Políticas (PDP7) que se encarga evaluar las políticas que aplican a una petición determinada y emite una decisión autorización.. de de de de de de. Finalmente, en XACML el modelo del lenguaje de políticas se compone de Reglas, Políticas y Conjunto de Políticas. Entre cada uno de estos se relacionan entre sí dado que el Conjunto de Políticas está formado de una serie de Políticas y a su vez una Política está conformado por una serie de Reglas. Vale la pena mencionar que cada uno de estos componentes está dirigido a un target que está dado por una triada de sujeto-recurso-acción. De esta manera se asocia una política a un sujeto, un recurso y una acción determinado. En la Figura 5 se puede ver de una forma más detallada el modelo de dicho lenguaje.. E. 1.. Bases de Datos Hipocráticas [8] [9] [10] [11] [12] [13] [14] Descripción y Propósito. Las bases de datos hipocráticas (HDB8) son bases de datos que incluyen a la privacidad de la información como su principal razón de ser. La idea de esto es traspasar esta responsabilidad de manejo de la privacidad de las aplicaciones, al nivel más bajo y en donde la información realmente reside. Bajo este mecanismo de protección, los datos están realmente protegidos, ya que la base de datos se encarga de suministrar la información que solo está autorizada en a revelarse a la personas autorizadas. De esta manera se garantiza la privacidad de la información de las personas. Las HDB están basadas en el principio hipocrático, el cual es el juramento que rige la ética y la labor de los profesionales del sector salud. El principio hipocrático dice: “Y sobre cualquier cosa que pueda ver u oír de las personas en un tratamiento médico o aún sin tratamiento (cosas que deberían no se reveladas al público), yo permaneceré en silencio, manteniendo esas cosas en privado”.. 4. Policy Administration Point Policy Enforcement Point 6 Policy Information Point 7 Policy Decision Point 8 Hippocratic Databases 5. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 17.

(21) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Figura 5. Modelo de Lenguaje de Política. [6]. Bajo este principio hipocrático y bajo las legislaciones del manejo de la privacidad de la información (HIPAA9), se ha definido diez principios fundamentales de las HDB. 1. Propósito especificado: La información personal recolectada por la BD, debe ser almacenada con su propósito de uso. 2. Consentimiento: El dueño de la información personal suministrada debe ser consistente de los propósitos de uso. 3. Recolección Limitada: La información recolectada debe ser la mínima necesaria para cumplir con el propósito especificado. 4. Uso Limitado: La BD debe permitir solo aquellas consultas que se ajusten a los propósitos para la cual la información fue recogida. 9. Health Insurance Portability and Accountability Act. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 18.

(22) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. 5. Acceso Limitado: La información recolectada no debe poder ser accedida para propósitos diferentes al definido. 6. Retención Limitada: La información debe ser retenido el tiempo mínimo para cumplir el propósito definido. 7. Exactitud: La información no debe sufrir problemas de integridad. 8. Seguridad: La información debe ser protegida contra accesos no autorizados. 9. Accesible: Un usuario debe tener la capacidad de acceder a la totalidad de sus datos almacenados. 10. Verificable: La BD debe permitir a un usuario verificar el cumplimiento de los anteriores principios.. 2.. Arquitectura de las Bases de Datos Hipocráticas. Para poder cumplir a cabalidad con los anteriores principios fundamentales, se ha definido una arquitectura con componentes que cumplen una función definida.. Figura 6. Arquitectura Inicial de las Bases de Datos Hipocráticas. [8]. En la Figura 6 podemos observar una arquitectura inicial para las Bases de Datos Hipocráticas. Ahora, se describirá cada componente que conforma la arquitectura de la HDB.. a) Privacy Policy El componente de Privacy Policy se encarga de definir y de almacenar las políticas de privacidad de la base de datos. Las políticas se encuentran almacenadas en la BD y deben definir para cada propósito y para cada atributo de información los usuarios externos de la información, el periodo de retención y los usuarios autorizados que pueden acceder a esa información.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 19.

(23) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Usualmente las políticas se definen mediante un lenguaje definido y estándar. Algunos de esos lenguaje son: Plataform for Privacy Prefereces (P3P), Enterprise Privacy Authorization Language (EPAL) y el OASIS eXtensible Access Control Markup Language (XACML).. b) Data Collection Al momento de recolectar la información, la BD debe informarle al usuario las políticas de privacidad que tiene definido y compararlas con las políticas definidas aceptables por el usuario. El Privacy Constraint Validator se encarga de esta tarea de verificación y chequeo. La información ingresada debe ser almacenada con el propósito mediante el cual el usuario acepto que la información fuera recolectada.. c) Queries Para la ejecución de consultas, la HDB debe realizar una serie de verificaciones antes, durante y después de la ejecución de la consulta. El Attribute Access Control, se encarga de la verificación antes de la consulta. Éste analiza la consulta y revisa si ésta no está accediendo a un atributo que no es requerido para el propósito especificado. Durante la consulta, el Record Access Control se asegura de suministrar solo los registros que hayan aceptado el propósito suministrado. Por último el Query Intrusion Detector se encarga de verificar que la consulta no sea sospechosa, este componente se encarga de verificar el comportamiento normal de un usuario y de determinar si la consulta es sospechosa aunque cumpla con los propósitos y requerimientos especificados.. d) Retention El Data Retention Manager, se encarga de eliminar aquella información que hayan cumplido con su propósito, es decir que su periodo de retención haya sido finalizado.. e) Audit Trail Finalmente, la HDB se encarga de realizar labores de auditoría sobre cualquier tipo de transacción ocurrida en la base de datos. Este registro de auditoría contiene, la consulta ejecutada, el propósito por el cual fue ejecutada y el usuario que la ejecutó.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 20.

(24) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. 3.. Esquema de Confidencialidad, Autenticación y Autenticidad.. Para proveer estos requisitos de seguridad, se propone una Authentication Authority (AA), que le permite al usuario realizar una autenticación del tipo Single Sign On, es decir solo debe realizar la autenticación en un solo lugar para obtener el acceso a cada uno de los nodos del sistema.. Figura 7. Arquitectura de Autenticación. [14]. La Figura 7 muestra la forma cómo funciona la autenticación. En el paso uno y dos, Bob se autentica contra la AA, luego en el paso tres la AA le responde con un token de autorización de ingreso al sistema. Cada uno de los sitios valida el token entregado para Bob y determinan su nivel de acceso en esa base de datos (pasos cinco y siete). Por último la confidencialidad y la autenticidad, se logra mediante una infraestructura de llave pública (PKI), donde la autoridad certificadora corresponde a la AA.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 21.

(25) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. IV.. Estado del Arte y Tecnologías Existentes. En esta sección se realizará una descripción de algunas tecnologías de integración de datos. Algunas de éstas están orientadas a arquitecturas utilizadas en el sector salud, las cuales también pueden ser utilizadas para otro tipo de ambientes. Además de la descripción se realizara una evaluación de la seguridad implementada en cada una de estas arquitecturas enunciando tanto las ventajas como sus puntos débiles.. A.. Universal Patient Record [15]. Esta arquitectura propone la creación de una red segura entre los diferentes actores involucrados en el sistema, la cual está compuesta de repositorios de información y de repositorios de CPR10. Tales repositorios CPR proveen identificadores únicos para cada paciente y que permite la localización de todos los registros en el sistema integrado de salud. Estos CPR se integran con un CPR centralizado, el cual es utilizado para dirigirle consultas al sistema. Este modelo no considera ningún modelo arquitectura de seguridad, solo asume de la existencia de una red segura, que debe garantizar los requerimientos de seguridad para un sistema integrado de salud. Finalmente la arquitectura del modelo podría llegar a presentar problemas de disponibilidad, ya que solo existe un solo CPR Central.. B.. Red de Diagnóstico Médico Colaborativo a través de una Red P2P [16]. Esta red tiene como propósito poner a disposición de los profesionales de la medicina de una red que les permita distribuir información médica e imponer diagnósticos. Dicha red se basa en los conceptos básicos de las redes P2P11, es decir se ofrece una infraestructura de comunicación y de localización de cada uno de los datos. Además, las transmisiones de datos médicos se realizan a través de estándares tales como HL712, que permite hacer una integración semántica de los datos. En cuanto a la seguridad de la información esta arquitectura contempla un modulo de autenticación y autorización que permite definir permisos de acceso a los datos de un 10. Computer Patient Record Point to Point 12 Health Level Seven 11. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 22.

(26) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. paciente determinado. También éste maneja certificados y firmas digitales para temas como la confidencialidad, la integridad y la autenticidad.. Aunque contempla un esquema de seguridad vale la pena mencionar que todo el sistema se encuentra totalmente centralizado lo que debilita la disponibilidad del sistema. Además las reglas de control de acceso utilizadas son estáticas y no reciben ningún tipo de protección ante modificaciones indebidas y no autorizadas.. C.. Grid de Información de Salud [17]. Este esquema nace en el servicio de salud de Canadá con el fin de suministrar un sistema integrado de salud que sea escalable, robusto, autónomo, mantenible y seguro. El sistema se basa en una infraestructura Grid, la cual presta servicios de localización y permite el ingreso de nuevos nodo y del retiro de los mismos de forma más sencilla y sin impactar del sistema, pero sí de los datos contenidos en los nodos. Además, el modelo integra ontologías de los términos utilizados en las fuentes de datos y permite la traducción, unión e intersección entre la información de una ontología y otra, por lo que garantiza una integración semántica. En cuanto a la seguridad, el modelo propone un componente que se encarga de proveer confidencialidad, integridad y autenticidad a los datos mediante certificados digitales por medio de webservices (WS-Security). Adicionalmente, el sistema provee una infraestructura de auditoría que pueden ser accedidos por los pacientes y poder ver que se ha hecho con su información médica. Dicho componente es llamado HIGSaP13 cuya arquitectura es centralizada y actúa como un tipo de entidad certificadora (CA) que se encarga del manejo de certificados y de llevar auditoría de las transacciones que se realizan en el sistema. Las desventajas de esta arquitectura radican en su centralización ya que se constituye un único punto de falla. También, esta arquitectura no contempla la autorización a través de reglas de control de acceso especificas, sino contempla uso de roles de forma muy general.. D.. Sovereing Information Integration (SII) [8] [9] [10] [11] [12] [13] [14]. Este modelo desarrollado por el IBM Research Center, además de considerar los requerimientos de seguridad, tiene en cuenta aspectos de seguridad desde su diseño.. 13. Health Information Grid Security and Privacy. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 23.

(27) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Al igual que los anteriores modelos, estos consideran un ambiente distribuido donde diversas fuentes de información aislada, pero con la restricción de que estos datos deben tener un mismo modelo semántico. Cada fuente pública mediante webservices UDDI, los datos que están dispuestos a ofrecer al sistema integrado. Luego, cuando otra fuente requiera consultar información que se encuentra en un algún tercero, realiza un descubrimiento de la localización de la fuente de datos y mediante SOAP realiza la consulta deseado a la otra fuente. El SII posee consideraciones de seguridad muy fuertes, especialmente con la Confidencialidad y la Privacidad de los datos, lo cual lo convierte en un esquema ideal para el manejo de información médica. Para proveer dicha seguridad, SII se basa en Bases de Datos Hipocráticas (HDB) las cuales se encargan del manejo de la privacidad de la información y de Autenticación, Autenticidad y Confidencialidad. Además, el SII provee mecanismos de protección de privacidad para realizar operaciones que involucran uno o más fuentes de datos, sin comprometer la privacidad de la información, pero sin impedir la integración de información. Quizás este modelo de integración constituye en uno de los más seguros que existen en la actualidad, ya que su esquema de autenticación está orientado más a usuario y no a nodos o máquinas, además no se preocupa por la revocación de certificados digitales comprometidos. También su punto fuerte constituye el manejo a la privacidad y el manejo de la autorización de forma granular sobre una entidad de datos. Sus debilidades al igual que los modelos anteriores es su centralismo que posibilita denegaciones de servicio en el caso que los servidores de autenticación estén fuera de línea. Otro punto en contra es el lenguaje utilizado para expresar sus políticas, ya que se utiliza P3P14 cuyo nivel de flexibilidad y riqueza para expresar reglas y políticas es bastante bajo.. E.. Globus Toolkit [18]. Globus Toolkit es una serie de herramientas que permiten el montaje de infraestructuras Grid desarrollado por Globus Alliance. Esta infraestructura se basa en webservices para la localización de recursos que pueden ser usados para la ejecución de ciertas tareas, con el fin de distribuir la carga computacional y aprovechar al máximo la utilización de los recursos. En cuanto al aspecto de seguridad, Globus Toolkit implementa el estándar GSI15 que especifica la comunicación segura, integra y autentica en un ambiente de computación en 14 15. Platform for Privacy Preferences Project Globus Security Infrastructure. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 24.

(28) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Grid. La autenticación es realizada a través de certificados digitales como las arquitecturas anteriormente mencionadas permitiendo la delegación de privilegios para implementar un esquema de Single Sign On. Por otra parte, los mecanismos de seguridad utilizados para la privacidad y confidencialidad de las comunicaciones dependen del nivel de seguridad aplicado. El nivel más bajo corresponde al nivel de transporte, el cual se protege con TLS/SSL16. El siguiente nivel se relaciona al nivel de mensaje que utiliza las propiedades WS-Security. En cuanto a la Autorización, Globus Toolkit ha considerado un mecanismo sencillo a nivel de roles u organizaciones virtuales (VO17) con los cuales se establecen reglas a nivel de grupos utilizando el lenguaje SAML18 que permite el intercambio de la identidad de los usuarios. Las desventajas de seguridad de esta infraestructura residen en la autenticación y en la autorización. Por un lado, el manejo de la autenticación no es muy diferente a los esquemas anteriores por lo tanto posee los problemas descritos en los anteriores modelos. Por otro lado, el manejo de la autorización es algo pobre ya que se basa a nivel de roles y no a nivel de entidades de datos. Tampoco es posible establecer reglas de control de acceso dinámicas, ni dependiendo de un contexto. En último lugar, Globus Toolkit también sufre de problemas de disponibilidad en cuanto a los servicios de autenticación, ya que su sistema es centralizado (es posible tener una federación de entidades certificadoras, pero es poco escalable). También, esta infraestructura no tiene en cuenta la protección de las reglas de control de acceso.. F.. Comparación de Arquitecturas y Tecnologías de Integración. En la Tabla 1 se muestra una comparación de las características de seguridad de las diferentes arquitecturas y tecnologías de integración. En dicha tabla se puede observar las limitaciones de cada sistema resaltados en rojo y las ventajas de seguridad resaltados en verde. En resumen, se puede concluir que las tecnologías de SII y Globus Toolkit se acercan a una arquitectura ideal con respecto a la seguridad de la información; pero aun se tienen ciertas limitaciones con respecto a los esquemas de autenticación, ya que todos se basan en modelos centralizados. También se evidencia una falta de flexibilidad y de desarrollo en los esquemas de autorización, pues aun las reglas de control de acceso son generales en forma de roles y 16. Transport Layer Security/Secure Socket Layer Virtual Organization 18 Security Assertion Markup Language 17. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 25.

(29) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. estáticas sin tener en cuenta contextos en los cuales se realiza o no una petición. Dichas limitaciones serán tenidas en cuenta en la propuesta de esta tesis. Criterio Confidencialidad Integridad Autenticidad Autenticación Autorización Privacidad Auditoria Arquitectura Sistema Autenticación Tipo de Autenticación. Universal Patient Record NO NO NO NO NO NO NO. Red Médica P2P SI SI SI SI SI NO NO. Sistema de Salud Grid SI SI SI SI SI NO SI. N/A. Centralizado. Centralizado. SII. Globus Toolkit. SI SI SI SI SI SI SI. SI SI SI SI SI NO NO. Centralizado. Centralizado. Contraseña. Certificados Tokens. Digitales. Single Sign On. Single Sign On. Revocación de Revocación de Revocación de Revocación de Certificados Certificados Tokens. Certificados Certificados Digitales. Certificados Digitales. N/A. Federado. Federado. Tipo de Reglas de Control de Acceso. N/A. Roles. Roles. Protección Reglas de Control de Acceso. N/A. Ninguno. Ninguno. Ninguno. Lenguaje Reglas de Control de Acceso. N/A. Propietario. Propietario. P3P. Dificultades Autenticación Arquitectura Sistema Autorización. N/A N/A. Federado. Federado. Roles. Estáticas por recurso.. Roles. Ninguno SAML. Propietario.. Tabla 1. Comparación de Factores de Seguridad entre las Arquitecturas de Integración. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 26.

(30) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. V. Análisis de Riesgos de la Infraestructura de Integración En esta sección se realizará un estudio de los posibles riesgos a la seguridad de la información que podrían exponer a un Sistema Integrado de Datos del Sector Salud. Dichos riesgos serán tenidos en cuenta para el diseño e implantación del esquema de seguridad con el fin de mitigar los riesgos más críticos.. A.. Metodología [19]. Para la realización del análisis de riesgos se utilizó la metodología enunciada en [19] que divide en una serie de pasos para obtener una matriz de riesgos que será utilizada para clasificar los riesgos encontrados en el sistema. En la Figura 8 podemos observar una serie de nueve pasos que debemos seguir para la identificación de riesgos. El primer paso consiste en la identificación del sistema que se va a analizar, es decir se debe conocer perfectamente las tecnologías utilizadas, los alcances del sistema, las funciones del mismo y el tipo de información que va a manejar. Luego se deben identificar las amenazas a las cuales se ve enfrentado el sistema. Una amenaza es definida como un posible peligro que puede utilizar una vulnerabilidad para poner en duda la seguridad del sistema. Aquí también se deben identificar las posibles fuentes de amenaza. Después, se identifican las vulnerabilidades que se definen como una falla o debilidad en un sistema que al ser utilizadas pueden incurrir en una violación de la seguridad del sistema o de una política de seguridad. Como cuarto paso se realiza un análisis de los controles que actualmente están implementados en el sistema, los cuales servirán para disminuir la probabilidad de que un riesgo ocurra. Quinto, se debe determinar los distintos niveles de probabilidad que serán utilizados para medir las probabilidades de que una amenaza explote una vulnerabilidad para que ocurra un riesgo. Seguidamente, se determinan los distintos niveles de riesgos, sobre los cuales se realizará el análisis de riesgos. Esta medición debe realizarse bajo los criterios de pérdida de integridad, pérdida de disponibilidad y pérdida de confidencialidad, teniendo como afecta a aspectos económicos, misión, objetivos y reputación de la organización, y vida de personas y/o empleados.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 27.

(31) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Figura 8. Metodología de Análisis de Riesgos. [19]. Luego, se determinar los niveles de riesgos que se obtienen de la probabilidad de que ocurra un riesgo contra el impacto del mismo. En este paso se pueden obtener los riesgos que más impactan en un sistema de información.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 28.

(32) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Finalmente, en el octavo y noveno paso se deben realizar recomendaciones de controles que servirán para mitigar los riesgos encontrados en la etapa anterior. Después se documentará todos los pasos y hallazgos encontrados en los pasos anteriores.. B. 1.. Análisis de Riesgos Caracterización del Sistema. a) Ambiente de Producción En la sección II.A.1 se describe el ambiente sobre el cual se desarrolla el sistema integrado de información. Este sistema de información está conformado por múltiples fuentes de datos que contienen información de pacientes, médicos, procedimientos clínicos, historias clínicas y entre otros. Además se tienen en cuenta terminales de consulta por las cuales los usuarios podrán tener acceso a la información integrada por el sistema de las distintas fuentes de datos. Finalmente, el sistema posee a Médicos y Pacientes como actores iníciales en el sistema de información.. b) Funcionalidades del Sistema Dicho sistema tiene como funcionalidad de permitir a los actores del ambiente de producción, la consulta rápida de información relacionada con los pacientes de la red nacional de salud.. c) Tipo de Información La información que se maneja en este sistema de información está limitada a información que pertenece a pacientes, más específicamente a historias clínicas. Por ende, el tipo de información es altamente sensible y confidencial, y además en el caso de Colombia se encuentra protegida por la Ley Nº 23 de 1981, la cual dicta normas de ética médica. Esta ley establece que la historia clínica de un paciente es un documento privado, sometido a reserva, que únicamente puede ser conocido por terceros previa autorización del paciente o en los casos previstos por la ley [20].. d) Tecnologías Involucradas Para la implementación de la solución de integración de datos se utilizará a Globus Toolkit como la infraestructura que facilitará la creación de una arquitectura Grid que será compuesta por cada fuente de datos y por cada computador que requiera utilizar las funcionalidades del sistema de información. Los criterios de seguridad fueron evaluados en la sección IV.E.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 29.

(33) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. Adicionalmente, se utilizará a OGSA-DAI como la tecnología para la localización de las distintas fuentes de datos del sistema de información. Dicha tecnología se basa en Globus Toolkit y aprovecha las propiedades de seguridad de éste. Finalmente, se utilizarán modelos de integración semántica de datos tales como Ontologías y motores para la conversión de lenguajes RDF a SQL. También el sistema contará con múltiples tipos de fuente de datos (Base de Datos) que serán las encargadas de almacenar la información y serán el objeto de integración de este sistema de información.. 2.. Identificación de Amenazas. Para el sistema integrado de salud basado en Grid se han identificado las amenazas que pueden poner en peligro la seguridad del sistema. A continuación en la Tabla 2 se muestra una lista de tales amenazas con la fuente de éstas. Fuente. Amenaza Accesos no Autorizados al Sistema Suplantación de Identidad Modificaciones no Autorizadas de la Información. Atacantes, Empleados Insatisfechos. Modificaciones no Autorizadas de políticas de Control de Acceso Accesos no Autorizados a la Información Espionaje de Datos en las Redes. Perdida de Confidencialidad Manipulación del Sistema. (Interceptación) Destrucción de la Información. Destrucción de las Reglas de Control de Acceso Indisponibilidad del Sistema Modificaciones no Autorizadas de la Información Modificaciones no Autorizadas de políticas de Control de Acceso Destrucción de la Información.. Virus, Código Malicioso. Destrucción de las Reglas de Control de Acceso Manipulación del Sistema. (Interceptación) Modificaciones no Autorizadas de políticas de Control de Acceso Accesos no Autorizados a la Información Indisponibilidad del Sistema. Tabla 2. Lista de Amenazas con sus fuentes de origen.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 30.

(34) Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud. 3.. Identificación de Vulnerabilidades. A continuación, se identificaron las vulnerabilidades asociadas al sistema de información en estudio. Para poder obtenerlas, se basó en el estudio de las tecnologías utilizadas y la arquitectura de la aplicación. En la Tabla 3 se lista las vulnerabilidades acompañadas con las amenazas previamente identificadas con el fin de identificar los riesgos resultantes. Habiendo realizado la identificación de vulnerabilidades que existen en la implementación del sistema de información y al haberlas confrontado con las amenazas se han identificados los siguientes riesgos: 1. Interceptación de Llaves y Certificados para el acceso al sistema de forma indebida. 2. Interceptación de Llaves y Certificados para suplantar a un Usuario. 3. Obtención de Contraseñas para conseguir certificados válidos. 4. Eliminación y/o Modificación de Reglas de Control de Acceso que Impiden el Acceso (Consulta, Modificación, Borrado) a Datos Privilegiados. 5. Acceso (Consulta, Modificación, Borrado) a Datos Privilegiados. 6. Indisponibilidad del Sistema de Información a Usuarios Autorizados.. Maestría en Ingeniería de Sistemas. Tesis II. 2007-II. 31.