EL DATO MÁS SENSIBLE
Un Historial Médico Filtrado No Se Puede Cambiar de Contraseña
Cuando se filtra un número de tarjeta de crédito, el banco la cancela y emite una nueva en 48 horas. Cuando se filtra un historial médico — un diagnóstico de VIH, un tratamiento psiquiátrico, una prueba genética — no hay botón de reset. Ese dato persigue al paciente el resto de su vida. Puede afectar a su empleabilidad, a sus seguros, a sus relaciones. Por eso los datos de salud no son 'datos sensibles más'. Son la categoría más crítica que existe en protección de datos.
El dato más caro del mercado negro
Un registro médico completo se vende por entre 250 y 1.000 dólares en la dark web. Una tarjeta de crédito robada, entre 5 y 110 dólares. La diferencia de precio refleja una asimetría fundamental: el dato financiero caduca cuando se cancela la tarjeta; el dato clínico es permanente y permite fraudes de seguros, extorsión personal y suplantación de identidad médica durante décadas.
España no es inmune
La Agencia Española de Protección de Datos (AEPD) ha impuesto múltiples sanciones superiores a 100.000 euros por brechas de datos sanitarios en 2023 y 2024. Los casos incluyen accesos no autorizados a historiales clínicos, envíos de informes médicos al paciente equivocado y bases de datos de pacientes accesibles sin autenticación. El regulador trata las brechas de datos de salud con una severidad significativamente mayor que las de otros sectores.
ASM — Superficie Externa Sanitaria5 hallazgos criticos
Subdominios descubiertos:14
CRITICOapi-pacientes.salud-app.example.com
Endpoint /Patient sin autenticacion. Devuelve nombre, DNI, diagnosticos.
CRITICOportal.salud-app.example.com/api/v1/records
IDOR confirmado: cambiando patient_id se accede a historiales de otros pacientes.
ALTOstaging-ehr.salud-app.example.com
Entorno staging con datos reales de produccion. Sin .htaccess ni autenticacion.
Exposicion estimada: ~45.000 registros de pacientes accesibles publicamente
CUMPLIMIENTO LEGAL
RGPD Artículo 32 No Es un Checkbox. Es Tu Obligación Legal.
Muchas healthtechs tratan el cumplimiento del RGPD como un ejercicio documental: redactar políticas de privacidad, firmar contratos de encargado de tratamiento, y marcar casillas en una hoja de cálculo. El Artículo 32 exige algo muy distinto: medidas técnicas y organizativas que sean proporcionales al riesgo. Y para datos de salud — categoría especial bajo el Artículo 9 — el listón es considerablemente más alto.
Lo que el Art. 32 realmente exige
El artículo enumera cuatro requisitos técnicos concretos que no puedes cumplir solo con documentación:
- a)Cifrado y seudonimización — no como opción, sino como medida explícita. ¿Tu base de datos PostgreSQL con historiales tiene cifrado en reposo activado? ¿Las conexiones a tu API usan TLS 1.2 como mínimo? Vulnerabbit verifica ambas cosas automáticamente.
- b)Confidencialidad, integridad y resiliencia — controles de acceso por rol, logging de quién accede a qué registro y cuándo, y la capacidad de detectar modificaciones no autorizadas.
- c)Restauración tras incidentes — backups cifrados, probados periódicamente, con RPO y RTO documentados. No basta con tener backups; hay que demostrar que funcionan.
- d)Pruebas periódicas de eficacia — este es el apartado que justifica directamente el pentesting y el escaneo de vulnerabilidades continuo. No es una recomendación: es un requisito legal. Cada escaneo de Vulnerabbit genera evidencia con fecha, alcance y resultados que documenta el cumplimiento de este apartado.
Datos de salud = categoría especial (Art. 9)
El RGPD prohíbe por defecto el tratamiento de datos de salud. Las excepciones (consentimiento explícito, interés vital, medicina del trabajo) vienen acompañadas de una obligación reforzada de protección. Esto significa que las medidas del Art. 32 que serían suficientes para datos personales genéricos (nombre, email) son insuficientes para datos de salud. La AEPD evalúa las brechas de datos sanitarios con un criterio de proporcionalidad mucho más exigente.
APIs CLÍNICAS
Las APIs Sanitarias Hablan HL7 FHIR. Los Atacantes También.
La adopción de HL7 FHIR como estándar de interoperabilidad sanitaria está transformando cómo se intercambian datos clínicos en España y Europa. Los hospitales públicos, las aseguradoras de salud y las healthtechs construyen integraciones sobre FHIR R4, exponiendo recursos de pacientes mediante endpoints REST estándar. El problema es que REST es una puerta abierta si no se asegura correctamente — y los atacantes conocen la especificación FHIR tan bien como tus desarrolladores.
SMART on FHIR: la autorización que nadie configura bien
SMART on FHIR es el framework de autorización que añade OAuth2 con scopes granulares sobre FHIR. En teoría, permite controlar que una aplicación de alergias solo acceda a AllergyIntolerance y no a todo el historial del paciente. En la práctica, encontramos que la mayoría de implementaciones usan scopes excesivamente amplios (
patient/*.read en lugar de patient/Observation.read), tokens de acceso sin expiración o con ventanas de horas, y ausencia de refresh token rotation. El resultado: un token comprometido da acceso completo al historial médico de un paciente.BOLA y la enumeración de pacientes
BOLA (Broken Object Level Authorization) es el riesgo #1 de OWASP API Security, y en APIs FHIR su impacto es devastador. Un endpoint
/Patient/12345 que no valida que el token del solicitante corresponde a ese paciente permite acceder a cualquier registro simplemente iterando IDs. Los endpoints de búsqueda (_search, _history) son aún más peligrosos: una sola petición mal filtrada puede devolver bundles con miles de registros. Nuestro módulo DAST prueba específicamente estas rutas FHIR.DAST — API FHIR R4
3 criticos5 altos
CRITICOBOLA en /Patient/{id}
- Token con scope patient/Patient.read accede a registros de CUALQUIER paciente.
- Probados IDs: 10001, 10002, 10003 — todos devuelven datos completos.
- Impacto: acceso no autorizado a nombre, DNI, diagnosticos, medicacion activa.
CRITICORespuesta excesiva en /Observation
- Peticion de glucosa (code=15074-8) devuelve TODAS las observaciones del paciente.
- Incluye: resultados de VIH, salud mental, genetica. Violacion del principio de minimizacion.
ALTOEndpoint _search sin paginacion
- GET /Patient?_count=1000 devuelve bundle con 847 pacientes en una sola respuesta.
- Sin rate limiting. Permite exfiltracion masiva en minutos.
ALTOToken sin expiracion
- Access token emitido hace 72h sigue siendo valido. Sin refresh token rotation.
CLOUD SANITARIO
Las Misconfiguraciones Cloud que Encontramos en Sanidad
Las healthtechs construyen sobre AWS, GCP y Firebase como cualquier startup — pero con un matiz crítico: los datos que almacenan están entre los más regulados del mundo. Una configuración cloud que sería un riesgo menor en un e-commerce se convierte en una brecha de datos de salud con consecuencias legales, reputacionales y humanas cuando hay historiales médicos de por medio.
Lo que tus auditores y clientes hospitalarios van a pedir
Sea cual sea tu marco normativo (RGPD, ENS si trabajas con sanidad pública, o los requisitos contractuales de un hospital cliente), necesitas demostrar que controlas la seguridad de tu infraestructura cloud. Eso significa: cifrado en reposo verificable, gestión activa de vulnerabilidades, monitorización de configuraciones y evidencias exportables de todo ello. Vulnerabbit audita tu cloud (AWS, GCP, Firebase) y genera las evidencias técnicas que respaldan tu postura de seguridad ante cualquier auditoría o proceso de homologación.
Las misconfiguraciones cloud que encontramos en sanidad
Tras auditar decenas de healthtechs, estos son los patrones que se repiten:
Firebase Realtime Database con reglas por defecto
Las reglas
{".read": true, ".write": true} que Firebase genera en modo test siguen activas en producción. Hemos encontrado bases de datos con citas médicas, resultados de laboratorio y datos de facturación sanitaria accesibles sin autenticación desde cualquier navegador.Buckets S3 con imágenes DICOM
Imágenes médicas (radiografías, TACs, resonancias) almacenadas en S3 con ACLs públicas o políticas de bucket permisivas. Los archivos DICOM contienen metadatos con el nombre del paciente, fecha de nacimiento y diagnóstico incrustados en las cabeceras del archivo.
RDS sin cifrado con datos de prescripción
Instancias PostgreSQL o MySQL en RDS con
StorageEncrypted: false. Si el disco subyacente se compromete o se accede a un snapshot, los datos de prescripción, alergias y tratamientos activos quedan en texto plano.El sector más atacado
El Coste de No Proteger Datos de Salud
La sanidad lleva más de una década siendo el sector con el coste medio por brecha más alto del mundo. No es casualidad: los datos son permanentes, los sistemas son críticos y los atacantes lo saben.
~10M €
Coste medio global de una brecha de datos en sanidad — el más alto de cualquier sector por 14 año consecutivo.
Fuente: IBM Cost of a Data Breach Report, 2024
x20-x40
Multiplicador de valor de un registro médico frente a un número de tarjeta de crédito en mercados ilegales.
Fuente: Trustwave, Ponemon Institute
+100K €
Sanciones de la AEPD por brechas de datos sanitarios en España durante 2023-2024.
Fuente: Resoluciones AEPD (ps-00xxx-2023/2024)
Protege los Datos que No Tienen Segunda Oportunidad
Empieza a escanear tu infraestructura healthtech en 5 minutos. Sin agentes, sin configuración compleja, sin acceso a datos reales de pacientes.
Plan Autónomo desde 49 €/mes. Sin contrato anual.