Gestion des clés cryptographiques pour ISO 27001, NIS2 et DORA
À 08 h 17 un lundi matin, le RSSI d’une entreprise SaaS européenne reçoit un message du responsable de l’ingénierie : « Nous avons effectué la rotation de la clé de chiffrement de la base de données pendant le week-end, mais une intégration ne parvient plus à déchiffrer les enregistrements. Nous avons rétabli le service en utilisant une ancienne clé du coffre-fort. »
Dix minutes plus tard, le DPO demande si les enregistrements concernés incluent des données à caractère personnel de l’UE. La direction financière demande si l’événement pourrait devenir un incident opérationnel notifiable pour un client réglementé. Les achats demandent si le fournisseur de services cloud ou l’entreprise est propriétaire de la clé gérée par le client. Le directeur général pose la seule question qui compte en comité de direction : « Pouvons-nous prouver que nous avons géré cela correctement ? »
C’est le moment où « nous utilisons le chiffrement » cesse d’être une formule rassurante et devient un sujet d’éléments probants.
En 2026, la gestion des clés cryptographiques se situe au croisement des contrôles ISO/IEC 27001:2022, de l’hygiène cyber NIS2, de la gestion des risques liés aux TIC DORA, des éléments probants relatifs à la sécurité du traitement exigés par GDPR Article 32, du modèle de responsabilité partagée du cloud et de la planification de l’agilité cryptographique post-quantique. Le véritable sujet n’est pas de savoir si le chiffrement existe. Il est de savoir si l’organisation peut démontrer, au moyen d’enregistrements, que les clés sont générées de manière sécurisée, attribuées à des propriétaires, stockées dans des environnements KMS ou HSM approuvés, soumises à rotation selon le calendrier défini, récupérées de manière sûre, révoquées en cas de compromission et rattachées au risque métier.
Clarysec observe régulièrement le même schéma dans les travaux de préparation. Le chiffrement est mis en œuvre système par système, mais la gouvernance des clés reste fragmentée. Les certificats vivent dans des feuilles de calcul. Les autorisations KMS dans le cloud sont héritées d’anciens projets. Les développeurs savent quels secrets sont critiques, mais le SMSI ne le sait pas. Les auditeurs reçoivent des captures d’écran plutôt que des éléments probants couvrant le cycle de vie. Les équipes NIS2 et DORA parlent de résilience, les équipes protection des données parlent de chiffrement et de pseudonymisation au titre du GDPR, et personne n’est responsable de bout en bout du plan de contrôle cryptographique.
Une réponse mature ne consiste pas à ajouter davantage de cryptographie isolée. Elle consiste à mettre en place une gestion gouvernée des clés cryptographiques, reliée au traitement du risque, à l’architecture cloud, à la supervision des prestataires, au contrôle des accès, à la journalisation, à la réponse aux incidents et aux éléments probants réglementaires.
Pourquoi la gestion des clés est désormais un enjeu de gouvernance
NIS2 fait des politiques de cryptographie et de chiffrement une composante des mesures minimales de gestion des risques de cybersécurité pour les entités essentielles et importantes. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité, la sécurité de la chaîne d’approvisionnement, le développement sécurisé, l’hygiène cyber, le contrôle des accès, la gestion des actifs, ainsi que les politiques de cryptographie et de chiffrement. Il impose également aux organes de direction d’approuver et de superviser les mesures de gestion des risques de cybersécurité.
Pour les fournisseurs SaaS, cloud, de services managés et de cybersécurité, le champ d’application peut être plus large que beaucoup d’équipes ne l’imaginent. NIS2 couvre des secteurs tels que l’infrastructure numérique, les fournisseurs de services d’informatique en nuage, les fournisseurs de centres de données, les fournisseurs DNS, les prestataires de services de confiance, les prestataires de services managés, les prestataires de services de sécurité managés, les places de marché en ligne, les moteurs de recherche et les plateformes de réseaux sociaux lorsque les seuils de taille ou de criticité sont atteints.
DORA élève le niveau d’exigence pour les entités financières. À compter du 17 janvier 2025, DORA exige un cadre documenté de gestion des risques liés aux TIC, la responsabilité de l’organe de direction, des plans de continuité d’activité TIC ainsi que des plans de réponse et de rétablissement, des tests de résilience opérationnelle numérique, la gestion du risque lié aux prestataires tiers TIC et la notification des incidents. Pour les entités financières identifiées au titre des règles nationales NIS2, DORA constitue l’acte juridique sectoriel de l’Union pour les obligations NIS2 équivalentes. Une fintech ne doit pas gérer une gouvernance cryptographique distincte pour NIS2, DORA et ISO. Elle a besoin d’un modèle de contrôle unique et défendable.
GDPR ajoute la dimension des éléments probants en matière de protection de la vie privée. GDPR Article 32 est l’endroit où le chiffrement est couramment évalué comme mesure de sécurité du traitement, mais « les données sont chiffrées » n’est pas une réponse complète. Les autorités de contrôle et les auditeurs demandent qui contrôle les clés, comment l’accès est restreint, comment la compromission est détectée, comment la récupération fonctionne et si la conception est adaptée au risque pour les personnes.
ISO/IEC 27001:2022 fournit aux organisations le système de management permettant de relier ces obligations. Les clauses 4.1 à 4.4 exigent le contexte, les exigences des parties intéressées, le domaine d’application du SMSI et les processus en interaction. Les clauses 5.1 à 5.3 exigent le leadership, la politique, les ressources et les responsabilités attribuées. Les clauses 6.1.1 à 6.1.3 exigent l’appréciation du risque, le traitement du risque, la sélection des contrôles, une déclaration d’applicabilité et l’approbation par le propriétaire du risque. Les clauses 8.1 à 8.3 exigent une exploitation maîtrisée, une réévaluation des risques lorsque des changements surviennent, la mise en œuvre des plans de traitement du risque et la conservation des résultats documentés.
Pour la gestion des clés cryptographiques, le SMSI doit répondre à cinq questions :
- Quels actifs informationnels, flux de données et services nécessitent une protection cryptographique ?
- Quelles clés, quels certificats, quels secrets et quels services cryptographiques les protègent ?
- Qui possède, administre, approuve et surveille ces actifs cryptographiques ?
- Comment la génération, le stockage, l’utilisation, la rotation, le séquestre, la récupération, la révocation et la destruction sont-ils contrôlés ?
- Quels éléments probants démontrent que les contrôles ont fonctionné comme prévu ?
L’ossature de contrôle ISO 27001 pour la gestion des clés cryptographiques
Clarysec traite la gestion des clés cryptographiques comme une chaîne de contrôles, et non comme un contrôle unique. Dans Zenith Controls : le guide de conformité croisée Zenith Controls, le sujet se rattache principalement à la mesure 8.24 d’ISO/IEC 27002:2022, Utilisation de la cryptographie, avec des relations de soutien importantes avec 5.17, Informations d’authentification, et 5.23, Sécurité de l’information pour l’utilisation des services cloud.
Cette relation est déterminante. Une défaillance de gestion des clés est rarement seulement un « mauvais chiffrement ». Il s’agit souvent d’un problème d’authentification, d’un problème de gouvernance du cloud, d’un problème fournisseur, d’une lacune de journalisation ou d’une défaillance de gestion des changements.
| Domaine ISO/IEC 27002:2022 | Pourquoi il est important pour la gestion des clés | Éléments probants types |
|---|---|---|
| 8.24 Utilisation de la cryptographie | Définit les cas d’usage cryptographiques approuvés, les algorithmes, les protocoles, le cycle de vie des clés et les attentes de mise en œuvre | Politique cryptographique, norme d’algorithmes, procédure de cycle de vie des clés, configuration KMS, enregistrements de rotation |
| 5.17 Informations d’authentification | Protège les identifiants, secrets, jetons et supports d’authentification liés aux opérations cryptographiques à privilèges | Inventaire des secrets, journaux d’accès au coffre-fort, revues des accès à privilèges, éléments probants MFA |
| 5.23 Sécurité de l’information pour l’utilisation des services cloud | Définit la responsabilité partagée, la propriété des clés dans le cloud, les décisions CMK ou BYOK et la gouvernance du prestataire | Registre des services cloud, matrice de responsabilité partagée, architecture KMS, revue de sécurité fournisseur |
| 5.19 à 5.22 Sécurité des fournisseurs | Vérifie que les fournisseurs et les prestataires de services TIC satisfont aux exigences de chiffrement, de garde des clés, d’incident et d’audit | Contrats, diligence raisonnable, assurance fournisseur, revues de surveillance |
| 5.24 à 5.28 Gestion des incidents | Relie la suspicion de compromission de clé à l’évaluation d’événement, à la réponse, au retour d’expérience et à la collecte des éléments probants | Procédures opérationnelles d’incident, playbooks de compromission de clés, journaux forensiques, retours d’expérience |
| 8.15 et 8.16 Journalisation et surveillance | Détecte l’utilisation non autorisée de clés, les appels API suspects, les tentatives de déchiffrement échouées et les changements de politique | Alertes SIEM, journaux d’audit KMS, règles de détection d’anomalies |
| 8.32 Gestion des changements | Contrôle les rotations, les migrations, les mises à niveau d’algorithmes, les révocations d’urgence et les travaux de transition post-quantique | Tickets de changement, approbations, plans de retour arrière, résultats des tests |
Le Zenith Blueprint : feuille de route d’audit en 30 étapes Zenith Blueprint rend ce dispositif opérationnel dans la phase de gestion des risques, étape 14, Politiques de traitement du risque et références réglementaires croisées. Son exemple de politique cryptographique indique que l’organisation doit définir où la cryptographie est nécessaire, approuver les algorithmes et les protocoles, définir la gestion des clés, couvrir des cas d’usage comme le chiffrement intégral du disque et les communications sécurisées, et relier la politique à GDPR Article 32.
« Les clés de chiffrement doivent être stockées de manière sécurisée, par exemple dans un coffre de clés ou un HSM, et l’accès doit être limité au personnel autorisé. »
Attribution : Zenith Blueprint, phase de gestion des risques, étape 14, Politiques de traitement du risque et références réglementaires croisées Zenith Blueprint
Dans la phase Contrôles en action, étape 20, le Zenith Blueprint va plus loin. La cryptographie ne consiste pas à « activer le chiffrement ». Elle consiste à intégrer la cryptographie à la conception, à la politique et à la gestion du cycle de vie. Cela inclut les données au repos, les données en transit, l’authentification des identités et des transactions, les algorithmes approuvés, les coffres de clés, les HSM, la rotation planifiée, la révocation et la validation par des tests d’intrusion et des revues de code.
Ce que les auditeurs attendent lorsqu’ils demandent des éléments probants sur les clés
La plupart des constats d’audit commencent par une demande simple : « Montrez-moi votre politique de chiffrement et vos enregistrements de gestion des clés. »
Les réponses faibles incluent :
- « Le fournisseur de services cloud chiffre tout par défaut. »
- « Nous utilisons TLS. »
- « Les secrets sont dans le coffre-fort. »
- « L’équipe d’ingénierie gère la rotation. »
- « La clé est gérée par l’application. »
Ces affirmations peuvent être techniquement exactes, mais elles ne constituent pas des éléments probants complets. Un auditeur ISO rattache la gestion des clés à l’appréciation du risque, à la déclaration d’applicabilité, aux exigences de politique, à la maîtrise opérationnelle et à la documentation conservée. Un évaluateur NIST CSF demandera si les actifs cryptographiques sont identifiés, protégés, surveillés et récupérables. Un auditeur DORA recherchera une gouvernance du risque lié aux TIC approuvée par l’organe de direction, les dépendances vis-à-vis des prestataires tiers, la gestion des incidents et les tests de résilience. Un examinateur GDPR demandera si le chiffrement et la séparation des clés réduisent le risque pour les personnes et si le responsable du traitement peut démontrer son obligation de rendre compte.
La Politique sur les contrôles cryptographiques d’entreprise de Clarysec Politique sur les contrôles cryptographiques répond directement à cette lacune d’éléments probants :
« Un registre centralisé de gestion des clés doit être tenu afin d’enregistrer toutes les clés cryptographiques, leur statut dans le cycle de vie, les dépositaires désignés et les contextes d’utilisation. »
Attribution : politique d’entreprise, Politique sur les contrôles cryptographiques, exigences de gouvernance, clause 5.2 Politique sur les contrôles cryptographiques
Cette phrase change la discussion d’audit. Au lieu de rechercher des connaissances tacites, l’organisation peut présenter un registre reliant les clés aux actifs, aux propriétaires, aux classifications de données, aux systèmes, aux comptes cloud, aux dates de rotation, aux contextes d’utilisation et aux éléments probants.
Pour les PME, la Politique sur les contrôles cryptographiques pour PME de Clarysec Politique sur les contrôles cryptographiques pour PME adapte la même exigence :
« Le prestataire de support informatique doit tenir un inventaire à jour des outils cryptographiques et des certificats utilisés. »
Attribution : politique PME, Politique sur les contrôles cryptographiques pour PME, exigences de gouvernance, clause 5.1.2 Politique sur les contrôles cryptographiques pour PME
Un établissement financier réglementé peut avoir besoin de cérémonies HSM, de connaissance partagée, de double contrôle, de désignations formelles des dépositaires et de revues trimestrielles des accès. Un petit fournisseur SaaS peut commencer par un inventaire maintenu, des algorithmes approuvés, une propriété KMS documentée et des éléments probants de rotation. Dans les deux cas, la gouvernance doit être proportionnée au risque.
Le cycle de vie des clés que votre SMSI doit contrôler
Un programme pratique de gestion des clés suit le cycle de vie. Chaque étape nécessite un propriétaire, une méthode approuvée, un contrôle technique, un enregistrement de changement et des éléments probants d’audit.
| Étape du cycle de vie | Question de gouvernance des clés | Attente de contrôle | Exemple d’élément probant |
|---|---|---|---|
| Classification | Quelles données ou transactions nécessitent une protection cryptographique ? | La classification des données identifie les données à caractère personnel, les données financières, les identifiants, les journaux, les sauvegardes et les configurations sensibles | Registre de classification des données, matrice des exigences de chiffrement |
| Conception | Quelle méthode cryptographique est approuvée ? | Les algorithmes, protocoles, bibliothèques et longueurs de clés approuvés sont définis et revus | Norme cryptographique, enregistrement de décision d’architecture |
| Génération | Comment les clés sont-elles créées de manière sécurisée ? | Les clés sont générées dans des KMS, HSM ou modules validés approuvés, et non manuellement ni dans le code source | Journaux de création de clés KMS, enregistrement de cérémonie HSM |
| Attribution | Qui possède et administre la clé ? | Le propriétaire métier, le dépositaire technique et le dépositaire suppléant sont désignés | Registre de gestion des clés |
| Stockage | Où la clé est-elle stockée ? | Les clés sont stockées dans un KMS, un HSM ou un coffre-fort avec contrôles d’accès et journalisation d’audit | Politique KMS, configuration du coffre-fort, journaux d’accès |
| Utilisation | Quels systèmes peuvent utiliser la clé ? | Le moindre privilège, l’identité des charges de travail, la séparation des tâches et l’accès API approuvé sont appliqués | Politique IAM, cartographie des comptes de service |
| Rotation | Quand et pourquoi la clé est-elle soumise à rotation ? | Rotation planifiée et rotation déclenchée par événement en cas de compromission ou de changement de rôle | Calendrier de rotation, tickets de changement, résultats des tests |
| Séquestre et récupération | Comment les services peuvent-ils être récupérés sans exposer les clés ? | Les procédures de sauvegarde et de récupération sont testées et l’accès est contrôlé | Test de récupération, enregistrement d’approbation du séquestre |
| Révocation | Que se passe-t-il après une compromission ou un retrait ? | Les clés et certificats sont révoqués ou désactivés, et les systèmes dépendants sont mis à jour | Ticket d’incident, journal de révocation |
| Destruction | Comment les clés retirées sont-elles détruites ? | La suppression sécurisée ou l’effacement cryptographique respecte les exigences de conservation et les obligations légales | Enregistrement de destruction, calendrier de suppression KMS |
La Politique sur les contrôles cryptographiques d’entreprise renforce la génération sécurisée :
« Génération des clés : réalisée au moyen de modules matériels ou logiciels sécurisés, par exemple des HSM ou des systèmes validés FIPS 140-2. »
Attribution : politique d’entreprise, Politique sur les contrôles cryptographiques, exigences de mise en œuvre de la politique, clause 6.3.1 Politique sur les contrôles cryptographiques
Elle précise également la rotation :
« Rotation des clés : requise à intervalles définis ou immédiatement en cas de compromission ou de changement de rôle. »
Attribution : politique d’entreprise, Politique sur les contrôles cryptographiques, exigences de mise en œuvre de la politique, clause 6.3.4 Politique sur les contrôles cryptographiques
Pour les PME, le même principe apparaît dans un langage opérationnel plus simple :
« La rotation des clés doit être effectuée conformément aux calendriers d’expiration ou en cas de compromission suspectée. »
Attribution : politique PME, Politique sur les contrôles cryptographiques pour PME, exigences de mise en œuvre de la politique, clause 6.3.4 Politique sur les contrôles cryptographiques pour PME
Ces clauses sont importantes pour NIS2 et DORA, car des clés obsolètes ou mal gouvernées ne sont pas seulement des faiblesses de confidentialité. Elles peuvent devenir des obstacles à la réponse aux incidents, des problèmes de dépendance fournisseur, des défaillances de reprise après sinistre et des sujets de notification client.
KMS dans le cloud, HSM et BYOK : le piège de la responsabilité partagée
Le chiffrement dans le cloud est l’une des sources les plus fréquentes de fausse assurance. Un fournisseur de services cloud peut chiffrer le stockage par défaut, mais cela ne signifie pas automatiquement que votre organisation a gouverné la clé.
Le Zenith Blueprint, phase Contrôles en action, étape 23, explique la mesure 5.23 d’ISO/IEC 27002:2022 en se concentrant sur la gouvernance du cloud, la visibilité et la responsabilité partagée. Il souligne que le fournisseur peut sécuriser l’infrastructure, mais que le client demeure responsable de ses données, de ses configurations, de ses politiques d’accès et de sa préparation à la réponse aux incidents.
« Les fournisseurs de services cloud sécurisent l’infrastructure, mais vous restez responsable de vos données, de vos configurations, de vos politiques d’accès et de votre préparation à la réponse aux incidents. »
Attribution : Zenith Blueprint, phase Contrôles en action, étape 23, Contrôles organisationnels 5.19-5.37 Zenith Blueprint
C’est ici que la responsabilité des clés dans le cloud devient un risque relevant de l’organe de direction. Une entreprise SaaS peut utiliser un chiffrement géré par le fournisseur pour des journaux à faible risque, des clés gérées par le client pour les bases de données clients, le BYOK pour des locataires réglementés et des clés racines adossées à un HSM pour la signature ou la tokenisation. Chaque choix emporte des implications de conformité.
La Politique d’utilisation du cloud d’entreprise de Clarysec Politique d’utilisation du cloud fournit une orientation de contrôle claire :
« Les clés gérées par le client (CMK) ou Bring Your Own Key (BYOK) doivent être utilisées lorsque le fournisseur cloud les prend en charge. »
Attribution : politique d’entreprise, Politique d’utilisation du cloud, exigences de mise en œuvre de la politique, clause 6.4.2 Politique d’utilisation du cloud
Cela ne signifie pas que chaque service cloud doit utiliser le BYOK. Cela signifie que l’organisation doit décider de manière délibérée, en fonction du risque, des engagements clients, des exigences contractuelles et de la capacité de récupération.
| Modèle de propriété des clés | Cas d’usage adapté | Axe de gouvernance |
|---|---|---|
| Clés gérées par le fournisseur | Télémétrie à faible risque, journaux non sensibles, chiffrement standard de la plateforme | Confirmer les contrôles du fournisseur, documenter la base de risque, surveiller la configuration du service |
| Clés gérées par le client | Bases de données de production, sauvegardes, enregistrements clients, charges de travail réglementées | Désigner un propriétaire, restreindre l’accès, journaliser l’utilisation des clés, effectuer la rotation et tester la récupération |
| BYOK ou gestion externe des clés | Locataires à risque élevé, cloisonnement contractuel, engagements envers des clients réglementés | Gérer l’import, la garde, la révocation, les clauses fournisseur et les tests de résilience |
| Clés adossées à un HSM | Clés racines de signature, autorités de certification, tokenisation et secrets à forte valeur | Appliquer le double contrôle, les enregistrements de cérémonie, la séparation des tâches et une surveillance stricte des accès |
DORA Article 28 et Article 30 rendent ce point particulièrement pertinent pour les entités financières. Ils exigent la gestion du risque lié aux prestataires tiers TIC, des registres des accords contractuels TIC, la diligence raisonnable, des droits d’audit et d’inspection, l’assistance en cas d’incident, la protection des données et l’accès, ainsi que des dispositions de récupération et de restitution. Si un fournisseur de services cloud ou un fournisseur SaaS gère les clés de chiffrement d’une fonction critique ou importante, cette relation doit être visible dans le registre des prestataires tiers TIC et dans les contrôles contractuels.
NIS2 exige également la sécurité de la chaîne d’approvisionnement, y compris les vulnérabilités propres aux fournisseurs, les pratiques de cybersécurité et les procédures de développement sécurisé. Si un fournisseur critique détient vos clés, exploite votre KMS, fournit votre HSM, gère le cycle de vie de vos certificats ou héberge vos sauvegardes chiffrées, ce fournisseur fait partie de votre environnement de contrôle cryptographique.
Approbation des algorithmes et crypto-agilité en 2026
Une politique de gestion des clés en 2026 ne doit pas seulement lister « AES-256 » et « TLS 1.2 ou version ultérieure ». Elle doit établir un processus d’approbation et de revue qui soutient la crypto-agilité. La crypto-agilité signifie que l’organisation peut identifier où les algorithmes, protocoles, certificats et longueurs de clés sont utilisés, évaluer l’exposition à une faiblesse ou à une obsolescence, puis migrer sans urgence désordonnée.
La politique PME de Clarysec indique :
« Seuls les algorithmes et protocoles conformes aux bonnes pratiques du secteur et approuvés par le prestataire de support informatique peuvent être utilisés, par exemple AES-256, RSA 2048, TLS 1.2 ou version ultérieure. »
Attribution : politique PME, Politique sur les contrôles cryptographiques pour PME, exigences de mise en œuvre de la politique, clause 6.2.1 Politique sur les contrôles cryptographiques pour PME
Elle exige également la documentation :
« Toutes les méthodes de chiffrement, par exemple AES-256 et TLS 1.2+, ainsi que les processus de gestion des clés, doivent être documentés. »
Attribution : politique PME, Politique sur les contrôles cryptographiques pour PME, exigences de gouvernance, clause 5.3.1 Politique sur les contrôles cryptographiques pour PME
La version conforme aux attentes d’audit est une norme cryptographique approuvée comprenant :
- Les algorithmes et protocoles autorisés pour les données au repos, les données en transit, les signatures, le hachage des mots de passe, la tokenisation et les sauvegardes.
- Les algorithmes, protocoles et bibliothèques interdits.
- Les longueurs minimales de clés et les durées de validité des certificats.
- Les plateformes approuvées de KMS, HSM, autorité de certification et gestion des secrets.
- Les exigences de génération sécurisée de nombres aléatoires.
- Les consignes aux développeurs pour les bibliothèques cryptographiques.
- Le processus de dérogation pour les systèmes hérités.
- Les déclencheurs de revue liés aux vulnérabilités, aux évolutions réglementaires, aux changements de fournisseur et à la planification de la transition post-quantique.
La planification post-quantique n’impose pas à chaque organisation de remplacer immédiatement toute sa cryptographie. Elle impose en revanche un inventaire. Sans inventaire cryptographique, vous ne pouvez pas savoir quels systèmes utilisent un chiffrement à clé publique de longue durée, quels certificats protègent les services critiques, où résident les clés de signature ni quels fournisseurs doivent prendre en charge la migration. Le registre de gestion des clés n’est pas de la bureaucratie. C’est le fondement de la crypto-agilité.
Un sprint de 90 minutes pour constituer les éléments probants de gestion des clés
Clarysec utilise souvent un sprint court de collecte d’éléments probants avec les équipes de direction, sécurité, cloud et conformité. L’objectif est de transformer rapidement des connaissances dispersées sur les clés en éléments probants d’audit.
Étape 1 : sélectionner un service critique
Choisissez un système pertinent pour NIS2, DORA ou GDPR. Il peut s’agir de l’identité client, du traitement des paiements, de la surveillance des transactions, de la base de données clients de production, d’une plateforme de sauvegarde chiffrée ou d’une API exposée aux clients.
Étape 2 : ouvrir le registre de gestion des clés
Utilisez l’exigence de registre centralisé de la Politique sur les contrôles cryptographiques comme structure. Si vous n’en disposez pas encore, créez un registre simple avec les champs suivants :
| Champ du registre | Exemple d’entrée |
|---|---|
| ID de clé ou de certificat | prod-db-cmk-eu-west-01 |
| Contexte d’utilisation | Chiffrement de la base de données clients de production |
| Données protégées | Données à caractère personnel des clients de l’UE et métadonnées de facturation |
| Propriétaire | Responsable de la plateforme |
| Dépositaire | Responsable de la sécurité cloud |
| Emplacement de stockage | KMS cloud, région UE |
| Type de clé | Clé symétrique gérée par le client |
| Date de création | 2026-01-14 |
| Fréquence de rotation | 180 jours |
| Dernière rotation | 2026-04-10 |
| Prochaine rotation | 2026-10-07 |
| Modèle d’accès | Rôle de service uniquement, administration via un groupe d’accès d’urgence |
| Journalisation | Journaux API KMS transférés vers le SIEM |
| Méthode de récupération | Sauvegarde KMS et procédure de restauration testée |
| Dépendance fournisseur | KMS du fournisseur de services cloud |
| Cartographie de conformité | ISO 8.24, 5.17, 5.23, GDPR Article 32, NIS2 Article 21, risque lié aux TIC DORA |
| Lien vers les éléments probants | Ticket de changement, capture d’écran KMS, revue IAM, requête de journal, test de récupération |
Étape 3 : tracer les accès et le double contrôle
Pour les opérations cryptographiques à fort impact, appliquez le double contrôle et le moindre privilège. La Politique sur les contrôles cryptographiques d’entreprise précise :
« Les principes de double contrôle et de moindre privilège doivent être appliqués aux opérations cryptographiques sensibles, par exemple les imports de clés racines et l’administration HSM. »
Attribution : politique d’entreprise, Politique sur les contrôles cryptographiques, exigences de mise en œuvre de la politique, clause 6.6.2 Politique sur les contrôles cryptographiques
Posez les questions suivantes :
- Qui peut désactiver ou supprimer la clé ?
- Qui peut modifier la politique de clé ?
- Qui peut déchiffrer directement les données ?
- Les rôles d’accès d’urgence sont-ils surveillés et limités dans le temps ?
- La MFA est-elle imposée pour les opérations à privilèges sur les clés ?
- Les actions à privilèges sont-elles journalisées et revues ?
Étape 4 : extraire cinq enregistrements d’éléments probants
Collectez cinq enregistrements démontrant que le contrôle fonctionne :
- Journal de création ou d’import de clé.
- Politique d’accès KMS ou HSM actuelle.
- Dernier ticket de changement de rotation de clé.
- Requête SIEM montrant l’utilisation de la clé ou les actions d’administration.
- Élément probant de test de récupération ou de restauration.
Étape 5 : cartographier le risque et la réglementation
Ajoutez une courte déclaration de risque : « L’utilisation non autorisée ou la perte de cette clé pourrait exposer des données à caractère personnel de l’UE, interrompre le service client et compromettre la récupération de systèmes critiques. » Puis rattachez-la aux obligations applicables.
| Obligation | Ce que les éléments probants soutiennent |
|---|---|
| Clauses 6 et 8 d’ISO/IEC 27001:2022 | Traitement du risque, maîtrise opérationnelle, résultats documentés |
| ISO/IEC 27002:2022 8.24 | Utilisation approuvée de la cryptographie et contrôle du cycle de vie des clés |
| NIS2 Article 21 | Politiques de cryptographie et de chiffrement, hygiène cyber, contrôle des accès, gestion des actifs |
| DORA Articles 5, 6, 17, 28 et 30 | Gouvernance TIC, cadre de gestion du risque lié aux TIC, processus d’incident, dépendances vis-à-vis de tiers et contrats |
| GDPR Article 5 et Article 32 | Obligation de rendre compte, intégrité et confidentialité, sécurité du traitement |
| NIST CSF 2.0 | Identifier les actifs, protéger les données, détecter les anomalies, répondre et rétablir |
En 90 minutes, l’équipe peut généralement déterminer si la gouvernance des clés est réelle ou seulement présumée.
Notification des incidents : quand la compromission d’une clé déclenche le compte à rebours
Une suspicion de compromission de clé n’est pas automatiquement une violation notifiable, mais elle peut déclencher le délai réglementaire.
Au titre de NIS2, les entités essentielles et importantes doivent notifier sans retard indu les incidents significatifs affectant la fourniture de services. Le modèle par étapes prévoit une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification d’incident dans les 72 heures, des mises à jour de statut lorsqu’elles sont demandées et un rapport final au plus tard un mois après la notification d’incident.
Au titre de DORA, les entités financières doivent détecter, gérer et notifier les incidents liés aux TIC, enregistrer les incidents et les cybermenaces significatives, classer les incidents selon leur gravité et la criticité des services affectés, communiquer avec les parties prenantes, déclarer les incidents majeurs à la direction générale et aux autorités compétentes, réaliser une analyse de la cause racine et remédier. L’externalisation de la notification peut être possible, mais la responsabilité demeure celle de l’entité financière.
Au titre du GDPR, la question devient de savoir si une violation de données à caractère personnel s’est produite, c’est-à-dire une destruction, une perte, une altération, une divulgation non autorisée ou un accès non autorisé à des données à caractère personnel, de manière accidentelle ou illicite. Un chiffrement robuste avec des clés non compromises peut modifier substantiellement l’analyse du risque de violation. Une gestion faible des clés peut affaiblir cet argument.
Les playbooks de compromission de clés doivent définir :
- Comment une exposition suspectée de clé est détectée.
- Qui déclare un incident cryptographique.
- Comment les données, services, clients et juridictions affectés sont identifiés.
- Comment les clés sont révoquées ou soumises à rotation.
- Comment les systèmes dépendants sont restaurés.
- Comment l’intégrité des éléments probants est préservée.
- Comment les décisions de notification juridique, réglementaire et client sont prises.
Le registre de gestion des clés devient essentiel pendant ce processus. Sans lui, les intervenants perdent du temps à identifier ce qu’une clé protégeait. Avec lui, ils peuvent circonscrire rapidement l’impact.
La perspective d’audit : un seul jeu de contrôles, plusieurs consommateurs d’éléments probants
Les différents auditeurs abordent la gestion des clés cryptographiques depuis des angles distincts, mais ils convergent vers les mêmes éléments probants.
| Perspective de l’auditeur | Question d’audit probable | Éléments probants efficaces |
|---|---|---|
| Auditeur ISO/IEC 27001:2022 | La gestion des clés cryptographiques est-elle sélectionnée dans le cadre du traitement du risque, documentée dans la déclaration d’applicabilité et exploitée comme prévu ? | Appréciation du risque, déclaration d’applicabilité, politique cryptographique, registre de gestion des clés, enregistrements de rotation |
| Évaluateur NIST CSF | Les actifs cryptographiques sont-ils identifiés, protégés, surveillés et récupérables ? | Inventaires des actifs et des données, contrôles d’accès, journaux KMS, alertes SIEM, enregistrements de réponse et de récupération |
| Auditeur DORA | Les dépendances liées aux clés font-elles partie de la gestion du risque lié aux TIC, de la supervision des prestataires tiers, des tests de résilience et de la notification des incidents ? | Cadre de gestion du risque lié aux TIC, registre des tiers, contrats KMS cloud, tests de continuité, processus de classification des incidents |
| Examinateur GDPR | Le chiffrement réduit-il le risque pour les personnes, et le responsable du traitement peut-il démontrer son obligation de rendre compte ? | Classification des données, séparation des clés, journaux des accès, conception du chiffrement, évaluation du risque de violation |
| Auditeur ISACA ou COBIT 2019 | Les objectifs de gouvernance, la propriété du risque, la performance des contrôles et la responsabilité de la direction sont-ils définis ? | RACI, indicateurs de contrôle, revue de direction, registre des exceptions, suivi de la remédiation d’audit |
Un dossier d’audit solide pour la gestion des clés cryptographiques contient généralement :
- Une Politique sur les contrôles cryptographiques approuvée.
- Une Politique d’utilisation du cloud approuvée lorsque le chiffrement cloud est concerné.
- Une norme cryptographique et une liste d’algorithmes.
- Un registre de gestion des clés.
- Un inventaire des certificats et des secrets.
- L’architecture KMS, HSM et coffre-fort.
- Des éléments probants de revue IAM et des accès à privilèges.
- Des enregistrements de rotation et de révocation.
- Des éléments probants de sauvegarde, de séquestre et de test de récupération.
- Des règles de journalisation et de surveillance de l’activité des clés.
- Une cartographie des fournisseurs et de la responsabilité partagée du cloud.
- Un playbook d’incident pour suspicion de compromission de clé.
- Les exceptions et acceptations de risque.
- Les enregistrements de revue de direction et de remédiation d’audit.
Ce dossier transforme une affirmation de contrôle en preuve.
Constats fréquents dans les audits de gestion des clés
Les constats les plus fréquents sont évitables :
- Aucun inventaire unique des clés, certificats et outils cryptographiques.
- Le chiffrement par défaut du fournisseur de services cloud est traité comme une gouvernance complète des clés.
- Aucun propriétaire ni dépositaire n’est désigné pour les clés de production.
- La rotation existe pour les certificats, mais pas pour les clés applicatives ni pour les CMK de bases de données.
- Les secrets et les clés sont mélangés dans le même coffre-fort sans classification.
- Les développeurs peuvent créer des clés en dehors des modèles approuvés.
- Aucun élément probant ne démontre que les administrateurs KMS sont revus.
- Les procédures de récupération existent mais n’ont jamais été testées.
- La compromission de clés n’est pas incluse dans les playbooks de réponse aux incidents.
- Des algorithmes hérités subsistent dans des services internes parce que personne n’est propriétaire de la remédiation.
- Des engagements BYOK sont pris dans les contrats clients sans être reflétés dans les opérations.
- Le chiffrement géré par les fournisseurs n’est pas inclus dans les revues de risque fournisseur.
Chaque constat renvoie à la gouvernance. C’est pourquoi la cryptographie ne peut pas être traitée comme un projet purement technique. Elle doit être reliée au domaine d’application du SMSI, au traitement du risque, à la politique, aux fournisseurs, au cloud, aux accès, à la journalisation, aux incidents et à la continuité.
Rendre la gouvernance des clés conforme aux attentes d’audit avant le prochain incident
Si votre organisation se prépare à NIS2, DORA, aux éléments probants attendus au titre de GDPR Article 32, à la certification ISO/IEC 27001:2022 ou à la crypto-agilité post-quantique, commencez par une question : pouvez-vous produire aujourd’hui un registre complet de gestion des clés ?
Si ce n’est pas le cas, Clarysec peut vous aider à construire le système de contrôle autour de ce registre.
Utilisez le Zenith Blueprint Zenith Blueprint pour structurer les travaux au travers de l’étape 14 de la phase de gestion des risques et de l’étape 20 de la phase Contrôles en action. Utilisez Zenith Controls Zenith Controls pour cartographier les contrôles ISO/IEC 27002:2022 8.24, 5.17 et 5.23 avec NIS2, DORA, GDPR, NIST et les attentes d’audit. Utilisez la Politique sur les contrôles cryptographiques de Clarysec Politique sur les contrôles cryptographiques, la Politique sur les contrôles cryptographiques pour PME Politique sur les contrôles cryptographiques pour PME et la Politique d’utilisation du cloud Politique d’utilisation du cloud pour transformer les exigences en règles opérationnelles.
L’étape pratique suivante est simple : choisissez un service critique, inventoriez ses clés, prouvez la propriété, validez les accès, extrayez les éléments probants de rotation et testez la récupération. Si cela prend plus d’une journée, votre gouvernance cryptographique nécessite une attention immédiate avant que l’autorité de contrôle, l’auditeur ou l’équipe de réponse aux incidents ne pose la même question sous pression.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
