DORA, article 7 : gestion des clés et registre des certificats

L'article 7 du règlement délégué (UE) 2024/1774 de la Commission, c'est-à-dire les normes techniques de réglementation (RTS) DORA relatives à la gestion du risque lié aux TIC, impose deux choses : une gestion des clés cryptographiques couvrant l'ensemble de leur cycle de vie, et un registre des certificats des actifs TIC qui soutiennent des fonctions critiques ou importantes. Ce registre est un livrable de conformité, mais c'est aussi la liste opérationnelle dont vous aurez besoin le jour où vous migrerez l'échange de clés et les signatures vers des algorithmes post-quantiques. Ce guide présente les champs à consigner, les commandes en lecture seule qui permettent de découvrir les certificats, et la manière dont le registre se rattache à l'inventaire cryptographique plus large exigé par l'article 6 de DORA. Il s'agit d'une information, et non d'un conseil juridique.

Ce que l'article 7 demande littéralement

Le texte des RTS est court et précis. Les entités financières doivent disposer de politiques et de procédures de gestion des clés cryptographiques couvrant la génération, le renouvellement, le stockage, la sauvegarde, l'archivage, la récupération, la transmission, le retrait, la révocation et la destruction des clés. Par ailleurs, elles doivent tenir un registre des certificats et des dispositifs de stockage de certificats pour les actifs TIC soutenant des fonctions critiques ou importantes, et gérer le renouvellement des certificats afin que leur expiration n'interrompe pas ces fonctions. Le texte faisant foi est disponible sur EUR-Lex : règlement délégué (UE) 2024/1774 de la Commission.

Trois conséquences découlent directement de cette formulation, avant toute interprétation.

• Le périmètre est défini par les fonctions, pas par l'infrastructure. Le déclencheur est le soutien à une fonction critique ou importante : le registre suit donc votre propre classification des fonctions, et non une frontière réseau.
• Les dispositifs sont dans le périmètre, pas seulement les fichiers. Les dispositifs de stockage de certificats désignent les modules matériels de sécurité (HSM), les cartes à puce, les modules de plateforme sécurisée et les magasins de clés des appliances : inventoriez donc le support autant que l'élément d'authentification qu'il contient.
• Le renouvellement est un contrôle de disponibilité. Un certificat expiré sur une passerelle de paiement constitue un incident lié aux TIC, c'est pourquoi l'article 7 associe le registre à la gestion du renouvellement.

Ce que l'article 7 ne dit pas est tout aussi important. Il ne nomme aucun algorithme post-quantique, ne fixe aucune date de migration et n'impose aucun format de fichier particulier. C'est l'article 6 qui exige des dispositions pour mettre à jour ou modifier la technologie cryptographique en fonction de l'évolution de la cryptanalyse : c'est là que s'ancre la crypto-agilité. Notre lecture, présentée comme une interprétation : un registre qui consigne l'algorithme et la taille de clé de chaque certificat fait passer l'article 6 d'une intention écrite à une mesure exécutable, car vous pouvez lister en quelques minutes tous les actifs qui reposent encore sur des signatures RSA ou ECDSA.

Champs à consigner pour chaque certificat

Gardez le registre lisible par machine (une ligne par certificat, exportée depuis vos sources plutôt que saisie à la main). Les colonnes ci-dessous couvrent les obligations de l'article 7 et contiennent les données dont une migration post-quantique a besoin.

Deux champs valent l'effort de les ajouter, même si aucun texte ne les exige : la surface de déploiement (quel répartiteur de charge, ingress, broker ou pair TLS mutuel présente le certificat) et un indicateur de préparation post-quantique par actif, renseigné à partir de mesures plutôt que d'intentions.

Cycle de vie des clés : ce qu'il faut consigner pour les clés, et non pour les certificats

Un certificat est un objet public doté d'une date d'expiration. L'obligation relative au cycle de vie des clés porte sur des éléments que vous ne devez jamais exporter : le registre consigne donc des faits relatifs à la clé plutôt que la clé elle-même. Pour chaque clé, ou pour chaque catégorie de clés lorsque vous en avez des milliers, consignez : la méthode de génération et la source d'entropie, l'algorithme approuvé et ses paramètres, la frontière de stockage (logiciel, HSM, magasin de clés cloud avec son niveau de protection), les détenteurs des droits d'administration et de récupération, les dispositifs de sauvegarde et de séquestre, la durée d'archivage des clés qui doivent encore permettre de vérifier d'anciennes signatures, les critères de retrait, la procédure de destruction et ses preuves, ainsi que le plan de réponse en cas de compromission et son décideur.

