Ciberseguridad en clínicas sanitarias: amenazas más comunes y cómo prevenirlas

1. Por qué las clínicas sanitarias son el objetivo preferido del cibercrimen

Los datos de salud se pagan mucho mejor que los financieros en los mercados donde se revenden, y por una razón simple: una tarjeta se cancela en una tarde y un diagnóstico dura toda la vida. Un expediente médico completo de un paciente puede alcanzar los 300 dólares en mercados de datos robados, frente a los 5-15 dólares de una tarjeta de crédito. Esto convierte a las clínicas sanitarias en objetivos prioritarios por tres razones estructurales:

1.1. Las tres razones de fondo

1. Alto valor del dato: las historias clínicas contienen datos de salud, identificativos, financieros (facturación y seguros) y, en algunos casos, datos familiares. Es el perfil de dato más completo y valioso del mercado negro.
2. Baja madurez de seguridad: en la mayoría de clínicas privadas pequeñas y medianas el presupuesto tecnológico se va casi entero al software asistencial, y queda poco para ciberseguridad, frente al 15-20 % que destinan los bancos. El contraste es enorme.
3. Alta presión operativa: cuando un hospital o clínica sufre un ataque de ransomware, la presión para pagar el rescate y recuperar el acceso a las historias clínicas es máxima porque los pacientes están esperando ser atendidos. Los atacantes lo saben y lo explotan.

1.2. Y una cuarta: la clínica no se puede permitir estar parada

Una fábrica que para pierde producción; una clínica que para deja a gente sin atender, con la agenda del día ya citada y sin acceso a los antecedentes de nadie. Esa urgencia es la que el atacante explota, y la que empuja a decisiones malas en caliente: pagar, o restaurar encima del equipo antes de haberlo copiado.

1.3. Dónde encaja este artículo

El marco legal que regula cómo deben protegerse estos datos y las consecuencias de no hacerlo está desarrollado en nuestra las obligaciones del RGPD en clínicas privadas. Este artículo se centra en la dimensión técnica y operativa de la protección.

2. Las 8 amenazas de ciberseguridad más frecuentes en clínicas privadas

No todas las amenazas tienen la misma probabilidad ni el mismo impacto. Esta clasificación las ordena por lo que de verdad se ve en el sector sanitario privado, no por lo espectacular que suene cada una:

No todas las amenazas pesan igual; el ransomware y el phishing concentran la mayoría de los casos.

2.1. Las ocho, ordenadas por lo que pasa de verdad

2.2. La que casi nunca sale en las listas

El correo mandado a la persona equivocada. No es un ataque, no sale en ningún informe de amenazas y es de las causas más frecuentes de reclamación ante la Agencia en clínicas. Se previene con lo más aburrido que hay: una vista previa antes de enviar, no usar el autocompletado con listas de pacientes y no mandar informes por correo cuando existe otra vía.

3. Ransomware sanitario: cómo funciona y cómo prevenirlo

El ransomware es el ataque que más miedo genera y con razón: cifra todos los archivos de la clínica (incluidas las historias clínicas) y exige un rescate para devolver el acceso. En el sector sanitario español, el rescate medio solicitado en 2025 fue de 47.000 euros, pero el coste real incluyendo tiempo de inactividad, recuperación de datos, honorarios legales y sanción de la AEPD superó los 190.000 euros de media.

3.1. Cómo entra el ransomware en una clínica

El 78 % de los ataques de ransomware en clínicas privadas entraron por el mismo vector: un empleado de recepción o administración que abrió un adjunto malicioso en un email aparentemente legítimo. Los adjuntos más frecuentes son facturas PDF falsas de laboratorios o mutuas, notificaciones de la Seguridad Social y actualizaciones de software clínico.

3.2. Medidas de prevención contra ransomware

• Copias de seguridad cifradas y aisladas: la única defensa real frente al ransomware es tener copias de seguridad que el ransomware no pueda alcanzar. Deben estar cifradas, guardadas fuera de la red de la clínica y con una retención que no se pueda alterar desde el sistema comprometido, y hay que restaurar alguna de vez en cuando para comprobar que sirven.
• Filtro de email avanzado (anti-spam + sandbox): los adjuntos maliciosos deben ser analizados en un entorno seguro antes de llegar al buzón del empleado.
• Parches y actualizaciones al día: el 60 % de los ransomwares explotan vulnerabilidades conocidas para las que ya existía parche. La gestión de actualizaciones es la medida de prevención más barata y la más ignorada.
• Segmentación de red: que el ordenador de recepción no pueda comunicarse directamente con el servidor de historias clínicas limita el radio de expansión del ransomware dentro de la clínica.
• EDR (Endpoint Detection and Response): más efectivo que el antivirus tradicional porque detecta comportamientos anómalos (como el cifrado masivo de archivos) en tiempo real y los detiene antes de que se extiendan.

