Cloud souverain santé HDS : le guide du DSI pour héberger des données médicales en conformité

Le secteur santé est le plus ciblé par les cyberattaques en France — 33 % des incidents signalés à l’ANSSI en 2025 concernent des établissements de santé. Et pour cause : un dossier médical vaut 50 fois plus qu’une carte bancaire sur le marché noir. Pour les DSI hospitaliers et des entreprises de santé, le défi est double : protéger des données ultra-sensibles tout en les rendant accessibles aux soignants 24h/24.

La certification HDS (Hébergeur de Données de Santé), obligatoire depuis 2021 pour tout hébergement de données médicales en France, rajoute une couche de contraintes techniques et organisationnelles. Le cloud souverain avec certification HDS est la seule réponse qui combine sécurité, conformité et performance.

Ce guide vous explique comment déployer un cloud privé HDS, héberger des données médicales en conformité, et satisfaire les exigences RGPD, HDS et NIS2 simultanément.

---

Pourquoi le cloud souverain santé est un enjeu critique

Les chiffres du secteur santé

Statistique	Source
33 % des incidents cyber concernent la santé	ANSSI, 2025
Un dossier médical vaut 50x une carte bancaire	McAfee
67 % des hôpitaux français ont subi une cyberattaque	HCSP, 2024
Coût moyen d’une breach santé : 10,93 M$	IBM, 2024
Temps moyen de détection d’une breach santé : 259 jours	IBM
Seulement 24 % des établissements ont un plan de réponse formalisé	ANSSI

Les 5 obligations légales du DSI santé

Obligation	Texte	Conséquence du non-respect
Héberger en HDS	Code de la santé publique, Art. L.1111-8	75 000 € d’amende + 5 ans de prison
Protéger les données médicales	RGPD, Art. 9 (données sensibles)	4 % du CA ou 20 M€
Notifier les breaches	RGPD, Art. 33	Sanction CNIL + perte de confiance
Assurer la disponibilité	NIS2, Art. 21	10 M€ ou 2 % du CA
Sécuriser les réseaux	NIS2 (hôpitaux = entités essentielles)	10 M€ ou 2 % du CA

La santé cumule les réglementations : RGPD (données sensibles), HDS (hébergement certifié), NIS2 (entité essentielle), et le Code de la santé publique. Le DSI doit satisfaire toutes ces exigences simultanément.

---

La certification HDS : ce que le DSI doit savoir

Qu’est-ce que la certification HDS ?

La certification HDS (Hébergeur de Données de Santé) est une obligation légale depuis la loi du 24 janvier 2019. Tout hébergement de données de santé en France doit être certifié HDS, que l’hébergeur soit français ou étranger.

Les 6 exigences clés de la certification HDS

Exigence HDS	Mise en œuvre technique
Localisation des données	Données hébergées en France ou dans l’EEE
Confidentialité	Chiffrement AES-256 au repos et TLS 1.3 en transit
Disponibilité	SLA 99,9 %, PRA/PRA testé annuellement
Traçabilité	Audit logging de chaque accès aux données de santé
Réversibilité	Possibilité de récupérer ses données dans un format ouvert
Sous-traitance	Tout sous-traitant doit aussi être certifié HDS

Cloud souverain vs cloud public : comparaison santé

Critère	Cloud public (AWS/Azure)	Cloud souverain HDS
Localisation	Région EU (mais données copiables aux USA via CLOUD Act)	France métropolitaine
Certification HDS	Oui, mais portée limitée	Complète (infrastructure + services)
CLOUD Act	Données accessibles aux autorités US par le CLOUD Act	Aucune exposition au CLOUD Act
RGPD	Conforme, mais transferts indirects possibles	Conforme, données en France
Réversibilité	Formats propriétaires, extraction coûteuse	Formats ouverts, extraction immédiate
Audit de sécurité	Rapports de audits (SOC2) non publics	Audit complet transparent
Coût (5 ans)	Croissant (pay-as-you-go)	Fixe (infrastructure propre)
Coût estimé 50 VMs/5 ans	800 K€ – 1,2 M€	250 K€ – 350 K€

Le cloud public certifie HDS, mais le CLOUD Act américain permet aux autorités US d’accéder aux données hébergées en Europe. Pour un hôpital français ou une entreprise de santé, ce risque juridique est inacceptable.

---

Architecture cloud souverain HDS

Vue d’ensemble

