Dossiers citoyens et la question de qui peut réellement les déchiffrer

Chaque fournisseur de plateforme au service des organismes publics affirme que les données des citoyens sont chiffrées. Mais cette affirmation occulte le détail qui garantit réellement la protection : qui détient la clé. Si le fournisseur la détient, le chiffrement protège les dossiers des citoyens contre les tiers extérieurs, mais ne les protège en rien contre le fournisseur lui-même, ni contre toute autorité pouvant légalement contraindre ce fournisseur à déchiffrer les données.

Ce n’est pas une crainte hypothétique pour une administration qui transfère les dossiers des citoyens via des plateformes tierces. Un coffre verrouillé n’a aucune valeur si le fournisseur garde un double des clés et le remet à la première demande d’une autorité étrangère. Cet article analyse l’impact réel de la gestion des clés pour les organismes publics, explique pourquoi ce détail échappe souvent aux audits de sécurité, et détaille ce que requiert une gestion des clés réellement détenue par le client, jusqu’à la rotation de la clé et à la maîtrise du calendrier.

Résumé exécutif

Les audits de sécurité des plateformes gouvernementales s’arrêtent souvent à l’algorithme de chiffrement et à la longueur des clés, comme si AES-256 suffisait à garantir la sécurité des données des citoyens. Ce n’est pas le cas. La véritable question porte sur le contrôle de la clé : celui qui détient la clé détient la donnée, chiffrement ou non. Quand un fournisseur génère, stocke et gère la clé pour le compte de l’administration, il conserve la capacité technique d’accéder aux dossiers des citoyens à tout moment, pour n’importe quelle raison, y compris une raison non validée par l’administration ou ses citoyens. La gestion des clés détenues par le client, adossée à une solution matérielle, élimine totalement ce risque. Pour les responsables IT du secteur public, cela transforme le chiffrement d’un simple critère d’achat en une réalité architecturale vérifiable.

Points clés à retenir

1. Le chiffrement ne protège les données que des parties qui ne détiennent pas la clé. Si le fournisseur détient la clé, la protection des données des citoyens dépend de sa bonne volonté, pas du chiffrement lui-même.
2. Les modèles « apportez votre propre clé » éliminent toute capacité de déchiffrement du fournisseur. Si le fournisseur gère la clé, il conserve cette capacité, quel que soit l’algorithme utilisé ou la description figurant dans le cahier des charges.
3. Un module matériel de sécurité rend la détention de la clé tangible, et non une simple politique. Une clé générée et stockée dans un HSM contrôlé par l’administration ne peut pas être extraite par la plateforme hébergeant les données, même avec des droits administrateur.
4. La rotation des clés à la demande fait partie intégrante de la véritable détention. Si une administration ne peut pas faire tourner une clé selon son propre calendrier, elle ne maîtrise pas totalement les données des citoyens.
5. La robustesse du chiffrement ne compte pas si la mauvaise partie détient la clé. Ce qui importe pour la confiance des citoyens, c’est de savoir qui peut déchiffrer, pas la puissance du chiffrement.

Pourquoi la robustesse du chiffrement n’est pas la bonne question pour les données des citoyens

Les audits de sécurité abordent systématiquement le chiffrement, et les réponses portent presque toujours sur l’algorithme : AES-256 au repos, TLS 1.3 en transit. Ces réponses sont exactes, mais passent à côté de l’essentiel.

Les données chiffrées ont toujours un détenteur de la clé

Pour chaque dossier citoyen chiffré, une seule chose sépare la donnée du texte en clair : la clé. Celui qui détient la clé peut lire la donnée, la déchiffrer pour autrui, ou être contraint de la déchiffrer par voie légale. Un fichier chiffré avec un algorithme robuste mais une clé détenue par le fournisseur n’est pas mieux protégé du fournisseur qu’un fichier avec un chiffrement plus faible, car dans les deux cas, le facteur limitant reste le même : le fournisseur peut y accéder s’il le souhaite, ou s’il y est contraint.

Pourquoi les fournisseurs évitent généralement cette distinction

