Almacenamiento de datos clínicos en la nube: seguridad y riesgos

El centro sanitario deja de administrar directamente parte del hardware, la climatización o la capacidad de almacenamiento, pero mantiene la obligación de garantizar confidencialidad, integridad, disponibilidad y trazabilidad.

El problema no es únicamente dónde se ubica el servidor. La seguridad en la nube depende también de quién controla las claves de cifrado, qué región procesa las identidades, qué subcontratistas intervienen y cómo se recupera la información después de un incidente. Un proveedor puede alojar físicamente los datos en la Unión Europea y, aun así, depender de servicios de autenticación o gestión operativa situados fuera de ella.

En España, los datos relativos a la salud pertenecen a una categoría especial según el artículo 9 del Reglamento General de Protección de Datos (RGPD). El margen de error es reducido. Una mala configuración de permisos, una cadena de subcontratación opaca o una copia de seguridad inutilizable pueden convertirse en un incumplimiento normativo y en una interrupción asistencial.

El marco normativo: RGPD y Esquema Nacional de Seguridad

El RGPD no prohíbe el uso de servicios en la nube para gestionar historiales clínicos electrónicos. Exige que el tratamiento tenga una base jurídica válida, que exista una finalidad definida y que se apliquen garantías técnicas y organizativas proporcionales al riesgo.

La historia clínica contiene información especialmente sensible. El proveedor tecnológico no puede tratarla como un conjunto genérico de documentos. El diseño debe contemplar, como mínimo:

• Control individualizado de identidades y permisos.
• Cifrado de la información durante la transmisión y el almacenamiento.
• Registro de accesos, modificaciones, exportaciones y eliminaciones.
• Separación entre entornos de producción, pruebas y desarrollo.
• Copias de seguridad protegidas frente al borrado y el cifrado malicioso.
• Procedimientos documentados de recuperación ante incidentes.
• Evaluación de impacto relativa a la protección de datos cuando el tratamiento lo requiera.

La Evaluación de Impacto relativa a la Protección de Datos (EIPD) no debe convertirse en un documento administrativo desconectado de la arquitectura. Debe describir los flujos reales. Si la aplicación clínica utiliza un sistema de autenticación externo, una plataforma de analítica o un servicio de soporte remoto, cada componente forma parte de la superficie de riesgo.

El Esquema Nacional de Seguridad, regulado por el Real Decreto 311/2022, es obligatorio para los hospitales públicos. También afecta a clínicas concertadas y proveedores de software como servicio que prestan servicios o suministran soluciones al sector público sanitario. Por tanto, una plataforma hospitalaria no se evalúa únicamente por sus funciones clínicas. También se examinan sus medidas de seguridad, gestión de incidentes, continuidad y control de proveedores.

El RGPD establece sanciones de hasta 20 millones de euros o el 4 % de la facturación global anual para infracciones de especial gravedad. La Directiva NIS2 contempla sanciones administrativas de hasta 10 millones de euros o el 2 % del volumen de negocio anual en determinados supuestos. La cifra no debe utilizarse como argumento comercial. Sirve para dimensionar el riesgo de una decisión técnica sin gobierno.

La nube no transfiere la responsabilidad. Transfiere parte de la operación y amplía la cadena que debe ser controlada.

Soberanía operativa: el servidor europeo no basta

La protección de datos médicos en servidores ubicados en la Unión Europea suele presentarse como una garantía suficiente. No lo es. La localización física es solo una variable de la arquitectura.

La soberanía operativa depende de varios elementos:

1. Región de almacenamiento. Determina dónde residen los datos principales y las réplicas.

2. Región de procesamiento. Una función de análisis, indexación o soporte puede tratar información fuera de la ubicación declarada.

3. Gestión de identidades. El proveedor de identidad puede operar en otra jurisdicción y conservar metadatos de autenticación.

4. Gestión de claves. Las claves pueden estar bajo control del cliente, del proveedor o de un tercero especializado.

5. Acceso de soporte. Los técnicos pueden acceder de forma remota desde países distintos al de alojamiento.