┌─────────────────────────────────────────────────────────────┐
│                    ZONE DE SAISIE                           │
│  (Données avant traitement — hors périmètre HDS)           │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │ Terminal │  │ Terminal │  │ Logiciel │  │ App Mobile│  │
│  │ médical  │  │ infirmier│  │ métier   │  │ patient   │  │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘  │
└───────┼──────────────┼──────────────┼──────────────┼──────┘
        │              │              │              │
        └──────────────┴──────────────┴──────────────┘
                              │ HTTPS (TLS 1.3)
┌─────────────────────────────▼──────────────────────────────┐
│                   EDGE / WAF                                │
│  ┌─────────────┐  ┌──────────────┐  ┌───────────────┐    │
│  │   Traefik    │  │ Coraza WAF   │  │ Rate limiting  │    │
│  │ Terminaison  │  │ OWASP CRS    │  │ 100 req/min   │    │
│  │   TLS 1.3    │  │ Anti-injection│ │  Anti-brute   │    │
│  └─────────────┘  └──────────────┘  └───────────────┘    │
└─────────────────────────────┬──────────────────────────────┘
                              │
┌─────────────────────────────▼──────────────────────────────┐
│                 ZONE HDS (Données de santé)                 │
│                    🔒 CHIFFRÉE · AUDITÉE 🔒                │
│                                                             │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ Keycloak │  │ Portail  │  │  API     │  │ DMP      │  │
│  │ Auth MFA │  │ Patient  │  │ Gateway  │  │ Connecteur│  │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
│                                                             │
│  ┌──────────────────┐  ┌──────────────────────────┐       │
│  │ PostgreSQL       │  │ Object Storage (MinIO)   │       │
│  │ Chiffrement AES  │  │ Chiffrement AES-256      │       │
│  │ Audit logging    │  │ Versioning + immuable   │       │
│  └──────────────────┘  └──────────────────────────┘       │
│                                                             │
│  ┌──────────────────┐  ┌──────────────────────────┐       │
│  │ Grafana          │  │ Wazuh SIEM               │       │
│  │ Dashboards       │  │ Détection d'intrusion     │       │
│  │ Alertes santé    │  │ Audit HDS                 │       │
│  └──────────────────┘  └──────────────────────────┘       │
└─────────────────────────────────────────────────────────────┘

Chiffrement : la base de la confiance santé

Donnée	Au repos	En transit	En utilisation
Dossiers médicaux	AES-256 (PostgreSQL TDE)	TLS 1.3	Application-level encryption
Images médicales (DICOM)	AES-256 (MinIO SSE)	TLS 1.3	Chiffrement sélectif par zone
Logs d’accès	AES-256 (Loki)	TLS 1.3	Pas de déchiffrement nécessaire
Sauvegardes	AES-256 (Borg + rotation)	TLS 1.3 + SSH	Chiffrement de bout en bout

Règle HDS : les données de santé sont chiffrées à chaque couche. Pas de clé unique, pas de clé stockée avec les données. Le chiffrement est géré par HashiCorp Vault avec rotation automatique tous les 90 jours.

---

Les 5 composants critiques du cloud HDS

1. Keycloak : authentification MFA pour les soignants

Le personnel soignant se connecte une fois (SSO) et accède à toutes les applications avec un seul mot de passe + MFA.

# Keycloak — Configuration spécifique santé
realm: health
  authentication:
    - type: password
    - type: totp        # TOTP (app mobile)
    - type: webauthn     # Clé YubiKey pour les administrateurs
  
  # Session courte — exigence HDS
  session:
    max_duration: 8h     # Durée max d'une session
    idle_timeout: 30min   # Déconnexion après 30 min d'inactivité
    
  # Politique de mot de passe — niveau santé
  password_policy:
    min_length: 14
    uppercase: 1
    lowercase: 1
    digits: 1
    special: 1
    history: 12
    max_age: 90d

Pourquoi le MFA est obligatoire en santé : un dossier médical volé permet l’usurpation d’identité, la fraude à l’assurance, et le chantage. Le MFA réduit le risque de compromission par mot de passe de 99,9 % (Microsoft).

2. PostgreSQL chiffré : la base de données HDS

# PostgreSQL — Configuration HDS

# Chiffrement au repos
ssl = on
ssl_cert_file = '/etc/postgresql/server.crt'
ssl_key_file = '/etc/postgresql/server.key'
ssl_min_protocol = 'TLSv1.3'

# Audit logging — obligatoire HDS
log_connections = on
log_disconnections = on
log_statement = 'all'           # Journaliser TOUTES les requêtes
log_duration = on
log_line_prefix = '%t [%p] %u@%d '  # Timestamp, PID, utilisateur, base

# Sécurité
password_encryption = scram-sha-256
max_connections = 200

