Vous chiffrez vos données. Mais qui contrôle les clés ?
Pourquoi la souveraineté des clés constitue-t-elle le déficit de conformité que la plupart des organisations ne voient jamais venir — et comment y remédier.
La plupart des organisations traitant des données réglementées ont fait des choses évidentes. Ils ont chiffré leurs bases de données. Ils ont signé des accords de traitement de données. Ils ont coché les cases RGPD, FINMA ou HIPAA que leurs équipes juridiques leur ont remises.
Et pourtant, les mesures coercitives ne cessent de se multiplier. Les amendes continuent d'atterrir. Les auditeurs continuent de trouver des lacunes.
La raison est presque toujours la même : les organisations confondent souveraineté des données et souveraineté des clés — et supposent que le chiffrement des données suffit à prouver qu'elles les contrôlent.
Ce n'est pas le cas.
Tout d'abord, comprenez la différence
La souveraineté des données concerne l'endroit où se trouvent physiquement vos données et la juridiction qui les régit. C'est la question que se posent en premier les régulateurs : ces données sont-elles stockées dans un pays agréé, dans un cadre juridique agréé ?
La souveraineté des clés concerne la personne qui détient les clés cryptographiques qui rendent ces données lisibles. C'est la question que la plupart des organisations oublient de poser : même si les données sont stockées au bon endroit, qui peut réellement les déverrouiller ?
Voici pourquoi cette distinction est importante : les données chiffrées sans souveraineté des clés ne sont pas des données véritablement contrôlées. Si un fournisseur de cloud tiers détient vos clés de chiffrement — même dans le cadre d'un modèle de responsabilité partagée — il peut techniquement accéder à vos données. Leur gouvernement aussi, sous assignation à comparaître. Il en va de même pour une stratégie IAM mal configurée. Un initié voyou aussi.
Vous n'avez pas protégé vos données. Vous avez protégé l'apparence de la protection de vos données.
Les chiffres de conformité sont de plus en plus difficiles à ignorer
L'application des réglementations en matière de chiffrement et de gestion des clés s'est considérablement développée dans les trois principaux cadres.
Dans le cadre du RGPD, le Comité européen de la protection des données a de plus en plus cité des mesures techniques inadéquates, notamment de mauvaises pratiques de gestion des clés, dans ses décisions d'application. Selon le CMS GDPR Enforcement Tracker, le total des amendes enregistrées a dépassé 5,65 milliards d'euros, avec 2 245 amendes prononcées début 2025. L'amende la plus importante — 1,2 milliard d'euros contre Meta en 2023 — était spécifiquement liée au transfert illégal de données personnelles vers les États-Unis, sans protections adéquates. La leçon pour la gestion des clés est directe : si vos données sont accessibles sous une juridiction étrangère, vous ne disposerez peut-être pas de protections adéquates, quel que soit le chiffrement.
Dans le cadre de la FINMA, les autorités de surveillance financières suisses ont relevé la barre en matière d'exigences de résilience opérationnelle par la Circulaire 2023/1, entrée en vigueur le 1er janvier 2024. Le régulateur a accordé une attention particulière aux dispositions informatiques externalisées. Dans son Rapport 2024 sur les cyber-risques et l'externalisation, la FINMA a constaté qu'en 2024, une banque ou une compagnie d'assurance sur cinq externalisait des données ou des fonctions importantes à des fournisseurs de cloud public — et a souligné le risque de concentration que cela engendre. Lorsque les institutions suisses ont stocké des clés de chiffrement auprès de fournisseurs tiers en dehors de la Suisse, les régulateurs se demandent si les obligations de confidentialité des clients en vertu du droit bancaire suisse peuvent être respectées de manière significative.
En vertu de la HIPAA, le ministère américain de la Santé et des Services sociaux réglemente le chiffrement selon 45 CFR 164.312, qui spécifie le chiffrement et le déchiffrement comme spécifications de mise en œuvre adressables — ce qui signifie que les organisations doivent les mettre en œuvre à moins qu'elles ne puissent justifier pourquoi, et doivent documenter les contrôles compensatoires si elles ne le font pas. HHS a toujours constaté que le chiffrement à lui seul ne constitue pas une protection adéquate si les contrôles de gestion des clés sont absents ou délégués à un fournisseur sans protections contractuelles appropriées.
Le schéma est cohérent : les régulateurs vont au-delà de la question « les données sont-elles chiffrées ? » à « qui contrôle les clés, où sont-elles stockées et sous quelle juridiction ? »
Comment le stockage transfrontalier des clés crée un réel risque de non-conformité
Scénario 1 : La banque de l'UE utilise un fournisseur de cloud américain
Une banque de détail allemande transfère ses données clients vers une plateforme cloud hyperscale. Les données sont chiffrées au repos. La conformité est approuvée.
Ce que la banque n'a pas entièrement pris en compte : le fournisseur de cloud gère les clés de chiffrement à partir d'une infrastructure basée aux États-Unis. En vertu du US CLOUD Act — officiellement la Clarifying Lawful Overseas Use of Data Act (2018) — les autorités américaines peuvent obliger les fournisseurs basés aux États-Unis à produire des données stockées n'importe où dans le monde, à condition que le fournisseur en ait la possession, la garde ou le contrôle. Comme le confirme le livre blanc du DOJ, la loi s'applique quel que soit l'endroit où les données sont physiquement stockées.
Du point de vue du RGPD, cela crée un problème. L'article 32 exige des mesures techniques appropriées pour garantir la sécurité des données. L'article 44 restreint les transferts de données personnelles vers des pays tiers. Si l'infrastructure de gestion des clés permet effectivement l'accès aux autorités américaines, les régulateurs pourraient constater que la banque a failli sur les deux points — même si les données n'ont jamais quitté Francfort.
Scénario 2 : Les prestataires de soins de santé suisses et les règles d'externalisation de la FINMA
Une clinique privée suisse s'associe à une plateforme de dossiers de patients basée sur le cloud. La plateforme est hébergée en Suisse. Tout semble correct sur le papier.
Mais les clés de chiffrement de la plateforme sont gérées par un service de gestion de clés exploité depuis l'Irlande. Lorsque les auditeurs de la FINMA examinent le dispositif, en appliquant les principes d'externalisation de la Circulaire 2018/3 ainsi que les exigences de résilience opérationnelle de la Circulaire 2023/1 — ils constatent que la clinique ne peut pas démontrer un contrôle exclusif sur l'accès aux données des patients. Le prestataire de gestion des clés pourrait, sous certaines contraintes légales, faciliter l'accès à l'insu de la clinique ou sans son consentement.
Les lois suisses sur le secret bancaire et la confidentialité des soins de santé exigent que l'accès aux informations sensibles des clients reste fermement sous le contrôle de l'institution. Une dépendance de la gestion des clés à l'égard d'un service exploité à l'étranger crée une lacune qu'aucun accord de traitement des données ne peut entièrement combler.
Scénario 3 : La société multinationale tente de se conformer partout en même temps
Une société mondiale de services professionnels opère dans l'UE, en Suisse et aux États-Unis. Elle utilise une plateforme cloud centralisée avec un service de gestion de clés unique, car c'est ce que le fournisseur de plateforme a recommandé et c'est plus simple sur le plan opérationnel.
Le problème : le RGPD exige que les données personnelles de l'UE ne soient accessibles que dans des conditions approuvées par l'UE. La FINMA exige que les données financières suisses restent sous contrôle suisse. HIPAA exige des contrôles documentés sur les informations de santé protégées. Un service de gestion de clés unique et centralisé soumis à une seule juridiction ne peut pas satisfaire simultanément aux trois cadres — et tenter de l'utiliser comme s'il le pouvait est une fiction de conformité qui attend d'être révélée.
Ce que les experts du secteur regardent
La direction à suivre en matière de réglementation est claire pour ceux qui travaillent à l'intersection des normes de chiffrement et des cadres de conformité.
La Cloud Security Alliance, dans son rapport Top Threats to Cloud Computing 2024 — basé sur une enquête menée auprès de plus de 500 experts du secteur — a identifié les faiblesses de la gestion des identités et des accès (IAM) comme le deuxième problème de sécurité du cloud pour la deuxième année consécutive. Une mauvaise gestion cryptographique a été explicitement citée comme un échec persistant dans la catégorie IAM. La CSA soutient depuis longtemps que de nombreuses organisations délèguent sans le savoir le contrôle de leurs données les plus sensibles en acceptant des accords de gestion des clés par défaut de la part des fournisseurs de cloud.
Les praticiens du droit qui conseillent sur les transferts de données transfrontaliers ont signalé que les organismes de réglementation de l'UE et de la Suisse commencent à examiner non seulement l'endroit où les données sont stockées, mais aussi l'endroit où l'accès à ces données peut être forcé — ce qui est déterminé par l'endroit où les clés sont gérées, et non par l'endroit où les données se trouvent.
Le consensus réglementaire émergent est que la résidence des clés — la juridiction juridique et physique de l'infrastructure des clés de chiffrement — deviendra une exigence de conformité explicite, et non seulement une bonne pratique, au cours du prochain cycle réglementaire.
Le paradoxe de la souveraineté
Voici le problème central, énoncé clairement.
Une organisation chiffre ses données, estimant que cela démontre le contrôle et la sécurité. Elle confie ensuite la gestion des clés à un fournisseur de cloud tiers, car c'est pratique et la documentation du fournisseur indique que c'est sécurisé. Les données sont chiffrées. L'organisation en a perdu le contrôle.
C'est là le paradoxe de la souveraineté : l'acte technique de chiffrement est utilisé pour satisfaire une exigence réglementaire de contrôle, tandis que simultanément la capacité pratique d'exercer ce contrôle a été déléguée.
Les régulateurs commencent à y voir clair. La question n'est plus de savoir si les données sont chiffrées. Il s'agit de savoir si l'organisation qui est responsable de ces données dispose d'un contrôle véritable, démontrable et juridiquement solide sur les personnes qui peuvent y accéder, y compris le contrôle des clés cryptographiques qui régissent l'accès.
Si la réponse est « notre fournisseur de cloud gère les clés et nous leur faisons confiance », ce n'est pas de la souveraineté. C'est une dépendance déguisée en sécurité.
Un cadre pour bien faire les choses
Voici comment combler systématiquement l'écart.
Étape 1 : Cartographiez vos dépendances de gestion de clés
Auditez chaque système traitant des données réglementées. Pour chacun d'entre eux, identifiez : qui gère les clés de chiffrement, où se trouve physiquement cette infrastructure de gestion des clés et sous quelle juridiction elle opère. Il s'agit souvent d'un exercice inconfortable. Faites-le quand même.
Étape 2 : Évaluer l'exposition juridictionnelle
Pour chaque dépendance de gestion de clés, évaluez quels mécanismes juridiques pourraient imposer l'accès à ces clés sans le consentement explicite de votre organisation. Cela inclut les demandes CLOUD Act, les ordonnances coercitives des gouvernements locaux et les conditions contractuelles que votre fournisseur a acceptées avec leurs propres gouvernements.
Étape 3 : Comprenez précisément vos obligations réglementaires
Article 32 du RGPD et Considérant 83 nécessitent des mesures techniques et organisationnelles appropriées. La Circulaire FINMA 2023/1 fixe des exigences explicites pour les contrats externalisés. La règle de sécurité HIPAA au 45 CFR 164.312 spécifie le chiffrement et le déchiffrement en tant que spécifications de mise en œuvre adressables. Lisez ce que votre organisme de réglementation spécifique exige, et non ce que l'équipe de conformité de votre fournisseur vous dit.
Étape 4 : Séparez le stockage des données de la gestion des clés
Les architectures les plus robustes stockent les données chiffrées auprès d'un seul fournisseur et gèrent les clés de chiffrement de manière totalement indépendante — de préférence avec une infrastructure sous le contrôle direct de l'organisation, ou avec un fournisseur spécialisé en gestion de clés dont la juridiction et l'exposition juridique sont appropriées au cadre réglementaire en question. C'est ce que réalise une véritable architecture Bring Your Own Key (BYOK) ou Hold Your Own Key (HYOK).
Étape 5 : Établir des politiques de résidence des clés
Définissez explicitement où doivent résider les clés de chiffrement pour chaque catégorie de données réglementées. Les données personnelles de l'UE en vertu du RGPD devraient avoir des clés gérées dans la juridiction de l'UE. Les données financières et de santé suisses devraient avoir des clés gérées au sein de la juridiction suisse. Documentez cette politique, mettez en œuvre des contrôles techniques pour la faire appliquer et vérifiez régulièrement sa conformité.
Étape 6 : Examiner les contrats avec des tiers en gardant à l'esprit les principaux enjeux
Vos accords de traitement de données concernent probablement la localisation des données et les contrôles d'accès. Ils n'abordent probablement pas la compétence de gestion des clés et les mécanismes d'accès avec suffisamment de spécificité. Comblez cette lacune contractuellement, et lorsqu'un fournisseur ne peut pas fournir les garanties nécessaires, traitez cela comme un risque de non-conformité important, car c'est le cas.
Étape 7 : Préparez-vous à la question d'audit qui ne vous a pas encore été posée
Les régulateurs s'orientent vers la question suivante : « Démontrez qu'aucune partie autre que votre organisation ne peut accéder à ces données sans votre autorisation explicite. » Préparez votre réponse maintenant. Si vous ne pouvez pas donner une réponse claire et techniquement étayée, vous avez du travail à faire.
Le paysage régional en un coup d'œil
| Cadre | Juridiction | Obligations de conformité | Implications |
|---|---|---|---|
| RGPD | Union européenne | Article 32, mesures techniques ; Article 44, restrictions de transfert | Les clés ne doivent pas être accessibles sous contrainte légale hors UE |
| FINMA | Suisse | Circulaires d'externalisation ; secret bancaire ; résilience opérationnelle | Les clés doivent rester sous contrôle suisse ; les gestionnaires de clés étrangers créent un risque d'externalisation |
| HIPAA | États-Unis | Spécifications de chiffrement et de déchiffrement des règles de sécurité ; Accords de partenariat commercial | Les principaux fournisseurs de gestion doivent être couverts en tant qu'associés commerciaux ; les contrôles d'accès doivent être documentés et vérifiables |
Le résultat
La souveraineté des données sans souveraineté des clés est une fiction de conformité. Chiffrer des données tout en déléguant la gestion des clés à un tiers sous une juridiction étrangère ne vous donne aucun contrôle. Cela vous donne l'apparence d'un contrôle — qui satisfera à un audit de case à cocher et échouera à une enquête réglementaire sérieuse.
Les organisations qui feront face à la prochaine vague de contrôles réglementaires sont celles qui considèrent la souveraineté des clés comme une exigence de conformité de premier ordre, et non comme une réflexion après coup. Elles seront en mesure de démontrer, techniquement et juridiquement, que l'accès à leurs données réglementées est entièrement régi par leurs propres politiques et infrastructures.
Tous les autres expliqueront leurs principales dépendances en matière de gestion à un régulateur.
DuoKey fournit aux organisations l'infrastructure nécessaire pour atteindre une véritable souveraineté des clés dans les environnements RGPD, FINMA et HIPAA, y compris une gestion des clés multipartite qui garantit qu'aucun fournisseur unique, y compris DuoKey, ne peut accéder unilatéralement à vos données.
Ressources associées
