E SEGURIDAD PARA UN SISTEMA NTEGRADO DE INFORMACIÓN …

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

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

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é.

Universidad de los Andes. Córdoba. Tesis II. Esquema de Seguridad en un Sistema Integrado de Salud

Maestría en Ingeniería de Sistemas. Tesis II. 2007-II 1

Tabla de Contenidos

I. Introducción ................................................................................................................ 5

II. 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



A. Arquitectura Global de la Solución ........................................................................ 40

B. 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



Í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



Í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



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



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.



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.



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



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.



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.



III. Marco Teórico

A. Kerberos Bibliografía

B. [1] [2] [3] [4]

1. 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



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



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. Infraestructura de Llave Pública (PKI) y Certificados Digitales [5]

1. 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



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 Public Key Infrastructure 3 Certification Authority



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. XACML [6] [7]

1. 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.



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]



Los componentes de XACML están compuestos por un Punto de Administración de Políticas (PAP4) que se encarga de la creación de políticas; Un Punto Cumplimiento de Políticas (PEP5) que se encarga de recibir y responder las peticiones; Un Punto de Información de Políticas (PIP6) que se encarga de dar información sobre los atributos de una política determinada; y Un Punto de Decisión de Políticas (PDP7) que se encarga de evaluar las políticas que aplican a una petición determinada y emite una decisión de autorización. 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. Bases de Datos Hipocráticas [8] [9] [10] [11] [12] [13] [14]

1. 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 5 Policy Enforcement Point 6 Policy Information Point 7 Policy Decision Point 8 Hippocratic Databases



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



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.



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ó.



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.



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 11 Point to Point 12 Health Level Seven



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



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 Platform for Privacy Preferences Project 15 Globus Security Infrastructure



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 17 Virtual Organization 18 Security Assertion Markup Language



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.

CriterioUniversal Patient

Record

Red Médica

P2P

Sistema de

Salud GridSII Globus Toolkit

Confidencialidad NO SI SI SI SI

Integridad NO SI SI SI SI

Autenticidad NO SI SI SI SI

Autenticación NO SI SI SI SI

Autorización NO SI SI SI SI

Privacidad NO NO NO SI NO

Auditoria NO NO SI SI NO

Arquitectura

Sistema

Autenticación

N/A Centralizado Centralizado Centralizado Centralizado

Tipo de

AutenticaciónN/A

Certificados

Digitales

Certificados

Digitales

Contraseña.

Tokens.

Single Sign On.

Certificados

Digitales.

Single Sign On.

Dificultades

AutenticaciónN/A

Revocación de

Certificados

Revocación de

Certificados

Revocación de

Tokens.

Revocación de

Certificados

Arquitectura

Sistema

Autorización

N/A Federado Federado Federado Federado

Tipo de Reglas de

Control de AccesoN/A Roles Roles

Roles.

Estáticas por

recurso.

Roles

Protección Reglas

de Control de

Acceso

N/A Ninguno Ninguno Ninguno Ninguno

Lenguaje Reglas de

Control de AccesoN/A Propietario Propietario P3P

SAML.

Propietario.

Tabla 1. Comparación de Factores de Seguridad entre las Arquitecturas de Integración



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.



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.

Figura 8. Metodología de Análisis de Riesgos. [19]



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. Análisis de Riesgos

1. 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.



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

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


Control de Acceso


Destrucción de las Reglas de Control de Acceso

Manipulación del Sistema. (Interceptación)


Control de Acceso

Accesos no Autorizados a la Información

Indisponibilidad del Sistema

Atacantes, Empleados

Insatisfechos

Virus, Código Malicioso

Tabla 2. Lista de Amenazas con sus fuentes de origen.



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.



Vulnerabilidad Amenazas Riesgos

Robo de Certificados y Llaves Privadas

Accesos no Autorizados al Sistema.

Suplantación de Identidad.

Interceptación de Llaves y Certificados para el

acceso al sistema de forma indebida.

Interceptación de Llaves y Certificados para

suplantar a un Usuario.

Obtención de Contraseñas para conseguir

certificados válidos.

Falta de Protección a Reglas de Control de Acceso (No Confidencialidad, No Integridad,

No Autenticidad)

Modificaciones no Autorizadas de la

Información.


Control de Acceso.

Accesos no Autorizados a la Información.

Destrucción de las Reglas de Control de Acceso.

Eliminación y/o Modificación de Reglas de

Control de Acceso que Impiden el Acceso

(Consulta, Modificación, Borrado) a Datos

Privilegiados.

Acceso (Consulta, Modificación, Borrado) a Datos

Privilegiados.

Falta de Protección de la Información de cada una de las Fuentes de Datos (No

Confidencialidad, No Integridad, No Autenticidad)


Información.




Privilegiados.

Indisponibilidad de los Servidores de Autenticación Indisponibilidad del SistemaIndiponibilidad del Sistema de Información a

Usuarios Autorizados.

Falta de Manejo de Reglas de Control de Acceso a nivel de entidades de datos


Información.




Privilegiados.

Transmición de Datos no Cifrados


Información.


Espionaje de Datos en las Redes. Perdida de

Confidencialidad.


Privilegiados.

Indisponibilidad de los Servidores de Autorización Indisponibilidad del SistemaIndiponibilidad del Sistema de Información a

Usuarios Autorizados.

Falta de Aseguramiento de Plataforma (Eliminación de Vulnerabilidades del Sistema

Operativo y de la Aplicación) de las Fuentes de Datos.


Información.


Manipulación del Sistema. (Interceptación).



Privilegiados.


Operativo y de la Aplicación) de los Servidores de Autorización.


Información.


Control de Acceso.




Destrucción de las Reglas de Control de Acceso.

Eliminación y/o Modificación de Reglas de

Control de Acceso que Impiden el Acceso

(Consulta, Modificación, Borrado) a Datos

Privilegiados.


Privilegiados.


Operativo y de la Aplicación) de los Servidores de Autenticación.

Accesos no Autorizados al Sistema.

Suplantación de Identidad.


Interceptación de Llaves y Certificados para el

acceso al sistema de forma indebida.

Interceptación de Llaves y Certificados para

suplantar a un Usuario.

Obtención de Contraseñas para conseguir

certificados válidos.

Almacenamiento de Resultados de Consulta de forma no cifrada


Información.



Privilegiados.

Inexistencia de restricción a acceso de datos sin validación de autorización a las fuentes

de datos


Información.




Privilegiados.

Tabla 3. Identificación de Vulnerabilidades y Riesgos



4. Identificación de Controles de Seguridad En la sección IV.E se discuten los controles de seguridad que posee la tecnología sobre la cual se implementa el sistema de información. Allí se enuncian tanto sus ventajas como sus puntos débiles. Por otra parte, A nivel de sistema operativo de cada máquina que participará en la infraestructura de Grid, no se han considerado mecanismos, procedimientos, ni controles que garanticen la seguridad de éstos y por ende afecten la seguridad del sistema de información.

5. Determinación de Niveles de Probabilidad Para este análisis se utilizaran los criterios estándar para determinar los niveles de probabilidad de que ocurra una amenaza, aprovechando una vulnerabilidad ocasionando así de que se materialice un riesgo. En la Tabla 4 se pueden observar estos criterios.

Nivel Probabilidad Definición de Probabilidad

ALTO

El origen de la amenaza está altamente motivada y es

suficientemente capaz de realizar un ataque, y los controles

para prevenir la vulnerabilidad es totalmente inefectivo.

MEDIO

El origen de la amenaza está motivada y es capaz de realizar

un ataque, y los controles para prevenir la vulnerabilidad

están implementados pero posee algunas debilidades.

BAJO

El origen de la amenaza está bajamente motivado o los

controles para prevenir la vulnerabilidad están

implementados. Tabla 4. Definición de Niveles de Probabilidad. [19]

Bajo estos niveles, se procedió a determinar los niveles de probabilidad de cada riesgo identificado. En la Tabla 4 se puede observar la definición de dichos niveles. A continuación, se realiza la explicación por la cual se definieron los niveles de probabilidad para los seis riesgos identificados:

1. La probabilidad asociada es MEDIO, ya que la infraestructura maneja certificados digitales de larga duración por lo que permite a un atacante tener más tiempo para poder obtener uno.