Exigence HDS : chaque accès à une donnée de santé doit être tracé. Le log_statement = 'all' garantit que chaque SELECT, INSERT, UPDATE sur les données médicales est journalisé avec l’utilisateur, l’horodatage et la requête.

3. Object Storage (MinIO) : images médicales DICOM

# MinIO — Stockage images médicales

# Chiffrement au repos (SSE-S3 avec Vault)
server-side-encryption:
  enabled: true
  type: sse-s3
  key-management: vault

# Rétention légale (10 ans minimum pour les données médicales)
lifecycle:
  - rule: "retention-medicale"
    status: enabled
    expiration: 3650d    # 10 ans
    noncurrent-version-expiration: 3650d

# Immuabilité (WORM — Write Once Read Many)
object-lock:
  enabled: true
  mode: compliance
  retention-duration: 3650d  # 10 ans

# Versionning
versioning: enabled

Immuabilité : les données médicales ne peuvent être ni modifiées ni supprimées pendant 10 ans. C’est une exigence légale (Code de la santé publique) et une protection contre les ransomwares.

4. Wazuh SIEM : surveillance en temps réel

# Wazuh — Règles spécifiques santé

rules:
  # Détection d'accès anormal aux dossiers médicaux
  - id: 100001
    level: 12
    description: "Accès médical inhabituel : plus de 50 dossiers en 5 minutes"
    condition:
      - field: "audit.module"
        value: "postgresql"
      - field: "audit.statement"
        value: "SELECT"
      - field: "audit.count_5min"
        value: ">50"
  
  # Détection de tentative d'exfiltration
  - id: 100002
    level: 14
    description: "Tentative d'exfiltration de données médicales"
    condition:
      - field: "audit.module"
        value: "minio"
      - field: "audit.action"
        value: "download"
      - field: "audit.volume_mb"
        value: ">100"
  
  # Détection de connexion hors horaire
  - id: 100003
    level: 10
    description: "Connexion aux données de santé en dehors des heures de service"
    condition:
      - field: "audit.module"
        value: "keycloak"
      - field: "audit.hour"
        value: "NOT_IN 08:00-20:00"
      - field: "audit.day"
        value: "NOT_IN mon-fri"

5. Grafana : dashboards de conformité HDS

Dashboard	Métriques	Alerte
Accès données médicales	Accès par utilisateur, par service, par période	> 50 dossiers/5 min → investigation
Sécurité	Tentatives d’intrusion, auth failures, MFA bypass	> 3 auth failures/15 min → blocage
Disponibilité	Uptime SLA, latence, stockage	< 99,9 % → incident
Conformité HDS	Audit trail complet, rétention, chiffrement	Log manquant → alerte critique
RGPD	Accès par finalité, demandes d’effacement, DPO notifications	Accès sans justification → violation

---

Conformité croisée : HDS × RGPD × NIS2

Matrice de conformité

Exigence	HDS	RGPD	NIS2	Mise en œuvre
Chiffrement au repos	✓	✓ Art. 32	✓	AES-256 (PostgreSQL TDE, MinIO SSE)
Chiffrement en transit	✓	✓ Art. 32	✓	TLS 1.3 partout
Authentification forte	✓	✓ Art. 32	✓ Art. 21	Keycloak MFA
Audit trail	✓	✓ Art. 30	✓ Art. 21	Wazuh + PostgreSQL audit logging
Localisation France	✓	✓ Art. 44	–	Data center en France métropolitaine
Droit d’accès	✓	✓ Art. 15	–	API dédiée + DPO portal
Droit d’effacement	✓	✓ Art. 17	–	Soft delete + anonymisation
Notification breach 72h	✓	✓ Art. 33	✓ Art. 23	Wazuh alert + workflow CNIL
PRA testé annuellement	✓	✓ Art. 32	✓ Art. 21	Test de reprise automatisé
Réversibilité	✓	✓ Art. 20	–	Export en formats ouverts

Registre des traitements santé

Le DSI santé doit maintenir un registre des traitements spécifique aux données de santé :

# Registre des traitements — Données de santé

treatments:
  - name: "Gestion des dossiers patients"
    purpose: "Soins médicaux"
    legal_basis: "Art. 6(1)(e) + Art. 9(2)(h) RGPD"
    data_categories:
      - "Données d'identité"
      - "Données médicales"
      - "Données de santé"
    recipients: ["Médecins", "Infirmiers", "Administration"]
    retention: "10 ans après le dernier contact"
    security_measures: ["Chiffrement AES-256", "MFA", "Audit logging", "WORM"]
    
  - name: "Téléconsultation"
    purpose: "Consultation médicale à distance"
    legal_basis: "Art. 6(1)(e) + Art. 9(2)(h) RGPD"
    data_categories:
      - "Données d'identité"
      - "Données médicales"
      - "Vidéo et audio"
    recipients: ["Médecins", "Patients"]
    retention: "10 ans (vidéo : 6 mois)"
    security_measures: ["E2E encryption", "MFA", "Enregistrement immuable"]

