Les erreurs fréquentes dans l’échange d’informations médicales

Les erreurs dans l'échange d'informations médicales sont récurrentes : tokens à durée excessive, absence de validation des entrées, comptes partagés et interfaces de maintenance non sécurisées.

M
Mehdi SARIAK
24 mai 2026 7 min de lecture 14 lectures

Points clés

  • Les erreurs dans l'échange d'informations médicales sont récurrentes et documentées dans les audits de sécurité des SI de santé.
  • Les plus fréquentes touchent aux contrôles d'accès, à la gestion des identités des tiers, au chiffrement des flux, et à la validation des données entrantes.
  • Ces erreurs ne sont pas uniquement techniques — elles reflètent des lacunes organisationnelles dans la gouvernance des interfaces.
  • Un audit régulier des interfaces d'échange est la méthode la plus efficace pour identifier et corriger ces erreurs avant qu'elles ne soient exploitées.
Cas US Yahoo (gestion des accès) — La gestion défaillante des sessions et des tokens d'authentification chez Yahoo a permis aux attaquants de forger des cookies d'authentification valides sans connaître les mots de passe. Dans le contexte des échanges de données de santé, une validation insuffisante des tokens OAuth2/SMART on FHIR produit le même type de vulnérabilité : un attaquant peut usurper l'identité d'un système de santé légitime pour accéder à des données médicales sans authentification valide.

Erreur 1 : tokens d'accès à durée de vie trop longue

Les tokens OAuth2 utilisés pour les échanges FHIR ont souvent des durées de vie excessives — plusieurs heures ou plusieurs jours. Un token compromis reste valide pendant toute sa durée de vie, permettant un accès non autorisé prolongé. La bonne pratique est de configurer des access tokens de courte durée (15 à 30 minutes maximum) avec des refresh tokens à usage limité, stockés et transmis de manière sécurisée. Les systèmes legacy utilisant des clés API statiques (sans expiration ni rotation) constituent une vulnérabilité particulièrement grave.

Erreur 2 : absence de validation des données entrantes

Les interfaces qui acceptent des données entrantes sans validation rigoureuse (format, valeurs, cohérence) sont exposées à des attaques par injection (SQL injection dans les parseurs, XML injection dans les messages HL7, XXE dans les flux FHIR). La validation doit être implémentée au niveau de chaque point d'entrée : validation du schéma (conformité au profil FHIR ou au segment HL7 attendu), validation du contenu (plages de valeurs acceptables), et filtrage des contenus malveillants. Le simple fait de « faire confiance » aux données envoyées par un partenaire est une erreur de conception.

Erreur 3 : comptes de service partagés entre systèmes

L'utilisation d'un compte de service partagé entre plusieurs systèmes ou plusieurs partenaires pour les échanges de données est une pratique encore fréquente dans les SI de santé. Elle empêche toute traçabilité individuelle des accès, ne permet pas de révoquer l'accès d'un seul système sans impacter les autres, et crée une dépendance forte à la confidentialité du credential partagé. Chaque système ou partenaire doit disposer d'une identité distincte avec des droits limités à ses besoins propres.

Cas EU British Airways (2018) — L'injection de code malveillant dans le site de British Airways a été rendue possible par une absence de validation côté serveur des requêtes JavaScript tierces. Dans le contexte des échanges médicaux, des erreurs similaires de validation des flux entrants — notamment dans les portails de santé permettant l'accès aux données patients — peuvent permettre l'injection de contenu malveillant récupérant les identifiants des professionnels de santé.

Erreur 4 : interfaces de maintenance non sécurisées

Les interfaces de maintenance et d'administration des systèmes d'échange (console d'administration HAPI FHIR, interface de monitoring HL7, tableau de bord d'un middleware d'intégration) sont souvent accessibles sur le même réseau que les interfaces de production, avec des authentifications moins strictes ou des comptes génériques. Ces interfaces sont des cibles de choix pour les attaquants qui souhaitent accéder à la configuration complète du système d'échange. Elles doivent être isolées sur un réseau dédié, protégées par une authentification forte, et accessibles uniquement depuis des postes d'administration identifiés.

Erreur 5 : absence de tests de sécurité des interfaces

Les tests de sécurité des interfaces d'échange sont rarement inclus dans les cycles de recette des projets de santé numérique. Les tests fonctionnels vérifient que les données sont correctement échangées — pas que les contrôles de sécurité résistent à une tentative d'attaque. Des tests spécifiques (test d'intrusion des APIs, fuzz testing des parseurs HL7/FHIR, validation de la configuration OAuth2) devraient être réalisés avant la mise en production de toute nouvelle interface d'échange de données de santé, et répétés périodiquement.

Cas Asie SingHealth (2018) — L'intrusion dans la base de données patients de SingHealth a exploité des comptes avec des droits d'accès excessifs et des mots de passe insuffisamment robustes. Ces erreurs — comptes sur-privilégiés, authentification faible — font partie des erreurs les plus fréquentes identifiées dans les audits des systèmes d'échange de données médicales. La mise en œuvre du principe du moindre privilège et de l'authentification forte pour tous les accès aux systèmes d'échange aurait limité significativement la portée de la compromission.
WhatsApp