2. La probabilidad asociada es MEDIO por la misma razón explicada anteriormente.

3. La probabilidad asociada es MEDIO por la misma razón explicada anteriormente.



Riesgo Nivel de Probabilidad


MEDIO

2. Interceptación de Llaves y Certificados para suplantar a un Usuario.

MEDIO

3. Obtención de Contraseñas para conseguir certificados válidos.

MEDIO

4. Eliminación y/o Modificación de Reglas de Control de Acceso que Impiden el Acceso (Consulta, Modificación, Borrado) a Datos Privilegiados.

ALTO

5. Acceso (Consulta, Modificación, Borrado) a Datos Privilegiados.

ALTO

6. Indisponibilidad del Sistema de Información a Usuarios Autorizados.

MEDIO

4. La probabilidad asociada es ALTO debido a que Globus Toolkit no considera

ningún tipo de protección para las reglas de control de acceso. 5. La probabilidad asociada es ALTO pues la infraestructura Grid no ofrece

adecuados mecanismos de autorización a nivel de entidades de datos. Adicionalmente, no se tiene en cuenta la protección para cada fuente de datos, ni tampoco se da un adecuado manejo a la confidencialidad a los resultados a consultas realizadas por los usuarios.

6. La probabilidad asociada es MEDIO debido a la arquitectura centralizada de los mecanismos de autenticación.

6. Determinación de Niveles de Impacto Al igual que la sección anterior, se utilizaran los criterios estándar para los niveles de impacto que tenga un riesgo. En la Tabla 6 se pueden observar estos criterios.

Nivel Impacto Definición de Impacto

ALTO

La materialización del riesgo puede resultar en altos costos

para la organización; afecta el cumplimiento de los objetivos

misionales de la organización; puede ocasionar muerte de

alguna personas u ocasionar severas lesiones.

MEDIO

La materialización del riesgo puede resultar en costos para la

organización; afecta el cumplimiento de objetivos de la

organización; puede poner en riesgo la integridad de las

personas.

BAJO

La materialización del riesgo puede resultar en costos poco

significativos para la organización; afecta el cumplimiento de

objetivos. Tabla 6. Definición de Niveles de Impacto. [19]

Tabla 5. Niveles de Probabilidad por cada Riesgo



Bajo estos niveles, se procedió a determinar los niveles de impacto de cada riesgo identificado. En la Tabla 7 se puede observar la definición de dichos niveles.

Riesgo Nivel de Impacto


MEDIO


MEDIO


MEDIO


ALTO


ALTO


ALTO

Tabla 7. Niveles de Impacto por cada Riesgo

A continuación, se realiza la explicación por la cual se definieron los niveles de impacto para los seis riesgos identificados:

1. El impacto asociado es MEDIO, ya que si se obtienen las Llaves de un usuario valido se pueden acceder a datos altamente sensibles pues se trata de información médica tal como se analizó en la sección V.B.1.c).

2. El impacto asociado es MEDIO por la misma razón explicada anteriormente. 3. El impacto asociado es MEDIO por la misma razón explicada anteriormente. 4. El impacto asociado es ALTO pues si se modifican o eliminan las reglas de

control de acceso podría ser posible acceder a información sensible y restringida. Adicionalmente, debido a la sensibilidad de la información podría poner en peligro la vida de una persona en particular, por tanto podría ser objeto de chantajes, extorsión o secuestro.

5. El impacto asociado es ALTO por la misma razón explicada anteriormente. 6. El impacto asociado es ALTO porque una indisponibilidad en el sistema puede

ocasionar la muerte de un ser humano, en el caso de que no sea posible consultar la historia clínica de un paciente y por tanto tomar una decisión médica equivocada.

7. Determinación de Niveles de Riesgo La determinación de los niveles de riesgo es la etapa en la cual se conocen los riesgos más importantes y por ende es posible planear controles de seguridad que mitiguen



riesgos de acuerdo con su nivel, en otras palabras es posible priorizar que riesgos se pueden mitigar teniendo en cuenta la relación costo-beneficio. Para conocer el nivel el riesgo, es necesario conocer tanto el nivel de probabilidad con la cual puede ocurrir junto el nivel de impacto del mismo. Para esto se utilizaran los valores estándar definidos en la Tabla 8.

BAJO

(10)

MEDIO

(50)

ALTO

(100)

ALTO

(1.0)

BAJO

10 x 1,0 = 10

MEDIO

50 x 1,0 = 50

ALTO

100 x 1,0 = 100

MEDIO

(0,5)

BAJO

10 x 0,5 = 5

MEDIO

50 x 0,5 = 25

MEDIO

100 x 0,5 = 50

BAJO

(0,1)

BAJO

10 x 0,1 = 1

BAJO

50 x 0,1 = 5

BAJO

100 x 0,1 = 10

Probabilidad

Impacto

Tabla 8. Definición de Niveles de Riesgo. [19]

Dada esta clasificación de niveles riesgo y conociendo los niveles de probabilidad y de impacto de cada riesgo, a continuación se procede a realizar la clasificación de cada riesgo identificado para el sistema de información. Dicha clasificación se puede observar en la Tabla 9.

Riesgo Nivel de Probabilidad Nivel de Impacto Nivel de Riesgo


MEDIO MEDIO MEDIO


MEDIO MEDIO MEDIO


MEDIO MEDIO MEDIO


ALTO ALTO ALTO


ALTO ALTO ALTO


MEDIO ALTO MEDIO

Tabla 9. Niveles de Clasificación para cada Riesgo del Sistema de Información Integrado

Conjuntamente, en la Tabla 10 se anexa una matriz de riesgos donde se ubica cada riesgo. Los riesgos más prioritarios de mitigar se acercan más al extremo superior derecho.



BAJO MEDIO ALTO

ALTO R4, R5

MEDIO R1, R2, R3 R6

PR

IOR

IDA

D

BAJO

PRIORIDAD

Probabilidad

Impacto

Tabla 10. Matriz de Riesgos de los Riesgos Identificados.

En conclusión los riesgos con mayor prioridad de mitigación son los número cuatro (4) y cinco (5), seguidos por el riesgo seis (6) y finalmente los riesgos uno (1), dos (2) y tres (3). De esta manera los riesgos quedan ordenados de esta manera:

R4. Eliminación y/o Modificación de Reglas de Control de Acceso que Impiden el Acceso (Consulta, Modificación, Borrado) a Datos Privilegiados.

R5. Acceso (Consulta, Modificación, Borrado) a Datos Privilegiados. R6. Indisponibilidad del Sistema de Información a Usuarios Autorizados. R1. Interceptación de Llaves y Certificados para el acceso al sistema de forma

indebida. R2. Interceptación de Llaves y Certificados para suplantar a un Usuario. R3. Obtención de Contraseñas para conseguir certificados válidos.

8. Recomendaciones de Controles y Conclusiones del Análisis Habiendo clasificado los riesgos asociados al sistema integrado de información para el sector salud, se puede observar que el menor de ellos es de nivel MEDIO y el mayor es ALTO. Lo anterior implica que es absolutamente necesario tomar medidas de mitigación en corto plazo. Debido a la sensibilidad de la información que el sistema maneja y a la criticidad de las funcionalidades que éste presta se requiere entonces que dichas medidas sean asumidas y solucionadas; no se permitirá que los riesgos sean mitigados transfiriéndolos a terceros ya que las leyes existentes no permiten dicho manejo de riesgo. La mitigación de riesgos se realiza por medio de controles de seguridad, los cuales deben constituir una “Seguridad Integral”. En otras palabras, se deben plantear una serie de



controles y no un único control, ya que no se logra la seguridad ideal con solamente considerar un control. Considerando lo anterior se proponen estas soluciones: Primero, es necesario diseñar e implementar nuevos esquemas de Autenticación y de Autorización para la infraestructura Globus Toolkit. Estos esquemas deben considerar los riesgos identificados y deben tenerlos en cuenta desde las etapas de diseño de las arquitecturas. Adicionalmente, estos esquemas deben ser altamente acoplables e independientes del sistema de información con el fin de que estos puedan ser utilizados para otro tipo de sistemas de información. Por ende, los nuevos esquemas deben cumplir los siguientes requerimientos:

