Pour la plupart des fournisseurs de services informatiques et d’ software , la certification ISO 27001 a discrètement cessé d’être un simple atout. Elle est désormais une condition indispensable à l’exercice de leur activité. Les questionnaires de sécurité destinés aux clients, les appels d’offres et les évaluations des risques liés aux fournisseurs exigent de plus en plus souvent une certification à jour avant qu’un contrat puisse aboutir, ce qui signifie qu’un certificat périmé ne constitue plus seulement un problème de conformité. Il s’agit désormais d’un risque pour le chiffre d’affaires.
La cryptographie est au cœur même de cette évolution. La révision de la norme de 2022 a regroupé la cryptographie et la gestion des clés au sein d’un seul et même contrôle clairement défini : l’annexe A, paragraphe 8.24, « Utilisation de la cryptographie ». Ce guide détaille les changements apportés par la révision de 2022, ce qu’exige réellement le contrôle 8.24 et comment en apporter la preuve à un auditeur avant votre prochaine visite de surveillance.
Quels sont les changements apportés à la norme ISO/IEC 27001:2022 ?
La révision de 2022 a réorganisé l’annexe A en 93 mesures de contrôle réparties en quatre thèmes. En matière de cryptographie, le changement le plus important réside dans la consolidation : les deux mesures de contrôle distinctes de l’édition de 2013 (A.10.1.1, « Politique relative à l’utilisation des mesures de contrôle cryptographiques », et A.10.1.2, « Gestion des clés ») ont été fusionnées en une seule mesure de contrôle : 8.24, « Utilisation de la cryptographie ».
Cette consolidation a une incidence sur la manière dont les équipes documentent et justifient leur programme de cryptographie. Au lieu de considérer la politique de sécurité et la gestion des clés comme deux exigences vaguement liées, la section 8.24 exige une approche cohérente : une stratégie de cryptographie bien définie et un cycle de vie géré pour les clés qui la sous-tendent, le tout étroitement lié et étayé par des preuves.
Ce qu'exige réellement la norme 8.24
La mesure 8.24 repose sur deux piliers.
La première consiste en une politique de cryptographie documentée et fondée sur les risques, qui définit les algorithmes approuvés et les niveaux minimaux de sécurité des clés. La seconde consiste en une gestion du cycle de vie des clés couvrant l'ensemble de celui-ci : génération, distribution, révocation, traitement des clés compromises, récupération des clés perdues, stockage, rotation, sauvegarde et destruction.
Le point crucial pour les entreprises du secteur des technologies de l'information et de l'software , c'est la manière dont les auditeurs vérifient cela. Ils vérifient la conformité à la clause 8.24 à l'aide de preuves opérationnelles, et non pas uniquement sur la base des déclarations de politique générale. Concrètement, cela implique l’inventaire des certificats et des clés, les registres de rotation attestant que l’intervalle défini par la politique a bien été respecté, les résultats de configuration de l’ TLS et du chiffrement, les journaux d’accès aux HSM ou aux KMS, ainsi que les registres de destruction accompagnés d’une validation. Une politique bien rédigée dont personne ne peut prouver qu’elle est respectée ne satisfera pas un évaluateur. Et comme la clause 8.24 s’applique au produit, son champ d’application inclut systématiquement la cryptographie intégrée au produit lui-même, et pas seulement l’environnement informatique interne.
Pourquoi la conformité à la norme ISO 27001 en matière de cryptographie est-elle importante pour les fournisseurs informatiques ?
La certification ISO 27001 est techniquement facultative. Dans la pratique, pour les fournisseurs de services informatiques et d’ software , elle est devenue une condition préalable commerciale de facto. Les questionnaires de sécurité, les appels d’offres et les évaluations des risques liés aux fournisseurs exigent de plus en plus souvent une certification à jour comme condition pour conclure une affaire ; ainsi, une lacune dans vos contrôles cryptographiques peut bloquer les procédures d’achat et compromettre la conclusion de contrats ; cela se répercute sur les achats de deux manières : soit cela apparaît directement dans une réponse à un questionnaire de sécurité que vous ne pouvez pas justifier, soit cela devient un cas de non-conformité qui met en péril le certificat lui-même.
Il y a également une dimension temporelle. La norme ISO 27001 étant une norme relative aux systèmes de gestion, la clause 8.24 ne fait pas l’objet d’un contrôle ponctuel suivi d’un oubli. Les audits de surveillance procèdent à un échantillonnage du SMSI plutôt que de tester chaque contrôle ; ainsi, le point 8.24 peut être abordé ou non au cours d’une année donnée. La recertification est différente : elle confirme que le système répond à toutes les exigences de la norme, et pas seulement aux domaines échantillonnés lors de la surveillance. Dans la pratique, il est impossible de prédire quelle année la cryptographie fera l’objet d’un examen. Cette cadence récompense les organisations qui maintiennent un contrôle continu et prêt à être justifié sur la cryptographie, plutôt que celles qui s’empressent de le reconstituer avant chaque audit.
Il est utile de savoir comment un certificat peut effectivement être perdu : une non-conformité majeure n’entraîne pas son annulation immédiate. Les organismes de certification fixent un délai précis pour remédier au problème, et la suspension ou le retrait n’interviennent que si celui-ci n’est pas résolu. Le risque commercial réside moins dans le fait d’« avoir échoué à un audit » que dans le fait d’« avoir passé un trimestre avec une non-conformité majeure non résolue que nous avons dû divulguer ».
Comment la norme 8.24 correspond aux contrôles cryptographiques réels
Le point de contrôle 8.24 n'est pas isolé. Il s'inscrit dans un ensemble de domaines de contrôle concrets dont les évaluateurs s'attendent à ce qu'ils fonctionnent de manière coordonnée dans l'ensemble du périmètre certifié.
Une politique documentée en matière de cryptographie et de gestion des clés (annexe A, point 8.24)
Fondamentalement, la norme 8.24 préconise la mise en place d’une politique spécifique à chaque domaine, définissant les algorithmes approuvés, les longueurs minimales de clés et les règles relatives au cycle de vie. Cette politique doit être directement liée à l’évaluation des risques du SMSI, de sorte que chaque décision cryptographique puisse être rattachée à un risque documenté plutôt qu’à une simple préférence.
Le cycle de vie des clés cryptographiques (annexe A, point 8.24)
C'est au niveau du cycle de vie que la cryptographie forte présente le plus souvent des failles. Les auditeurs s'attendent à ce que la génération, la distribution, la rotation et la destruction des clés et des certificats soient centralisées, y compris celles intégrées aux software livrés, le tout s'appuyant sur une piste d'audit complète. La révocation, la gestion des clés compromises, la récupération des clés perdues, le stockage sécurisé et la sauvegarde complètent le tableau.
Confidentialité et intégrité des données (annexe A, points 5.14, 8.20 et 8.21 ; données à caractère personnel, point 5.34)
La cryptographie a pour but de protéger les données. Selon la section 8.24, la cryptographie est le mécanisme ; les contrôles qui créent l’obligation relèvent d’autres sections. L’annexe A, sections 5.34 (transfert d’informations) et 8.20–8.21 (sécurité des réseaux et des services réseau), régissent le chiffrement en transit. Les certificats délivrés par PKI sécurisent les données des clients au repos et en transit dans l’ensemble du périmètre certifié. Pour les fournisseurs de solutions « software », ce périmètre s’étend généralement aux environnements SaaS multi-locataires, dans lesquels de nombreux clients partagent la même infrastructure.
Cryptographie des produits (annexe A, points 8.25, 8.26 et 8.28)
Si la cryptographie fait partie intégrante de vos produits, c’est au niveau du cycle de vie de développement sécurisé (8.25), des exigences de sécurité des applications (8.26) et du codage sécurisé (8.28) que les auditeurs vérifient si les choix relatifs aux algorithmes et à la longueur des clés, définis dans votre politique 8.24, sont effectivement pris en compte dans le code source. Les contrôles des fournisseurs portent sur les bibliothèques héritées ; ceux-ci concernent votre propre code.
Authentification sécurisée (annexe A, point 8.5)
La section 8.5 de l'annexe A aborde la question de l'authentification dans le contexte de la cryptographie. L'authentification par certificat réduit le recours aux secrets partagés et aux mots de passe statiques, tant pour les accès clients que pour les accès administratifs, en remplaçant les identifiants, qui peuvent facilement faire l'objet de fuites, par des identités bien plus difficiles à utiliser à mauvais escient.
Cryptographie fournie par les fournisseurs et héritée (annexe A, points 5.21 et 8.8)
Les systèmes d’ software s modernes héritent de la cryptographie de bibliothèques et de tiers. L’annexe A, point 8.24, exige qu’un système de gestion des clés soit mis en place pour gérer la révocation des clés et les clés compromises. Chacune de ces obligations s’applique par clé, et une obligation par clé présuppose de savoir quelles clés existent. Pour l’annexe A, point 8.8, un inventaire précis des actifs est une condition préalable à une gestion efficace des vulnérabilités. L’annexe A, point 5.21, étend la question à la chaîne d’approvisionnement des TIC, où les composants sont du code appartenant à des tiers. Lues conjointement, l’inventaire n’est pas une exigence explicitement mentionnée ; c’est le seul moyen pratique de démontrer les quatre exigences qui le sont.
Déclaration de traçabilité de l'applicabilité (clause 6.1.3)
Enfin, la clause 6.1.3 ramène tout cela à la gouvernance. Un système de reporting centralisé qui établit une correspondance entre les contrôles cryptographiques et les décisions documentées en matière de gestion des risques offre aux auditeurs un lien clair et traçable entre un contrôle et le risque auquel il s'applique.
Se préparer à l'audit : ce que les auditeurs examinent
Lorsqu'un évaluateur atteint le niveau 8,24, il recherche des preuves, et non des intentions. Voici les domaines qu'il examine systématiquement :
- Une politique de cryptographie documentée qui s'applique à la fois aux systèmes internes et aux produits commercialisés, définissant les algorithmes approuvés, les longueurs minimales de clé et les conditions dans lesquelles le chiffrement est obligatoire.
- Preuves relatives au cycle de vie des clés : les registres, et non les procédures : registres de rotation attestant que l'intervalle prévu par la politique a été respecté, registres de destruction comportant une signature de validation, registres d'activité par clé, ainsi que les dates d'activation et de désactivation.
- Déclaration relative à la traçabilité de l'applicabilité qui justifie l'inclusion de la clause 8.24 et établit un lien avec l'évaluation des risques sous-jacente.
- Respect des obligations légales et juridictionnelles, y compris les contrôles à l'exportation et les considérations relatives à la localisation des données.
- Un inventaire à jour des certificats et des clés, indiquant les titulaires et les dates d'expiration, y compris les clés intégrées dans les versions d'software .
- Contrôles d'audit interne portant sur les 8,24 contrôles, dont les conclusions sont examinées par la direction dans le cadre du cycle du SMSI.
- Conformité de la configuration à la politique. Les évaluateurs comparent les algorithmes et les longueurs de clé autorisés par votre politique à ce qui est réellement déployé. Un écart entre la politique et la réalité constitue une non-conformité, même si la politique et la configuration sont chacune justifiables en soi.
Le point commun, c'est la propriété et la traçabilité. Chaque affirmation que vous avancez au sujet de la cryptographie doit s'appuyer sur un élément concret qu'un auditeur peut examiner.
Comment Keyfactor vous aider
La réunion du 24 août porte essentiellement sur la visibilité, les règles applicables et la gestion rigoureuse des clés à grande échelle. La plateforme de Keyfactorcorrespond parfaitement aux domaines de contrôle mentionnés ci-dessus.
- AgileSec établit l'inventaire des composants cryptographiques qui permet de garantir la fiabilité des fournisseurs et fournit des preuves sous forme de « Déclaration d'applicabilité » pour les composants intégrés ou tiers.
- EJBCA fournit l'PKI e nécessaire à la confidentialité et à l'intégrité des données garanties par des certificats, ainsi qu'une gestion centralisée du cycle de vie des clés, y compris celles intégrées aux appareils « software » livrés.
- Keyfactor Command assure le respect de la politique, offre une visibilité sur le cycle de vie des clés, gère l'inventaire des certificats et des clés, et génère des rapports de traçabilité conformes à la « Déclaration d'applicabilité ».
Une fois regroupées, ces fonctionnalités constituent un système unique de référence en matière de cryptographie, capable de fournir les preuves exactes exigées par un auditeur ISO 27001, sans que les équipes aient à les rassembler manuellement.
Conclusion et prochaines étapes
Le message qui se dégage de la version 8.24 est clair : le contrôle privilégie la propriété, la traçabilité et les preuves plutôt que les déclarations de principe. La certification dépend moins de la présence des mots justes dans un document que de la capacité à démontrer, sur simple demande, comment votre cryptographie est régie et comment vos clés sont gérées.
La prochaine étape concrète est simple. Évaluez votre politique actuelle en matière de cryptographie et votre inventaire de clés au regard de la section 8.24 avant votre prochain audit, et centralisez les justificatifs plutôt que de les répertorier dans des feuilles de calcul dispersées.
Prêt à découvrir comment la cryptographie automatisée et la gestion du cycle de vie des clés s'inscrivent dans le cadre de l'annexe A, paragraphe 8.24 ? Demander une démo.
Vous avez des questions sur la cryptographie dans le cadre de la norme ISO 27001 ? Nous avons les réponses.
Qu'est-ce que la section 8.24 de l'annexe A de la norme ISO/IEC 27001 ?
La section 8.24 de l'annexe A, intitulée « Utilisation de la cryptographie », est la mesure de contrôle de la norme ISO 27001:2022 qui régit la manière dont une organisation utilise la cryptographie. Elle exige une politique de cryptographie documentée et fondée sur les risques, ainsi qu'une gestion du cycle de vie des clés, vérifiées à l'aide de preuves opérationnelles plutôt que par de simples déclarations de politique générale. L’annexe A elle-même énonce cette mesure de contrôle en une seule phrase ; les exigences détaillées figurent dans la norme ISO/IEC 27002:2022, que les auditeurs utilisent comme référence.
Quels changements ont été apportés en matière de cryptographie lors de la révision de 2022 ?
La révision de 2022 a réorganisé l’annexe A en 93 contrôles répartis en quatre thèmes. Elle a regroupé les contrôles distincts relatifs à la cryptographie et à la gestion des clés de l’édition de 2013 en un seul contrôle, le 8.24.
La clause 8.24 couvre-t-elle la cryptographie intégrée aux produits que nous commercialisons ?
Oui. Pour les entreprises d'software s et de services informatiques, le champ d'application de la clause 8.24 inclut systématiquement la cryptographie intégrée au produit lui-même, et pas seulement à l'environnement informatique interne.
Que doit inclure une politique de cryptographie conforme ?
Il doit s’agir d’une politique spécifique à un domaine, définissant les algorithmes approuvés, les longueurs minimales de clé et les conditions dans lesquelles le chiffrement est obligatoire. Elle doit être liée à l’évaluation des risques du SMSI et s’appliquer aussi bien aux systèmes internes qu’aux produits commercialisés.
Quels éléments probants relatifs au cycle de vie attendent les auditeurs ?
Les auditeurs s'attendent à ce que soient mises en œuvre des procédures avérées concernant la génération, le stockage sécurisé, la rotation et la destruction des clés, et non pas seulement à ce qu'une politique écrite soit en place. Un inventaire à jour des certificats et des clés, indiquant les responsables désignés et les dates d'expiration, vient étayer ces éléments.
À quelle fréquence le point 8.24 fait-il l'objet d'un contrôle ?
La norme ISO 27001 étant une norme relative aux systèmes de management, le point 8.24 est contrôlé lors des audits de surveillance annuels et fait l'objet d'un contrôle complet lors de la recertification triennale.
Pourquoi la certification ISO 27001 revêt-elle une importance commerciale ?
La certification est devenue une condition préalable de facto sur le plan commercial pour les fournisseurs de services informatiques et d’ software . Les questionnaires de sécurité, les appels d’offres et les évaluations des risques liés aux fournisseurs exigent de plus en plus souvent une certification à jour ; ainsi, un certificat périmé peut constituer une menace directe pour le chiffre d’affaires.
Quel est le lien entre la clause 8.24 et la déclaration d’applicabilité ?
La déclaration d’applicabilité doit justifier l’inclusion de la clause 8.24 et l’établir en lien avec l’évaluation des risques sous-jacente. Un système de reporting centralisé qui met en correspondance les contrôles cryptographiques et les décisions documentées relatives au traitement des risques facilite l’examen par l’auditeur prévu à la clause 6.1.3.