6. Subcontratación. Un proveedor principal puede utilizar servicios adicionales para copias, monitorización, seguridad o atención técnica.

7. Continuidad. La recuperación ante desastre puede depender de una región secundaria situada fuera de la Unión Europea.

La Agencia Española de Protección de Datos ha advertido de que el alojamiento en servidores europeos no garantiza por sí solo la resiliencia si la gestión de recursos, claves de cifrado o servicios de autenticación depende de regiones o infraestructuras de terceros países.

Este punto afecta de forma directa al cifrado de historiales clínicos electrónicos. Si el proveedor administra todas las claves, el hospital puede disponer de cifrado técnico sin tener control efectivo sobre la capacidad de descifrado. Si la clave se expone durante una operación de soporte, la ubicación del fichero deja de ser la principal preocupación.

Arquitectura de cifrado y control de claves

El cifrado debe analizarse en dos estados:

• En tránsito: protege la comunicación entre estaciones clínicas, aplicaciones, interfaces de interoperabilidad y almacenamiento.
• En reposo: protege bases de datos, volúmenes, copias de seguridad y objetos almacenados.

El cifrado de extremo a extremo aporta una protección adicional cuando el diseño impide que intermediarios no autorizados accedan al contenido durante el flujo. Sin embargo, no soluciona una mala gestión de identidades. Un usuario con permisos excesivos puede consultar datos ya descifrados desde una aplicación legítima.

La gestión de claves requiere rotación, segregación de funciones, registro de operaciones y procedimiento de revocación. También debe contemplar la recuperación. Una política que impide al proveedor leer los datos puede ser técnicamente sólida, pero si el hospital pierde las claves y no existe una copia protegida, la disponibilidad clínica queda comprometida.

Por esa razón, la revisión debe incluir preguntas operativas concretas:

• ¿Quién genera las claves?
• ¿Quién puede utilizarlas?
• ¿Dónde se almacenan?
• ¿Cómo se rotan?
• ¿Qué ocurre si se revoca una clave durante una incidencia?
• ¿Existe una copia de recuperación separada del entorno principal?
• ¿El proveedor puede acceder al contenido durante el soporte?
• ¿Queda constancia de cada operación criptográfica?

Una respuesta genérica del proveedor no permite evaluar la seguridad. La evidencia debe estar en la documentación contractual, la configuración y los registros.

La cadena de suministro y la subcontratación del software clínico

La gestión segura de información del paciente rara vez depende de una sola empresa. Un hospital puede contratar una plataforma de historial clínico electrónico y, detrás, existir una cadena de servicios de infraestructura, almacenamiento, copias de seguridad, monitorización, soporte, mensajería o analítica.

El artículo 28 del RGPD obliga a regular la relación con los encargados del tratamiento. La organización sanitaria debe conocer quién trata los datos, con qué finalidad, durante cuánto tiempo y bajo qué instrucciones. La subcontratación no puede quedar oculta detrás de una cláusula amplia que permita incorporar proveedores sin control operativo.

La Agencia Española de Protección de Datos ha sancionado a centros hospitalarios por omitir la notificación previa y el consentimiento formal sobre empresas subcontratadas para el tratamiento de datos en soluciones de software de terceros. La existencia de un contrato con el proveedor principal no elimina la necesidad de gobernar la cadena.

Una evaluación práctica debe separar tres niveles:

El contrato debe definir también el fin de la relación. La eliminación de una cuenta no demuestra que se hayan eliminado todas las copias. El proveedor debe describir el tratamiento de réplicas, copias de seguridad, registros y soportes retirados.

Interoperabilidad sin ampliar el perímetro sin control

La interoperabilidad médica añade valor clínico, pero también multiplica los puntos de intercambio. Un sistema hospitalario puede conectarse con laboratorios, radiología, receta electrónica, facturación, portales del paciente y plataformas regionales.

Cada interfaz debe tener una finalidad y un propietario. Una conexión permanente con permisos amplios es difícil de auditar. Una interfaz con alcance limitado y autenticación fuerte permite reducir la exposición.

La revisión técnica debe cubrir:

