Seguridad de datos en clínicas: dónde viven y quién accede

Casi todas las clínicas creen que la seguridad de sus datos es un problema del proveedor del software de gestión. Es una suposición cómoda y es falsa: ante la Agencia Española de Protección de Datos, la clínica es la responsable del tratamiento. El proveedor es encargado. Cuando hay una brecha, quien tiene que notificarla en 72 horas, quien responde ante el paciente y quien aparece en la resolución sancionadora es la clínica.

Y la brecha casi nunca entra por donde se espera. No es un hacker rompiendo el cifrado del historial: es un ecógrafo con un Windows sin actualizar colgado de la misma red que el mostrador, un backup que nadie ha restaurado nunca, o una cuenta compartida que usan seis personas del turno de mañana. En este artículo contamos dónde viven de verdad los datos clínicos, por dónde se rompen y cómo se diseña una infraestructura que aguante.

Qué significa realmente proteger datos clínicos

El dato de salud no es un dato personal más. El RGPD lo clasifica en su artículo 9 como categoría especial: su tratamiento está prohibido por defecto y solo se permite bajo excepciones tasadas, entre ellas la asistencia sanitaria, y siempre sujeto a secreto profesional. En la práctica esto significa que el listón de medidas técnicas es más alto que para un CRM comercial cualquiera, y que una brecha aquí no se valora igual.

A eso se suman capas que mucha clínica descubre tarde. La Ley 41/2002 obliga a conservar la documentación clínica un mínimo de cinco años desde el alta, y varias comunidades autónomas amplían ese plazo: no es un dato que puedas borrar cuando te venga bien, y eso condiciona la política de retención y los backups. La directiva NIS2 sitúa la sanidad entre los sectores esenciales, con obligaciones de gestión de riesgo y notificación de incidentes. Y si prestas servicio concertado con la administración, el Esquema Nacional de Seguridad puede alcanzarte a través del contrato aunque seas una entidad privada.

Nada de esto se resuelve con una casilla ni con un certificado colgado en recepción. Se resuelve con arquitectura.

Escenarios reales que nos encontramos

La red plana: el ecógrafo, el wifi de pacientes y la gestión en el mismo sitio

Es el patrón que más se repite en entornos sanitarios y el más peligroso. La clínica creció por acumulación: se puso el software de gestión, luego llegó el equipo de imagen, después el wifi para la sala de espera, más tarde el sistema de citas. Todo colgando de la misma red, porque cada cosa se instaló en su momento y funcionaba.

El problema es que los equipos médicos —el PACS, el ecógrafo, el TAC— suelen correr sobre sistemas operativos antiguos que el fabricante no deja actualizar sin invalidar la certificación del equipo. Son máquinas que no puedes parchear y que van a seguir ahí cinco o diez años. En una red plana, ese equipo sin parchear está a un salto del servidor donde vive la historia clínica, y el portátil de un paciente conectado al wifi de la sala de espera está en ese mismo segmento.

La solución no es cambiar el ecógrafo. Es asumir que ese equipo es inseguro por diseño y aislarlo para que su compromiso no signifique nada.

“Está en la nube”, pero nadie sabe en qué país

Cuando preguntamos dónde se almacenan los datos clínicos, la respuesta habitual es “en la nube, lo lleva el proveedor”. Esa frase no dice nada. La nube no es un sitio: es el centro de datos de alguien, en una región concreta, bajo un contrato concreto.

Las preguntas que hay que poder responder son cuatro, y conviene tenerlas por escrito: en qué región se almacena y se procesa el dato, si hay subencargados y quiénes son, qué política de retención y borrado aplica el proveedor cuando termine el contrato, y si existe un contrato de encargo del tratamiento firmado que cubra todo lo anterior. Si tu proveedor de software clínico no te da esas cuatro respuestas por escrito, no tienes un problema técnico: tienes un problema de cumplimiento que ya está en marcha.

Ojo con un matiz que se pasa por alto: un proveedor puede almacenar en la UE y aun así dar soporte desde fuera con acceso remoto a los datos. Ese acceso también es una transferencia y también tiene que estar contemplada.

Un usuario compartido para todo el mostrador

El clásico. Un solo usuario para el turno, porque “así es más ágil”. Funciona hasta el día en que hay que responder quién consultó la historia de un paciente concreto un martes por la tarde, y la respuesta es “recepción”.

La trazabilidad no es burocracia: en datos de categoría especial, poder demostrar quién accedió a qué y cuándo es parte de la medida de seguridad, no un extra. Sin identidad individual no hay registro de acceso que valga, y sin registro de acceso no hay forma de acotar el alcance de una brecha ni de demostrar diligencia ante la autoridad.

El backup que nunca se ha restaurado

La sanidad es un objetivo predilecto del ransomware por una razón muy simple: es un sector donde la indisponibilidad tiene coste clínico inmediato, y eso presiona a pagar. La clínica que se encuentra el cifrado un lunes por la mañana descubre dos cosas a la vez: que sí tenía backups, y que nadie los había restaurado nunca.