4. Phishing médico: el vector de ataque más frecuente en clínicas

El phishing dirigido (spear phishing) contra clínicas sanitarias ha evolucionado mucho. Ya no son los emails con errores ortográficos obvios del pasado: los atacantes investigan previamente la clínica (nombre del director, proveedores habituales, software que usan) y elaboran emails personalizados casi indistinguibles de los originales.

4.1. Los 4 tipos de phishing más usados contra clínicas

1. Suplantación de la mutua o aseguradora: email que solicita actualizar datos de facturación o credenciales del portal de la mutua. La URL de destino es una copia exacta del portal real.
2. Suplantación del proveedor de software clínico: email con «actualización urgente de seguridad» que instala malware en lugar del parche real.
3. Suplantación de la AEPD o la Seguridad Social: notificación falsa de inspección o requerimiento que incluye un adjunto infectado.
4. Business Email Compromise (BEC): el atacante compromete el email del director médico y desde esa cuenta legítima solicita transferencias urgentes o cambios de datos bancarios de proveedores.

4.2. Medidas de prevención contra phishing

• Autenticación multifactor (MFA): incluso si el empleado entrega sus credenciales en una página falsa, el atacante no puede acceder sin el segundo factor. Es la medida más efectiva contra el phishing de credenciales.
• Protocolo de verificación por segundo canal: cualquier solicitud de cambio de datos bancarios o transferencia urgente recibida por email debe verificarse siempre por teléfono antes de ejecutarse.
• Formación anti-phishing y simulacros: los empleados deben aprender a identificar señales de alarma (urgencia artificial, remitente con dominio ligeramente diferente, solicitudes inusuales). Los simulacros periódicos son más efectivos que los cursos teóricos.
• Configuración DMARC/DKIM/SPF en el dominio: estas tecnologías de autenticación del email dificultan que los atacantes suplanten el dominio de tu clínica para atacar a terceros.

5. La amenaza interna: accesos indebidos del propio personal

La amenaza interna es la que más se subestima y la que más vergüenza da reconocer. El 14 % de las brechas de seguridad reportadas en clínicas privadas ante la AEPD en 2025 tuvieron su origen en el acceso indebido de un empleado, exempleado o colaborador externo a historias clínicas de pacientes sin justificación asistencial.

Las motivaciones son variadas: curiosidad (acceder a la historia de un familiar o conocido), venganza (empleado despedido que exporta datos antes de irse), beneficio económico (venta de datos a terceros) o simple error (envío accidental de datos a un paciente equivocado).

5.1. Por qué es la más sancionada

No hace falta un atacante: basta con que alguien de dentro consulte la historia de un conocido. Es el caso que más aparece en las resoluciones del sector, y se sanciona doble, por el acceso y por lo que revela: que los permisos estaban repartidos de más y que nadie revisaba el registro. Además casi siempre se descubre por el propio paciente, que es el peor de los agravantes.

5.2. Cómo prevenir la amenaza interna

• RBAC granular estricto: cada empleado solo debe poder acceder a los datos que necesita para su función concreta. El personal de recepción no necesita ver el contenido de las historias clínicas, solo la agenda y los datos de contacto.
• Registro de accesos protegido: cada acceso a una historia clínica debe quedar registrado con el usuario, la fecha, la hora y la IP. Estos logs deben ser inmutables (nadie puede borrarlos, ni el administrador).
• Protocolo de baja inmediata: cuando un empleado causa baja, sus accesos deben revocarse en menos de 24 horas. En clínicas sin proceso definido, es frecuente encontrar cuentas activas de exempleados meses después de su salida.
• Acuerdos de confidencialidad en los contratos: con cláusula específica de responsabilidad ante accesos o revelaciones indebidas, que disuada y establezca consecuencias claras.
• Alertas automáticas ante comportamientos anómalos: el software clínico debería poder alertar cuando un usuario accede a un volumen inusual de historias clínicas fuera de su horario habitual o descarga masivamente expedientes.

5.3. Revisar el registro, media hora al mes