---

Le DMP et les interconnexions santé

Connecteur DMP (Dossier Médical Partagé)

Le DMP est le système national de partage des données médicales. Un cloud souverain santé doit pouvoir interagir avec le DMP :

# Connecteur DMP / Services numériques santé

dmp_connector:
  # Authentification CPS/CPE (Carte Professionnel de Santé)
  auth:
    type: "CPS"              # Carte de Professionnel de Santé
    certificate: "/etc/cps/cert.p12"
    mfa: true                 # CPS + code PIN
  
  # Endpoints DMP
  endpoints:
    creation: "https://dmp.esante.gouv.fr/api/v1/create"
    consultation: "https://dmp.esante.gouv.fr/api/v1/read"
    mise_a_jour: "https://dmp.esante.gouv.fr/api/v1/update"
    
  # Journalisation de chaque accès DMP (obligatoire)
  audit:
    enabled: true
    destination: "wazuh"
    fields: ["practitioner_id", "patient_id", "action", "timestamp", "justification"]

Obligation légale : chaque accès au DMP doit être justifié et tracé. Le praticien doit indiquer le motif de consultation (soins, urgence, contrôle).

---

TCO : Cloud souverain HDS vs Cloud public HDS

Scénario : Hôpital régional (1 000 lits, 5 000 utilisateurs)

Poste	Cloud public (AWS/Azure)	Cloud souverain HDS	Économie
Compute (50 VMs)	480 K€/5 ans	180 K€/5 ans	-63 %
Stockage (100 TB)	240 K€/5 ans	80 K€/5 ans	-67 %
Réseau / bande passante	120 K€/5 ans	30 K€/5 ans	-75 %
Licence OS + DB	150 K€/5 ans	50 K€/5 ans	-67 %
Support + HDS certifié	180 K€/5 ans	60 K€/5 ans	-67 %
Sécurité (WAF, SIEM)	200 K€/5 ans	50 K€/5 ans (open source)	-75 %
Total 5 ans	1 370 K€	450 K€	-67 %
Coût mensuel	22,8 K€	7,5 K€	-67 %

Les coûts cachés du cloud public

• Egress : le transfert de données médicales (DICOM) est coûteux (0,09 €/Go)
• Conformité CLOUD Act : juridique et organisationnel (audit supplémentaire)
• Vendor lock-in : migration des données de santé : 3-6 mois, 50-100 K€
• Réversibilité : les formats propriétaires rendent l’export complexe

---

Déploiement en 10 jours

Phase	Jours	Action	Livrable
Phase 1	J1-J3	Infrastructure HDS base	OpenNebula + PostgreSQL + MinIO + Keycloak
Phase 2	J4-J5	Sécurité + conformité	WAF Coraza + Wazuh SIEM + Audit logging
Phase 3	J6-J7	Observabilité	Grafana dashboards + Alertes HDS
Phase 4	J8-J9	Connecteurs santé	DMP / e-CPS / SI métier
Phase 5	J10	Formation + documentation	Documentation HDS + formation équipe

Prérequis HDS : la certification HDS est un processus organisationnel (18-24 mois). Le cloud souverain HDS fournit l’infrastructure technique conforme ; la certification reste à la charge de l’hébergeur ou de l’établissement.

---

Conclusion

Le cloud souverain santé HDS n’est pas un choix technique — c’est une obligation légale et une nécessité de confiance. Les patients confient leurs données médicales les plus intimes à des institutions qui doivent les protéger avec le plus haut niveau de sécurité. Le CLOUD Act américain, les ransomwares qui paralysent les hôpitaux, et les sanctions CNIL pour les violations de données médicales sont autant de risques réels.

La combinaison cloud souverain (OpenNebula, infrastructure en France, données non soumises au CLOUD Act) + certification HDS (audit trail, chiffrement, MFA, rétention 10 ans) + open source (Keycloak, Coraza, Wazuh, Grafana) offre le meilleur rapport sécurité/conformité/coût du marché.

67 % d’économie sur 5 ans par rapport au cloud public HDS, avec zéro exposition au CLOUD Act et une réversibilité complète.

Cloud Inspire déploie l’infrastructure HDS en 10 jours sur votre cloud privé OpenNebula. Si vous êtes un DSI d’établissement de santé ou d’entreprise du medicotech, parlons-en.