Esquema de Autenticación: 1. Sistema federado, que sea altamente escalable y que no afecte la disponibilidad

del sistema de forma total cuando el servicio de autenticación sufra inconvenientes.

2. Compatible con los esquemas de Autenticación de Globus Toolkit. 3. Permitir manejo de información de usuarios tal como identificador de usuario,

nombre, perfil de usuario, organización a la cual pertenece. 4. Administración de perfiles y usuarios. 5. Dificultar la intercepción y/o robo de credenciales de autenticación.

Esquema de Autorización: 1. Sistema federado, que sea altamente escalable y que no afecte la disponibilidad

del sistema de forma total cuando el servicio sufra inconvenientes. 2. Definición de reglas de control de acceso a nivel de entidades de datos. 3. Definición de reglas de control de acceso en términos de perfiles de usuario,

usuarios puntuales, reglas dinámicas dependiendo de atributos de ambiente. 4. Ofrecer protección de reglas de control de acceso, como ciframiento, integridad

y que al ser eliminadas no implique dar un acceso que antes estaba denegado. 5. Prevenir ataques de replicación de mensajes de accesos válidos. 6. Prevenir el acceso a las fuentes de datos sin que se haya dado el acceso por el

sistema de autorización. Finalmente, existen controles adicionales a nivel de hardware de la infraestructura. Un control que debe ser tenido en cuenta es la realización de Aseguramiento de Plataforma (hardening) a cada uno de los nodos participantes, especialmente para las fuentes de datos. La idea de lo anterior es poder contar con un ambiente seguro y que dificulte ataques directos a los nodos participantes en la Grid. Una buena guía de aseguramiento se puede encontrar en [21].



Por otra parte, deben tenerse en cuenta los aseguramientos a nivel de red tales como Firewalls y Switches. Una de las problemáticas en la infraestructura Grid es la imposibilidad de establecer reglas de control de acceso en los dispositivos de red, dado que muchas de estas infraestructuras son de utilización abierta. Esta funcionalidad abre una vulnerabilidad en los computadores que forman parte de la Grid, ya que se encuentran accesibles tanto por usuarios legítimos como por atacantes que pueden aprovechar este acceso para realizar hacking. Por esta razón es necesario idear un control de acceso dinámico para permitir el ingreso a los usuarios legítimos y denegar accesos a usuarios no autenticados.



VI. Propuesta de Solución En esta sección se realizará la descripción del diseño y del funcionamiento de unos de los controles propuesto para la mitigación de los riesgos enunciados en la sección anterior. El control referido son los Esquemas de Autenticación y de Autorización. Primero se describirá la arquitectura global de estos esquemas que incluye las decisiones de diseño y la integración con el sistema de información integrado. Por último, se detallará el diseño de los esquemas de autenticación y autorización, enunciando sus componentes y las decisiones realizadas para el diseño de tales arquitecturas.

A. Arquitectura Global de la Solución El sistema integrado de salud está conformado de diferentes servicios basados en webservices, con el fin de proveer la integración necesaria para las distintas fuentes de datos. La preocupación principal es proveer un mecanismo de autenticación al sistema y de autorización para el acceso a las fuentes de datos a nivel de entidades de datos. Dichos mecanismos, al igual que los servicios de integración, debe proveerse a través de webservices y deben ser totalmente desacoplados de la infraestructura. Tal orientación a servicios hace necesario que los servicios de seguridad provean una especie de token o certificado, que permita la identificación frente a los servicios existentes y restrinja el acceso a los servicios que ofrece el sistema. Además es necesario que tales mensajes no sean vulnerables a ataques de replicación (ataque que consiste en la interceptación de un mensaje valido y utilizarlo posteriormente para un acceso no autorizado) y a ataques de modificación indebida.

Figura 9. Arquitectura Global de Servicios



En la Figura 9 se puede ver la arquitectura global de la aplicación, con el intercambio de mensajes entre cada uno de los servicios del sistema de información. También se puede observar la localización de los servicios de autenticación y autorización. En cuanto al servicio de autorización es el punto de entrada al sistema de información. Con el fin de permitir la integración con la infraestructura Globus Toolkit, este servicio recibirá como entrada un nombre de usuario y contraseña, y retornará un certificado que será utilizado por Globus Toolkit para usar la autenticación mutua por certificados digitales. Por otro lado, el servicio autorización es utilizado por el servicio de wrapping (el cual es el encargado de la interacción entre el sistema de información y las fuentes de datos) para poder realizar peticiones de autorización a acceso de datos. Para este servicio es necesario expresar las reglas de control de acceso en términos de la ontología general utilizada para el sistema de información. Por último para permitir la integración con los demás servicios, este servicio expedirá tokens que serán utilizados para obtener el acceso a las fuentes de datos. Este token será derivado de una serie de atributos, entre estos una estampa de tiempo que evitará ataques de replicación.

B. Esquema de Autenticación

1. Descripción de la Problemática El mayor problema de identificar usuarios en un sistema Grid es el mantenimiento de las listas de usuarios de manera escalable, ya que muchos esquemas exigen listas de usuarios centralizados exigiendo grandes capacidades de almacenamiento y convirtiendo estos esquemas sensibles a ataque de denegación de servicio; pues en muchos casos la indisponibilidad del servicio centralizado, afecta el funcionamiento total del sistema. Adicionalmente, un problema presentado en los sistemas de autenticación consiste en el manejo de listas de revocación, dado que muchos sistemas Grid utilizan un esquema de autenticación por certificados digitales. El problema radica en establecer un mecanismo de revocación en el caso que la llave privada asociada a un certificado sea comprometido. Entonces, la idea es diseñar un sistema de autenticación escalable, administrable, que sea fácilmente integrable y que se exponga lo menos posible al robo de identidades.

2. Descripción de la Solución Este servicio puede ser utilizado por cualquier infraestructura Grid que permite la autenticación al sistema Grid y a cualquier componente o recurso igualmente autenticado.



El servicio mantiene una lista de usuarios distribuida, organizada por organizaciones o segmentos, así cada segmento autentica a sus usuarios y permite el ingreso a cualquier recurso o servicio en la Grid. Para notificar que la autenticación se realizó a los demás participantes de la Grid, el servicio local de autenticación expide un certificado de corta duración, es decir con certificados con validez de un periodo corto de tiempo, con lo que se elimina la idea de mantener listas de revocación de certificados. Adicionalmente, este servicio es compatible con aplicaciones kerberizadas y con la autenticación a través de certificados, lo que lo hace compatibles con infraestructuras de Grid como Globus Toolkit o OGSA-DAI, por lo que debe utilizar en este punto los servicios de autenticación de la plataforma de Grid sobre la cual este servicio está instalado. Finalmente, este servicio se presta en dos niveles. El primero consiste a nivel de nodos y/o recursos que pertenecen a la Grid, con el cual se establecen canales seguros de autenticación, mientras que el segundo corresponde a nivel de usuario del sistema, en el cual se definen perfiles, identificadores de usuario y pertenencias a organizaciones.

3. Arquitectura de la Solución

a) Diseño

El servicio de autenticación es proveído por un servidor de Kerberos, el cual presta servicios de autenticación de usuarios a través de REALMS. Cada REALM está determinado por una federación que contiene y autentica a los usuarios pertenecientes a ésta. La arquitectura está divida por jerarquías, es decir cada servidor Kerberos puede tener hijos y puede tener un padre. Tales jerarquías se encuentran expresadas por el nombre del REALM, es decir si un servidor Kerberos raíz tiene un REALM (realm-padre), el hijo debe tener como su REALM parte del REALM de su padre (realm-hijo.realm-padre). Una federación es representada por un servidor Kerberos, con lo que si se afecta la disponibilidad un servidor de Kerberos se afectaría la disponibilidad de los recursos y usuarios registrados pertenecientes a ésta.



Figura 10. Arquitectura de Autenticación

En la Figura 10 se muestra la arquitectura de autenticación anteriormente descrita. Como vemos, una federación puede ser vista como un nodo más desde su federación padre. Por otra parte, el servicio de autenticación está compuesto por un elemento llamado KCA, el cual constituye la pieza central del funcionamiento del servicio y representa las jerarquías y federaciones anteriormente mencionadas.

