Comment le chiffrement AES-256 contribue à la conformité CMMC

Les sous-traitants de la défense qui visent la certification Cybersecurity Maturity Model Certification (CMMC) 2.0 doivent répondre à une exigence fondamentale : protéger les informations non classifiées contrôlées (CUI) grâce à un chiffrement conforme aux normes cryptographiques fédérales. Le chiffrement AES-256 répond à cette exigence lorsqu’il est mis en œuvre via des modules cryptographiques validés FIPS, mais l’algorithme de chiffrement seul ne garantit pas la conformité. Les évaluateurs CMMC examinent non seulement la présence du chiffrement, mais aussi sa bonne implémentation, sa validation appropriée et la solidité de la gestion des clés.

La plupart des organisations du secteur industriel de la défense (DIB) viseront la certification CMMC Niveau 2, qui intègre les 110 contrôles de sécurité du NIST SP 800-171. Plusieurs de ces contrôles exigent explicitement une protection cryptographique de la CUI au repos et en transit. Comprendre comment le chiffrement AES-256 répond à ces exigences spécifiques — et où les écarts d’implémentation apparaissent le plus souvent — est fondamental pour obtenir et maintenir la certification.

Ce guide analyse les exigences de chiffrement du CMMC Niveau 2, explique pourquoi l’AES-256 répond aux normes fédérales lorsqu’il est correctement mis en œuvre, et aborde la question cruciale de la gestion des clés de chiffrement lorsque la CUI est stockée sur une infrastructure cloud.

Résumé des points clés

1. Le CMMC Niveau 2 exige un chiffrement validé FIPS pour protéger la CUI au repos et en transit, avec des exigences précises définies dans les contrôles NIST SP 800-171 SC.L2-3.13.8 et SC.L2-3.13.16.
2. Les sous-traitants de la défense doivent utiliser des modules cryptographiques validés FIPS, et non simplement des algorithmes approuvés FIPS — la validation FIPS 140-3 constitue la norme actuelle et démontre une conformité tournée vers l’avenir.
3. Le chiffrement AES-256 répond aux exigences cryptographiques du CMMC lorsqu’il est mis en œuvre dans un module validé et appliqué de manière cohérente sur tous les systèmes et canaux de communication où la CUI est présente.
4. Lorsque la CUI est stockée sur une infrastructure cloud certifiée FedRAMP, la propriété des clés de chiffrement a un impact direct sur la conformité CMMC — des clés détenues par le client (vous seul avez accès aux clés) offrent des frontières de contrôle claires, contrairement aux clés gérées par le client (le fournisseur cloud conserve un accès).
5. Les pratiques de gestion des clés de chiffrement sont scrutées lors des évaluations CMMC, notamment la documentation des procédures de génération, stockage, rotation et destruction des clés dans le Plan de sécurité du système.

Exigences de chiffrement CMMC selon le niveau de certification

Le CMMC 2.0 définit trois niveaux de certification, chacun comportant des exigences distinctes selon la sensibilité des informations à protéger. Le Niveau 2 s’applique aux organisations qui traitent de la CUI et représente le niveau de certification que la majorité des sous-traitants du DIB viseront.

Le CMMC Niveau 1 s’adresse aux organisations qui ne manipulent que des informations contractuelles fédérales (FCI) et comprend 17 pratiques de protection de base. Ces contrôles fondamentaux n’incluent pas d’exigence explicite de chiffrement, même si le chiffrement reste recommandé pour toute donnée sensible.

Le CMMC Niveau 2 intègre les 110 contrôles du NIST SP 800-171 Révision 2, y compris des exigences spécifiques de protection cryptographique. La famille de contrôles Systèmes et protection des communications (SC) contient les principales obligations de chiffrement. Le contrôle SC.L2-3.13.8 exige des mécanismes cryptographiques pour protéger la CUI lors de la transmission, tandis que SC.L2-3.13.16 impose la protection de la CUI au repos. Ces contrôles ne mentionnent pas explicitement l’AES-256, mais exigent un chiffrement mis en œuvre via des modules cryptographiques validés FIPS.

Le CMMC Niveau 3 s’adresse aux organisations qui traitent la CUI la plus sensible et ajoute des contrôles du NIST SP 800-172. Ces exigences renforcées peuvent inclure des procédures de gestion des clés plus strictes, des évaluations cryptographiques plus fréquentes et des protections supplémentaires contre les menaces persistantes avancées. Les organisations visant le Niveau 3 doivent s’attendre à une analyse approfondie de leur architecture de chiffrement et de leurs pratiques de gestion des clés.

