Fuite de données de santé : tester l’exfiltration à l’hôpital et en HDS

Une fuite de données de santé désigne la sortie non autorisée d’informations médicales ou administratives concernant des patients hors du périmètre de l’établissement ou de son hébergeur. Pour un hôpital, une clinique ou un hébergeur certifié HDS, la vraie question n’est pas « avons-nous des contrôles ? » mais « ces contrôles empêchent-ils réellement une donnée patient de sortir ? ». Seul un test actif, mené avec des données factices, permet d’y répondre avec une preuve.

Pourquoi les données de santé sortent si facilement

La donnée de santé a deux particularités. Elle est durable (un antécédent médical ne se « réinitialise » pas comme un mot de passe) et elle se monnaye bien, ce qui en fait une cible classique des opérations de ransomware à double extorsion. L’ANSSI et le CERT Santé de l’Agence du numérique en santé signalent régulièrement les établissements de santé parmi les victimes récurrentes de rançongiciels.

Le constat de terrain est simple : les établissements ont souvent investi dans des briques de protection, mais rarement vérifié qu’elles bloquent quoi que ce soit en conditions réelles.

Le cadre : RGPD, Code de la santé publique et certification HDS

Ce que dit la réglementation

• RGPD, article 9 : les données concernant la santé font partie des catégories particulières de données, dont le traitement est en principe interdit sauf exceptions.
• RGPD, article 32 : le responsable de traitement doit mettre en place des mesures adaptées au risque et une procédure pour tester, analyser et évaluer régulièrement leur efficacité.
• Code de la santé publique, article L1111-8 : tout hébergement de données de santé à caractère personnel pour le compte d’un tiers doit être réalisé par un hébergeur certifié (ou agréé pour l’hébergement sur support papier).

Ce que recouvre la certification HDS

La certification HDS est pilotée par l’Agence du numérique en santé (ANS). Elle s’appuie sur la norme ISO/IEC 27001, complétée d’exigences propres à la santé. Un nouveau référentiel a été publié en 2024, avec une période de transition pour les hébergeurs déjà certifiés : vérifiez auprès de votre organisme certificateur l’échéance exacte qui s’applique à votre périmètre. Ce référentiel renforce notamment les exigences sur la localisation des données et la transparence vis-à-vis des clients.

L’audit regarde les processus et un échantillon de preuves. Le test d’exfiltration regarde le résultat. Les deux sont complémentaires, pas substituables. La logique est proche de celle du contrôle ISO 27001 8.12 sur la prévention des fuites de données.

Hôpital ou hébergeur HDS : des surfaces de fuite différentes

Faites défiler le tableau →

Dans un hôpital, le risque principal tient souvent à l’utilisateur de confiance pressé : l’interne qui s’envoie un compte rendu sur sa messagerie personnelle pour finir chez lui, la secrétaire médicale qui dépose un fichier sur un service de partage grand public. Ce sont les fuites du quotidien, sans malveillance, mais avec les mêmes conséquences juridiques. Chez un hébergeur, le sujet se déplace vers le réseau, les comptes à privilèges et les sous-traitants.

Scénario concret : tester sans toucher à un seul dossier patient

Prenons un centre hospitalier de taille moyenne. Le RSSI dispose d’une DLP sur la messagerie, d’un proxy web et d’une politique de blocage USB. La direction veut savoir si un fichier de patients peut sortir.

1. Fabriquer des leurres réalistes. Générer des fichiers factices qui ressemblent à de vraies données : noms fictifs, numéros au format du NIR mais invalides, comptes rendus types, exports CSV de séjours. Aucune donnée réelle n’est utilisée. C’est le principe des données factices en production.
2. Choisir des postes représentatifs. Un poste de soins partagé, un poste de secrétariat médical, un poste administratif, un serveur applicatif.
3. Rejouer les canaux un par un. Envoi par e-mail vers une adresse externe, dépôt sur un cloud personnel, copie sur support amovible, téléversement web, saisie dans un assistant d’IA générative, sortie réseau via des protocoles moins surveillés.
4. Noter trois résultats par canal. Bloqué, autorisé mais détecté (alerte au SOC ou à l’infogérant), ou passé sans trace. La troisième catégorie est celle qui compte.
5. Hiérarchiser. Classer les écarts selon le volume exposé, la facilité d’exploitation et le coût de la correction.

À vérifier avant de lancer un test dans un établissement de santé

• Validation écrite de la direction, du RSSI et du DPO, avec un périmètre précis.
• Information du SOC ou de l’infogérant, ou décision assumée de tester aussi la détection à leur insu.
• Exclusion explicite des équipements biomédicaux critiques et des postes en salle d’intervention.
• Données exclusivement factices, identifiables comme telles en cas de découverte.
• Destinations de sortie maîtrisées par l’équipe de test, purgées à la fin.
• Fenêtres de test compatibles avec l’activité de soins.
• Critère de succès défini avant le test : ce qui doit être bloqué, ce qui doit être détecté.

Un test ponctuel ne suffit pas

Un SI hospitalier change en permanence : nouvelle application de téléconsultation, mise à jour d’un logiciel de DLP, migration de la messagerie, nouveau prestataire. Une règle qui fonctionnait en janvier peut être inopérante en juin sans que personne ne s’en aperçoive. C’est pourquoi le rejeu régulier des scénarios d’attaque a plus de valeur qu’un audit annuel. Il produit une posture mesurée dans le temps, utile pour le DPO face à la CNIL, pour le RSSI face à la direction générale, et pour l’hébergeur face à ses clients et à son auditeur HDS. Pour la méthode générale, voyez notre page sur le test d’exfiltration de données.

FAQ