(1) KCA Un KCA está compuesto por un servidor Kerberos y un por una entidad certificadora (CA), con dichos elementos, un KCA puede ofrecer los servicios de autenticación mediante el esquema de certificados digitales. La conformación de los KCA como jerarquía inicia por una serie de servidores KCA raíz, los cuales corresponden a servidores replicados donde uno de estos es un maestro y los demás son esclavos. La idea es proveer un nivel de redundancia al más alto nivel. Luego en los niveles más bajos, se estructuran jerarquía de KCA, en donde un KCA debe tener un KCA padre y a su vez puede tener KCA hijos. En esta arquitectura deben existir vínculos de confianza entre un padre y sus hijos, para que la autenticación global funcione y se establezcan vínculos de confianza transitivos entre padres e hijo de otras federaciones. Esto implica que si se tiene una cadena de



confianza entre dos KCA hijos A y B, y un KCA entre A y B se cae la relación de confianza entre A y B se rompe. Gracias a este esquema, cada KCA o REALM es el encargado de la administración de sus usuarios, pero los perfiles del sistema solo deben ser administrados por los KCA raíz. Debido a lo anterior, se permite que la administración de los usuarios sea autónoma, evitando cargas administrativas en los niveles superiores. Por último, la autenticación de certificados mediante el KCA funciona debido a la transición del esquema de seguridad, ya que para la expedición de certificados digitales, es necesario poseer un tiquete de autenticación otorgado por Kerberos, el cual debe ser entregado a la entidad certificadora. En otras palabras, solo un usuario con un nombre de usuario y una contraseña puede obtener un certificado digital.

(2) Certificados Digitales, Usuarios y Perfiles Gracias a esta arquitectura, la administración de usuarios se centraliza en servidores Kerberos, los cuales pueden ser servidores de autenticación utilizados por otras aplicaciones de cada organización, con el fin de eliminar la necesidad de tener diferentes nombres de usuario para diferentes aplicaciones y alcanzar un esquema de Single Sign

On. Para el sistema integrado del sector salud la información de un usuario está contenida en un certificado digital y está compuesta por:

• Usuario: nombre de usuario que debe ser único en un dominio. • Identificador de Usuario: Número de identificación tal como un número de cédula o

número de seguridad social, etc. • Perfil(es): Grupo o nivel de usuario que tiene la persona en el sistema. • Realm: Dominio u organización al cual pertenece el usuario.

Esta información se encuentra almacenada en el campo Subject del certificado digital en codificación X.500 de la siguiente manera:

CN=(usuario), UID=(identificador), O=(realm), OU=(perfil1), …[OU=(perfiln)]

(3) Administración de Usuarios y Perfiles Toda la información de los usuarios es almacenada por un servidor LDAP19 que se encuentra integrado al servidor Kerberos. La información que corresponde al nombre de usuario y contraseña, es manejada y administrada por la implementación del servidor Kerberos utilizado (en este caso MIT-Kerberos); mientras que la información relacionada

19 Lightweight Directory Access Protocol



con los perfiles de usuario y los identificadores del mismo es administrada aparte en otro subárbol del mismo servidor LDAP. La información de los perfiles es almacenada en el subárbol CN=(perfil),DC=(realm) y para relacionar a un perfil con el usuario se almacena en el subárbol CN=(usuario),CN=(perfil),DC=(realm) con los atributos CN=(usuario) y SN=(identificador).

(4) Niveles de Autenticación Para la arquitectura se han determinado dos niveles de autenticación. El primero permite crear vínculos de confianza entre cada de los nodos del sistema y el segundo permite identificar a los usuarios que ingresan al sistema.

Figura 11. Niveles de Autenticación

En la Figura 11 se ilustra los dos niveles de autenticación. El primer túnel de comunicación se obtiene mediante el servicio de autenticación por certificados de Globus, mientras que el segundo se obtiene mediante el ciframiento entre la comunicación del usuario y los servicios que éste llama. Adicionalmente, es necesario que tanto como usuarios y servicios se encuentren autenticados y ambas partes posean sus certificados, para luego establecer una llave de sesión que va a ser usada para el ciframiento. Para el establecimiento de la llave se utiliza el protocolo Diffie-Helman Autenticado usando los certificados digitales para realizar una autenticación mutua (usuario-servicio, servicio-servicio).



b) Diagrama de Componentes

Figura 12. Diagrama de Componentes Servicio Autenticación

En la Figura 12 se puede ver el diagrama de componentes del Esquema de Autenticación, que consiste en tres componentes: KCA, InfoProtector y EndPointAuth.

(1) KCA Este componente se encarga del manejo relacionado con la autenticación de usuario, expedir certificados y lo relacionado con la administración de usuarios y perfiles. El KCA debe existir por cada REALM que se quiera constituir y debe estar en el nodo que va a actuar como rol de KCA.

Figura 13. Funcionamiento del Componente KCA

La Figura 13 muestra como está compuesto el componente KCA. Por un lado se observa un servidor Kerberos y por otro una CA. El servidor Kerberos se encarga de autenticar a los usuarios y guardar información del usuario y de los perfiles; mientras que el servidor de CA se encarga de la expedición de certificados. El servidor Kerberos se encuentra integrado con LDAP que permite el almacenamiento de la información del usuario y permite realizar búsquedas rápidas. Por otra parte, la CA es una aplicación kerberizada, es decir solo permite conexiones por parte de usuarios que han sido autenticados por un servidor Kerberos. Su funcionalidad principal es generar certificados digitales (Certificados X.509) a través de librerías de Bouncycastle.



Para poder generar certificados, es necesario que el usuario realice una genere una pareja de llaves (pública y privada) y le envíe la llave pública a la CA para que ésta la firme y genere el certificado digital que va a ser usado para la autenticación y el cifrado de la información en el sistema.

(2) InfoProtector Este componente se encarga del ciframiento de la información intercambiada del usuario con los demás servicios, es decir ofrece una protección adicional al ofrecido por el servicio de confidencialidad de Globus Toolkit. Éste puede ser localizado como un servicio de Globus o puede ser instanciado en cada nodo. El InfoProtector usa la librería de Bouncycastle usando algoritmos de ciframiento asimétricos. El algoritmo a utilizar es el RSA con longitud de llave de 1024 bits para ajustarse a las recomendaciones del NIST.

(3) EndPointAuth El EndPointAuth se encarga de realizar la autenticación entre dos puntos autenticados (usuario-servicio y servicio-servicio) y de establecer la llave privada para la comunicación de datos. Para realizar esto, es necesario intervenir la comunicación de servicios de Globus Toolkit y realizar el siguiente protocolo:

1. Cada punto obtiene su certificado mediante el proceso de autenticación anteriormente descrito.

2. Cada punto se autentica mediante el procedimiento de challenge-response. 3. Se establece una llave simétrica que será utilizada para el ciframiento de la

información que se intercambia.

c) Restricciones y Supuestos

El servicio de autenticación presenta tres restricciones debido a su diseño arquitectónico, el cual impide mantener repositorios de usuarios del sistema. La primera restricción se presenta cuando un usuario cualquiera interactúa con dos o más REALMS o dominios, ya que si se registra un usuario en el realm1 en el momento del registro del mismo usuario en el realm2, éste último no tiene conocimiento de la existencia del usuario en el primero. Por esta razón, los usuarios están compuestos por <nombreusuario>@<realm> lo que permite caracterizar la unicidad de los mismos. Esta restricción no afecta de ninguna manera la autenticación de los usuarios, ya que cualquier usuario puede autenticarse desde cualquier REALM y acceder a todos los nodos y/o recursos que están autenticados en la Grid; el inconveniente surge a la hora de



entrar en la fase de autorización, pues si las reglas de control de acceso son especificadas en términos de REALM y si el usuario está autenticado con un REALM distinto, entonces no podrá tener acceso a la información. Para evitar esta restricción se recomienda que además de especificar las reglas en términos de REALM, se deba incluir reglas con condiciones dependientes de identificaciones de usuario tales como número de identificación (ej. Cédula, NIT, número de seguridad social, etc.). También es posible permitir a los usuarios autenticarse a varios REALM, con el fin que al momento de realizar la autorización se presenten todos los certificados y obtener la autorización por alguno de éstos. La segunda restricción se presenta en el caso de manejo de perfiles, debido a que no se puede obtener un estado global de perfiles en todo el sistema, por lo que se restringe a que la creación de perfiles se realice desde los KCA raíz y se replique dicha creación hacia los demás REALMS. Por último la tercera restricción radica en la utilización de certificados de corta duración, pues es necesario que para que un usuario se mantenga en el sistema accediendo la misma información, se requiere que el usuario se vuelva autenticar renovando su certificado y utilizando la misma pareja de llaves. Para que esto sea transparente para el usuario, es necesario contar con un demonio de autenticación que se percate de esos cambios y renueve el certificado.

