Stockage des données des services financiers dans le cloud : l'impératif du chiffrement en 2026

Les institutions financières ont franchi le point de non-retour en matière d'adoption du cloud. La question n'est plus de savoir s'il faut stocker les données financières dans le cloud : il s'agit plutôt de savoir si votre stratégie de chiffrement est suffisamment solide pour les protéger en cas de problème — et non en cas de problème.

Les chiffres parlent d'eux-mêmes : le coût moyen d'une violation de données dans le secteur financier s'élève désormais à 5,85 millions de dollars par incident, et 60 % des organisations financières déclarent avoir du mal à sécuriser leurs données de manière cohérente dans les environnements multi-cloud. Dans le même temps, les régulateurs ont considérablement placé la barre plus haut. DORA est pleinement en vigueur depuis janvier 2025. Les contrôles obligatoires PCI DSS 4.0.1 sont entrés en vigueur en mars 2025. L'application de NIS2 s'accélère dans les États membres de l'UE jusqu'en 2026.

Cet article explique ce que le paysage réglementaire exige actuellement en matière de stockage de données financières, les domaines dans lesquels le chiffrement cloud standard ne répond pas aux attentes et à quoi ressemble dans la pratique une architecture de gestion de clés véritablement sécurisée.

Table des matières

1. Le problème de la sécurité des données financières
2. Ce que les réglementations exigent réellement
3. Pourquoi le chiffrement cloud par défaut n'est pas suffisant
4. L'écart de gestion des clés
5. Gestion des clés externes : l'architecture qui satisfait les régulateurs
6. Calcul multipartite : la nouvelle génération de contrôle de clé
7. Meilleures pratiques en matière de stockage de données financières
8. Comment DuoKey sécurise le stockage cloud des services financiers
9. Couverture de conformité en un coup d'œil
10. FAQ

Le problème de la sécurité des données financières

Les institutions financières gèrent certaines des données les plus sensibles qui existent : dossiers des titulaires de cartes, historiques des transactions, documentation KYC, dossiers de crédit et communications internes qui les entourent. Ces données sont de plus en plus réparties dans plusieurs environnements : cloud public provenant de plusieurs fournisseurs, plateformes SaaS, systèmes sur site et architectures hybrides qui peuvent être véritablement difficiles à inventorier.

La réalité multi-cloud crée un problème spécifique. Lorsque les données financières se trouvent simultanément sur AWS, Azure et une plateforme SaaS tierce, chaque environnement apporte ses propres paramètres de chiffrement natifs par défaut, son propre système de gestion de clés et sa propre piste d'audit. Obtenir une protection cohérente et vérifiable pour tous nécessite une couche de contrôle située au-dessus de n'importe quel fournisseur de cloud unique, et non trois politiques distinctes vaguement coordonnées par la feuille de calcul de quelqu'un.

Ce n'est pas non plus un risque hypothétique. Les violations dans le secteur financier remontent à plusieurs reprises à la même faiblesse fondamentale : les données étaient techniquement chiffrées, mais les clés étaient gérées par la même partie qui avait été compromise, ou étaient accessibles de manière à permettre aux attaquants de passer. Le chiffrement sans contrôle significatif des clés n'est en réalité qu'une apparence de sécurité.

Ce que les réglementations exigent réellement

Le cadre réglementaire du stockage des données financières a considérablement évolué au cours des 18 derniers mois. Cela vaut la peine de passer en revue chaque cadre majeur en particulier, car les exigences en matière de chiffrement et de gestion des clés sont plus prescriptives que de nombreuses équipes ne le pensent.

DORA

DORA est entrée en application complète le 17 janvier 2025 — et contrairement à une directive européenne, elle s'applique de manière identique dans les 27 États membres, sans possibilité de variation nationale. Elle couvre les banques, les assureurs, les entreprises d'investissement, les prestataires de services de paiement et les prestataires tiers de TIC qui les servent.

