Politique Cryptographie ISO 27001 : Modèle Word [A.8.24 + ANSSI]

Liens entre la politique de cryptographie A.8.24 et les autres contrôles ISO 27001:2022

Le contrôle A.8.24 (Utilisation de la cryptographie) s'inscrit dans un ensemble cohérent de contrôles ISO 27001 qui se renforcent mutuellement et dont la mise en oeuvre doit être coordonnée par le responsable SMSI. Le contrôle A.8.10 (Suppression de l'information) nécessite que les données soient chiffrées avant destruction physique des supports ou que les clés de chiffrement soient détruites de façon irréversible pour rendre les données irrécupérables. Le contrôle A.8.11 (Masquage des données) peut utiliser des techniques cryptographiques comme la tokenisation ou le pseudonymat pour protéger les données sensibles dans les environnements de non-production. Le contrôle A.5.14 (Transfert d'information) impose l'utilisation de protocoles de transport chiffrés (TLS 1.2+ minimum, TLS 1.3 recommandé) pour tous les transferts de données sensibles entre systèmes ou vers des parties externes à l'organisation.

La politique de cryptographie doit également s'articuler avec la gestion des risques (clause 6.1.2) : les exigences de chiffrement doivent être directement liées aux risques identifiés sur les actifs informationnels lors de l'analyse de risques. Un actif classifié "hautement confidentiel" exposé à un risque d'interception réseau documenté doit être protégé par un chiffrement en transit et au repos. La politique de cryptographie est ainsi un document vivant qui évolue avec les résultats des évaluations de risques périodiques du SMSI et avec les recommandations publiées par les autorités compétentes comme l'ANSSI sur les algorithmes cryptographiques recommandés pour les systèmes gouvernementaux et industriels en France.

Erreurs courantes lors de l'audit du contrôle A.8.24 ISO 27001

Plusieurs erreurs récurrentes sont observées lors des audits de certification sur le contrôle A.8.24. La première est l'utilisation d'algorithmes cryptographiques obsolètes ou insuffisants dans les systèmes de production : MD5 et SHA-1 pour les signatures numériques et les fonctions de hachage, DES ou 3DES pour le chiffrement symétrique, RSA-1024 pour les clés asymétriques — autant d'algorithmes considérés comme insuffisants par les standards cryptographiques actuels (NIST SP 800-131A, recommandations ANSSI). Un inventaire des algorithmes effectivement utilisés dans les systèmes d'information de l'organisation, comparé à la liste des algorithmes recommandés dans la politique de cryptographie approuvée par la direction, révèle souvent des écarts significatifs à corriger pour maintenir la conformité au contrôle A.8.24.

La deuxième erreur est l'absence de processus formalisé de gestion du cycle de vie des clés cryptographiques : génération sécurisée via un générateur de nombres aléatoires cryptographiquement sûr, stockage sécurisé dans un HSM ou un coffre de secrets comme HashiCorp Vault ou AWS KMS, rotation périodique des clés selon des intervalles définis dans la politique, et révocation immédiate en cas de compromission suspectée ou avérée. Sans ce processus formalisé et effectivement opérationnel, la politique de cryptographie reste théorique et ne résiste pas à l'examen approfondi de l'auditeur de certification ISO 27001.

La politique de cryptographie est le document de référence qui définit l'utilisation des techniques cryptographiques au sein du Système de Management de la Sécurité de l'Information (SMSI). Le contrôle A.8.24 d'ISO/IEC 27001:2022 impose d'établir et de mettre en œuvre une politique formalisée sur l'utilisation de la cryptographie pour protéger la confidentialité, l'authenticité et l'intégrité des informations. Cette politique doit couvrir les algorithmes autorisés et prohibés, les longueurs de clés minimales, les protocoles cryptographiques approuvés, et la gestion du cycle de vie des clés cryptographiques (génération, distribution, stockage, rotation, révocation, destruction). Ce modèle Word, développé par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001, s'aligne sur les recommandations de l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) publiées dans ses guides de référence (RGS — Référentiel Général de Sécurité, et guide "Cryptographie" de 2021). Les algorithmes recommandés incluent AES-256-GCM pour le chiffrement symétrique, ChaCha20-Poly1305 comme alternative, RSA-3072 et ECDSA P-256 pour la cryptographie asymétrique, SHA-256 et SHA-3 pour le hachage, et TLS 1.3 pour les communications. La politique cryptographique s'articule étroitement avec la politique de gestion des accès logiques, la politique de classification de l'information (le niveau de chiffrement requis dépend de la classification), et les contrôles de sécurité réseau (A.8.20-23). À l'ère de l'informatique quantique en développement, une politique cryptographique à jour doit également anticiper la migration vers la cryptographie post-quantique, un enjeu que l'ANSSI et le NIST adressent activement avec la standardisation de nouveaux algorithmes (CRYSTALS-Kyber, CRYSTALS-Dilithium).