d) Proceso de Autenticación

En un escenario típico para un sistema de información, suponga que se tienen dos organizaciones que tienen acceso a la Grid, para este caso las organizaciones son org1 y org2. Además cada una de estas posee y administra su propia KCA. En la Figura 14 se puede ver este ejemplo.

Figura 14. Proceso de Autenticación



Para un usuario realizar la autenticación al sistema Grid perteneciente a la organización org1 debe realizar lo siguiente:

1. Proveer un nombre de usuario y una contraseña. 2. Contactar al servicio de autenticación. 3. El servicio de autenticación contacta al KCA correspondiente al usuario mediante

una búsqueda en DNS utilizando el REALM (Esta búsqueda se realiza a través del registro SRV del servicio _udp._kerberos.

4. Se autentica el usuario y obtiene un certificado digital. 5. El certificado debe ser pasado a través de los servicios que se desean ejecutar. 6. Cada servicio verifica la validez del certificado y cifra los resultados con una llave

de sesión que va cifrado con la llave pública contenida en el certificado.

e) Interfaces del Servicio

Aquí se expondrán las diferentes funcionalidades ofrecidas por el Servicio de Autenticación, tal como se muestra en la Tabla 11.

Nombre addUser Nombre addProfile

Nombre removeUser Nombre Authenticate

Nombre Cipher Nombre Decipher

Entradas

Datos a Descifrar

Llave

Salidas

Datos Descifrados

Entradas

Datos a Cifrar

Llave

Salidas

Datos Cifrados

Llave Pública

Salidas

Certificado Digital

Descripción

Cifra la información con una llave

Descripción

Descifra la información con una llave

Salidas

Ninguna

Descripción

Se encarga de autenticar el usuario

en el sistema

Entradas

Nombre de Usuario (Con realm)

Contraseña

Salidas

Ninguna

Descripción

Se encarga de la eliminación de

usuarios en un Realm determinado

Entradas


Ninguna

Contraseña

Descripción

Se encarga del registro de perfiles en

un Realm determinado

Entradas

Nombre de Perfil

Descripción

Se encarga del registro de usuarios en

un Realm determinado

Entradas

Salidas


Perfil(es)

Número de Identificación

Tabla 11. Interfaces del Servicio de Autenticación



C. Esquema de Autorización

1. Descripción de la Problemática En la actualidad las infraestructuras de Grid poseen mecanismos de autorización de acceso a recursos a través de directivas simples y especificación de usuarios. Tales directivas solo especifican si un usuario puede o no acceder a un nodo, pero no permiten definir reglas de control de acceso con mayor nivel de detalle tal como entidades de datos y/o otros recursos. Además, el lenguaje usado para las reglas de control de acceso, no permite establecer condiciones dinámicas ni dependientes del contexto en el cual se realiza la petición de acceso tales como hora, dirección IP, usuario, etc. Finalmente, los sistemas Grid actuales no proveen ningún tipo de protección de integridad a las reglas, dejando como un punto vulnerable a modificación de las mismas y por ende al compromiso de la información que intentan proteger.

2. Descripción de la Solución Este servicio puede ser utilizado por parte de algún servicio que requiera verificar el acceso a un recurso por parte de un sujeto a realizar una acción. El servicio posee un componente llamado Policy Decision Point (PDP), el cual se encarga de recibir peticiones de acceso conformado por una triada que consiste en un sujeto, un recurso y una acción acompañada de atributos tales como hora de la petición y dirección IP. El PDP debe localizarse en cada fuente de datos, con el fin de que cada una de estas pueda garantizar la integridad y validez de las reglas de control de acceso y también que cada fuente decida si debe dar el acceso o no. Éste finalmente suministrará un token al servicio o usuario que está solicitando el acceso, para que después sea presentado a la interfaz que recibe las peticiones para que verifique la autenticidad del token. Para poder garantizar el funcionamiento adecuado en las infraestructuras de Grid actuales, es necesario realizar algunas modificaciones en las infraestructuras de Grid existentes. Para este caso se realizarán modificaciones al funcionamiento de OGSA-DAI para manejar la autorización de forma adecuada.

3. Arquitectura de la Solución El servicio de autenticación es proveído en el plano de la Grid y puede ser usado por cualquier servicio que lo requiera. Este servicio requiere como entrada:



• Certificado del usuario o servicio que desea hacer la petición • Consulta en formato SPARQL. • Consulta en formato MySQL. • Localización de la fuente de datos.

Por otro lado el servicio tiene como salida:

• Token de autorización, que relaciona el certificado del usuario, las dos consultas y una estampa de tiempo que indica la validez del token. Si el usuario no está autorizado, se retorna un token nulo.

(1) Punto de Decisión de Autorización Para el diseño de la arquitectura se tuvo en cuenta que las reglas deben estar protegidos adecuadamente mediante mecanismos de protección de integridad y confidencialidad tal como se recomienda en el documento de especificación de XACML. Con el fin de cumplir con este requerimiento, se decidió que el PDP y las reglas en XACML deben permanecer en la fuente de datos con mecanismos de protección adecuados y no deben salir de la fuente de datos. Lo anterior implica que la fuente de datos debe ser la responsable de tomar las decisiones sobre peticiones que se realicen sobre ésta.

Figura 15. Primera opción de llamado de servicio de autorización

Por otra parte, en la arquitectura se tomó en cuenta el punto de decisión de alguna acción sobre algún recurso. Para este caso se contaban con dos opciones. La primera opción era tomar la decisión en la fuente de datos, es decir que el llamado del servicio de autorización se realice en ésta tal como se muestra en la Figura 15. Esta opción no era viable, ya que en este punto se ha realizado la transformación entre los lenguajes Sparql y el lenguaje de la fuente de datos. Esto implica que se tiene una pérdida de procesamiento en el caso que la petición sea negada.



Figura 16. Segunda opción de llamado de servicio de autorización

La segunda opción consiste en tomar la decisión en el momento de materializar las consultas, es decir en el momento que se tienen las subconsultas dirigidas a cada fuente de datos tal como se muestra en la Figura 16. Esta opción necesita que se llame el servicio de autorización por cada subconsulta. Se debe notar que en ambas opciones las peticiones de autorización deben ir siempre a la fuente de datos, debido a las restricciones de seguridad mencionadas anteriormente.

(2) Definición de Atributos de Peticiones y Reglas Las reglas deben ser especificadas en lenguaje XACML en términos de Subject-

Resource-Action y se debe tener en cuenta que dependiendo como se especifique el Subject se obtenga una respuesta. Esto se debe a que el Subject se puede especificar en términos de perfil, Realm, nombre de usuario o funciones. Para poder expresar estos atributos, es necesario definir cuáles serán los atributos del lenguaje de XACML van a ser usados para su representación. Para el esquema de autorización los atributos utilizados y la forma de expresarlos son los siguientes:

• Nombre de Usuario: Se utilizará el atributo urn:oasis:names:tc:xacml:1.0:subject:subject-id expresado en formato RFC82220 de la forma <nombre usuario>@<realm> para expresar a un usuario específico, o @<realm> para expresar pertenencia a organizaciones.

• Perfil: Se utilizará el atributo urn:oasis:names:tc:xacml:2.0:subject:role del tipo String.

20 Formato de Nombres de Correo Electrónico



• Identificador de Usuario: Se usará el atributo urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier del tipo String.

• Recursos: Se usará el atributo urn:oasis:names:tc:xacml:1.0:resource:resource-id y se expresará en términos de XPath.

Vale la pena mencionar que la combinación de uno o más de cada uno de estos atributos se estará haciendo referencia a un Subject en particular.

b) Diagrama de Componentes

