UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
ÁREA TÉCNICA
TÍTULO DE INGENIERO EN INFORMÁTICA
Diseño e instalación de una red para visualización de imágenes radiológicas
con acceso remoto vía VPN e internet, con código abierto y Mac OS X
Server
TRABAJO DE TITULACIÓN
AUTOR: Flores Hidalgo Ignacio Javier
DIRECTOR: Torres Tandazo Rommel Vicente, PhD
CENTRO UNIVERSITARIO LOJA
APROBACIÓN DEL DIRECTOR DEL TRABAJO DE TITULACIÓN
Ph. D.
Rommel Vicente Torres Tandazo
DOCENTE DE TITULACIÓN
De mi consideración
El presente trabajo de titulación: “Diseño de una red de visualización de imágenes radiológicas con acceso remoto vía VPN e internet, con código abierto y Mac OS X Server” realizado por el profesional en formación: Flores Hidalgo Ignacio Javier; cumple con los requisitos establecidos en las normas generales para la Graduación en la Universidad Técnica Particular de Loja, tanto en el aspecto de forma como de contenido, por lo cual me permito autorizar su presentación para los fines pertinentes.
Loja, marzo de 2016
DECLARACIÓN DE AUTORÍA Y CESIÓN DE DERECHOS
Yo, Flores Hidalgo Ignacio Javier, declaro ser autor del presente trabajo de titulación: “Diseño e instalación de una red para visualización de imágenes radiológicas con acceso remoto vía VPN e internet, con código abierto y Mac OS X”, y eximo expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos
o acciones legales. Además certifico que las ideas, conceptos, procedimientos y resultados vertidos en el presente trabajo investigativo, son de mi exclusiva responsabilidad.
Adicionalmente declaro conocer y aceptar la disposición del Art. 88 del Estatuto Orgánico de
la Universidad Técnica Particular de Loja que en su parte pertinente textualmente dice:
“Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través, o con el apoyo financiero, académico o institucional (operativo) de la Universidad”
...
Ignacio Javier Flores Hidalgo
DEDICATORIA
A mi esposa por su infinito amor y comprensión, siempre motivándome a cumplir mis metas
y mejorar cada día. A mis hijas motor de mi existencia y luz de mis días. A mis padres por su
apoyo incondicional y sabios consejos que han inculcado en mí el deseo de siempre seguir
AGRADECIMIENTO
Primero a Dios, por permitir mi existencia y poder hacer realidad este sueño anhelado.
A mi esposa, por su apoyo en los momentos más complicados del desarrollo de este trabajo.
A mis padres y suegros, por su apoyo tanto moral como material.
A mis profesores de la modalidad presencial y de la modalidad a distancia, que han
compartido conmigo sus conocimientos.
Y un agradecimiento especial al Ph. D. Rommel Torres por toda la guía brindada, por su
ÍNDICE DE CONTENIDOS
CERTIFICACIÓN………...……ii
CESIÓN DE DERECHOS………..……….iii
DEDICATORIA………..…iv
AGRADECIMIENTO………..………v
ÍNDICE DE CONTENIDOS……….…vi
LISTA DE FIGURAS………...viii
LISTA DE TABLAS………...…………ix
RESUMEN………10
ABSTRACT ……….11
INTRODUCCIÓN ………12
OBJETIVOS……….13
CAPÍTULO I: Imagen Médica Digital………14
1.1. DICOM………...15
1.1.1. ¿Qué es DICOM? ………..15
1.1.2. Historia de DICOM……….17
1.1.3. Funcionamiento de DICOM………..18
1.1.4. DICOM y datos médicos ………..20
1.2. Comunicaciones DICOM ………..21
1.3. PACS………23
1.3.1. Fundamentos………..23
1.3.2. PACS manejo de datos y WEB………25
1.3.3. Implementación clínica ……….28
1.3.4. Telemedicina y Teleradiología……….29
1.4. Osirix……….30
1.4.1 Componentes y funcionamiento de Osirix ………..32
CAPÍTULO II: Redes VPN……….35
2.1. Red VPN………..36
2.1.1 Riesgos de seguridad en Internet……….37
2.2. Tecnologías VPN………38
2.3. Acceso Remoto y VPN………..39
2.3.1 Encriptamiento y protocolos de seguridad………..41
2.5. Redes VPN en Mac OS X Server 10.10 ………44
CAPÍTULO III: Diseño e Implementación de la solución ………46
3.1. Requerimientos Cliente……….47
3.1.1. Detalle equipos de imagen………...47
3.2. Diseño de solución……….48
3.2.1 Diseño de WAN………49
3.2.2 Diseño de Red DICOM para cada centro………50
3.2.2.1 Red DICOM Centro 1 Cuenca………..51
3.2.2.2 Red DICOM Centro 2 Cuenca………..52
3.2.2.3 Red DICOM Centro 3 Azogues……….54
3.2.3 Configurando L2TP sobre IPsec………...55
3.3. Configuración Servidores………..56
3.3.1 Características Técnicas de Servidores y Workstation……….56
3.3.2 Configuración Mac OS X Server………...57
3.3.3 Configuración VPN en el Servidor………58
3.4 Configuración Osirix………59
CAPÍTULO IV: Validación ………..………...…63
4.1. Pruebas de desempeño……….64
4.1.1. Pruebas de velocidad de Red WAN………65
4.1.2. Pruebas de transferencia de archivos DICOM………..69
CONCLUSIONES………..……….…73
RECOMENDACIONES………..………74
LISTA DE FIGURAS
Figura 1. Sistema DICOM – PACS………..16
Figura 2. Datos DICOM………..19
Figura 3.Flujo de datos entre equipos DICOM………...20
Figura 4. Capa TCP/IP usada por DICOM……….22
Figura 5. Flujo de Datos entre PACS y Bases de Datos……….24
Figura 6. Acceso a PACS a través de navegador de páginas electrónicas………..27
Figura 7. Flujo de datos consulta / recuperación………..28
Figura 8: Estructura de comunicación en telemedicina………30
Figura 9. Arquitectura Osirix……….33
Figura 10. Interfaz principal de Osirix………..34
Figura 11: Esquema de una red VPN………..37
Figura 12. Diagrama de red Wan……….49
Figura 13. Diagrama Red DICOM Centro 1 Cuenca……….51
Figura 14. Diagrama Red DICOM Centro 2 Cuenca……….53
Figura 15. Diagrama Red DICOM Centro 3 Azogues………...54
Figura 16. Descarga de OS X Server………..57
Figura 17. Configuración DNS en Servidor……….58
Figura 18. Configuración VPN………..59
Figura 19. Configuración Receptor………..60
Figura 20. Configuración Nodos de Red……….61
Figura 21. Configuración Servidor Web………..62
Figura 22. Diagrama de Validación ……….64
Figura 23. Gráfica prueba de velocidad red VPN Centro 2 Cuenca………...66
Figura 24. Prueba iPerf Centro 2 Cuenca………...………66
Figura 25. Gráfica de prueba de velocidad red VPN Centro 3 Azogues………...68
Figura 26. Prueba iPerf Centro 3 Azogues………...………..68
Figura 27. Desempeño Red VPN……….70
Figura 28. Desempeño Consulta Web……….71
LISTA DE TABLAS
Tabla 1. Direcciones red DICOM Centro 1……….52
Tabla 2. Direcciones red DICOM Centro 2……….53
Tabla 3. Direcciones red DICOM Centro 3 Azogues ………...55
Tabla 4. Prueba de velocidad red VPN Centro 2 Cuenca ………..………...65
Tabla 5. Prueba de velocidad de la red VPN Centro 3 Azogues ………..………67
Tabla 6. Desempeño en Red VPN ………..69
Tabla 7. Desempeño en Consulta Web ………..70
RESUMEN
En el presente proyecto se diseña e instala una red de visualización de imagen digital
radiológica, utilizando una red de largo alcance, usando software libre y Mac OS X Server.
En donde se enlazan tres centros de imagen (dos en Cuenca y uno en Azogues).
Además se describen las tecnologías existentes y analiza a profundidad las soluciones
médicas de imagen y almacenamiento de las mismas.
Finalmente se describe el proceso de diseño, implementación y pruebas realizadas al
proyecto ya en funcionamiento.
ABSTRACT
In the present project is designed and installed a network of digital radiological image
display, using a long-range network, with free software and Mac OS X Server. Where three
imaging centers (two in Cuenca and one in Azogues) are linked.
Furthermore existing technologies are described and analyzed medical solutions depth
image and storage thereof.
Finally the process of designing, implementing and testing the project already in operation is
described.
INTRODUCCIÓN
La imagen digital permite consultar, distribuir y mejorar los tiempos de diagnóstico para el
área de radiología de los centros médicos, así como también permite el diagnóstico remoto
ya que estos sistemas permiten la “Teleradiología”, que es de una gran ayuda no solo
logística sino de acceso a sitios remotos donde no se dispone de estos servicios.
La imagen médica digital ha tenido un desarrollo significativo en los últimos 15 años, y en
nuestro país las mejoras en el acceso a internet, con un constante y creciente acceso con
velocidades cada vez mayores, han permitido que los sistemas de imagen se vayan
incrementando y permitiendo el acceso a varios hospitales, clínicas y centros de imagen
médica a contar con estos servicios.
El costo de estos sistemas es bastante alto y con grados de complejidad elevados. Esto
sumado a los altos costos de los equipos de imagen hace que no todos instalen estos
sistemas en sus centros. Esto es una limitante para su implementación, más aún en
nuestros países sudamericanos, donde los recursos económicos no abundan, y se deben
racionar.
En este proyecto se plantea una opción de implementación de sistemas de imagen médica
digital pero usando opciones de software de código abierto, además de equipos Apple y con
redes privadas de largo alcance. Si bien esta solución significa una inversión económica
significativa, es solo una fracción si se compara con soluciones de grandes empresas que
proveen los equipos de imagen médica.
Este trabajo se desarrolla en cuatro capítulos: en el primero se describe el estado del arte en
todo lo referente a imagen médica digital; en el segundo se investiga todo lo referente a las
redes privadas virtuales; en el tercero se realiza el diseño y la implementación de la
OBJETIVOS
Objetivo General :
- Diseñar e implementar una Red de largo alcance (WAN) de imagen médica digital
con acceso remoto a través de una Red Privada Virtual (VPN) con código abierto.
Objetivos Específicos:
- Investigar soluciones de imagen médica de código abierto.
- Diseñar una solución de imagen médica digital a través de una red segura.
- Unir 3 centros de diagnóstico de imagen ubicados en diferentes ciudades, con
1.1 DICOM
1.1.1 ¿Qué es DICOM?
DICOM es el acrónimo en inglés para Digital Imaging and Communications in Medicine
(Imagen Digital y Comunicaciones en Medicina) y representa años de desarrollo para crear
un formato universal y completo para la imagen médica digital. Proporciona todas las
herramientas necesarias para la representación, diagnóstico y tratamiento de datos en
imágenes médicas. Además, DICOM no es sólo un formato de imagen o archivo, involucra
también una transferencia de datos, almacenamiento y protocolos de visualización,
construidos y diseñados para cubrir todos los aspectos funcionales de la imagen médica
digital, por eso muchos ven el DICOM como un conjunto de normas, en lugar de un único
estándar (Pianykh, 2008).
Sin lugar a dudas, DICOM abarca casi la totalidad de la práctica de medicina digital1.
Otra acrónimo importante que se asocia a las siglas DICOM es PACS (Picture Archiving and
Communication Systems) o traducido como (Sistema de Comunicación y Almacenamiento
de Imágenes).
PACS son sistemas médicos que constan de hardware y software, diseñados y utilizados
para ejecutar el procesamiento de imagen médica digital. La arquitectura en general se la
puede ver en la Figura 1. Comprenden los dispositivos digitales de adquisición de imágenes
(modalidades - como la tomografía computarizada (TC) escáneres o ecografía), archivos de
imágenes digitales (donde se almacenan las imágenes adquiridas), y estaciones de trabajo
(donde los radiólogos pueden ver las imágenes).
1
16
Figura 1. Sistema DICOM-PACS.
Fuente: Tomado de (Pianykh, 2008) modificado por el autor.
Los sistemas PACS están directamente relacionados con DICOM. Su funcionalidad es
impulsada por DICOM, lo que garantiza su interoperabilidad. Por esa razón, cualquier
dispositivo PACS o software viene con su propia “Declaración” de conformidad DICOM. Este
es un documento muy importante que explica el grado en el que el dispositivo es compatible
con el estándar DICOM.
DICOM ha dado forma a la medicina contemporánea, proporcionando:
• Un estándar médico universal de imagen digital. Todos los dispositivos de
adquisición de imagen digital producen imágenes DICOM y se comunican a través
de redes DICOM.
• DICOM provee una excelente calidad de imagen. Por ejemplo, DICOM soporta hasta
65536 (16 bits) tonos de gris para la visualización de imágenes monocromáticas,
capturando así los matices más leves en las imágenes médicas. En comparación, la
conversión de imágenes DICOM en JPEG (Joint Photographic Experts Group)
traducido como “Grupo Conjunto de Expertos en Fotografía, es el nombre de un
comité de expertos que creó un estándar de compresión y codificación de archivos e
imágenes fijas”2 o mapas de bits (BMP), siempre esta limitado a 256 tonos de gris. A
menudo los hace poco prácticos para diagnóstico. DICOM toma ventaja de las más
recientes y avanzadas técnicas de representación de imágenes digitales para
proporcionar la máxima calidad de imagen.
2
17
• Soporte completo para numerosos parámetros de adquisición de imágenes y
diferentes tipos de datos. No sólo registra las imágenes, sino que también registra
una multitud de otros parámetros relacionados con la imagen, como la posición 3D
en la imagen del estudio, tamaños de los objetos en la imagen, grosor de corte, la
exposición de la imagen, parámetros del equipo de captura, entre otros.
• Codificación de los datos médicos. Los archivos DICOM utilizan más de 2.000
atributos estandarizados (diccionario de datos DICOM) para transmitir datos
médicos, que van desde el nombre del paciente a la imagen de profundidad de color.
Estos datos son a menudo esenciales para el diagnóstico preciso, y la captura de
todos los aspectos de la radiología actual.
• La claridad en la descripción de los dispositivos de imágenes digitales y su
funcionalidad que es la columna vertebral de cualquier proyecto de imagen médica.
DICOM define la funcionalidad de dispositivos médicos en términos muy precisos e
independientes del dispositivo. Trabajar con dispositivos médicos a través de
interfaces DICOM deja poco espacio para errores.
1.1.2 Historia de DICOM
El estándar DICOM tiene unos 30 años de antigüedad y ha evolucionado constantemente,
ajustándose a las prácticas actuales, pero conservando muchas de sus características
históricas originales (Pianykh, 2008).
La norma fue concebida en 1983 por una comisión mixta formada por el Colegio Americano
de Radiología (ACR)3, y la Asociación Nacional de Fabricantes Eléctricos (NEMA)4. El
objetivo principal era desarrollar un estándar que haría a la imagen médica digital
independiente de particulares y los fabricantes de dispositivos, facilitando así la expansión
de la imagen digital y PACS. En otras áreas médicas los productores de equipos y
desarrolladores de sistemas tienen muchos problemas de compatibilidad, ya que no existen
estándares definidos como sí los tiene DICOM.
El comité conjunto, llamado el ACR-NEMA (Digital Imaging and Communications Standards
Committee)5, comenzó su labor mediante la revisión de muchas otras normas establecidas
en ese momento. Aunque el comité no encontró nada específicamente ajustado a sus
necesidades, se tomó algunos consejos valiosos del estudio. La Asociación Americana de
3
http://www.acr.org
4 http://www.nema.org/pages/default.aspx
5
18
Físicos en Medicina (AAPM)6 había aprobado recientemente un estándar para grabar
imágenes en una cinta magnética. La AAPM estaba tomando el enfoque de codificar toda la
información como secuencias de elementos de datos, por lo que cada elemento puede tener
una longitud variable (tamaño) y se identificó por su nombre único (etiqueta). Esta idea de
representar los datos como una secuencia de elementos de datos etiquetados fue adoptada
por el grupo de ACR-NEMA. El concepto de la utilización de elementos de datos como
pequeños bloques de construcción para representar los datos de cualquier complejidad ha
demostrado ser extremadamente útil y robusto.
La primera versión de la norma, llamado ACR-NEMA 300-1985 o ACR- NEMA 1.07, fue
publicada en 1985 y distribuida en la Sociedad Radiológica de Norteamérica (RSNA)8.
Oficialmente, el estándar ACR-NEMA original se propone como una guía y NEMA no asume
ninguna responsabilidad por su ejecución o interpretación. Los objetivos de normalización,
sin embargo, estaban bien establecidos y el cumplimiento de la norma se ha convertido en
imperativo para la comunidad médica.
1.1.3 Funcionamiento de DICOM
DICOM utiliza su propio lenguaje, basado en su modelo (modelo de información DICOM)
para hacer una analogía en el mundo real.
Los datos en mundo real: pacientes, estudios, dispositivos médicos, y así sucesivamente,
son vistos por DICOM como objetos con propiedades respectivas o atributos. Las
definiciones de estos objetos y atributos están estandarizados de acuerdo a las definiciones
de objetos (IOD)9. Se piensa en IODs como colecciones de atributos que describen cada
objeto de datos en particular. Un paciente IOD, por ejemplo, puede ser descrito por su
nombre, número de historia clínica (ID), sexo, edad, peso, entre otros (Pianykh, 2008).
En un sentido más amplio, un paciente (al igual que cualquier otro objeto DICOM) es el
conjunto de atributos de los que consta, como se puede ver en la Figura 2. DICOM mantiene
una lista de todos los atributos estándar (más de 2.000), conocido como el diccionario de
datos DICOM. Por ejemplo, los atributos de paciente - nombre, fecha de nacimiento, sexo,
etc. - también se incluyen en el diccionario de datos DICOM. Todos los atributos DICOM se
6 https://www.aapm.org
7
http://dicom.nema.org/dicom/2001/01_01pu.pdf 8 http://www.rsna.org
9
19
formatean según representaciones de valores (VR) tipos, correspondientes a fechas, horas,
nombres, y así sucesivamente (Pianykh, 2008).
Figura 2. Datos DICOM.
Fuente: Tomado de (Pianykh, 2008) modificado por el autor.
Tan pronto como se capturan los datos como atributos de datos DICOM, estos pueden ser
transmitidos y procesados entre varios dispositivos DICOM y software de procesamiento
DICOM. Debido a que cada servicio implica generalmente algún intercambio de datos
(generalmente realizado a través de una red de computadores), resulta natural las
asociaciones de tipos de servicios con los datos que procesan. DICOM llama a estas
asociaciones Service-Object Pairs (SOP)10, y los agrupa en clases SOP.
Por ejemplo, guardar una imagen de CT (CT acrónimo de “Computed Tomography” para
rayos X) o TC (Tomografía Computarizada) de un escáner CT digital a un archivo PACS
digital, en un disco de almacenamiento SCP (Service Clase Provider)11 o (Proveedo de
Servicio de Clase), se muestra en la Figura 3.
10 http://dicom.nema.org/MEDICAL/DICOM/2015a/output/chtml/part03/sect_6.5.html
11
20
Figura 3. Flujo de datos entre equipos DICOM.
Fuente: Tomado de (Pianykh, 2008) modificado por el autor.
Debido a que cientos de dispositivos DICOM y aplicaciones son producidos por cientos de
fabricantes de DICOM, cada unidad DICOM esta acompañada por su propia “Declaración de
conformidad DICOM”12. Esta declaración explica que SOP (Service-Object Pair)13 (servicios)
son compatibles. La Declaración de conformidad DICOM es la hoja de ruta esencial para
cualquier proyecto relacionado con DICOM, ya que permite asegurar la compatibilidad y
confiabilidad de los datos transmitidos entre diferentes equipos DICOM. Se debe obtener del
fabricante y leerlo detenidamente. Por ejemplo, si se compara un archivo digital que admite
sólo CT Almacenamiento SCU14 (no soporta CT Almacenamiento SCP) usted no será capaz
de almacenar imágenes de CT en ella.
1.1.4 DICOM y Datos Médicos
Para el desarrollo de un flujo de trabajo médico, se definen dos tareas principales:
recolección y tratamiento de los datos clínicos. DICOM se diseñó para ayudar con ambas
tareas de forma consistente. Para garantizar la coherencia y eliminar la ambigüedad en la
manera de interpretar los datos, el estándar utiliza un conjunto de reglas formales de
representación de datos y la codificación.
Conocer los conceptos básicos del lenguaje DICOM es indispensable para cualquier
persona que quiera adentrarse en el mundo de la imagen médica digital.
La Imagen Médica digital es un subconjunto de la informática médica que estudia la
adquisición de la imagen y los datos relacionados a esta: el procesamiento, manipulación,
12
http://dicom.nema.org/dicom/2004/04_02PU.PDF 13 http://www.dicomlibrary.com/dicom/sop/
14
21
almacenamiento, transmisión, seguridad, gestión, distribución, visualización, el diagnóstico,
la intervención y la terapia. Aunque la informática de imágenes se basa en muchos
conceptos, la terminología y metodología se deriva de la informática médica. Diferentes
tipos de datos están involucrados, incluyendo imágenes multidimensionales médicas,
gráficos, formas de onda y texto. En consecuencia la formación de imágenes médicas
digitales requieren nuevos conceptos y nuevas herramientas para manejar este tipo de
datos.
La modalidad de estudios más común es la de Rayos X que representa el 60 % de los
exámenes radiológicos, seguidos por estudios de ultrasonido, tomografía computarizada,
resonancia magnética entre otros (Ross, 2011).
Los recientes avances en la tecnología de imágenes médicas, tales como PACS, la cirugía
guiada por imagen y la terapia, CAD (PC- diagnóstico asistido por computador), EPR
(historia clínica electrónica), tienen a la informática de imágenes como disciplina para
manejar y sintetizar el conocimiento a partir de imágenes médicas para la atención eficaz y
eficiente del paciente, así como para el análisis de resultados. DICOM se utiliza como
palabra clave para identificar los datos de la comunicación y de aspecto de formato de la
informática de imágenes médicas y el énfasis en las imágenes (Ross, 2011).
1.2. Comunicaciones DICOM
Mientras que la mayoría piensa en DICOM como un simple formato de archivo de imagen
médica, realmente es un estándar mucho más amplio que dirige todas las facetas del flujo
de trabajo clínico y va mucho más allá del ámbito de la gestión de formatos de archivos de
imagen. Se crea un universo entero de imagen médica digital y poblado por objetos DICOM
cuando viajan e interactúan a través de redes informáticas.
DICOM actual utiliza el mismo protocolo TCP / IP, que se utiliza para el envío de correo
22
Figura 4. Capa TCP/IP usada por DICOM.
Fuente: Tomado de (Pianykh, 2008) modificado por el autor.
TCP / IP soporta todas las variaciones de hardware y software, además proporciona la
funcionalidad de red necesaria: por ejemplo, enviar información (como una secuencia de
bytes) de una dirección de puerto IP a otro. DICOM sólo suma su propio lenguaje de redes
(la capa de aplicación) (Pianykh, 2008).
Este lenguaje consiste en servicios de alto nivel, DICOM Message Service Elements
(DIMSE)15.
Aunque a veces el lenguaje técnico confunde, todos los conceptos utilizados en la creación
de redes DICOM son bastantes intuitivos, no se necesita ser un experto en redes para
entenderlos. Por otra parte, conocer los principios de la red DICOM (al menos en el nivel
más alto) mejora considerablemente su comprensión de DICOM y PACS, y su capacidad
para hacer frente a proyectos de este tipo.
La identificación de unidades de la red DICOM: El DICOM AE (Application Entity –
Entidad de aplicación)16 corresponde en general a cualquier aplicación en un dispositivo
DICOM en red; por ejemplo puede ser un servidor DICOM (archivo), estación de trabajo de
15 http://dicom.nema.org/dicom/2013/output/chtml/part07/sect_7.5.html
16
23
imagen, impresora, película, o un dispositivo de adquisición de imágenes. Estos cuatro
ejemplos cubren alrededor del 95 % de todas las entidades solicitantes en un entorno
clínico.
Se espera que cada dispositivo en una red tenga una tarjeta de red y su propia dirección IP,
que es como los otros dispositivos pueden encontrarlo. Además de que la configuración de
red estándar, DICOM asigna a cada AE su propio nombre DICOM conocida como su
"Solicitud Título de la entidad" (AET – Application Entity Title). En DICOM, la AET está
codificado con el VR (Value Representation – Valor de Representación) AE, “este valor
describe el tipo de dato y el valor de este”17 . La AE puede tener hasta 16 caracteres. Un
enfoque práctico para la denominación de AET es utilizar el nombre de la aplicación (por
ejemplo, PACSSERVER), o el nombre / ubicación del equipo (CONSDRARIZAGA)
preferiblemente sin signos de puntuación o espacios y en mayúsculas para evitar la
ambigüedad. Esto hace que sea fácil de mantener y fácil de identificar. Cuando el software
PACS se instala en su sitio, asegúrese de que las AET se asignan de una manera clara y
coherente (Pianykh, 2008).
Servicios y Redes de Datos: El modelo de procesamiento de datos y el intercambio
adoptada por DICOM es clásico y elegante; las DICOM AE proporcionan servicios entre sí.
Una entidad DICOM puede solicitar un servicio a otro, y la entidad que proporciona el
servicio solicitarlo a la primera. En el lenguaje DICOM, un AE que solicita un servicio es visto
como un SCU (Service Class User), y un AE que proporciona un servicio es visto como un
SCP (Service Class Provider). En otras palabras, AE puede ser SCP o SCU para
comunicarse entre sí (Pianykh, 2008).
Todos los servicios DICOM se prestan en el nivel de Clases de servicios DICOM. Las
clases de servicios de datos DICOM se unen con las funciones de procesamiento de datos.
1.3. PACS
1.3.1. Fundamentos
Los principales componentes de PACS son una imagen o un conjunto de imágenes, un
digitalizador o equipo de toma de imágenes, un servidor PACS y los archivos. Pueden existir
17
24
varias estaciones de trabajo de visualización enlazadas por redes digitales. PACS puede
conectarse adicionalmente con otros sistemas de información de salud a través de base de
datos y redes de comunicación como se muestra en la Figura 5 (Huang, 2010).
Los PACS adquieren las imágenes enviadas desde los equipos de imagen (dispositivos) y
los datos del paciente relacionados desde el sistema de información hospitalaria (HIS –
Hospital Information System)18 o de un sistema de información de radiología (RIS –
Radiology Information System)19.
Hay dos tipos de pasarelas (GW - Gateway) en el servidor y archivo PACS, la base de datos
GW (Figura 5, verde) para datos de texto, y la adquisición de la imagen GW (Figura 5,
amarillo) para los datos de la imagen (Huang, 2010).
Figura 5. Flujo de Datos entre PACS y Bases de Datos.
Fuente: tomado de (Huang, 2010) modificado por el autor.
Una tarea importante del PACS es adquirir imágenes de manera fiable y en tiempos
óptimos. Cada modalidad de imagen radiológica y los datos relevantes del paciente, incluida
la información de apoyo al estudio del paciente, descripción del estudio, y los parámetros
pertinentes para la adquisición de imágenes deben ser almacenadas correctamente y estar
disponibles cuando se los requiera (Huang, 2010).
18 https://en.wikipedia.org/wiki/Hospital_information_system
19
25
La adquisición de imágenes es una tarea importante en el PACS. Debido a que la técnica de
imagen no está bajo el control de un solo gestor de PACS, las modalidades de imagen
suministrados por fabricantes tienen cada uno sus propias declaraciones compatibles con
DICOM. Peor aún, algunas modalidades de imagen antiguas pueden incluso no ser
compatibles con DICOM (Huang, 2010).
Para que las muchas modalidades de imágenes puedan conectarse a un PACS se requiere
muchas horas de trabajo de mano de obra, de los técnicos tanto de los fabricantes de los
equipos, como de los técnicos que realizan la instalación del PACS, el software que lo
maneja y su configuración. La adquisición de imágenes es una operación lenta debido a que
los exámenes de los pacientes son los documentos implicados en el proceso.
Inevitablemente se necesita la imagen y un tiempo considerable para que el técnico
radiológico pueda adquirir los datos necesarios para la reconstrucción de la imagen y crear
un archivo de imagen completo. Las imágenes y los datos de los pacientes generados, a
veces, contienen información de formato inaceptable para la operación del PACS. Para
hacer frente a este problema, se instala un equipo de puerta de enlace de adquisición,
algunos fabricantes lo llamaron unidad de integración de modalidad, MIU, a menudo se
coloca entre la modalidades de imágenes y el resto de la red PACS para aislar el equipo
anfitrión desde el PACS. El aislamiento es necesario porque los ordenadores de dispositivos
de imagen tradicionales carecen del software de comunicación y la coordinación necesaria
que estén estandarizados dentro de la infraestructura PACS (Huang, 2010).
Si los equipos que reciben la información no pueden manejar los datos como para trabajar
con el servidor PACS, el computador pasarela tiene tres tareas principales: adquiere datos
de imagen del dispositivo de imagen radiológica, puede convertir los datos de las
especificaciones del fabricante a un formato estándar PACS (formato de cabecera, orden de
bytes, y tamaños de matriz) que son compatibles con los formatos de datos DICOM y luego
transmita el estudio de imagen al servidor PACS o mostrar en un visualizador (Huang,
2010).
1.3.2. PACS manejo de datos y red
La red se basa en el protocolo de transferencia de hipertexto (HTTP), que apoya la
transmisión de documentos de hipertexto en todos los equipos accesibles a través de
Internet. Los dos idiomas más utilizados para aplicaciones de red que permiten la
26
utilizados, son el lenguaje de marcado de hipertexto (HTML) y el lenguaje Java.
Recientemente, el XML (Extensible Markup Language) se ha aplicado ampliamente para la
imagen y el texto estándar (Huang, 2010).
Hoy en día, la mayoría de los navegadores, el apoyo JPEG (24 bits para imágenes de color)
o GIF (Graphics Interchange Format, 8 bits) para la representación de la imagen, han
permitido la distribución de imágenes de alta calidad con tamaños pequeños para su
distribución a través de internet (Huang, 2010).
En la terminología de Internet, existe el servidor y los clientes (o sitios, o navegadores). El
sitio electrónico utiliza procesos de activación para acceder a la información desde el
servidor Web a través de HTTP. Durante los últimos años las aplicaciones de la tecnología
de la Web se han extendido a las aplicaciones de información de salud. Algunas páginas
electrónicas ahora soportan el acceso a la información textual de registro electrónico del
paciente sistemas (EPR – Electronic Patient Record) (Huang, 2010).
Estos sistemas EPR basadas en red se pueden clasificar de acuerdo a sus características,
como la integridad y el detalle del modelo de información, métodos de acoplamiento entre
los sistemas de información hospitalarios basados en red, la calidad de los datos, y el grado
de personalización.
El uso del servidor como un medio para acceder a la imagen y datos PACS se ha
implementado por algunos fabricantes y desarrolladores independientes, creando soluciones
cada vez más funcionales y con características avanzadas.
Concepto del servidor Web en un medio ambiente PACS: Considere un servidor de
27
Figura 6. Acceso a PACS a través de navegador.
Fuente: Tomado de (Huang, 2010) modificado por el autor.
En donde:
1. El usuario se conecta con su navegador a internet,
2. El servidor web interpreta las consultas HTML del navegador (en la actualidad muchos
desarrollan en HTML5) o Java y convierten las consultas con los estándares DICOM y
HL722.
3. El servidor web realiza una consulta DICOM / SOP para consultar y recuperar la imagen /
datos del servidor PACS.
4. El intérprete DICOM/HTTP proporciona un traductor para convertir las imágenes DICOM
y texto a protocolo HTTP y puedan ser visualizadas en el navegador del usuario (Huang,
2010).
Consulta / Recuperación imagen DICOM en un PACS: Se puede consultar y recuperar
las imágenes DICOM almacenados en el servidor PACS utilizando el navegador. El
funcionamiento y las comunicaciones entre el navegador y el servidor Web para PACS son
similares a la de la consulta de imagen del servidor Web. Sin embargo, la interoperación
entre el servidor de red y el servidor PACS es a través de los servicios DICOM. Por ejemplo,
cuando se hace la consulta a través de XML desde un navegador cliente, esta es recibida
por el servidor, el mensaje luego se registra en el componente de servicio de comunicación
DICOM, este se convierte en un objeto de consulta DICOM y se envía al servidor a través
del servicio (PACS – DICOM) C-FIND23. Cuando el componente DICOM recibe el resultado
22 http://www.hl7.org/about/index.cfm?ref=common
23
28
consultado desde el servidor PACS, se convierte en un mensaje XML, y envía el mensaje
XML al navegador a través del servidor (Huang, 2010).
Para la operación de recuperación, el flujo de datos es similar al de la consulta, pero los
servicios de comunicación DICOM entre el servidor Web y el servidor PACS son C-MOVE24
y C-STORE25. La Figura 7 muestra el flujo de datos de la operación de consulta /
recuperación entre el navegador, el servidor web y el servidor PACS (Huang, 2010).
Figura 7. Flujo de datos consulta / recuperación. Tomado de (Huang, 2010) modificado por
el autor.
1.3.3. Implementación clínica
La filosofía de diseño e implementación PACS que se recomienda es hacerla a escala.
Siempre se debe dejar espacio para la expansión futura, incluyendo integración con PACS
empresariales. Por lo tanto, si el objetivo de la planificación es tener un PACS a gran escala
ahora, la arquitectura PACS debería permitir su crecimiento futuro. Por otro lado, si se está
planificando sólo un módulo de PACS, la consideración de la conectividad y la
compatibilidad de este módulo con los módulos futuros, o de una escala más grande, es
esencial (Huang, 2010).
En estos modelos el departamento de radiología o la empresa participante ingresa
información en su flujo de trabajo y el entorno operativo, incluyendo los recursos utilizados y
los gastos; en el modelo se comparan los costos de la operación de película y con la
24 http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.4.2.2.html
25
29
operación en base digital pronosticado. Siempre los costos de una implementación digital
pueden parecer elevados inicialmente, pero el beneficio en el corto y mediano plazo son
siempre una mejor inversión para el centro de imagen y/o hospital o clínica (Huang, 2010).
1.3.4. Telemedicina y Teleradiología
La telemedicina y la teleradiología se hacen cada vez más importantes para los sistemas de
salud. Cada día aumentan el número de hospitales, clínicas, centros de salud, tanto
privados como públicos que cuentan con algún componente de telemedicina y
teleradiología. Son además los centros de estudio universitarios los que tienen un rol
protagónico para la masificación de estas herramientas (Huang, 2010).
Estas soluciones tecnológicas logran una disminución en los costos hospitalarios, así como
amplían el área de acción de los mismos. Las zonas remotas pueden contar ya con acceso
a tecnologías, que antes solo era posible en las grandes ciudades con grandes centros
médicos y hospitalarios.
La telemedicina en pocas palabras se define como la distribución y acceso a salud usando
telecomunicaciones, computadoras y tecnologías de la información, lo que incluye a la
imagen médica (Huang, 2010).
Teleradiología: es el subconjunto de la telemedicina que se encarga de la transmisión,
visualización y diagnóstico de imagen médica, además de otra información relacionada con
el paciente, entre un centro de toma de imagen y otro centro remoto especializado en
imagen (Huang, 2010).
Un asunto importante en la telemedicina es la privacidad de la información del paciente, es
por ello que los centros médicos deben asegurar la seguridad y confidencialidad del manejo
de la información a través de sus sistemas RIS o HIS. Tanto en el mundo empresarial como
en el área médica la información almacenada debe ser manejada adecuadamente y debe
ser protegida de accesos a terceros que no tienen nada que ver con el manejo de esta
información.
Otro requerimiento en teleradiología es el diseño de protocolos de comunicación, lo que
requiere de componentes de hardware y software especiales (como podemos ver en la
Figura 8), así como las formas de conexión. En la actualidad las conexiones de banda ancha
30
componente de software debe ser basado en estándares para evitar problemas de
integración en el futuro, si bien los equipos de imagen son de diferentes fabricantes, la gran
mayoría y sobre todo los equipos más modernos respetan estos estándares de
comunicación y almacenamiento de datos (Huang, 2010).
Figura 8: Estructura de comunicación en telemedicina.
Fuente: Tomado de (Huang, 2010) modificado por el autor.
1.4. Osirix
La mayoría de aplicaciones de imagen médica y de salud funcionan en PCs basados en
Microsoft Windows, aunque en la actualidad los equipos con Mac OS X de Apple están
incursionando en centros de imagen y sistemas de radiología. Se ha creído que sólo los PC
con Windows o estaciones de trabajo DICOM de las empresas que proveen los equipos de
imagen, pueden estar o ser parte en entornos radiológicos10.
Esa suposición está demostrando ser incorrecta. En los últimos años, las nuevas
generaciones de sistemas basados en Mac OS X se han adoptado en los entornos
radiológicos, gracias en gran parte a su inclusión de procesadores multinúcleo de Intel,
aceleradores de gráficos de gama alta, y tecnologías de visualización de calidad profesional.
10
31
Al mismo tiempo, los desarrolladores de código abierto se han dedicado a la creación de
una aplicación de estación de trabajo de imágenes médicas, expresamente diseñado para
el sistema operativo Mac OS X llamado Osirix, esta aplicación de código abierto sólo está
disponible para ordenadores con Mac OS X. El software brinda a los médicos y tecnólogos
acceso a la mayoría de las características comunes de las imágenes radiológicas y de
estaciones de trabajo DICOM, esta aplicación incluye:
• Soporte para casi todos los tipos de modalidades de estudios radiológicos.
• Funciones de redes DICOM.
• Herramientas de organización de imagen avanzadas.
• Herramientas de reconstrucción 2D, 3D y 4D, multiplanar y los algoritmos de
representación de volumen.
• Métodos sofisticados de fusión de imágenes.
• Imágenes 4D, necesarios para la resonancia magnética cardiaca o TC
(Tomografía Computarizada de rayos X)
• Apoyo a terceros, permite “plug-ins” (componentes de software especializados y
a medida) para personalizar la aplicación.
• PACS completo y capacidades de integración de flujo de trabajo.
• Soporte completo para angiografía digital (Pixmeo, 2015).
Los beneficios de Osirix desde su inicio en la comunidad de código abierto, le han permitido
crecer rápidamente como una de las soluciones de software radiológico más completas y
ricas en funcionalidades disponible. Los desarrolladores de código abierto de todo el mundo
regularmente incorporan nuevas características, a petición de los usuarios finales. Aunque
existen proyectos de software de radiología para otros sistemas operativos, incluyendo Linux
y Microsoft Windows, ninguno puede igualar las características y el rendimiento de Osirix.
Del mismo modo, es difícil que un solo proveedor de imágenes médicas pueda con el rápido
ritmo de innovación que dispone este proyecto de código abierto (Pixmeo, 2015).
En la actualidad existe el proyecto Horos27, que continúa el desarrollo de software libre de
Osirix, ya que ahora se han cerrado las colaboraciones de terceros, mientras que Horos
continúa con la colaboración activa de desarrolladores de todo el mundo.
27
32
1.4.1 Componentes y funcionamiento de Osirix
Osirix es un software de procesamiento y almacenamientos de imágenes dedicada a las
imágenes DICOM (extensión ".dcm") producido para la gestión de imágenes (MRI, CT, PET,
PET-CT, SPECT-TAC, ecografías). Es totalmente compatible con el estándar DICOM para
formatos de comunicación de imagen y archivos de imagen médica. OsiriX es capaz de
recibir imágenes transferidas por el protocolo de comunicación DICOM desde cualquier
PACS o equipo de adquisición de imágenes (STORE SCP / SCU, y Query / Retrieve:
C-MOVE SCU / SCP, C-FIND SCU / SCP, C-GET SCU / SCP , WADO) (Pixmeo, 2015).
Osirix ha sido diseñado específicamente para la navegación y visualización de imágenes
multimodalidad y multidimensionales: Visualizador 2D, Visualizador 3D, 4D Visualizador
(series 3D con dimensión temporal, por ejemplo: Cardio-CT) y Visualizador 5D (series 3D
con dimensiones temporal y funcional, por ejemplo: Cardiac-PET-CT). El Visor 3D ofrece
todos los modos modernos de renderizado: reconstrucción multiplanar (MPR),
reconstrucción de volumen y proyección de intensidad máxima (MIP). Todos estos modos
admiten datos 4D y son capaces de producir la fusión de imágenes entre dos series
diferentes (PET-CT y soporte de pantalla SPECT-CT) (Pixmeo, 2015).
Osirix es a la vez una estación de trabajo PACS DICOM para imágenes y un software de
procesamiento de imágenes para la investigación médica (radiología y medicina nuclear),
imagen funcional, imágenes en 3D, microscopía confocal y de imagen molecular (Pixmeo,
2015).
Osirix actualmente es desarrollado y mantenido por Pixmeo, una empresa con sede en
Ginebra, Suiza.
Osirix está disponible en 32 bits y el formato de 64 bits. La versión de 64 bits le permite
cargar un número ilimitado de imágenes, excediendo el límite de 4 GB de aplicaciones de 32
bits. La versión de 64 bits está totalmente optimizada para procesadores Intel multi-núcleos,
que ofrece las mejores prestaciones para representaciones en 3D (Pixmeo, 2015).
Osirix es compatible con una arquitectura completa de módulos programables que le permite
33
modular le da acceso al Framework Cocoa28 con un potente y fácil lenguaje orientado a
objetos: Objective-C29 (podemos ver su estructura en la Figura 9) (Pixmeo, 2015).
Figura 9. Arquitectura Osirix.
Fuente: Tomado de (Pixmeo, 2015) modificado por el autor.
Cocoa es un conjunto de librerías para uso en programación de Objective-C, proporcionadas
por Apple y que pueden ser usadas por cualquier desarrollador ya que estas son de código
abierto.
Componentes de Código Abierto:
- Cocoa (OpenStep, GNUStep, NextStep)
- VTK (Visualization Toolkit)
- ITK (Insight Toolkit)
- PixelMed (David Clunie)
- Papyrus 3.0
- DICOM Offis DCMTK
- OpenGL
- LibTIFF
- LibJPEG
- CharLS (Pixmeo, 2015)
En la Figura 10 se muestra al programa Osirix en su pantalla principal, en donde podemos
ver los diferentes elementos que la conforman, en la parte izquierda los tipos de estudio
agrupados por fechas, en la parte central la base de datos de pacientes, y en la parte inferior
las imágenes de los estudios realizados. Esta interfaz es muy amigable para el usuario y
28
https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/Cocoa.html
29
34
sobre todo muy completa para el diagnóstico que realizan los radiólogos, uno de los puntos
fuertes en este programa.
35
36 2.1. Red VPN
Una red privada virtual (RPV o VPN, Virtual Private Network) es la interconexión de varias
redes locales (LAN, Local Area Network) que están separadas físicamente (remotas) y que
realizan una transmisión de un volumen considerable de datos entre ellas. De forma
habitual, lo que se pretende es que dicho grupo de redes locales se comporten como si se
tratara de una única red local, aunque por diversos motivos, fundamentalmente de índole
económica, la interconexión entre dichas redes LAN se efectúa a través de medios
potencialmente servidoriles o inseguros (Internet, Red telefónica conmutada o RTC a través
de módem, líneas alquiladas, RDSI o ISDN, X.25, Frame Relay, ATM), de forma que hay
que articular diversos mecanismos, especialmente de encriptación y de firma digital, para
garantizar la seguridad de los sistemas (González, 2002).
El principal elemento en una red VPN son las “pasarelas” (del inglés “gateways”, también
conocidas como puertas de enlace, para este trabajo utilizaremos el nombre pasarelas)
entre la red pública y la red privada. Estos son basados en software, hardware o su
combinación (González, 2002).
Cuando un servidor local envía información a un servidor remoto que pertenece a la misma
VPN, los datos tienen que atravesar la primera pasarela protectora antes de salir a la red
pública, y luego a través de la segunda pasarela a la entrada de la red local remota en la
que está el servidor receptor de la información. El sistema protege dicha información de
forma automática encriptándola, haciéndola de tal forma incomprensible a terceras partes.
Las pasarelas pueden asimismo hacer una doble función, al actuar también como
cortafuegos o cortafuegos que nieguen el acceso de datos dañinos o maliciosos a nuestra
red (González, 2002).
En la Figura 11 se puede ver de una manera gráfica y simplificada de como se ve una red
37
Figura 11: Esquema de una red VPN30
Fuente: http://www.dada-dada.com/dms/fwvpn.php
2.1.1 Riesgos de seguridad en Internet
Los riesgos asociados con Internet se publican todos los días. Ya se trate de una persona
que quiera acceder a sus números de tarjeta de crédito, encontrar información privada, o
borrar archivos, siempre hay una nueva noticia de información tomada por “hackers” sea de
usuarios comunes o grandes empresas, además del riesgo de información inapropiada o
que se considere ofensiva (Charlie Scott, 1999).
Para las empresas, los riesgos son aún más reales. Datos corporativos robados o
eliminados pueden afectar negativamente a los medios de vida de las personas, y cuestan
mucho dinero a las empresas.
Dado que Internet es una red pública, siempre se corre el riesgo de que alguien acceda a
cualquier sistema que se conecte al mismo. Si su red corporativa está conectada a través de
30
38
Internet y su seguridad es baja, un intruso podría ser capaz de acceder a su red utilizando
cualquier cuenta de acceso estándar de cualquier ISP (Internet Service Provider, o
proveedor de servicios de internet en castellano) en el mundo. Incluso los usuarios no
sofisticados pueden obtener y usar herramientas automatizadas para buscar agujeros en la
red de una empresa. Lo peor es que, y lo más probable, el usuario nunca sabrá que está
pasando (Charlie Scott, 1999).
Antes de colocar o enviar datos privados a través de Internet, será mejor tener una VPN lo
suficientemente robusta como para protegerla.
2.2 Tecnologías VPN
Existen diferentes tecnologías sobre las que una VPN puede estar implementada. A
continuación destacamos las más importantes.
PPTP (Point-to-Point Tunneling Protocol)31
Encapsulado de tramas PPP en datagramas IP, utilizando una versión extendida del GRE
(Generic Routing Encapsulation, protocolo IP 47). La conexión de control se realiza sobre
TCP, puerto 1723.
Actualmente este protocolo, aunque muy popular en el mundo Microsoft32, está siendo
sustituido por el L2TP33(Layer 2 Tunnelling Protocol). La implementación de Microsoft,
además, sufre de importantísimos errores de diseño que hacen que su protección
criptográfica sea inefectiva.
L2TP (Layer 2 Tunnelling Protocol)
Encapsulado de tramas PPP sobre cualquier medio, no necesariamente redes IP. En el caso
IP se usa UDP34(User Datagram Protocol), puerto 1701. L2TP pasa a ser una propuesta de
estándar en Agosto de 1.999. Aporta grandes ventajas y es sencillo de configurar.
IPSEC35
31
https://es.wikipedia.org/wiki/PPTP
32 https://msdn.microsoft.com/es-es/library/cc739465(v=ws.10).aspx
33
https://es.wikipedia.org/wiki/L2TP
34 https://es.wikipedia.org/wiki/User_Datagram_Protocol
35
39
IPSec es el nuevo marco de seguridad IP, definido con el advenimiento del IPv6. Aunque
IPv6 está muy poco difundido en este momento, la tecnología marco IPSec se está
utilizando ya, lo que asegura, entre otras cosas, la interoperabilidad entre sistemas de
diversos fabricantes y sistemas operativos, como Linux, Windows Macintosh, pasarelas y
enrutadores comerciales. IPSec integra confidencialidad, integridad y autentificación en un
mismo marco de interoperabilidad. Además, como trabaja a nivel IP, es transparente a la
aplicación, ya que esta no necesita modificación alguna, y ni siquiera se entera de la
existencia de criptografía intermedia, a diferencia de protocolos de nivel de transporte, como
son los túneles sobre TCP (SSL, SSH).
2.3 Acceso remoto y VPN
Una red VPN de acceso remoto permite a los usuarios individuales establecer conexiones
seguras con una red de computadores a distancia. Los usuarios pueden acceder a los
recursos seguros en esa red como si estuvieran conectados directamente a los servidores
de la red local. Un ejemplo de una empresa que necesita una VPN de acceso remoto es una
gran empresa con cientos de vendedores en el campo (González, 2002).
Hay dos componentes necesarios en una VPN de acceso remoto. El primero es un servidor
de acceso a la red (NAS – Network Access Server), también llamado una pasarela de
medios o un servidor de acceso remoto (RAS – Remote Access Server). Un NAS puede ser
un servidor dedicado, o podría ser una de las múltiples aplicaciones de software que se
ejecutan en un servidor compartido. El NAS requiere que el usuario proporcione
credenciales válidas para iniciar sesión en la VPN. Para autenticar las credenciales del
usuario, el NAS utiliza ya sea un proceso propio de autenticación o un servidor de
autenticación independiente que se ejecuta en la red (González, 2002).
El otro componente necesario de las VPN de acceso remoto es el software de cliente. En
otras palabras, los empleados que quieran utilizar la VPN desde sus computadoras
requieren software en los ordenadores que pueden establecer y mantener una conexión a la
VPN. La mayoría de sistemas operativos de hoy han incorporado software que puede
conectarse a redes VPN de acceso remoto, aunque algunos VPNs pueden requerir que los
usuarios instalen una aplicación específica. El software de cliente establece la conexión de
túnel a un NAS, que el usuario indica por su dirección de Internet. El software también
40
Las grandes corporaciones o empresas con personal de TI (Tecnologías de la Información)
con conocimientos suelen comprar, implementar y mantener sus propias VPNs de acceso
remoto. Las empresas también pueden optar por externalizar sus servicios de VPN de
acceso remoto a través de un proveedor de servicios empresariales (ESP – Enterprise
Service Provider). El ESP establece un NAS para el negocio y mantiene el NAS funcionando
sin problemas (González, 2002).
El propósito de una VPN es proporcionar una conexión privada segura y fiable entre redes
privadas de computadores a través de una red pública existente, típicamente Internet (Cisco,
2008).
Una VPN bien diseñada ofrece a un negocio los siguientes beneficios:
- Conexiones a través de múltiples ubicaciones geográficas sin necesidad de utilizar
una línea alquilada.
- Mejora de la seguridad para el intercambio de datos.
- Flexibilidad para oficinas y empleados remotos para utilizar la intranet del negocio a
través de una conexión a Internet existente como si estuvieran directamente
conectados a la red local.
- Ahorro en tiempo y dinero para los empleados si trabajan desde lugares remotos.
- Mejora de la productividad de los empleados remotos (Cisco, 2008).
Una empresa podría no requerir todos estos beneficios de su VPN, pero debe exigir las
siguientes características esenciales de VPN:
- Seguridad: La VPN debe proteger los datos mientras están viajando en la red
pública. Si los intrusos intentan capturar los datos, deben ser incapaces de leerlos o
utilizarlos.
- Confiabilidad: Los empleados y oficinas remotas deben ser capaces de conectarse a
la VPN sin ningún problema en cualquier momento (a menos que las políticas de las
empresas lo impidan), y la VPN debe proporcionar la misma calidad de conexión
para cada usuario, incluso cuando se está manejando un número máximo de
conexiones simultáneas.
- Escalabilidad: Como un negocio crece, debe ser capaz de extender sus servicios de
VPN para manejar ese crecimiento sin reemplazar la tecnología VPN completa
41
2.3.1 Encriptamiento y Protocolos de Seguridad.
El cifrado es el proceso de codificación de datos de forma que sólo un computador con el
decodificador correcto será capaz de leer y usar los datos transmitidos. Se podría utilizar el
cifrado para proteger los archivos en las computadoras o mensajes de correo electrónico
que se envíen. Una clave de cifrado indica a la computadora los cálculos necesarios que se
necesita realizar a los datos con el fin de cifrar o descifrar. Las formas más comunes de
cifrado son el cifrado de clave simétrica o cifrado de clave pública:
En el cifrado de clave simétrica, todas las computadoras (o usuarios) comparten la misma
clave que se utiliza tanto para cifrar y descifrar un mensaje (Charlie Scott, 1999).
En el cifrado de clave pública, cada equipo (o usuario) tiene un par de claves
pública-privada. Una computadora usa su clave privada para cifrar un mensaje, y otro equipo utiliza
la clave pública correspondiente para descifrar ese mensaje (Charlie Scott, 1999).
En una VPN, los ordenadores en cada extremo del túnel (conexión) cifran los datos que
entran en el túnel y descifran en el otro extremo. Sin embargo, una VPN necesita algo más
que un par de claves para aplicar el cifrado. Ahí es donde entran los protocolos. Una VPN
de punto a punto podría utilizar cualquiera de los protocolos de seguridad de protocolo de
Internet (IPSec) o encapsulación de enrutamiento genérico (GRE). GRE proporciona el
marco para la forma de empaquetar el protocolo para el transporte de datos a través del
protocolo de Internet (IP). Este marco incluye información sobre qué tipo de paquete está
encapsulando y la conexión entre el emisor y el receptor (Wikipedia, 2015).
Encapsulated Security Payload (ESP) cifra la carga útil del paquete (los datos que está
transportando) con una clave simétrica (Wikipedia, 2015).
Encabezado de autenticación (AH) utiliza una operación de hash36(función matemática
utilizada en encriptación) en la cabecera del paquete para ayudar a ocultar cierta
información de paquetes (como la identidad del remitente) hasta que llegue a su destino
(Wikipedia, 2015).
Los dispositivos de red pueden usar IPSec en uno de los dos modos de encriptación. En el
modo de transporte, cifrar los datos que viajan entre ellos. En modo túnel, los dispositivos
36
42
construyen un túnel virtual entre dos redes. Como se puede observar, VPNs IPSec utilizan el
modo túnel con IPSec ESP e IPSec AH trabajando juntos (Wikipedia, 2015).
En una VPN de acceso remoto normalmente se utiliza el protocolo punto a punto (PPP), que
forma parte de los protocolos nativos utilizados por Internet. Sin embargo, las VPN de
acceso remoto utilizan uno de los tres protocolos basados en PPP:
L2F (Layer 2 Forwarding) - Desarrollado por Cisco; no utiliza ningún esquema de
autenticación con el apoyo de PPP (Cisco, 2008).
2.4 Implementación de conexiones de capa 2
Implementaciones de capa 2 - Enlace
El encapsulamiento a este nivel ofrece ciertas ventajas ya que permite transferencias sobre
protocolos no-IP, como por ejemplo IPX4 de Netware Systems. Teóricamente, las
tecnologías implementadas en capa 2 pueden enviar datos a través de un “túnel” seguro de
comunicación, cualquier tipo de paquetes y en la mayoría de los casos lo que se hace es
establecer un dispositivo virtual PPP5 con el cual se establece la conexión con el otro lado
del túnel (Wikipedia, 2016).
Algunos ejemplos de estas tecnologías:
PPTP: “Point to Point Tunneling Protocol”. Desarrollado por Microsoft, es una extensión de
PPP (Wikipedia, 2016).
Su principal desventaja es que solo puede establecer un túnel por vez entre pares.
L2F: “Layer 2 Forwarding”. Desarrollado por la empresa Cisco principalmente, ofrece
mejores posibilidades que PPTP principalmente en el uso de conexiones simultáneas
(Wikipedia, 2016).
L2TP: “Layer 2 Tunneling Protocol”. Usado por Cisco y otros fabricantes, se ha convertido
en estándar de la industria y combina las ventajas de PPTP y L2F y además eliminando las
desventajas. Dado que esta solución no ofrece mecanismos de seguridad, para su uso
deberá ser combinada con otros mecanismos generalmente implementados en capa 3 del
43
Implementaciones de capa 3 - Red
IPsec es la tecnología más aceptada en este punto y fue desarrollada como un estándar de
seguridad de Internet en capa 3. IPsec se puede utilizar para encapsular cualquier tráfico de
capa 3 pero no el tráfico de capas inferiores, por lo que no se podrá utilizar para protocolos
no-IP como IPX37 o mensajes de broadcast. Su principal ventaja es que puede ser usado
prácticamente en cualquier plataforma existiendo una gran variedad de soluciones tanto de
software como de hardware (Wikipedia, 2016).
Existen dos métodos principales usados por IPsec:
Modo Túnel. Todos los paquetes IP son encapsulados en un nuevo paquete y enviados a
través del túnel siendo desempaquetados en el otro extremo y posteriormente dirigidos a su
destinatario final. En este modo, se protegen las direcciones IP de emisor y receptor así
como el resto de los metadatos de los paquetes (Wikipedia, 2015).
Modo Transporte. Solo la carga útil de la sección de datos es cifrada y encapsulada. La
sobrecarga entonces, es sensiblemente menor que en el caso anterior, pero se exponen los
metadatos a posibles atacantes que podrán ver quien se está comunicando con quien.
(Wikipedia, 2015)
Implementaciones de capa 7 - Aplicación
También es posible establecer túneles en la capa de aplicación y de hecho son ampliamente
utilizados hoy en día siendo algunas aproximaciones soluciones como SSL6 y TLS738. El
usuario accede a la VPN de la organización a través de un browser iniciando la conexión en
un sitio web seguro (HTTPS-Secured website)39 (Wikipedia, 2016).
Además, existen otros productos como SSL-Explorer40 y otros que ofrecen una combinación
de gran flexibilidad, seguridad fuerte y facilidad de configuración. La seguridad es lograda
mediante cifrado del tráfico usando mecanismos SSL/TLS41, los cuales han probado ser muy
seguros y están siendo constantemente sometidos a mejoras y pruebas. (Wikipedia, 2016)
37
https://es.wikipedia.org/wiki/IPX/SPX
38 https://es.wikipedia.org/wiki/Transport_Layer_Security
39
https://es.wikipedia.org/wiki/OpenVPN
40 https://en.wikipedia.org/wiki/SSL-Explorer:_Community_Edition
41
44 2.5. Redes VPN en Mac OS X Server 10.10
El servicio VPN en OS X Server y el cortafuegos de servidor permite el acceso desde dentro
y fuera de una intranet. La principal diferencia es que una VPN requiere de autenticación
para el acceso, pero el acceso a través de cortafuegos no requiere de autenticación. Si el
servicio de VPN esta encendido, no se necesita exponer algunos servicios del servidor a
través del cortafuegos. Por ejemplo, se puede permitir el acceso por cortafuegos a los
servicios de páginas electrónicas, sitios de consulta entre otros (sujetos a las
autenticaciones y restricciones que uno configure); mientras que los servicios de archivos
compartidos, contactos, calendario, mensajería, entre otros, se pueden brindar a través de
una conexión VPN.
Para garantizar la confidencialidad, autenticación e integridad de las comunicaciones, el
servicio VPN utiliza el protocolo L2TP de secreto compartido. El secreto compartido es como
una frase de contraseña, pero no se utiliza para autenticar a los usuarios de equipos cliente
para una conexión VPN. En cambio, permite que el servidor confíe en equipos cliente que
han compartido el secreto, y permite que los equipos cliente confíen en el servidor que tiene
el secreto. Ambos equipos servidor y cliente deben tener el secreto compartido (Davidsson,
2015).
Los computadores de los usuarios deben configurarse para realizar conexiones VPN. Los
ordenadores de los usuarios con OS X instalado se pueden configurar de forma automática.
Si desea permitir el acceso al servicio de VPN en Internet a través un enrutador por cable,
enrutador ADSL, u otro enrutador de la red:
- El enrutador debe tener el reenvío de puertos (mapeo de puertos) configurado para
el servicio de VPN.
- El enrutador y los enrutadores de los usuarios de VPN deben configurarse de modo
que no se asignan direcciones IP en conflicto (Davidsson, 2015).
Si se desea permitir el acceso al servicio de VPN fuera de la intranet y la intranet tiene un
dispositivo de cortafuegos separado, se necesita que el administrador del servidor de
seguridad abra en el cortafuegos los puertos y protocolos que utiliza el servicio de VPN. En
todo entorno corporativo se debe tener unas políticas de seguridad implementadas y
45
común, esta debería hacerse una norma en este mundo cada vez más interconectado
(Davidsson, 2015).
La configuración detallada de la red VPN, así como la implementación se describe en el
46