Contexte réglementaire et normatif

ISO/IEC 27001:2022 — Contrôle A.8.24 : Utilisation de la cryptographie

Le contrôle A.8.24 est classé dans le thème "Technologiques" de l'Annexe A 2022. Il impose d'établir et mettre en œuvre une politique sur l'utilisation de la cryptographie, incluant la gestion sécurisée des clés cryptographiques. La politique doit tenir compte des exigences légales, réglementaires et contractuelles liées à la cryptographie (certains pays imposent des restrictions sur l'exportation d'algorithmes cryptographiques ou exigent un escrow de clés). Le contrôle A.8.24 s'applique à toutes les formes de cryptographie utilisées dans le SMSI : chiffrement des données au repos, chiffrement des communications, signatures électroniques, hachage, et authentification par certificats.

Référentiel Général de Sécurité (RGS) — ANSSI

Le RGS est le cadre de référence français pour la sécurité des systèmes d'information des administrations et des opérateurs d'importance vitale. Sa composante cryptographique définit les algorithmes autorisés pour les usages officiels en France. Bien que le RGS soit formellement obligatoire pour les administrations, ses recommandations sont la référence de l'état de l'art pour toute organisation souhaitant mettre en œuvre une politique cryptographique robuste. Le Guide de la cryptographie de l'ANSSI (version 2021) est la ressource technique de référence pour choisir des algorithmes adaptés selon l'usage.

RGPD — Article 32 : Sécurité du traitement

L'article 32 du RGPD impose de mettre en œuvre des mesures techniques et organisationnelles appropriées pour assurer un niveau de sécurité adapté au risque, incluant explicitement "le chiffrement des données à caractère personnel". Bien que le RGPD ne prescrive pas d'algorithmes spécifiques, le chiffrement des données personnelles est l'une des mesures les plus efficaces pour réduire le risque en cas de violation de données. Une politique cryptographique conforme aux recommandations ANSSI répond également aux exigences de l'article 32 du RGPD.

Structure détaillée de la politique de cryptographie

Section 1 — Objet, périmètre et référentiels

Objectif de la politique, périmètre d'application (tous les systèmes dans le scope SMSI qui utilisent des mécanismes cryptographiques), référentiels utilisés (ISO 27001:2022 A.8.24, ANSSI RGS, RGPD Art.32, ETSI, NIST), propriétaire de la politique, et processus de révision (minimum annuel).

Section 2 — Algorithmes autorisés et prohibés

Tableau listant les algorithmes cryptographiques autorisés par usage (chiffrement symétrique, chiffrement asymétrique, signature numérique, hachage, échange de clés, protocoles TLS/SSH) et les algorithmes explicitement prohibés (DES, 3DES, RC4, MD5, SHA-1, RSA < 2048 bits, TLS 1.0/1.1). Cette section doit être revue annuellement pour intégrer les évolutions des recommandations ANSSI et les nouvelles vulnérabilités découvertes.

Section 3 — Gestion du cycle de vie des clés cryptographiques

Procédures pour chaque phase du cycle de vie des clés : génération (sources d'entropie, modules HSM recommandés), distribution (canaux sécurisés, ceremonies de remise de clés), stockage (HSM matériel, KMS cloud sécurisé, coffre-fort de clés), rotation (fréquence par type de clé), révocation (procédure d'urgence en cas de compromission), et destruction (méthode de suppression sécurisée, journalisation). La gestion des clés est souvent le maillon faible de la cryptographie en pratique — une clé robuste stockée dans un fichier texte non protégé n'offre aucune sécurité réelle.

Section 4 — Certificats numériques

Politique de gestion des certificats numériques : autorités de certification (CA) autorisées, durée de vie maximale des certificats (recommandation : 1 an pour les certificats TLS depuis 2023), processus de renouvellement, gestion des révocations (CRL/OCSP), et inventaire des certificats. La gestion des certificats est souvent négligée jusqu'à ce qu'une panne survienne lors de l'expiration d'un certificat en production.

Section 5 — Chiffrement des données au repos

Exigences de chiffrement selon la classification des données : données "Secret" et "Confidentiel" — chiffrement obligatoire pour tous les supports (serveurs, postes, laptops, supports amovibles, cloud), données "Usage Interne" — chiffrement recommandé pour les laptops et supports amovibles, données "Public" — chiffrement non requis. Algorithme minimum requis : AES-256 pour le chiffrement symétrique des données au repos.

Section 6 — Chiffrement des communications