De nada sirve registrar si nadie mira. Con una revisión corta y periódica basta —accesos fuera de horario, consultas a historias sin cita asociada, usuarios que abren muchas más fichas que la media de su puesto—, siempre que el criterio esté escrito antes y no se improvise al mirar. La designación del delegado y la configuración de permisos por rol son las dos medidas más efectivas combinadas. Lo desarrollamos en detalle en cómo elegir un DPO para tu clínica.

6. El modelo de defensa en profundidad para clínicas sanitarias

La ciberseguridad no funciona con una sola medida. Ningún antivirus, ningún firewall y ninguna formación es suficiente por sí solo. El estándar profesional es el modelo de defensa en profundidad (defense in depth): múltiples capas de protección independientes que se refuerzan mutuamente, de forma que si un atacante supera una capa, las siguientes lo detienen.

Si una capa falla, las siguientes detienen al atacante antes de que llegue al dato.

6.1. Capas 1 y 2 — el perímetro y cada dispositivo

La primera línea de defensa filtra el tráfico que entra y sale de la red de la clínica. Un firewall bien configurado con reglas restrictivas bloquea el acceso desde IPs sospechosas y limita las conexiones salientes no autorizadas. La red Wi-Fi de pacientes debe estar completamente separada (VLAN independiente) de la red interna de la clínica.

Capa 2 — Endpoints: protección en cada dispositivo.

Cada ordenador, tablet y móvil que accede a datos de la clínica debe tener EDR activo y actualizado, disco duro cifrado (BitLocker en Windows, FileVault en macOS) y política de pantalla de bloqueo automático en menos de 5 minutos. Los dispositivos personales (BYOD) deben estar expresamente regulados.

6.2. Capas 3 y 5 — quién entra y quién mira

MFA obligatorio para todos los accesos remotos y para el panel de administración del software clínico. RBAC granular configurado según el principio de mínimo privilegio. Gestión de contraseñas con política de complejidad y caducidad, o uso de un gestor de contraseñas corporativo.

6.3. Capa 4 — los datos: cifrado y copias fuera de alcance

Los datos de salud deben estar cifrados en reposo (AES-256-GCM) y en tránsito (TLS 1.3). Y las copias tienen que estar fuera del alcance de la red principal: si desde el equipo comprometido se pueden borrar o sobrescribir, el atacante se las lleva con el resto. El detalle sobre qué documentos y qué campos se cifran en la clínica sanitaria —y por qué no se cifra el expediente entero— se cuenta en cifrado documental en la clínica. Aisladas, con una retención que no se pueda cambiar desde la consola de administración, y restauradas de prueba de vez en cuando.

Capa 5 — Monitorización: detección y respuesta.

Si las capas anteriores fallan, la monitorización es la que detecta el ataque antes de que cause daño irreversible. Logs de acceso en tiempo real, alertas ante comportamientos anómalos y un plan de respuesta a incidentes documentado y ensayado. Esta última capa conecta directamente con el el protocolo de actuación ante una brecha.

7. Cómo evaluar la seguridad de tu software clínico actual

7.1. Las diez preguntas, con su respuesta mínima

El software clínico es el corazón digital de la clínica y, por tanto, el objetivo prioritario de cualquier atacante que quiera acceder a las historias clínicas. Antes de confiar en un software, estas son las 10 preguntas que debes hacerle al proveedor y las respuestas mínimas aceptables:

• ☐ ¿Dónde están los servidores? Respuesta mínima: territorio europeo, con cifrado en reposo y en tránsito y registro de accesos. Pide el país concreto, no el continente, y pregunta también dónde acaban las copias.
• ☐ ¿Qué tipo de cifrado usan en reposo y en tránsito? Respuesta mínima: AES-256-GCM en reposo, TLS 1.3 en tránsito.
• ☐ ¿Quién puede tocar el registro de accesos? Respuesta mínima: nadie que consulte datos puede editar ni borrar su propia traza, y el registro se conserva aunque se elimine el usuario.
• ☐ ¿Tienen contrato de encargado del tratamiento listo para firmar? Respuesta mínima: sí, conforme al art. 28 RGPD, disponible antes del primer acceso a datos reales.
• ☐ ¿Cuál es su política de copias de seguridad? Respuesta mínima: copias cifradas cada hora, retención 30 días, test de restauración mensual.
• ☐ ¿Tienen MFA disponible? Respuesta mínima: sí, obligatorio para accesos administrativos como mínimo.
• ☐ ¿Cuál es su SLA de disponibilidad y recuperación? Respuesta mínima: 99,9 % uptime, RTO menor de 4 horas, RPO menor de 1 hora.
• ☐ ¿Han sufrido brechas de seguridad en los últimos 3 años? Respuesta mínima: respuesta honesta, con descripción de qué ocurrió y cómo lo resolvieron.
• ☐ ¿Permiten la exportación completa de datos en formato abierto? Respuesta mínima: sí, en cualquier momento y sin coste.
• ☐ ¿Cuándo fue su última auditoría de seguridad externa? Respuesta mínima: en los últimos 12-24 meses, con informe disponible bajo NDA.