Pourquoi l’AES-256 répond aux normes du CMMC Niveau 2

L’Advanced Encryption Standard avec des clés de 256 bits (AES-256) est approuvé par le National Institute of Standards and Technology (NIST) pour la protection des informations fédérales classifiées et non classifiées. Cette approbation fait de l’AES-256 le choix adapté pour la conformité CMMC, mais une distinction essentielle détermine si votre implémentation satisfait réellement aux exigences d’évaluation.

Les évaluateurs CMMC vérifient que le chiffrement est mis en œuvre via des modules cryptographiques validés FIPS, et pas seulement qu’un algorithme approuvé FIPS est utilisé. Une organisation pourrait utiliser le chiffrement AES-256 via des bibliothèques logicielles non validées et échouer à l’évaluation CMMC malgré l’utilisation du bon algorithme. Le module cryptographique lui-même — qu’il s’agisse de logiciel, de firmware ou de matériel — doit disposer d’un certificat FIPS 140 valide.

Le gouvernement fédéral passe de la norme FIPS 140-2 à FIPS 140-3 pour la validation des modules cryptographiques. Les certificats FIPS 140-2 restent valides jusqu’à leur date d’expiration, mais les nouvelles validations sont délivrées selon FIPS 140-3. Les organisations qui choisissent des solutions de chiffrement doivent privilégier les produits validés FIPS 140-3, qui démontrent leur conformité aux exigences cryptographiques fédérales actuelles et évitent le risque de dépendre de certificats FIPS 140-2 arrivant à expiration pendant la durée d’un contrat.

La longueur de clé de 256 bits offre une marge de sécurité adaptée à la protection de la CUI. Bien que l’AES-128 soit également approuvé par le NIST, l’AES-256 offre une meilleure résistance face aux avancées futures en cryptanalyse et s’aligne sur les préférences du DoD pour la protection des informations sensibles de défense.

Chiffrer la CUI au repos pour la conformité CMMC

Le contrôle NIST SP 800-171 SC.L2-3.13.16 exige que les organisations protègent la confidentialité de la CUI au repos. Cette exigence s’applique à tous les emplacements où la CUI est stockée : serveurs de fichiers, bases de données, terminaux, systèmes de sauvegarde, archives e-mail et stockage cloud.

Les sous-traitants de la défense doivent identifier tous les emplacements où la CUI est présente et s’assurer qu’un chiffrement protège chaque dépôt. Les scénarios de stockage courants nécessitant un chiffrement incluent les plans d’ingénierie et spécifications techniques sur des partages de fichiers, les documents contractuels et la correspondance dans les systèmes de gestion documentaire, les archives e-mail contenant de la CUI échangée avec des agences gouvernementales ou des sous-traitants, les enregistrements de bases de données avec des informations techniques contrôlées, les bandes de sauvegarde et systèmes de reprise après sinistre, ainsi que les terminaux comme les ordinateurs portables utilisés par les employés ayant accès à la CUI.

Le chiffrement au repos peut être mis en œuvre à plusieurs niveaux. Le chiffrement de disque complet protège l’ensemble des volumes de stockage, tandis que le chiffrement au niveau fichier protège chaque fichier, quel que soit son emplacement ou ses déplacements. Le chiffrement de base de données protège les données structurées dans les systèmes de gestion de bases de données. De nombreuses organisations optent pour un chiffrement en couches, combinant une protection au niveau volume et au niveau fichier pour une défense en profondeur.

L’implémentation du chiffrement doit utiliser un module validé FIPS. Les disques autochiffrés, les fonctionnalités de chiffrement des systèmes d’exploitation et les solutions tierces nécessitent tous une validation FIPS 140 pour répondre aux exigences du CMMC. Les organisations doivent conserver la documentation des numéros de certificats FIPS pour chaque produit de chiffrement déployé dans leur environnement.

Chiffrer la CUI en transit pour la conformité CMMC

Le contrôle NIST SP 800-171 SC.L2-3.13.8 exige des mécanismes cryptographiques pour empêcher la divulgation non autorisée de la CUI lors de la transmission. Cette exigence concerne tous les canaux de communication utilisés pour transmettre de la CUI : connexions réseau, e-mails, transferts de fichiers et communications API.