• Identificación de cada sistema que envía o recibe información.
• Formato y contenido de los mensajes.
• Frecuencia de intercambio.
• Mecanismo de autenticación.
• Cifrado de la conexión.
• Gestión de errores y reintentos.
• Registro de consultas y transferencias.
• Revocación de credenciales.
• Conservación y eliminación de mensajes temporales.

El riesgo no se limita a los datos clínicos. Los metadatos también pueden revelar identidad, actividad asistencial, horarios, centros de atención o relaciones entre profesionales y pacientes. Una arquitectura de interoperabilidad madura registra esos movimientos y evita que las interfaces se conviertan en canales invisibles.

Ransomware, disponibilidad y continuidad asistencial

El ransomware no afecta únicamente a la confidencialidad. Su impacto más inmediato suele producirse sobre la disponibilidad. Si el hospital no puede consultar el historial, validar una medicación o recuperar resultados diagnósticos, la atención se ralentiza y aumenta la dependencia de procedimientos manuales.

El artículo 32 del RGPD exige medidas adecuadas para garantizar la seguridad del tratamiento. Entre ellas se encuentran la capacidad de asegurar la confidencialidad, integridad, disponibilidad y resiliencia permanentes, además de la restauración de la disponibilidad tras un incidente.

La copia de seguridad solo cumple su función si puede restaurarse. Un repositorio conectado permanentemente al entorno de producción puede ser cifrado por el mismo atacante. La arquitectura debe contemplar separación lógica o física, credenciales independientes, control de borrado y pruebas periódicas de recuperación.

El proceso de continuidad debe establecer una secuencia operativa:

1. Detectar el incidente. El sistema debe identificar cifrado anómalo, accesos masivos, extracción de datos o cambios inusuales.

2. Aislar los recursos afectados. La contención debe evitar que el ataque se extienda a otras redes, cuentas o regiones.

3. Preservar evidencias. Los registros no deben modificarse durante la respuesta.

4. Determinar el alcance. Hay que diferenciar indisponibilidad, acceso no autorizado y exfiltración.

5. Activar el procedimiento asistencial alternativo. El personal necesita instrucciones para trabajar sin el sistema principal.

6. Restaurar por fases. La recuperación debe comenzar por los servicios clínicos prioritarios.

7. Notificar cuando proceda. Las brechas de seguridad con datos personales deben notificarse a la AEPD en un plazo máximo de 72 horas cuando exista obligación de hacerlo.

8. Revisar la causa raíz. La restauración no cierra el incidente si la vulnerabilidad permanece.

La prueba de recuperación debe medir tiempos reales. No basta con comprobar que existe una copia. El hospital debe conocer cuánto tarda en recuperar el historial, qué información queda disponible, qué dependencias externas son necesarias y qué operaciones no pueden ejecutarse durante la interrupción.

La escalabilidad también debe evaluarse desde la continuidad. Un sistema puede soportar el volumen normal y fallar durante una recuperación masiva. La latencia de acceso, el ancho de banda de restauración y la capacidad de procesamiento de la base de datos condicionan la vuelta a la actividad.

Gestión de accesos al historial clínico

El control de acceso es uno de los puntos más sensibles del software hospitalario. No todos los usuarios necesitan consultar la misma información. El personal de urgencias, enfermería, laboratorio, administración y soporte técnico trabaja con funciones distintas.

El modelo debe aplicar el principio de mínimo privilegio. La autorización debe depender del rol, la unidad, la relación asistencial y la operación solicitada. Consultar un resultado no equivale a exportar un historial completo. Administrar usuarios no equivale a leer datos clínicos.

La identificación multifactor debe reservarse, como mínimo, para perfiles privilegiados, accesos remotos y operaciones de alto impacto. Las cuentas compartidas deben evitarse. Si varias personas utilizan la misma credencial, la trazabilidad desaparece.

Los registros deben permitir reconstruir:

• Quién accedió.
• A qué paciente accedió.
• Qué información consultó o modificó.
• Desde qué dispositivo o red.
• En qué fecha y hora.
• Qué operación ejecutó.
• Si exportó, imprimió o compartió información.