La documentation des fournisseurs décrit souvent le chiffrement avec des formulations rassurantes : « chiffré au repos et en transit avec des algorithmes standard du secteur ». C’est exact, mais incomplet. Cela ne dit rien sur l’origine de la clé, son lieu de stockage, ni sur l’accès potentiel du fournisseur à cette clé via son infrastructure. Une administration qui se contente de cette affirmation n’aura aucune réponse solide à fournir lors d’une enquête parlementaire.

Ce que requiert réellement la gestion des clés détenues par le client

Détenir une clé n’est pas une simple fonctionnalité, mais une chaîne de conditions à respecter. Si un maillon manque, le contrôle de la clé par l’administration devient théorique, et non opérationnel.

Apportez votre propre clé vs clé gérée par le fournisseur

Dans un modèle où le fournisseur gère la clé, la plateforme génère et stocke la clé de chiffrement dans sa propre infrastructure, et l’administration n’y a parfois jamais accès. Dans un modèle où le client détient la clé, l’administration contrôle la génération et le stockage de la clé, généralement via un module matériel de sécurité qu’elle administre ou auquel elle a un accès dédié. La différence est claire : un fournisseur qui peut techniquement déchiffrer les données des citoyens, et un autre qui ne le peut pas.

Pourquoi les modules matériels de sécurité sont essentiels, au-delà de leur nom

Un module matériel de sécurité est un dispositif physique dédié à la génération, au stockage et à la gestion des clés cryptographiques, conçu pour empêcher toute extraction, même par une personne disposant d’un accès administrateur au système environnant. Une simple promesse logicielle de détention des clés par le client peut, en théorie, être discrètement contournée par un fournisseur ayant un accès suffisant à son infrastructure. Une intégration HSM correctement réalisée élimine ce risque par conception, et non par politique.

Pourquoi la rotation et le contrôle des algorithmes déterminent la réalité de la détention

Détenir une clé à un instant donné ne signifie pas la contrôler en continu. Deux aspects opérationnels distinguent la véritable détention de la clé d’une simple déclaration sur une fiche technique, qui ne tient pas la route en pratique.

Rotation des clés à la demande

Si une administration soupçonne une exposition de la clé, que ce soit à cause d’un identifiant compromis ou d’une faille suspectée, la capacité à faire tourner cette clé immédiatement, sans attendre le calendrier du fournisseur, donne tout son sens opérationnel à la détention de la clé.

Contrôle granulaire des algorithmes et protocoles

La possibilité d’activer ou de désactiver certains algorithmes et de choisir les versions de TLS autorisées constitue un autre levier de contrôle, que l’administration doit pouvoir exercer selon son propre calendrier, et non celui du fournisseur.

Intégrer la gestion des clés à la sélection des fournisseurs

Pour une équipe IT du secteur public qui évalue un fournisseur, il s’agit concrètement de demander qui génère la clé, où elle est stockée, si un HSM est utilisé, qui peut la faire tourner et sur quel calendrier. Un fournisseur qui ne répond qu’à la première question, sur l’algorithme et la longueur de la clé, ne dit rien sur le véritable contrôle des données des citoyens une fois chiffrées.

Comment un plan de contrôle des données garantit la détention des clés dans l’architecture

Le Data Control Plane de Kiteworks intègre les clés de chiffrement détenues par le client via un module matériel de sécurité, de sorte que la génération et le stockage des clés échappent totalement à Kiteworks. Les administrations peuvent faire tourner les clés à la demande, choisir les algorithmes et versions de TLS activés, et fonctionner sur une architecture à locataire unique où la gestion des clés n’est partagée avec aucun autre client. Chaque action, sur chaque canal (messagerie électronique, partage de fichiers, API et agents IA), est consignée dans un journal d’audit infalsifiable et non limité qui s’interface directement avec les outils SIEM, garantissant ainsi la gestion des clés par des preuves concrètes, et non par une simple mention dans un cahier des charges.

Les administrations souhaitant comparer le modèle de gestion des clés de leur fournisseur actuel à ce standard peuvent planifier une démonstration personnalisée pour voir comment l’intégration d’un HSM contrôlé par le client s’applique à leurs propres données citoyennes et exigences de conformité.