Figura 17. Diagrama de Componentes del Servicio de Autorización

(1) Parsing Este componente se encarga de la interpretación de una consulta en Sparql para su posterior transformación en una petición en formato XACML.

(2) PDP Este componente se encarga de recibir las peticiones del componente de parsing y se encarga de tomar la decisión de aceptar o denegar la petición. Para esto el PDP debe preguntarle al contenedor de reglas las reglas relacionadas con la triada Subject-

Resource-Action. Para realizar esta comunicación entre estos dos componentes, es necesario establecer en cada conexión una llave privada simétrica (sesión) para poder tener una protección adicional a la ofrecida por Grid. Luego el contenedor debe pasar las reglas relacionadas acompañadas de un resultado de hash de cada una para garantizar la integridad de las mismas. El procesamiento de la reglas se realiza de la forma del menor privilegio, es decir la respuesta por defecto es denegar y las reglas de control de acceso dan los accesos necesarios.



(3) RulesContainer El RulesContainer es el componente que se encarga de la protección y la custodia de las reglas proporcionadas por cada fuente de datos. Éste se encuentra localizado en cada fuente de datos y entrega las reglas relacionadas. Éste posee una interfaz para el registro de nuevas reglas en la fuente, el cual somete a una función de hash a cada una de estas, luego las cifra y las almacena en el disco, con el fin de ofrecer integridad y confidencialidad de las mismas. Al momento de realizar de procesar una regla, éste componente verifica la integridad de la misma y en el caso que no sea integra la regla es descartada. En el caso que una regla sea descarta no se verá afectada la seguridad del sistema dado a que las reglas solo dan permisos a ciertos usuarios, pero no los niega. En este caso sería propenso un caso de denegación de servicio en el caso que todas las reglas sean eliminadas.

(4) TokenGeneration Este componente se encarga de la generación del token de autorización que debe ser devuelto al servicio o usuario que llamo el servicio. El token está formado de la siguiente forma: Token = Cprifuente(Hash(<Query Sparql>) + Hash(<Query SQL>) + Certificado_Solicitante +

Certificado_Fuente + Cprisolicitante(Timestamp_Solicitante))

Es el ciframiento con la llave privada de la fuente de la concatenación del Hash de la consulta en sparql, el hash de la consulta en SQL, una estampa de tiempo en la cual se inició la solicitud del usuario cifrado con la llave privada del solicitante. Vale la pena mencionar que el token tiene una validez configurable, por lo que se exige que todos los relojes de los nodos participantes deban estar sincronizados. Para evitar que el token sufra ataques de replicación, se incluye en éste una estampa de tiempo. Ésta va cifrada con la llave privada del solicitante, con la cual se garantizará que el solicitante es en realidad el que dice ser. Tal estampa de tiempo será validada, verificando hace cuanto fue generado. Además, las fuentes de datos almacenarán los tokens utilizados hasta el tiempo de su validez para evitar su doble uso. El token resultante, debe ser pasado al usuario o servicio para que este a través de OGSA-DAI realice la consulta presentando el token, el cual debe ser verificado por OGSA-DAI.



c) Restricciones y Supuestos

Este servicio posee una restricción arquitectónica, dado a que se debe evitar los ataques dirigidos a las reglas de control de acceso, tales como modificación de las reglas, manipulación de las respuestas a peticiones de acceso. La restricción consiste que para todas las peticiones de acceso deben de pasar por la fuente de datos, es decir cada acceso debe ser autorizado por la misma fuente de datos, lo que implica una conexión adicional y por ende le añade latencia al procesamiento de cualquier petición.

d) Proceso de Autorización

Figura 18. Proceso de Autorización

Supóngase un médico autenticado y posee un certificado que indica que ha realizado su autenticación en el sistema.

1. El usuario contacta el servicio de consulta y le provee: La consulta a realizar, el certificado y la estampa de tiempo cifrada con la llave privada del usuario.

2. El servicio de consulta contacta al servicio de autorización pasándole los atributos proveídos por el usuario y la ubicación de la fuente.

3. El servicio de autorización contacta la fuente, en la cual el parsing procesa la consulta y genera una petición en XACML.

4. El motor PDP le solicita al contenedor de reglas las reglas que apliquen a dicha petición.



5. RulesContainer carga las reglas del disco, verifica las firmas digitales y las descifra (Este proceso se realiza al inicio del arranque del servicio). Luego buscas las reglas aplicables.

6. El PDP con las reglas aplicables decide si se puede realizar la acción o no. 7. Si se puede realizar la acción, se solicita al TokenGeneration la generación del

correspondiente token y lo retorna, de lo contrario retorna null. 8. El servicio de consulta ejecuta la consulta a través de OGSA-DAI pasándole el

token retornado. 9. La consulta llega a la fuente de datos, ésta verifica el token con los criterios de:

a. La consulta solicitada concuerde con el hash de la consulta en SQL del token.

b. El certificado del cliente solicitante concuerda con el del token. c. El certificado de la fuente concuerda con el del token. d. Descifra la estampa de tiempo con el certificado del usuario solicitante y

verifica la vigencia de dicha estampa. Tal vigencia es configurable por la fuente de datos.

e) Interfaces del Servicio

Aquí se expondrán las diferentes funcionalidades ofrecidas por el Servicio de Autorización, tal como se muestra en la Tabla 12.

Nombre addPolicy Nombre authorize

Nombre validate

Token de Autorización

Estampa de Tiempo Cifrada

Certificado de la Fuente

Token

Salidas

Respuesta que determina si es o no

válido

Query SQL

Entradas

Certificados de Usuario

Query Sparql

Salidas

Ninguna

Descripción

Se encarga de la validación de los

tokens

Query Sparql

Query SQL

Identificador de la Fuente

Localización del Archivo de Pruebas Certificados de Usuario

Salidas

Descripción Descripción

Se encarga del registro de politicas en

una fuente de datos. (Instanciado en

cada fuente de datos).

Se encarga de la autorización de los

accesos

Entradas Entradas

Tabla 12. Interfaces del Servicio de Autorización



VII. Implementación y Resultados

A. Esquema de Autenticación

1. Implementación Este esquema en su implementación fue separado en dos ambientes. El primero consiste en un webservice instanciado en Globus Toolkit que es el encargado de recibir las peticiones de los usuarios. El segundo, corresponde a un modelo cliente-servidor que se encarga de cumplir las funciones de KCA. El funcionamiento de este esquema depende de la interacción de estos ambientes, ya que el webservice se encarga de contactarse con el KCA correspondiente al usuario que se autentica.

Figura 19. Diagrama de Clases del Esquema de Autenticación

En la Figura 19 se puede ver el diagrama de clases que representa las entidades utilizadas para la implementación. Aquí se puede observar el KCA que implementa las



funcionalidades de autenticación y expedición de certificados; y los elementos KCAServer y KCAClient que realizan la conexión cliente-servidor.

2. Pruebas Las pruebas realizadas para el esquema de autenticación están orientadas al rendimiento en el proceso de autenticación. Para el escenario de las pruebas, se instalo un servidor Kerberos MIT integrado con LDAP. Las características de este servidor consistía en una máquina virtual con Fedora

Core 7 con procesador 1.83 Ghz y con memoria asignada de 512 Gb. Además del servidor Kerberos, éste también poseía el lado servidor del KCA, el cual generará los certificados de corta duración. El tiempo del proceso de autenticación está compuesto por el tiempo utilizado para consultar la base de datos en LDAP de Kerberos y el tiempo que se requiere para la generación de certificados digitales. Para el caso del último, el tiempo utilizado para la generación del certificado siempre va a ser el mismo. Dada las características de procesamiento, el tiempo utilizado por la implementación 1.200 ms, mientras que los tiempos de búsqueda variaban conforme aumentaban el número de usuarios registrados. La Tabla 13 muestra tales resultados.

Número de

Usuarios

Tiempo

(ms)

1000 1534

10000 1537

100000 1687

1000000 2228

Tabla 13. Comparación de Rendimiento con Respecto el Número de Usuarios



Por último, se tuvo en cuenta para medir el rendimiento se tomó en cuenta el tamaño ocupado por cada registro de usuario. El tamaño está dado por el tamaño del registro en la base de datos de Kerberos, el cual ocupa 700 bytes en promedio. Por otro lado, existe el tamaño utilizado para almacenar la información de la relación de pertenecía a un perfil que ocupa 100 bytes por cada relación. En conclusión cada registro de usuario ocupa en promedio 800 bytes.

