Après plusieurs centaines de discussions avec des éditeurs logiciels en e-santé, voici la réponse TRÈS courante que je reçois : nous avons déjà du chiffrement de bout-en-bout, car nous sommes HDS.

Nous sommes en juin 2023, une époque où chaque mois nous pouvons lire qu’une nouvelle fuite de données médicales a eu lieu.

Plus que jamais, les responsables techniques des solutions de e-santé ont besoin de comprendre la différence entre la certification HDS et le chiffrement de bout-en-bout.

La certification HDS et le chiffrement de bout-en-bout sont deux notions distinctes, et ont tous deux un rôle essentiel à jouer dans la protection des données de santé. Il est donc crucial de les distinguer et de les intégrer efficacement dans la stratégie de sécurité des données de santé.

Qu’est-ce qu’une certification HDS ?

Il existe plusieurs périmètres pour l’HDS divisés en deux grandes catégories :

  • « Hébergeur d’infrastructure physique » qui encadre la façon dont l’hébergement est physiquement géré.
  • « Hébergeur infogéreur » qui encadre la façon dont l’hébergement est administré.

La certification est délivrée après un audit, qui vérifiera point par point le référentiel de certification, équivalent aux normes ISO 27001 et ISO 20000.

L’objectif est de vérifier la bonne gestion des serveurs : mise à jour, sauvegardes, chiffrement des connexions, protections physiques, accès à privilège, etc. mais sans rentrer dans le code applicatif ou seulement marginalement.

Bien qu’un flou existe sur la nécessité que les éditeurs et fabricants de dispositifs médicaux soient certifiés pour leur activité d’infogérance, tout fournisseur de solution portant sur des données de santé à caractère personnel pour le compte d’un patient ou d’un professionnel de santé est tenu d’être certifié.

C’est pourquoi certains éditeurs délèguent à des tiers infogéreurs le déploiement de l’application qu’ils éditent pour ne pas avoir à passer cette certification eux-mêmes, mais ces éditeurs n’ont alors pas accès à leurs propres serveurs de production, seuls les infogéreurs y ont accès.

En prenant un peu de recul, la certification HDS quel que soit le périmètre se concentre sur la sécurité de l’infrastructure et de sa bonne gestion (c'est déjà un très bon pas en avant) !

Néanmoins, en aucun cas le fait d’avoir une certification HDS empêche l'infogéreur de lire les données, ou empêche un attaquant de pénétrer le serveur grâce à une faille applicative. Le seul chiffrement obligatoire dans HDS est pour tout ce qui rentre et sort de l’hébergement, c’est-à-dire de l’HTTPS concrètement (ce qui est dérisoire)… HDS n’inclut pas du tout du chiffrement de bout-en-bout.

Il est tout à fait possible d’utiliser un serveur HDS et de ne pas faire de chiffrement sur les données au repos ou de bout-en-bout. Pour autant, le RGPD s’applique aussi sur les données de santé, et ce règlement requiert l’implémentation de chiffrement minimisant les droits d’accès à leur strict minimum : du chiffrement de bout-en-bout dès qu’il est possible.

Qu'est-ce que le chiffrement de bout-en-bout ?


Pour bien comprendre à quoi sert le chiffrement de bout-en-bout, il est important de rappeler rapidement les autres techniques de chiffrements communément utilisées.

Le chiffrement en transit

Le chiffrement en transit (comme du TLS) permet de sécuriser un « tuyau », tout ce qu’il y a dedans est protégé. Avant et après le tuyau, ça ne l’est pas.

Ce schéma illustre le rôle que joue le chiffrement en transit dans la protection des données. À gauche, l'utilisateur 1 dans son application, qui envoie le message "Hello" à destination de l'utilisateur 2. Le message est envoyé à travers la connexion TLS, le « tuyau sécurisé », qui sert de pont entre l'application et le serveur backend. Au milieu, le serveur backend qui reçoit le message "Hello", prêt à être redistribué à l'utilisateur 2. Le chiffrement en transit garantit que le message reste sécurisé pendant son voyage de l'utilisateur 1 au serveur backend, puis du backend à l'utilisateur 2. On voit donc qu'avec le seul chiffrement en transit, le backend a un accès aux données.

Le chiffrement au repos

Le chiffrement au repos (comme du chiffrement de disque dur, de base de données ou de stockage objet) permet de sécuriser les données lorsqu’elles ne sont pas utilisées. Si quelqu’un s’introduit dans le bâtiment qui contient les disques durs contenant les données et les vole, il ne pourra rien en faire. En revanche, si quelqu’un accède au backend (via une faille applicative par exemple), il aura accès à tout.

Ce schéma illustre le rôle que joue le chiffrement au repos dans la protection des données. Considérons que l'application possède un historique des messages ; ces données doivent donc être stockées sur un serveur (stockage) afin de conserver cet historique. Une fois que le serveur backend a fini de transmettre le message " Hello " aux utilisateurs, il peut alors procéder au chiffrement du message et l'envoyer sur le serveur de stockage, assurant ainsi sa sécurité au repos.

Le schéma ci-dessus représente l'architecture de sécurité des données de la majorité des applications dans le monde. On voit que le serveur backend a accès aux données des utilisateurs, et donc quiconque qui accède au serveur backend aussi.

Le chiffrement de bout-en-bout

Le chiffrement de bout-en-bout protège les données depuis l'appareil de l'expéditeur, le premier "bout", jusqu'à l'appareil du destinataire final, le second "bout", sans interruption. Cela garantit que les données sont accessibles uniquement par l'expéditeur et le destinataire final.

Pas même l’hébergeur des données, le développeur de l’application, un quelconque administrateur, ou un gouvernement, et par extension toute personne malveillante s’en prenant à un ou plusieurs de ces intermédiaires ne pourront accéder aux données.

Ce schéma illustre le rôle que joue le chiffrement de bout-en-bout dans la protection des données. Le chiffrement de bout-en-bout va protéger côté client le message "Hello" pour l'utilisateur 1 et pour l'utilisateur 2 uniquement. Ainsi, le serveur backend n'a jamais accès au message, garantissant que le message demeure confidentiel, même face à d'éventuelles compromissions des serveurs de l'application.

Si une application utilise du chiffrement de bout-en-bout, cela garantit que les employés de l’entreprise éditant ou infogérant l’application ne pourront pas accéder aux données hébergées comme les conversations, fichiers ou autres, que l'hébergeur soit HDS ou non.

À l'inverse, sans chiffrement de bout-en-bout, le non-accès aux données dépend du bon vouloir de l’entreprise, parce qu’il n’y a aucune mesure technique garantissant que ses employés ne peuvent pas y accéder.

Si un employé est malveillant, négligeant, ou simplement qu’une vulnérabilité "zero day" est découverte permettant à un attaquant de s’introduire (comme on en trouve tous les jours) et que l’hébergeur ne la patche pas assez vite, le bon vouloir de l’entreprise ne suffira pas à protéger les données des utilisateurs...

En conclusion, non, la certification HDS n’est pas du tout équivalente à faire du chiffrement de bout-en-bout.