Pour le stockage des données financières, les exigences les plus importantes concernent la gestion des risques liés aux TIC et la surveillance par des tiers. Les entités financières doivent mettre en œuvre un cadre documenté de gestion des risques avec une responsabilité au niveau du conseil d'administration, et le chiffrement des données sensibles au repos et en transit est un contrôle de base attendu. Plus spécifiquement, le cadre doit aborder la manière dont les clés cryptographiques sont protégées : non seulement le fait que les données soient chiffrées, mais aussi que les clés elles-mêmes soient sous le contrôle significatif de l'entité.

Les dispositions relatives aux tiers sont là où les choses deviennent particulièrement pertinentes pour le stockage basé sur le cloud. Si vous déléguez la gestion des clés à un fournisseur de cloud, DORA vous oblige à démontrer une surveillance continue des contrôles de ce fournisseur. Les régulateurs vérifieront si le fournisseur de cloud a un accès unilatéral à vos clés, c'est-à-dire s'il pourrait déchiffrer vos données sans votre implication. S'ils le peuvent, votre posture de conformité sur ce front est faible. Les pénalités de non-conformité peuvent atteindre 2 % du chiffre d'affaires annuel mondial total pour les entités financières.

NIS2

NIS2 classe les organisations du secteur financier comme entités à la fois « essentielles » et « importantes ». L'article 21 exige explicitement le chiffrement comme mesure de gestion des risques, avec des contrôles proportionnés au risque. L'application se poursuivra jusqu'en 2026 : les entités allemandes sont confrontées à une date limite d'enregistrement au BSI en avril 2026, et les autres États membres travaillent sur leurs propres délais.

En juin 2025, l'ENISA a publié près de 200 pages de conseils techniques pour la mise en œuvre de NIS2, rendant explicites des attentes auparavant informelles : normes spécifiques pour le chiffrement en transit et au repos, pratiques de gestion des clés et méthodologies de surveillance des fournisseurs. Si votre équipe de sécurité n'a pas encore examiné ce document, cela vaut la peine.

RGPD et Schrems II

L'article 32 du RGPD a toujours exigé « des mesures techniques et organisationnelles appropriées » pour la protection des données personnelles, et le chiffrement en est l'exemple canonique. Ce que Schrems II a ajouté — en invalidant le bouclier de protection des données UE-États-Unis — est une exigence plus opérationnelle : les organisations stockant les données financières des résidents de l'UE dans une infrastructure cloud basée aux États-Unis doivent être en mesure de démontrer que les données ne peuvent pas être accessibles par le fournisseur de cloud (ou forcées par les autorités américaines) à l'insu de la personne concernée et sans la possibilité de révoquer cet accès.

Pour toute institution financière disposant de données client de l'UE sur AWS, Azure ou GCP, cela crée un argument direct en faveur de clés de chiffrement qui ne touchent jamais l'infrastructure du fournisseur de cloud.

PCI DSS 4.0.1

La norme PCI DSS 4.0.1 est désormais pleinement en vigueur depuis mars 2025. Les exigences 3 et 4 régissent respectivement les données stockées des titulaires de carte et les données en transit. Les dispositions de gestion des clés de l'Exigence 3.7 précisent que les clés cryptographiques doivent être protégées contre la divulgation et l'utilisation abusive, avec des dépositaires documentés et des connaissances partagées ou des procédures de double contrôle pour les clés de chiffrement. Ce ne sont pas des concepts nouveaux, mais ils sont désormais obligatoires, sans délai de grâce et sans marge discrétionnaire de l'auditeur.

FINMA

Pour les établissements ayant des activités en Suisse, la circulaire sur les risques opérationnels de la FINMA exige une souveraineté démontrable en matière de gestion des clés pour les données stockées dans des environnements cloud. Les régulateurs suisses ont toujours adopté une position conservatrice sur le contrôle des données cloud, et ils s'attendent à des preuves plutôt qu'à des affirmations.

Pourquoi le chiffrement cloud par défaut ne suffit pas

