2 Le chiffrement est un pilier de la sécurité des données. Chiffrer les données au repos et en transit est indispensable pour toute organisation qui stocke des informations sensibles. Mais le chiffrement ne vaut que ce que vaut votre gestion des clés. Un algorithme peut être mathématiquement inviolable : si vos clés de chiffrement sont compromises, volées ou perdues, le chiffrement ne protège plus rien. Pour les architectes sécurité et les RSSI, la gestion des clés de chiffrement est l’une des disciplines opérationnelles les plus critiques, et l’une des plus souvent négligées. De nombreuses organisations mettent en place le chiffrement puis délaissent la gestion des clés, ce qui crée une fausse impression de sécurité. Les auditeurs découvrent des clés stockées en clair, jamais renouvelées, intégrées au code ou protégées par des systèmes constituant un point de défaillance unique. Partir d’un guide complet du chiffrement des données (en anglais) aide à établir des pratiques de base. Cet article explique à quoi ressemble une gestion des clés de niveau entreprise, comment l’architecturer et pourquoi une gestion défaillante peut compromettre même les mises en œuvre de chiffrement les plus robustes. Les trois problèmes fondamentaux que résout la gestion des clés Avant d’entrer dans les solutions techniques, il faut comprendre ce que l’on cherche à résoudre. La gestion des clés répond à trois problèmes fondamentaux : La confidentialité : votre clé de chiffrement doit être protégée contre toute divulgation. Si un attaquant la vole, il peut déchiffrer vos données. Les clés doivent être stockées et transmises de manière sécurisée, sans jamais être exposées à des tiers non autorisés. La disponibilité : votre clé doit être accessible lorsque vous en avez besoin. Si la clé principale est perdue ou devient inaccessible, vous risquez de ne plus pouvoir déchiffrer vos données. C’est rarement intentionnel, mais cela arrive : un disque contenant les clés tombe en panne, la personne détenant la clé de secours quitte l’entreprise, ou le certificat qui porte la clé expire sans que personne ne s’en aperçoive. L’auditabilité : vous devez savoir qui a accédé à vos clés, quand et dans quel but. Cela sert les enquêtes de conformité, les contrôles de sécurité de détection (repérer l’utilisation inattendue d’une clé) et la responsabilisation. Les cadres de gestion des clés répondent à ces trois problèmes en fournissant les systèmes nécessaires pour générer, stocker, protéger, renouveler et retirer les clés de chiffrement. Les types de clés et leur emplacement Les environnements de stockage d’entreprise utilisent plusieurs types de clés de chiffrement : Les clés de chiffrement des données (DEK) : elles chiffrent vos données proprement dites. Elles sont utilisées fréquemment (à chaque lecture ou écriture de données chiffrées) et doivent être accessibles avec une latence minimale. Les DEK résident souvent sur le système de stockage lui-même, protégées par des clés de chiffrement de clés (voir ci-dessous). Les clés de chiffrement de clés (KEK) : elles chiffrent les clés de chiffrement des données. Elles sont utilisées moins souvent (généralement à l’initialisation du stockage et lors des rotations) et doivent être stockées de manière plus sécurisée que les DEK. Les KEK résident souvent dans un module de sécurité matériel (HSM) ou un service de gestion des clés. Les clés racines : au sommet de la hiérarchie, une clé racine chiffre la clé de chiffrement de clés. Les clés racines sont rarement utilisées et doivent bénéficier du plus haut niveau de protection. Les clés à base de certificats : certains systèmes utilisent la cryptographie à clé publique, où le chiffrement se fait avec une clé publique et le déchiffrement exige une clé privée. La clé privée doit être protégée ; la clé publique peut être partagée librement. Savoir où réside chaque type de clé est essentiel pour comprendre votre architecture de gestion des clés. Les modèles d’architecture de gestion des clés Il existe plusieurs approches de gestion des clés, chacune avec ses compromis : Les clés gérées par le fournisseur : le fournisseur de stockage gère toutes les clés. Vous ne les voyez pas et ne les contrôlez pas directement. Le fournisseur applique ses propres contrôles : génération, stockage et rotation selon ses procédures. C’est simple pour les opérateurs, mais la visibilité et le contrôle sont minimes. En cas d’incident de sécurité chez le fournisseur, vos données sont compromises. Ce modèle convient aux données non sensibles ou aux organisations sans exigences de conformité strictes. Les clés gérées par le client (CMEK) : vous gérez les clés, mais le fournisseur de stockage les conserve et les utilise. Vous générez ou importez la clé, le fournisseur la stocke (généralement dans son HSM ou un stockage sécurisé) et l’utilise pour chiffrer et déchiffrer vos données. Vous avez de la visibilité sur les clés et pouvez les révoquer ou les renouveler, mais le fournisseur y a toujours accès. C’est le modèle le plus courant en entreprise, car il apporte du contrôle sans obliger à construire une infrastructure de gestion des clés. Bring Your Own Key (BYOK) : vous générez les clés dans votre propre environnement (HSM sur site ou KMS externe) et ne les transmettez au fournisseur de stockage qu’au moment nécessaire. Les clés ne sont jamais stockées durablement chez le fournisseur : après usage, elles peuvent être immédiatement supprimées ou effacées de sa mémoire. Le BYOK offre un contrôle maximal et un accès minimal du fournisseur, mais exige une infrastructure de gestion des clés sophistiquée et des tests d’intégration rigoureux. Ce modèle est utilisé par les organisations très réglementées (finance, secteur public, défense) et par celles soumises à des exigences strictes de résidence ou de souveraineté des données. Le chiffrement détenu par le client (chiffrement d’enveloppe) : vous chiffrez les données avec vos propres clés avant de les envoyer au fournisseur. Celui-ci stocke des données chiffrées sans jamais avoir accès à vos clés. Vous obtenez un contrôle maximal et ne dépendez plus de la gestion des clés du fournisseur. En revanche, l’exploitation se complique : le chiffrement et le déchiffrement se font côté client, et rechercher ou analyser les données chiffrées impose de les déchiffrer d’abord. Ce modèle est utilisé lorsqu’on ne peut pas confier de données sensibles au fournisseur. La plupart des grandes entreprises combinent ces approches : CMEK pour la majorité des données (équilibre entre contrôle et simplicité de gestion) et BYOK pour les données les plus sensibles (lorsque le contrôle et la souveraineté priment). Les modules de sécurité matériels : le point d’ancrage de la gestion des clés Un module de sécurité matériel (HSM) est une appliance matérielle conçue spécifiquement pour protéger les clés cryptographiques. Les HSM présentent plusieurs avantages par rapport au stockage logiciel des clés : La sécurité physique : les HSM sont des équipements matériels inviolables. Toute tentative d’extraction physique des clés déclenche une réponse anti-intrusion (généralement la destruction des clés). Ils protègent ainsi contre les attaques physiques. La sécurité opérationnelle : les clés ne quittent jamais le HSM, même en clair. Les opérations de chiffrement et de déchiffrement s’effectuent à l’intérieur du HSM. Votre serveur ne manipule jamais de clés non chiffrées, ce qui réduit la surface d’attaque. La validation de conformité : de nombreux cadres de conformité (FedRAMP, HIPAA, PCI-DSS) exigent explicitement une gestion des clés fondée sur des HSM pour les données sensibles. Les HSM sont la référence en matière de conformité. La gestion du cycle de vie des clés : les HSM prennent en charge la génération, la rotation, l’archivage et la suppression des clés. Ils appliquent les politiques définies (une clé ne peut être utilisée qu’une fois activée, ou ne peut être supprimée sans double approbation). En entreprise, les HSM constituent souvent le socle de la gestion des clés. Votre architecture comprend probablement un ou plusieurs HSM, qui conservent les clés et dont l’accès est contrôlé par des procédures rigoureuses. Les HSM dans le cloud : les grands fournisseurs cloud (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) proposent des services de HSM managés. Vous bénéficiez de la protection des clés par HSM sans gérer de matériel. C’est une option rentable pour les architectures de stockage cloud natives. Les HSM sur site : pour un contrôle maximal et une latence minimale (important si vous avez des besoins de chiffrement et de déchiffrement à haut débit), les HSM sur site fournissent un matériel dédié dans votre data center. Ils exigent un investissement initial et une expertise opérationnelle. La rotation des clés : la discipline opérationnelle la plus négligée La rotation des clés consiste à retirer une ancienne clé de chiffrement et à la remplacer par une nouvelle. Les données chiffrées avec l’ancienne clé le restent (elles ne sont pas automatiquement rechiffrées, sauf si vous le faites), mais les nouvelles données sont chiffrées avec la nouvelle clé. Pourquoi renouveler les clés ? Pour plusieurs raisons : Les exigences de conformité : la plupart des normes (NIST, ISO 27001, etc.) imposent une rotation des clés selon un calendrier défini, souvent annuel ou plus fréquent. Les cadres réglementaires partent du principe que les clés sont renouvelées régulièrement. La réduction du risque : si une clé est compromise, sa rotation limite l’exposition aux données chiffrées depuis sa création. Avec une rotation régulière, une clé compromise n’expose qu’une fenêtre de temps limitée. L’agilité cryptographique : la rotation permet de passer à des algorithmes plus robustes. À mesure que la puissance de calcul augmente et que des faiblesses cryptographiques apparaissent, vous pouvez adopter des algorithmes plus récents et plus solides sans rechiffrer immédiatement tout l’historique. La détection de problèmes opérationnels : les processus de rotation font souvent apparaître des problèmes : clés de secours qui ne fonctionnent pas, clés archivées introuvables ou contrôles d’accès qui bloquent des opérations autorisées. Mieux vaut les découvrir lors d’une rotation de routine qu’en pleine crise. Pourtant, de nombreuses organisations négligent la rotation des clés. Elles la configurent une fois sans jamais vérifier qu’elle a bien lieu. Les auditeurs découvrent des clés qui n’ont pas été renouvelées depuis des années, ce qui crée un risque important de non-conformité et de sécurité. Une rotation des clés efficace, c’est : Définir un calendrier de rotation : au minimum annuel, voire trimestriel ou mensuel pour les systèmes à haut risque. Documentez cette politique. Automatiser la rotation : la rotation des clés doit être automatisée autant que possible. Vous définissez le calendrier, le système renouvelle les clés automatiquement et les administrateurs vérifient la réussite de l’opération. Tester la rotation : régulièrement (au moins une fois par an), testez votre procédure de rotation. Vérifiez que la nouvelle clé fonctionne, que l’ancienne donne toujours accès aux données historiques et que la transition se fait sans heurt. Auditer la rotation : journalisez chaque rotation. Indiquez quelle clé a été retirée, quand, pourquoi et qui l’a autorisé. Conservez ces journaux pendant plusieurs années. Sauvegarde des clés et reprise après sinistre Les clés doivent être sauvegardées. Si la clé principale est perdue, vous ne pouvez plus déchiffrer les données qu’elle protège. Mais la sauvegarde des clés pose des défis de sécurité : la copie doit être protégée aussi soigneusement que l’original. Bonnes pratiques de sauvegarde des clés : Séparer les sauvegardes de la clé principale : une sauvegarde stockée au même endroit que la clé principale ne protège pas (si cet emplacement est compromis, les deux sont perdues). Les clés de secours doivent se trouver sur des sites géographiquement distincts ou sur des supports physiques séparés. Chiffrer les sauvegardes : les clés doivent être sauvegardées sous forme chiffrée, à l’aide d’une clé de chiffrement de sauvegarde distincte de la clé principale. Fractionner les sauvegardes et imposer un double contrôle : certaines organisations divisent les clés en plusieurs fragments (cryptographie à seuil). Une clé ne peut être reconstituée qu’avec plusieurs fragments détenus par différentes personnes, ce qui empêche une seule personne de la récupérer sans autorisation. Sécuriser les sauvegardes : les clés sauvegardées sur des supports physiques (comme des clés USB) doivent être conservées dans des locaux sécurisés (coffres, chambres fortes). Tout accès doit être journalisé et autorisé. Tester la restauration : testez régulièrement la récupération des clés. Vérifiez que vous pouvez récupérer une clé de secours et l’utiliser pour déchiffrer des données. Vous validez ainsi vos sauvegardes avant qu’une crise ne vous oblige à le faire. Le retrait et la destruction des clés Lorsqu’une clé arrive en fin de vie, elle doit être retirée et détruite de manière sécurisée, c’est-à-dire de façon à empêcher toute récupération. Une destruction sécurisée des clés comprend : L’effacement cryptographique : la clé est écrasée à plusieurs reprises (les normes du NIST et du DoD précisent les motifs à utiliser). Après effacement, toute récupération est cryptographiquement impossible. La destruction physique : pour les HSM ou les supports de sauvegarde contenant des clés, la destruction physique (incinération, broyage) garantit qu’aucune clé ne pourra être extraite. La piste d’audit : journalisez le retrait de la clé : quand, pourquoi, qui l’a autorisé et comment elle a été détruite. Conservez cet enregistrement. Les données concernées : avant de retirer une clé, assurez-vous qu’aucune donnée n’a encore besoin d’être déchiffrée avec elle (à moins d’accepter que ces données deviennent définitivement inaccessibles). Si des données sont toujours chiffrées avec cette clé, rechiffrez-les avec une nouvelle clé avant de retirer l’ancienne. Les erreurs courantes de gestion des clés Les organisations mettent souvent en place le chiffrement pour ensuite trébucher sur la gestion des clés : Des clés dans le code : des clés de chiffrement codées en dur dans le code source des applications. Lorsque les développeurs publient leur code dans des dépôts, les clés deviennent visibles par tous ceux qui y ont accès. Cela viole tous les principes de sécurité. Un point de défaillance unique : des clés stockées à un seul endroit avec une seule sauvegarde. Une compromission expose toutes les clés ; une sauvegarde défaillante les rend irrécupérables. Une rotation qui n’a jamais lieu : les clés sont configurées une fois et jamais renouvelées. Des clés vieilles de plusieurs décennies sont toujours utilisées et exposeraient des années de données en cas de compromission. L’absence de pistes d’audit : personne ne journalise l’accès aux clés ni leur utilisation. Impossible de détecter une utilisation abusive ou un accès non autorisé. Des clés perdues : les clés de secours sont introuvables, ou les procédures d’accès sont si restrictives que les utilisateurs autorisés ne peuvent pas récupérer les clés en cas de sinistre. La conformité de façade : des organisations mettent en place une gestion des clés pour réussir leurs audits, mais ne suivent pas les procédures entre deux audits. Les auditeurs voient une documentation soignée ; la réalité est tout autre. Bâtir votre programme de gestion des clés Commencez par un inventaire : quelles données sont chiffrées ? Quelles clés les protègent ? Où se trouvent ces clés ? Qui y a accès ? Comment sont-elles renouvelées ? Puis, si des lacunes apparaissent, priorisez : Commencez par les données à plus forte valeur et les plus réglementées (données personnelles, données de santé, données financières). Mettez d’abord en place pour elles une gestion des clés fondée sur des HSM. Établissez des procédures de rotation et testez-les. Associer la gestion des clés aux bonnes pratiques du chiffrement AES (en anglais) garantit que votre chiffrement est aussi solide que votre gestion des clés. Étendez ensuite méthodiquement la démarche aux autres données sensibles. Toutes les données n’exigent pas une protection de niveau HSM : les données moins sensibles peuvent s’appuyer dans un premier temps sur des clés gérées par le fournisseur, avant une montée en gamme. Évaluez aussi votre posture de sécurité globale au travers de cadres comme l’architecture zero trust (en anglais), afin d’aligner la gestion des clés sur vos principes de sécurité plus larges. Mettez en place une journalisation d’audit pour tous les accès aux clés et toutes leurs utilisations. Vous pourrez ainsi surveiller et enquêter en cas de problème. Testez régulièrement votre architecture : renouvelez les clés, restaurez les sauvegardes, vérifiez que tout fonctionne. Le chiffrement sans gestion des clés rigoureuse relève du théâtre sécuritaire. Pour les RSSI et les architectes sécurité, la gestion des clés doit être l’une des disciplines opérationnelles centrales. Elle n’a rien de spectaculaire, mais elle est le fondement de tout ce que vous protégez. Pour aller plus loin L’architecture zero trust (en anglais) Bonnes pratiques de sécurité zero trust (en anglais) Bonnes pratiques de gestion des identités et des accès (IAM) (en anglais) Le NIST Cybersecurity Framework (en anglais) L’authentification multifacteur (MFA) (en anglais) Qu’est-ce qu’un SIEM ? (en anglais)