Exigences de chiffrement des communications pour chaque type de flux : HTTPS (TLS 1.3 minimum, TLS 1.2 avec suites de chiffrement robustes toléré), messagerie électronique (TLS pour le transport, S/MIME ou PGP pour les communications sensibles), VPN (IKEv2 avec AES-256-GCM, Perfect Forward Secrecy obligatoire), SSH (SSH 2.0 avec clés Ed25519 ou ECDSA P-256, authentification par clé obligatoire pour les accès administrateurs).

Tableau des algorithmes cryptographiques recommandés (ANSSI 2024)

Guide d'utilisation étape par étape

1. Inventorier tous les usages cryptographiques actuels : avant de rédiger la politique, dressez l'inventaire de tous les mécanismes cryptographiques en place (chiffrement disque, HTTPS, VPN, SSH, messagerie chiffrée, stockage des mots de passe, certificats). Cet inventaire révèle souvent des algorithmes obsolètes ou des pratiques non conformes.
2. Identifier les algorithmes non conformes : comparez l'inventaire avec les recommandations ANSSI. Les découvertes typiques : MD5 encore utilisé pour des checksums "de sécurité", SHA-1 dans des certificats, TLS 1.0/1.1 sur des serveurs legacy, RSA-2048 sur des systèmes qui devraient migrer vers 3072, DES/3DES dans des systèmes mainframe ou industriels.
3. Planifier la migration des algorithmes non conformes : pour chaque algorithme non conforme identifié, planifiez la migration vers un algorithme conforme. Certaines migrations sont simples (reconfiguration TLS), d'autres complexes (migration des systèmes SCADA qui ne supportent pas les algorithmes modernes). Priorisez selon l'exposition et le niveau de risque.
4. Mettre en place une gestion formalisée des clés : la gestion des clés est le point le plus souvent défaillant. Mettez en place a minima : un inventaire des clés (quelles clés existent, pour quel usage, quelle durée de vie), une procédure de rotation (fréquence définie par type de clé), et un stockage sécurisé (HSM matériel ou KMS cloud pour les clés critiques).
5. Gérer les certificats numériques proactivement : mettez en place une supervision des dates d'expiration des certificats (alertes 60, 30, et 7 jours avant expiration). Un certificat expiré peut provoquer une indisponibilité de service majeure. Les outils comme Certbot (Let's Encrypt), Vault (HashiCorp), ou les fonctions KMS des cloud providers facilitent la gestion automatisée des certificats.
6. Former les équipes IT aux bonnes pratiques cryptographiques : les développeurs doivent connaître les API cryptographiques sécurisées de leurs langages (libsodium, Java Cryptography Architecture, .NET cryptography), éviter les implémentations "maison" de cryptographie, et utiliser TLS plutôt que d'implémenter leur propre chiffrement. Les administrateurs système doivent savoir configurer TLS correctement sur les serveurs web, proxy, et VPN.
7. Anticiper la cryptographie post-quantique : les ordinateurs quantiques capables de casser RSA et ECC (via l'algorithme de Shor) sont encore dans le futur, mais les données chiffrées aujourd'hui pourraient être déchiffrées rétroactivement ("harvest now, decrypt later"). Le NIST a standardisé en 2024 les premiers algorithmes post-quantiques (CRYSTALS-Kyber pour l'échange de clés, CRYSTALS-Dilithium pour les signatures). Commencez à évaluer votre exposition et planifiez la migration pour les données à haute sensibilité à long terme.

Points de vigilance pour l'audit de certification

1. Politique cryptographique non mise à jour : une politique de cryptographie qui référence encore SHA-1 ou TLS 1.0 comme "recommandés" est une NC. Remédiation : révisez annuellement la politique en consultant les dernières recommandations ANSSI et les CVE publiées sur les bibliothèques cryptographiques.
2. Absence de gestion formalisée des clés : des clés cryptographiques sans inventaire, sans rotation, et stockées dans des fichiers de configuration non protégés est une faiblesse grave. Remédiation : mettez en place a minima un inventaire des clés critiques et une procédure de rotation, même simplifiée.
3. Certificats expirés en production : l'auditeur peut demander à vérifier les certificats TLS de vos serveurs accessibles. Un certificat expiré, ou utilisant SHA-1 ou RSA-2048, sera signalé. Remédiation : auditez trimestriellement l'état des certificats via des outils comme SSL Labs ou Qualys SSL Test.
4. Mots de passe stockés en clair ou hachés avec MD5 : si vos bases de données stockent des mots de passe avec des algorithmes non conformes (MD5, SHA-1 non salé), c'est une NC technique grave. Remédiation : migrez vers bcrypt, Argon2id, ou PBKDF2 avec un facteur de coût adapté.

Questions fréquentes

Faut-il chiffrer toutes les données en transit, même les données publiques ?

Le chiffrement de toutes les communications en transit est une bonne pratique recommandée, même pour les données publiques. Le modèle "HTTPS partout" (HSTS — HTTP Strict Transport Security) est désormais la norme du web : les navigateurs modernes affichent des avertissements pour les sites HTTP, et les moteurs de recherche pénalisent le contenu non chiffré. Les raisons de chiffrer même les données "publiques" en transit : prévenir les attaques man-in-the-middle qui pourraient injecter du contenu malveillant, protéger les métadonnées de navigation (quelles pages consulte l'utilisateur), et maintenir l'intégrité des données (garantir que le contenu reçu n'a pas été modifié en transit). Pour les communications internes entre serveurs dans un datacenter, la décision est plus nuancée : un micro-périmètre de confiance interne peut justifier l'absence de chiffrement sur certains flux internes, mais cette décision doit être documentée dans la politique et justifiée par une analyse de risques.

Comment gérer la cryptographie pour les systèmes industriels (ICS/SCADA/OT) ?

Les systèmes industriels (ICS/SCADA/OT) représentent un défi particulier pour la politique cryptographique : ils sont souvent anciens, difficiles à mettre à jour, et peuvent ne pas supporter les algorithmes cryptographiques modernes. Plusieurs approches existent. L'encapsulation réseau sécurisée : les équipements OT qui ne peuvent pas être mis à jour sont placés dans un réseau segmenté, et les communications sont chiffrées au niveau des passerelles (VPN industriel, diodes de données). L'inventaire des exceptions : les équipements OT qui ne supportent pas les algorithmes conformes font l'objet d'une dérogation documentée dans la politique, avec une justification de risque accepté par la direction. L'isolation : les équipements OT non chiffrables sont isolés du réseau IT par une architecture de type DMZ industrielle avec contrôles d'accès stricts. Dans la politique de cryptographie, créez une section dédiée aux "exceptions OT" qui documente les systèmes concernés, les raisons de non-conformité, et les mesures compensatoires en place.

Quelle est la durée de vie recommandée pour les clés cryptographiques ?

La durée de vie recommandée varie selon le type de clé et son usage. Pour les clés symétriques (AES) : clés de session TLS — durée de session (Perfect Forward Secrecy renouvelle les clés à chaque session), clés de chiffrement de données au repos — rotation annuelle recommandée, clés de chiffrement de clés (KEK) — rotation tous les 2-3 ans avec procédure de re-chiffrement. Pour les clés asymétriques (RSA/ECDSA) : clés de certificats TLS/HTTPS — 1 an maximum (recommandation CA/Browser Forum depuis 2023), clés de signature de code — 2-3 ans, clés d'infrastructure (CA racines, CA intermédiaires) — 5-10 ans avec procédures de cérémonie de clé. Pour les clés SSH : rotation annuelle pour les clés d'authentification, révocation immédiate lors du départ d'un administrateur. Ces durées sont des recommandations générales — adaptez-les selon la sensibilité des données protégées et les contraintes opérationnelles. Documentez explicitement les durées de vie dans votre politique et planifiez les rotations dans votre calendrier opérationnel.

Comment aborder la cryptographie post-quantique dans la politique ?

La cryptographie post-quantique (PQC) est un sujet urgent pour les données à haute sensibilité à long terme, mais pas encore une exigence ISO 27001 actuelle. Voici comment l'aborder dans votre politique de cryptographie. Premièrement, incluez une section "Veille technologique et cryptographie post-quantique" qui reconnaît la menace des ordinateurs quantiques pour RSA et ECC à long terme et référence les standards NIST PQC finalisés en 2024 (FIPS 203 CRYSTALS-Kyber, FIPS 204 CRYSTALS-Dilithium, FIPS 205 SPHINCS+). Deuxièmement, identifiez dans votre politique les données dont la confidentialité à long terme est critique (secrets d'État, secrets industriels majeurs, données personnelles sensibles à durée de conservation > 10 ans) — ce sont elles qui nécessitent une migration PQC prioritaire. Troisièmement, incluez un engagement de suivi des recommandations ANSSI et NIST sur la PQC et de mise à jour de la politique au fur et à mesure de l'évolution des standards. Cette approche montre aux auditeurs de certification une maturité dans la gestion prospective de la cryptographie.

Pour aller plus loin

• Politique de gestion des accès logiques ISO 27001 (A.5.15-18)
• Politique de classification de l'information ISO 27001 (A.5.12-14)
• Politique de mots de passe ISO 27001 — Modèle conforme ANSSI
• Gap Analysis ISO 27001:2022 — 93 contrôles [outil Excel]
• Notre service d'accompagnement ISO 27001 complet