AWS, Azure et Google Cloud chiffrent tous les données au repos par défaut. C'est un enjeu majeur : ce n'est pas un différenciateur, et pour les données financières réglementées, cela crée un problème de conformité spécifique que la plupart des organisations ne découvrent que lorsqu'un auditeur pose la bonne question.

Avec le chiffrement cloud par défaut, le fournisseur cloud gère les clés. Leur infrastructure les génère, les stocke et les utilise en votre nom. Cela signifie quelques éléments importants pour la conformité. En vertu d'une ordonnance gouvernementale légale, un fournisseur de cloud basé aux États-Unis peut être contraint de produire vos clés — et peut ne pas être autorisé à vous dire que cela s'est produit. Une violation de l'infrastructure de gestion des clés du fournisseur de cloud est, en termes pratiques, une violation de vos données chiffrées. Et vous ne disposez d'aucun moyen indépendant pour vérifier que votre chiffrement n'a pas été contourné en silence.

Les clés gérées par le client (CMK) constituent une amélioration : elles vous permettent de contrôler les politiques de clés, les calendriers de rotation et les conditions d'accès. Mais le matériau de clé lui-même réside toujours dans l'infrastructure du fournisseur de cloud. Vous faites confiance à un tiers avec la racine de votre chaîne de confiance cryptographique et vous êtes obligé, en vertu de DORA, de démontrer une surveillance continue de ce même tiers.

Pour la plupart des catégories de données, ce compromis est acceptable. Pour les données financières sensibles (dossiers des titulaires de cartes, informations financières personnelles, historiques des transactions), les régulateurs européens attendent de plus en plus. L'orientation de la réglementation va vers le matériau de clé de chiffrement que l'institution financière contrôle réellement, et non vers les politiques de clé appliquées aux clés qu'un fournisseur de cloud détient en votre nom.

L'écart de gestion des clés

L'écart entre « chiffré » et « réellement sécurisé » se résume à une seule question : qui détient les clés ?

Considérez une architecture cloud de services financiers typique. Dossiers financiers des clients dans AWS S3, chiffrés avec des clés KMS gérées par le client. Données de transaction dans Azure SQL, chiffrées via Azure Key Vault. Traitement des cartes géré par un processeur de paiement tiers. Personnel accédant à tout ce qui précède via des applications SaaS avec un chiffrement géré par le fournisseur.

Dans cette image, trois fournisseurs de cloud différents détiennent chacun des éléments clés pour différentes tranches de vos données financières. Votre capacité à révoquer l'accès de manière centralisée — en cas de violation, de directive réglementaire ou de décision de quitter un fournisseur — est fragmentée. Votre piste d'audit est répartie sur trois consoles de fournisseur distinctes. Et votre position en matière de conformité dépend du maintien indépendant par chaque fournisseur des contrôles de sécurité que vous supposez.

C'est là que réside la lacune en matière de gestion des clés : le chiffrement est présent partout, mais le contrôle des clés est dispersé, incomplet et effectivement délégué à des fournisseurs que vous n'avez pas nécessairement choisis en gardant cette conséquence à l'esprit.

Gestion des clés externes : l'architecture qui satisfait les régulateurs

La réponse directe au manque de gestion des clés est une architecture de gestion des clés externe : votre matériau de clé cryptographique réside entièrement en dehors de l'infrastructure de tout fournisseur de cloud, dans un système que votre organisation possède et contrôle. Les fournisseurs de cloud effectuent toujours des opérations de chiffrement (vous ne les remplacez pas) mais ils ne peuvent pas accéder aux clés sans un appel autorisé à votre gestionnaire de clés externe.

Cette architecture répond aux exigences qui se chevauchent de DORA, NIS2 et Schrems II grâce à une seule décision de conception. La souveraineté des clés est satisfaite car les clés résident dans votre infrastructure. La révocation d'accès est réelle et immédiate : mettez votre gestionnaire de clés externe hors ligne et toutes les opérations de chiffrement cloud utilisant ces clés s'arrêtent. Une piste d'audit centralisée devient possible car chaque événement d'utilisation de clé, chez chaque fournisseur de cloud, passe par un seul système. Et les exigences de DORA en matière de risque de tiers deviennent beaucoup plus faciles à respecter lorsque vous êtes le dépositaire des clés, et non un fournisseur que vous êtes obligé de superviser.

