Chiffrement pour un éditeur SaaS en dossier HDS : architecture et preuves

Que demande vraiment le cadre HDS à un éditeur de logiciel de santé ?

La certification HDS porte sur l'hébergeur, pas sur l'éditeur. Un éditeur healthtech s'appuie sur un hébergeur certifié pour la couche d'infrastructure, mais reste responsable du chiffrement applicatif de sa solution et de la maîtrise de ses clés. C'est cette partie que l'établissement de santé, donneur d'ordre, vous demande de documenter dans son questionnaire de sécurité.

Le référentiel de certification des hébergeurs de données de santé est passé en version 2.0 par l'arrêté du 26 avril 2024, publié au Journal officiel le 16 mai 2024, avec une mise en conformité obligatoire au plus tard le 16 mai 2026 selon l'Agence du numérique en santé (ANS, page de certification HDS). Ce texte s'appuie sur la norme ISO/IEC 27001:2022, dont les mesures de cryptographie, et il renforce la transparence sur les transferts hors Espace économique européen (ANS, évolution du référentiel HDS).

La certification HDS v2 qualifie donc les activités d'hébergement, comme l'infogérance ou la sauvegarde. Elle ne dispense pas l'éditeur de prouver, de son côté, que les données de santé qu'il traite sont chiffrées et que ses clés sont gérées correctement. Un hôpital sous-traitant un traitement à votre solution vous transmet ses propres exigences de sécurité, et c'est là que se joue la signature du contrat.

Quelle base réglementaire fonde l'obligation de chiffrer ?

La base la plus solide n'est pas le référentiel HDS, c'est le RGPD. Son article 32 cite explicitement le chiffrement parmi les mesures techniques appropriées pour sécuriser un traitement, et il s'impose au responsable de traitement comme au sous-traitant. Pour un éditeur, c'est le texte à citer en priorité, car il est en vigueur et opposable sans condition de transposition.

L'article 32 du RGPD, dans le règlement (UE) 2016/679 consultable sur EUR-Lex, demande des mesures adaptées au risque et nomme le chiffrement et la pseudonymisation comme exemples. La CNIL le confirme dans ses fiches pratiques de 2024 sur le chiffrement dans l'informatique en nuage, qui rappellent que le chiffrement est une mesure de base pour le stockage de données sensibles (CNIL, pratiques de chiffrement dans le cloud). Les données de santé étant des données sensibles au sens de l'article 9, le niveau de garantie attendu est élevé.

En pratique, un éditeur solide s'appuie sur le RGPD Article 32 pour justifier son architecture, et mobilise le cadre HDS pour montrer que sa chaîne d'hébergement est certifiée. Les deux se complètent, ils ne se remplacent pas.

Faut-il chiffrer toute la base ou seulement les champs sensibles ?

Les deux répondent à des menaces différentes. Le chiffrement du disque protège contre le vol physique du support, mais laisse les données en clair dès que la base tourne. Le chiffrement applicatif, au niveau du champ, garde la donnée chiffrée jusque dans la mémoire de l'application, ce qui protège aussi contre une compromission logique de la base. Pour de la donnée de santé, c'est cette seconde couche que l'auditeur regarde.

La CNIL distingue quatre niveaux de verrouillage du chiffrement au repos dans ses fiches de 2024 : disque, fichier, base de données et applicatif (CNIL, fiches pratiques chiffrement et sécurité). Plus le verrou est proche de l'application, plus le fournisseur d'infrastructure a un accès réduit à la donnée en clair. Le chiffrement des champs sensibles répond à cette logique, et c'est le sujet d'un des articles de ce dossier.

Comment structurer les clés pour tenir dans le temps ?

Le standard de fait est l'enveloppe cryptographique. On chiffre chaque donnée avec une clé de données jetable, elle-même chiffrée par une clé maîtresse conservée dans un module dédié. Ce schéma permet de tourner les clés sans re-chiffrer toutes les données historiques, et de réduire la surface exposée si une clé de données fuite. C'est l'architecture attendue sur un volume de données de santé qui vit plusieurs années.

L'enveloppe cryptographique, ou envelope encryption, repose sur une DEK aléatoire par opération et une KEK qui l'enveloppe. Le NIST décrit ce modèle et recommande des durées d'usage des clés dans sa publication SP 800-57 Part 1 Révision 5 (NIST, Recommendation for Key Management). MAFATE implémente ce schéma en AES-256-GCM, et le détail de l'architecture est développé dans un article dédié de ce dossier.

Que doit contenir le journal d'audit pour être opposable ?

Un journal opposable trace chaque opération sensible, résiste à la modification a posteriori et se vérifie. Une simple table de logs applicatifs ne suffit pas, car rien n'empêche de la réécrire. L'exigence pratique est un journal chaîné, où chaque entrée dépend de la précédente, de sorte qu'une altération devienne détectable, et un export qui prouve son intégrité.

Le NIST rappelle dans sa publication SP 800-57 que la sécurité des données chiffrées ne vaut que par la protection accordée aux clés et à leur traçabilité. La CNIL, dans ses fiches de 2024, recommande des audits réguliers des accès aux données comme aux clés. MAFATE produit un journal chaîné par HMAC-SHA256 avec vérification d'intégrité sur tout export, sujet traité en détail plus loin dans ce dossier, et documenté côté intégration (guide audit et conformité).

Faut-il un HSM, et lequel ?

Un module de sécurité protège la clé maîtresse en la gardant hors de la mémoire applicative. La vraie question pour un éditeur n'est pas d'exhiber un matériel certifié, c'est de démontrer que la clé maîtresse n'est jamais exposée en clair et que son usage est tracé. Le niveau de certification du module devient un argument à mesure que le donneur d'ordre est exigeant.

Un HSM matériel certifié apporte une garantie forte, mais un module logiciel correctement isolé répond déjà à l'essentiel de l'exigence pour un mid-market. Il faut le dire sans ambiguïté : MAFATE utilise aujourd'hui un HSM logiciel PKCS#11, avec une migration vers un HSM matériel FIPS 140-2 planifiée. Ce point, et la transition FIPS en cours au NIST, font l'objet du dernier article de ce dossier.

Que faut-il pouvoir montrer à un auditeur, concrètement ?

Trois choses : l'inventaire des algorithmes et des clés, la preuve du cycle de vie des clés, et un journal d'audit vérifiable. Un rapport de conformité qui agrège ces éléments accélère considérablement la réponse à un questionnaire de sécurité, à condition de rester honnête sur son statut : il contribue au dossier, il ne constitue pas un certificat.

MAFATE génère des rapports adossés au preset RGPD Article 32, exportables en PDF, CSV ou JSON, à partir des journaux d'audit réels du tenant (documentation de vérification des attestations). Ces rapports ne sont pas signés cryptographiquement et ne remplacent pas une certification : ils rassemblent la preuve que l'auditeur demande. Pour un éditeur healthtech, c'est la différence entre répondre en dix minutes et collecter des documents pendant deux semaines. La brique de chiffrement et les preuves qui alimentent votre dossier sont détaillées sur la page solutions santé et sur la page conformité.

Ce dossier détaille chacun de ces points au fil de la semaine. Si vous avez un contrat de santé bloqué par une exigence de chiffrement ou un questionnaire de sécurité en attente, parlez à un ingénieur.