Politique de cryptographie au titre de l'article 21(2)(h)
Chiffrer le trafic n'est pas la même chose qu'avoir une politique de cryptographie. L'article 21(2)(h) de NIS 2 exige la politique. Le §9 du CIR précise ce qu'elle doit contenir : choix d'algorithmes, robustesse des clés, agilité cryptographique et cycle de vie de gestion des clés en douze points.
En bref
La cryptographie dans NIS 2, ce n'est pas la mesure technique. C'est la politique écrite qui décide quelle cryptographie vous utilisez, où, et comment les clés sont gérées. L'article 21(2)(h) tient en une ligne. Le §9 du CIR transforme cette ligne en un document réel avec des sections concrètes.
La politique doit faire trois choses. Lier la robustesse cryptographique à votre classification des actifs. Nommer les algorithmes, tailles de clés et protocoles approuvés, avec une approche d'agilité cryptographique permettant de les remplacer à mesure que l'état de l'art évolue. Et couvrir l'intégralité du cycle de vie de gestion des clés (le CIR nomme douze étapes distinctes, de la génération à la destruction).
L'Allemagne inscrit la même obligation au §30(2)(8) BSIG. L'ancrage technique du BSI est la série TR-02102 (TR-02102-1 pour les algorithmes et longueurs de clés, TR-02102-2/-3/-4 pour TLS, IPsec, SSH). Cette page parcourt la directive, le détail du CIR et la transposition allemande, dans cet ordre.
Article 21(2)(h) de la directive NIS 2 (2022/2555)
Les politiques et procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement.
Point (h) de la liste des dix mesures de cybersécurité que toute entité essentielle et importante doit mettre en place. « Le cas échéant » s'applique au chiffrement (l'application), pas au fait d'avoir la politique (qui est obligatoire).
CIR (UE) 2024/2690, annexe §9
Les entités concernées établissent, mettent en œuvre et appliquent une politique et des procédures relatives à la cryptographie, afin d'assurer une utilisation adéquate et efficace de la cryptographie pour protéger la confidentialité, l'authenticité et l'intégrité des données, conformément à la classification des actifs et de la valeur de l'entité et aux résultats de l'évaluation des risques.
Parce qu'il s'agit d'un règlement (et non d'une directive), c'est un droit de l'UE directement contraignant pour les secteurs de son annexe (DNS, TLD, cloud, centres de données, MSP, services de confiance et autres). Le §9.2 précise les trois sections que la politique doit contenir, le §9.3 fixe une obligation de réexamen périodique en gardant l'agilité cryptographique à l'esprit.
§30(2)(8) BSIG (Allemagne)
Les concepts et procédures relatifs à l'utilisation de la cryptographie et, le cas échéant, du chiffrement.
L'Allemagne reprend le texte de l'UE presque mot pour mot. La référence technique du BSI est TR-02102 (la série qui nomme les algorithmes approuvés, les longueurs de clés et les configurations de protocole). Le module IT-Grundschutz CON.1 (Krypto-Konzept) fournit le modèle de mise en œuvre.
Faire correspondre la robustesse cryptographique à la classification des actifs
Pour chaque classe de données ou d'actifs (confidentialité, authenticité, intégrité, par niveau de sensibilité), la politique nomme le type, la robustesse et la qualité des mesures cryptographiques utilisées. Le lien avec l'inventaire des actifs et l'évaluation des risques du §2.1 est explicite. Les données de plus grande valeur reçoivent une cryptographie plus forte ; la règle doit être écrite, pas improvisée.
Algorithmes approuvés, robustesse des clés, agilité cryptographique
La politique énumère les protocoles, algorithmes, robustesses de clés et procédures de gestion des clés que vous autorisez, et exclut ceux que vous n'autorisez pas. Le CIR nomme cela explicitement « une approche d'agilité cryptographique le cas échéant » : les algorithmes doivent être remplaçables à mesure que l'état de l'art évolue. Nouvel algorithme, nouvelle taille de clé, nouvelle version de protocole : la politique permet le remplacement, pas la réécriture.
Cycle de vie de gestion des clés en douze points
Le CIR §9.2(c) nomme douze étapes concrètes de gestion des clés : (i) génération, (ii) émission de certificat pour les clés publiques, (iii) distribution et activation, (iv) stockage et accès autorisé, (v) changement ou mise à jour, (vi) traitement des clés compromises, (vii) révocation, (viii) récupération des clés perdues ou endommagées, (ix) sauvegarde et archivage, (x) destruction, (xi) journalisation et audit, (xii) dates d'activation et de désactivation. Les douze figurent dans la politique.
La classification des actifs détermine la profondeur cryptographique (proportionnalité de l'art. 21(1))
Vous n'utilisez pas AES-256 avec des clés adossées à un HSM pour tout. Vous adaptez la cryptographie à la valeur et à l'exposition de l'actif. Base de données clients avec données personnelles, dossiers financiers, code source : niveau élevé. Modèles internes et notes de réunion : niveau bas. L'article 21(1) dispose que les mesures doivent être « appropriées au risque encouru ». Le CIR §9.2(a) intègre ce lien dans la politique.
Agilité cryptographique : réexaminer et remplacer (CIR §9.3)
Le CIR §9.3 dispose que vous réexaminez la politique à intervalles planifiés et la mettez à jour « le cas échéant, en tenant compte de l'état de l'art en cryptographie ». C'est l'agilité cryptographique en deux mots. SHA-1 convenait, puis ne convenait plus. RSA-1024 convenait, puis ne convenait plus. Le post-quantique arrive pour RSA et ECC au cours de la prochaine décennie. La politique doit permettre le remplacement, pas seulement décrire ce que vous utilisez aujourd'hui.
BSI / §30(2)(8) BSIG / TR-02102
L'Allemagne transpose l'article 21(2)(h) par le §30(2)(8) BSIG. L'ancrage technique est la série TR-02102 du BSI : TR-02102-1 pour les algorithmes cryptographiques et les longueurs de clés, TR-02102-2 pour TLS, -3 pour IPsec, -4 pour SSH. Le module IT-Grundschutz CON.1 (Krypto-Konzept) est le bloc qui opérationnalise une politique. Les auditeurs attendent que vous citiez TR-02102 ou que vous expliquiez pourquoi votre choix est au moins aussi robuste.
Orientations techniques de mise en œuvre de l'ENISA
Les orientations techniques de mise en œuvre de l'ENISA pour le CIR couvrent le §9 et le mettent en correspondance avec l'ISO/IEC 27001:2022 (A.8.24 Utilisation de la cryptographie), le NIST CSF 2.0, l'ETSI EN 319 401 et le CEN/TS 18026. Si vous exploitez déjà l'ISO 27001, les contrôles sont pour l'essentiel présents. NIS 2 veut tout de même que la politique soit structurée selon l'énumération du §9.2.
Lois nationales de transposition
Chaque État membre dispose de sa propre transposition (Pays-Bas : Cyberbeveiligingswet, Autriche : NISG, Belgique : NIS2-Wet). L'obligation est la même parce que la directive fixe une norme unique à l'échelle de l'UE. La référence technique nationale diffère : l'ANSSI en France publie le RGS, des orientations alignées sur l'ENISA sont réutilisées aux Pays-Bas. La structure de la politique ne change pas.
Nous avons TLS partout, donc c'est réglé.
Le chiffrement en transit n'est qu'une partie de la politique. Le CIR §9.2(c) veut l'intégralité du cycle de vie de gestion des clés par écrit : comment les clés sont générées, où elles résident, comment elles sont renouvelées, ce qui se passe quand l'une est compromise, qui peut les récupérer, quand elles sont détruites. Si ces douze points ne sont pas sur le papier, la politique n'est pas achevée, quelle que soit la quantité de TLS déployée.
Nous utilisons ce que notre fournisseur livre.
L'entité reste responsable. Le §30 BSIG et l'article 21 ne transfèrent pas l'obligation au fournisseur. Si votre fournisseur SaaS utilise AES-128 et que vous avez classé ces données comme hautement confidentielles, c'est à vous de le corriger dans la politique ou dans le contrat. La politique doit nommer ce que vous acceptez, pas seulement ce qui figurait dans la configuration par défaut.
La gestion des clés, c'est le problème de l'informatique.
La gestion des clés relève de la gouvernance. La politique est validée par l'organe de direction (l'article 20 et le schéma de validation par l'organe de direction qui traverse l'article 21). Lorsqu'une clé est compromise, la réponse passe par le processus d'incident au titre de l'article 23. Lorsque l'accès à une clé de grande valeur est accordé, il est journalisé. L'informatique exploite les contrôles ; la direction est titulaire de la politique.
Ce que nous voyons dans le Mittelstand allemand : le chiffrement en transit est en général correct (TLS, VPN, S/MIME ou SMTP-TLS pour le courrier). Le chiffrement au repos est inégal mais récupérable. Le véritable manque, c'est la documentation de la gestion des clés. Qui détient les clés maîtresses du VPN ? Où sont sauvegardées les clés KMS du cloud ? Qu'advient-il du certificat de chiffrement d'un partant ? La plupart des équipes connaissent les réponses ; les réponses ne sont pas écrites.
Une approche en deux temps qui résiste à l'audit. D'abord, écrire la politique : niveaux d'actifs, algorithmes approuvés (citer TR-02102 ou le TIG de l'ENISA), cycle de vie de gestion des clés couvrant les douze points du §9.2(c), validation par l'organe de direction. Ensuite, faire correspondre la politique aux systèmes que vous exploitez déjà (KMS cloud, autorité de certification, VPN, courrier, chiffrement de fichiers). La plupart des contrôles existent. La liste de vérification du §9.2(c) est l'artefact que les auditeurs réclament.
Nous fournissons un modèle de politique de cryptographie structuré selon le CIR §9.2(a), (b) et (c). Vous partez du modèle, nommez vos niveaux d'actifs, choisissez des algorithmes dans une liste alignée sur TR-02102 et parcourez le cycle de vie des clés en douze points. Le résultat est un document signé qui correspond directement aux sous-points du CIR auxquels un auditeur se référera.
L'inventaire des clés du module CRY répertorie les clés par finalité (TLS, signature, chiffrement, code), par système, par titulaire, par date d'activation et de désactivation. Le CIR §9.2(c)(xi) (journalisation) et le §9.2(c)(xii) (dates d'activation/désactivation) deviennent un tableau, pas un exercice de mémoire. Réexaminez la politique chaque année ; la plateforme planifie le réexamen du §9.3 et suit la validation.
- Directive (UE) 2022/2555 (NIS 2), article 21(2)(h) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement d'exécution (UE) 2024/2690 de la Commission (CIR), annexe §9 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Loi BSI (BSIG), §30(2)(8) tel que modifié par la loi de mise en œuvre de NIS2 et de renforcement de la cybersécurité
- Série BSI TR-02102 (Cryptographic Mechanisms: Recommendations and Key Lengths) — bsi.bund.de/dok/tr-02102
- IT-Grundschutz Kompendium, module CON.1 (Krypto-Konzept) — bsi.bund.de/grundschutz
- Orientations techniques de mise en œuvre de l'ENISA pour le CIR (UE) 2024/2690, correspondance avec l'ISO/IEC 27001:2022 A.8.24