La identificación individualizada de los profesionales sanitarios que acceden al historial no constituye, según la doctrina recogida en la Sentencia 789/2026 del Tribunal Supremo, un requisito general del derecho de acceso cuando actúan dentro de la organización. La situación cambia si existen indicios de accesos irregulares o no autorizados.

La distinción es relevante. El derecho de acceso del paciente no implica necesariamente revelar de forma general la identidad de cada profesional que intervino en su atención. Pero el hospital sí debe mantener registros internos suficientes para investigar accesos sospechosos y responder ante una incidencia.

Un sistema de auditoría eficaz no almacena registros sin análisis. Debe generar alertas sobre patrones anómalos:

• Consulta de un volumen inusual de historiales.
• Acceso fuera del horario o de la unidad habitual.
• Descarga masiva.
• Consulta de pacientes sin relación asistencial.
• Uso repetido de cuentas privilegiadas.
• Accesos desde ubicaciones incompatibles con la jornada.
• Cambios de permisos sin una solicitud registrada.

La latencia de la detección también importa. Un registro revisado meses después tiene valor forense, pero poca capacidad preventiva. Las alertas de mayor riesgo deben llegar al equipo responsable en un plazo operativo definido.

Cómo evaluar una plataforma antes de migrar los datos

La migración a la nube no debe comenzar con el traslado de ficheros. Debe comenzar con un inventario de información, dependencias y permisos. El hospital necesita saber qué datos conserva, quién los utiliza, qué interfaces los intercambian y qué servicios son críticos.

El proceso puede organizarse en cinco fases:

1. Clasificación de la información

Se separan historiales, imágenes, informes, datos administrativos, registros de auditoría, copias y datos temporales. Cada categoría puede tener requisitos distintos de retención, cifrado y acceso.

2. Mapa de flujos

Se documenta el recorrido desde la captura hasta el almacenamiento, la consulta, la copia y la eliminación. El mapa debe incluir servicios externos y subencargados.

3. Evaluación de arquitectura

Se revisan regiones, centros de datos, redundancia, claves, identidad, redes, interfaces y mecanismos de recuperación. La documentación comercial no sustituye a los diagramas técnicos ni a las pruebas.

4. Validación contractual

El contrato debe establecer instrucciones, subcontratación, incidentes, auditoría, devolución, eliminación y asistencia durante la recuperación. También debe reflejar el papel de cada entidad en el tratamiento.

5. Prueba controlada

La migración debe comenzar con un entorno limitado y datos adecuadamente protegidos. Se miden latencia, integridad, disponibilidad, rendimiento de las interfaces y comportamiento de los permisos. Después se ejecuta una prueba de restauración.

La optimización no consiste en trasladar toda la carga al proveedor con mayor capacidad. Consiste en asignar cada función al nivel adecuado de control. Una base de datos clínica, el archivo de imágenes, el sistema de copias y el servicio de analítica pueden requerir configuraciones distintas.

El criterio final debe ser operativo. Si el hospital no puede explicar cómo aislar una cuenta, recuperar una copia, revocar una clave, identificar un subencargado o mantener la actividad asistencial durante una caída, la arquitectura todavía no está preparada.

Conclusión: seguridad medible, no ubicación declarada

El almacenamiento de datos clínicos en la nube puede mejorar la escalabilidad, reducir la dependencia de centros locales y simplificar determinadas tareas de administración. También puede ampliar el perímetro de ataque y hacer menos visible la cadena de tratamiento.

La seguridad en la nube debe evaluarse mediante controles verificables: cifrado, gestión de claves, latencia de detección, capacidad de restauración, segregación de permisos, trazabilidad, interoperabilidad y gobierno de subcontratistas. La ubicación europea del servidor ayuda, pero no resuelve por sí sola la soberanía operativa ni el cumplimiento del RGPD.

El criterio de aceptación es directo. El hospital debe conservar el control sobre quién accede, qué se procesa, dónde se replica, cómo se recupera y qué ocurre cuando un proveedor falla. Si esas respuestas dependen de promesas comerciales o de documentación incompleta, existe un riesgo técnico pendiente de resolver.