B. Esquema de Autorización

1. Implementación Al igual que el Esquema de Autenticación, el Esquema de Autorización se encuentra divido en los ambientes de webservice y cliente-servidor. Al igual que el esquema anterior, el webservice se encarga de recibir las peticiones por parte de los usuarios y/o servicios, mientras que el ambiente cliente-servidor se encuentra instanciado en cada fuente de datos que desee publicar su información en la Grid.

Figura 20. Diagrama de Clases del Esquema de Autorización

En la Figura 20 se puede ver las clases utilizadas para la implementación del esquema de autorización, las cuales tienen una correspondencia con los componentes descritos anteriormente. Al igual que el esquema anterior, el XACMLServer y XACMLClient se encargan de la comunicación cliente-servidor para el procesamiento de la petición de autorización. Por otro lado, con el fin de realizar la integración adecuada con el ambiente de integración de datos utilizado (OGSA-DAI) se utilizaron mecanismos de interceptación a través de



webservices llamados Handlers; estos Handlers intervienen en el procesamiento de peticiones y respuestas de los webservices. Para más información ver [22]. Finalmente, para el procesamiento de las reglas se utilizo una versión modificada de una implementación de XACML realizada por Sun Microsystem's Research Laboratories el cual puede ser encontrado en [23].

2. Pruebas Las pruebas realizadas para el esquema de autorización están orientadas a nivel funcional y al rendimiento en el proceso de autorización. Vale la pena mencionar que las pruebas no incluyen el funcionamiento global de XACML, el cual ya fue debidamente probado por los desarrolladores del procesador de reglas. Para el escenario de las pruebas se instalo en el mismo servidor utilizado para las pruebas del esquema de autenticación, el cual incluía el servidor de autorización que contiene las reglas y realiza el proceso de autenticación. Los casos utilizados para las pruebas funcionales son los siguientes:

1. Regla expresada en términos de nombre de usuario. 2. Regla expresada en términos de REALM. 3. Regla expresada en términos de perfiles. 4. Regla expresada en términos de identificador de usuario.

Cada uno de estos casos incluye una regla que permite el acceso a un recurso en particular.

Número de

PruebaResultado

1 Exitosa

2 Exitosa

3 Exitosa

4 Exitosa Tabla 14. Resultados de Pruebas Funcionales

En la Tabla 14 se resume el resultado de las pruebas, las cuales tuvieron un resultado exitoso. Adicionalmente, se realizo otro caso de prueba que incluía la creación de dos reglas de control de acceso. Una que permitía el acceso y la otra que lo denegaba. El resultado obtenido a la petición de acceso fue denegado, ya que el sistema está diseñado para permitir acceso si no existe una regla que lo deniegue.



No obstante, éste último de caso no es un modelo recomendable para la definición de reglas pues se recomienda que solo se definan reglas que permitan el acceso, ya que la respuesta por defecto del esquema de autorización es la repuesta denegada. Por otro lado, para la evaluación del rendimiento de la implementación se utilizaron escenarios de pruebas con distintos volúmenes de reglas de reglas. En este caso los tiempos de procesamientos se deducen del proceso de ciframiento y firma de los archivos de reglas, y por el procesamiento de las peticiones de autorización. Vale la pena mencionar que el tiempo del primer proceso solo se lleva a cabo en el momento de la carga del sistema, es decir en el momento de la inicialización. A continuación en la Tabla 15 se muestran los resultados obtenidos para cada uno de los escenarios de prueba.

Carga de

ReglasProcesamiento

1 840 0

1.000 21.650 32

10.000 190.644 286

100.000 2.033.407 3.426

1.000.000 30.108.444 10.323

Tiempo (ms) Número de

Reglas

Tabla 15. Comparación de Rendimiento con Respecto al Número de Reglas



Finalmente, al igual en la evaluación de desempeño del esquema de autenticación se tuvo en cuenta los recursos de almacenamiento utilizados para el almacenamiento de las reglas de control de acceso. En esta implementación el tamaño de una regla cifrada y firmada es de 4.432 Bytes lo cual constituye un espacio lo suficientemente tolerable debido a la cantidad de atributos y de expresiones que es posible de expresar.



VIII. Conclusiones y Trabajo Futuro

A. Conclusiones La propuesta de esta tesis consistió en el diseño e implementación de un esquema de seguridad para un sistema integrado de información basado en Grid, el cual ofrece un control de seguridad adecuado para los riesgos informáticos presentados en dicha infraestructura. El diseño de este esquema no son una serie de controles de seguridad propuestos sin ningún tipo de marco de referencia, sino que se basa en un análisis que contempla una serie de riesgos que no han sido debidamente mitigados por las infraestructuras de integración de información que existen en la actualidad. Por una parte el esquema de autenticación permite la kerberización de las infraestructuras Grid, es decir que permite la integración de estas infraestructuras a un sistema de autenticación centralizada y de Single Sign On lo que permite una integración de todas las aplicaciones de una compañía a nivel de autenticación. Gracias a la utilización de servidores Kerberos la solución permite la federación del sistema de autenticación. Lo anterior hace al sistema altamente escalable, ya que se permite tantas federaciones como sea posible y tanto que facilite la administración de usuarios. Este esquema a su vez pretende la reutilización de los controles de autenticación de Globus Toolkit a través de certificados digitales. Lo anterior permite una fácil integración de la solución y no implica modificaciones al sistema. Además, esta solución contempla la utilización de certificados digitales de corta duración con el fin de exponer de menor forma la confidencialidad de las llaves privadas y por lo tanto el acceso a datos privilegiados. Una característica añadida a la solución introduce la autenticación a nivel de usuarios y servicios, con el fin de evitar introducción de servicios maliciosos no permitidos en un nodo debidamente autenticado en el sistema. Por otro lado, la solución considera un esquema de autorización el cual utiliza un sistema de expresión de reglas tan amplio y estandarizado como XACML. Tal decisión permite que la solución facilite la definición de reglas de control de acceso a recursos más específicos y granulares como entidades de datos de una ontología, entidades de una base de datos, accesos a archivos, accesos a recursos computaciones y entre otros.



En suma, la solución permite la utilización de reglas dinámicas a condiciones de ambientes o atributos de pertenencia y/o de utilización, en otras palabras se introduce las ventajas de XACML a una infraestructura Grid. También, el sistema de autorización se encuentra diseñado de forma federada. Es decir, cada fuente de datos es la responsable de la custodia y protección de reglas, y de responder a peticiones de autorización. Esta propuesta no solo contempla el proceso de autorización, también garantiza la protección adecuada de las reglas de control de acceso en términos de confidencialidad e integridad. Lo anterior certifica un proceso de autorización bajo ningún tipo de intervención por parte de un usuario mal intencionado. Adicionalmente, con el fin de permitir una integración con las infraestructuras Grid existentes se utilizó la notación de autorización a través de token, el cual permite el acceso a un recurso y lo deniega si no se presenta. Para poder implementar esta característica se recurrió a mecanismos de interceptación de peticiones que son los encargados de verificar la validez del token. Finalmente, en la Tabla 16 se incluye una comparación de la propuesta de tesis contra los controles de los demás infraestructuras de integración.

CriterioUniversal Patient

Record

Red Médica

P2P

Sistema de

Salud GridSII Globus Toolkit Propuesta Tesis

Confidencialidad NO SI SI SI SI SI

Integridad NO SI SI SI SI SI

Autenticidad NO SI SI SI SI SI

Autenticación NO SI SI SI SI SI

Autorización NO SI SI SI SI SI

Privacidad NO NO NO SI NO NO

Auditoria NO NO SI SI NO NO

Arquitectura

Sistema

Autenticación

N/A Centralizado Centralizado Centralizado Centralizado Federado

Tipo de

AutenticaciónN/A

Certificados

Digitales

Certificados

Digitales

Contraseña.

Tokens.

Single Sign On.

Certificados

Digitales.

Single Sign On.

Certificados

Digitales.

Single Sign On.

Dificultades

AutenticaciónN/A

Revocación de