Y hay un detalle que decide el desenlace. Si el backup está montado como una unidad de red accesible desde el mismo servidor que se ha comprometido, el ransomware también lo cifra. Un backup que el atacante puede alcanzar no es un backup: es una copia más del problema.

Cómo lo abordamos

Primero el inventario del dato, después la arquitectura

Antes de tocar red o servidores, mapeamos qué datos existen, dónde viven, quién los toca y cuánto tiempo hay que conservarlos. Casi siempre aparecen sitios que nadie tenía en la cabeza: un Excel de listas de espera en el escritorio de alguien, exportaciones para la gestoría, imágenes en el disco local del equipo de diagnóstico. No se puede proteger lo que no se sabe que existe, y ese inventario es también la base del registro de actividades de tratamiento que el RGPD exige.

Segmentar por función, no por planta

Separamos la red en segmentos con una lógica de riesgo: dispositivos médicos que no se pueden parchear, puestos de trabajo, wifi de invitados, servidores. Entre segmentos no se permite tráfico salvo lo que hace falta de verdad, declarado puerto a puerto —el flujo DICOM entre el equipo de imagen y el PACS, y poco más—. El wifi de pacientes sale a internet y no ve nada interno. El equipo médico viejo sigue siendo viejo, pero deja de ser una puerta.

Cifrado en tránsito y en reposo, y secretos fuera del código

Cifrado en tránsito para todo, cifrado en reposo en discos y backups, y las claves gestionadas en un servicio de secretos (Vault, KMS) con rotación y auditoría de uso, nunca en un fichero de configuración ni en una variable de entorno plana. El cifrado en reposo no protege de un usuario legítimo comprometido, pero convierte el robo de un disco o de una copia en un incidente sin datos expuestos, que es una conversación muy distinta con la autoridad de control.

Identidad individual, mínimo privilegio y trazabilidad

Un usuario por persona, segundo factor para los accesos administrativos y remotos, y permisos por rol: recepción no necesita ver el contenido clínico para gestionar una cita. Encima, registro inmutable de accesos —quién, qué historia, cuándo— guardado fuera del alcance del propio sistema, de forma que quien comprometa el servidor no pueda borrar el rastro de lo que hizo.

Backups aislados y un DR que se ensaya

Regla simple y no negociable: al menos una copia fuera del alcance del sistema que protege, inmutable o con retención bloqueada, cifrada. Y un plan de recuperación con RTO y RPO acordados con la dirección de la clínica en términos de negocio —cuántas horas puede estar la consulta sin sistema, cuántos datos es asumible perder— que se ensaya periódicamente. Un DR documentado y nunca probado es un documento, no un plan.

Errores que conviene evitar

• Dar por hecho que la responsabilidad es del proveedor. El proveedor es encargado; la clínica es responsable. Ese reparto no se puede subcontratar.
• Confundir “está cifrado” con “estamos cubiertos”. El cifrado en reposo no hace nada contra una cuenta legítima comprometida, que es el vector más común.
• Backups accesibles desde el servidor que protegen. Si el ransomware llega al servidor, llega a la copia. Aislamiento o inmutabilidad, o no cuenta.
• Usuarios compartidos por turno. Sin identidad individual no hay trazabilidad, y sin trazabilidad no puedes acotar ni demostrar nada.
• Aceptar “está en la nube” como respuesta. Sin región, subencargados, retención y DPA por escrito, no sabes dónde están tus datos.
• Tratar la formación como un trámite. El phishing sigue siendo la puerta de entrada número uno, y ninguna arquitectura compensa una credencial regalada.
• Dejar la seguridad para después de migrar. Rediseñar la red y los accesos con el sistema ya en producción cuesta mucho más que haberlo planteado antes.

Cómo elegir con quién montarlo

Si vas a que alguien te revise o te monte esto, fíjate en el orden en que hace las preguntas. Un buen equipo te pregunta qué datos tienes, dónde viven y cuánto tiempo hay que conservarlos antes de proponerte producto. Te habla de segmentación, de identidad y de recuperación antes que de firewalls de marca. Y te dice con claridad qué no hace falta, porque en seguridad vender de más es tan fácil como vender de menos.

Desconfía de quien te ofrezca “cumplimiento RGPD” como si fuera un paquete cerrado. El cumplimiento es el resultado de una arquitectura bien pensada y de unos procesos que se ejecutan, no un entregable que se compra.

En LMNHUB diseñamos infraestructura para datos sensibles con aislamiento por capas, cifrado, gestión de secretos, control de acceso por rol y recuperación probada, todo definido como código para que sea auditable y reproducible. La misma disciplina que aplicamos a entornos financieros, con las exigencias particulares del dato de salud. Si te interesa cómo decidimos qué información puede salir de tu sistema y cuál no, lo desarrollamos en nuestra guía sobre RGPD e IA, y el criterio de residencia y aislamiento del dato lo tratamos también al elegir modelo de multi-tenancy.

Si llevas tiempo con la sensación de que tu infraestructura clínica creció sin plan y no sabrías responder dónde están tus datos ni quién accede a ellos, cuéntanos tu caso y te respondemos con un diagnóstico concreto y un equipo senior, no con un presupuesto genérico.