DORA pour les banques : cryptographie, risque post-quantique et attentes des superviseurs
Pourquoi les banques sont en première ligne
- Des données confidentielles de longue durée. Identités clients, historiques de comptes, dossiers de crédit et pièces de lutte contre le blanchiment doivent être conservés des années après la fin de la relation, et les dossiers de prêt courent sur des décennies. Tout ce qui est capté aujourd’hui en transit sous un échange de clés RSA ou sur courbes elliptiques reste exposé à une attaque « harvest now, decrypt later » pendant toute cette période.
- Des infrastructures de longue durée. HSM de paiement, plateformes cartes, cœurs bancaires et connexions interbancaires se remplacent sur des cycles de plusieurs années, et chaque changement exige certification, agrément des schémas ou coordination avec les contreparties.
- Une forte interdépendance. Une banque ne migre pas seule : schémas de cartes, systèmes de paiement, infrastructures de marché, fournisseurs cloud et partenaires fintech sont à l’autre bout de sa cryptographie.
- Un règlement qui nomme la cryptographie. DORA et ses normes techniques font du chiffrement, des contrôles cryptographiques et de la gestion des clés des sujets de supervision explicites.
Les instances du secteur le disent elles-mêmes. Le G7 Cyber Expert Group a publié en septembre 2024 une déclaration invitant les institutions financières à planifier dès maintenant les risques liés à l’informatique quantique, et la feuille de route post-quantique de l’UE attend des inventaires d’ici fin 2026 et la migration des cas d’usage à haut risque d’ici fin 2030. Pour une banque, la plupart des flux de paiement et de données clients sont des cas d’usage à haut risque.
Ce que DORA exige pour la cryptographie
DORA (règlement (UE) 2022/2554) s’applique depuis le 17 janvier 2025. Son chapitre sur la gestion du risque lié aux TIC est précisé par les RTS du règlement délégué 2024/1774. Les dispositions qui concernent la cryptographie :
| Disposition | Ce que cela implique pour la cryptographie | Preuves à préparer |
|---|---|---|
| DORA art. 5 Gouvernance | L’organe de direction est responsable du cadre de gestion du risque lié aux TIC : le risque quantique est un sujet de direction, pas seulement du RSSI. | Une note à l’organe de direction sur l’exposition cryptographique et quantique, avec décisions et responsables consignés. |
| DORA art. 8 Identification | Les actifs TIC et les actifs informationnels doivent être identifiés, classés et documentés. Les actifs cryptographiques en font partie. | Un inventaire cryptographique relié à l’inventaire des actifs TIC et à la classification des données. |
| DORA art. 9 Protection et prévention | Protéger les données au repos, en cours d’utilisation et en transit ; authentification forte ; protection des clés cryptographiques, avec un chiffrement fondé sur la classification des données et l’analyse de risque. | La correspondance entre classes de données et cryptographie qui les protège, écarts listés. |
| RTS art. 6 Chiffrement et contrôles cryptographiques | Une politique documentée de chiffrement et de contrôles cryptographiques, fondée sur la classification et le risque, couvrant les données au repos, en transit et en cours d’utilisation, et prévoyant la mise à jour de la technologie cryptographique selon l’évolution de la cryptanalyse. | La politique elle-même, et la trace de la veille sur la cryptanalyse quantique et de ce qui déclenche un changement. |
| RTS art. 7 Gestion des clés cryptographiques | Une gestion des clés sur tout leur cycle de vie, et un registre des certificats et des dispositifs qui les stockent, au moins pour les actifs qui soutiennent des fonctions critiques ou importantes, avec un renouvellement en temps utile. | Des procédures de gestion des clés et un registre des certificats à jour, idéalement généré plutôt que tenu à la main. |
| DORA art. 28 Risque lié aux prestataires TIC | Les contrats et le registre d’informations sur les prestataires tiers de services TIC. Une grande partie de la cryptographie d’une banque s’exécute dans des produits et services de fournisseurs. | Les feuilles de route post-quantiques des fournisseurs, suivies au regard du registre, et des clauses PQC dans les nouveaux contrats. |
| DORA art. 24 à 27 Tests | Les tests de résilience, et les tests de pénétration fondés sur la menace pour les entités désignées, testeront les faiblesses cryptographiques comme tout autre contrôle. | Les constats sur la cryptographie faible ou obsolète clos, ou acceptés avec une justification documentée. |
La clause des RTS sur la mise à jour de la technologie cryptographique selon l’évolution de la cryptanalyse est le point d’ancrage réglementaire de la migration post-quantique et de la crypto-agilité : une banque qui ne sait pas où se trouvent ses usages de RSA et de courbes elliptiques ne peut pas démontrer qu’elle est prête à les mettre à jour.
Où se cache la cryptographie dans une banque
- Paiements et cartes : HSM de paiement, processus de gestion des PIN et des clés, et authentification des cartes, qui repose sur des certificats RSA émis dans le cadre des schémas de cartes.
- Open banking et API partenaires : endpoints TLS et certificats eIDAS utilisés pour l’accès DSP2, ainsi que les clés de signature d’API et de jetons.
- Connexions interbancaires et de marché : réseaux de messagerie, liaisons de compensation et de règlement, et la PKI et les HSM qui les sous-tendent.
- Canaux numériques : banque mobile et en ligne, y compris la signature des applications et du code, l’appairage des appareils et l’authentification des clients.
- Cœur bancaire et plateformes de données : chiffrement des bases et des sauvegardes, magasins de clés, transferts de fichiers batch et TLS interne entre services, rarement visible sur un schéma d’architecture.
- Gestion des clés dans le cloud : clés conservées dans les services KMS des fournisseurs cloud et charges de travail qui les utilisent.
- Produits de fournisseurs : cryptographie intégrée aux progiciels et appliances, visible uniquement par la transparence des fournisseurs, idéalement un CBOM.
Ce que les superviseurs demanderont probablement
Les établissements importants sont supervisés par la BCE dans le cadre du mécanisme de surveillance unique ; les autres par leur autorité nationale compétente, l’ACPR en France. Selon notre lecture de DORA et des RTS, une revue des contrôles cryptographiques se ramène à quelques questions :
- Montrez-nous votre politique de chiffrement et de contrôles cryptographiques, et comment elle découle de la classification des données.
- Où la cryptographie est-elle utilisée pour les systèmes qui soutiennent des fonctions critiques ou importantes, et comment le savez-vous ?
- Montrez-nous le registre des certificats et la façon dont les expirations sont détectées.
- Comment suivez-vous l’évolution de la cryptanalyse, y compris l’informatique quantique, et qu’avez-vous décidé en conséquence ?
- Lesquels de vos prestataires TIC critiques ont une feuille de route post-quantique, et où est-elle consignée ?
- Qu’a révélé votre dernier test de résilience ou d’intrusion sur la cryptographie, et qu’en avez-vous fait ?
Aucune de ces questions n’exige une migration post-quantique achevée. Toutes exigent un inventaire, une politique qui s’y réfère et un plan. Notre checklist post-quantique pour RSSI couvre le même terrain plus en détail.
Un plan à 90 jours pour une banque
| Semaines | Actions | Livrables |
|---|---|---|
| 1 à 4 | Choisir une fonction critique ou importante, par exemple les paiements par carte ou la banque en ligne. Inventorier sa cryptographie dans le code, les certificats et les endpoints. Recueillir les déclarations des fournisseurs des produits dont elle dépend. | Un premier CBOM et une liste de certificats pour cette fonction ; un suivi des fournisseurs. |
| 5 à 8 | Relier les constats aux classes de données et durées de conservation. Évaluer chaque actif selon le risque quantique et l’exposition HNDL. Séparer la cryptographie de production du code de test et des bibliothèques tierces embarquées. | Une liste classée par risque, les flux à longue conservation en tête. |
| 9 à 12 | Mettre à jour la politique de contrôles cryptographiques pour qu’elle renvoie à l’inventaire et à la veille post-quantique. Rédiger une feuille de route de migration par vagues. Présenter le sujet à l’organe de direction. Ajouter des exigences PQC aux nouveaux contrats. | Politique mise à jour, feuille de route par vagues, note à la direction et clauses contractuelles. |
Étendre ensuite fonction par fonction, et régénérer l’inventaire à chaque version pour que les preuves restent à jour. Notre guide pour estimer le périmètre d’impact d’une migration explique comment passer de l’inventaire aux vagues et à l’effort.
La place de CRYPTAGION
CRYPTAGION produit la partie inventaire de ces preuves. Il découvre la cryptographie dans le code Python, JavaScript/TypeScript, Java, Go et C/C++, les certificats X.509 et les endpoints TLS en direct, avec le fichier et la ligne ou l’endpoint de chaque finding et une étiquette de périmètre qui distingue le code de production des tests et du code tiers. Il évalue chaque actif selon le risque quantique et l’exposition HNDL à l’aide d’une politique de sensibilité par chemin, exporte un CBOM CycloneDX 1.6 validé contre le schéma, et produit un rapport PDF pour la direction rattaché à DORA, NIS2, au CRA et à FIPS 203/204/205, avec une feuille de route par vagues. L’offre Platform ajoute l’analyse d’AWS KMS, Azure Key Vault et GCP KMS, et un contrôle en CI qui bloque toute nouvelle cryptographie faible. Il s’exécute sur site ou en environnement isolé (déploiement et flux de données).
Ce qu’il ne voit pas : les langages mainframe comme COBOL, la cryptographie configurée dans les HSM, et les binaires ou images de conteneurs, qui sont sur notre feuille de route. Ces parties d’un système d’information bancaire exigent, en complément de tout outil, la transparence des fournisseurs et une revue manuelle ; posez la même question à chaque éditeur, avec notre checklist d’évaluation d’un outil CBOM.
Sources
- Règlement (UE) 2022/2554 (DORA), articles 5, 8, 9, 24 à 28
- Règlement délégué (UE) 2024/1774 de la Commission (RTS sur la gestion du risque lié aux TIC), articles 6 et 7
- Recommandation (UE) 2024/1101 de la Commission relative à une feuille de route coordonnée pour la transition vers la cryptographie post-quantique
- G7 Cyber Expert Group, déclaration sur la planification des opportunités et des risques de l’informatique quantique (septembre 2024)
Cette page reflète une lecture de praticien de DORA et de ses RTS ; elle ne constitue pas un avis juridique. Confirmez vos obligations avec vos équipes conformité et juridiques. CRYPTAGION contribue aux activités de conformité ; son utilisation ne suffit pas à établir la conformité réglementaire.
Le voir sur une stack de type bancaire
En 30 minutes, nous exécutons CRYPTAGION en direct sur un dépôt public proche de votre stack et montrons le CBOM, les scores de risque et la feuille de route. Aucun accès à votre code n’est nécessaire.
Demander une démo gratuite →