L'intégration technique utilise des protocoles déjà pris en charge par les principaux fournisseurs de cloud : AWS KMS External Key Store (XKS), Azure Key Vault Managed HSM avec HYOK et GCP Cloud KMS avec EKMS. Chacun permet au fournisseur de cloud concerné d'effectuer des opérations cryptographiques à l'aide de clés qui ne quittent jamais votre garde.

Calcul multipartite : la nouvelle génération de contrôle des clés

La gestion traditionnelle des clés externes basée sur HSM résout le problème de garde du fournisseur de cloud, mais en introduit un autre : la clé complète existe sous la forme d'un seul secret dans un seul emplacement. Une compromission physique de cet emplacement, une menace interne avec un accès suffisant ou une ordonnance coercitive légale ciblant ce système spécifique sont autant de vecteurs d'attaque crédibles contre lesquels un seul HSM ne peut pas se défendre.

Le calcul multipartite élimine ce point de défaillance unique au niveau cryptographique. Avec la gestion des clés basée sur MPC, aucune clé complète n'existe nulle part : ni dans un seul appareil, ni dans une seule juridiction, ni entre les mains d'un seul administrateur. Les opérations cryptographiques sont effectuées de manière collaborative sur des partages de clés distribués, chacun étant mathématiquement inutile en soi. Un quorum de parties autorisées doit participer pour que toute opération de clé réussisse.

En pratique, cela signifie qu'un accès non autorisé aux clés nécessite de compromettre simultanément plusieurs systèmes indépendants. Un scénario de menace interne nécessite une collusion entre des parties qui ne se connaissent peut-être pas. Un ordre coercitif du gouvernement ciblant un emplacement produit un partage de clé incomplet qui ne permet rien. Pour les services financiers, la gestion des clés basée sur MPC constitue la défense disponible la plus solide contre les attaques techniques et les contraintes réglementaires — et c'est l'architecture qui satisfait le plus de manière crédible aux interprétations exigeantes des exigences de DORA en matière de risques liés aux TIC.

Le chiffrement des services financiers de DuoKey est basé sur MPC. Ce n'est pas un module complémentaire ; c'est l'architecture fondamentale. Le résultat est une gestion externe des clés sans le risque résiduel de point d'exposition unique que comportent les solutions HSM traditionnelles.

Meilleures pratiques en matière de stockage de données financières

Quelques éléments représentent la véritable attente de base en matière de stockage de données financières réglementées en 2026, quelle que soit l'approche spécifique de gestion des clés que vous adoptez.

Commencez par la classification des données. Toutes les données financières ne comportent pas la même sensibilité réglementaire. Les données des titulaires de carte selon la norme PCI DSS, les dossiers financiers personnels selon le RGPD et la télémétrie opérationnelle ont des exigences de protection très différentes. La classification permet une sélection appropriée des contrôles et facilite la production de preuves de conformité lorsque les auditeurs le demandent.

Chiffrez tout en transit et au repos, sans exception pour le trafic que vous considérez comme « interne ». PCI DSS 4.0.1 et DORA traitent tous deux cela comme non négociable. TLS 1.2 minimum pour les données en transit, AES-256 pour les données au repos. Les organisations sous NIS2 devraient consulter les orientations techniques de l'ENISA de juin 2025 — certaines normes auparavant informelles sont désormais explicites.

Consolidez la gestion des clés entre les fournisseurs de cloud plutôt que de maintenir des hiérarchies de clés distinctes par environnement. La gestion fragmentée des clés crée une complexité d'audit, des risques de non-conformité et une fragilité opérationnelle. Un gestionnaire de clés externe centralisé qui s'intègre à tous les principaux fournisseurs de cloud vous offre la piste d'audit unique et cohérente que les régulateurs souhaitent réellement voir.

