Le service documentaire · chiffrement, accès, et les limites réelles
Chaque affirmation de conformité de ce site — l’américaine, l’européenne, la britannique, l’allemande — finit par désigner une même mécanique : le service qui stocke les documents cliniques. Cette page explique comment il fonctionne, en langage ordinaire, puis fait quelque chose que la plupart des documentations fournisseur évitent.
Elle énumère les risques qui n’ont pas de correctif technique. Pas ceux que nous avons résolus et dont nous aimerions parler — ceux où la réponse honnête est « cela peut arriver, voici pourquoi nous l’avons choisi, et voici ce que vous devez faire ». Si vous ne lisez qu’une section, lisez celle-là.
Imaginez chaque document clinique dans une boîte avec son propre cadenas, et chaque cadenas avec une clé différente. Ces clés sont elles-mêmes enfermées dans un coffre. Les documents et les petites clés vivent dans votre base de données. La clé du coffre, non.
C’est toute la conception. Tout ce qui suit en est le détail, et les conséquences méritent d’être posées avant la mécanique :
Celui qui copie toute votre base de données obtient les boîtes et les petites clés verrouillées. Sans la clé du coffre, rien ne s’ouvre. C’est ce qui met à votre portée l’exemption pour chiffrement du droit des violations — vous pouvez soutenir que les données étaient inintelligibles, à condition que la clé du coffre n’ait pas été emportée elle aussi.
Pour supprimer un document, vous détruisez sa petite clé. La boîte demeure, vide et à jamais inouvrable. C’est plus fort que d’effacer une ligne — une ligne effacée revient de la sauvegarde d’hier soir, une clé détruite non.
Il n’y a pas de copie maîtresse, pas de séquestre chez l’éditeur, pas de service de récupération. Si la clé du coffre disparaît, chaque document clinique que vous détenez disparaît avec elle. C’est délibéré, et la section 05 explique pourquoi toute « solution » serait pire que le problème.
La technique s’appelle le chiffrement enveloppe, et c’est celle qu’utilisent les banques et les fournisseurs de nuage pour le même problème. Il y a trois couches. La raison pour laquelle il y en a trois plutôt qu’une est dans la troisième colonne.
| Couche | Ce que c’est | Pourquoi elle est séparée |
|---|---|---|
| La version du document | Le fichier lui-même — un compte rendu de séance, un signalement d’incident, une pièce d’identité — chiffré avec AES-256-GCM. Le résultat chiffré est écrit dans un répertoire à part sur le disque, hors du stockage de fichiers ordinaire d’Odoo, et n’est jamais servi par la route de téléchargement normale. | Garder le texte chiffré hors de la zone de fichiers ordinaire signifie qu’un serveur web mal configuré ne peut pas publier des fichiers cliniques par accident, parce qu’ils ne sont pas là où un serveur web regarderait. |
| La clé de données (DEK) | Une nouvelle clé aléatoire de 256 bits, générée pour chaque version de chaque document. Pas par patient, pas par document : par version. Elle est stockée dans la base de données, mais seulement sous forme enveloppée. | Une clé par version, c’est ce qui rend la suppression précise. Détruire la clé d’une version supprime exactement cette version et rien d’autre : une correction peut donc être conservée pendant que l’original est supprimé, ou l’inverse. |
| La clé de déploiement (KEK) | Une seule clé de 256 bits pour toute l’installation, détenue dans un fichier sur le serveur, qui enveloppe toutes les clés de données. Elle n’est jamais stockée dans la base de données et ne quitte jamais le serveur. | C’est la séparation qui fait le travail. La base de données et les clés sont des choses différentes, dans des endroits différents, avec des sauvegardes différentes : obtenir l’une ne donne donc pas l’autre. |
Six choses existent pour chaque version de document. Elles sont délibérément gardées à des endroits différents, car toute la conception repose sur le fait qu’aucun endroit n’en détient deux.
| La pièce | Où elle est gardée | Ce que le fait de n’avoir que cela vous donne |
|---|---|---|
| Le fichier lui-même, chiffré | Un répertoire à part sur le serveur, disposé comme
<store>/<first 2 of uuid>/<next 2>/<uuid>.enc.v<version>. Les répertoires sont accessibles au seul propriétaire, les fichiers en lecture-écriture pour le propriétaire. Hors du stockage de fichiers d’Odoo, donc inatteignable par /web/content et non touché par le ramasse-miettes des pièces jointes. |
Rien. Du texte chiffré authentifié sans clé. Un fichier par version, si bien que classer une nouvelle version ne peut pas écraser la précédente. |
| Le nonce et deux empreintes | Dans la base de données, sur la ligne de la version : le nonce utilisé pour ce chiffrement, une empreinte du texte en clair, et une empreinte du texte chiffré. | Rien à elles seules — mais l’empreinte du clair est nécessaire pour reconstruire la liaison décrite plus bas : la perdre rend donc le texte chiffré indéchiffrable. C’est par conception, pas par oubli. |
| La clé de données, enveloppée | Dans la base de données, chiffrée sous la clé de déploiement. La forme déballée n’existe qu’en mémoire, le temps d’une lecture, et est jetée immédiatement après. | Rien sans la clé de déploiement. Une base de données volée vous donne des clés enveloppées et des chemins de texte chiffré, et ni l’un ni l’autre n’ouvre quoi que ce soit. |
| La clé de déploiement | Un fichier sur le serveur, lisible seulement par le compte sous lequel tourne Odoo. Jamais dans la base de données. Jamais dans le stockage de fichiers. Jamais à l’intérieur d’une racine de sauvegarde déclarée — chacun de ces points est vérifié au démarrage et est bloquant, pas un avertissement. | Rien sans la base de données, qui détient les clés de données enveloppées, et sans le magasin de texte chiffré. Trois choses distinctes sont nécessaires, et elles sont gardées à trois endroits. |
| Les règles d’accès | Dans la base de données, sous forme d’enregistrements — qui peut ouvrir quoi, à quel titre, et jusqu’à quand. | Elles décident de ce qu’un collègue peut ouvrir. Elles n’ont aucun effet sur quelqu’un qui a les fichiers mais pas les clés, ce qui est précisément le cas pour lequel le chiffrement existe. |
| Le journal d’accès | Dans la base de données, en ajout seul et chaîné par empreinte. Chaque lecture, pas seulement chaque modification. | Le relevé de qui a ouvert quoi. Il est écrit avant que le contenu soit remis : un téléchargement que quelqu’un annule est donc tout de même consigné comme un accès. |
Tout ce qui précède est plus facile à vérifier avec ces deux flux. Le premier est ce qui se passe quand un document est classé ; le second, ce qui se passe quand quelqu’un demande à en voir un. Lisez le second attentivement — c’est là que la plupart des systèmes sont plus faibles qu’ils ne le prétendent.
Un compte rendu de séance, un signalement d’incident, une pièce d’identité. Il arrive en mémoire.
32 octets issus de la source cryptographique aléatoire du système d’exploitation. Pas dérivée d’un mot de passe, pas réutilisée d’un autre document, pas réutilisée de la version précédente de ce document.
une clé par version — c’est ce qui rend la suppression préciseUn SHA-256 du texte en clair, et un nombre de 96 bits utilisé une seule fois. Aucune fonction du cœur de chiffrement n’accepte un nonce fourni par l’appelant : l’erreur classique de réutilisation ne peut donc pas être commise ici.
AES-256-GCM, avec uuid | numéro de version | empreinte du contenu comme données authentifiées supplémentaires. Cette liaison est obligatoire. Un texte chiffré ensuite copié sur un autre document ou une autre version refusera de se déchiffrer plutôt que de s’ouvrir en silence sous les règles d’accès de la mauvaise personne.
Chiffrée avec la clé de déploiement, étiquetée avec la génération de clé et l’espace de noms, et stockée dans la base de données sous cette forme. La clé déballée est immédiatement jetée de la mémoire.
Écrit dans un fichier temporaire du répertoire de destination, vidé sur le disque physique, puis renommé en place — de sorte qu’un plantage en cours d’écriture ne peut pas laisser une demi-version. Le fichier temporaire contient du texte chiffré, jamais du clair.
Chemin de stockage, nonce, les deux empreintes, la taille, et la clé enveloppée. Jamais le texte en clair, jamais une clé déballée, jamais la clé de déploiement.
Qui l’a classé, quand, quelle taille, et quel type. En ajout seul et chaîné aux entrées précédentes.
Un clinicien dans le back-office, ou un patient sur sa propre page de dossiers. Les deux passent par les mêmes contrôles ; aucune voie ne contourne ceux de l’autre.
Sur la voie côté patient, les dossiers ne sont pas montrés à un compte qui n’a qu’un mot de passe. Le refus dit quoi faire plutôt que de prétendre que le document n’existe pas.
Une limite de débit par personne sur la voie côté patient. Dite clairement, car le dire ne divulgue rien et évite un appel au support.
Les règles de refus d’abord — une seule est définitive. Puis les règles d’autorisation : si aucune ne correspond, la réponse est non. L’accès d’urgence n’est consulté qu’à ce moment-là, si bien qu’il peut atteindre ce qui n’a jamais été accordé mais ne peut pas renverser un refus. Les étiquettes de sensibilité s’appliquent en dernier et ne peuvent que retirer de l’accès.
fermé par défaut · aucune branche superutilisateur n’existe dans ce contrôleL’entrée est écrite d’abord, si bien qu’un transfert interrompu à mi-course figure tout de même comme un accès. Le journal est en ajout seul et chaîné par empreinte ; les entrées ne peuvent pas être discrètement retirées après coup, ni par nous ni par votre propre administration.
Avant de toucher la moindre clé. Une corruption dans le magasin est ainsi signalée comme une corruption, plutôt que de ressurgir plus tard comme un échec d’authentification déroutant.
Utilisée pour déballer la clé de données de cette version, en vérifiant au passage la génération de clé et l’espace de noms. Une clé enveloppée pour un espace de noms ne peut pas être déballée comme un autre, même par quelqu’un qui détient les deux clés de déploiement.
L’identifiant du document, le numéro de version et l’empreinte du contenu sont reconstruits et doivent correspondre. Une altération, une mauvaise clé et un texte chiffré déplacé depuis un autre dossier échouent tous ici — et tous échouent de façon identique, car dire à un attaquant quelle partie a échoué est une information gratuite.
La clé de données est retirée de la mémoire. Aucun chemin de code de ce produit n’écrit un octet déchiffré sur le disque — ni pour les aperçus, ni pour les vignettes, ni pour l’indexation de recherche.
Une version supprimée signale que sa clé n’existe plus. Il n’y a pas de repli, pas de copie en cache et pas de voie de récupération, ce qui est tout l’intérêt de supprimer de cette façon.
Une seule clé protège toutes les clés de données de l’installation : son maniement est donc la partie à vérifier ligne à ligne. Tous les contrôles ci-dessous s’exécutent au démarrage et tous sont bloquants — le serveur ne démarre pas plutôt que de tourner avec une protection que vous croyez avoir sans l’avoir.
32 octets issus de la source aléatoire du système d’exploitation, écrits dans un fichier créé avec la permission de lecture pour le seul propriétaire, en une seule opération, de sorte qu’il n’est jamais brièvement lisible par quelqu’un d’autre.
Le fichier doit contenir soit 32 octets bruts, soit 64 caractères hexadécimaux. Rien d’autre n’est accepté — une phrase de passe est refusée plutôt qu’étirée en clé, car une phrase de passe étirée est une clé plus faible qui a l’air plus forte.
Pas dans la base de données. Pas dans le répertoire de données d’Odoo, son chemin d’addons ou son stockage de fichiers. Pas à l’intérieur du magasin de texte chiffré. Pas à l’intérieur d’un répertoire que vous avez déclaré comme racine de sauvegarde.
C’est ce dernier point que les gens ratent. Une sauvegarde contenant à la fois la base de données et la clé est une clé compromise, et cela place le déploiement hors du safe harbour américain et hors de l’exemption européenne de l’art. 34(3)(a) — qui est la raison même de la présence du chiffrement.
Faire tourner la clé de déploiement ré-enveloppe les clés de données et ne réécrit pas un seul octet de texte chiffré. Cent mille documents tournent aussi vite que cent clés peuvent être rechiffrées, pas aussi vite que cent mille fichiers peuvent être réécrits.
Le numéro de génération est à l’intérieur de l’enveloppe : une clé enveloppée sous l’ancienne génération ne peut donc pas être ouverte en silence comme si c’était la nouvelle.
Supprimer une version écrase sa clé enveloppée avec des octets aléatoires plutôt que de vider le champ : il ne reste donc rien à récupérer, même depuis la page de la base de données.
L’enveloppe de métadonnées de la version et tout le journal d’accès survivent — vous pouvez encore prouver que vous déteniez le document et que vous l’avez supprimé correctement. Une version ne peut pas être effacée tant que sa clé existe encore, si bien que l’ordre ne peut jamais être inversé.
Ce sont les endroits où le chiffrement est habituellement implémenté presque correctement, et le presque fait toute la différence.
Quand une version est chiffrée, le chiffrement est lié à l’identifiant de ce document, à son numéro de version et à une empreinte de son contenu. Les cryptographes appellent cela les données authentifiées supplémentaires, et c’est obligatoire ici : aucun appelant ne peut s’en passer.
L’effet : un texte chiffré copié sur un autre document, ou sur une autre version, refuse de se déchiffrer. Il ne s’ouvre pas en silence sous les règles d’accès du mauvais patient — ce qui est précisément l’attaque à laquelle un système sans cette liaison est exposé.
AES-GCM est catastrophiquement faible si le même nonce est utilisé deux fois avec la même clé : un attaquant qui voit deux textes chiffrés de ce genre peut récupérer de l’information dans les deux. C’est l’erreur d’implémentation classique.
Ici, chaque chiffrement génère son propre nonce et aucune fonction n’accepte un nonce fourni par l’appelant. L’erreur n’est pas rendue plus difficile à commettre ; elle est rendue impossible à commettre.
Le cœur de chiffrement est écrit comme une pièce autonome sans dépendance au cadre applicatif, de sorte que quelqu’un qui audite l’affirmation sur le chiffrement peut le lire et le tester seul, sans faire tourner un système de cabinet.
Si votre équipe sécurité veut vérifier les affirmations de cette page plutôt que les croire, c’est ce fichier qu’il faut leur donner, et il est court.
Là où la loi sépare les notes de processus du thérapeute du dossier clinique — l’exception américaine sur les notes de psychothérapie en est le cas le plus clair — ces notes sont chiffrées sous une seconde clé de déploiement, différente. La clé qui ouvre le dossier ordinaire ne les ouvre pas.
Cela compte parce que la séparation devient une propriété du stockage plutôt que des règles d’accès. Si demain toutes les permissions du système étaient fausses, la clé ordinaire ne déchiffrerait toujours pas ces notes. Cela signifie aussi que la seconde clé doit être configurée avant la mise en service : classer une telle note sans elle échoue plutôt que de retomber discrètement sur la clé principale, car un repli silencieux détruirait la séparation sans que personne s’en aperçoive.
On confond souvent les deux. Le chiffrement protège contre quelqu’un qui ne devrait pas être dans le système du tout. Il ne fait rien contre le problème bien plus fréquent : quelqu’un qui est dans le système et regarde un dossier qu’il n’a aucune raison de lire.
C’est à cela que sert la couche d’autorisation, et elle fonctionne sur un principe différent de la plupart des systèmes : l’accès suit la relation de traitement, pas l’intitulé du poste.
Chaque fois. Pas une fois à la connexion.
Indiqué explicitement, parce que les auditeurs le demandent
Un clinicien a parfois réellement besoin d’un dossier avec lequel il n’a aucune relation — une crise, un appel hors horaires, un collègue tombé malade. Là où votre organisation le permet, l’accès par bris de glace est disponible. L’utiliser ouvre une session consignée qui est revue ensuite.
Un système qui ne fait que refuser est dangereux à sa manière, et au Royaume-Uni il est explicitement non conforme : le principe Caldicott 7 rend le devoir de partager aussi important que le devoir de protéger. L’accès existe donc, et son usage n’est jamais silencieux.
Contre un type de document — c’est ce type qui décide des règles, de la durée de conservation et de qui peut l’ouvrir.
En mots simples, avant qu’il soit enregistré. La plupart des erreurs de classement viennent de ce que personne ne savait où un document allait atterrir.
Lié à ce document, à cette version, et à une empreinte de ce contenu.
La clé déballée n’existe qu’en mémoire, le temps où elle est nécessaire.
Avec ses propres permissions, dans son propre répertoire.
Chaque ouverture journalisée avant que le contenu n’apparaisse.
Comme une nouvelle version, avec sa propre nouvelle clé. L’original est intact et toujours lisible — un dossier modifiable ne vaut rien comme preuve.
Il refuse de se déchiffrer, parce que le chiffrement est lié à l’identité du document d’origine.
À partir de la fin de la relation — pas du jour où le fichier a été créé.
Le matériel de clé est écrasé par des octets aléatoires, puis la ligne de clé est effacée. Écraser d’abord est délibéré : si le processus est interrompu, le mode de défaillance est un document illisible, jamais un document qui survit alors qu’il n’aurait pas dû.
Vous pouvez encore prouver que le dossier a existé, qui l’a vu pendant vingt ans, et qu’il a été supprimé dans les temps. Le contenu est illisible par quiconque, définitivement, nous compris.
Tout ce qui précède est ce que le système fait bien. Cette section est l’inverse : les endroits où quelque chose de grave peut arriver et où aucune quantité d’ingénierie ne le referme — parce que le refermer coûterait plus de protection que cela n’en achète.
Chacun dit ce qui se passe réellement, ce que nous en faisons, et ce qui reste de votre côté. Si un fournisseur vous dit que son chiffrement n’a aucun de ces risques, soit il n’y a pas réfléchi, soit il espère que vous non plus.
Ce qui se passe : le fichier de clé est effacé, le disque tombe, le serveur est reconstruit sans elle, ou la seule personne qui savait où elle était est partie. Chaque document clinique du système devient définitivement illisible. Pas difficile à récupérer — impossible. La base de données est intacte et sans valeur.
Pourquoi nous ne le corrigeons pas : les seuls correctifs sont une copie détenue par l’éditeur ou une porte dérobée de récupération. Les deux détruisent la propriété pour laquelle toute la conception existe. Si nous détenions une copie, « une base de données volée n’est pas une violation » cesserait d’être vrai, et chaque promesse de cette page sur ce que nous ne pouvons pas voir deviendrait fausse. Une clé récupérable est une clé que quelqu’un d’autre peut utiliser.
Ce que nous faisons : le système refuse de démarrer si la clé manque, plutôt que de tourner en silence et de vous laisser découvrir le problème quand un document ne s’ouvrira pas. Le contrôle de démarrage refuse aussi si le fichier de clé est lisible par quelqu’un d’autre que son propriétaire, ou s’il appartient au mauvais compte.
Ce qui est à vous : sauvegardez la clé, séparément des données, et testez que vous pouvez la restaurer. Deux personnes devraient savoir où elle est. C’est le devoir opérationnel aux conséquences les plus lourdes de toute la plateforme, et il prend une dizaine de minutes à bien faire.
Ce qui se passe : une administration envoie le fichier de clé par courriel à un collègue, le colle dans un ticket, le copie sur un portable, ou un ingénieur qui s’en va en garde une copie. Quiconque détient à la fois ce fichier et une copie de la base de données peut déchiffrer chaque document, hors ligne, sans connexion, et rien n’est écrit dans votre journal d’accès — parce que le journal consigne les lectures faites via l’application, et que cela contourne l’application entièrement.
Pourquoi nous ne le corrigeons pas : la clé doit être lisible par le logiciel qui l’utilise. Tout processus capable de la lire peut la copier. Les modules matériels de sécurité déplacent ce problème plutôt qu’ils ne le résolvent — le logiciel doit toujours pouvoir demander au module de déballer des clés, si bien qu’un attaquant disposant des privilèges de ce logiciel obtient encore du texte en clair.
Ce que nous faisons : les permissions du fichier sont vérifiées au démarrage : une clé lisible par tous arrête donc le système au lieu de passer inaperçue. Et comme vous hébergez vous-même, nous n’avons jamais le fichier — la population de gens qui pourraient le copier, c’est votre personnel, et non votre personnel plus le nôtre.
Ce qui est à vous : traitez la clé comme un objet physique contrôlé. Restreignez qui peut se connecter au serveur, utilisez des comptes d’administration individuels plutôt qu’un compte partagé, et faites tourner la clé quand quelqu’un ayant l’accès serveur s’en va — la section 06 explique pourquoi la rotation est peu coûteuse.
Ce qui se passe : la défaillance la plus silencieuse et la plus fréquente. Quelqu’un met en place une sauvegarde qui balaie tout le serveur, et le fichier de clé se retrouve dans la même archive que la base de données. Désormais une seule bande volée contient les deux moitiés, le chiffrement ne protège rien, et — pire — vous revendiqueriez toujours l’exemption pour chiffrement dans un rapport de violation, parce que sur le papier tout était chiffré.
Pourquoi c’est difficile : rien dans le système en fonctionnement n’a l’air différent. Tout marche parfaitement. Le problème n’existe que dans la sauvegarde, et ne compte que le jour où la sauvegarde est volée.
Ce que nous faisons : c’est le seul de cette liste contre lequel nous avons en partie bel et bien fait de l’ingénierie. Vous déclarez vos répertoires de sauvegarde dans la configuration, et le système refuse de démarrer si le fichier de clé se trouve à l’intérieur de l’un d’eux. Si vous ne déclarez aucun chemin de sauvegarde, il avertit que l’exemption ne peut pas être vérifiée — car une affirmation non vérifiée est la variété dangereuse.
Ce qui est à vous : déclarez honnêtement les racines de sauvegarde, et vérifiez ce que votre outil de sauvegarde inclut réellement plutôt que ce que vous croyez qu’il inclut.
Ce qui se passe : une thérapeute ouvre le dossier d’un patient qui est aussi son voisin. Une réceptionniste cherche une célébrité locale. Toutes les règles étaient satisfaites — la personne avait une relation de soins valable, ou des motifs valables, et en a simplement abusé. Ici, le chiffrement n’y change rien. Le contrôle d’accès non plus, car l’accès avait été accordé.
Pourquoi aucun système ne corrige cela : un logiciel ne peut pas lire une intention. Un système qui essaierait — en bloquant un accès parce qu’un nom a l’air local — bloquerait du vrai travail clinique en urgence, ce qui est un dommage en soi et, au Royaume-Uni, une non-conformité en soi.
Ce que nous faisons : le rendre visible plutôt qu’impossible. Chaque ouverture est consignée avant que le contenu n’apparaisse, dans un journal que personne ne peut modifier — ni votre administration ni nous. Les relations de soins se terminent, et l’accès se termine avec elles après un bref délai de grâce : la fenêtre est donc étroite. L’accès d’urgence est un acte distinct, délibéré et revu, plutôt qu’une capacité silencieuse.
Ce qui est à vous : quelqu’un doit réellement faire cette lecture du journal. Le module de gouvernance donne un foyer à la revue — cadence, relecteur nommé, trace des constats — mais un journal que personne ne regarde ne dissuade personne. C’est le contrôle qui existe le plus souvent sur le papier et n’a jamais lieu.
Ce qui se passe : pour montrer un document à un clinicien autorisé, le logiciel doit le déchiffrer. Pendant ce moment, il existe dans la mémoire du serveur sous forme de texte lisible. Quelqu’un ayant le contrôle total du système d’exploitation peut, en principe, l’y lire — ou modifier le logiciel pour en garder des copies.
Pourquoi aucun système ne corrige cela : c’est vrai de tout système qui affiche quoi que ce soit à qui que ce soit. Si la machine peut montrer le document, le propriétaire de la machine peut obtenir le document. Le chiffrement protège les données au repos et en transit ; il ne peut pas protéger les données contre l’ordinateur qui les traite licitement.
Ce que nous faisons : réduire la fenêtre — le déchiffrement a lieu en mémoire le temps de la lecture et le texte en clair n’est jamais écrit sur le disque. Et l’hébergement chez vous signifie que vous êtes la partie qui détient root, pas nous.
Ce qui est à vous : l’administration serveur est le rôle le plus privilégié dont vous disposez. Peu de personnes, nommées individuellement, des clés plutôt que des mots de passe, et un relevé de qui détient l’accès. Sa place est sur la liste des arrivées et départs, à côté des comptes cliniques.
Ce qui se passe : une règle de conservation est mal paramétrée, ou une destruction est lancée sur la mauvaise sélection. Les clés sont écrasées et les documents sont illisibles. Il n’y a pas d’annulation, et restaurer la sauvegarde d’hier soir n’aide pas — la sauvegarde contient le même texte chiffré, et sa clé a disparu.
Pourquoi nous ne le corrigeons pas : une suppression réversible n’est pas une suppression. Toute la valeur du crypto-effacement aux yeux d’un régulateur, c’est qu’il ne peut pas être défait. Une « corbeille » pour clés détruites signifierait que les données n’ont jamais été réellement détruites, et chaque affirmation d’effacement que vous avez faite serait fausse.
Ce que nous faisons : les clés ne peuvent être effacées par aucune voie ordinaire — l’opération d’effacement est bloquée net et la suppression ne passe que par la route de destruction, qui écrit une entrée d’audit au passage. Les conservations légales suspendent entièrement la suppression. La conservation compte à partir de dates d’ancrage stockées plutôt qu’à partir de l’âge du fichier, si bien que la cause la plus fréquente de suppression à la mauvaise date ne se présente pas.
Ce qui est à vous : vérifiez la configuration de conservation avant la mise en service, et non après la première passe de suppression. Et confirmez que les tâches planifiées tournent réellement — une tâche de conservation arrêtée en silence est un problème différent, mais il se découvre de la même façon, c’est-à-dire trop tard.
Ce qui se passe : les dossiers de santé mentale sont conservés vingt ans et parfois plus. L’AES-256 n’est pas considéré aujourd’hui comme cassable, y compris par les ordinateurs quantiques dont on spécule — mais aucun ingénieur honnête ne promet quoi que ce soit sur 2046 sans sourciller.
Pourquoi personne ne le corrige : on ne peut pas acheter une protection contre un résultat mathématique qui n’est pas encore survenu. Quiconque vend du stockage « résistant au quantique » pour des dossiers cliniques vend une histoire.
Ce que nous faisons : rendre l’algorithme et les clés remplaçables sans toucher à vos données. La rotation de clé ré-enveloppe chaque clé de données sous une nouvelle clé de déploiement sans réécrire un seul octet de texte chiffré, c’est donc une tâche de fond et non un projet de migration. La cryptographie est isolée dans un petit composant relisable précisément pour pouvoir être remplacée le moment venu.
Ce qui est à vous : faites tourner périodiquement plutôt que jamais, et attendez-vous à rechiffrer une fois dans la vie d’un dossier de vingt ans. Prévoyez-le comme de la maintenance, pas comme une crise.
Regardez ce que les sept ont en commun. Dans chaque cas, le « correctif » qui refermerait le risque — une clé récupérable, une suppression réversible, un système qui lit les intentions, une protection contre votre propre administration — détruirait quelque chose de plus précieux qu’il ne protège. Le choix de conception n’est pas que ces risques ont été négligés. C’est que les refermer rendrait fausses les garanties qui restent.
Ce qui vous reste est petit, précis et largement procédural : sauvegardez la clé séparément, contrôlez qui peut atteindre le serveur, déclarez vos chemins de sauvegarde, lisez le journal d’accès, et vérifiez une fois les réglages de conservation. Cette liste tient sur une page et c’est tout.
Puisque le risque 1 et le risque 2 sont les deux points aux conséquences les plus lourdes de cette page, il vaut la peine d’être précis sur ce qui est automatique et ce qui vous revient.
| Contrôle | État | Ce qui se passe |
|---|---|---|
| La clé existe | ✓ | Vérifié au démarrage. Une clé manquante arrête le système plutôt que de le laisser tourner et échouer plus tard, un document à la fois, devant un patient. |
| Seul son propriétaire peut la lire | ✓ | Une clé lisible par le groupe ou par tout le monde est bloquante au démarrage, pas un avertissement dans un journal que personne ne lit. |
| Elle appartient au bon compte | ✓ | Vérifié contre le compte sous lequel tourne le service. Une clé appartenant au compte d’un ingénieur parti est un constat. |
| Elle n’est pas dans un répertoire de sauvegarde | ✓ | Vous déclarez vos racines de sauvegarde ; le système refuse de démarrer si la clé s’y trouve. Si vous n’en déclarez aucune, il avertit que l’exemption en cas de violation ne peut pas être vérifiée. |
| Elle n’est pas là où elle voyagerait avec les données | ✓ | Une courte liste de répertoires où la clé ne doit jamais vivre est refusée d’emblée. |
| C’est une vraie clé | ✓ | Acceptée seulement sous forme de 32 octets bruts ou de 64 caractères hexadécimaux. Un fichier tronqué ou corrompu est refusé plutôt qu’utilisé pour produire des documents que personne ne pourra jamais ouvrir. |
| Elle est sauvegardée, séparément | — | À vous, et le logiciel ne peut pas aider. Nous ne pouvons pas vérifier une sauvegarde que nous n’avons pas le droit de voir, et un système capable de vérifier la sauvegarde de sa propre clé serait un système capable de l’atteindre. Deux personnes, deux endroits, une restauration testée. |
| Qui peut atteindre le serveur | — | À vous. Quiconque dispose de root peut lire la clé. Cette liste devrait être courte, nominative, et revue quand des gens partent. |
| Rotation quand quelqu’un part | ⚙ | Prise en charge et peu coûteuse : la rotation ré-enveloppe chaque clé de données sous une nouvelle clé de déploiement sans réécrire de texte chiffré, et les clés remplacées peuvent être conservées pour déballer ce qui est encore en vol. Décider quand faire tourner vous revient. Après le départ d’une administration serveur est le moment évident, et c’est celui qu’on manque le plus souvent. |
Chaque version de chaque document clinique est chiffrée avec sa propre clé, liée à l’identité de ce document pour qu’elle ne puisse pas être déplacée ailleurs. Ces clés sont enveloppées sous une seule clé de déploiement qui vit hors de la base de données et ne quitte jamais votre serveur — si bien qu’une base de données volée n’est pas une divulgation, et que la suppression se fait en détruisant une clé plutôt qu’en effaçant une ligne. Les documents ne s’ouvrent que pour des personnes ayant une relation de traitement en cours, et chaque ouverture est d’abord écrite dans un journal chaîné, si bien qu’un abus est visible même quand l’accès était légitime. Ce que l’ingénierie ne peut pas corriger est nommé en section 05, et la version courte de votre part, c’est : sauvegardez la clé séparément, gardez l’accès serveur court et nominatif, déclarez vos chemins de sauvegarde, lisez le journal, et vérifiez une fois les réglages de conservation avant la mise en service.
Chaque page pays s’appuie sur la mécanique décrite ici et y ajoute la machinerie de droits et de gouvernance qu’exige son propre droit.