Certificados

Revocación de

Certificados

Revocación de

Tokens.

Revocación de

Certificados

Renovación de

Certificados de

Corta Duración

Arquitectura

Sistema

Autorización

N/A Federado Federado Federado Federado Federado

Tipo de Reglas de

Control de AccesoN/A Roles Roles

Roles.

Estáticas por

recurso.

Roles

Roles

Dinámicas

Estáticas

Protección Reglas

de Control de

Acceso

N/A Ninguno Ninguno Ninguno NingunoConfidencialidad

Integridad

Lenguaje Reglas de

Control de AccesoN/A Propietario Propietario P3P

SAML.

Propietario.XACML

Tabla 16. Comparación de Factores de Seguridad entre las Arquitecturas de Integración y la Propuesta de Solución



B. Trabajo Futuro Con el fin de desarrollar y de mejorar un esquema de seguridad se proponen seis nuevos requerimientos que deben ser tenidos en cuenta para el futuro. Primero, se requiere una administración adecuada para el manejo de perfiles. Lo anterior se debe a la arquitectura federada del esquema de autenticación no permite una actualización adecuada de la información de los perfiles en todos los KCA. Para poder solucionar esto, se propone un esquema de replicación de la información de los perfiles a todos los servidores de autenticación. Segundo, se necesita un sistema automático de renovación de certificados y de administración de llaves. Esto se debe a la utilización de certificados de corta duración utilizados para la autenticación, ya que si un certificado se vence en el momento que el usuario se encuentre autenticado en la actualidad se niega el acceso al sistema. Por esta razón se requiere un sistema que permita la renovación del certificado ante el KCA. Adicionalmente, el sistema de administración de llaves es requerida para el caso que se requiera acceder información cifradas con llaves pertenecientes a sesiones anteriores. Tercero, sería útil contar con una interfaz gráfica que permita la construcción de reglas de control de acceso con el fin de generar los archivos en XACML que serán utilizados para ingresarlos al sistema. Cuarto, al igual que se desea un sistema de edición de reglas, sería ideal tener con un sistema gráfico de administración de usuarios y perfiles que permita la adición de usuarios a través de una interfaz amigable para el administrador de usuarios. Quinto, se requiere el diseño de una arquitectura de auditoría que consiste en el almacenamiento de las transacciones realizadas por los usuarios del sistema de información. Dicha arquitectura debe ser capaz de permitir consultar a los usuarios quienes han accedido a su información y para qué propósito, incluyendo fecha, hora y fuentes de datos involucradas. Por último, del análisis de riesgos se identifico la necesidad de la existencia de un control que permite la autorización de accesos de nodos pertenecientes a la Grid. Para esto último se propone de la utilización del token generado por el esquema de autorización por parte de los dispositivos de seguridad de red, lo anterior con el fin de garantizar una integración de los controles a distintos niveles hardware-software.



Bibliografía [1] B. Cliford, T. Ts’o. Kerberos: An Authentication Service for Computer Networks. IEEE Communications Magazine, Volume 32, Number 9, pages 33-38, September 1994. [2] John T. Kohl, B. Clifford Neuman, and Theodore Y. T'so, The Evolution of the Kerberos Authentication System. Distributed Open Systems, pp78–94. IEEE Computer Society Press, 1994. [3] Kerberos Operation. Disponible en: http://www.xml-dev.com/blog/index.php?action=viewtopic&id=21 [4] Kerberos Protocol. Wikipedia Disponible en: http://en.wikipedia.org/wiki/Kerberos_(protocol) [5] Richard D, Hu V, Timothy P, Chang S. Introduction to Public Key Technology and the Federal PKI Infrastructure. SP 800-32. Nist Special Publications. 2001. [6] OASIS. eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS Standard. 2005. [7] Cover Pages. eXtensible Access Control Markup Language (XACML). Disponible en: http://xml.coverpages.org/xacml.html [8] R. Agrawal, J. Kiernan, R. Srikant, Y. Xu. “Hippocratic Databases”. Proceedings of the 28th VLDB Conference. Hong Kong. 2002. [9] K. LeFevre, R. Agrawal, V. Ercegovac, R. Ramakrishnan, Y.Xu, D. DeWitt. “Limiting Disclosure in Hippocratic Databases”. Proceedings of the 30th VLDB Conference. Hong Kong. 2004. [10] R. Agrawal, A. Kini, K. LeFevre, A. Wang, Y.Xu, D. Zhou. “Managing Healthcare Data Hippocratically”. Sigmod 2004. Paris, France. 2004. [11] R. Agrawal, D. Asonov, R. Bayardo, T. Grandison, C.Johnson, J. Kiernan. “Managing Disclosure of Private Health Data with Hippocratic Databases”. IBM Research. USA. 2005. [12] R. Agrawal, A. Evfimievski, R. Srikant. “Information Sharing Across Private Databases”. Sigmod 2003. USA. 2003. [13] R. Agrawal, R. Srikant, D. Asonov. “Enabling Sovereign Information Sharing Using Web Services”. Sigmod 2004. Paris, France. 2004. [14] R. Agrawal, D. Asonov, P. Baliga, L. Liang, B. Porst, R. Srikant. “A Reusable Platform for Building Sovereign Information Sharing Applications”. First Workshop on Databases in Virtual Organizations. Paris, France. June 2004.



[15] M. McGuire. “Incorporating an EPR System with a Universal Patient Record”. October 29 de 2005. [16] M. Ilias, D. Constantinos, K. Leonidas. “Enabling Collaborative Medical Diagnosis Over the Internet via Peer-to-Peer Distribution of Electronic Health Records”. J Med Syst (2006) 30:107–116; 2006. [17] I. Bilykh, Y. Bychkov, D. Dahlem, J. H. Jahnke, G. McCallum, C. Obry, A. Onabajo, c. Kuziemsky. “Can grid services provide answers to the challenges of National Health Information Sharing?”. Proceedings of the 2003 conference of the Centre for Advanced Studies on Collaborative Research. Toronto, Ontario, Canada. 2003 [18] Globus Alliance. Globus Toolkit. Disponible en: http://www.globus.org/toolkit/docs/4.0/ [19] Stoneburner G, Goguen A, Feringa A. Risk Management Guide for Information Technology Systems. SP 800-30. Nist Special Publications. 2002. [20] Congreso de la Republica de Colombia, “Ley Nº 23 de 1981 Normas en Materia Ética”. Diario Oficial No. 35.711. 27 de febrero de 1981. [21] Homsher L. Linux Security Checklist. Disponible en: http://www.sans.org/score/checklists/linuxchecklist.pdf [22] Apache. Webservices – Axis. Architecture Disponible en: http://ws.apache.org/axis/java/architecture-guide.html [23] Sun Microsystem's Research Laboratories. SUN’s XACML Implementation Disponible en: http://sunxacml.sourceforge.net/ [24] Clifford B. Proxy-Based Authorization and Accounting for Distributed Systems. University of Southern California. 1993. [25] Vullings E, Buchhorn M, Dalziel J. Secure Federated Access to GRID applications using SAML/XACML. 2006. [26] Doster W, Watts M, Hyde D. The KX.509 Protocol. University of Michigan. 2000. [27] Erdos M, Pato J. Extending the OSF DCE Authorization System to Support Practical Delegation. PSRG Workshop on Network and Distributed System Security. 1993. [28] I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Djaoui, A. Grimshaw, B. Horn, F. Maciel, F. Siebenlist, R. Subramaniam, J. Treadwell, J. Von Reich. The Open Grid Services Architecture, Version 1.5. Open Grid Forum. 2006. [29] Lorch M, Kafura D, Shah S. An XACML-based Policy Management and Authorization Service for Globus Resources. Department of Computer Science, Virginia Tech. 2003.



[30] Ramakrishnan L. Policy Management for OGSA Applications as Grid Services. MCNC-RDI Research and Development Institute. 2003. [31] National Institute of Standards and Technology. Recommendation for Key Management – Part 1: General. NIST Special Publication 800-57. May 2006. [32] A. Menezes, P. van Oorschot, S. Vanstone. Handbook of Applied Cryptography. CRC Press. 1996.

Documents

E SEGURIDAD PARA UN SISTEMA NTEGRADO DE INFORMACIÓN …