7.2. Qué hacer con las respuestas

Guarda las respuestas por escrito y féchalas: eso es lo que acredita después que elegiste con diligencia, que es un criterio expreso de graduación si algún día hay expediente. Si el proveedor no puede responder con claridad a estas diez preguntas, es una señal de alarma. La comparativa técnica entre arquitecturas de software clínico y sus implicaciones para el RGPD está en software médico en la nube vs. on-premise: ventajas, riesgos y costes reales.

8. Plan de contingencia: qué hacer cuando el ataque ya ocurrió

Ninguna medida de prevención garantiza el 100 % de protección. Las clínicas con mejor posición ante la AEPD tras un incidente son las que tenían un plan de contingencia documentado, lo habían ensayado y lo activaron correctamente. Estas son las fases del plan:

8.1. Fase 1 — Contención (primeras 2 horas)

• Aislar los sistemas afectados de la red inmediatamente (desconectar Ethernet y Wi-Fi).
• No apagar los equipos afectados (los logs en memoria son evidencia forense).
• Notificar al DPO y a la dirección de la clínica.
• Activar el modo de contingencia manual si los sistemas de agenda están caídos.

8.2. Fase 2 — Evaluación (horas 2-24)

• Contratar un equipo de respuesta a incidentes (DFIR) si no se tiene capacidad interna.
• Determinar el alcance: qué datos han sido comprometidos, cuántos pacientes afectados, cuál fue el vector de entrada.
• Evaluar si la brecha obliga a notificación a la AEPD (plazo de 72 horas desde que se tiene conocimiento).

8.3. Fase 3 — Notificación (antes de las 72 horas)

Si el análisis determina que hay riesgo para los derechos y libertades de los pacientes, la notificación a la AEPD es obligatoria en el plazo de 72 horas. El procedimiento exacto, los formularios y el guion de comunicación a los pacientes afectados están en nuestro el protocolo de actuación ante una brecha.

Fase 4 — Recuperación y mejora.

• Restaurar desde las copias de seguridad más recientes no comprometidas.
• Eliminar el vector de entrada antes de reconectar los sistemas.
• Ejecutar una auditoría post-incidente para identificar qué medida falló.
• Actualizar el plan de contingencia con las lecciones aprendidas.

Regla de oro: una clínica que paga el rescate del ransomware sin notificar a la AEPD tiene dos problemas en lugar de uno. El pago no garantiza la recuperación de los datos (el 40 % de las clínicas que pagan no recuperan todos sus datos) y la falta de notificación a la AEPD convierte una brecha en una infracción adicional.

9. Qué aporta obeliOmed en cada capa

9.1. En la capa de datos

Los servidores están en España. Los documentos clínicos y los campos marcados como sensibles se cifran con AES-256-GCM, con la clave derivada por ámbito mediante HKDF-SHA-256 y rotación de claves, y la conexión viaja bajo TLS. Se cifran esos documentos y esos campos, no el expediente entero: cuando preguntes a cualquier proveedor, exige ese nivel de detalle en la respuesta y desconfía del «todo cifrado».

9.2. En la capa de identidad

Los permisos se conceden por rol y por pantalla sobre la misma historia clínica electrónica, que es lo que responde a la amenaza interna de la sección 5: recepción no llega a lo que no necesita para trabajar. Es la medida con mejor relación entre esfuerzo y riesgo evitado de todo este artículo.

9.3. En la capa de monitorización

Cuando alguien corrige un dato del expediente, el cambio queda registrado con su autor, su fecha y el valor anterior. Es lo que permite reconstruir qué pasó cuando ya ha pasado, que es el trabajo del día después. Y cada centro puede descargar en cualquier momento una copia de sus propios datos, que sirve también para tu propia política de copias. Lo que ningún proveedor cubre son las capas 1 y 2, ni la formación del equipo: el checklist de auditoría RGPD las recorre todas.