Distinguez trois catégories, car leurs trajectoires de migration diffèrent. Les clés d'accord de clés protègent la confidentialité en transit, et un trafic enregistré peut être déchiffré plus tard si l'accord de clés est cassé : c'est pourquoi le scénario « récolter maintenant, déchiffrer plus tard » fait de l'échange de clés le premier élément à migrer. Les clés de signature servent à authentifier, et une signature falsifiée en 2035 ne peut pas compromettre rétroactivement une session d'aujourd'hui : les certificats peuvent donc migrer après l'échange de clés. Les clés de signature à longue durée de vie font exception : les clés de signature de micrologiciels et de logiciels qui doivent rester dignes de confiance pendant une décennie méritent une attention dès maintenant, et le NIST a normalisé des signatures fondées sur le hachage avec état précisément pour ce cas dans SP 800-208 (LMS et XMSS, voir SP 800-208).

Découverte : comment alimenter le registre

Aucune source ne contient à elle seule tous les certificats. Combinez-en au moins quatre, et considérez chacune comme partielle.

1. Interroger les autorités de certification

Les bases de données des AC internes et vos comptes auprès des AC publiques recensent tout ce qu'elles ont émis. Les émissions publiques sont également visibles dans les journaux Certificate Transparency, ce qui constitue le moyen le plus rapide de trouver des certificats émis pour vos domaines par des équipes dont vous ignoriez l'existence.

2. Analyser ce qui est réellement à l'écoute

Des vérifications en lecture seule sur un hôte montrent le certificat réellement en production, qui n'est parfois pas celui que vous pensez avoir déployé. Testez d'abord dans un environnement hors production et vérifiez que vous disposez de l'autorisation d'effectuer ces analyses.

# Inspect the presented chain and the key algorithm
openssl s_client -connect host.example.com:443 -servername host.example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -serial -fingerprint -sha256 -text \
  | grep -E "Subject:|Issuer:|Not (Before|After)|Public Key Algorithm|Public-Key|Signature Algorithm|DNS:"

# Which key agreement group was negotiated (OpenSSL 3.5 or later for the ML-KEM groups)
openssl s_client -connect host.example.com:443 -servername host.example.com \
  -groups X25519MLKEM768:X25519 </dev/null 2>/dev/null | grep -E "Negotiated|Protocol"

3. Passer en revue les systèmes de fichiers et les magasins de clés

# Certificates and keys on disk, with expiry, for one host
find /etc /opt /srv -type f \( -name "*.pem" -o -name "*.crt" -o -name "*.cer" \) 2>/dev/null \
  | while read -r f; do
      printf '%s\t' "$f"
      openssl x509 -in "$f" -noout -subject -enddate 2>/dev/null || echo "not a certificate"
    done

# Java keystore contents (read-only listing)
keytool -list -v -keystore /path/to/keystore.jks | grep -E "Alias name|Valid from|Signature algorithm"

4. Interroger les plateformes qui gèrent les certificats pour vous

Secrets Kubernetes et ressources cert-manager, gestionnaires de certificats cloud, coffres de clés cloud et partitions HSM, maillages de services émettant des certificats TLS mutuel de courte durée, passerelles d'API, brokers de messages, configuration TLS des bases de données, concentrateurs VPN et services de signature de code. Les certificats de maillage à courte durée de vie sont généralement mieux consignés sous la forme d'une ligne de politique (émetteur, algorithme, durée de vie, mécanisme de rotation) que sous la forme de millions de lignes individuelles ; indiquez-le explicitement dans le registre afin qu'un évaluateur voie que ce choix est délibéré.

# cert-manager inventory across a cluster (read-only)
kubectl get certificates -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,SECRET:.spec.secretName,RENEWAL:.status.renewalTime,EXPIRY:.status.notAfter