Le protocole Transport Layer Security (TLS) constitue la base de la plupart des chiffrages en transmission. TLS 1.2 et TLS 1.3 prennent en charge des suites de chiffrement utilisant l’AES-256 pour le chiffrement de masse, répondant ainsi aux exigences de robustesse pour la protection de la CUI. Les organisations doivent configurer leurs systèmes pour exiger TLS 1.2 ou supérieur et désactiver les versions antérieures présentant des vulnérabilités connues. TLS 1.3 offre une sécurité et des performances accrues par rapport à TLS 1.2 et représente la meilleure pratique actuelle pour la protection de la CUI en transit.

L’e-mail représente un défi particulier pour les sous-traitants de la défense. La transmission standard des e-mails ne chiffre pas le contenu de bout en bout, exposant la CUI lors du passage par les serveurs de messagerie. Les solutions de messagerie sécurisée qui appliquent le chiffrement AES-256 au contenu des messages — et non uniquement au canal de transmission — apportent la protection requise par le CMMC pour les e-mails contenant de la CUI.

Les opérations de transfert de fichiers requièrent la même vigilance. Les protocoles SFTP et FTPS offrent une transmission chiffrée, mais les organisations doivent vérifier que leurs implémentations utilisent des modules cryptographiques validés FIPS. Les transferts de gros fichiers entre sous-traitants, sous-traitants secondaires et agences gouvernementales contiennent fréquemment de la CUI et nécessitent une protection constante par chiffrement.

Les communications API entre systèmes sont également concernées par les exigences de chiffrement en transmission. Les organisations qui s’intègrent à des systèmes gouvernementaux ou échangent de la CUI via des interfaces automatisées doivent s’assurer que ces connexions utilisent des canaux correctement chiffrés.

Gestion des clés de chiffrement sur une infrastructure certifiée FedRAMP

De nombreux sous-traitants de la défense utilisent des services cloud certifiés FedRAMP pour stocker et traiter la CUI. Si la certification FedRAMP confirme que le fournisseur cloud répond aux exigences fédérales de sécurité, elle ne garantit pas automatiquement la conformité CMMC du sous-traitant. Ce dernier reste responsable de sa propre conformité, notamment en prouvant qu’il contrôle correctement l’accès à la CUI.

La gestion des clés de chiffrement détermine qui peut réellement accéder à la CUI chiffrée, quel que soit son emplacement. Trois modèles de gestion des clés existent pour les données hébergées dans le cloud, chacun ayant des implications différentes pour la conformité CMMC.

Les clés gérées par le fournisseur représentent la solution la plus simple : le fournisseur cloud génère, stocke et contrôle les clés de chiffrement. Bien que les données soient chiffrées, le fournisseur conserve la capacité technique de les déchiffrer. Ce modèle soulève d’importantes questions lors de l’évaluation CMMC quant au contrôle réel du sous-traitant sur l’accès à la CUI.

Les clés gérées par le client (souvent appelées BYOK, Bring Your Own Key) donnent au sous-traitant le contrôle sur la génération et le cycle de vie des clés, mais celles-ci sont téléchargées et stockées dans le service de gestion de clés du fournisseur cloud. Le fournisseur conserve un accès technique à ces clés et peut être contraint de déchiffrer les données en vertu du CLOUD Act ou d’autres procédures légales — souvent sans en informer le client. Pour le CMMC, ce modèle crée une ambiguïté sur le contrôle réel de l’accès à la CUI.

Les clés détenues par le client (HYOK, Hold Your Own Key) offrent une séparation réelle. Le sous-traitant conserve les clés de chiffrement exclusivement dans son propre système de gestion de clés ou module matériel de sécurité (HSM), et le fournisseur cloud n’a jamais accès aux clés. Même si le fournisseur reçoit une injonction gouvernementale, il ne peut pas déchiffrer la CUI car il ne détient pas les clés. Ce modèle établit des frontières de contrôle claires qui satisfont les exigences des évaluateurs CMMC.

Le statut FedRAMP concerne la posture de sécurité du fournisseur cloud, mais ne détermine pas l’approche de gestion des clés du sous-traitant. Les évaluateurs CMMC examineront la manière dont le sous-traitant contrôle l’accès à la CUI. Les clés de chiffrement détenues par le client — où le sous-traitant est le seul à pouvoir déchiffrer la CUI — constituent la preuve définitive de ce contrôle. Les clés gérées par le client, malgré leur nom rassurant, laissent un accès technique au fournisseur cloud qui complique la démonstration de conformité.

Déficiences courantes de chiffrement CMMC