Planifiez l'agilité cryptographique. DORA, NIS2 et la feuille de route post-quantique du groupe de coopération EU NIS (qui vise 2030 pour la transition des systèmes financiers à haut risque vers le PQC) supposent tous que les normes cryptographiques continueront d'évoluer. Concevez votre infrastructure de gestion de clés de manière à ce qu'elle soit indépendante des algorithmes dès maintenant, avant que la pression réglementaire liée au quantique n'entre en vigueur.

Testez la résilience de votre infrastructure cryptographique, et pas seulement de vos applications. Les exigences de test de résilience de DORA s'étendent aux systèmes de gestion des clés. Des tests d'intrusion annuels et des exercices de basculement réguliers sont attendus, et les régulateurs demanderont des preuves.

Documentez correctement la garde des clés. L'exigence PCI DSS 3.7 exige des enregistrements de dépositaire formels et des procédures définies pour la génération, la distribution, le stockage, le retrait et la destruction des clés. Cette documentation est l'une des premières choses que les auditeurs demandent, et les organisations qui l'improvisent sous la pression de l'audit ne font pas forte impression.

Comment DuoKey sécurise le stockage cloud des services financiers

DuoKey résout le problème du stockage des données financières au niveau le plus important : le contrôle des clés cryptographiques que votre organisation possède réellement.

La plateforme assure le chiffrement des données financières sensibles dans les environnements cloud (données structurées dans les bases de données cloud, données non structurées dans le stockage objet, données traitées par les applications cloud natives) avec des clés qui ne quittent jamais l'infrastructure contrôlée par le client. Étant donné que DuoKey utilise MPC plutôt qu'un HSM traditionnel, il n'existe aucun périphérique unique à compromettre, aucun administrateur unique disposant d'un accès complet aux clés et aucun emplacement unique susceptible d'être la cible d'une commande forcée.

DuoKey s'intègre à AWS KMS via XKS, Azure Key Vault et GCP EKMS, afin que les institutions financières puissent maintenir un contrôle centralisé des clés dans des environnements cloud hétérogènes sans remplacer l'infrastructure existante ni modifier les applications. Les opérations de chiffrement et de déchiffrement se déroulent au sein de la surface API du fournisseur de cloud existant ; la couche de gestion des clés est transparente pour les charges de travail.

Les avantages en matière de conformité sont architecturaux plutôt que simplement documentés. Les principales exigences de souveraineté et de surveillance par des tiers de DORA sont prises en compte dans la conception elle-même. La capacité de révocation d'accès Schrems II est intégrée. Les exigences de partage de connaissances PCI DSS sont satisfaites par le modèle de partage de clé de MPC. Et la piste d'audit centralisée dans tous les environnements cloud simplifie la collecte de preuves demandée par les régulateurs et les auditeurs.

Couverture de conformité en un coup d'œil

Réglementation	Ce dont il a besoin pour le stockage des données	Comment la gestion des clés externes y répond
DORA	Clés sous le contrôle de l'entité financière ; surveillance par des tiers ; tests de résilience	Clés détenues à l'extérieur ; le fournisseur de cloud n'a pas accès ; MPC réduit le risque de point de défaillance unique
NIS2	Le chiffrement comme mesure de gestion des risques ; contrôles techniques de pointe	Chiffrement AES-256 avec conservation des clés externes ; aligné sur les orientations de l'ENISA de juin 2025
RGPD / Schrems II	Capacité de révocation d'accès ; fournisseur de cloud ne peut pas accéder aux données personnelles	Kill switch immédiat via un gestionnaire de clés externe ; aucun élément de clé sur l'infrastructure du fournisseur de cloud
PCI DSS 4.0.1	Connaissances partagées/double contrôle pour les clés de chiffrement ; garde documentée	Les partages de clés MPC prennent en charge le partage des connaissances dès la conception ; journalisation d'audit complète
FINMA	Souveraineté des données cloud ; gestion des risques opérationnels	Contrôle de clé externe centralisé avec options de résidence des données en Suisse