Dès le premier jour, l'automatisation compte davantage que l'exhaustivité. Les instructions fédérales américaines issues de l'OMB M-26-15 demandent un inventaire cryptographique automatisé et mis à jour en continu, et ce principe se transpose bien : un registre actualisé par une tâche planifiée perdure, un tableur actualisé par bonne volonté ne perdure pas.

Rattacher le registre à l'inventaire cryptographique

Le registre des certificats est une couche d'un inventaire plus large. Gardez-les liés plutôt que fusionnés : le registre des certificats indique quels éléments d'authentification existent et quand ils expirent, tandis que l'inventaire cryptographique indique quels algorithmes vos logiciels et protocoles utilisent réellement, y compris l'accord de clés, le chiffrement symétrique au repos, le hachage et les bibliothèques. Une nomenclature cryptographique (CBOM, cryptography bill of materials) est une manière concrète d'exprimer la couche logicielle, comme décrit dans qu'est-ce qu'un CBOM ; il s'agit de notre interprétation des bonnes pratiques, et non d'une exigence de DORA.

Les mêmes livrables servent plusieurs référentiels, ce qui plaide pour ne les construire qu'une seule fois.

Concernant les dates, maintenez des distinctions précises. L'exigence 12.3.3 de PCI DSS v4.0.1 est obligatoire depuis le 31 mars 2025. La feuille de route de mise en œuvre coordonnée de l'UE v1.1, publiée le 23 juin 2025, constitue une orientation coordonnée à destination des États membres et non un règlement contraignant pour les entreprises : elle situe les inventaires cryptographiques et les feuilles de route nationales d'ici fin 2026, la migration des cas d'usage à haut risque d'ici fin 2030 et celle des cas à risque moyen d'ici fin 2035. NIST IR 8547 reste un projet initial soumis à consultation publique ; il propose de déprécier les algorithmes vulnérables au quantique offrant une sécurité de 112 bits après 2030 et d'interdire les algorithmes à clé publique vulnérables au quantique après 2035, et il devrait être cité en tant que projet. L'ensemble des jalons datés figure sur notre page consacrée aux réglementations.

Pièges courants

• Ne consigner que les certificats web publics. Le TLS mutuel entre services internes, les clients de bases de données, les brokers de messages, la signature de code et l'identité des équipements sont généralement plus nombreux que les certificats publics.
• Omettre l'emplacement de la clé privée. Sans cette information, vous ne pouvez pas répondre à la seule question qui compte lors d'une compromission : où se trouve la clé et qui peut y accéder.
• Considérer l'expiration comme le seul événement du cycle de vie. Une révocation qui n'a jamais été mise en œuvre est un contrôle non testé.
• Laisser le périmètre dériver sans s'en apercevoir. Lorsqu'une fonction est reclassée comme critique ou importante, ses certificats entrent dans le périmètre. Réappliquez la règle de périmètre à intervalles réguliers et conservez le résultat daté.
• Confondre la migration des certificats avec celle de l'échange de clés. L'accord de clés hybride protège le trafic enregistré aujourd'hui et peut déjà être déployé ; les certificats post-quantiques dépendent de la prise en charge par les AC et les clients. Commencez par l'échange de clés, comme expliqué dans crypto-agilité.
• Conserver des algorithmes obsolètes antérieurs à la normalisation. Les groupes TLS issus des projets Kyber sont remplacés par les groupes ML-KEM normalisés ; le groupe hybride à rechercher est X25519MLKEM768.

Étape suivante : mesurer avant de documenter

Un registre fondé sur des intentions vieillit mal : renseignez donc les colonnes algorithme et préparation à partir de mesures. Pour chaque actif accessible depuis l'extérieur et soutenant une fonction critique ou importante, analysez votre domaine avec PQC Status afin de relever les versions TLS négociées, les groupes d'accord de clés proposés, les suites cryptographiques et la chaîne de certificats, puis reportez ces valeurs directement dans le registre. L'analyse décrit uniquement la configuration TLS visible de l'extérieur : il ne s'agit ni d'une certification ni d'une attestation de conformité, et notre page de méthodologie précise exactement ce qu'elle prouve et ce qu'elle ne prouve pas. Une fois la surface externe consignée, répétez les commandes de découverte ci-dessus sur les services internes à l'écoute, attribuez un propriétaire à chaque ligne et planifiez l'export afin que le registre s'actualise de lui-même.