Ángel Pérez Arroyo
1
Sistema para el seguimiento médico de pacientes
Máster Universitario en Ciberseguridad
Trabajo Fin de Máster
Autor:
Ángel Pérez Arroyo
Tutor/es:
Jose Luis Antón Bueso
Rafael Ignacio Álvarez Sánchez
Julio 2021
Ángel Pérez Arroyo
2
Índice de contenido
Resumen ............................................................................................................................................. 8
1. Introducción ............................................................................................................................... 9
1.1. ¿Qué es un sistema médico? ............................................................................................... 9
1.2. Estado del arte .................................................................................................................... 9
1.3. Ventajas de un sistema médico accesible desde Internet ................................................. 10
1.4. Objetivos del proyecto ..................................................................................................... 11
1.5. Metodología ..................................................................................................................... 12
2. Desarrollo del proyecto ............................................................................................................ 16
2.1. Elementos de seguridad requeridos para el sistema ......................................................... 16
2.2. Principios de seguridad aplicado ...................................................................................... 18
2.2.1. Perímetro de Seguridad ............................................................................................ 18
2.2.2. Superficie de Ataque ................................................................................................ 18
2.2.3. Principios de seguridad ............................................................................................ 19
2.2.4. Estrategias de defensa .............................................................................................. 25
2.3. Entorno de trabajo ............................................................................................................ 30
2.4. Tecnologías utilizadas ...................................................................................................... 34
2.4.1. Spring ....................................................................................................................... 34
2.4.2. Spring Boot .............................................................................................................. 42
2.4.3. Spring Data ............................................................................................................... 43
2.4.4. Spring Security ......................................................................................................... 45
2.4.5. Spring HATEOAS .................................................................................................... 59
2.4.6. Certificados SSL ...................................................................................................... 61
2.4.7. Claves RSA .............................................................................................................. 64
2.4.8. JWT .......................................................................................................................... 69
2.4.9. OpenID ..................................................................................................................... 73
2.4.10. OAuth 2.0 ................................................................................................................. 79
2.4.11. Docker ...................................................................................................................... 84
Sistema para el seguimiento médico de pacientes
3
2.4.11.1. WireGuard ............................................................................................................ 89
2.4.12. SSH ........................................................................................................................ 111
2.5. Diseño de la aplicación .................................................................................................. 113
2.6. Arquitectura de la aplicación .......................................................................................... 117
3. Funcionalidades del sistema ................................................................................................... 119
3.1. Swagger .......................................................................................................................... 119
3.1.1. Swagger integrado en Spring Boot ......................................................................... 120
3.1.2. Swagger UI ............................................................................................................. 123
3.1.3. Swagger junto con el servicio desarrollado ............................................................ 126
3.2. JavaDoc .......................................................................................................................... 128
4. Resultados .............................................................................................................................. 132
4.1. Ciudadano (Citizen) ....................................................................................................... 133
4.2. Paciente (Patient)............................................................................................................ 136
4.3. Administrador de Sistemas (System Administrator) ...................................................... 139
4.4. Personal Sanitario (Health Personnel) ............................................................................ 143
4.4.1. Médico (Doctor) ..................................................................................................... 145
4.4.2. Enfermero (Nurse) .................................................................................................. 149
4.4.3. Trabajador Social (Social Worker) ......................................................................... 151
4.5. Dispositivo (Device) ...................................................................................................... 155
4.6. Historial Médico (History) ............................................................................................. 158
4.7. Registro de Acceso (Access Register)............................................................................ 161
4.8. Auditoría (Audit) ............................................................................................................ 164
4.9. Clave Pública-Privada (Private-Public Key) .................................................................. 169
5. Conclusiones .......................................................................................................................... 174
5.1. Análisis de los resultados obtenidos ............................................................................... 175
5.2. Problemas encontrados durante el desarrollo ................................................................. 177
5.3. Posibles líneas futuras .................................................................................................... 179
6. Referencias ............................................................................................................................. 180
7. Glosario .................................................................................................................................. 183
Ángel Pérez Arroyo
4
Índice de Ilustraciones
Imagen 1. Kanban en GitHub ........................................................................................................... 14
Imagen 3. Modelo de Seguridad Positivo ........................................................................................ 21
Imagen 4. Anotaciones Java ............................................................................................................ 36
Imagen 5. MVC ................................................................................................................................ 38
Imagen 6. Método autenticate (AuthenticationManager) - Spring Security .................................... 46
Imagen 7. AuthenticationManager - Spring Security ....................................................................... 46
Imagen 8. Estructura Spring Security .............................................................................................. 47
Imagen 9. Personalización de la autenticación ................................................................................. 48
Imagen 10. Personalización autenticación (Global) ......................................................................... 49
Imagen 11. AccessDecisionVoter .................................................................................................... 49
Imagen 12. Web Security - Servlets ................................................................................................. 51
Imagen 13. Spring Security Filters ................................................................................................... 52
Imagen 14. FilterChainProxy ........................................................................................................... 53
Imagen 15. Personalización de cadenas de filtrado .......................................................................... 54
Imagen 16. Roles de usuario - Autorización .................................................................................... 55
Imagen 17. Activación SpringSecurity ............................................................................................ 56
Imagen 18. Método de seguridad personalizado .............................................................................. 56
Imagen 19. Spring Security corriendo en distintos hilos .................................................................. 57
Imagen 20. Procesamiento de forma asíncrona - Spring Security .................................................... 58
Imagen 21. Principio HATEOS aplicado en el servicio REST ........................................................ 60
Imagen 22. HTTP vs HTTPS ........................................................................................................... 61
Imagen 23. Comunicación cifrada ................................................................................................... 62
Imagen 24. JWT - Cabecera ............................................................................................................. 69
Imagen 25. JWT- Contenido ............................................................................................................ 69
Imagen 26. JWT - Firma .................................................................................................................. 70
Imagen 27. JWT - Codificado/Decodificado ................................................................................... 70
Imagen 28. Autenticación mediante JWT ........................................................................................ 71
Imagen 29. JWT del sistema - Codificado/Decodificado ................................................................. 72
Imagen 31. Diagrama de flujo - OpenID Connect ........................................................................... 76
Imagen 32. Arquitectura OpenID ..................................................................................................... 77
Imagen 33. Flujo de OAuth2 ............................................................................................................ 80
Imagen 34. Ejemplo de petición OAuth2 ......................................................................................... 82
Imagen 35. Ejemplo petición OAuth2 con Postman ........................................................................ 83
Sistema para el seguimiento médico de pacientes
5
Imagen 36. Contenedores tradicionales vs Docker .......................................................................... 85
Imagen 37. Conceptos de Keycloak ................................................................................................. 93
Imagen 38. Arquitectura Keycloak .................................................................................................. 94
Imagen 39. Manejo de usuarios no autenticados .............................................................................. 96
Imagen 40. Manejo de verficación de JWT ..................................................................................... 97
Imagen 41. Adaptadores para Java - Keycloak ................................................................................ 99
Imagen 43. Funcionamiento NetData ............................................................................................. 110
Imagen 44. Arquitectura del sistema .............................................................................................. 117
Imagen 45. pom.xml ...................................................................................................................... 120
Imagen 46. Configuración Swagger en Spring Boot ...................................................................... 121
Imagen 47. Interfaz Web Swagger ................................................................................................. 122
Imagen 48. Access Register - Swagger UI ..................................................................................... 123
Imagen 49. Etiqueta Java para Swagger ......................................................................................... 123
Imagen 50. Documentación petición REST utilizando Swagger ................................................... 124
Imagen 51. Documentación para Swaggeer en código fuente ....................................................... 125
Imagen 52. Uso del servicio a través de Swagger .......................................................................... 125
Imagen 53. JWT en Swagger UI .................................................................................................... 126
Imagen 54. Petición REST utilizando Swagger ............................................................................. 127
Imagen 55. Resultado petición REST en Swagger ......................................................................... 127
Imagen 56. Documentación JavaDoc en el código fuente ............................................................. 129
Imagen 57. Documentación JavaDoc - 1 ....................................................................................... 130
Imagen 58. Documentación JavaDoc - 2 ....................................................................................... 131
Imagen 59. Documentación JavaDoc - 3 ....................................................................................... 131
Imagen 60. CitizenController ......................................................................................................... 133
Imagen 61. Firma digital - Citizen Controller ................................................................................ 134
Imagen 62. Cuerpo petición - Citizen Controller ........................................................................... 134
Imagen 63. Resultado petición - Citizen Controller ....................................................................... 135
Imagen 64. PatientController ......................................................................................................... 136
Imagen 65. Firma digital - PatientController ................................................................................. 137
Imagen 66. Cuerpo petición - PatientController ............................................................................ 137
Imagen 67. Resultado petición - PatientController ........................................................................ 138
Imagen 68. SystemAdministratorController. ................................................................................. 139
Imagen 69. Firma digital - SystemAdministratorController .......................................................... 140
Imagen 70. Cuerpo petición - SystemAdministratorController ..................................................... 141
Imagen 71. Resultado petición - SystemAdministratorController ................................................. 142
Imagen 72. HealthPersonnelController .......................................................................................... 143
Imagen 73. Resultado petición - HealthPersonnelController ......................................................... 144
Ángel Pérez Arroyo
6
Imagen 74. DoctorController ......................................................................................................... 145
Imagen 75. Firma digital - DoctorController ................................................................................. 146
Imagen 76. Cuerpo petición - DoctorController ............................................................................ 147
Imagen 77. Resultado petición - DoctorController ........................................................................ 148
Imagen 78. NurseController ........................................................................................................... 149
Imagen 79. Resultado petición - NurseController .......................................................................... 150
Imagen 80. SocialWorkerController .............................................................................................. 151
Imagen 81. Firma digital - SocialWorkerController ...................................................................... 152
Imagen 82. Cuerpo petición - SocialWorkerController ................................................................. 152
Imagen 83. Resultado petición - SocialWorkerController ............................................................. 154
Imagen 84. DeviceController ......................................................................................................... 155
Imagen 85. Firma digital – DeviceController ................................................................................ 156
Imagen 86. Cuerpo petición - DeviceController ............................................................................ 156
Imagen 87. Resultado petición - DeviceController ........................................................................ 157
Imagen 88. HistoryController ........................................................................................................ 158
Imagen 89. Cuerpo petición - HistoryController ............................................................................ 159
Imagen 90. Resultado petición - HistoryController ....................................................................... 160
Imagen 91. AccessRegisterController ............................................................................................ 161
Imagen 92. Cuerpo petición - AccessRegistryController ............................................................... 162
Imagen 93. Resultado petición - AccessRegisterController ........................................................... 163
Imagen 94. AuditController ........................................................................................................... 164
Imagen 95. Cuerpo petición - AuditController .............................................................................. 165
Imagen 96. Resultado petición 1 - AuditController ....................................................................... 166
Imagen 97. Resultado petición 2 - AuditController ....................................................................... 167
Imagen 98. Public and Private Key Manager Encription Controller.............................................. 169
Imagen 99. Cuerpo petición 1 - Public and Private Key Manager Encription Controller .............. 170
Imagen 100. Resultado petición 1 - Public and Private Key Manager Encription Controller ....... 171
Imagen 101. Cuerpo petición 2 - Public and Private Key Manager Encription Controller ............ 172
Imagen 102. Resultado petición 2 - Public and Private Key Manager Encription Controller ....... 173
Sistema para el seguimiento médico de pacientes
7
Agradecimientos
Quiero agradecer a mi tutor D. Jose Luis Antón Bueso, de la empresa ALTIA CONSULTORES,
S.A. por su gran apoyo, dedicación e inestimable ayuda, sin ello no habría sido posible la
realización de este proyecto. Siempre ha puesto a mi disposición algo tan preciado como es su
tiempo para ayudarme en todo lo que he ido necesitando.
Ángel Pérez Arroyo
8
Resumen
En la actualidad, cuando algún paciente presenta alguna patología o circunstancia personal, que le
impide acudir a su centro de salud más cercano, el personal sanitario se ve en la necesidad de
desplazarse a los correspondientes domicilios particulares. Tras la visita al paciente, el sanitario
siguiendo un protocolo preestablecido debe actualizar el historial clínico del paciente con aquella
información que considere necesaria, reflejando así, su visita y seguimiento, para el caso de que
fuera necesario.
Como no se dispone de ninguna aplicación o herramienta, que permita a los sanitarios actualizar
“in situ” el historial del paciente, éstos, al final de su jornada laboral, deben volver al centro de
salud para actualizar todos los historiales médicos de los pacientes visitados. Por este motivo, el
objetivo del presente proyecto es crear un sistema, que permita enviar y recibir datos desde
cualquier punto de la geografía española de manera segura, dada la naturaleza sensible de los datos
a tratar.
Con esto, se consigue gestionar información útil y valiosa de forma rápida y más eficiente, a la vez
que supone una mejora laboral para el personal sanitario que realiza la intervención. Y siempre en
un contexto de máxima seguridad, siendo esto último el objetivo principal del presente proyecto.
Para ello, se han utilizado diversas técnicas de seguridad con las que garantizar en todo momento la
confidencialidad, integridad y disponibilidad.
Se han implementado diversas medidas para ofrecer un sistema lo más fiable y robusto posible
utilizando algoritmos de encriptación simétricos, asimétricos, redes VPN y certificados SSL para
cada uno de los servicios utilizados.
A lo largo del presente Trabajo Final de Máster se exponen todos los elementos y tecnologías
utilizadas para implementar el servidor del sistema propuesto.
Sistema para el seguimiento médico de pacientes
9
1. Introducción
1.1. ¿Qué es un sistema médico?
Se denomina “sistema” al conjunto de reglas o serie de principios que actúan de manera
inteligente entre sí, para formar una estructura mucho más grande. En cambio, el término
“médico” hace referencia a una organización, con una finalidad tan concreta y sensible para la
comunidad como es la gestión de nuestra salud.
Por lo tanto, el concepto sistema médico o sistema de salud hace referencia a la estructura, que
permite proporcionar asistencia sanitaria a la población de un territorio, ya sea a nivel local,
autonómico, nacional o internacional. Entre algunas de las múltiples funciones que desempeña
este tipo de sistemas son las de atender a pacientes con múltiples y muy variadas patologías.
1.2. Estado del arte
Los sistemas médicos actuales presentan varios defectos, ya que, éstos no se encuentran
adaptados o no recogen la totalidad de las necesidades sanitarias de los pacientes a los que
asiste. Entre las deficiencias que presenta se encuentra la imposibilidad de acceso,
visualización y actualización de los historiales médicos en una visita a domicilio.
Por ello, algo tan sencillo como puede ser consultar o modificar la medicación de un paciente o
bien, visualizar los resultados de una prueba, se convierte en una tarea lenta y tediosa al no
poder realizarse al momento. Esto además puede provocar errores por parte del personal a la
hora de introducir los datos de una visita, debido a que, no es lo mismo hacerlo cuando se
acaba de atender al paciente que, introducirlos al final de la jornada laboral, más aún cuando en
muchas ocasiones, por motivos de urgencia, no existe tiempo material para tomar notas.
Los sistemas actuales presentan un diseño “seguro”, pero únicamente desde el punto estático en
los que son accesibles. Pero ello resta eficacia al propio sistema en cuanto no se aborda el
acceso remoto a pesar de que existen multitud de tecnologías y técnicas con capacidad de
solventar esta necesidad de manera fiable.
Ángel Pérez Arroyo
10
1.3. Ventajas de un sistema médico accesible desde Internet
El sistema médico propuesto como proyecto de final de máster viene a cubrir una gran
necesidad que tienen los sanitarios encargados de atender a pacientes en sus domicilios, ya que,
en muchas ocasiones estos tienen que consultar datos sobre el seguimiento del paciente o el
resultado de alguna prueba y les es imposible, por no tener un acceso remoto.
Por ello, muchos profesionales se ven en la necesidad de preparar o mirar muy bien toda la
documentación necesaria de cada paciente antes de abandonar el centro de salud, con todo el
tiempo que esto implica. Además, añade otra variable, ya que, si el sanitario debe consultar
diversos expedientes médicos se incrementa la posibilidad de que aparezca el error humano.
Además, se le resta eficacia al sistema general en cuanto durante la visita a domicilio el
sanitario puede tener la necesidad de realizar la comprobación de datos o resultados de
pruebas, y al no tener el acceso inmediato, se debe realizar una segunda visita, por lo que, en
lugar de movilizar todos los medios para la atención de otro paciente, se ralentiza el sistema,
teniendo que repetir la asistencia.
Para el caso de que las visitas previstas por un sanitario hayan podido ir de acuerdo con lo
previsto en su agenda, al finalizar la jornada laboral el personal debe volver al centro de salud
y rellenar todos los informes de los pacientes que ha visitado, siendo este otro de los puntos
débiles de un sistema “tradicional”, ya que, el sanitario debe anotar o recordar toda la
información recopilada en sus visitas, para dejar constancia de ello en cada uno de los
correspondientes historiales médicos.
Por todo lo anteriormente descrito, se ha propuesto el sistema de seguimiento médico con el
claro objetivo de simplificar el día a día de los sanitarios, a la vez que se agilizar el sistema
disminuyendo el tiempo necesario de cada intervención domiciliaria y evitando segundas o
posteriores visitas, al mismo tiempo que, se tratan los datos médicos de los pacientes de una
manera fiable, aspecto fundamental dada la naturaleza sensible de los datos.
Sistema para el seguimiento médico de pacientes
11
1.4. Objetivos del proyecto
En este apartado se expondrán los objetivos propuestos al inicio del proyecto que además, se
han ido completando conforme pasaban cada una de los ‘sprints’ de trabajo definidos cada dos
semanas.
Dichos objetivos son:
● Definir un sistema que tenga como máxima principal la seguridad, el control de acceso
fiable a los datos y protección de los datos sensibles.
● El sistema debe ser accesible desde cualquier lugar de la geografía española.
● Tan sólo los usuarios registrados previamente en el sistema deben poder acceder.
● Controlar los permisos de cada usuario, para verificar si las acciones solicitadas están
autorizadas o no.
● Cifrar la información sensible de los datos.
● El acceso al sistema debe realizarse a través de una VPN con uso de claves
pública/privada.
● Uso de comunicaciones SSL entre cada elemento de la arquitectura del sistema, para
asegurar en todo momento una comunicación cifrada.
● Permitir a los sanitarios acceder a información actualizada y en tiempo real sobre un
paciente.
● Permitir a los sanitarios realizar registros y modificaciones sobre datos de los sanitarios
desde cualquier lugar.
● Aprender a utilizar tecnologías muy utilizadas en entornos empresariales como Spring
Boot.
● Gestión del proceso de autenticación utilizando el protocolo OpenID
● Gestión de los permisos de usuario utilizando el protocolo OAuth2.
Ángel Pérez Arroyo
12
1.5. Metodología
A lo largo del presente apartado de la memoria se procederá a explicar la metodología
utilizada para llevar a cabo el proyecto, así como las principales razones por las que se ha
elegido dicha metodología.
Metodología Kanban
Motivos ● Imposibilidad para poder emplear el mismo tiempo todas las
semanas.
● Falta de experiencia previa en los campos a tratar.
● Previsiones mal realizadas por la falta de experiencia.
● Todas las tecnologías utilizadas eran nuevas para mí.
Ventajas ● Se trata de una metodología ágil y flexible.
● Resulta sencillo, eficaz e intuitivo.
Dado el tema escogido para este Trabajo Final de Máster en Ciberseguridad, que consiste
en la creación e implementación de un sistema para consultar, registrar y modificar datos
médicos de pacientes desde cualquier lugar del país, todo ello, bajo el acuerdo con la
empresa ALTIA.
Conocía de antemano que me iba a encontrar con la problemática de tener que utilizar
tecnologías de implementación totalmente nuevas, y esto necesariamente aumenta el
tiempo de desarrollo. Por lo tanto, resultaba fundamental utilizar una metodología que
fuera ágil, flexible, pero sobre todo sencilla, que permitiera ir modificando las estimaciones
realizadas en un inicio para cada una de las tareas que componen el proyecto.
Sistema para el seguimiento médico de pacientes
13
En cuanto a la metodología, Kanban utiliza tarjetas para indicar a través de una serie de
etapas (Pendiente, En progreso y Finalizadas) las actividades pendientes de hacer, las
tareas que se encuentran en proceso y las que ya se encuentran terminadas o completadas,
así como una estimación en horas para completar cada una.
Algunas de las ventajas de Kanban son:
● Fácil organización: permite ver de una manera muy visual, rápida y sencilla, gracias a
las distintas columnas, aspectos como el flujo de trabajo actual o el número de horas
pendientes previstas hasta finalizar el proyecto.
● Distribución del trabajo: permite dividir y planificar mejor el trabajo al poder prever
fácilmente la cantidad de horas necesarias para completar la tarea. Aunque como se ha
indicado previamente, ésta podrá modificarse en cualquier momento debido a distintos
factores como puede ser la mala previsión en el cálculo de horas.
● Rendimiento: gracias al movimiento de cada una de las etiquetas, Kanban permite
también analizar si el proyecto va de acuerdo con la planificación prevista, retrasado o
más rápido de lo previsto.
Actualmente, existen multitud de herramientas gratuitas compatibles con Kanban, ya sean
online o de escritorio. Para el caso del presente proyecto, se decidió por comodidad utilizar
la incluida dentro de cualquier repositorio de GitHub, que permite ir moviendo las distintas
etiquetas a lo largo de las columnas tal y como se puede ver en la imagen inferior:
Ángel Pérez Arroyo
14
Imagen 1. Kanban en GitHub
En cuanto al coste de diseño y desarrollo del sistema tenemos el siguiente:
● Configuración del entorno de trabajo -> 3.5 horas
● Estudio de la documentación de Spring Boot -> 20 horas
● Realización de las guías oficiales para comprender el funcionamiento básico de
Spring Boot -> 40 horas
● Configuración básica del servidor utilizado -> 20 horas
● Aprendizaje de Docker -> 8 horas
● Configuración del contenedor MariaDB de manera apropiada -> 2.5 horas
● Configuración del servicio de VPN -> 6 horas
● Configuración del contenedor para desplegar el proyecto -> 4 horas
● Instalación y configuración del servidor Keycloak -> 10 horas
● Estudio y comprensión del funcionamiento del protocolo OpenID -> 6 horas
● Estudio y comprensión el funcionamiento del protocolo OAuth2 -> 5 horas
● Generación y configuración de certificados SSL para los servicios-> 6 horas
● Realización del diseño base del sistema -> 15 horas
● Desarrollo de proyecto
○ Gestión de Ciudadanos -> 10 horas
○ Gestión de Pacientes -> 4 horas
○ Gestión de Administradores de Sistemas -> 6.5 horas
○ Gestión de Personal Sanitario -> 5.5 horas
○ Gestión Médicos, Enfermeros y Trabajadores Sociales -> 8 horas
○ Gestión de Historiales Médicos -> 9 horas
○ Gestión de Control de Acceso -> 10 horas
Sistema para el seguimiento médico de pacientes
15
○ Gestión Dispositivos con Acceso al sistema -> 10 horas
○ Gestión del subsistema de auditoría -> 25 horas
○ Gestión para la realización y verificación de firmas digitales -> 12 horas
● Proceso de documentación del sistema -> 30 horas
● Generación del presente documento -> 60 horas
Por lo tanto, el coste de desarrollo de la aplicación para este Trabajo Final de Máster en
Ciberseguridad ha supuesto un total de 334 horas. Si valoramos la hora a 12 euros, la
aplicación tiene un coste total de aproximadamente 4.008 euros.
Ángel Pérez Arroyo
16
2. Desarrollo del proyecto
2.1. Elementos de seguridad requeridos para el sistema
Dada la alta sensibilidad de los datos tratados por el sistema, resulta crucial el proporcionar
un sistema lo más fiable posible reduciendo los posibles puntos de entrada, así como
vectores de ataque a ciberdelincuentes a través de los cuales puedan acceder a los datos
médicos o personales de las personas registradas en el sistema.
Para ello, se propone un sistema en el que toda comunicación, por muy poco sensible o
interna que pueda parecer, debe ir correctamente cifrada y protegida mediante los
mecanismos más apropiados de acuerdo a la situación. Asimismo, las acciones realizadas
por los usuarios se encuentran reducidas a las mínimas indispensables. También destacar
que, cualquier información que es recibida por el servidor desarrollado en conjunto con el
framework Spring es validada antes de ser procesada, con el objetivo de evitar ataques de
inyección de código, inyección de sentencias SQL y similares. Todo ello se expondrá con
más detalle a lo largo de este segundo apartado del documento.
En concreto, para el sistema médico desarrollado se trata de un servicio que no es accesible
de manera directa desde Internet, y para el que hay que tener un dispositivo previamente
registrado, es decir, el sistema tan sólo es accesible mediante un servicio VPN
(WireGuard) para el que se requiere de una clave privada RSA de 4096 bits, que
obviamente tenga su complementaria (clave pública) registrada y habilitada en el servidor.
Por lo tanto, toda comunicación entre los dispositivos móviles de los sanitarios y el
servidor, se realiza de manera segura a través de un túnel VPN.
Los dispositivos móviles una vez acceden a la red privada donde se encuentra accesible el
servicio, tienen restringido mediante Firewall el tráfico a tan sólo dos direcciones IP,
siendo éstas las únicas indispensables con las que deben compartir tráfico, que son el
servidor de autenticación y autorización Keycloak y el servidor desarrollado bajo la
tecnología de Spring Boot.
Tras ello, los usuarios tan sólo pueden comunicarse en primera instancia con el servidor
Keycloak mediante una conexión HTTPS, ya que, para poder hacer uso del servicio REST
desarrollado, es estrictamente necesario estar debidamente autenticado contra Keycloak
para obtener un JWT válido para hacer uso del servicio REST bajo una conexión HTTPS.
Sistema para el seguimiento médico de pacientes
17
Una vez el usuario dispone de su JWT e intente hacer uso del servicio REST, este último
procederá a verificar tres aspectos fundamentales para la seguridad del sistema que son:
verificación del JWT enviado junto a la petición HTTPS, verificación de que el terminal
solicitante está dado de alta y de que éste está habilitado para ser utilizado por el usuario
indicado en el JWT.
Por último, el servicio de base de datos MariaDB tan sólo es accesible por el servidor de
Keycloak y por el servicio REST desarrollado bajo el framework Spring.
A modo de resumen, se trata de un seguro con acceso limitado y controlado gracias al uso
de una defensa en profundidad, tanto en el sistema perimetral como una vez dentro de la
red donde se encuentra toda la infraestructura que da soporte al sistema. Este incluye
también diversas capas de seguridad para las comunicaciones, obligando a establecer
túneles VPN entre los clientes y el servidor de la aplicación, asimismo, toda comunicación
se obliga a que funcione sobre el protocolo HTTPS, añadiendo una capa adicional de
encriptación.
Ángel Pérez Arroyo
18
2.2. Principios de seguridad aplicado
A lo largo del presente apartado del documento se tratarán todos los principios y técnicas
de seguridad aplicados al sistema desarrollado, con el objetivo de proteger tanto a los datos
gestionados por el sistema, así como preservar que cualquier atacante pueda afectar al
correcto funcionamiento de la infraestructura levantada y requerida, para un correcto
funcionamiento del sistema.
Dada la alta importancia y sensibilidad de los datos tratados, el sistema desarrollado no es
accesible desde cualquier parte de Internet, como sí lo puede ser un servicio REST al uso,
por ejemplo Flickr. Por ello, con el objetivo de proporcionar las máximas garantías tanto a
los profesionales como a los pacientes registrados en el sistema, se han tomado una serie de
medidas que se van a detallar a lo largo de los siguientes subapartados.
2.2.1. Perímetro de Seguridad
La seguridad perimetral hace referencia a la frontera virtual que existe entre los elementos
que se quieren proteger y el resto. Para el caso particular del presente trabajo, el elemento a
proteger es el equipo servidor utilizado para levantar toda la infraestructura necesaria para
ejecutar con normalidad el sistema. Para el caso de utilizar más de un servidor la frontera
virtual estaría alrededor de los equipos que compondrían la infraestructura.
Por lo tanto, tan sólo a través del puerto reservado para el uso de WireGuard se puede
acceder al sistema. En caso de emplear cualquier otro puerto o protocolo de comunicación,
el cortafuegos integrado en el dispositivo descartará todos los paquetes entrantes.
2.2.2. Superficie de Ataque
Se podría definir como todos aquellos puntos de entrada existentes, que de ser utilizados
por un atacante comprometerían el sistema, ya sea, de manera parcial o total. Algunos
ejemplos de superficies de ataque existentes en el sistema:
● Las conexiones VPN dan acceso “físico” a la infraestructura utilizada. Se podría
llegar a atacar a la totalidad de elementos que componen la infraestructura.
Sistema para el seguimiento médico de pacientes
19
● Cualquier petición API del sistema presenta un vector de entrada, incluyendo los
parámetros proporcionados a la misma.
● Parámetros de las cabeceras utilizadas podrían llegar a comprometer el sistema si
se detectase alguna vulnerabilidad.
● La integridad del servidor Keycloak resulta un aspecto crucial para garantizar un
sistema fiable, ya que, si se comprometiera este elemento, el resto del sistema se
vería afectado de manera directa.
Dado que ningún sistema es perfecto e infalible, resulta crucial el detectar desde un inicio
todos los puntos y maneras de acceso, ya que, mediante una correcta planificación se
pueden prever la mayoría de las vulnerabilidades desde una fase muy temprana del
desarrollo. Finalizado éste y antes de su puesta en marcha en un entorno de producción, es
muy recomendable realizar un proceso de auditoría tanto interno como externo, con el
objetivo de verificar la correcta solución de todos los puntos de posibles ataques.
2.2.3. Principios de seguridad
A continuación, se exponen los principios de seguridad aplicados con el objetivo de
securizar el sistema, y hacerlo lo más fiable y robusto posible.
Seguridad en profundidad
Este principio determina que el nivel de seguridad de un
sistema se incrementa de manera sustancial, si se
aplican diversas capas de seguridad de manera
superpuesta. Es decir, no se aplica una sola medida para
proteger un componente del sistema, sino que, se
emplean varias con la finalidad de prevenir que, si una
de ellas falla, siempre exista una capa más que pueda
frenar el ataque.
Ángel Pérez Arroyo
20
Para el caso, de que se dispusiera de una única medida para defender una parte del
sistema, si ésta cae o falla, la totalidad del sistema podría verse comprometido.
De esta manera, se minimiza la posibilidad de que exista un punto débil o de fallo en el
sistema.
Para implementar esta capa de seguridad se han aplicado una serie de medidas, siendo
algunas de ellas las siguientes:
● El sistema tan sólo es accesible mediante VPN por el puerto y protocolo
designado.
● En el servidor utilizado se comprueba mediante una configuración de Firewall
si un paquete que entra sale o pasa (INPUT, OUTPUT, FORWARD) está
admitido o no.
● El servidor Keycloak y el servicio REST tan sólo escuchan en las direcciones
de la red física local y en las direcciones de la red virtual generada para el
servicio VPN.
● El servicio de base de datos tan sólo es accesible desde la red física local y por
el servicio REST. Usuario con mínimo privilegio aplicado.
● Se validan las credenciales y dispositivos utilizados por el personal.
● Las comunicaciones viajan cifradas en todo momento proporcionando un alto
grado de confidencialidad.
Modelo de Seguridad Positivo
El modelo positivo o también conocido como estrategia de lista blanca (whitelisting) se
trata de un modelo opuesto al tradicional negativo o de blacklisting, ya que, éste último
define todo aquello que está prohibido dando por válido cualquier petición que no
coincida con alguna condición de la lista.
En cambio, un enfoque mucho más seguro y eficaz es el modelo positivo, que hace
totalmente lo opuesto, dando por inválida o incorrecta una petición si ésta contiene
alguna parte que coincide con alguna de las reglas definidas. De esta manera, se puede
definir de forma mucho más clara, personalizada y efectiva la política a aplicar. Al
mismo tiempo, esta política también minimiza la posibilidad de introducir brechas de
seguridad, ya que, desde un inicio es mucho más restrictiva.
Sistema para el seguimiento médico de pacientes
21
Imagen 2. Modelo de Seguridad Positivo
Por lo tanto, podríamos decir que el modelo negativo permite una introducción sencilla
de errores, mientras que, el modelo de lista blanca se esfuerza por definir todo aquello
que es correcto y válido de utilizar. Esto último es mucho más laborioso, pero más
efectivo y seguro desde cualquier punto de vista.
El modelado de seguridad positivo se ha utilizado en multitud de lugares para validar
el contenido de las peticiones, con el objetivo de determinar si estas podrían
comprometer de alguna manera el sistema o no. Por ejemplo, con cada petición que el
sistema recibe, se valida si los campos a procesar contienen caracteres especiales
como: %,/,),$... Desechando automáticamente la petición para el caso de encontrarse
algunos de ellos.
Fallo Seguro
Se trata de uno de los errores más frecuentes durante la realización de software, y es el
correcto tratamiento y manejo de los errores que se producen en una aplicación. Este es
un proceso fundamental para poder proporcionar un producto de calidad, seguro y
robusto.
Los fallos más comunes los encontramos principalmente en dos aspectos:
• Excepciones producidas al saltar una alerta durante un paso del control de
seguridad.
• Excepciones producidas por una mala programación, que no contempla todos
los casos, llegando a producir bajo determinadas circunstancias que se lance
una excepción.
Ángel Pérez Arroyo
22
Solucionar este tipo de situaciones es mucho más sencillo de lo que podría parecer,
debido a que, los sistemas de seguridad tan sólo deben ofrecer 3 posibles resultados:
1. Permitir la operación (Se determina que todo es correcto).
2. Rechazar la operación (Se ha detectado algo extraño o perjudicial para el
sistema).
3. Lanzamiento de una excepción (Se produce una circunstancia no controlada).
Para el caso de los resultados 2 y 3, la aplicación debe comportarse de la misma
manera, que es, desechando la petición y sin informar de manera explícita al usuario de
que ha ocurrido un error, evitando así, proporcionar más información de la
estrictamente necesaria, ya que, podría ser perjudicial en un futuro.
Mínimo Privilegio
El principio del mínimo privilegio define que los usuarios utilizados para ejecutar
programas, establecer conexiones remotas, etc, deban tener la mínima cantidad de
privilegios imprescindibles para poder ofrecer el servicio de manera correcta.
De esta forma, para el caso de descubrirse una vulnerabilidad, el atacante se topará con
unos permisos muy limitados impidiéndole en la mayoría de las circunstancias que
acometa las acciones deseadas por este.
Este principio es un concepto muy importante a tener en cuenta al desarrollar un
sistema crítico, ya que, sistemas como el desarrollado se componen de distintos
elementos, que se unen para ofrecer el servicio proporcionado. Esto también tiene un
punto negativo y es que, al mismo tiempo, esos distintos elementos pueden tener
vulnerabilidades pudiendo llegar a comprometer a otros, y en el peor de los casos la
totalidad del sistema.
Por ejemplo, para el caso particular del software desarrollado, esta técnica se ha
utilizado para la base de datos, de tal manera que, tan sólo el usuario empleado tiene
acceso a la base de datos desde la dirección IP del servidor implementado bajo el
framework Spring. Asimismo, este usuario tan sólo tiene permisos para realizar
operaciones básicas en las tablas indicadas, no pudiendo realizar otra no definida
explícitamente para dicha tabla. A modo de protección adicional y aunque el sistema
Sistema para el seguimiento médico de pacientes
23
REST no define ninguna llamada para ello, las tablas “Audit” y “Access Register” tan
sólo permiten insertar y leer datos, no pudiendo eliminar ni modificar ningún registro
de estas, ya que, el usuario no dispone de los permisos necesarios. Así, se busca
preservar a toda costa los registros para dejar constancia de cada acontecimiento
producido en el sistema.
Importancia de la sencillez
Mantener un código fuente sencillo, claro y comprensible por cualquier desarrollador
es algo fundamental, pero en un sistema como el propuesto, esto se convierte en algo
indispensable. A este principio también se le conoce como principio KISS (Keep it
simple stupid).
Al mismo tiempo, aplicar correctamente este principio también permite aplicar o
contribuir otros principios de resiliencia como:
● Separar y aislar recursos.
● Mantener la ejecución de los distintos servicios y la información que éstos
manejan lo más alejada y oculta de los atacantes que sea posible.
● Defensa de cada capa de seguridad aplicada como si se tratara de la última.
Monitorización acciones realizadas
La monitorización continua en un sistema como el desarrollado en un entorno de
producción, resulta crucial para la correcta estabilidad de este.
Gracias a una correcta monitorización se pueden prevenir y solucionar problemas con
la suficiente antelación e impedir que estos se conviertan en problemas de gran
envergadura y puedan comprometer al sistema.
Por ello, además de la monitorización mediante la base de datos de las distintas
peticiones REST que el sistema atiende y procesa, se ha hecho uso de NetData, que es
un software especializado de monitorización de cargas de trabajo. Este software ofrece
información de manera totalmente gráfica y en tiempo real sobre cada uno de los
Ángel Pérez Arroyo
24
elementos del servidor, incluida información en particular de cada uno de los
contenedores de Docker empleados.
De esta manera, se puede analizar el consumo de CPU, disco, tráfico de red, etc, por
un administrador de sistemas con un solo vistazo.
Desconfianza de la infraestructura
En la actualidad, existe multitud de hardware que, aunque en un principio pueda
parecer igual al de otras marcas o modelos, presentan pequeñas diferencias que pueden
convertir a nuestro sistema en algo totalmente inutilizable y/o con multitud de
vulnerabilidades.
Es por ello que, aunque es correcto utilizar la infraestructura como una capa de
defensa, también es cierto que, nunca se debe dejar toda la responsabilidad a dichos
elementos, ya que, en caso de que estos sean distintos o funcionen de manera
incorrecta, las consecuencias podrían ser desastrosas para nuestro sistema
Por lo tanto, es necesario asegurarse de que tanto los requisitos de funcionalidad como
los de seguridad de un sistema se pueden proporcionar también mediante software, de
esta manera, en caso de fallo en la infraestructura utilizada siempre existirá una capa
software que pueda proteger al sistema (defensa en profundidad).
Otra gran aproximación de este principio es el uso de contenedores Docker, ya que,
este servicio permite definir entornos totalmente personalizados y fácilmente
replicables en otros equipos con una pequeña cantidad de acciones. Esto permite que
tanto la distribución como configuración del sistema en nuevas infraestructuras sea
mucho más rápida y eficaz. Asimismo, también garantiza que los componentes del
sistema siempre se ejecuten de forma idéntica, eliminando la posibilidad de fallo al
utilizar otro sistema operativo, distribución, paquetes, librerías, etc, ya que, siempre
serán las mismas.
Sistema para el seguimiento médico de pacientes
25
2.2.4. Estrategias de defensa
A continuación, se exponen algunas de las tácticas de defensa empleadas durante el
desarrollo, con el objetivo de mitigar o reducir los riesgos a los que el sistema debe hacer
frente. Como se ha venido defendiendo hasta el momento, ningún sistema informático
puede decirse que es seguro, ya que, siempre existirán brechas de seguridad o puntos
débiles, por lo que, siempre es recomendable aplicar una serie de estrategias con el objetivo
de fortalecer el sistema lo máximo posible.
Autenticación
Se trata del proceso que pretende confirmar que algo o alguien es efectivamente quien
dice ser. Este proceso se divide en dos partes o componentes que son: la parte
probadora y la parte verificadora.
En la parte probadora el usuario que desea acceder a una aplicación debe demostrarle
al sistema que es quien dice ser.
En cambio, en la parte verificadora sería el sistema quien debe confirmar y asegurar
que efectivamente el usuario que ha intentado acceder a su cuenta es el legítimo.
Para el caso del sistema desarrollado, un sanitario se autentica contra el sistema
mediante un usuario y contraseña con el objetivo de obtener un JWT, que
posteriormente le permitirá hacer uso del sistema API REST desarrollado utilizando el
framework Spring. Posteriormente, el sistema REST realizará una comprobación
adicional antes de cada petición, en la que también comprobará si el usuario
autenticado contra Keycloak, tiene el dispositivo asignado el utilizado.
Ángel Pérez Arroyo
26
Integridad
El principal objetivo de esta estrategia es la de prevenir y asegurar modificaciones no
autorizadas en la información tratada en un sistema.
Para prevenir este tipo de modificaciones normalmente se hacen uso de funciones
resumen, conocidas también como funciones hash o firmas digitales.
Durante el funcionamiento del sistema se hace uso de ambas técnicas para distintos
aspectos con el objetivo de asegurar con la mayor certeza posible, que la información
manejada no ha sido manipulada en ningún momento.
En el proceso de autenticación y autorización, el sistema REST desarrollado requiere
de un JWT emitido por el servidor Keycloak. Dicho token en su última parte incluye
una firma digital realizada a partir de una función “HS256”. De esta manera, el sistema
REST tan sólo tiene que verificar mediante la clave pública del servidor, que
efectivamente dicho token fue generado por él y que su contenido no ha sido alterado,
por lo que, se trata de un token válido.
Además, para cualquier petición HTTP (GET, POST, PUT o DELETE) requiere de
una firma digital que efectivamente valide la solicitud del usuario que ha realizado
dicha petición, para ello, el sistema almacena las claves públicas de los usuarios con
acceso.
Sistema para el seguimiento médico de pacientes
27
No Repudio
Las amenazas por repudio cada vez son más frecuentes e importantes en cualquier
sistema en Internet.
Para evitar este tipo de amenazas existen 4 elementos o técnicas para abordar esta
problemática:
● Evitar transacciones fraudulentas.
● Identificación de los elementos bajo disputa.
● Investigar los elementos bajo disputa.
● Determinar y ejecutar la mejor solución.
Para solucionar este tipo de amenazas el sistema está protegido bajo 3 técnicas
principales: registro de eventos, uso de firmas digitales y marcas de tiempo seguras.
El sistema registra cualquier tipo de acción que se lleve a cabo en él,
independientemente del contenedor que haya tramitado la petición. Es decir, por
ejemplo, si el servicio de VPN recibe una nueva conexión queda registrada, así como
cualquier tipo de comunicación que un dispositivo autorizado realice. De la misma
forma, el servicio REST desarrollado registra en unas tablas designadas para ello en. la
base de datos, cualquier tipo de petición HTTPS realizada por un usuario.
Además, el sistema requiere de firmas digitales que validen y acrediten en procesos de
auditoría futuros. Todo ello se realiza mediante el uso de firmas digitales para
cualquiera de las peticiones HTTPS realizadas contra el servicio REST.
También destacar que, el sistema también registra cada uno de los eventos mediante
marcas temporales seguras, ya que, se hace uso de un proveedor NTP fiable y de
confianza (“hora.redirisi.es”). Por lo tanto, todos los relojes de cada uno de los
elementos que componen el sistema se encuentran correctamente sincronizados,
dejando información clara y válida en los registros empleados.
Ángel Pérez Arroyo
28
Confidencialidad
Se debe tener muy en cuenta que los datos tratados por el presente sistema son
considerados como críticos, dada su alta sensibilidad. Por ello y por otros muchos
aspectos destacados en el presente documento, es muy importante que toda la
comunicación vaya correctamente cifrada y protegida.
Para solucionar la problemática de la comunicación entre los elementos que componen
el sistema, se ha hecho uso en todo momento de comunicaciones bajo el protocolo
HTTPS. De esta manera cualquier comunicación viaja de manera cifrada entre ambos
extremos.
Además, dado que las conexiones remotas (sanitarios en casa de pacientes) viajan a
través de una red totalmente insegura como es internet, es necesario añadir una capa
adicional de protección. Dicha capa se consigue al hacer pasar todo el tráfico del
sistema que viaja por Internet, a través de un túnel VPN. Esto proporciona una
seguridad que, junto con la comunicación cifrada mediante HTTPS, da lugar a un
intercambio de información con un grado de confiabilidad e integridad sumamente
elevado.
Autorización
Se trata de la acción y efecto de permitir que se lleve a cabo una acción. En definitiva,
se trata de reconocer a una persona la facultad o derecho de llevar a cabo una acción o
proceso.
Por lo tanto, aplicando esta estrategia lo que se busca es controlar qué usuario o grupo
de ellos pueden realizar ciertas acciones.
Para gestionar este proceso, los usuarios han sido clasificados en grupos para aplicar la
técnica de autorización basada en roles. Dichos roles son definidos en el servidor de
autorización del sistema, para que, de esta manera, cada vez que se emita un JWT se
defina en éste los roles o permisos a los que un usuario tiene acceso. Una vez se
incluyen estos datos en el JWT, el sistema REST ya puede comprobar antes de ejecutar
una petición HTTPS si el usuario que posee dicho token tiene los permisos necesarios
o no, para realizar dicha petición.
Sistema para el seguimiento médico de pacientes
29
En caso de que el usuario tenga los permisos suficientes, el sistema inicia el proceso
asociado a la petición realizada por el usuario. En cambio, si el usuario no está
habilitado para realizar dicha petición, simplemente se le denegará el acceso y no se
iniciará ningún proceso.
Ángel Pérez Arroyo
30
2.3. Entorno de trabajo
A lo largo del presente apartado se procederá a mostrar y explicar las principales herramientas
que han sido utilizadas para el desarrollo del proyecto desde un inicio, siendo éstas las
siguientes:
El software IntelliJ IDEA Ultimate ofrece un entorno de desarrollo
integrado, también conocido en el campo de la informática como IDE.
Este software ha sido desarrollado por la empresa JetBrains, y se
encuentra preparado para desarrollar software de cualquier tipo,
independientemente, del lenguaje de programación escogido (Listado de
lenguajes soportados). Para el caso particular del proyecto realizado para el presente trabajo, el
sistema se ha desarrollado utilizando el framework 1Spring Boot, para el cual el IDE dispone
de un gran soporte, ya que, incluye numerosas características que facilitan el desarrollo
utilizando dicho framework. [1]
Se trata de un software de pago, teniendo cada una de las distintas licencias que ofrece un coste
elevado. Por suerte, al ser estudiante de la Universidad de Alicante, adquirir una licencia
ampliable de un año del producto ha salido por 0 euros.
Se trata de un software que provee de todas las herramientas que un
desarrollador de Java necesita para crear cualquier tipo de aplicación o
sistema. Dicho software permite instalarse tanto en un ordenador de
manera local como ha sido el caso, o bien, instalarse en una unidad de red
para ser compartido por varios dispositivos al mismo tiempo. Para su
correcta configuración, tan sólo se deben generar tres variables de
entorno con los siguientes valores:
● JAVAPATH: ruta desde la raíz del sistema hasta la ubicación
donde se tienen los binarios el JDK2.
● CLASSPATH: debe hacer referencia a las bibliotecas o librerías
propias definidas por un usuario del software.
● PATH: se debe incluir la ruta absoluta donde se tiene el directorio
con todo el contenido del JDK descargado y descomprimido. [2]
1 Consultar en el glosario 2 Consultar en el glosario
Sistema para el seguimiento médico de pacientes
31
Se trata de una herramienta para la gestión y construcción de proyectos
software para los que se utiliza como lenguaje de programación Java.
Ofrece una funcionalidad similar a Gradle o Apache Ant, pero con la
diferencia de que éste ofrece un sistema de construcción mucho más
sencillo, que se encuentra basado en XML.
Maven permite definir en un único fichero conocido como “pom.xml”,
sobre el que se aplica la técnica conocida como Project Object Model. A
través de este fichero, los proyectos Java basados en Maven permiten
construir el proyecto, al definirse en éste todas las dependencias
(directivas “dependencies” y “dependecy”), módulos (etiqueta “modules”
y “modul”), el orden de construcción del proyecto, así como cualquier
otro componente externo que se necesite durante el proceso.
Como una de sus principales ventajas presenta la gran facilidad a la hora de descargar cualquier
tipo de plugin o dependencia, ya que, éste antes de iniciar el proceso de construcción del
proyecto, inicia una sesión con el “Maven Central Repository” y descarga al equipo todos los
paquetes que sean necesarios, y tras ello, inicia el proceso de construcción. [3]
Por último, hay que destacar que Maven dispone de un ciclo de vida dividido en 9 partes,
siendo las principales las siguientes:
• Compile. Compila los ficheros con extensión “.java” para generar los ficheros
“.class”, para que puedan ser utilizados por la máquina virtual del lenguaje.
• Test. Permite ejecutar las pruebas JUnit incluidos en el proyecto, finalizando la
ejecución del proceso de construcción, si alguno falla.
• Package. Genera un fichero con extensión “.jar” siendo este resultante de la
compilación, y permitiendo su ejecución en cualquier equipo con Java instalado y
configurado correctamente.
• Install. Copia el fichero generado en la fase “Package” al repositorio local de
Maven en el equipo. Esto permite acceder al paquete en futuros desarrollos como si
de un paquete o dependencia común se tratara.
• Deploy. Copia el fichero generado en la fase “Package” a un repositorio de Maven
en la nube. Esto permite a otros desarrolladores acceder y utilizar el paquete
generado en cualquier proyecto Maven.
Ángel Pérez Arroyo
32
HeidiSQL es un cliente administrador de bases de datos de código abierto
que permite a los usuarios conectarse y administrar bases de datos SQL
como Microsoft SQL Server, PostgreSQL o MariaDB (Base de datos
utilizada). Gracias al uso de este cliente gráfico, se ha podido verificar de
manera fácil y sencilla el estado de las tablas de la base de datos, así como
el correcto funcionamiento de las acciones realizadas por la aplicación
servidora de este proyecto entre otras. [4]
Postman es una herramienta gratuita que busca facilitar y comprobar el
correcto funcionamiento de desarrollo de proyectos REST, SOAP y
GraphQL.
Como principal ventaja que ofrece es la de poder realizar y comprobar el
funcionamiento de manera sencilla de todo tipo de peticiones HTTP como
HTTPS sin la necesidad de implementar un cliente, abstrayendo y
reduciendo toda la problemática asociada. [5]
GitHub Desktop se trata del cliente oficial de la plataforma desarrollo
colaborativo GitHub, que permite alojar y manejar todo tipo de proyectos
software utilizando como base el control de versiones de Git. A través de
este software se han gestionado todas las versiones y mejoras añadidas al
sistema tras completar cada una de las tareas propuestas. [6]
Microsoft Visio se trata de un software especializado para el diseño de todo
tipo de diagramas, que van desde el modelado de planos a la generación de
diagramas de trabajo, pasando por la creación de diagramas UML y diseños
de bases de datos.
Para el caso del proyecto, la herramienta se ha utilizado para generar el
diagrama UML, así como para generar los diagramas de flujo que aparecen
más adelante, con el objetivo de exponer de una manera más sencilla y
visual el funcionamiento del presente proyecto realizado como trabajo de
final del máster. [7]
Sistema para el seguimiento médico de pacientes
33
En el equipo utilizado para realizar todo el desarrollo del presente proyecto,
se ha empleado el sistema operativo Windows 10, porque permitía un
acceso rápido a todas las herramientas descritas anteriormente.
En cambio, para el servidor del proyecto, que ha sido una Raspberry Pi 4 se le
ha instalado la última versión disponible estable LTS de Ubuntu Server.
Además, sobre dicho equipo se ha instalado y configurado todo lo necesario
para el correcto funcionamiento del sistema, siempre teniendo como máxima
la seguridad.
Ángel Pérez Arroyo
34
2.4. Tecnologías utilizadas
A lo largo del presente apartado se procederá a describir con mayor detalle todas las
tecnologías utilizadas para llevar a cabo el proyecto siendo Spring y los proyectos
complementarios a éste, los utilizados para el desarrollo del servicio API REST que permite la
gestión de datos médicos objetivo del presente trabajo.
2.4.1. Spring
Spring es un framework de código abierto enfocado al desarrollo de
todo tipo de aplicaciones bajo la plataforma de desarrollo de Java
(JDK). Asimismo, el framework también incluye un contenedor de
inversión de control3 que es muy útil para poder obtener un mayor
grado de abstracción.
El framework fue originalmente lanzado en el 2002, pero a lo largo de los años se le han
ido añadiendo cada vez más funcionalidades, llegando a modificar gran parte de los
lenguajes utilizados, con el objetivo de adaptarse siempre a las últimas tendencias. Por ello,
el framework en la actualidad está programado utilizando Java, Kotlin y Groovy.
Además, Spring permite utilizar tanto Maven como Gradle con el objetivo de facilitar la
adopción de los entornos de trabajo ya existentes a la utilización de esta tecnología, que
como así la definen sus propios creadores, convierte a Java en un lenguaje de
programación moderno.
El framework utilizado para el desarrollo del proyecto se encuentra dividido en distintos
módulos, que pueden ser añadidos y utilizados por los desarrolladores de manera
totalmente independiente. Por lo tanto, en un proyecto se pueden determinar qué módulos
del Framework son necesarios y cuáles no. Reduciendo las dependencias del proyecto,
eliminando puntos de fallo y convirtiendo a la aplicación desarrollada en una mucho más
ligera y estable. En cuanto a los módulos del framework son muchos y variados, a
continuación, se muestra un resumen con 5 importantes módulos que construyen el
proyecto global de Spring. [8]
3 Consultar en el glosario
Sistema para el seguimiento médico de pacientes
35
Contenedor de inversión de control
Se trata del corazón o núcleo del framework, ya que, se encarga de multitud de
acciones, entre ellas, instanciar, inicializar y conectar cualquier tipo de objeto definido
en la aplicación. Además, también se encarga de simplificar una enorme cantidad de
tareas cotidianas con el framework, lo que acelera enormemente el ritmo de trabajo, al
proporcionar un mayor nivel de abstracción.
Cualquier objeto creado y gestionado por el contenedor es llamado y etiquetado en el
programa desarrollado como “Bean” (Etiquetado en el programa como “@Bean”),
siendo esta la manera que tiene Spring de identificar, durante el proceso de
construcción del proyecto, a los objetos que deben ser creados y gestionados por él.
Comúnmente, este tipo de objetos suelen ser del tipo conocido como POJO4. Para
poder ser manejados por el módulo es necesario una serie de información que se
conoce como metadatos de configuración. Existen 3 tipos de metadatos posibles,
teniendo cada uno de ellos sus ventajas y desventajas, pudiendo incluso utilizar de
manera totalmente independiente, cualquiera de ellos:
● Etiquetas XML
● Anotaciones Java
● Objetos Java
La opción seleccionada para el desarrollo de la aplicación ha sido la segunda, ya que,
es una manera clara e intuitiva de registrar una serie de metadatos en el código fuente
del programa para que, en tiempo de ejecución y/o compilación dependiendo de la
“Bean” definida, se encuentren disponibles para un correcto proceso de construcción y
ejecución de la aplicación.
4 Consultar en el glosario
Ángel Pérez Arroyo
36
Las anotaciones se realizan de la siguiente manera:
Imagen 3. Anotaciones Java
La imagen superior se corresponde con un ejemplo real utilizado en la clase
“HistoryController” de la aplicación desarrollada. Las anotaciones se declaran en el
código fuente utilizando su nombre identificador precedidas del carácter “@” [9]
Ventajas del uso de anotaciones Java
Las anotaciones de Java permiten a los desarrolladores declarar en el código fuente de
la herramienta en proceso de desarrollo, la manera en la que se desea que el software se
comporte, con el simple hecho de añadir una pequeña anotación al mismo.
Desventajas del uso de anotaciones Java
Las anotaciones Las desventajas que presenta este sistema principalmente son dos:
1. Al utilizar anotaciones es necesario añadir en tiempo de ejecución una gran
cantidad de metadatos si se hace uso de diversas anotaciones simultáneas, lo
que puede producir una sobrecarga de la memoria requerida por el software.
2. Asimismo, existen pocos o nulos estándares que se encarguen de regular y
especificar el uso de este tipo de anotaciones, lo que provoca que cada
desarrollador las utilice como considere, provocando en muchas ocasiones
conflictos con el desarrollo llevado a cabo por otro programador.
Según los desarrolladores de Spring: “Spring’s flexible and comprehensive set of
extensions and third-party libraries let developers build almost any application
imaginable. At its core, Spring Framework’s Inversion of Control (IoC) and
Sistema para el seguimiento médico de pacientes
37
Dependency Injection (DI) features provide the foundation for a wide-ranging set of
features and functionality. Whether you’re building secure, reactive, cloud-based
microservices for the web, or complex streaming data flows for the enterprise, Spring
has the tools to help.”
Programación orientada a aspectos
Se trata de un paradigma de programación, que permite una muy alta modularización y
desacoplamiento del código desarrollado, al permitir separar de una manera mucho
más clara y simple las distintas responsabilidades de una misma aplicación. Esto da
como resultado un código mucho más comprensible, fácil de aceptar nuevos cambios y
mejoras, así como permite una mayor reusabilidad de un mismo método o clase por
distintos métodos.
Además, el uso de esta programación permite también controlar de una mejor manera
el funcionamiento de la aplicación, al mantener el funcionamiento de la aplicación lo
más sencillo posible (principio KISS), reduciendo los puntos de fallo o de introducción
de brechas de seguridad, algo sumamente importante dada la importancia de los datos
procesados por el sistema, ya que, cualquier tipo de fuga de información del sistema es
considerada como crítica. [10]
Gestión de transacciones
Se trata del módulo del framework encargado de gestionar y unificar, la manera en la
que se hace uso de las distintas APIs para coordinar las distintas transacciones para los
objetos Java generados y procesados durante la ejecución de un programa desarrollado
bajo Spring.
Ángel Pérez Arroyo
38
Modelo-vista-controlador (MVC)
El modelo vista controlador (MVC) se trata de un
patrón básico y fundamental de la arquitectura del
software, que permite separar en tres capas muy
diferenciadas el acceso a datos (modelo), la lógica de
negocio (controlador) y la representación que se le
muestra al usuario (vista).
Los principales propósitos del modelo son la reutilización de código y la
delegación de responsabilidades. Con esto lo que se consigue es eliminar lo
conocido como “código spaguetti”.
● Modelo. Hace referencia a la representación de la información con la que el
sistema opera. En este caso se trataría de la información médica de pacientes,
gestión de sanitarios, personal administrador, etc, al tratarse de un sistema para la
gestión médica de datos de pacientes. Para el caso del software desarrollado, la
presente capa del modelo se ha denominado “Service”, siendo en dicha capa la
encargada de gestionar las consultas, actualizaciones e inserciones de datos. Según
la referencia del modelo MVC, esta capa también debería ser la encargada de
gestionar los privilegios de acceso a los datos, pero dado que se ha utilizado Spring
Security (se explica más adelante en el presente documento), que ofrece una mejor
y más fácil gestión y administración.
Por último, hay que destacar que, dado que esta capa es la que gestiona los datos,
así como las instrucciones sobre las tareas a realizar que son enviadas desde la
capa Controlador.
● Controlador. Hace referencia a la capa encargada de responder y atender los
distintos eventos que suceden en la aplicación. Para el caso particular del software
desarrollado, esta capa hace referencia a las clases de Java denominadas con la
terminación “Controller”. Dichas clases son las encargadas de atender y procesar
las distintas peticiones API REST que se incluyen en el sistema.
Por lo tanto, esta capa del patrón ha sido la encargada de enviar la información
necesaria a la capa “Service”, denominada en el modelo como “Modelo”, así como
devolver los datos producidos por la capa “Service” al usuario.
Normalmente, los datos se devolverían al cliente del sistema, para el caso
particular del proyecto desarrollado, los datos devueltos por el controlador han sido
visualizados y verificados a través de una respuesta HTTPS con un cuerpo del
Imagen 4. MVC
Sistema para el seguimiento médico de pacientes
39
mensaje en formato JSON, que contienen la información que el cliente del sistema
tendría que utilizar para mostrarle la información de manera visual al usuario.
● Vista. Se trata de la tercera y última capa del sistema, con la que se busca la
manera adecuada de interactuar con el usuario. Esta capa normalmente hace
referencia a la interfaz de usuario (aplicación cliente), que por lo tanto requiere de
un modelo adecuado para mostrar al usuario la información devuelta por el
servidor del sistema de una manera apropiada.
Al delegar responsabilidades en determinadas clases y eliminar código repetido se
promueve la reusabilidad, mantenimiento y seguridad entre otros muchos factores,
ya que, no es lo mismo solucionar, mantener o ampliar un programa correctamente
estructurado que uno desarrollado sin utilizar un modelo apropiado. Un desarrollo
no correctamente estructurado desde un inicio es altamente propenso a incluir
numerosos errores y problemas de seguridad.
Por los motivos descritos anteriormente, son por los que se decidió utilizar dicho
modelo para el desarrollo del software desarrollado como objetivo del presente
trabajo. [11]
Testing
La realización de pruebas o testing como se conoce en inglés a esta idea, hace referencia a
la investigación tanto empírica como técnica, que proporcione una visión global sobre la
calidad de un producto software. Esta fase es la más crucial para el proceso de control de
calidad.
Existen diversos tipos de pruebas que varían en su enfoque con el objetivo de abarcar y
verificar la mayor cantidad posible de líneas de código de un producto. De esta manera, se
puede tener una mejor perspectiva sobre el correcto funcionamiento de cada una de las
secciones de un producto software.
Este tipo de pruebas se pueden dividir principalmente en dos tipos:
● Pruebas estáticas. Se trata de un tipo de prueba que se realiza sin la necesidad de
ejecutar nada de código de una aplicación. Un símil a este tipo de pruebas podría
decirse que es la revisión de documentos. Se revisa de manera visual el código
fuente de una aplicación o sección de esta, con el objetivo de seguir y analizar los
distintos flujos o caminos que contiene una herramienta.
Ángel Pérez Arroyo
40
● Pruebas dinámicas. Este tipo de pruebas se caracterizan a diferencia de las
anteriores en que sí requieren la ejecución de la aplicación o al menos de secciones
de esta. Gracias al uso de técnicas como las de caja negra y caja blanca, se puede
verificar el correcto funcionamiento en detalle, al poder comprobar el producto en
entornos más reales o similares a los que se va a tener que enfrentar el producto
software desarrollado.
Para elaborar los distintos casos de prueba diseñados e implementados con el objetivo de
comprobar la correcta calidad del producto desarrollado, se ha hecho uso de pruebas
unitarias. Este tipo de pruebas se encuentran englobadas dentro de las pruebas dinámicas,
ya que, ejecuta código fuente de la aplicación y, además, permiten verificar de manera muy
localizada secciones de un desarrollo. Por lo tanto, permiten hacer una serie de pruebas
muy localizadas, asegurando con mayor certeza la correcta calidad de un producto por las
distintas secciones que lo componen. [12]
A continuación, se van a describir algunas de las ventajas e inconvenientes que presentan
este tipo de pruebas:
Ventajas
1. Permiten delimitar más fácilmente los errores al encontrarse estos más acotados.
Una continua etapa de tests unitarios es muy aconsejada en desarrollos grandes o
con muchos elementos involucrados.
2. Permiten documentar el código al proporcionar ejemplos de su utilización.
3. Simplifican el proceso de integración debido a la gran eliminación de errores
descubiertos durante la fase de tests unitarios.
Desventajas
1. Las pruebas unitarias nunca afloran la totalidad de errores de un código fuente al
que se han pasado diversas pruebas.
2. Las pruebas requieren mucho tiempo para abordar la mayor cantidad de casos
posibles.
3. Las pruebas unitarias son más eficaces si se aplican junto con otras pruebas de
software.
Dada la importancia de este tipo de pruebas, el propio framework incluye un módulo
específico que simplifica esta tarea de manera notable. Además, conocedor también de lo
valiosa que es a la correcta documentación de estas pruebas, Spring incluye una etiqueta o
Sistema para el seguimiento médico de pacientes
41
anotación de Java llamada “AutoConfigureRestDocs”, que libera a los ingenieros de
software encargados de las pruebas de documentar gran parte de las pruebas diseñadas.
Gracias a la gran potencia del framework existen diversos casos de éxito en empresas
importantes en las que Spring ha ayudado enormemente. Por ejemplo, según el líder de
transformación del área digital de la empresa “DICK’S SPORTING GOODS” destaca lo
siguiente de Spring: “We use a lot of the tools that come with the Spring framework and
reap the benefits of having a lot of the out of the box solutions, and not having to worry
about writing a ton of additional code—so that really saves us some time and energy”.
En español lo dicho por SEAN GRAHAM sería: “Usamos muchas de las herramientas que
vienen con el marco de Spring y nos beneficiamos de los beneficios de tener muchas de las
soluciones listas para usar y no tener que preocuparnos por escribir multitud de código
adicional, por lo que realmente nos ahorra algo de tiempo y energía”.
Ángel Pérez Arroyo
42
2.4.2. Spring Boot
El framework Spring incluye diversos módulos de desarrollo
oficiales totalmente listos para ser utilizados, siendo uno de
los más conocidos Spring Boot.
Este módulo del framework ha sido empleado desde un inicio para llevar a cabo el
desarrollo de la aplicación servidor del sistema implementado como parte de este proyecto
final de máster.
Una de las principales ventajas del uso de módulos oficiales de Spring es que reducen
drásticamente el tiempo de desarrollo de cualquier tipo de aplicación, sin repercutir en la
seguridad o en algún otro aspecto fundamental de la misma. Esto es debido a que cada
módulo es desarrollado de manera directa y revisado por la comunidad de desarrollo del
framework, permitiendo así, ofrecer a la comunidad una gran herramienta al mismo tiempo
que segura.
Por lo tanto, podríamos decir que es Spring Boot es una extensión o “suite”, que viene
preconfigurado para ejecutar aplicaciones Spring desde el primer momento y sin perder
flexibilidad.
Un caso particular de adopción de esta tecnología ha sido Netflix. Según el ingeniero de
software senior de Netflix TAYLOR WICKSELL: “Originally [Netflix's Java] libraries and
frameworks were built in-house. I'm very proud to say, as of early 2019, we've moved our
platform almost entirely over to Spring Boot.”
En español lo dicho por TAYLOR WICKSELL sería: “Originalmente, las bibliotecas y
frameworks se construían internamente. Estoy muy orgulloso de decir que, a principios de
2019, hemos trasladado nuestra plataforma casi por completo a Spring Boot.” [13]
Sistema para el seguimiento médico de pacientes
43
2.4.3. Spring Data
Con objetivo de simplificar y poder acceder a todas las
características que ofrece Spring para acceder a datos, se ha
hecho uso del módulo Spring Data. El principal objetivo de
Spring Data (módulo de acceso a datos) es el de proporcionar a
los desarrolladores del framework un modelo sencillo y
coherente, para poder ser utilizado en cualquier tipo de
proyecto sin problemas.
En particular, el módulo está desarrollado para facilitar la conexión y acceso a cualquier
tipo de dato: bases de datos relacionales (SQL), bases de datos no relacionales (NoSQL),
marcos de reducción de mapas, así como servicios de datos basados en la nube.
Para poder ofrecer un gran producto a la comunidad, Spring Data se encuentra desarrollado
de manera totalmente desacoplada. De esta manera, existen multitud de subproyectos
desarrollados en colaboración con personal de distintas empresas, para poder ofrecer un
producto que facilite el acceso a datos independientemente de la forma de almacenamiento.
Por ejemplo, existe un subproyecto en específico desarrollado para manejar conexiones con
bases de datos MariaDB, que ha sido la base de datos utilizada.
A continuación, se muestra un listado con todos los módulos que incluye Spring Data para
manejar el acceso a multitud de maneras de almacenar información:
● Spring Data Commons: se trata de un módulo con elementos comunes al resto.
Con esto se busca desacoplar el código y favorecer su reusabilidad.
● Spring Data JDBC: permite a Spring dar soporte al repositorio de Spring Data para
JDBC.
● Spring Data JDBC (Extensión): proporciona soporte para extensiones específicas
de base de datos que la versión estándar no permite. Además, incluye soporte para
la conmutación por error de conexión rápida de Oracle RAC, soporta AQ JMS, así
como el uso de tipos de datos avanzados.
● Spring Data JPA: permite a Spring dar soporte al repositorio de Spring Data para
JPA.
Ángel Pérez Arroyo
44
● Spring Data KeyValue: añade soporte para el uso de repositorios basados en mapas
y SPI5, que permiten a Spring Data construir fácilmente almacenes de claves.
● Spring Data LDAP: soporta el acceso a datos en árboles LDAP.
● Spring Data MongoDB: proporciona soporte para utilizar los repositorios que
permiten manejar objetos basados en Spring para MongoDB.
● Spring Data Redis: ofrece una fácil configuración y acceso a Redis desde cualquier
aplicación desarrollada utilizando el framework Spring.
● Spring Data REST: permite exportar de manera directa los repositorios de Spring
Data como recursos Restful.
● Spring Data para Apache Cassandra: módulo específicamente diseñado para
ofrecer una fácil configuración y acceso a Apache Cassandra o aplicaciones Spring
a gran escala, con alta disponibilidad y orientadas a datos.
● Spring Data para Apache Geode: módulo específicamente diseñado para ofrecer
una fácil configuración y acceso a Apache Geode para aplicaciones Spring con alta
fiabilidad, baja latencia y orientadas a datos.
● Spring Data para Pivotal GemFire: módulo específicamente diseñado para ofrecer
una fácil configuración y acceso a Pivotal GemFire para aplicaciones basadas en
Spring con alta fiabilidad, baja latencia, alto rendimiento y orientadas a datos. [14]
5 Consultar en el glosario
Sistema para el seguimiento médico de pacientes
45
2.4.4. Spring Security
Dada la problemática de la seguridad siendo ésta un
aspecto crítico en un sistema como el propuesto, se
han aplicado diversas capas de seguridad con el
objetivo de aplicar una defensa en profundidad, que
permita proteger de ciberdelincuentes los datos
personales de los pacientes, así como de los
sanitarios y administradores de sistemas registrados.
Spring Security ha sido el elemento de seguridad principal empleado en la capa software,
que al igual que los dos anteriores módulos, se trata de uno totalmente configurado y
preparado para funcionar con cualquier proyecto Spring, al disponer de total apoyo y
soporte de manera oficial.
Con este módulo se han controlado partes fundamentales de la seguridad como son:
● Las peticiones generadas por los sanitarios que se encuentren en casa de pacientes
deben provenir de un rango específico de red (Acceso al sistema mediante VPN, se
detalla más adelante).
● Los administradores del sistema tan sólo disponen de acceso desde su dirección IP
preasignada.
● No se almacenan contraseñas, al disponer de un servidor de autenticación y
autorización (Keycloak) externo.
● Se controla mediante una gestión de roles de usuario, si el usuario autenticado
dispone de los permisos necesarios para realizar dicha petición API.
Normalmente los principales problemas de seguridad de cualquier aplicación son la
autenticación (¿quién es?) y la autorización (¿está autorizado a realizar la acción?). Por ese
motivo, Spring Security está especialmente diseñado desde un inicio para separar y
personalizar como se desee tanto el proceso de autenticación como el de autorización. [15]
Ángel Pérez Arroyo
46
Autenticación
La principal interfaz de estrategia para la autenticación es AuthenticationManager, que solo
contiene un método:
El método anterior puede devolver 3 cosas:
1. Devolver un objeto de tipo Authentication que sirve para indicar que las
credenciales del usuario son correctas.
2. Se lanza una excepción del tipo AuthenticationException si el módulo determina
que la entrada representa un principal no válido.
3. En caso de no saber qué hacer el método devuelve nulo.
La excepción AuthenticationException es una excepción del tipo RuntimeException, que
se suele manejar tanto de manera genérica como personalizada dependiendo del propósito
de la aplicación. En un sistema backend API REST como el propuesto para el presente
proyecto final de máster, lo normal es devolver una respuesta HTTP con código 401
(Unauthorized), que ha sido la opción aplicada como se podrá comprobar en el apartado de
verificaciones.
Para llevar a cabo el proceso de autenticación, la implementación más común de
AuthenticationManager es mediante ProviderManager, permite delegar en él una serie de
instancias de AuthenticationProvider. Este último es similar a AuthenticationManager,
pero con la salvedad de que contiene un método extra que permite consultar si se admite un
tipo de autenticación en concreto o no.
Imagen 6. AuthenticationManager - Spring Security
Imagen 5. Método autenticate (AuthenticationManager) - Spring Security
Sistema para el seguimiento médico de pacientes
47
El argumento del método llamado “supports”, se trata de un objeto de tipo “Class<?>” que
hereda de la clase Authentication. La ventaja de AuthenticationProvider es que puede
funcionar con un amplio número de tipo de autenticaciones distintas delegando
responsabilidades en la cadena de Authentication Providers. De esta manera, si un
ProviderManager no reconoce un tipo de autenticación, ésta puede pasar la responsabilidad
al siguiente ProviderManager de la cadena.
En la mayoría de las ocasiones, una aplicación tiene recursos protegidos (en el caso de la
aplicación servidor desarrollada todo requiere de autenticación). Por ese motivo, se pueden
constituir una serie de grupos con un AuthenticationManager determinado. A menudo,
cada uno de ellos es un ProviderManager y comparten un padre. Al compartir un mismo
elemento como padre, se puede ofrecer un recurso como “global”, que actúa de respaldo
para todos los proveedores. [15]
Imagen 7. Estructura Spring Security
Ángel Pérez Arroyo
48
Personalización de los administradores de autenticación
Con el objetivo de simplificar la implementación del proceso de autenticación, el módulo
Spring Security proporciona una serie de “ayudas” de configuración, para rápidamente
proporcionar las funciones comunes de este proceso en cualquier tipo de aplicación.
Para lograr este propósito, el asistente o ayudante más comúnmente utilizado es
AuthenticationManagerBuilder, que es ideal para configurar detalles de usuario en
memoria, JDBC o LDAP o para agregar un UserDetailsService personalizado. A
continuación, se muestra un ejemplo obtenido de una guía oficial del framework donde se
puede ver cómo se gestiona el proceso de autenticación mediante JDBC:
Imagen 8. Personalización de la autenticación
El problema con la implementación de la imagen superior es
AuthenticationManagerBuilder, porque está utilizando la etiqueta Autowired en un método
una “Bean”. Esto provoca que se construya el AuthenticationManager como global.
Para solucionar el inconveniente que supone la implementación superior, en lugar de
utilizar la etiqueta Autowired utilizamos Override sobre el método de configuración de la
clase WebSecurityConfigurerAdapter, el AuthenticationManagerBuilder se usaría sólo para
construir un AuthenticationManager de manera local, por lo que, sería un hijo del global,
mejorando así la seguridad y abstrayendo al desarrollador de la necesidad de implementar
un AuthenticationManager personalizado global. [15]
Sistema para el seguimiento médico de pacientes
49
Imagen 9. Personalización autenticación (Global)
Autorización
Finalizado el proceso de autenticación de manera satisfactoria (credenciales enviadas por el
usuario son correctas), el siguiente paso consiste en autorizar o denegar al usuario acceder
al recurso solicitado en función de los permisos de los que disponga.
La estrategia de autorización está gestionada por AccessDecisionManager, habiendo tres
implementaciones distintas proporcionadas por el módulo, y estando cada una de ellas
delegadas en la cadena de instancias AccessDecisionVoter. Se trata de un proceso similar
al expuesto anteriormente entre ProviderManager y AuthenticationProviders.
A continuación, se exponen los tres métodos de la interfaz AccessDecisionVoter. Esta
interfaz considera un objeto del tipo Authentication y a un objeto seguro del tipo Object,
que ha sido customizado mediante la interfaz ConfigAttribute:
Imagen 10. AccessDecisionVoter
Ángel Pérez Arroyo
50
La interfaz superior representa cualquier recurso o cosa a la que un usuario quiere tener
acceso. En cambio, los elementos de la interfaz ConfigAttribute son bastante genéricos,
representando una personalización de un objeto de manera segura, conteniendo éste
metadatos que representan el nivel de permisos que debe disponer el usuario para acceder
al recurso solicitado.
La interfaz ConfigAttribute tan sólo define un único método que devuelve un objeto del
tipo String. Mediante dicho objeto se expresa el rol de usuario o roles de usuario que tienen
acceso a dicho recurso. Un ConfigAttribute común contiene el nombre de un rol de usuario
(como ROLE_ADMIN o ROLE_AUDIT), y a menudo, tienen formatos especiales (como el
prefijo ROLE_) o representan expresiones que necesitan ser evaluadas posteriormente.
Por último, destacar que, es muy común utilizar ConfigAttributes que pertenecen al
lenguaje de expresiones de Spring (expresiones SpEL). Por ejemplo, un ejemplo de SpEL
sería el siguiente: “isFullyAuthenticated() && hasRole('user')”. [15]
Sistema para el seguimiento médico de pacientes
51
Web Security
Para aplicaciones web como la diseñada para el presente proyecto, Spring Security dispone
de un funcionamiento específico para este ámbito que se encuentra basado en Servlets. El
funcionamiento de Spring Security en aplicaciones web se puede entender mejor mediante
la siguiente imagen:
Imagen 11. Web Security - Servlets
Cuando el cliente de la aplicación o cualquier otro envía una petición HTTP al servidor, el
contenedor del módulo decide en tiempo de ejecución qué filtros y qué servlets se deben de
aplicar en función de la ruta solicitada y el método HTTP empleado. Como mucho un
servlet puede manejar una única solicitud, pero los filtros pueden formar una cadena como
la que se muestra en la imagen superior, ejecutándose cada uno de ellos de manera
ordenada.
De hecho, un filtro puede hacer las siguientes dos acciones:
● Puede vetar el resto de la cadena si quiere manejar la solicitud por sí mismo.
● Puede modificar la solicitud o la respuesta utilizada en los filtros descendentes y el
servlet.
Ángel Pérez Arroyo
52
Al ejecutarse los filtros de manera ordenada, es muy importante tener en cuenta el orden de
ejecución de los mismos, ya que, Spring Boot lo gestiona mediante dos mecanismos:
1. Etiquetas Bean del tipo Filter que pueden tener una etiqueta del tipo Order o
implementar Ordered.
2. También pueden pasar a formar parte de un FilterRegistrationBean que a su vez
tiene un orden propio al tratarse de una API independiente.
Como curiosidad destacar que, algunos filtros estándares de la cadena definen sus propias
constantes para ayudar a señalar el orden recomendado en el que deben estar. Por ejemplo,
SessionRepositoryFilter de Spring Session, tiene un DEFAULT_ORDER de
Integer.MIN_VALUE + 50, lo que indica que debe ser de los primeros de la cadena, pero
tampoco es necesario que sea el primero.
Cuando Spring Security es añadido a un proyecto basado en Spring, éste se instala con un
único filtro en la cadena siendo del tipo FilterChainProxy. En una aplicación Spring Boot,
los filtros de seguridad son del tipo “Bean”, ya que, todos ellos incluyen la etiqueta
“@Bean” en el contexto de la aplicación, lo que permite que sean instalados por defecto
cada vez que se realiza una petición HTTP a la aplicación.
Cada filtro es instalado en una posición de la cadena que viene definida por dos variables
principales:
● SecurityProperties.DEFAULT_FILTER_ORDER
● FilterRegistrationBean.REQUEST_WRAPPER_FILTER_MAX_ORDER
Imagen 12. Spring Security Filters
Sistema para el seguimiento médico de pacientes
53
Aclarado lo anterior, también es importante mencionar que Spring Security incluye una
capa más de seguridad en el filtro de seguridad. Esta capa normalmente es instalada como
un contenedor del tipo DelegatingFilterProxy, no estando esta interfaz definida como una
“Bean” de Spring. En cambio, el proxy mencionado anteriormente sí delega en
FilterChainProxy, que es siempre una “Bean” de Spring. Esta semilla normalmente tiene
un nombre fijo o común que es “springSecurityFilterChain”. Es entonces la clase
FilterChainProxy la que contiene toda la lógica de seguridad organizada internamente
como una cadena (o cadenas) de filtros. Todos los filtros empleados por Spring Security
hacen uso de la misma API (todos implementan la interfaz Filter de la especificación de
Servlet), y todos tienen la oportunidad de vetar el resto de la cadena.
También se puede configurar Spring Security para que administre todas las cadenas de
filtrado utilizando el mismo FilterChainProxy, ya que, Spring Security contiene un listado
de cadenas de filtrado y envía la solicitud a la primera cadena que coincide con los
parámetros requeridos.
Imagen 13. FilterChainProxy
Por último, destacar que, Spring Security contempla que muchas aplicaciones basadas en
Spring Boot necesitan que ciertos recursos estáticos como las hojas de estilos (/css/**),
imágenes (/images/**), ficheros JavaScript (/js/**) o vistas de errores (/error) no necesitan
de control de seguridad, ya que, en la mayoría de las ocasiones son recursos que se quieren
ofrecer abiertamente a todo el público. Para ello, el módulo provee de una directiva
llamada “security.ignored” descrita en la configuración de la clase llamada
SecurityProperties. Mediante dicha directiva, se puede conseguir que ciertos recursos
ofrecidos por la aplicación no pasen por cadenas de filtrado.
Ángel Pérez Arroyo
54
Creando y personalizando cadenas de filtrado
Con el objetivo de ofrecer un mayor poder de personalización, el módulo de Spring
Security ofrece la posibilidad de crear y personalizar las cadenas de filtrado como se desee.
Para ello, tan sólo se tiene que indicar la posición en la que se debe incluir el nuevo filtro
utilizando la orden “SecurityProperties.BASIC_AUTH_ORDER”, o bien, también se puede
utilizar la función de retroceso y definir reglas con un orden anterior al común. Un ejemplo
de esto último sería el que se muestra en la siguiente imagen:
Imagen 14. Personalización de cadenas de filtrado
Gracias a la gran modularidad que ofrece este módulo de Spring, se pueden configurar de
manera distinta, reglas de acceso para adaptarse a todo tipo de aplicaciones. Por ejemplo,
habrá aplicaciones que llevarán el control de usuarios mediante Cookies, Token, Claves
asimétricas, etc, y sus procesos serán distintos dadas las necesidades del proyecto. Por lo
tanto, es necesario ofrecer un sistema que sea válido en la amplia mayoría de situaciones, y
esto se consigue gracias a la gran modularidad de Spring Security. [15]
Sistema para el seguimiento médico de pacientes
55
Coincidencia en la solicitud para el envío de datos y Autorización
Una cadena de filtros de seguridad o de manera equivalente, un
WebSecurityConfigurerAdapter, ofrece un comprobador de solicitudes que permite
determinar si se debe procesar una solicitud HTTP o no. Para el caso de que se deba
procesar la petición, se procede a aplicar la cadena de filtros convenientes. Sin embargo, al
personalizar una cadena de filtrado, se puede obtener un mayor control sobre el proceso de
autorización al poder realizar comparaciones y verificaciones adicionales, que ofrecen una
mayor fiabilidad.
Imagen 15. Roles de usuario - Autorización
Uno de los errores más comunes al inicio de empezar a utilizar esta característica del
módulo es olvidar que las reglas se aplican de arriba a abajo y que se divide en dos
secciones. La primera parte es el comparador de solicitudes (“antMatchers”) y la segunda
es la regla que controla el acceso al recurso (“hasRole”). [15]
Ángel Pérez Arroyo
56
Método de Seguridad
Además de ofrecer seguridad para aplicaciones web como los servicios API REST, Spring
Security también ofrece la posibilidad de aplicar esas mismas reglas directamente a
métodos Java. De esta manera, indistintamente de si se trata de una aplicación web o no, el
módulo proporciona soporte a todo tipo de aplicaciones desarrolladas con Spring.
Habilitar esta funcionalidad es muy sencillo, simplemente añadiendo la etiqueta
“@EnableGlobalMethodSecurity(securedEnabled = true)” en la clase principal de la
aplicación, tal y como se puede ver en la imagen inferior, dicha funcionalidad debería estar
disponible.
Imagen 16. Activación SpringSecurity
En cambio, para su uso, simplemente se añadirán etiquetas como “Secure” sobre la
implementación del método desarrollado en Java, tal y como se puede ver en la imagen
inferior:
Imagen 17. Método de seguridad personalizado
En el ejemplo anterior, el framework crea una nueva “Bean”, siendo esta de tipo proxy. Por
lo tanto, antes de cada ejecución del método se comprueba que el usuario solicitante tiene
los permisos necesarios para realizar dicha acción. En caso de ser esto último afirmativo, el
método se ejecuta normalmente. Para el caso opuesto, el sistema lanzará una excepción del
tipo AccessDeniedException, sin llegar a ejecutar el método.
Sistema para el seguimiento médico de pacientes
57
Además de la etiqueta “Secure”, existen muchas más, pero las más frecuentes son
“PreAuthorize” y “PostAuthorize”, que permiten hacer referencias a métodos definidos por
el desarrollador que se deben ejecutar antes y/o después de cada proceso de autorización.
[15]
Trabajo con hilos de ejecución
Debido a que Spring Security ofrece un mismo principio autenticado a multitud de
consumidores, este ofrece un hilo de ejecución a cada uno de ellos. De esta manera, se
puede ofrecer a cada consumidor el mismo principio sin que exista problema entre ellos al
momento de consumir la misma información. Todo ello se gestiona mediante el bloque de
construcción básico SecurityContext, que contiene un objeto del tipo Authentication.
Una de las principales ventajas de este sistema de trabajo, es que permite acceder y
manipular instancias de SecurityContext a través de métodos estáticos de la clase
SecurityContextHolder, y este a su vez modifica los datos del hilo local. [15]
A continuación, se muestra un ejemplo en el que se verifica si un usuario está autenticado
correctamente:
Imagen 18. Spring Security corriendo en distintos hilos
Ángel Pérez Arroyo
58
Procesamiento de métodos seguros de forma asincrónica
Para finalizar con la presente sección de la memoria referente a Spring Security, se debe
tener en cuenta la problemática subyacente de los métodos asíncronos para poder
ejecutarlos de manera segura. Dado que SecurityContext se encuentra vinculado a distintos
subprocesos (hilos de ejecución), si se desea ejecutar más métodos, siendo estos
asíncronos, es fundamental asegurarse de que el contexto (SecurityContext) se propague
por cada uno de ellos de manera correcta.
Para ayudar a los desarrolladores en esta tarea, el módulo proporciona clases específicas
como Runnable y Callable para simplificar el proceso de manera significativa. Para
propagar SecurityContext a los métodos @Async, debe proporcionar un AsyncConfigurer
y asegurarse de que el Ejecutor sea del tipo correcto. [15]
Un ejemplo práctico de todo lo anteriormente descrito es lo que se muestra en la siguiente
imagen:
Imagen 19. Procesamiento de forma asíncrona - Spring Security
Sistema para el seguimiento médico de pacientes
59
2.4.5. Spring HATEOAS
Otro módulo muy utilizado durante todo el
desarrollo de la aplicación servidora del
proyecto ha sido Spring HATEOAS. El término
HATEOAS hace referencia a Hypermedia as
the Engine of Application State, que en español
significa hipermedia como motor del estado de
la aplicación.
HATEOAS es un componente específico empleado en diseños de arquitecturas API REST
como el desarrollado para el presente proyecto de final de máster. Aplicando esta técnica
una aplicación cliente web, puede consumir recursos ofrecidos por una API y obtener
información de manera dinámica.
Además, gracias al principio HATEOAS, una aplicación bien desarrollada bajo este
principio debería necesitar de poco o de ninguna información previa para entender cómo se
debe interactuar con el sistema.
En cambio, clientes y servidores web basados en estándares más antiguos y estáticos como
CORBA, se comunican mediante una interfaz fija o similares.
A continuación, procederemos a poner un ejemplo visual con el objetivo de que se entienda
mejor el principio HATEOAS. Cuando un cliente web que consume recursos de una API
REST, realiza una petición HTTP/S a una URL. Una vez llega la petición al servidor del
servicio, éste procesa la petición realizada por el cliente y le ofrece junto con la respuesta
de la solicitud, información adicional sobre posibles acciones futuras o interesantes en
función de la solicitud realizada.
Por ejemplo, si utilizamos como cliente REST a Postman e intentamos realizar una petición
correctamente autenticada y con los parámetros requeridos y correctos al recurso
“/patient/one” obtenemos el siguiente objeto JSON:
Ángel Pérez Arroyo
60
Imagen 20. Principio HATEOS aplicado en el servicio REST
Como se puede comprobar en la imagen superior, a parte de proporcionar la información
solicitada del paciente indicado, el sistema incluye al final de la respuesta un objeto JSON
llamado “_links” donde se hace referencia a la URL empleada para obtener dichos datos,
así como un enlace adicional que en este caso sirve para actualizar la información del
paciente. [16] [17]
Sistema para el seguimiento médico de pacientes
61
2.4.6. Certificados SSL
Los certificados digitales y en particular los SSL son el corazón de la
seguridad de cualquier conexión segura en Internet. Los certificados
SSL (Secure Sockets Layer) se utilizan para establecer conexiones
cifradas entre un cliente y un servidor.
Para el caso del presente proyecto, el cliente empleado para establecer las distintas
peticiones API REST ha sido Postman, y el servidor ha sido la aplicación desarrollada
utilizando el framework Spring.
Gracias al uso de conexiones HTTPS (SSL sobre HTTP), los datos enviados entre un
cliente y servidor viajan por una red como Internet de manera totalmente confidencial,
impidiendo o dificultando considerablemente el acceso a los datos originales, para el caso
de que algún ciberdelincuente interpretara y analizara la comunicación entre ambos
extremos.
Imagen 21. HTTP vs HTTPS
Ángel Pérez Arroyo
62
Dada la naturaleza de los datos tratados, siendo éstos de carácter muy sensible, se ha visto
como una necesidad básica la inclusión de este tipo de certificados, con el objetivo de
anonimizar las conexiones llevadas a cabo desde cada uno de los clientes del sistema.
Todo este proceso se realiza de manera totalmente transparente para un usuario, por lo que,
no es necesario tener ningún conocimiento en el campo de la ciberseguridad para poder
establecer un canal seguro.
En cuanto al proceso de creación de un canal seguro de comunicación entre los extremos es
el siguiente:
1. En primer lugar, el servidor envía una copia de su clave pública al cliente, que para
el caso vamos a suponer que es un navegador web, aunque hay multitud de clientes
posibles.
2. A continuación, el cliente utilizado procede a crear y a enviar al servidor una clave
de cifrado para utilizar junto con un algoritmo de cifrado simétrico. Por ejemplo,
AES 256.
3. Cuando el servidor recibe el mensaje, lo descifra con su clave privada y obtiene la
clave de cifrado del algoritmo simétrico. Ahora ambos extremos comparten una
clave de sesión.
4. Llegados a este punto, tanto el cliente como el servidor de un servicio web o
similar, disponen de un canal seguro por el que compartir información, ya que, tan
sólo ellos conocen la clave de cifrado empleada para encriptar las comunicaciones.
Este proceso se repite en cada ocasión que se establece una nueva sesión contra el
servidor web.
Por lo tanto, el tiempo que se utiliza la misma clave de cifrado se considera
reducido, ya que, este tipo de conexiones no suelen perdurar en el tiempo. Para el
caso del sistema desarrollado, este tiempo nunca es superior a los 20 minutos.
Imagen 22. Comunicación cifrada
Sistema para el seguimiento médico de pacientes
63
Para el caso particular del proyecto desarrollado, no ha sido posible utilizar un certificado
SSL válido generado mediante autoridades certificadoras como Let´s Encrypt, ya que, por
motivos de seguridad impuestos por el proveedor de acceso a Internet contratado, tanto el
puerto 80 (HTTP) como el 443 (HTTPS) se encontraban bloqueados por Firewall. Para
solucionar esta problemática se ha hecho uso de un certificado SSL autofirmado, que si
bien es igual de fiable a la hora de establecer canales de comunicación seguros, es un factor
a tener en cuenta antes de poner el sistema en producción. En caso de no modificar el
certificado SSL, la amplia mayoría de clientes web reconocerían el servicio como no
seguro o peligroso. [18] [19]
Ángel Pérez Arroyo
64
2.4.7. Claves RSA
Dentro del campo de la criptografía, RSA (Rivest,
Shamir y Adleman) es un sistema criptográfico de clave
pública/privada o asimétrico, que fue desarrollado en el
año 1979 dentro del Instituto Tecnológico de
Massachusetts, también conocido como MIT.
RSA es el primer algoritmo de este tipo que se publicó, además de ser el más popularmente
utilizado para multitud de propósitos, ya que, es válido tanto para firmar digitalmente como
para permitir el envío seguro de todo tipo de información.
El punto fuerte de RSA radica en la problemática de la factorización de números enteros
muy grandes, ya que, es un proceso matemático con un coste computacional sumamente
elevado, y más, con claves de 4096 bits como las utilizadas en el presente proyecto. El
funcionamiento del algoritmo se basa en el producto de dos números primos de varias
cifras, que son elegidos al azar y mantenidos en secreto.
En la actualidad estos números primos son del orden de 10300 y aumentando, ya que, a
medida que la capacidad computacional de los ordenadores va creciendo, va surgiendo la
necesidad de ampliar el tamaño de los números utilizados. Si no se utilizaran números cada
vez más grandes, aplicando técnicas como la fuerza bruta podrían empezar a convertirse en
factibles, convirtiendo esta circunstancia en una gran problemática.
Con el objetivo de dejar constancia de los datos generados o modificados por cualquier
usuario del sistema, se han generado un par de claves pública/privada RSA de 4096 bits
con las que se firma digitalmente cualquier tipo de acción que implique la inserción o
modificación de cualquier dato registrado en el sistema. De esta manera, se deja constancia
de manera fiable qué se ha realizado y quien. Este proceso es muy útil entre otros para
auditar la correcta utilización del sistema, así como para detectar anomalías o malas praxis
llevadas a cabo por el personal sanitario. [20]
Sistema para el seguimiento médico de pacientes
65
Idea del algoritmo
El algoritmo se basa en la idea de que dos personas quieren establecer una
comunicación segura utilizando un medio inseguro como es Internet. Supongamos que
la primera persona se llama Bob, y quiere enviar un mensaje cifrado a Alice, sin que
nadie sea capaz de obtener el mensaje original.
Para ello, Alice procede a enviar a Bob una caja con un candado abierto (Clave
pública). Cuando Bob lo recibe coloca el mensaje en el interior de la caja y procede a
cerrar el candado que Alice le ha enviado. A continuación, envía la caja cerrada a
Alice. Cuando Alice recibe la caja, procede a abrir el candado con la clave que ella tan
sólo posee (Clave privada). Finalmente, Alice puede acceder al contenido del mensaje
que Bob le ha enviado. [20]
Descripción funcionamiento del algoritmo RSA
Para poder utilizar el algoritmo, en primer lugar, se necesita generar un par de
claves pública/privada con las que poder encriptar y desencriptar la información.
1. Se eligen dos números primos distintos p y q.
2. A continuación, se calcula el módulo (n), que se obtiene del producto entre
p y q (n = p * q).
3. Después, se procede a calcular φ utilizando la función de Euler (φ(n) = (p
- 1) * (q - 1)) aprovechando las dos propiedades que ofrece esta función:
a. p es primo si φ(p) = p - 1
b. m y n son primos entre sí, sólo si φ(mn) = φ(m) * φ(n)
4. El siguiente paso consiste en escoger un entero positivo e menor que φ(n),
que sea coprimo6 con φ(n).
5. El quinto paso consiste en determinar un valor d que sea el inverso de e
mod φ(n), o lo que es lo mismo, d * e mod φ(n). [21]
6 Consultar en el glosario
Ángel Pérez Arroyo
66
Clave pública
De acuerdo con lo expuesto en el punto anterior, una clave pública RSA, se encuentra
compuesta por los valores de n y e, siendo estos valores el módulo y el exponente de
cifrado
Clave privada
En cambio, la clave privada de un algoritmo RSA viene generada por el valor de n y d,
siendo estos valores el módulo y el exponente de descifrado. La seguridad del
algoritmo RSA se fundamenta en que esta clave se mantenga siempre en secreto. En
caso de hacerse pública la clave privada, cualquier mensaje podría ser descifrado. [21]
Proceso de cifrado
Supongamos que Alice quiere enviar un mensaje cifrado a Bob. Para ello, lo primero
que debe hacer Alice es preguntar a Bob por su clave pública. Al ser accesible y
conocida por cualquiera, tal y como su nombre indica, Bob le enviará su clave a Alice.
Una vez Alice haya recibido la clave pública de Bob, procederá a cobrar el mensaje
deseado aplicando la siguiente fórmula:
c = me (mod n)
Ahora que Alice ya dispone del mensaje cifrado mediante la clave pública de Bob,
procede a enviarle a Bob el mensaje mediante un canal inseguro como es Internet.
Sistema para el seguimiento médico de pacientes
67
Proceso de descifrado
Llegados a este punto, supongamos que Bob ha recibido el mensaje cifrado enviado
por Alice utilizando la propia clave pública de Bob. Cuando Bob recibe el mensaje,
procede a descifrarlo utilizando su clave privada, que como su propio nombre indica,
no debe ser conocida por nadie más que Bob. [21]
Para descifrar el mensaje Bob aplica la siguiente fórmula:
m = cd (mod n)
Hay que destacar que, todo el proceso anterior funciona correctamente debido a que
como se puede ver en la siguiente ecuación, la función de descifrado es la inversa de la
de cifrado:
cd = (me)d = med (mod n)
Firma digital
Otra gran aplicación que ofrece el algoritmo asimétrico RSA es la autenticación de
mensajes, que junto con la ayuda de funciones resumen (hash), permiten realizar
firmas digitales a partir de un mensaje m. La aplicación de esta técnica se justifica
desde el momento en el que distintas transacciones se realizan a través de Internet.
Para el caso concreto del proyecto desarrollado, la firma digital se aplica para verificar
que las acciones solicitadas por un sanitario ya sean de crear una nueva entrada en el
historial, modificar algún dato de un paciente, etc, las realiza efectivamente el personal
sanitario que dice ser y no otra persona.
Para ello, suponiendo que, por ejemplo, la doctora Alice deseara firmar digitalmente la
introducción de un nuevo registro en el historial médico de un paciente se realizan los
siguientes pasos:
1. Genera un resumen de los datos que se deben registrar en el sistema, utilizando
una función hash.
2. A continuación, el cliente del sistema genera la firma digital del mensaje,
cifrado con la clave privada de Alice el hash calculado en el paso anterior.
Ángel Pérez Arroyo
68
3. El cliente del sistema envía todos los datos, tanto la firma digital como los
datos del paciente que deben ser registrados.
4. Cuando el servidor recibe los datos, verifica la autenticidad de estos
utilizando la clave pública de Alice que es almacenada en el servidor.
a. Si el proceso resulta satisfactorio se procesan los datos.
b. En caso de resultar incorrecto el proceso, se detiene el proceso y se
devuelve un error. [21]
Sistema para el seguimiento médico de pacientes
69
2.4.8. JWT
JSON Web Token (JWT) es un estándar abierto (RFC 7519) que
define de una manera compacta y autocontenida, un tipo de objeto
JSON para la transmisión de información de una forma segura
entre ambos extremos de una comunicación.
Debido a que el contenido del JWT puede ser leído en todo momento durante su
transmisión, se recomienda el uso de algoritmos de cifrado como AES, que imposibiliten a
un atacante conocer la información transmitida.
En cambio, para detectar cualquier modificación del objeto JSON, la información puede
ser firmada digitalmente utilizando un secreto o bien, mediante un par de claves pública-
privada.
Un JWT está compuesto por tres partes:
● Cabecera
○ Se indica el tipo de token, que en este caso es de
tipo JWT.
○ Se indica el algoritmo empleado para la firma
(HMAC SHA256 o RSA).
● Cuerpo o contenido
○ Contiene información del usuario, así como
información adicional.
○ Suelen haber tres tipos de declaraciones:
registradas7, públicas8 y privadas9.
● Firma
○ Sirve para verificar que el mensaje no ha sido modificado durante su viaje.
Se puede hacer utilizando funciones hash o mediante una firma con clave
privada lo que garantiza el origen del mensaje.
○ Se compone de la suma del encabezado codificado más la parte del cuerpo
codificado separados por un signo de puntuación.
7 Consultar en el glosario
8 Consultar en el glosario
9 Consultar en el glosario
Imagen 23. JWT - Cabecera
Imagen 24. JWT- Contenido
Ángel Pérez Arroyo
70
Imagen 25. JWT - Firma
Como se puede apreciar en la imagen superior, todos los componentes de un JWT van
codificados en Base64Url, por lo que, es un factor a tener en cuenta a la hora de acceder a
los datos que contiene el JWT.
Como resultado se obtienen tres cadenas con codificación Base64Url separadas entre ellas
por signos de puntuación. Esto facilita enormemente la transmisión de información a través
de protocolos como HTTP, al ser mucho más compacto que otros estándares basados en
XML.
Imagen 26. JWT - Codificado/Decodificado
Por lo tanto, las mejores situaciones para utilizar JSON Web token serían para los procesos
de autenticación y para el intercambio de información.
● Autenticación: cuando un usuario es autenticado contra el servidor, cada nueva
petición que realice incluirá en la cabecera de la petición el correspondiente JWT,
permitiendo así al usuario, acceder a los distintos servicios y recursos ofrecidos.
Además, otra gran ventaja que ofrece JWT es su utilización para desarrollar
sistemas “Single Sign On”, debido a su pequeña carga en el sistema y a la gran
capacidad para poder utilizarse fácilmente en distintos dominios.
Sistema para el seguimiento médico de pacientes
71
● Intercambio de información: JWT también puede ser empleado para el
intercambio de información, ya que, garantiza la integridad del contenido al hacer
uso de firmas mediante funciones resumen y/o empleando sistemas de clave
pública y privada para garantizar el origen del mensaje recibido. [22]
Este sistema presenta como principal ventaja el poder garantizar el origen de las
comunicaciones, así como la notificación en caso de alteración del mensaje durante su
envío.
Esto repercute de manera directa en la seguridad del sistema, ya que, éste se convierte en
uno más robusto y fiable frente a distintos ataques
Además, su funcionamiento es muy simple y se podría resumir en el siguiente diagrama de
flujo:
Imagen 27. Autenticación mediante JWT
A continuación, se muestra un pequeño ejemplo de un JWT real utilizado en el sistema.
Dicho token ha sido generado por el servidor de autenticación y autorización utilizado
(Keycloak).
Como se puede comprobar en la imagen inferior, algunos de los parámetros más
importantes como la fecha de expiración o el usuario asociado a dicho token se encuentran
correctamente definidos de acuerdo con el estándar.
Asimismo, también se incluyen algunos campos como los roles asociados a dicho usuario o
el tipo de token empleado, siendo en este caso siempre del tipo “Bearer”.
Ángel Pérez Arroyo
72
A continuación, se muestra un pequeño ejemplo de un JWT real utilizado en el sistema.
Dicho token ha sido generado por el servidor de autenticación y autorización utilizado
(Keycloak).
Como se puede comprobar en la imagen inferior, algunos de los parámetros más
importantes como la fecha de expiración o el usuario asociado a dicho token se encuentran
correctamente definidos de acuerdo con el estándar.
Asimismo, también se incluyen algunos campos como los roles asociados a dicho usuario o
el tipo de token empleado, siendo en este caso siempre del tipo “Bearer”. [22]
Imagen 28. JWT del sistema - Codificado/Decodificado
Sistema para el seguimiento médico de pacientes
73
2.4.9. OpenID
OpenID se trata de un estándar para la
identificación de usuarios en Internet de manera
descentralizada.
Al disponer de esta arquitectura, cualquier usuario que haga uso de un sistema con OpenID
puede identificarse en un sitio web a través de una URL10 o XRI11 determinada, y tras un
proceso de autenticación satisfactorio aparecerá como verificado en cualquier servidor que
haga uso del protocolo OpenID.
Un ejemplo de los servicios que hacen uso de este protocolo se puede corresponder con el
momento en el que los usuarios no se ven en la necesidad de tener que registrarse en cada
uno de ellos de manera independiente, ya que, utilizando el identificador generado por un
servidor de OpenID o también llamado proveedor de identidad (IdP), podrán acceder al
servicio de manera normal.
La parte negativa que presenta el estándar es que la seguridad de una conexión OpenID
depende principalmente de la confianza que un cliente tenga sobre un proveedor de
identidad en específico. Esto provoca que, este sistema no se haya popularizado
enormemente en Internet pese a su gran potencia, ya que, servicios con información crítica
como son los accesos a cuentas bancarias o comercio electrónico, no pueden permitir que
proveedores de identidad autentiquen de manera fraudulenta a usuarios.
Por ello, para el presente proyecto de final de máster, se ha hecho uso de un servidor de
autenticación y autorización llamado Keycloak, con el que se ha podido utilizar de manera
fiable y controlada el protocolo OpenID. Esto ha sido posible ya que, los clientes de la API
REST desarrollada utilizando el framework Spring, pueden verificar las credenciales de los
usuarios contra un proveedor de identidad seguro. Asimismo, el servicio REST
desarrollado también puede contrastar contra el servidor de Keycloak, que el JWT enviado
por el cliente para acceder a recursos protegidos es válido. [23]
10 Consultar en el glosario
11 Consultar en el glosario
Ángel Pérez Arroyo
74
Vocabulario referente a OpenID
1. Cliente -> Aplicación que quiere acceder a los recursos de un propietario o
propietarios.
2. Servidor de autorización -> Equipo encargado de autorizar las acciones pueden
producirse.
3. URL de redirección -> URL a la que se redirigirá al usuario cuando termine el proceso
de autenticación. La dirección dependerá de si el resultado es satisfactorio o no.
4. Token de autenticación -> Clave que permite a los clientes acceder a los recursos a los
que quiere acceder.
5. Parte confidente -> Servicio que quiere verificar la identidad de un usuario. [24]
Funcionamiento del protocolo
Ahora vamos a ver un pequeño ejemplo que permita entender de una manera más clara el
funcionamiento del protocolo. Por ejemplo, vamos a suponer que un usuario quiere acceder
al servicio UACloud, y que éste soportara el protocolo OpenID.
Cuando un miembro de la Universidad de Alicante quisiera acceder al servicio, en lugar de
introducir su correspondiente usuario y contraseña, en el mismo formulario habría un botón
o similar que permitiera acceder utilizando OpenID Connect, de la misma manera que hay
uno para acceder por Certificado digital.
Sistema para el seguimiento médico de pacientes
75
Una vez seleccionado el método de autenticación, si por ejemplo se quiere acceder
utilizando el proveedor de identidad “ciberseguridad-openid.org”, el usuario simplemente
introduciría lo siguiente: usuario.ciberseguridad-openid.org. Llegados a este punto el
servicio de UACloud utilizando el correspondiente cliente de OpenID junto con la URL
adecuada, solicitaría al servidor indicado por el usuario los datos requeridos para que el
usuario pueda ser autenticado. Si el proceso puede ser completado correctamente, el
usuario accedería al servicio de UACloud normalmente. [23]
Ángel Pérez Arroyo
76
Lo anteriormente indicado puede verse desglosado mediante el siguiente diagrama de flujo:
Imagen 29. Diagrama de flujo - OpenID Connect
Modos de funcionamiento del protocolo
El protocolo OpenID Connect ofrece dos mecanismos distintos para su utilización, con el
objetivo de que la parte confidente pueda comunicarse correctamente con el proveedor de
identidad seleccionado por el usuario.
1. checkid_immediate -> se trata de un sistema enfocado a la identificación
automática. De esta manera el usuario no es consciente de todo el proceso que se
está llevando internamente, ya que, toda la comunicación necesaria entre los
servidores (proveedor de identidad y servidor del servicio) se realiza como una
tarea más.
2. checkid_setup -> se trata de la opción más común que se utiliza en aplicaciones
Web. En esta opción a diferencia de la anterior, el usuario es redirigido para que se
autentique en el servicio IdP. Finalizado el proceso de autenticación, éste es
redirigido al servicio al que quería acceder.
Sistema para el seguimiento médico de pacientes
77
OpenID 2.0
La versión 2 del protocolo funciona de una manera similar a OpenID Connect, pero con la
principal salvedad de que el uso de la API es mucho más sencillo, intuitivo y utilizable
para multitud de aplicaciones de manera nativa.
Además, gracias al uso de la segunda versión del protocolo se pueden acceder a mejores y
más robustos sistemas de verificación y encriptado, que la primera versión de la API no
incluye.
Finalmente, destacar que, OpenID Connect incluye e integra capacidades de OAuth 2.0 de
manera totalmente integrada y nativa, ofreciendo mayores funcionalidades y posibilidades
con la que desarrollar multitud de sistemas bajo este estándar. [23]
Imagen 30. Arquitectura OpenID
Ángel Pérez Arroyo
78
Control sobre OpenID
Una de las principales garantías para el uso de OpenID es que es OpenSource. Esta
tecnología fue desarrollada durante el 2005 por la comunidad de desarrolladores, con el
objetivo de dar una solución fiable e integrable en multitud de sistemas, que permitiera
solucionar la problemática del proceso de autenticación.
Al tratarse de una tecnología totalmente gratuita, accesible y totalmente descentralizada,
cualquier persona se puede convertir en “OpenID Provider”, sin la necesidad de registrarse
y añadir funcionalidades al protocolo, mejorando aún más las características de este. [23]
Sistema para el seguimiento médico de pacientes
79
2.4.10. OAuth 2.0
El protocolo OAuth 2.0 es el estándar de la industria en lo
referente al proceso de autorización. Este estándar busca en todo
momento simplificar la tarea de desarrollo de cualquier tipo de
sistema, ya que, en la actualidad muchas aplicaciones necesitan
realizar las mismas o similares tareas de gestión y autorización de
acceso a datos.
Una de las principales ventajas de este protocolo es que incluye soporte para todo tipo de
aplicaciones: móviles, web, escritorio, etc, por lo que, su aplicación es prácticamente
infinita. Esto es debido a que su gran modularidad que le permite adaptarse a multitud de
entornos que, junto con su gran funcionamiento, le ha hecho convertirse en un referente
claro para ser utilizado en prácticamente cualquier aplicación.
Asimismo, todas sus especificaciones y extensiones se encuentran en continuo desarrollo
dentro del IETF OAuth Working Group.
El protocolo OAuth 2.0 es cierto que se puede utilizar en muchos ámbitos totalmente
distintos, pero uno de los más populares es la gestión de los procesos de autorización para
servicios API como el desarrollado para el presente proyecto. [25]
2.4.10.1. Vocabulario referente a OAuth 2.0
1. Propietario del recurso -> El dueño de los recursos que son accesibles utilizando el
sistema, y que da su autorización para que dichos recursos puedan ser consumidos
por otros usuarios.
2. Servidor del recurso -> Equipo encargado de almacenar y proporcionar a los
usuarios los recursos requeridos.
3. Aplicación cliente -> Software que simplifica a un usuario el acceso a los datos, así
como el encargado de acceder a los datos de la cuenta del usuario, para lo que
suele solicitar permiso.
4. Permisos del usuario -> Permisos que un usuario dispone En función de sus
permisos podrá tener disponibles o no determinados recursos.
Ángel Pérez Arroyo
80
5. Servidor de autenticación -> Se trata del equipo encargado de gestionar las
distintas peticiones que le llegan, para autorizar o denegar el acceso al recurso
solicitado por el usuario.
2.4.10.2. Flujo de OAuth2
El flujo llevado a cabo por un sistema que hace uso del protocolo OAuth2 sería el que se
muestra en la siguiente imagen:
Imagen 31. Flujo de OAuth2
Para el caso del sistema de gestión médica desarrollado, los recursos son globales al
desearse que la información médica de un paciente pueda ser consultada por varios
sanitarios. Por lo tanto, el proceso de autorización se gestiona en función del “ROLE” del
usuario, es decir, si un usuario determinado dispone de unos permisos mínimos, se le
permite el acceso al recurso API y en caso contrario se le deniega el acceso.
Por lo tanto, para el caso concreto del sistema diseñado, el usuario en primer lugar debe
autenticarse contra el servidor Keycloak, ya que, cualquier petición en el sistema debe ir
correctamente autenticada (proceso necesario para obtener el JWT). A continuación, el
servidor de autorización (Keycloak) determina si el usuario dispone de los permisos
necesarios para que dicho usuario pueda acceder al recurso o no. En caso afirmativo, el
servidor de recursos procede a procesar su petición. [26]
Sistema para el seguimiento médico de pacientes
81
Tipos de concesión (Grant types)
Dentro del estándar de autorización OAuth 2.0 se proponen distintos mecanismos para
llevar a cabo el proceso de concesión de acceso a datos. En definitiva, los tipos de
concesiones disponibles no son más que maneras mediante las que se puede obtener un
token de acceso válido para una aplicación.
Cada uno de los tipos presenta sus ventajas e inconvenientes por lo que es recomendable
estudiar detenidamente cada uno de ellos, y escoger el que mejor se adapte al sistema en
cuestión.
A continuación, vamos a mencionar algunos de los tipos propuestos dentro del estándar:
● Credenciales de cliente
● Implícito
● Código de autorización
● Código de autorización con PKCE
● Credenciales de contraseña
Credenciales de contraseña
El tipo de concesión por contraseña o como también se le conoce “Resource Owner
Password Credentials”, se trata de un flujo de autorización que normalmente es sólo
recomendable para entornos seguros como el propuesto, ya que, para que su aplicación se
considere fiable debe existir una relación de confianza entre todos los componentes del
sistema.
Además, la concesión por contraseña se trata de una de las más simples que el protocolo
define, y para la que tan sólo es necesario llevar a cabo un paso. Normalmente, para
facilitar al usuario la utilización de un sistema con concesión por contraseña, se incluye un
formulario donde se recoge el usuario y contraseña de manera tradicional y se validan en
el servidor. Tras una correcta validación, se devuelve un token de acceso, que en esta
ocasión como se ha visto anteriormente es del tipo JWT.
Un ejemplo de petición HTTP que se debe realizar para aplicar correctamente este tipo de
concesión en particular es el que se muestra en la imagen inferior.
Ángel Pérez Arroyo
82
Imagen 32. Ejemplo de petición OAuth2
Como se puede ver en la imagen superior, es necesario incluir los siguientes parámetros o
información:
1. URL sobre la que se deben validar las credenciales del usuario.
2. Dirección del servidor que debe validar las credenciales.
3. Tipo de contenido de la petición.
4. Tipo de concesión de contraseñas => password para este caso particular.
5. Nombre de usuario.
6. Contraseña del usuario.
7. Identificador de cliente.
A continuación, se muestra una configuración real utilizada en el software Postman con el
objetivo de que el servidor de autenticación y autorización devuelva un JWT válido para
ser utilizado en el servicio REST del sistema desarrollado. [27]
Sistema para el seguimiento médico de pacientes
83
Imagen 33. Ejemplo petición OAuth2 con Postman
Con la configuración anterior, iniciado el proceso de autenticación, Keycloak, devuelve a
Postman un token JWT que es válido para ser utilizado en el sistema. Este token tiene un
formato como el mostrado anteriormente en el apartado referente a JWT.
Ángel Pérez Arroyo
84
2.4.11. Docker
Dados los recursos disponibles para montar un servidor físico, se ha
hecho uso de una Raspberry Pi 4 sobre la que se ha levantado la
totalidad del sistema desarrollado para el presente proyecto de final
de máster.
Como los recursos del equipo utilizado son bastante limitados, existe la necesidad de
optimizar los procesos ejecutados sobre el mismo lo máximo posible, con el fin de poder
disponer de la mejor experiencia a los usuarios del sistema, al mismo tiempo que, se
garantiza que la estabilidad del sistema con un grupo reducido de usuarios utilizando el
sistema al mismo tiempo.
Además, con el objetivo de aislar los distintos elementos que componen el sistema lo
máximo posible, minimizando el rango de ataque de un ciberdelincuente en caso de
detectarse alguna vulnerabilidad en el sistema, se ha hecho uso de la tecnología Docker.
Una de las principales ventajas de Docker es que, permite conseguir una mayor eficiencia y
rendimiento que ejecutando máquinas virtuales tradicionales, mediante softwares como
VirtualBox o VMWare.
Docker es un software enfocado a las tecnologías de la información, que permite crear todo
tipo de contenedores basados en Linux. Por ese motivo es muy fácil encontrar
contenedores de Docker utilizando Ubuntu, Debian, Centos, Alpine, etc. Así mismo,
Docker dispone de una gran comunidad OpenSource a sus espaldas que está mejorando de
manera continua todo el ecosistema de Docker, con el objetivo de poder ofrecer a los
usuarios de manera totalmente gratuita un mejor producto.
Este software se encuentra gestionado por la empresa Docker Inc., que colabora
activamente con la comunidad, con el objetivo de poder ofrecer un producto mejor y más
seguro, al mismo tiempo que también comparte los avances logrados con el resto de la
comunidad.
Sistema para el seguimiento médico de pacientes
85
Funcionamiento de Docker
El motivo principal por el que Docker tan sólo permite ejecutar contenedores basados en
Linux, es porque utiliza funciones propias de este sistema operativo. Algunas de ellas son
“Cgroups” y “namespaces”, que permiten separar los procesos pudiendo ejecutarse de
manera totalmente aislada del resto.
Por ello, el propósito que se busca conseguir mediante Docker es conseguir justo, esta
independencia entre distintos procesos, pudiendo ejecutar programas, aplicaciones, etc, por
separado, con el objetivo de hacer un mejor uso de la infraestructura disponible, así como,
disponer de una mejor seguridad al disponer de sistemas separados y aislados.
Diferencia con contenedores Linux tradicionales
Los contenedores tradicionales de Linux se encuentran basados en la tecnología LXC, que
hace unos años era útil como medio de virtualización “ligera”, pero que presentaba
diversos inconvenientes, que dificultan su utilización tanto a usuarios como
desarrolladores.
Mediante el uso de Docker no sólo se proporciona a los usuarios y desarrolladores la
capacidad de ejecutar contenedores, sino que también se simplifica de forma considerable
el proceso de creación y diseño, así como el envío y compartición de las imágenes de los
contenedores. Por último, hay que destacar que, Docker también permite hacer uso de un
gestor de versiones con el que se puede manejar de una mejor manera las distintas mejores
de una imagen.
Imagen 34. Contenedores tradicionales vs Docker
Ángel Pérez Arroyo
86
Finalmente, destacar que, los contenedores Linux tradicionales usan un sistema “init” que
permite gestionar varios procesos, es decir, las aplicaciones completas se ejecutan como
una sola. En cambio, con Docker las aplicaciones se pueden separar como se desee.
Por ejemplo, para el sistema desarrollado se ha hecho uso de 4 contenedores Docker,
estando cada uno de ellos encargado de diferentes aspectos, permitiendo delegar ciertas
responsabilidades a contenedores específicos. Así la aplicación obtiene un mayor grado de
modularidad y aislamiento. [28]
Ventajas
Como se ha visto anteriormente, el uso de Docker como tecnología de “contenerización”
presenta múltiples ventajas que se van a resumir a lo largo del siguiente subapartado.
A grandes rasgos, Docker tiene cuatro principales ventajas que son:
1. Modularidad
2. Control de versiones
3. Restauración
4. Implementación rápida
Modularidad
El enfoque propuesto por Docker permite separar una aplicación en muchos elementos o
componentes independientes, pudiendo personalizarlos y adaptarlos para funcionar como
se desee. Para el caso del proyecto desarrollado, el sistema está dividido en 4 contenedores
de Docker, encargados de las siguientes tareas:
1. Gestionar conexiones VPN.
2. Gestionar peticiones HTTPS.
3. Gestionar conexiones a la base de datos.
4. Gestionar los procesos de autenticación y autorización.
Además, gracias al enfoque utilizado que se encuentra basado en una arquitectura de
microservicios, se pueden compartir distintos procesos de un mismo contenedor entre
distintas aplicaciones, de la misma forma que funciona la arquitectura orientada al servicio
Sistema para el seguimiento médico de pacientes
87
(SOA). Por ejemplo, un mismo motor de base de datos puede ser utilizado por distintas
aplicaciones indistintamente.
Control de versiones
Una imagen de un contenedor Docker se encuentra compuesta por una serie de capas, que
se van añadiendo una encima de la otra. Cuando todas estas capas se combinan dan lugar a
lo que se conoce como una imagen. Cada vez que un usuario realiza la ejecución de un
comando, sea del tipo que sea, se añade una nueva capa, dando lugar a una nueva versión
de la imagen.
Para solucionar el problema derivado del tiempo empleado para generar una nueva versión
de una imagen, Docker reutiliza las capas anteriores que componen el contenedor. De esta
manera, el tiempo necesario para construir una nueva imagen se reduce sustancialmente.
Restauración
Una de las grandes ventajas que ofrece esta tecnología y que la mayoría de sus usuarios
desconoce, es la simplicidad a la hora de volver a un punto anterior o proceso de
restauración. Al estar compuesta una imagen por distintas capas, constituyendo cada una de
ellas una nueva imagen, se pueden eliminar las capas deseadas hasta volver al momento
deseado.
Implementación rápida
Hace unos años el tiempo necesario para configurar adecuadamente un entorno de
desarrollo o producción, podía ser una tarea compleja y larga en el tiempo. Esto se puede
solucionar fácilmente utilizando Docker, ya que, el tiempo necesario para disponer de una
base de datos se puede reducir, literalmente, a unos pocos segundos.
Ángel Pérez Arroyo
88
Además, si se necesita configurar un contenedor de una manera muy concreta o particular
para conseguir que una aplicación funcione correctamente, gracias al sistema de
compartición de imágenes que integra esta tecnología, se puede compartir una imagen con
otros usuarios y que éstos, automáticamente, dispongan del mismo entorno para ejecutar la
aplicación.
Por último, destacar que, gracias a la alta velocidad con la que los contenedores se pueden
crear o destruir, se pueden levantar y eliminar entornos a una velocidad muy elevada. [29]
Sistema para el seguimiento médico de pacientes
89
2.4.11.1. WireGuard
Con el fin de gestionar las distintas conexiones VPN, que
permitirá el acceso al sistema por los sanitarios que se desplazan al
domicilio de pacientes con la imposibilidad de acudir al hospital o
centro de salud más cercano, se ha generado un contenedor de
Docker que hace uso de una imagen con el software WireGuard.
WireGuard es un servicio que permite definir un servidor de conexiones VPN. Una de las
grandes ventajas que ofrece esta tecnología es la capacidad de poder ofrecer una VPN
simple, rápida y moderna, pero siempre teniendo la seguridad como una máxima, ya que,
se hace uso de funciones criptográficas de última generación.
El principal objetivo de WireGuard es el de poder ofrecer a sus usuarios un rendimiento
global mucho mejor que el que ofrecen tecnologías alternativas como IPsec o OpenVPN.
El servicio WireGuard está diseñado como una VPN de propósito general tanto en equipos
ligeros y compactos, como en servidores con mucha mayor capacidad, que para equipos
como una Raspberry es algo fundamental para un correcto funcionamiento del resto de los
procesos. Tras verificar su correcto funcionamiento, se ha podido comprobar que es cierto,
ya que, el uso de CPU con diversos usuarios haciendo uso de conexiones VPN no ha
aumentado significativamente.
Otro factor a tener en cuenta es que dispone de clientes oficiales para prácticamente
cualquier plataforma: Windows, macOS, Linux, iOS y Android.
El servicio, actualmente, se encuentra en un proceso de desarrollo intenso, pero ya se
puede utilizar con total normalidad, al mismo tiempo que, también se puede considerar
como una de las mejores opciones para un servidor de conexiones VPN.
Ángel Pérez Arroyo
90
Simplicidad
WireGuard pretende ser una opción fácil tanto a nivel de configuración como de
utilización, llegando al nivel de servicios más cotidianos como SSH del que se hablará más
adelante. Para iniciar una conexión VPN, se hace uso de un intercambio de claves RSA, al
igual que como se hace cuando se accede mediante SSH,, siendo un proceso totalmente
transparente para cualquier usuario.
En resumen, WireGuard presenta una interfaz extremadamente simple, pero
extremadamente potente. [30]
Criptográficamente sólido
WireGuard hace uso de criptografía de última generación al utilizar funciones como Noise,
Curve 25519, ChaCha20, Poly1305, BLAKE2, SipHash24 o HKDF, que convierten a
WireGuard en un servicio fiable. Además, el software es continuamente revisado por
criptógrafos con el objetivo de garantizar la integridad y confidencialidad de los datos.
Superficie de ataque mínima
WireGuard ha sido diseñado desde el principio teniendo como un aspecto fundamental la
simplicidad, tanto para la implementación como para el uso de los usuarios. Por ello, el
software está diseñado para ser implementado en la menor cantidad de líneas de código
posibles, lo que simplifica notablemente los procesos de auditoría por los que pasa tras
cada nueva versión.
Así, en comparación con sus principales competidores como OpenVPN, OpenSSL o Swan,
WireGuard requiere un proceso de auditoría mucho más rápido y sencillo, a diferencia de
sus competidores que tienen que analizar gigantescas bases de datos y un número muy
superior de líneas de código, algo que, incluso para un grupo de expertos resulta una tarea
abrumadora.
Sistema para el seguimiento médico de pacientes
91
Alto rendimiento
Los principales motivos por los que WireGuard es mucho más rápido que sus competidores
son dos principalmente: el uso de funciones criptográficas optimizadas y su correcta
integración dentro del kernel de Linux, lo que tiene como relación directa un gran aumento
del rendimiento.
Todo ello provoca que, se puedan disponer de redes seguras y de muy alta velocidad.
Ángel Pérez Arroyo
92
2.4.11.2. Keycloak
Keycloak es un servidor de autenticación y autorización
desarrollado principalmente en Java por la compañía Red Hat
desde el año 2013, siempre bajo la licencia de Apache. Su
utilización no comenzó a popularizarse hasta el año 2015,
convirtiéndose en un gran producto que permite a los
desarrolladores de todo tipo de aplicaciones, abstraerse de la
problemática de desarrollar e implementar los procesos de
autenticación y autorización necesarios.
Desde hace años, Keycloak dispone de una nueva versión cada 6 semanas, ya que, dispone
de un gran desarrollo tanto de mantenimiento como de implementación de nuevas
funcionalidades, que convierten a Keycloak en una gran opción siendo esta muy fiable.
El servidor de autenticación y autorización utilizado en el proyecto dispone de infinitas
características, pero a continuación se muestran las más relevantes:
● Facilita el desarrollo de aplicaciones “Single Sign-on” y “Single Sign-out”.
● Hace uso de protocolos estándares como: OAuth 2.0, OIDC 1 .0, SAML 2.0 y
OpenID Connect.
● Realiza un proceso flexible de autenticación y autorización.
● Permite aplicar varios factores de autenticación como contraseñas de un solo uso o
verificaciones por doble factor (Google Authenticator, Correo electrónico...).
● También es compatible con la autenticación social, teniendo soporte para los
principales proveedores: Google, Facebook, Twitter….
● Es compatible con Active Directory y versiones similares de código abierto, por lo
que, puede acceder y utilizar información ya existente en árboles LDAP de las
organizaciones. [31]
Sistema para el seguimiento médico de pacientes
93
Conceptos principales
A continuación, vamos a tratar los conceptos principales asociados a un servidor Keycloak,
que permitirán entender de una mejor manera futuras explicaciones.
Imagen 35. Conceptos de Keycloak
A. Realm: se trata de la generalización de todo aquello que es necesario para realizar
un proceso de autenticación y autorización para una aplicación o conjunto de ellas
(Single-Sign-On).
B. User -> Listado de usuarios que están registrados y que disponen de acceso a la
aplicación.
C. Client -> Aplicación que va a utilizar Keyclock para realizar los procesos de
autenticación y autorización.
D. Roles -> Roles o grupos que van a poder tener los usuarios. Por ejemplo, para el
presente proyecto existen roles para médicos, enfermeros, trabajadores sociales y
administradores de sistemas.
E. (UI) Themes -> Aspecto visual y configuraciones ofrecidas por el servidor a los
distintos usuarios y clientes, que hacen uso de éste.
F. Identity Provider -> Encargado de obtener la identidad del usuario a partir de otro
proveedor.
G. Keys -> Listado de claves que pueden ser necesarios por Keyclock y sus clientes
asociados para establecer una conexión más fiable.
H. User Federation -> Permite conectarse con servidores Kerberos o LDAP.
Ángel Pérez Arroyo
94
Arquitectura del servidor
Como se puede ver en la imagen inferior, un servidor Keycloak está altamente
modularizado, permitiendo una gran introducción de mejoras, así como la solución de
problemas o vulnerabilidades encontradas.
Imagen 36. Arquitectura Keycloak
Debido a su diseño y arquitectura, Keycloak dispone de una serie de módulos
especializados cada uno de ellos en determinadas tareas. Por lo tanto, dichos módulos
pueden ser activados o no, dependiendo de las circunstancias de los distintos reinos
definidos.
Para el caso del proyecto desarrollado, en el reino (“realm”) definido en Keycloak se han
activado y utilizado los siguientes módulos:
● El módulo Realm fue el primero que se utilizó, ya que, tras la instalación del
servidor, se procedió a aplicar diversas técnicas de securización, con el objetivo de
proteger al servidor de ciberdelincuentes o ataques contra el mismo. Tras ello, el
módulo tan sólo se ha utilizado para acceder a través de la vista web con el fin de
administrar el servidor para dar de alta a los usuarios y al cliente del sistema.
Sistema para el seguimiento médico de pacientes
95
● El módulo Account ha permitido dar de alta y definir la política de permisos de los
que iba a disponer cada uno de los usuarios del sistema. Importante hay que
destacar que, el sistema no permite el registro de usuarios como lo hace un sistema
público.
El sistema desarrollado exige que un administrador desde su vista administrativa
de Keycloak, registre y habilite a un usuario para que éste pueda acceder al
sistema. De hecho, el software API REST no incluye ninguna petición HTTPS
para dar de alta nuevos usuarios, por lo que, tan sólo un administrador de sistemas
con las credenciales válidas y desde un equipo habilitado para ello, puede acceder
al servidor de Keycloak para dar de alta a nuevos usuarios.
● El módulo de SSO Protocols se ha hecho uso al gestionar los procesos de
autenticación mediante el uso del protocolo OpenID Connect 2.0.
● El módulo User Storage permite almacenar de manera segura gracias a los
mecanismos de cifrado de la información, las credenciales de acceso de los
distintos usuarios del sistema.
● Por último, el módulo Events ha sido utilizado para dejar constancia mediante el
sistema de logs que incluye el servidor, de cualquier circunstancia que acontezca al
servidor. [31]
Ángel Pérez Arroyo
96
Proceso sistema con usuarios no autenticados
A lo largo del presente apartado se procederá a exponer de una manera mucho más visual y
fácil, cómo un sistema genérico que está utilizando un servidor Keycloak, gestiona una
petición no autenticada de un usuario. A modo de apoyo se incluye la imagen inferior que
proporciona un gráfico bastante ilustrativo extraído de la página oficial del servidor.
Imagen 37. Manejo de usuarios no autenticados
1. Llega una petición sin autenticar al sistema.
2. Cuando el sistema recibe la petición, redirige al usuario a la vista de “Login”, para
que éste se autentique antes de realizar cualquier tipo de petición.
3. Una vez el usuario ha introducido sus credenciales, el servidor procede a
validarlas.
a. Si el proceso de autenticación es correcto, el servidor emite un token de
sesión, cookie de sesión, JWT, etc. Dependiendo de la configuración
aplicada, el servidor emitirá un tipo de acceso u otro para ser utilizado por
el cliente del sistema.
b. Si el proceso finaliza de manera incorrecta, se informa al usuario del error
y no se emite ningún tipo de acceso al usuario.
4. A continuación, se redirige al usuario a la vista o página indicada. Cuando el
servicio API en este caso recibe la clave de acceso, procede a validarla contra
Keycloak.
5. Con el fin de validar la clave de acceso al sistema utilizada por un usuario, el
sistema contrasta utilizando un canal alternativo contra Keycloak la veracidad de
los datos recibidos.
6. Seguidamente, el Keycloak emitirá una respuesta en función del token recibido. Si
es correcto así se lo hará saber a la aplicación, de la misma manera que si el token
es inválido, manipulado o similar.
Sistema para el seguimiento médico de pacientes
97
7. El usuario ya se encuentra totalmente autenticado en el sistema, y ya puede hacer
total uso del sistema dentro de sus permisos. [31]
Uso de tokens de acceso
Supongamos ahora que un usuario autenticado quiere realizar alguna acción contra el
servicio REST desarrollado. Cuando un usuario correctamente autenticado en el sistema
realiza una petición HTTPS, éste valida la veracidad del token utilizado. De la misma
manera que en el apartado anterior, con el fin de simplificar el proceso de comprensión del
procedimiento, se ha incluido una fotografía extraída del sitio web oficial del servidor
utilizado.
Imagen 38. Manejo de verficación de JWT
Ángel Pérez Arroyo
98
1. Un usuario autenticado realiza una petición API al sistema. Para ello, incluye en la
cabecera designada el token o clave de acceso al sistema.
2. El backend o proceso servidor procede a validar la veracidad de los datos. Como el
token, JWT o cualquier otro tipo de objeto emitido por Keycloak se manda firmado
por éste, se procede a validar dicha firma mediante la clave pública del reino
utilizado.
a. Para ello, el backend solicita a Keycloak la clave pública del reino o realm
del que está haciendo uso.
b. Keycloak le manda la clave pública solicitada, que como es pública no hay
problema en que sea conocida.
c. El servidor del servicio valida las credenciales. Si son correctas el proceso
continuo, en caso contrario se detiene.
3. Validando el token de acceso se comprueba posteriormente, que el usuario
disponga de los permisos necesarios para realizar la petición solicitada.
a. En caso afirmativo, se procesa la petición y se devuelven los datos
pertinentes.
b. En caso negativo, se deniega al usuario la realización de la petición. [31]
Sistema para el seguimiento médico de pacientes
99
Adaptadores para Java
Como Keycloak es un servicio adicional del sistema, éste ofrece diversos adaptadores que
permiten a desarrollos realizados en cualquiera de los principales lenguajes de
programación, hacer uso de sus tecnologías. Por ello, Keycloak incluye diversos tipos de
adaptadores diferentes para aplicaciones Java, de hecho, incluye uno específico para ser
utilizado en aplicaciones basadas en Spring Boot. La selección del adaptador correcto
depende de la plataforma a utilizar. Cada adaptador de Java compatible con Keycloak se
puede configurar mediante un simple archivo JSON, como el que se muestra en la
siguiente imagen:
Imagen 39. Adaptadores para Java - Keycloak
Ángel Pérez Arroyo
100
A continuación, se muestra la utilidad de cada una de las directivas que el fichero
mencionado anteriormente admite.
● realm -> reino a utilizar
● resource -> identificador del cliente en ese reino
● realm-public-key -> clave pública (formato PEM) del reino que se va a utilizar
desde el cliente
● auth-server-url -> la URL base del servidor Keycloak
● ssl-required -> garantiza que toda la comunicación hacia y desde el servidor
Keycloak se realice a través de HTTPS.
● confidential-port -> el puerto que utiliza el servidor Keycloak para conexiones
seguras a través de SSL / TLS. Esto es OPCIONAL. El valor predeterminado es
8443.
● use-resource-role-mappings -> si se establece en verdadero, el adaptador buscará
dentro del token “role mappings” a nivel de aplicación para el usuario. Si es falso,
buscará en el nivel de dominio las asignaciones de roles de usuario. Esto es
OPCIONAL. El valor predeterminado es falso.
● public-client -> si se establece en verdadero, el adaptador no enviará las
credenciales del cliente a Keycloak. Esto es OPCIONAL. El valor predeterminado
es falso.
● enable-cors -> Esto habilita la compatibilidad con CORS. Manejará las solicitudes
de verificación previa de CORS. También examinará el token de acceso para
determinar los orígenes válidos. Esto es OPCIONAL. El valor predeterminado es
falso.
● cors-max-age -> si CORS está habilitado, esto establece el valor del encabezado
Access-Control-Max-Age. Esto es OPCIONAL. Si no se establece, este
encabezado no se devuelve en las respuestas CORS.
● cors-allowed-methods -> si CORS está habilitado, esto establece el valor del
encabezado Access-Control-Allow-Methods. Debe ser una cadena separada por
comas. Esto es OPCIONAL. Si no se establece, este encabezado no se devuelve en
las respuestas CORS.
● cors-allowed-headers -> si CORS está habilitado, esto establece el valor del
encabezado Access-Control-Allow-Headers. Debe ser una cadena separada por
comas. Esto es OPCIONAL. Si no se establece, este encabezado no se devuelve en
las respuestas CORS.
● cors-exposed-headers -> si CORS está habilitado, esto establece el valor del
encabezado Access-Control-Expose-Headers. Debe ser una cadena separada por
Sistema para el seguimiento médico de pacientes
101
comas. Esto es OPCIONAL. Si no se establece, este encabezado no se devuelve en
las respuestas CORS.
● bearer-only -> esto debe establecerse como verdadero para los servicios. Si está
habilitado, el adaptador no intentará autenticar a los usuarios, solo verificará los
tokens de portador. Esto es OPCIONAL. El valor predeterminado es falso.
● autodetect-bearer-only -> esto debe establecerse en verdadero si su aplicación sirve
tanto para una aplicación web como para servicios web (por ejemplo, SOAP o
REST). Le permite redirigir a los usuarios no autenticados de la aplicación web a
la página de inicio de sesión de Keycloak, pero enviar un código de estado HTTP
401 a clientes SOAP o REST no autenticados, ya que no entenderían una
redirección a la página de inicio de sesión. Keycloak detecta automáticamente a los
clientes SOAP o REST basándose en encabezados típicos como X-Requested-
With, SOAPAction o Accept. El valor predeterminado es falso.
● enable-basic-auth -> esto le dice al adaptador que también admita la autenticación
básica. Si esta opción está habilitada, también se debe proporcionar el secreto. Esto
es OPCIONAL. El valor predeterminado es falso.
● expose-token -> si es verdadero, un cliente de navegador autenticado (a través de
una invocación HTTP de JavaScript) puede obtener el token de acceso firmado a
través de la URL root / k_query_bearer_token. Esto es OPCIONAL. El valor
predeterminado es falso.
● credentials -> especifica las credenciales de la aplicación. Esta es una notación de
objeto donde la clave es el tipo de credencial y el valor es el valor del tipo de
credencial. Actualmente se admite contraseña y jwt. Esto es REQUERIDO solo
para clientes con tipo de acceso 'Confidencial'.
● connection-pool-size -> esta opción de configuración define cuántas conexiones al
servidor Keycloak deben agruparse. Esto es OPCIONAL. El valor predeterminado
es 20.
● disable-trust-manager -> si el servidor Keycloak requiere HTTPS y esta opción de
configuración está establecida en true, no es necesario que especifique un almacén
de confianza. Esta configuración sólo debe usarse durante el desarrollo y nunca en
producción, ya que deshabilitará la verificación de certificados SSL. Esto es
OPCIONAL. El valor predeterminado es falso.
● allow-any-hostname -> si el servidor Keycloak requiere HTTPS y esta opción de
configuración se establece en verdadera, el certificado del servidor Keycloak se
valida a través del almacén de confianza, pero no se realiza la validación del
nombre de host. Esta configuración sólo debe usarse durante el desarrollo y nunca
en producción, ya que deshabilitará la verificación de certificados SSL. Esta
Ángel Pérez Arroyo
102
configuración puede ser útil en entornos de prueba. Esto es OPCIONAL. El valor
predeterminado es falso.
● proxy-url -> la URL del proxy HTTP, si se utiliza uno.
● truststore -> el valor es la ruta del archivo a un archivo de almacén de confianza. Si
antepone la ruta con classpath :, el almacén de confianza se obtendrá de la ruta de
clase de la implementación. Se utiliza para las comunicaciones HTTPS salientes al
servidor Keycloak. Los clientes que realizan solicitudes HTTPS necesitan una
forma de verificar el host del servidor con el que están hablando. Esto es lo que
hace el fideicomisario. El almacén de claves contiene uno o más certificados de
host de confianza o autoridades de certificación. Puede crear este almacén de
confianza extrayendo el certificado público del almacén de claves SSL del servidor
Keycloak. Esto es OBLIGATORIO a menos que ssl-required sea none o disable-
trust-manager sea verdadero.
● truststore-password -> contraseña del almacén de confianza. Esto es obligatorio si
el almacén de confianza está configurado y el almacén de confianza requiere una
contraseña.
● client-keystore -> esta es la ruta del archivo a un archivo de almacén de claves.
Este almacén de claves contiene un certificado de cliente para SSL bidireccional
cuando el adaptador realiza solicitudes HTTPS al servidor Keycloak. Esto es
OPCIONAL.
● client-keystore-password -> contraseña para el almacén de claves del cliente. Esto
es OBLIGATORIO si se establece el almacén de claves del cliente.
● client-key-password -> contraseña de la clave del cliente. Esto es OBLIGATORIO
si se establece el almacén de claves del cliente.
● always-refresh-token -> si es verdadero, el adaptador actualizará el token en cada
solicitud. Advertencia: cuando está habilitado, esto dará como resultado una
solicitud a Keycloak para cada solicitud a su aplicación.
● register-node-at-startup -> si es verdadero, el adaptador enviará la solicitud de
registro a Keycloak. Es falso de forma predeterminada y útil solo cuando la
aplicación está agrupada. Consulte Agrupación en clústeres de aplicaciones para
obtener más detalles.
● register-node-period -> período para volver a registrar el adaptador a Keycloak.
Útil cuando la aplicación está agrupada. Consulte Agrupación en clústeres de
aplicaciones para obtener más detalles.
● token-store -> los valores posibles son sesión y cookie. El valor predeterminado es
sesión, lo que significa que el adaptador almacena la información de la cuenta en la
sesión HTTP. Una cookie alternativa significa el almacenamiento de información
Sistema para el seguimiento médico de pacientes
103
en una cookie. Consulte Agrupación en clústeres de aplicaciones para obtener más
detalles
● token-cookie-path -> cuando se utiliza una tienda de cookies, esta opción establece
la ruta de la cookie utilizada para almacenar la información de la cuenta. Si es una
ruta relativa, se supone que la aplicación se ejecuta en una raíz de contexto y se
interpreta en relación con esa raíz de contexto. Si es una ruta absoluta, entonces la
ruta absoluta se usa para establecer la ruta de la cookie. Predeterminado para usar
rutas relativas a la raíz de contexto.
● principal-attribute -> atributo OpenID Connect ID Token con el que completar el
nombre de UserPrincipal. Si el atributo de token es nulo, el valor predeterminado
es sub. Los valores posibles son sub, nombre_usuario_preferido, correo
electrónico, nombre, apodo, nombre_proporcionado, nombre_familia.
● turn-off-change-session-id-on-login -> la identificación de la sesión se cambia de
forma predeterminada en un inicio de sesión exitoso en algunas plataformas para
conectar un vector de ataque de seguridad. Cámbielo a verdadero si desea
desactivarlo. Esto es OPCIONAL. El valor predeterminado es falso.
● token-minimum-time-to-live -> cantidad de tiempo, en segundos, para actualizar
de forma preventiva un token de acceso activo con el servidor Keycloak antes de
que expire. Esto es especialmente útil cuando el token de acceso se envía a otro
cliente REST donde podría caducar antes de ser evaluado. Este valor nunca debe
exceder la vida útil del token de acceso del reino. Esto es OPCIONAL. El valor
predeterminado es 0 segundos, por lo que el adaptador actualizará el token de
acceso solo si está vencido.
● min-time-between-jwks-requests -> cantidad de tiempo, en segundos, que
especifica el intervalo mínimo entre dos solicitudes a Keycloak para recuperar
nuevas claves públicas. Son 10 segundos por defecto. El adaptador siempre
intentará descargar una nueva clave pública cuando reconozca el token con un niño
desconocido. Sin embargo, no lo intentará más de una vez cada 10 segundos (de
forma predeterminada). Esto es para evitar DoS cuando el atacante envía muchos
tokens con bad kid obligando al adaptador a enviar muchas solicitudes a Keycloak.
● public-key-cache-ttl -> cantidad de tiempo, en segundos, que especifica el
intervalo máximo entre dos solicitudes a Keycloak para recuperar nuevas claves
públicas. Es 86400 segundos (1 día) por defecto. El adaptador siempre intentará
descargar una nueva clave pública cuando reconozca el token con un niño
desconocido. Si reconoce el token con un niño conocido, sólo usará la clave
pública descargada anteriormente. Sin embargo, al menos una vez por este
Ángel Pérez Arroyo
104
intervalo configurado (1 día por defecto) se descargará siempre una nueva clave
pública, incluso si el niño del token ya es conocido.
● ignore-oauth-query-parameter -> el valor predeterminado es falso; si se establece
en verdadero, se desactivará el procesamiento del parámetro de consulta
access_token para el procesamiento del token de portador. Los usuarios no podrán
autenticarse si solo pasan un access_token
● redirect-rewrite-rules -> si es necesario, especifique la regla de reescritura de URI
de redireccionamiento. Esta es una notación de objeto donde la clave es la
expresión regular con la que se debe hacer coincidir el URI de redireccionamiento
y el valor es la Cadena de reemplazo. El carácter $ se puede usar para referencias
inversas en la cadena de reemplazo.
● verify-token-audience -> si se establece en verdadero, durante la autenticación con
el token de portador, el adaptador verificará si el token contiene este nombre de
cliente (recurso) como audiencia. La opción es especialmente útil para los
servicios, que principalmente atienden solicitudes autenticadas por el token de
portador. Está configurado como falso de forma predeterminada; sin embargo, para
mejorar la seguridad, se recomienda habilitarlo. [31]
Sistema para el seguimiento médico de pacientes
105
2.4.11.3. MariaDB
Como gestor de bases de datos, se ha hecho uso de MariaDB
que es un motor derivado del más que conocido MySQL. El
gestor utilizado cuenta con licencia de uso GPL, lo que viene a
significar que se trata de un software abierto y gratuito para ser
utilizado por cualquier persona interesada.
Se trata de un software desarrollado por el propio fundador de MySQL, la fundación
MariaDB y la comunidad de desarrolladores de código libre. Una de las principales
ventajas de MariaDB es su fácil utilización, ya que, si se ha trabajado anteriormente con
bases de datos MySQL, cualquier persona puede hacer uso de MariaDB de la misma
manera, debido a que los comandos internos, interfaces, APIs y bibliotecas del sistema son
los mismos o prácticamente iguales, facilitando a nuevos usuarios su utilización
enormemente.
Esto ha sido uno de los grandes atractivos de MariaDB a la hora de captar nuevos usuarios,
porque permite a usuarios de MySQL utilizar código libre, con todas las ventajas que ello
incluye y abandonar el software privativo. Todo ello, sin tener que pasar por una curva de
aprendizaje prolongada, ya que, en un periodo muy reducido se pueden aprender las pocas
diferencias entre ambos sistemas.
Actualmente, MariaDB dispone de 5 versiones distintas del motor que cuentan con soporte:
● 10.6
● 10.5
● 10.4
● 10.3
● 10.2
En el sistema desarrollado en colaboración con la empresa Altia, se ha hecho uso de la
versión 10.5, en el momento en el que se inició el proyecto era la más reciente.
Posteriormente, se ha publicado la versión 10.6 que incluye algunas mejoras y solución a
ciertas vulnerabilidades detectadas. En concreto, para la versión utilizada que ha sido la
10.5.9, se conoce a fecha de redacción del presente documento una vulnerabilidad crítica
con código CVE-2021-27928, por lo que, en caso de trasladar el sistema a un entorno de
Ángel Pérez Arroyo
106
producción, se recomienda encarecidamente actualizar el motor de bases de datos a la
última versión disponible para solucionar este problema.
Mejoras con respecto a MySQL
Es cierto que MariaDB utiliza mecanismos para simplificar el proceso de aprendizaje a los
recién llegados desde motores MySQL, pero también incluye una serie de técnicas que
mejoran al SGBD MySQL en diversos apartados, y a continuación se detallan algunos de
ellos.
● Mecanismos de almacenamiento
○ Como alternativa a MyISAM en MariaDB se proporciona Aria que tiene
como principal ventaja su mayor fortaleza y estabilidad, lo que reduce de
manera significativa el número de caídas.
○ A partir de la versión 10.0 se incluyen mecanismos basados en el motor de
base de datos Cassandra, para gestionar datos NoSQL. Su funcionamiento
es limitado por el momento, pero ya sienta las bases para poder utilizar
MariaDB como una base de datos NoSQL.
○ Se ha reemplazado el motor de gestión de almacenamiento InnoDB por
XtraDB. Este nuevo motor incorpora el diseño compatible con ACID de
InnoDB y la arquitectura MVCC, lo que permite un mayor grado de ajuste
y escalabilidad. Asimismo, el motor también se adapta mejor al
procesamiento de procesadores con muchos núcleos, lo que soluciona
algunos de los problemas conocidos por InnoDB.
● Facilidad de uso
○ Permite definir columnas virtuales a las tablas deseadas por el usuario.
○ Se proporcionan estadísticas de índices y tablas a través de nuevas tablas
de la base de datos INFORMATION_SCHEMA, así como se ofrecen
nuevas utilidades mediante los comandos FLUSH y SHOW.
○ Se han introducido características similares a los gestores de bases de
datos NoSQL, como HandlerSocket. Esto proporciona acceso directo a
tablas del gestor InnoDB saltando la capa SQL, que en ocasiones puede
resultar problemática.
Sistema para el seguimiento médico de pacientes
107
● Prestaciones
○ El optimizador de MariaDB hace que el núcleo del SGBD ofrezca un
rendimiento más elevado que el de alternativas como MySQL.
○ Durante tareas de replicación se han introducido significativas mejoras de
rendimiento en las últimas versiones. En concreto, para algunas
ejecuciones el rendimiento es prácticamente el doble. [32]
Ángel Pérez Arroyo
108
2.4.11.4. Alpine + JDK8 + Maven
Para servir el desarrollo realizado bajo Spring Boot se
ha hecho uso de un contenedor basado en la distribución
de Linux llamada Alpine.
Alpine Linux es una distribución del sistema operativo de código libre basada en musl y
Busybox, teniendo como principal objetivo el proporcionar a sus usuarios un sistema
operativo lo más ligero posible, pero siempre teniendo en cuenta la seguridad como un
aspecto fundamental a tener siempre en cuenta. Asimismo, el sistema operativo pretende
que pueda ser útil para tareas de propósito general, pero sus aplicaciones se encuentran
principalmente en routers profesionales, cortafuegos, VPNs y servidores. [33]
Se trata de una distribución con tanta optimización que la imagen oficial de Alpine para
Docker tiene un tamaño inferior a los 5MB, de ahí que, esta distribución sea especialmente
conocida por poder ejecutarse directamente en la memoria RAM de prácticamente
cualquier dispositivo moderno.
Dadas las limitaciones del servidor utilizado y que las aplicaciones desarrolladas en Java
no son las más eficientes a nivel de recursos requeridos, se ha visto en la necesidad de
buscar una imagen que fuera lo más eficiente posible, al mismo tiempo que, las
características de seguridad requeridas para el sistema se cumplieran, con el fin de reducir
los recursos empleados por el contenedor.
Dado el tamaño de la imagen de Alpine (inferior a 5 MB) la lista de paquetes de Linux
instalados por defecto es muy reducida, por lo que, se ha visto en la necesidad de
personalizar la imagen de oficial para añadirle los paquetes de Maven y del JDK 8, con el
fin de poder compilar y ejecutar normalmente la aplicación desarrollada.
Por lo tanto, se dispone de una imagen con los mínimos paquetes necesarios para que ésta
funcione correctamente, y con la finalidad de poder ejecutar y servir el desarrollo
realizado, se han instalado los paquetes de Maven y JDK 8.
Sistema para el seguimiento médico de pacientes
109
2.4.11.5. NetData
Por último, y para concluir con el presente apartado de la
memoria dedicado a los contenedores Docker, destacar que, se
ha hecho uso del contenedor oficial de NetData con el que se
ha monitorizado el uso de los distintos componentes tanto del
sistema como físicos del servidor.
NetData es una herramienta que permite visualizar desde cualquier navegador web una
enorme cantidad de datos de monitorización recopilados en tiempo real sobre un equipo
con sistema operativo Linux. A parte de ofrecer los datos tradicionales como uso de CPU,
uso de memoria RAM, velocidad de disco, etc, también ofrece otros menos convencionales
y muy útiles para la correcta monitorización del sistema como pueden ser consultas SQL,
conexiones VPN y peticiones API realizadas.
Como se trata de una herramienta de monitorización, es fundamental que la cantidad de
recursos consumidos por la misma sean los menores posibles, con el objetivo de ofrecer
unas métricas lo más fidedignas posibles. Tanto es así que, para una mayor optimización,
es una herramienta desarrollada en su mayoría en C.
Su eficiencia llega a un nivel tan elevado que en un equipo como una Raspberry, que tiene
un núcleo muy poco potente en comparación a un servidor o equipo de sobremesa
moderno, no se llega a consumir ni un 5% de la CPU con todos los contenedores en
ejecución, pero sin tráfico de usuarios.
También destacar que, el sistema también incluye un entorno de alertas personalizables por
las que, si el sistema se encuentra bajo ciertas condiciones, se puede configurar para que
por ejemplo envíe un correo electrónico o SMS alertando al administrador de la
circunstancia. También se incluye una sección específica en lo referente a alertas, en la que
se pueden visualizar las actuales y un historial para ver las ocurridas en el pasado.
Por último, se muestran algunas fotografías ilustrativas de secciones de la página web que
genera NetData con toda la información. [34]
Ángel Pérez Arroyo
110
Imagen 40. Funcionamiento NetData
Sistema para el seguimiento médico de pacientes
111
2.4.12. SSH
El protocolo Secure SHell o también conocido como SSH es una
aplicación que funciona bajo el protocolo TCP en el puerto 22 por
defecto.
Mediante este protocolo se puede obtener acceso remoto bajo línea de comandos a un
servidor de manera segura (se debe utilizar la versión 2), tal y como su propio nombre
indica, toda la comunicación entre un cliente SSH y el proceso servidor va totalmente
cifrada.
Toda esta comunicación se realiza de manera segura, debido a que, se realiza a través de un
túnel SSH, que se genera entre ambos extremos de la comunicación cuando una nueva
sesión se produce. Además, gracias a diversas técnicas de cifrado aplicadas sobre la
comunicación que viaja dentro del túnel, cualquier información va de manera ilegible,
incluido el usuario y su correspondiente contraseña, siendo esto último una clara diferencia
con respecto a otros protocolos como Telnet. [35]
El acceso al servidor se realiza mediante este protocolo, como modo de protección, algo
fundamental teniendo en cuenta que, se trata de un servidor sin interfaz gráfica y sin una
conexión física a un monitor, ha sido mediante SSH mediante el que se ha establecido una
conexión remota para gestionar y administrar todo lo necesario para configurar y securizar
el equipo.
Con el fin de securizar dicho acceso se han aplicado una serie de medidas, quedando la
mayoría de ellas resumidas en el siguiente listado:
● El servicio tan sólo es accesible desde la red local o en su defecto desde una
conexión VPN, es decir, no es un servicio expuesto a internet de manera directa.
● El puerto empleado no ha sido el de por defecto.
● Se encuentra oculto gracias a la técnica del Port Knocking.
● El acceso al servidor requiere de una clave RSA privada de 4096 bits.
● Si el acceso se realiza fuera del horario definido (8:30-19:30), se solicita también
un código para ejecutar un doble factor de autenticación. El código se puede
obtener mediante la aplicación de Google Authenticator.
Ángel Pérez Arroyo
112
● Además, si el acceso se realiza entre medianoche y las 6 de la madrugada, el
servicio envía un correo electrónico.
Por último, si se producen 3 intentos seguidos fallidos de autenticación, otro correo
electrónico es enviado de manera automática, bloqueando también la dirección IP desde la
que se realizaron los intentos.
Sistema para el seguimiento médico de pacientes
113
2.5. Diseño de la aplicación
Ángel Pérez Arroyo
114
El sistema API REST desarrollado utilizando el framework Spring, presenta un diseño con
diversas clases Java así como entidades de base de datos, todo ello con el objetivo de poder
ofrecer un sistema lo más desacoplado, organizado y eficiente posible.
Al disponer de un sistema con un grado tan alto de desacoplamiento, cada clase del sistema
tiene sus responsabilidades correctamente delimitadas, lo que repercute de manera directa
en una mayor facilidad y fiabilidad a la hora de añadir mejoras y/o corregir errores.
Además, un gran desacoplamiento favorece tanto la reusabilidad como la mantenibilidad
del código fuente generado para proporcionar una buena experiencia al usuario, al mismo
tiempo que, no se pierde de vista la seguridad, siendo esto último un aspecto crítico en
sistemas que manejan información sensible como el desarrollado. Se debe tener en cuenta
que cuanto más claro, sencillo y estructurado se redacte el código fuente de una
herramienta más fácil será de entender y analizar por todo el mundo, lo que repercute de
manera directa en algunos aspectos como:
● La detección de errores podría ser posible simplemente leyendo el código.
● La realización de pruebas será más rápida y eficaz.
● Los procesos de auditoría serán mucho menos complejos.
Esto unido al modelo “vista controlador” correctamente aplicado, proporciona un sistema
con una gran cantidad de archivos, pero delegando en cada uno de ellos ciertos aspectos
muy concretos. Así, añadir elementos al sistema o modificar ciertos comportamientos del
mismo, debería ser un proceso totalmente transparente para el resto de los elementos no
involucrados.
En cuanto al sistema como se puede ver en 16 clases principales distintas que son:
● Address -> Representa la dirección asociada a un ciudadano.
● Citizen -> Se trata de la clase padre con la que se quiere generalizar la idea de
Paciente, Personal Sanitario y de un Administrador de Sistemas. Por ello, se
incluyen en ella datos genéricos que cualquier persona posee.
● Patient -> Representa los datos de un paciente y tiene relación con las siguientes
clases:
○ History -> Representa un registro del historial médico de un paciente. Por
ello, el historial médico total de un paciente se compone de diversos
registros de la clase History.
Sistema para el seguimiento médico de pacientes
115
○ Access Register -> Permite registrar cualquier tipo de acción (Lectura o
Escritura) sobre el historial de un paciente, así como de cualquiera de sus
datos.
● Health Personnel -> Se trata de una nueva generalización, que en este caso sirve
para representar la idea de un Médico, Enfermero o de un Trabajador Social.
○ Doctor -> Permite definir y gestionar de una manera mucho más particular
y específica a los médicos con acceso al sistema.
○ Nurse -> Permite definir y gestionar de una manera mucho más particular
y específica a los enfermeros y enfermeras con acceso al sistema.
○ Social Worker -> Igual que con los dos casos anteriores, permite definir y
gestionar de una manera mucho más particular y específica a los
enfermeros y enfermeras con acceso al sistema.
Al haberse hecho una especificación más concreta de los tipos de personal
sanitario con acceso al sistema, se puede
Además, esta clase además tiene relación con otras que son:
○ Device -> Permite definir y gestionar los diversos dispositivos a un
sanitario. Esto permite proporcionar una capa de seguridad adicional, tan
sólo permitiendo que un sanitario pueda acceder al sistema si está
utilizando un dispositivo habilitado para ello, y que además, está asociado
a su usuario. En caso contrario se deniega cualquier tipo de intento de
conexión contra el servidor.
○ Digital Certificate -> Permite definir y gestionar de manera fiable los
distintos certificados emitidos por la aplicación. Mediante dichos
certificados se puede validar y autenticar de manera inequívoca las
acciones realizadas por un sanitario o administrador de sistemas, ya que,
cualquier petición necesita de una firma digital.
● System Administrator -> Se trata de una especificación de la clase Citizen, con la
que se quiere definir y gestionar de la manera más apropiada y fiable las acciones a
las que los administradores de sistemas tienen acceso. Al igual que otras clases
anteriores, la referente a los administradores de sistemas también tiene relaciones
con otras clases:
Ángel Pérez Arroyo
116
○ Digital Certificate -> Tal y como se ha indicado anteriormente, permite
definir y gestionar los certificados que en este caso los administradores
utilizan para realizar las distintas gestiones. Así mismo, dado su posición
en el sistema, también son los encargados de generar, renovar y revocar
certificados digitales al resto de los usuarios del sistema.
○ Device -> En este caso el sistema está sólo pensado por motivos de
seguridad para que, un administrador tan sólo pueda acceder al sistema,
sólo si este se encuentra físicamente frente a su equipo de trabajo
destinado. Por lo tanto, el acceso remoto al sistema para los
administradores se encuentra bloqueado, reduciendo el rango de ataque de
un atacante y mejorando la seguridad del sistema.
○ Audit -> Se trata de una clase similar a Access Register pero destinada a
registrar de manera explícita las acciones (Lectura o Escritura,
Modificación o Borrado) realizadas por estos usuarios en particular.
● Audit Action -> Se trata de una enumeración para gestionar las acciones permitidas
por los usuarios. Contiene 4 valores: “READ”, “WRITE”, “UPDATE” y
“DELETE”.
● Active-> Se trata de una enumeración para controlar si un usuario está activo y
puede acceder al sistema. Contiene 2 valores: “YES”, “NO”.
● Document Type -> Se trata de una enumeración para definir los tipos posibles de
documentos de identidad que el sistema admite. Contiene 3 valores: “DNI”, “NIE”,
“PASSPORT”.
Tras aplicar el modelo MVC descrito anteriormente en el presente documento, así como
tras la generación de los distintos adicionales requeridos por el sistema (controladores,
excepciones, archivos de configuración, etc), el desarrollo total incluye 178 archivos de
código fuente, por lo que, como se puede intuir no se trata de un desarrollo pequeño y que
éste se encuentra altamente desacoplado tal y como se ha indicado.
Sistema para el seguimiento médico de pacientes
117
2.6. Arquitectura de la aplicación
A continuación, se muestra un diagrama con el que se pretende ilustrar el diseño de la
arquitectura global utilizada en el sistema desarrollado para el presente trabajo final de máster.
Como se puede ver en la imagen inferior, para poder acceder al sistema, los dispositivos
móviles asociados a los sanitarios deben establecer un túnel VPN entre ellos y el servidor del
sistema, ya que, aparte de que se quiere establecer un túnel seguro por el que viaje toda la
comunicación, el servicio REST tal y como se ha venido comentando hasta el momento, no es
un servicio accesible de manera directa desde internet, ya que, tan sólo es accesible y atiende
peticiones que provengan desde equipos de la red física local de la instalación y de dispositivos
conectados a la VPN.
Imagen 41. Arquitectura del sistema
Ángel Pérez Arroyo
118
Una vez el equipo tiene un túnel VPN generado, ya puede acceder al servicio REST para lo que en
primer lugar tendrá que autenticarse contra el servidor Keycloak para obtener el JWT, que como se
ha expuesto, anteriormente, es un requisito indispensable para poder hacer uso del servicio REST
diseñado, ya que, cualquier petición realizada en el sistema va debidamente autenticada.
Destacar que, pese a que el sistema se haya establecido en un único servidor está perfectamente
planteado para poder distribuirse en diversos servidores si así se desea, así cada uno de los
servicios hace uso de certificados SSL con los que se cifra cualquier tipo de comunicación,
estableciendo un grado más de seguridad que prevenga de cualquier tipo de fuga de información.
Sistema para el seguimiento médico de pacientes
119
3. Funcionalidades del sistema
A lo largo de este tercer apartado de la memoria, se van a mostrar las funcionalidades que el
sistema ofrece, una vez el usuario ha accedido a este. Por lo tanto, se van a mostrar las distintas
peticiones API que el sistema ofrece, pero sin profundizar en ellas, y será en el apartado de
resultados donde se profundizará un poco más en este aspecto.
Además, destacar que debido a un acuerdo de confidencialidad no se podrá exponer con un alto
grado de detalle el funcionamiento interno del sistema, pero aún así, se expondrá de forma
comprensible.
Con el objetivo de documentar y facilitar tanto el proceso de análisis del funcionamiento de cada
llamada API en profundidad, así como de los métodos utilizados por el servicio desarrollado bajo el
framework Spring, se ha documentado todo mediante dos métodos que son: Swagger y JavaDoc.
3.1. Swagger
Se trata de un conjunto de herramientas de código libre desarrolladas
originalmente por la organización SmartBear Software, que se
encuentran integradas dentro de un mismo ecosistema con el objetivo
de facilitar las tareas de diseño, construcción, utilización y
documentación de servicios web basados en el principio RESTful.
Una de las herramientas más utilizadas, es Swagger UI Tool, que como veremos más adelante
permite utilizar Swagger de manera totalmente gráfica a través de un navegador web.
Para generar toda la documentación necesaria, Swagger se basa en SpringFox, que es un
conjunto de librerías de Java que tienen como objetivo, permitir la automatización de
especificaciones de sistemas desarrollados bajo Spring, tanto por equipos informáticos como
por humanos. Todo ello se puede realizar mediante el uso de etiquetas o anotaciones Java
propias de Swagger.
Destacar que, no es la única opción a la hora de documentar servicios REST en Spring Boot, ya
que, existen otras alternativas como Spring REST Docs, que ofrece características similares a
Swagger y que también es muy fácil de utilizar e integrar en un proyecto, debido a que se trata
de un subproyecto oficial dentro del framework Spring.
Ángel Pérez Arroyo
120
3.1.1. Swagger integrado en Spring Boot
Ahora, procederemos a exponer el procedimiento necesario con el que se podrá integrar
Swagger dentro de una aplicación basada en Spring Boot. En concreto, esta integración se
ha realizado de manera satisfactoria utilizando la versión 2.4.4 de Spring Boot.
El primer paso para incluir Swagger dentro del proyecto, es el de añadir las siguientes
dependencias al fichero “pom.xml”:
Imagen 42. pom.xml
Al añadir y descargar las dependencias anteriores, ya podremos desde nuestro proyecto de
Spring Boot acceder a las librerías necesarias para integrar Swagger.
El siguiente paso consistirá en generar una clase Java para configurar el funcionamiento de
Swagger, como se muestra a continuación:
Sistema para el seguimiento médico de pacientes
121
Imagen 43. Configuración Swagger en Spring Boot
Mediante el método que se muestra en la imagen superior estaremos indicando entre otros
elementos, el tipo de documentación que debe generar (documentación del tipo Swagger),
el contexto de seguridad a aplicar, así como las rutas de los archivos que se deben incluir
durante el proceso de documentación, que en este caso han sido todos los controladores
que atienden las peticiones API REST de los clientes.
Tras ello, tan sólo nos restará por iniciar nuestro servidor de Spring Boot y acceder al
recurso “/swagger-ui.html”, que si se ha seguido el procedimiento correctamente debería
ofrecer un resultado como el siguiente:
Ángel Pérez Arroyo
122
Imagen 44. Interfaz Web Swagger
Sistema para el seguimiento médico de pacientes
123
3.1.2. Swagger UI
Tal y como se ha podido comprobar en la última imagen del apartado anterior, se han
detectado de manera totalmente automática los controladores utilizados en el servicio
REST, para los que, si hacemos ‘click’ sobre cualquiera de ellos podremos ver cada uno de
los métodos Java encargados de procesar cada petición HTTPS en particular, como es el
caso del controlador “Access Register” de la imagen inferior:
Imagen 45. Access Register - Swagger UI
Para que la información de la imagen anterior pueda aparecer de esa manera en la vista de
usuario de Swagger, es necesario proporcionar a Swagger la información que desea que
éste utilice para generar informes.
Por ejemplo, para el caso particular del controlador “Access Register” se han utilizado
principalmente 3 etiquetas Java propias de Swagger que son: “@Api”, “@ApiOperation”
y “@GetMapping”. Es cierto que existen más etiquetas que podrían permitir documentar
de una manera más intensa el sistema, pero es algo que no se ha considerado necesario, ya
que, junto con la documentación generada utilizando JavaDoc, ya se puede disponer de una
imagen lo suficientemente clara como para poder utilizar la API desarrollada sin
problemas.
Mediante la etiqueta “@Api” indicamos el nombre identificador de la clase que queremos
que aparezca en la vista de usuario de Swagger. En este caso el nombre utilizado ha sido
“Access Register”, que como se puede ver en la imagen inferior, se ha indicado de la
siguiente manera.
Imagen 46. Etiqueta Java para Swagger
Ángel Pérez Arroyo
124
A continuación, si se quiere proporcionar información detallada sobre el uso de una
petición HTTPS como puede ser la mostrada en la imagen inferior
(“/accessRegister/byHealthPersonnel”), todo ello se puede hacer utilizando las etiquetas
“@ApiOperation” y “@GetMapping”.
Imagen 47. Documentación petición REST utilizando Swagger
Mediante la primera de ellas, podemos hacer una pequeña explicación de la utilidad de
dicha petición HTTPS. Asimismo, también podemos explicar los parámetros requeridos
que se deben proporcionar junto con la petición. En este caso, como se puede ver tanto en
la imagen inferior como superior, la petición requiere de un objeto JSON que incluya dos
atributos: “idCitizen” y “idSocialSecurity”.
Sistema para el seguimiento médico de pacientes
125
Imagen 48. Documentación para Swaggeer en código fuente
Por último, mediante la etiqueta “@GetMapping” se indica que la petición es de tipo GET
y que su resultado será un objeto JSON.
En cuanto a los posibles códigos HTTP que la petición puede generar, son
automáticamente detectados por el software Swagger y se incluyen automáticamente. Se
podría proporcionar más detalle sobre los mismos utilizando la etiqueta
“@ApiResponse()”.
En caso de requerir otro tipo de dato más común como puede ser un ‘String’, Swagger
permitirá introducir el valor de dicho dato mediante un campo de texto, añadiendo a la
petición HTTPS que realizará al servidor el valor incluido por el usuario.
Imagen 49. Uso del servicio a través de Swagger
Ángel Pérez Arroyo
126
3.1.3. Swagger junto con el servicio desarrollado
Como se ha comentado anteriormente, una de las funcionalidades que ofrece Swagger
además de documentar un servicio RESTful, es poder interactuar con el sistema sin la
necesidad de tener que desarrollar ningún cliente o sistema similar.
Para ello, dado que todas las peticiones API requieren de un proceso de autenticación y
autorización realizado a partir de un token JWT, emitido por el servidor del sistema
encargado de dichas tareas, para poder hacer uso del servicio a través de Swagger, será
necesario proporcionar dicho token, en caso contrario, cualquier petición será denegada.
Para solucionar este problema, Swagger incluye una opción llamada “Authorize” donde
podemos incluir el JWT que se debe enviar al servicio REST, tal y como se puede ver en la
imagen inferior.
Imagen 50. JWT en Swagger UI
Finalmente, si procedemos a realizar una petición al servicio REST desarrollado, podremos
comprobar como efectivamente se puede utilizar también el conjunto de herramientas
Swagger para validar y monitorear el correcto funcionamiento del servicio desarrollado.
Para el caso del presente ejemplo, se ha hecho uso de una petición que devuelve los datos
de un ciudadano registrado en el sistema a partir de su DNI.
Sistema para el seguimiento médico de pacientes
127
Imagen 51. Petición REST utilizando Swagger
Tal y como se puede comprobar en la imagen superior, se introduce en el campo
designado, el ID del usuario que como se ha dicho anteriormente es su DNI. Por último,
para obtener el resultado se debe presionar el botón que pone “Execute”, que nos realizará
la petición HTTPS correspondiente, ofreciendo el siguiente resultado:
Imagen 52. Resultado petición REST en Swagger
Ángel Pérez Arroyo
128
3.2. JavaDoc
JavaDoc es una manera propuesta por la empresa Oracle con la
que generar documentación de una manera sencilla e intuitiva,
de cualquier tipo de desarrollo software basado en el lenguaje de
programación Java. Por lo tanto, JavaDoc es una alternativa más
que puede ser utilizada en desarrollos basados en Spring Boot,
así como para documentar desarrollos de sistemas REST.
Dada su facilidad de uso junto con el gran abanico de opciones que ofrece el estándar, ha
hecho que JavaDoc sea hoy en día el referente en temas de documentación de sistemas que
hacen uso de Java.
Es por ello, que la mayoría de IDEs como Visual Studio Code o IntelliJ incluyen soporte
de manera oficial y mediante extensiones de terceros, que facilitan el proceso de
construcción tanto de la documentación como de la generación de esta.
Su uso es muy sencillo y se reduce a conocer ciertas etiquetas reservadas para su uso
exclusivo en JavaDoc, siendo algunas de ellas las siguientes:
● “@author” -> Permite indicar el nombre del desarrollador.
● “@version” -> Permite indicar la versión de por ejemplo un método.
● “@param” -> Permite explicar un parámetro requerido por un método y su
utilidad.
● “@return” -> Permite informar sobre el tipo de objeto y/o contenido que devuelve
un método, a excepción de los métodos ‘void’.
● “@throws” -> Permite definir y explicar las excepciones que se lanzan en un
método, así como el motivo o los motivos por los que estas pueden ser generadas.
● “@see” -> Permite asociar a un método con otro o con otra clase.
● “@deprecated” -> Permite indicar si un método ha quedado obsoleto.
Expuesto brevemente el funcionamiento de JavaDoc, se va a mostrar un ejemplo real
llevado a cabo en el sistema, en el que se ha documentado tanto con Swagger como con
JavaDoc, la llamada HTTPS que atiende cuando se quiere visualizar el historial médico de
un paciente determinado. Como se puede ver en la imagen inferior, se ha proporcionado
una pequeña descripción del objetivo del método Java, así como se ha indicado el tipo de
dato necesario que en este caso es un objeto JSON. Por último, también se indica el tipo de
dato devuelto, que en este caso es una instancia de “ResponseEntity”.
Sistema para el seguimiento médico de pacientes
129
Imagen 53. Documentación JavaDoc en el código fuente
Una vez documentado todo el sistema y utilizando la utilidad proporcionada por IntelliJ
Ultimate, se ha procedido a generar toda la documentación con JavaDoc, que se ofrece a
través de ficheros HTML, por lo que, para su visualización será necesario disponer de un
navegador web con el que visualizar su contenido adecuadamente. Una vez se ha accedido
al fichero “index.html”, para el caso del sistema desarrollado se obtiene el siguiente
resultado:
Ángel Pérez Arroyo
130
Imagen 54. Documentación JavaDoc - 1
Si buscamos la clase “HistoryController” que es donde se encuentra el método indicado
anteriormente, se obtiene el siguiente resultado:
Sistema para el seguimiento médico de pacientes
131
Imagen 55. Documentación JavaDoc - 2
Finalmente, accediendo al método llamado “one” se puede ya visualizar, de una manera
clara, toda la información que se ha incluido en el fichero de código fuente de Java.
Imagen 56. Documentación JavaDoc - 3
Por lo tanto, la documentación de cualquier sistema es crucial, ya que, permite a otros
desarrolladores entender de una manera mucho más clara el funcionamiento del sistema.
Así se facilitan las tareas de mantenimiento, actualizaciones y soluciones de errores y
vulnerabilidades encontradas.
Ángel Pérez Arroyo
132
4. Resultados
Durante el presente apartado de la memoria, se procederán a exponer las distintas peticiones API
desarrolladas para el presente proyecto, así como se demostrará el correcto funcionamiento de
algunas de ellas. No se procederá a mostrar en detalle la totalidad de las peticiones que admite el
sistema por motivos contractuales.
Para llevar a cabo la presente demostración, se hará uso de la herramienta Postman, ya que,
después de utilizar diversas herramientas como Swagger o CURL, se ha llegado a la conclusión de
que al menos para el presente proyecto, Postman incluye todas las características necesarias para
hacer uso del servicio REST en una misma herramienta o entorno.
También resaltar que, a modo de verificación global del sistema, las siguientes pruebas se van a
realizar mediante un equipo portátil tanto a través de una conexión WiFi en la misma red en la que
se encuentra el servidor, como a través de una conexión VPN utilizando el cliente de WireGuard y
una conexión de datos móviles.
Con el objetivo de que este proceso resulte claro y sencillo de entender, he añadido 9 subapartados,
a través de los cuales se expondrán de manera detallada las distintas características que cada uno de
los controladores12 o controllers que el sistema incluye.
12 Ver en el glosario
Sistema para el seguimiento médico de pacientes
133
4.1. Ciudadano (Citizen)
Como se puede apreciar en la imagen inferior, en cuanto al manejo de la información
referente a los ciudadanos registrados en el sistema, se disponen de 5 peticiones REST,
siendo dos de ellas del tipo GET y el resto del tipo DELETE, POST y PUT.
Imagen 57. CitizenController
Además, gracias al uso de Swagger UI podemos ver que para cada una de las peticiones
que el controlador para ciudadanos admite, se incluye una pequeña descripción indicando
la utilidad de cada una de ellas.
Aclarado lo anterior, a continuación, se va a proceder a mostrar el correcto funcionamiento
del método POST, que como se indica en la imagen superior, permite dar de alta o registrar
a un nuevo ciudadano en el sistema. Por ello, utilizando el software Postman, se ha
configurado el entorno de la siguiente manera para realizar correctamente la petición:
1. Se ha seleccionado que el método HTTP a utilizar sea del tipo POST.
2. Se ha indicado la URL a utilizar, siendo en este caso
“https://192.168.100.51:8443/citizen/newCitizen”, ya que, tal y como se muestra
en la imagen inferior, se ha hecho uso de una variable llamada “HTTPS raspberry”
que hace referencia a la parte común que cualquier petición tiene.
3. Además de la cabecera “Authorization” donde se ha incluído el JWT precedido del
valor “Bearer”, que permite al servidor conocer el tipo de acceso empleado por el
cliente, la cabecera “digitalSignature” donde se incluye una firma digital generada
por el personal autorizado, que permita dejar constancia de la operación que éste
va a realizar.
Ángel Pérez Arroyo
134
Imagen 58. Firma digital - Citizen Controller
1. Por último, se ha incluido en el cuerpo o body de la petición, el siguiente objeto
JSON, con todos los datos referentes al nuevo ciudadano que se desea registrar en
el sistema.
Imagen 59. Cuerpo petición - Citizen Controller
Finalmente, se envía la petición recién configurada, y si todo ha ido correctamente, el
servidor devolverá al cliente un código de confirmación 201, indicando que el proceso se
ha podido realizar correctamente y que el nuevo ciudadano ha sido dado de alta. Así, tal y
como se puede ver en la imagen inferior, el servidor también procede a devolver los datos
con los que el ciudadano ha sido dado de alta en el sistema.
Sistema para el seguimiento médico de pacientes
135
Imagen 60. Resultado petición - Citizen Controller
Ángel Pérez Arroyo
136
4.2. Paciente (Patient)
Para el caso del controlador de pacientes, también se han desarrollado un total de cinco
nuevas peticiones API REST, las cuales se dividen nuevamente en dos peticiones del tipo
GET, que permiten conocer los datos de un paciente en concreto a partir de una serie de
parámetros o bien, obtener el listado completo de pacientes registrados en el sistema.
Además de estas dos peticiones del tipo GET, también se incluye una de los tipos
DELETE, POST y PUT.
Imagen 61. PatientController
En esta ocasión, se demostrará el funcionamiento de la petición GET que permite conocer
los datos concretos de un paciente. Para ello, tal y como se demostrará posteriormente, el
sistema necesita conocer su identificador como ciudadano (NIF, NIE o Pasaporte) y su
número identificativo como paciente (número seguridad social o similares). Por lo tanto,
ambos números deben ser únicos y deben coincidir para una misma persona física, en caso
contrario, el sistema rechazará la petición.
Para hacer uso de la petición REST, se vuelve a hacer uso de la variable “HTTPS
raspberry”, que como se ha mencionado durante el ejemplo anterior, tiene el valor
“https://192.168.100.51:8443”. Seguidamente, se indica que se desea utilizar el controlador
de paciente, y por último el recurso llamado “one”. Además, tal y como se puede ver en la
imagen inferior, el sistema requiere que incluya con la petición una cabecera llamada
“digitalSignature” con el contenido de la firma digital que se debe validar en el servidor.
Sistema para el seguimiento médico de pacientes
137
Imagen 62. Firma digital - PatientController
Junto con la cabecera mencionada anteriormente, la petición también requiere que se
incluya en el cuerpo de la petición un objeto JSON con el identificador del ciudadano y de
la seguridad social, que como se ha mencionado anteriormente, ambos números deben
ofrecer como resultado una única persona. En caso contrario, el sistema rechazará la
petición.
Imagen 63. Cuerpo petición - PatientController
Con todos los datos requeridos por el sistema incluidos en la petición HTTPS, ya
estaremos en disposición de enviar la solicitud y verificar la respuesta recibida por parte
del servidor del sistema. Si toda la información incluída junto con la petición es correcta, el
sistema devolverá junto con un código HTTP 200, los datos personales de ese paciente en
particular, tal y como se puede ver en la imagen inferior:
Ángel Pérez Arroyo
138
Imagen 64. Resultado petición - PatientController
Por último, destacar que, en el campo llamado “digitalSignature” que se incluye dentro del
objeto JSON generado por el servidor a modo de respuesta, se incluye la firma digital del
último sanitario que ha realizado algún cambio sobre los datos del paciente o bien, ha
registrado al paciente en el sistema. Este hecho junto con un sistema propio de auditoría,
deja evidencias que permitan auditar el correcto desempeño de los usuarios del sistema, es
decir, malas praxis por parte de los sanitarios o acciones perjudiciales llevabas a cabo por
los administradores del sistema.
Sistema para el seguimiento médico de pacientes
139
4.3. Administrador de Sistemas (System Administrator)
En lo referente al controlador de peticiones relacionadas con los administradores de
sistemas, para la primera versión del sistema desarrollado, se han incluido nuevamente
cinco peticiones HTTPS, que se componen de dos peticiones del tipo GET y una para el
resto de las peticiones desarrolladas (DELETE, POST y PUT).
Como se puede ver en la imagen inferior, al igual que con los anteriores dos controladores,
se ha incluido una pequeña documentación de Swagger, que permite a cualquier usuario
del sistema que pretenda utilizar esta interfaz de usuario, conocer el propósito de cada una
de las distintas peticiones.
Imagen 65. SystemAdministratorController.
En esta ocasión, se va a proceder a demostrar el correcto funcionamiento de la petición que
hace uso del método PUT, es decir, la petición del controlador destinada a actualizar
información de un administrador de sistemas.
Este procedimiento puede resultar más práctico de lo que en un primer momento se pudiera
llegar a pensar, entre otras posibilidades, la presente petición permite sin eliminar del
sistema a un administrador, bloquear su usuario para que éste no pueda realizar ninguna
acción en el sistema. Esta acción en particular se puede conseguir cambiando el valor del
parámetro “active” a NO. Automáticamente, el sistema desarrollado detectará antes de
procesar cualquier tipo de petición, que el usuario ya no tiene acceso al sistema, por lo que,
rechazará cualquier petición directamente.
Ángel Pérez Arroyo
140
Para hacer uso de este recurso del servicio REST, se deberá configurar la petición con el
método HTTP apropiado (PUT) junto con la URL correcta, siendo en este caso
“https://192.168.100.51:8443/administrators/updateAdministrator”. Junto a la petición, tal
y como se puede ver en la imagen inferior, se debe incluir una cabecera con la firma digital
de los datos que se van a actualizar en el servidor del administrador
Imagen 66. Firma digital - SystemAdministratorController
En el cuerpo del mensaje, se debe incluir un objeto en formato JSON como el que se
muestra a continuación, que permite al sistema detectar de manera inequívoca los campos a
actualizar de forma automática, reduciendo el tiempo necesario para actualizar los datos, ya
que, tan sólo se modifican aquellos que son necesarios. En este caso, tal y como se había
adelantado al inicio del presente apartado, se va a bloquear el acceso al sistema al
administrador de sistemas con ID “76262f21-7157-47f6-9e54-59635f34dcdd”.
Sistema para el seguimiento médico de pacientes
141
Imagen 67. Cuerpo petición - SystemAdministratorController
Si la petición ha sido enviada de manera correcta y se cumplen con todos los
requerimientos de seguridad definidos para el uso del recurso descrito, el servidor del
sistema devolverá una respuesta con código 200 y un objeto JSON con los datos
registrados para el administrador de sistemas para el que se han acaban de actualizar los
datos. Un ejemplo de este hecho, podría ser el objeto JSON mostrado en la imagen inferior.
Ángel Pérez Arroyo
142
Imagen 68. Resultado petición - SystemAdministratorController
Sistema para el seguimiento médico de pacientes
143
4.4. Personal Sanitario (Health Personnel)
El sistema también dispone de un nuevo controlador encargado de atender las peticiones
relacionadas con el procesamiento de datos de los sanitarios registrados en el sistema. Al
igual que para los tres controladores anteriores, el sistema dispone de cinco recursos API
REST con los que consultar entre otros la información de un sanitario en concreto o de
todos aquellos que el sistema tiene constancia.
Nuevamente, para el controlador de las peticiones referentes a los sanitarios del sistema, se
ha incluido la suficiente documentación tanto a nivel de JavaDoc como de Swagger, con el
objetivo de permitir tanto a los usuarios como desarrolladores, hacer uso del servicio de
una manera sencilla y rápida.
Imagen 69. HealthPersonnelController
Para la demostración del funcionamiento del presente controlador, se va a mostrar cómo
también el sistema es capaz de mostrar de una manera estructurada el contenido de todos
los sanitarios registrados en el sistema. Destacar que, por el tamaño de la respuesta del
servidor no se va a proceder a mostrar la totalidad de esta, ya que, la respuesta generada
daría lugar a varias páginas del documento, y eso tampoco es lo que se pretende demostrar,
sino el correcto funcionamiento y las distintas capas de seguridad que el proyecto incluye
para proteger y securizar los datos. Aclarado lo anterior, como se va a hacer uso del recurso
que ofrece toda la información de los sanitarios registrados, la URL empleada será
“https://192.168.100.51:8443/administrators/all”. Además, el método HTTP utilizado será
del tipo GET tal y como se podría prever. Por último, al igual que con anteriores peticiones
realizadas, se debe enviar una cabecera con el contenido de una firma digital que permita al
sistema dejar constancia y veracidad de la acción solicitada por el usuario.
Ángel Pérez Arroyo
144
Imagen 70. Resultado petición - HealthPersonnelController
Tal y como se puede ver en la imagen anterior, con una misma petición HTTPS se ha
conseguido obtener los datos de los sanitarios registrados en el sistema. Nuevamente
Sistema para el seguimiento médico de pacientes
145
recalcar que por motivos de tamaño de la respuesta no se ha podido visualizar el contenido
total de la misma, pero sí que mediante la imagen anterior se puede apreciar como en una
misma respuesta se ha devuelto la información de un enfermero y de un trabajador social,
con los siguientes nombres de usuario: Enfermero - TFM, Trabajador social - TFM.
4.4.1. Médico (Doctor)
A continuación, se procede a detallar y exponer el funcionamiento de una de las cinco
peticiones HTTPS, que el controlador destinado a manejar y procesar información de los
médicos dispone. Al igual que con los anteriores casos, el controlador dispone de dos
peticiones del tipo GET y una de los tipos: DELETE, POST y PUT.
Todo esto se puede visualizar de una manera mucho más rápida e intuitiva para cualquier
usuario a través de la interfaz web de Swagger, gracias al trabajo realizado para
documentar cada una de las peticiones.
Imagen 71. DoctorController
En esta ocasión se demostrará el correcto funcionamiento del proceso referente al registro
y activación de la cuenta de un nuevo médico en el sistema, ya que, presenta algunas
diferencias con el proceso de registro de un sanitario. La principal diferencia entre ambos
casos radica en que los médicos tendrán acceso al sistema, mientras que los ciudadanos o
pacientes no. Con ello aclarado, vamos a ver el proceso de creación de un nuevo médico.
En esta ocasión, debido a que es un proceso de registro el método a utilizar será POST y la
URL “https://192.168.100.51:8443/doctor/newDoctor/?userID={value}”. Tal y como se
Ángel Pérez Arroyo
146
puede deducir tanto de la URL anterior, como de la que aparece en la imagen inferior, el
sistema requiere de un identificador de usuario que va a realizar el alta, como parámetro
necesario para el control del personal habilitado para efectuar ese tipo de operación.
Al mismo tiempo, se dará de alta al nuevo médico en el servicio Keycloak, con el objetivo
de conocer su identificador como usuario del sistema, por ser un valor necesario que incluir
en el cuerpo de la petición.
Además, por seguridad, el sistema requiere el paso de una firma digital a través de una
cabecera especialmente destinada para ello, tal y como se puede ver en la imagen inferior:
Imagen 72. Firma digital - DoctorController
Por último, el recurso requiere de un cuerpo en formato JSON con los datos
correspondientes al médico que se quiere registrar en el sistema, siendo un ejemplo de este
objeto el que se muestra a continuación:
Sistema para el seguimiento médico de pacientes
147
Imagen 73. Cuerpo petición - DoctorController
Finalmente, ya se podrá enviar la petición, que devolverá un código 201 indicando que
todo ha ido correctamente y que el nuevo médico ha sido registrado en el sistema. Destacar
que, este proceso es algo más lento que los anteriores debido a que el sistema debe generar
claves RSA de 4096 bits para el nuevo usuario, que en un futuro le permitan realizar firmas
digitales. Debido a que la clave privada no es almacenada en el servidor por motivos
obvios, la presente operación sólo puede ejecutarse por personal habilitado para ello, y está
disponible desde determinadas direcciones IP indicadas previamente, ya que, junto con los
datos de confirmación registrados en el sistema, se incluye un parámetro adicional que es
la clave privada del usuario. De esta manera, el personal habilitado para estas operaciones
puede obtener la clave privada del usuario y almacenarla en los dispositivos móviles que
vaya a utilizar dicho usuario.
Ángel Pérez Arroyo
148
Imagen 74. Resultado petición - DoctorController
Con esto lo que se consigue es evitar almacenar claves privadas en el sistema. Y como se
ha dicho recalcado anteriormente, dada la importancia de operaciones como la presente,
existen medidas de seguridad adicionales que ofrecen mayores garantías durante el
proceso. Además, todo el proceso al igual que el resto, queda debidamente registrado para
poder conocer de manera sencilla el momento, lugar y usuario que ha llevado a cabo cada
acción.
Sistema para el seguimiento médico de pacientes
149
4.4.2. Enfermero (Nurse)
Como se puede ver en la imagen inferior obtenida de la interfaz web de Swagger, el
controlador de esta primera versión encargado de procesar las peticiones relacionadas con
los enfermeros del sistema también tiene implementadas cinco peticiones HTTPS, siendo
estás las descritas en la imagen inferior.
Imagen 75. NurseController
En esta ocasión se mostrará el correcto funcionamiento del recurso que permite obtener la
información concreta de un enfermero o enfermera registrado en el sistema. Para ello, será
necesario conocer el identificador como profesional que dispone dicho usuario en el
sistema. Aclarado lo anterior, para hacer uso del recurso necesitaremos configurar la
petición nuevamente al tipo GET y establecer la URL adecuada, siendo ésta de acuerdo a lo
indicado en la interfaz de Swagger, la siguiente:
“https://192.168.100.51:8443/nurse/one?id={value}”. El parámetro que se debe pasar por
la URL, será el identificador del sanitario del que se desea obtener la información, tal y
como se ha indicado previamente.
Por último, antes de enviar la solicitud, al igual que con anteriores peticiones descritas, será
necesario incluir una cabecera con el valor de la firma digital, que permita verificar que la
solicitud se ha realizado por el usuario que se indica en el JWT adjuntado junto con la
petición.
Si todos los datos incluidos son correctos, el sistema devolverá un código 200, junto con
los datos asociados al enfermero o enfermera con ese identificador, tal y como se puede ver
en la siguiente imagen:
Ángel Pérez Arroyo
150
Imagen 76. Resultado petición - NurseController
Sistema para el seguimiento médico de pacientes
151
4.4.3. Trabajador Social (Social Worker)
El controlador asociado a los trabajadores sociales se trata del último de los cuatro
controladores diseñados e implementados para la presente versión del sistema objetivo del
presente proyecto final de máster. Al igual que para los anteriores controladores
relacionados con el personal sanitario con acceso al sistema, éste admite cinco peticiones
HTTPS, siendo dos de ellas del tipo GET y una de los tipos DELETE, POST y PUT.
Imagen 77. SocialWorkerController
Para concluir con los controladores relacionados con el personal sanitario, se va a mostrar
nuevamente el proceso empleado por el sistema para registrar un nuevo trabajador social,
que como se podrá comprobar es muy similar al de los médicos. Con esto lo que se quiere
demostrar es que se ha dado la misma importancia a los registros de los médicos que a los
trabajadores sociales, y esto por motivos de seguridad y en evitación de accesos ilegítimos
al sistema.
Dado que se trata nuevamente de una petición del tipo POST, se debe configurar el cliente
utilizado para enviar este tipo de petición. En cuanto a la URL que se debe emplear para
acceder correctamente al recurso REST implementado es
“https://192.168.100.51:8443/socialWorker/newSocialWorker/?userID={value}”, siendo el
valor del parámetro “userID” el identificador que el usuario que va a hacer la petición
dispone en Keycloak. De esta manera, el sistema puede añadir una capa de seguridad
adicional para verificar que el usuario es legítimo y puede realizar dicha petición al
sistema..
Ángel Pérez Arroyo
152
Imagen 78. Firma digital - SocialWorkerController
Al igual que con las anteriores peticiones, el sistema requiere de una firma digital que debe
ser incluida mediante la cabecera con nombre “digitalSignature”. Con todos los datos
correctamente incluídos, tan sólo restará por añadir en el cuerpo de la petición, un objeto
JSON con los datos del nuevo trabajador social que se quiera registrar en el sistema.
Imagen 79. Cuerpo petición - SocialWorkerController
Como se puede ver en la imagen anterior, el objeto JSON enviado al sistema no contiene
una clave pública RSA válida, pero esto no es problema, ya que, el sistema es conocedor
Sistema para el seguimiento médico de pacientes
153
de que ese dato en particular no puede ser conocido hasta que el usuario no ha sido
registrado y se proceda a generar su pareja de claves RSA de 4096 bits. Pese a que su
contenido sea irrelevante para la petición, su inclusión en el objeto JSON al igual que con
el resto de atributos resulta fundamental, así el controlador lo primero que hace antes de
procesar la petición es convertir de manera automática el objeto JSON a un objeto Java del
tipo “SocialWorker”. En caso de no incluirse, el sistema de Spring Boot no sabrá convertir
correctamente el objeto, lo que provocará que la petición no se llegue a procesar y se
devuelva un error.
En este caso, como todos los datos han sido correctamente indicados, el servidor devuelve
una respuesta con código 201 indicando que el proceso se ha realizado con éxito. Además,
al igual que se ha podido mostrar durante el procedimiento de registro de un nuevo médico,
se incluye también la clave pública y privada del nuevo trabajador social, para que ésta
pueda ser correctamente almacenada por el personal habilitado en el dispositivo o
dispositivos móviles, que el sanitario vaya a utilizar. Resaltar nuevamente que la clave
privada no es almacenada en el servidor y por lo tanto, no es enviada en ningún otro
momento por el servidor.
En caso de extraviar o perder el anonimato de la clave privada del usuario, un usuario
administrador, debería deshabilitar la clave actual y generar una nueva al sanitario, para
que éste pueda seguir utilizando el sistema con normalidad.
Ángel Pérez Arroyo
154
Imagen 80. Resultado petición - SocialWorkerController
Sistema para el seguimiento médico de pacientes
155
4.5. Dispositivo (Device)
Con el objetivo de simplificar la administración de los distintos dispositivos móviles y fijos
que los usuarios pueden utilizar para hacer uso del sistema, se ha incluído otro nuevo
controlador, que para esta primera versión del servicio incluye un total de siete peticiones
HTTPS, siendo cuatro de ellas del tipo GET, tal y como se puede comprobar en la imagen
inferior.
Imagen 81. DeviceController
Con la inclusión de este nuevo controlador, se pretende que el acceso al sistema por parte
de los usuarios sea fiable, al mismo tiempo que los administradores puedan realizar las
tareas cotidianas relacionadas con los dispositivos de una manera sencilla y eficaz.
Aclarado lo anterior, se va a proceder a mostrar los pasos necesarios para consultar los
datos de un terminal, que tiene asociada una clave pública determinada, es decir, se quieren
conocer los datos de un terminal a partir de una clave RSA, que a su vez está vinculada a
un único usuario del sistema, como se verá al final.
Para hacer uso de esta petición necesitamos realizar la siguiente configuración:
● Configurar el cliente para enviar una petición del tipo GET.
● Fijar la URL a la que se debe realizar la petición, siendo en este caso:
“https://192.168.100.51:8443/device/byPublicKey”.
● Introducir la correspondiente firma digital en la cabecera destinada para ello.
Ángel Pérez Arroyo
156
● Enviar en el cuerpo de la petición el valor de la clave pública RSA que se quiere
utilizar para obtener el dispositivo o dispositivos, asociados a ella.
Todos estos detalles se pueden observar mediante las siguientes dos imágenes:
Imagen 82. Firma digital – DeviceController
Imagen 83. Cuerpo petición - DeviceController
Finalmente, tan sólo nos quedará enviar la petición y esperar el resultado, si los datos son
correctos, debe devolver un código 200 junto con los datos del terminal asociado a la clave
pública del usuario en formato JSON al igual que el resto de las respuestas del sistema.
Sistema para el seguimiento médico de pacientes
157
Imagen 84. Resultado petición - DeviceController
Ángel Pérez Arroyo
158
4.6. Historial Médico (History)
Uno de los controladores más relevantes para el correcto funcionamiento global del sistema
es el referente a los historiales médicos de los pacientes, ya que, se debe recordar que el
objetivo principal del proyecto es permitir el acceso de manera segura a los datos médicos
de un paciente, y ello implica de manera directa al historial clínico.
Por ello, y con el objetivo de intentar suplir las necesidades básicas de los sanitarios
encargados de realizar visitas a pacientes a domicilio, para esta primera versión del
servicio, se han implementado cinco peticiones REST que se pueden ver de manera gráfica
en la imagen inferior.
Imagen 85. HistoryController
En esta ocasión se va a proceder a demostrar el correcto funcionamiento del recurso REST
que permitiría a un sanitario, acceder de manera fiable a los datos médicos de un paciente
realizados en un día determinado, desde el propio domicilio del paciente utilizando su
dispositivo habilitado y asignado para ello.
Para hacer uso de este recurso, el futuro cliente del sistema con el que se pretende facilitar
la realización y visualización de las distintas peticiones y respuestas, por parte de los
usuarios, debería realizar una petición HTTPS del tipo GET con las siguientes
particularidades:
Sistema para el seguimiento médico de pacientes
159
● Fijar la URL a la que se debe realizar la petición, siendo en este caso:
“https://192.168.100.51:8443/history/one”.
● Enviar en el cuerpo de la petición un objeto del tipo JSON con tres atributos con
los siguientes nombres: “idCitizen”, “historyDate” y “digitalSignature”.
Imagen 86. Cuerpo petición - HistoryController
Si los valores introducidos son correctos y se han encontrado resultados, el servidor
devolverá una petición como la que se muestra a continuación, donde como se puede ver,
aparecen todos los datos referentes a la entrada en el registro médico del paciente con DNI
74016303A realizadas el día 15 de Junio del 2021.
Ángel Pérez Arroyo
160
Imagen 87. Resultado petición - HistoryController
Sistema para el seguimiento médico de pacientes
161
4.7. Registro de Acceso (Access Register)
Dada la alta sensibilidad de los datos manejados por el sistema y sus usuarios, resulta
fundamental el dejar constancia de cualquier tipo de acción que ocurre en el sistema. Por
ello, ante cualquier petición REST disponible, incluye un procedimiento que deja
constancia de manera clara e inequívoca de la acción realizada por cada usuario.
Con esto se pretende poder determinar, por ejemplo, la intervención de cada usuario del
sistema en el expediente del paciente.
Por ello, y para facilitar el acceso a todo este tipo de información, se ha desarrollado un
controlador en específico que permite visualizar aquella información que se desee. En
particular este controlador incluye cuatro peticiones GET mediante las cuales se puede
desde visualizar toda la información de manera “bruta”, o realizar una serie de filtrados con
los que obtener de una manera más rápida la información deseada.
Imagen 88. AccessRegisterController
Por ello, en la presente demostración, se puede verificar cómo se puede conocer de forma
sencilla todas las entradas, lecturas y modificaciones que un sanitario ha realizado sobre el
historial médico de un paciente. Para ello, el cliente del sistema debería realizar una
petición con la siguiente estructura:
● Configurar el cliente para enviar una petición del tipo GET.
● Fijar la URL a la que se debe realizar la petición, siendo en este caso:
“https://192.168.100.51:8443/accessRegistry/byHealthPersonnelAndPatient”.
Ángel Pérez Arroyo
162
● Enviar en el cuerpo de la petición un objeto JSON con los siguientes campos:
“idCitizen”, “idSocialSecurity”, “idHealthPersonnel” y “digitalSignature”.
A modo de resumen, se incluye la imagen inferior, con un ejemplo realizado sobre este
mismo recurso utilizando el software Postman.
Imagen 89. Cuerpo petición - AccessRegistryController
Si la petición va como se espera de ella, el servidor devolverá un código 200 y un objeto
JSON con todos los datos encontrados que coinciden con los parámetros proporcionados,
tal y como se puede ver en la imagen inferior. En este caso se está buscando un paciente
con identificador de seguridad social “11111” y DNI 74016303A, que tenga algún registro
generado, generado, leído o modificado por el sanitario con ID 10, que produce la
respuesta mostrada en la imagen inferior, en la que se aprecia que existe al menos un
registro del historial generado (valor CREATED) por el sanitario con ID 10.
Sistema para el seguimiento médico de pacientes
163
Imagen 90. Resultado petición - AccessRegisterController
Ángel Pérez Arroyo
164
4.8. Auditoría (Audit)
Los usuarios administradores son una pieza fundamental en el correcto funcionamiento del
sistema, de ellos depende la aplicación de determinados procedimientos como los descritos
anteriormente, que por motivos de seguridad están restringidos a tan sólo usuarios con sus
privilegios. Además del registro de nuevos usuarios (sanitarios y otros administradores),
estos usuarios con un elevado número de privilegios tienen también disponibles acciones
como la generación o reemplazo de claves RSA o el bloqueo de ciertos usuarios, para
impedir el acceso al sistema a determinadas personas.
Por todo lo mencionado anteriormente y otras peticiones REST que tienen disponibles y no
han sido mencionadas, resulta crucial registrar las acciones que también llevan a cabo los
administradores. Para ello, se ha generado un nuevo controlador que permite mediante unas
simples peticiones HTTPS, visualizar estos datos.
Tal y como se puede ver en la imagen inferior, este controlador al igual que el expuesto
anteriormente está compuesto por cuatro peticiones, siendo todas ellas del tipo GET.
Además, de acuerdo con lo expuesto en la documentación realizada mediante el entorno
Swagger, se puede ver que el controlador puede devolver todos los registros realizados, los
realizados en un día determinado, los guardan relación con un paciente o bien, registros
producidos por las acciones de un administrador de sistemas en particular.
Imagen 91. AuditController
Sistema para el seguimiento médico de pacientes
165
Se va a proceder a exponer el correcto funcionamiento del controlador mediante el uso de
la petición API REST, que devuelve todos los registros en los que se ha visto relacionado
un paciente en particular.
Para realizar la petición se deberá configurar el cliente utilizado de la siguiente manera:
● Configurar el cliente para enviar una petición del tipo GET.
● Fijar la URL a la que se debe realizar la petición, siendo en este caso:
“https://192.168.100.51:8443/audit/byPatient”.
● Enviar en el cuerpo de la petición un objeto JSON con los siguientes campos:
“idCitizen”, “idSocialSecurity”, y “digitalSignature”. Siendo el último campo el
valor de la firma digital de los datos que van a ser enviados.
Imagen 92. Cuerpo petición - AuditController
Configurado el cliente con todos los datos correctamente, ya nos encontraremos en
disposición de realizar el envío de la petición, y de haber introducido todos los datos de
una manera correcta, el servidor devolverá un código 200 junto con un objeto JSON con
todos los datos solicitados. Un ejemplo de la respuesta generada por este método del
controlador AuditController, sería el expuesto en las siguientes imágenes.
Ángel Pérez Arroyo
166
Imagen 93. Resultado petición 1 - AuditController
Sistema para el seguimiento médico de pacientes
167
Imagen 94. Resultado petición 2 - AuditController
Ángel Pérez Arroyo
168
Como se puede ver en la respuesta generada por el servicio REST, se ha registrado que el
administrador de sistemas con identificador 1, ha procedido a leer un registro del historial
médico del paciente con DNI 74016303A. En concreto, el administrador ha accedido a los
datos del registro llevado a cabo el 15 de junio del 2021 a las 13:47:26 hora peninsular.
De esta manera, se puede ver claramente que el sistema deja siempre constancia de las
acciones realizadas por administradores de sistemas, pudiendo auditar en un futuro si algún
usuario ha llevado a cabo acciones perjudiciales contra el sistema o sus usuarios de manera
intencionada.
Sistema para el seguimiento médico de pacientes
169
4.9. Clave Pública-Privada (Private-Public Key)
Como se ha podido ir viendo a lo largo de los distintos ejemplos realizados durante el
presente apartado (Resultados), las peticiones que se envían al sistema requieren de una
firma digital. Dicha firma digital es necesaria para que el sistema pueda verificar los
siguientes aspectos fundamentales en cada petición que recibe:
1. Permite asegurar que la petición REST que el servidor ha recibido es idéntica a la
que el cliente envió desde el otro extremo de la comunicación.
2. Se puede comprobar si efectivamente la firma digital ha sido generada utilizando la
clave privada del mismo usuario propietario del JWT empleado para autenticarse
contra el servicio.
Como se puede ver, el procedimiento de generación y validación de firmas digitales se
trata de un proceso común y sumamente repetido, con el claro objetivo de dotar de una
mayor seguridad al sistema. Por ello, y dado que no se disponía de ningún cliente con el
que realizar las firmas digitales que el sistema debía validar, se decidió añadir un noveno
controlador, para calcular y validar las firmas digitales, antes de que estas fueran enviadas
junto con una petición de las expuestas anteriormente.
Este noveno y último controlador, ofrece dos recursos GET con los que calcular y verificar
una firma digital.
Imagen 95. Public and Private Key Manager Encription Controller
En esta ocasión y dada la alta importancia que ambos recursos han tenido durante el
desarrollo del servicio desarrollado, se va a exponer el funcionamiento de ambos.
En primer lugar, procederemos a analizar el funcionamiento del recurso que calcula una
firma digital. Como se ha indicado anteriormente, se trata de un recurso del tipo GET y que
requiere de un objeto JSON en el cuerpo de la petición. Este objeto debe tener como
Ángel Pérez Arroyo
170
mínimo un atributo que sea la clave privada a utilizar, junto con el resto de los atributos
que se quieran utilizar para calcular la firma digital utilizando el algoritmo RSA.
Tal y como se puede ver en la imagen inferior, se ha proporcionado la clave privada, junto
con un DNI y una fecha, para que estos dos últimos datos puedan ser utilizados para
calcular el resultado deseado. Cuando se envía la petición, el servidor responderá con un
código HTTP 200 y un objeto JSON con dos atributos (“result”, “error”).
Imagen 96. Cuerpo petición 1 - Public and Private Key Manager Encription Controller
Sistema para el seguimiento médico de pacientes
171
Imagen 97. Resultado petición 1 - Public and Private Key Manager Encription Controller
Una vez se dispone de la firma digital deseada, ya se puede utilizar para ser enviada junto a
alguna petición HTTPS de las analizadas anteriormente.
Expuesto el procedimiento anterior,se va a proceder a analizar el funcionamiento del
proceso que realiza el sistema para validar una firma digital.
Para validar una firma digital el sistema requiere de tres datos principales que son: clave
pública a emplear, firma digital a validar y un listado de los valores utilizados para calcular
dicha firma digital. Todos estos datos deben ser enviados en el cuerpo de la petición
haciendo uso de un objeto JSON como el mostrado en la imagen inferior.
Por último, una vez la petición ha sido verificada por el servidor, se devuelve nuevamente
un objeto JSON con los mismos atributos que en el caso anterior (“result”, “error”). Si la
firma se ha podido validar correctamente, como es el caso del ejemplo de la siguiente
imagen, el atributo “result” estará igualado a verdadero y no se mostrarán errores. Esto
querrá decir que la firma digital es correcta, y que fue generada utilizando la clave privada
asociada a la clave pública utilizada para esta verificación.
Ángel Pérez Arroyo
172
Imagen 98. Cuerpo petición 2 - Public and Private Key Manager Encription Controller
En cambio, si se vuelve a repetir pero alterando ligeramente la firma digital enviada, se
podrá comprobar cómo el resultado en esta ocasión cambia, y nos informa que no se ha
podido validar correctamente la firma digital, algo de esperar, ya que, el valor de la nueva
firma enviada es incorrecto.
Sistema para el seguimiento médico de pacientes
173
Imagen 99. Resultado petición 2 - Public and Private Key Manager Encription Controller
Ángel Pérez Arroyo
174
5. Conclusiones
En primer lugar, se procederá a analizar los resultados obtenidos al finalizar el presente proyecto de
final de máster en la Universidad de Alicante, explicando de manera detallada cada uno de los
principales objetivos que se querían alcanzar al inicio de este. Además, también se expondrán los
principales problemas o dificultades encontrados durante todo el desarrollo del proyecto.
Asimismo, se determinan las posibles líneas futuras a llevar a cabo en posteriores versiones del
sistema, pero antes de todo ello, aclarar que, para la realización del presente proyecto de final de
máster, todas las asignaturas cursadas durante el curso académico han contribuido en mayor o
menor medida a conseguir el objetivo propuesto al inicio, pero quizá las que han tenido una mayor
relevancia dada la temática del proyecto han sido:
○ Protección de la Información. Ha proporcionado los conocimientos necesarios para
manejar, tratar y procesar correctamente información cifrada.
○ Desarrollo de Aplicaciones Seguras. Ha establecido las bases para la realización de
un diseño y desarrollo de software seguros que permitan evitar la introducción de
vulnerabilidades durante el proyecto.
○ Seguridad en los Sistemas Operativos. Ha otorgado mayores conocimientos en lo
referente a la administración de servicios en entornos Linux, que han permitido
definir y configurar de manera adecuada la infraestructura levantada.
○ Seguridad en Aplicaciones y Bases de datos. Ha dotado de las técnicas de
desarrollo de software seguro, que evite la introducción de vulnerabilidades como
la inyección de código SQL.
○ Hacking Ético y Contramedidas. Ha demostrado la necesidad de aplicar medidas
de seguridad a nivel de infraestructura con el objetivo de dotar de una mayor
seguridad al sistema desarrollado.
Sistema para el seguimiento médico de pacientes
175
5.1. Análisis de los resultados obtenidos
El principal objetivo del proyecto era crear un sistema que permitiera al personal sanitario
(Médicos, Enfermeros, Trabajadores Sociales …) gestionar las distintas visitas, que
muchos de ellos deben realizar a pacientes que, por cualquier patología, les es imposible
desplazarse a su centro de salud más cercano.
Por ello, se propone un sistema informático que permita acceder de manera remota, desde
cualquier punto de la geografía española, a los datos de los pacientes. Todo ello, teniendo
siempre como una máxima la seguridad, dada la alta sensibilidad de los datos tratados por
el sistema. Por ese motivo, el sistema en todo momento garantiza la confidencialidad,
integridad y disponibilidad de los datos, con el objetivo de proporcionar un sistema robusto
y fiable, que permita tan sólo a los usuarios legítimos y autorizados del sistema conocer los
datos solicitados.
De esta manera, se pretende mejorar las condiciones de miles de sanitarios de toda España,
y a la vez disponer de un sistema más eficiente, tanto en el tratamiento de la información
como en el acceso a la misma, lo que puede repercutir en el sistema en general, en cuanto
se puede realizar un mejor uso de los medios disponibles en la actualidad.
Así, en el sistema médico desarrollado, los sanitarios autorizados podrán además de
acceder a los datos médicos de los pacientes, repercutiendo esto directamente en la calidad
de la atención, incluir nuevos registros en el historial médico del paciente al que acaban de
visitar, proporcionando mayor fiabilidad a la información que se transcribe, en cuanto
disminuye el riesgo de cometer errores y a la vez supone una mejora laboral, en cuanto
evita tener que volcar todos las anotaciones que se hayan realizado en cada uno de los
expedientes al final de la jornada laboral de un sanitario. Pero además permitiría un uso
más eficiente de los recursos en cuanto podrían evitarse segundas visitas o retrasos en las
ya previstas.
Para conseguir desarrollar el sistema necesario, se ha hecho uso de una infraestructura
basada en microservicios, y se ha logrado mediante el uso de 5 contenedores Docker con
distintos fines, tal y como se ha mencionado con un amplio grado de detalle en dicha
sección del documento. Gracias al uso de una arquitectura de microservicios junto con
Docker, se ha podido separar y aislar los cinco elementos fundamentales del sistema que
son: servicio de conexiones VPN (WireGuard), servicio de base de datos (MariaDB),
servidor de autenticación y autorización de usuarios (Keycloak), servicio de
monitorización del sistema (NetData) y el encargado de ejecutar los procesos asociados al
Ángel Pérez Arroyo
176
desarrollo REST realizado bajo Spring Boot (Alpine). Además, dada la naturaleza sensible
de los datos, toda comunicación incluida entre contenedores va debidamente cifrada
mediante el uso de certificados SSL, a la que se le añade una capa adicional para las
conexiones remotas al sistema. Así, las conexiones realizadas por los sanitarios
desplazados a los domicilios de los pacientes se realizan dentro de un túnel VPN con su
correspondiente capa de cifrado adicional.
Además, el sistema ha sido debidamente protegido mediante una configuración de Firewall
específica, que junto con una protección por software realizada en cada uno de los distintos
servicios que componen el sistema, permite garantizar la disponibilidad de los mismos tan
sólo a los usuarios autorizados. Para ello, se han definido dos subredes dentro de la
infraestructura utilizada, siendo una de ellas física, mientras que la otra es virtual, es decir,
los equipos físicos de la red hacen uso de la subred preexistente, mientras que, los
dispositivos remotos hacen uso de una subred distinta.
De esta manera, se puede realizar una configuración mucho más específica y sencilla,
evitando que, por ejemplo, los dispositivos remotos puedan acceder al servicio de
monitorización. De la misma manera, el servicio Keycloak tan sólo puede ser utilizado
administrado por los equipos de la red física, mientras que, los equipos de la red virtual
(conexiones VPN) tan sólo pueden realizar tareas de autenticación.
Todo el sistema junto con la infraestructura necesaria ha sido configurado desde cero, por
lo que, cada elemento ha sido cuidadosamente adaptado para una mayor seguridad.
También destacar el alto grado de optimización realizado sobre cada uno de los
componentes del sistema, ya que, aparte de verificar el correcto funcionamiento del mismo,
se ha obtenido una gran experiencia de usuario, algo especialmente destacable si se tiene
en cuenta que el servidor empleado ha sido una Raspberry Pi 4, que cuenta con una
potencia bastante limitada, y que el lenguaje de programación Java junto a Spring Boot no
ofrece el mismo rendimiento que aplicaciones similares desarrolladas en lenguajes como C
o C++.
Sistema para el seguimiento médico de pacientes
177
5.2. Problemas encontrados durante el desarrollo
Tal y como se ha venido exponiendo a lo largo del presente documento, el proyecto
desarrollado presenta una alta complejidad, al mismo tiempo que, se trata de un proyecto
vanguardista que viene a cubrir ciertas necesidades que determinados sanitarios a día de
hoy requieren. Todo ello, combinado con el uso de muchas y diferentes tecnologías, que
me eran totalmente desconocidas antes de iniciar el proyecto, han hecho que se haya
convertido en un estudio realmente laborioso al mismo tiempo que enriquecedor.
Como se puede deducir, se trata de un proyecto que ha requerido de una enorme lista de
tareas para el correcto desarrollo de cada uno de los elementos que constituyen el sistema.
Durante el tiempo de realización del presente trabajo, se han encontrado multitud de
problemas y dificultades, estando la mayoría de ellas relacionadas con una falta de
experiencia previa en las tecnologías utilizadas.
Se debe destacar la curva de aprendizaje requerida para poder aprovechar al máximo cada
una de las tecnologías empleadas, siendo bastante elevadas en algunos casos, como por
ejemplo con Spring. Es cierto que, el framework empleado ofrece multitud de ventajas a la
hora de desarrollar un proyecto de gran envergadura como el presente, ya que, dota de una
gran capa de abstracción, eliminando y reduciendo de manera considerable problemas
comunes durante cualquier desarrollo software. Esto al mismo tiempo es un “arma de
doble filo”, ya que, un grado tan alto de abstracción implica conocer muy bien el
funcionamiento interno del framework utilizado, si se desea entender con detalle el
comportamiento del sistema (“under the hood”). Por lo tanto, comenzar a utilizar un
framework nuevo como Spring, da lugar a situaciones en las que no se sepa entender el
origen de un error o problema encontrado. A todo lo mencionado anteriormente, se debe
tener en cuenta que no sólo se ha utilizado la base del proyecto Spring, sino también
algunos de sus subproyectos como Spring Boot o Spring Security, lo que ha llevado a que
el aprendizaje haya sido muy prolijo.
Un gran problema encontrado ha sido la necesidad de levantar y configurar desde cero la
infraestructura necesaria para una correcta ejecución del sistema, si bien es cierto que es
algo que se había venido practicando durante el grado de Ingeniería Informática y en el
presente máster, nunca me había visto en la necesidad de enfrentarme a una situación real,
que siempre presenta retos nuevos que un entorno más limitado como puede ser una
práctica de la Universidad.
Ángel Pérez Arroyo
178
Otro gran reto ha sido el planificar y diseñar todas las capas de seguridad que el sistema
incluye, con las que se espera que el sistema sea lo más robusto y fiable posible. Se debe
recordar que el sistema incluye una estrategia en profundidad, en la que se han aplicado
diversas capas de seguridad en cada uno de los elementos, tanto a nivel de infraestructura
como software. Por ejemplo, a nivel de seguridad perimetral existe una configuración de
cortafuegos específicamente desarrollada para suplir tan sólo los requerimientos del
sistema y ninguno más, limitando así el rango de ataque de un ciberdelincuente. Asimismo,
tal y como se ha venido destacando hasta el momento cualquier comunicación, por muy
segura que se considere, al viajar dentro de la misma red, se vuelve en cierto modo
vulnerable, por lo que siempre viaja cifrada. Y en cambio, la información que va a circular
por fuera de la red privada recibe una capa adicional de cifrado (VPN).
Por último, y para concluir con el presente subapartado, destacar el esfuerzo que ha
supuesto trabajar con unos recursos tan limitados, como una Raspberry Pi, teniendo en
cuenta la elevada cantidad de procesos llevados a cabo de manera simultánea por el equipo.
Sistema para el seguimiento médico de pacientes
179
5.3. Posibles líneas futuras
Uno de los factores más determinantes para que un sistema sea atractivo para su uso en un
entorno real como el propuesto, es que además de ser seguro y robusto, también sea
práctico, porque de nada sirve que un sistema sea hiper seguro si su uso es extremadamente
difícil, ya que, se convertiría al instante en un sistema prácticamente inútil.
Por ello, a continuación, se propone un pequeño listado con algunas líneas futuras que se
podrían llevar a cabo con el objetivo de mejorar aún más el sistema:
1. Desplegar el sistema en una infraestructura en la nube, lo que proveería al sistema
de manera casi automática de ciertos elementos de seguridad adicionales, como
protección ante ataques de denegación de servicio, contra los que el sistema actual
no dispone de elementos extremadamente robustos.
2. Al desplegar el sistema en un entorno cloud, se podría hacer uso de más recursos
hardware cuando estos fueran necesarios, es decir, se podría hacer uso de un
cluster dinámico13 con balanceo de carga, permitiendo al sistema una mejor
estabilidad y escalabilidad.
3. Haciendo uso de una mejor infraestructura, también se podría disponer de un o
múltiples WAF (Web Application Firewall) con los que asegurar en mejor medida
las distintas conexiones que el servidor recibe.
4. Uso de tecnologías como Kubernetes con las que también ajustar de manera
dinámica el uso de contenedores necesarios para satisfacer la demanda en cada
momento.
5. A medida que crezca el sistema, podría resultar que un modelo de base de datos
SQL llegara a ser contraproducente en términos de rendimiento. Por ello, la
migración a modelos de datos NoSQL a través de gestores de bases de datos como
MongoDB, podría ser una actualización a tener en cuenta.
6. Modificar el sistema de autenticación a un sistema mediante datos biométricos
como huella dactilar. Otro mecanismo perfectamente válido sería una correcta
implementación mediante reconocimiento facial, que además de acelerar el
proceso de autenticación lo convertiría en mucho más fiable.
13 Ver en el glosario
Ángel Pérez Arroyo
180
6. Referencias
[1] JETBRAINS, «Jetbrains.com,» [En línea]. Available: https://www.jetbrains.com/es-es/idea/.
[2] Oracle, «Oracle.com,» [En línea]. Available:
https://www.oracle.com/es/java/technologies/javase/javase-jdk8-downloads.html.
[3] J. v. Zyl, «Wikipedia.com,» 14 Junio 2021. [En línea]. Available:
https://es.wikipedia.org/wiki/Maven.
[4] A. Becker, «Wikipedia.com,» 31 Julio 2021. [En línea]. Available:
https://es.wikipedia.org/wiki/HeidiSQL.
[5] Postman, Inc., «Postman.com,» [En línea]. Available: https://www.postman.com/.
[6] «Wikipedia.com,» 15 Julio 2021. [En línea]. Available: https://es.wikipedia.org/wiki/GitHub.
[7] Microsoft, «Microsoft.com,» [En línea]. Available: https://www.microsoft.com/es-
ww/microsoft-365/visio/flowchart-software.
[8] Spring, «Spring.io,» [En línea]. Available: https://spring.io/why-spring.
[9] SpringSource, «Wikipedia,» 11 Agosto 2021. [En línea]. Available:
https://es.wikipedia.org/wiki/Spring_Framework.
[10] «Wikipedia.com,» 13 Junio 2021. [En línea]. Available:
https://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_aspectos.
[11] «Wikipedia.com,» 17 Junio 2021. [En línea]. Available:
https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador.
[12] «Wikipedia.com,» 26 Mayo 2021. [En línea]. Available:
https://es.wikipedia.org/wiki/Pruebas_de_software.
[13] «Spring.io,» [En línea]. Available: https://spring.io/projects/spring-boot.
[14] «Spring.io,» [En línea]. Available: https://spring.io/projects/spring-data.
Sistema para el seguimiento médico de pacientes
181
[15] «Spring.io,» [En línea]. Available: https://spring.io/guides/topicals/spring-security-
architecture/.
[16] «Wikipedia.com,» 30 Octubre 2020. [En línea]. Available:
https://es.wikipedia.org/wiki/HATEOAS.
[17] «Ionos.es,» [En línea]. Available: https://www.ionos.es/digitalguide/paginas-web/desarrollo-
web/hateoas-que-es-y-cual-es-su-funcion-en-las-api-rest/.
[18] «Digicert.com,» [En línea]. Available: https://www.digicert.com/es/ssl-certificate/.
[19] «Tutorialsmate.com,» [En línea]. Available: https://www.tutorialsmate.com/2020/07/http-vs-
https.html.
[20] «Wikipedia.com,» 19 Agosto 2021. [En línea]. Available:
https://es.wikipedia.org/wiki/RSA#:~:text=Las%20claves%20RSA%20son%20normalmente,
el%20algoritmo%20RSA%20es%20seguro..
[21] P. d. l. I. -. A. M. C. U. d. Alicante, 2021.
[22] «JWT.io,» [En línea]. Available: https://jwt.io/introduction.
[23] «Openid.net,» [En línea]. Available: https://openid.net/connect/.
[24] «Wikipedia.com,» [En línea]. Available: https://es.wikipedia.org/wiki/OpenID.
[25] «OAuth.net,» [En línea]. Available: https://oauth.net/2/.
[26] «Okta.com,» [En línea]. Available: https://developer.okta.com/blog/2018/06/29/what-is-the-
oauth2-password-grant.
[27] «Openwebinars.net,» [En línea]. Available: https://openwebinars.net/blog/que-es-oauth2/.
[28] «Dockerlabs.collabnix.com,» [En línea]. Available:
https://dockerlabs.collabnix.com/beginners/docker/docker-vs-container.html.
[29] «Redhat.com,» [En línea]. Available: https://www.redhat.com/es/topics/containers/what-is-
docker.
[30] «Wireguard.com,» [En línea]. Available: https://www.wireguard.com/.
Ángel Pérez Arroyo
182
[31] «Keycloak.org,» [En línea]. Available: https://www.keycloak.org/.
[32] «Mariadb.com,» [En línea]. Available: https://mariadb.com/.
[33] «Alpinelinux.org,» [En línea]. Available: https://alpinelinux.org/.
[34] «Netdata.cloud,» [En línea]. Available: https://www.netdata.cloud/.
[35] «Wikipedia.org,» 7 Junio 2021. [En línea]. Available:
https://es.wikipedia.org/wiki/Secure_Shell.
[36] «Wikipedia,» 2020 Enero 13. [En línea]. Available:
https://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_aspectos.
Sistema para el seguimiento médico de pacientes
183
7. Glosario
● Framework. Hace referencia al entorno de trabajo o marco de trabajo con una serie de
conceptos, prácticas y criterios estandarizados con el objetivo de enfocar de una mejor
manera una determinada problemática.
● Inversión de control. Se trata de un principio de diseño de software por el que, el flujo de
ejecución de un programa se invierte con respecto a un programa desarrollado con
metodologías tradicionales. Tradicionalmente, el desarrollador de un programa especifica
una serie de órdenes o acciones que se deben ejecutar por el programa, pero en un
programa con inversión de control, se especifican directamente las respuestas deseadas
para un suceso o solicitudes de datos concretos. De esta manera, el desarrollador deja toda
la responsabilidad a una entidad externa, obteniendo un mayor grado de abstracción.
● POJO. Hace referencia a clases de Java simples y que no son dependientes de ningún
framework. Un objeto de una clase POJO es una instancia que no extiende ni implementa
nada especial. Un ejemplo de esto puede ser una clase básica de Java que busque reflejar
por ejemplo las características de un animal o persona.
● SPI. Se trata de una API destinada a ser implementada o ampliada por una persona externa.
Por lo tanto, puede ser utilizada tanto para habilitar como reemplazar componentes y
extensiones de un framework.
Para el caso de Java, los SPIs son utilizados en las siguientes interfaces:
● Java Database Connectivity
● Java Cryptography Extension
● Java Naming and Directory Interface
● Java API for XML Processing
● Java Business Integration
● Java Sound
● Java Image I/O
● Java File Systems
● Número coprimo. Hace referencia a dos números primos entre sí, es decir, dos números
enteros a y b que tienen como máximo común divisor (MCD) al número 1.
Ángel Pérez Arroyo
184
● Registradas. Conjunto de declaraciones predefinidas que no es de uso obligatorio, aunque
sí muy recomendable. Ejemplos: iss (issuer), exp (expiration time), sub (subject) o aud
(audience).
● Públicas. Pueden ser definidos por el propio desarrollador, aunque para evitar colisiones
con otros proyectos se deben registrar en el registro de IANA.
● Privadas. Son declaraciones personalizadas que pueden ser utilizadas para compartir
información entre las partes que acuerden su utilización.
● URL. Uniform Resource Locator. Traducción al castellano: Localizador de Recursos
Uniforme.
● XRI. eXtensible Resource Identifier. Se trata de un nuevo sistema de identificación
diseñado específicamente para ser utilizado en Internet. En particular, se encuentra
enfocado al uso de identidades digitales bajo dominios cruzados. Los XRIs se presentan de
dos maneras: números y nombres. Habitualmente estos datos se encuentran registrados
para poder ser utilizados de manera equivalente los unos por los otros.
● Clúster dinámico. Se trata de un conjunto de servidores que hacen uso de gestores de
carga de trabajo. De esta manera, se pueden equilibrar las cargas del sistema, permitiendo
reducir y aumentar de manera dinámica los recursos del cluster. Es decir, en momentos
puntuales de alta carga el clúster podría crecer para soportar el aumento de la demanda,
mientras que, en momentos de baja carga se puede reducir los recursos disponibles. Esto
permite hacer una mejor optimización del hardware, ya que, en entornos cloud existen
multitud de sistemas que comparten continuamente los mismos recursos físicos.
● Controlador. Método o función del código fuente que se encarga de manejar y gestionar la
lógica de negocio que se debe aplicar, en función de la petición HTTP que un cliente
realiza sobre el sistema.
Top Related