Les évaluations CMMC identifient fréquemment des lacunes liées au chiffrement qui empêchent la certification. Comprendre ces écarts aide les organisations à mieux se préparer.

L’utilisation de modules de chiffrement non validés reste une constatation fréquente. Les organisations peuvent mettre en œuvre l’AES-256 via des bibliothèques ou produits sans validation FIPS 140, ne répondant pas à l’exigence de module validé même si l’algorithme est correct.

Une couverture de chiffrement incomplète crée des failles lorsque la CUI n’est pas chiffrée partout où elle est présente. Les systèmes de messagerie, plateformes collaboratives et terminaux manquent souvent de chiffrement même si le stockage principal est protégé.

Une documentation insuffisante dans le Plan de sécurité du système (SSP) entraîne des remarques lors de l’évaluation, même si les contrôles techniques sont bien mis en œuvre. Le SSP doit documenter les méthodes de chiffrement, les numéros de certificats FIPS, les procédures de gestion des clés et les systèmes couverts par les contrôles de chiffrement.

Se reposer sur le chiffrement du fournisseur cloud sans comprendre les implications de la gestion des clés peut créer une ambiguïté sur le contrôle d’accès à la CUI. Les évaluateurs examineront qui, du sous-traitant ou du fournisseur cloud, contrôle effectivement l’accès à la CUI chiffrée.

Des certificats de validation FIPS obsolètes présentent un risque de non-conformité si les certificats expirent pendant la durée d’un contrat. Les organisations doivent suivre les dates d’expiration des certificats pour tous les produits de chiffrement utilisés.

Des failles de chiffrement lors des mouvements de données apparaissent lorsque la CUI est protégée au repos et lors des transmissions externes, mais circule sans chiffrement entre systèmes internes. Les évaluateurs examinent l’ensemble du flux de données, pas seulement le stockage et les communications externes.

Protégez la CUI avec les fonctions de chiffrement robustes de Kiteworks

La certification CMMC Niveau 2 exige que les sous-traitants de la défense prouvent que la CUI est protégée par un chiffrement validé FIPS au repos et en transit, soutenu par des pratiques documentées de gestion des clés. Le chiffrement AES-256 répond aux exigences cryptographiques lorsqu’il est mis en œuvre via des modules validés et appliqué de façon cohérente sur tous les systèmes traitant la CUI.

Le choix du modèle de propriété des clés impacte fortement la conformité CMMC, en particulier lorsque la CUI est stockée sur une infrastructure cloud. Les clés de chiffrement détenues par le client — vous seul possédez les clés et même votre fournisseur cloud ne peut y accéder — établissent des frontières de contrôle claires qui satisfont les exigences des évaluateurs et éliminent toute ambiguïté sur l’accès à la CUI.

Kiteworks répond à près de 90 % des exigences du CMMC Niveau 2 dès l’installation. Cela inclut le chiffrement validé FIPS 140-3 — la norme fédérale actuelle, et non l’ancienne FIPS 140-2 — pour la protection de la CUI au repos et en transit. La plateforme, un Réseau de données privé, sécurise les données en mouvement avec le chiffrement TLS 1.3, le protocole de couche de transport le plus robuste, sur la messagerie électronique, le partage et le transfert de fichiers, ainsi que les formulaires web.

Pour les communications e-mail contenant de la CUI, la passerelle de protection e-mail de Kiteworks applique automatiquement le chiffrement AES-256 aux messages sortants, supprimant la dépendance à l’utilisateur final pour le choix du chiffrement et garantissant une protection constante sur l’ensemble de la supply chain de défense.

Kiteworks propose une architecture de clés détenues par le client, garantissant aux sous-traitants de la défense la propriété exclusive de leurs clés de chiffrement, même lors d’un déploiement sur une infrastructure certifiée FedRAMP. Votre fournisseur cloud ne peut pas accéder à votre CUI car il ne détient jamais les clés nécessaires à son déchiffrement — fournissant ainsi une preuve claire du contrôle d’accès à la CUI pour les évaluateurs CMMC.

Les organisations ayant besoin du plus haut niveau de protection des clés peuvent intégrer Kiteworks à des modules matériels de sécurité (HSM) pour un stockage inviolable des clés, conforme aux exigences de validation FIPS 140-3.

Pour découvrir comment Kiteworks contribue à la conformité CMMC 2.0 avec des clés de chiffrement validées FIPS 140-3 et détenues par le client, réservez une démo personnalisée adaptée à votre environnement de sous-traitance défense.