Quand on développe une application manipulant des données médicales dans une plateforme d'échange de documents ou de chat, comment protéger ces données pour les mettre à disposition d'utilisateurs tels que des praticiens, patients, pharmaciens ou encore des gestionnaires d'assurance ?

Contexte

Avec la transformation numérique de la société — qui s'est accélérée depuis la crise sanitaire de la Covid-19 — de nombreux échanges entre patients et professionnels de santé ne peuvent plus s'effectuer face à face et se font par des solutions numériques dédiées. Il en va de même pour d'autres activités manipulant des données médicales (assurance, crédit, etc.).

Les données échangées sont extrêmement sensibles pour plusieurs raisons :

  • leur fuite serait extrêmement dommageable pour la réputation du fournisseur de service ;
  • l'hébergement non souverain de ces données peut être risqué pour des personnes exposées politiquement ;
  • il s'agit de données personnelles soumises au RGPD ;
  • il s'agit de données médicales soumises au secret médical au titre de l'article 226-13 du code pénal.

Si les deux premières raisons peuvent être considérées comme étant spéculatives, les deux dernières elles sont associées à des sanctions pécuniaires et pénales dissuasives (4 % du chiffre d'affaires d'amende, peine d'emprisonnement, etc.) qui ont déjà été appliquées par le passé.

La protection de ces données est donc un enjeu stratégique !

Comment alors les protéger efficacement ?

En France, il est nécessaire (Article L1111-8 du code de la santé publique) de stocker les données de santé sur un hébergeur de données de santé (HDS) (liste des hébergeurs certifiés). Est-ce vraiment suffisant ?

Hébergement de Données de Santé

Les solutions d'HDS offrent un certain niveau de garantie quant à la sécurité d'accès physique ou logique aux serveurs et quant à l'amélioration continue de la sécurité. Ce n'est en revanche pas suffisant pour assurer un niveau de protection des données satisfaisant : les données qui y sont stockées seraient lisibles par n'importe quel attaquant qui parviendrait à compromettre le serveur

Si de plus l'hébergeur est non européen, on peut légitimement se poser la question de la souveraineté des données !

Outre les aspects techniques et géopolitiques, l'utilisation d'un HDS ne répond pas à l'impératif de l'article 32-a du RGPD indiquant qu'il faut anonymiser, pseudonymiser ou chiffrer les données à caractère personnel.

Du chiffrement côté serveur ?

En complément d'un HDS, il est possible d'adosser des systèmes de chiffrement côté serveur (avec des KMS, des HSM ou par une clé configurée dans l'applicatif). Ceux-ci sont couramment proposés par les fournisseurs de Cloud eux-mêmes. Sont-ils vraiment efficaces ? De quoi protègent-ils vraiment ?

Ils permettent de réduire la surface d'attaque. Par exemple si un attaquant arrivait à compromettre seulement le bucket de stockage, ou la base de données, mais pas le serveur applicatif, il ne pourra pas déchiffrer les données.

En revanche, en cas de compromission du serveur applicatif (qui lui a toutes les pièces du puzzle pour reconstituer les données en clair) : l'attaquant aurait accès à tout. Ce genre d'attaque arrive, et même à des entreprises dont on pensait que la sécurité était inviolable !

Le RGPD ne précise pas si une telle solution de chiffrement répond à l'article 32 ou non, il reste volontairement flou en laissant le couperet de l'obligation de résultat tomber en cas de fuite.

Du chiffrement côté client !

La véritable solution à ce problème est de faire en sorte que les serveurs n'aient plus accès aux données sensibles avec du chiffrement côté client, dit "de bout en bout". Ainsi, si un attaquant parvenait à compromettre les serveurs, il ne pourrait pas accéder aux données, puisque les clés permettant le déchiffrement ne sont pas accessibles au serveur, donc pas à un quelconque attaquant non plus.

Avec le SDK Seald vous pouvez directement intégrer du chiffrement de bout-en-bout dans vos applications sur les données que vous voulez protéger, que ce soient des documents, des entrées en base de données, etc.

Les avantages du SDK Seald sont :

  • sa robustesse : le SDK Seald a été audité par une société tierce et est en cours de certification auprès de l'ANSSI, vous assurant ainsi d'utiliser des primitives de chiffrement et des protocoles d'échange de clés robustes ;
  • sa facilité d'intégration : il est disponible en Node.js, Javascript navigateur, React-Native ou même en micro-service conteneurisé et est directement utilisable par vos développeurs sans connaissance préalable en cryptographie et dans toutes vos applications ;
  • sa souplesse : il est possible de modifier les personnes autorisées à déchiffrer une donnée a posteriori sans modifier la donnée stockée et de mettre en place des mécanismes de récupération en cas de perte des clés des utilisateurs (oubli de mot de passe, etc.) ;

Une API Rest est évidemment disponible pour administrer les utilisateurs, associer leur identité Seald avec l'identité applicative et tracer l'activité (ouverture, modification de droits, etc.) de chaque utilisateur.

Conclusion

Protéger les données médicales que l'on collecte, stocke et envoie est un enjeu stratégique dans le monde numérique d'aujourd'hui. L'arsenal de solutions possibles peut parfois étourdir les décideurs qui doivent prendre une décision en ayant une fausse idée de la sécurité que la solution choisie apporte.

Mettre en place de véritables solutions de chiffrement protégeant de bout-en-bout les données de ses utilisateurs est un chantier qui peut paraître titanesque, surtout quand on n'a pas de compétence en cryptographie appliquée.

C'est pour cela que Seald fournit un SDK clé-en-main permettant d'intégrer de telles technologies très facilement et très rapidement sans expertise dans vos solutions.

Contactez nos équipes pour en savoir plus !