Arquitectura de Datos Segura para SaaS de Salud

La seguridad no se añade al final. Se diseña desde el principio (Art. 25 — Privacy by Design).

Principios de arquitectura

1. Separación de datos

[TU SAAS]
    │
    ├── DATOS DE USUARIO (identidad)
    │   └── email, nombre, id interno
    │
    ├── DATOS CLÍNICOS (salud)
    │   └── CGM, HbA1c, dosis, diagnósticos
    │   └── ⚠️ CIFRADOS + SEUDONIMIZADOS
    │
    └── DATOS DE INVESTIGACIÓN
        └── Anonimizados o seudonimizados
        └── Sin posibilidad de reidentificación directa

2. Seudonimización vs Anonimización

SEUDONIMIZACIÓN                    ANONIMIZACIÓN
───────────────                    ──────────────
Reemplazas ID real por token       Eliminas toda posibilidad
Ej: Paciente 37482                 de identificación
                                   ───
El endocrino puede                  No hay vuelta atrás
re-identificar si necesita         ───
                                     No aplica GDPR
⚠️ Sigue siendo dato personal       (Reg. 26 GDPR)
  → Aplica GDPR

Para tu SaaS:

  • Producción: datos reales con seudonimización + cifrado
  • Analytics: datos anonimizados (no puedes identificar individuos)
  • Investigación: seudonimizados con token mantenido por separado

3. Cifrado

EN REPOSO (at-rest)              EN TRÁNSITO (in-transit)
┌───────────────┐                ┌───────────────┐
│ BD principal  │ ← AES-256     │ API REST      │ ← TLS 1.3
│ Backups       │ ← AES-256     │ Websockets    │ ← WSS
│ Archivos      │ ← AES-256     │ App móvil     │ ← Cert pinning
└───────────────┘                └───────────────┘

🔑 Truco: Usa cifrado a nivel de aplicación (no solo de base de datos). Si alguien roba la BD, que no pueda leer los datos aunque tenga acceso.

4. Control de accesos (RBAC)

ROLES EN TU SAAS DE ENDOCRINOLOGÍA:

PACIENTE               ENDOCRINO               ADMIN
───────                ─────────               ─────
✅ Sus datos            ✅ Sus pacientes       ✅ Configurar sistema
✅ Compartir datos      ✅ Ver CGM en tiempo   ✅ Gestionar usuarios
  con su endocrino        real                 ✅ Logs de auditoría
✅ Historial propio     ✅ Añadir notas        ❌ NO ver datos clínicos
❌ Ver otros pacientes  ❌ NO paciente fuera   ❌ NO modificar HC
                          de su lista

INVESTIGADOR            SOPORTE IT
────────────            ─────────
✅ Datos agregados      ❌ NO acceder a datos
✅ Series temporales    ❌ NO leer mensajes
  seudonimizadas        ❌ NO ver CGM
❌ NO identificar        ✅ Solo infraestructura
✅ Solicitud HDAB

5. Logs de auditoría

Cada acceso a datos de salud debe quedar registrado:

┌───────────────────────────────────────────────────┐
│ QUIÉN      │ Paciente 37482                       │
│ CUÁNDO     │ 2026-05-04 14:32:17 UTC              │
│ QUÉ        │ Lectura CGM (rango: 70-180 mg/dL)    │
│ DÓNDE      │ Módulo: dashboard paciente           │
│ IP         │ 84.xxx.xxx.xxx                       │
│ RESULTADO  │ 200 OK                               │
│ SESIÓN     │ 2FA verificada                       │
└───────────────────────────────────────────────────┘

Los logs deben ser:

  • Inmutables (no se pueden borrar)
  • Accesibles solo para auditoría
  • Conservados según política (mínimo 1-2 años)
  • Revisables por el DPO y la AEPD

Stack técnico recomendado

FRONTEND                BACKEND                 DATABASE
────────                ──────                  ────────
React Native/           FastAPI/NestJS          PostgreSQL + 
Flutter (móvil)         (API REST/GraphQL)       TimescaleDB
React (web)                                     (series CGM)
                        ENCRYPTION              Redis (caché)
AUTH                    ──────────
────────                Fernet/AES-256-GCM      BACKUPS
Clerk/Auth0/            a nivel de campo        ────────
Supabase Auth                                  Cifrados + off-site
                        2FA
2FA + OAuth             ────
                        TOTP + magic links      INFRA
                                                ────────
STORAGE                 MESSAGE QUEUE           AWS/GCP/Azure
───────                 ─────────────           (UE region)
S3/GCS (cifrado)        RabbitMQ/SQS
  (imágenes, PDFs)      (logs async)

Checklist técnica GDPR-ready

□ Cifrado AES-256 en reposo (a nivel de campo o disco)
□ TLS 1.3 en todas las comunicaciones
□ Seudonimización de IDs de pacientes
□ RBAC implementado (mínimo: paciente, endocrino, admin, investigación)
□ Logs de auditoría inmutables
□ 2FA para accesos de personal sanitario
□ Política de contraseñas robusta
□ Backups cifrados con prueba de restauración
□ Plan de continuity / disaster recovery
□ Vault de secretos (no claves en .env)
□ Rate limiting para prevenir scraping
□ WAF / protección DDoS
□ Escaneo de vulnerabilidades (SAST + DAST)
□ Bug bounty program (cuando tenga tracción)
□ DPA con proveedor cloud
□ Datos en región UE (obligatorio para datos de salud)

Ubicación de datos — Cloud regional

Los datos de salud deben estar en la UE (salvo garantías):

✅ UE/EEE: AWS Frankfort, Irlanda, París
✅ UE/EEE: Google Cloud Madrid, Bélgica, Países Bajos
✅ UE/EEE: Azure Norte de Europa, Oeste de Europa
❌ USA: Solo con SCC + Data Privacy Framework
❌ China: Prohibido para datos de salud UE

Tabla: Cómo proteges cada tipo de dato

DatoCifrado repoCifrado tránsitoSeudonimizadoRBACLogs
Email/name❌ (necesario)
CGM readings
Diagnósticos❌ (necesario)
Datos genéticos✅ + HSM✅ + 2FA
Analytics✅ (anonimizado)
Logs de accesoadmin

Referencias