FAQ

Qu'est-ce que la sécurité du stockage des données des services financiers ?

Il s'agit de l'ensemble des contrôles qui protègent les données financières (dossiers des titulaires de cartes, données de transaction, informations financières personnelles) lorsqu'elles sont stockées dans des environnements cloud. La couche la plus importante est le chiffrement combiné à un véritable contrôle des clés : garantir que les données chiffrées ne sont pas accessibles même si le stockage sous-jacent est compromis ou si le fournisseur de cloud est soumis à un ordre juridique.

Le chiffrement cloud standard est-il suffisant pour se conformer à DORA ?

Pour les catégories de données financières les plus sensibles, généralement non. Lorsqu'un fournisseur de cloud gère vos clés, vous déléguez la garde des clés à un tiers que DORA vous demande de superviser. La gestion des clés externes est l'architecture qui satisfait de la manière la plus crédible l'intention de DORA en matière de contrôle des clés significatif.

Quelle est la différence entre BYOK et HYOK ?

Bring Your Own Key (BYOK) signifie que vous générez la clé et l'importez dans l'infrastructure de gestion des clés du fournisseur de cloud, où il en prend la garde. Hold Your Own Key (HYOK) signifie que la clé ne quitte jamais votre infrastructure : le fournisseur de cloud appelle votre gestionnaire de clés externe chaque fois qu'il a besoin d'effectuer une opération cryptographique.

La gestion des clés externes ralentit-elle les choses ?

Cela ajoute un aller-retour pour les opérations cryptographiques, mais en pratique, l'impact est souvent minime pour les charges de travail financières. Les services cloud mettent en cache les clés de chiffrement des données, de sorte que les gestionnaires de clés externes ne sont pas appelés pour chaque accès à un enregistrement individuel.

En quoi MPC améliore-t-il un HSM traditionnel ?

Un HSM contient la clé complète dans un seul dispositif inviolable. MPC distribue les partages de clés sur plusieurs systèmes indépendants afin qu'aucun partage ne puisse exécuter seul des opérations. Pour les institutions financières, il s'agit d'une amélioration significative à la fois en matière de sécurité et de défendabilité réglementaire.

Certaines réglementations exigent-elles explicitement une gestion externe des clés ?

Pas par son nom. Mais DORA, NIS2 et Schrems II créent des attentes en matière de conformité que la gestion externe des clés est un moyen solide et crédible de satisfaire, en particulier en ce qui concerne la souveraineté des clés, la limitation de l'accès des fournisseurs de cloud et la capacité de révocation immédiate des accès.

Le résultat

Les données financières dans le cloud sont sécurisées lorsque deux conditions sont véritablement remplies : un chiffrement fort et des éléments de clés sous le contrôle effectif de l'institution financière — et non délégués à un fournisseur de cloud. En 2026, avec DORA et PCI DSS 4.0.1 pleinement en vigueur et l'application de NIS2 s'accélérant, le respect de ces conditions constitue une attente réglementaire et non un différenciateur concurrentiel.

Les institutions qui s'attaquent à ce problème construisent désormais une architecture de conformité qui résiste à un examen minutieux. Ceux qui s'en remettent ont tendance à découvrir ce que coûte réellement la mise à niveau des contrôles de chiffrement sous la pression des audits — ce qui est bien plus que la mise en place d'une architecture correcte dès le départ.

Références et lectures complémentaires

• Loi de l'UE sur la résilience opérationnelle numérique (DORA) - Texte officiel
• Lignes directrices techniques ENISA NIS2, juin 2025
• PCI DSS v4.0.1 - Conseil des normes de sécurité PCI
• Article 32 du RGPD - Sécurité du traitement
• NIST SP 800-57 : Directives de gestion des clés
• Cloud Security Alliance : Gestion des clés cloud des services financiers
• Cas d'utilisation du stockage de données cloud sécurisé DuoKey