Ce que la protection des CUI exige réellement en matière de gestion des clés

Tous les fournisseurs de plateformes destinées aux sous-traitants de la défense affirment que les CUI sont chiffrées. Cette affirmation masque le véritable critère de protection : qui détient la clé. Si le fournisseur la possède, le chiffrement protège les données contrôlées contre les tiers extérieurs, mais ne protège en rien contre le fournisseur lui-même, ni contre toute personne pouvant légalement contraindre ce fournisseur à déchiffrer.

Ce n’est pas une simple hypothèse pour un sous-traitant qui transfère des données techniques soumises à des restrictions d’exportation via des plateformes tierces. Un coffre verrouillé ne sert à rien si le fournisseur garde un double de la clé et le remet dès qu’une autorité étrangère le demande. Cet article explique ce que change réellement la gestion des clés pour les sous-traitants de la défense, pourquoi il s’agit du détail que la plupart des audits de sécurité négligent, et ce que requiert concrètement une gestion des clés réellement détenue par le client, jusque dans la capacité à faire tourner la clé et selon quel calendrier.

Résumé exécutif

Les audits de sécurité des plateformes traitant des CUI s’arrêtent souvent à l’algorithme de chiffrement et à la longueur de la clé, comme si AES-256 suffisait systématiquement à répondre aux exigences liées au contrôle à l’export. Ce n’est pas le cas. La véritable question qui détermine la protection est : qui contrôle la clé ? Car celui qui contrôle la clé contrôle la donnée, chiffrement ou non. Si le fournisseur génère, stocke et gère la clé pour le compte du sous-traitant, il conserve la capacité technique de lire les données techniques contrôlées à tout moment, pour n’importe quelle raison, y compris une raison à laquelle le sous-traitant n’a jamais consenti et dont il ne prendra connaissance que bien après coup. Une gestion des clés détenue par le client, reposant sur du matériel, supprime totalement cette capacité. Pour les responsables sécurité des programmes, cela fait passer le chiffrement d’un simple point de documentation à un fait architectural concret et vérifiable lors d’un audit CMMC ou de contrôle à l’export.

Points clés à retenir

1. Le chiffrement ne protège les données que des parties qui ne détiennent pas la clé. Si la clé est détenue par le fournisseur, la protection des CUI dépend de la volonté du fournisseur, et non du chiffrement lui-même.
2. Les modèles « apportez votre propre clé » suppriment totalement la capacité de déchiffrement du fournisseur, répondant ainsi directement aux exigences de contrôle à l’export. Une clé gérée par le fournisseur maintient cette capacité, quel que soit l’algorithme utilisé ou la description faite dans une proposition.
3. Un module matériel de sécurité rend la détention de la clé tangible, et non une simple politique. Une clé générée et stockée dans un HSM contrôlé par le sous-traitant ne peut pas être extraite par la plateforme hébergeant les données, même avec un accès administratif.
4. La rotation à la demande de la clé fait partie intégrante de la véritable propriété. Un sous-traitant qui ne peut pas faire tourner une clé selon son propre calendrier ne détient pas le contrôle opérationnel total sur ses données techniques contrôlées.
5. La robustesse du chiffrement n’a aucune importance si la clé est détenue par la mauvaise partie. Pour les CUI, la seule question qui compte est : qui peut déchiffrer, et non la puissance du chiffrement.

Pourquoi la robustesse du chiffrement n’est pas la bonne question pour les CUI

Les audits de sécurité posent sans cesse des questions sur le chiffrement, et les réponses évoquent presque toujours l’algorithme : AES-256 au repos, TLS 1.3 en transit. Ces réponses sont exactes, mais passent à côté de l’essentiel.

Les données chiffrées ont toujours un détenteur de la clé

Chaque fichier CUI chiffré n’a qu’un seul obstacle entre lui et une lecture en clair : la clé. Celui qui détient cette clé peut lire les données, les déchiffrer pour autrui, ou être contraint de les déchiffrer par voie légale. Un fichier chiffré avec un algorithme robuste mais une clé détenue par le fournisseur n’est pas réellement mieux protégé du fournisseur qu’un fichier avec un chiffrement plus faible, car dans les deux cas, le facteur limitant est le même : le fournisseur peut y accéder s’il le souhaite, ou s’il y est contraint.

Pourquoi les fournisseurs évitent généralement cette distinction

La documentation des fournisseurs décrit souvent le chiffrement avec des termes qui semblent rassurants : « chiffré au repos et en transit avec des algorithmes standard du secteur ». C’est exact, mais incomplet. Cela ne dit rien sur l’origine de la clé, son lieu de stockage, ou sur l’accès potentiel de l’infrastructure du fournisseur à cette clé, ce qui est précisément le point que vise à vérifier un audit de contrôle à l’export.

Ce que requiert réellement une gestion des clés détenue par le client

Détenir une clé n’est pas une simple fonctionnalité, mais une chaîne de conditions qui doivent toutes être réunies. Si un maillon manque, le contrôle du sous-traitant sur la clé devient théorique et non opérationnel.

Apportez votre propre clé vs clé gérée par le fournisseur

Dans un modèle de clé gérée par le fournisseur, la plateforme génère et stocke la clé de chiffrement dans sa propre infrastructure, et le sous-traitant ne la voit parfois jamais. Dans un modèle de clé détenue par le client, le sous-traitant contrôle la génération et le stockage de la clé, généralement via un module matériel de sécurité qu’il administre ou auquel il a un accès dédié. La différence, c’est la différence entre un fournisseur qui peut techniquement déchiffrer les CUI et un autre qui ne le peut pas, quels que soient les arguments marketing sur la robustesse du chiffrement.

Pourquoi les modules matériels de sécurité sont plus importants qu’il n’y paraît

Un module matériel de sécurité est un dispositif physique dédié, conçu pour générer, stocker et gérer des clés cryptographiques de façon à empêcher leur extraction, même par une personne disposant d’un accès administratif au système environnant. Intégrer la gestion des clés à un HSM, plutôt que de stocker les clés dans un logiciel à côté de l’application, transforme la détention de la clé en une contrainte physique. Une simple affirmation logicielle de détention de la clé par le client peut, en principe, être discrètement révoquée par un fournisseur ayant un accès suffisant à sa propre infrastructure. Un HSM correctement intégré élimine cette possibilité par conception, et non par politique.

Pourquoi la rotation et le contrôle des algorithmes déterminent la réalité de la propriété

Détenir une clé une fois ne signifie pas la contrôler en continu. Deux aspects opérationnels distinguent la véritable propriété d’une clé d’une affirmation qui paraît correcte sur une fiche technique mais ne tient pas face aux questions d’un auditeur.

Rotation à la demande de la clé

Si un sous-traitant soupçonne une exposition de la clé, que ce soit à cause d’un identifiant compromis, d’un collaborateur quittant l’entreprise ou d’une suspicion de fuite, la capacité à faire tourner cette clé immédiatement, sans attendre le calendrier du fournisseur ou la file d’attente du support, donne à la détention de la clé tout son sens opérationnel pour les données contrôlées.

Contrôle granulaire des algorithmes et protocoles

La possibilité d’activer ou de désactiver certains algorithmes de chiffrement et de contrôler les versions TLS autorisées constitue une forme de contrôle distincte mais complémentaire, que le sous-traitant doit pouvoir exercer selon son propre calendrier, notamment pour retirer un algorithme obsolète avant un audit.

Intégrer la gestion des clés dans l’évaluation des fournisseurs

Pour une équipe sécurité programme qui évalue un fournisseur, la démarche concrète est simple à décrire mais facile à négliger sous la pression du temps : demandez qui génère la clé, où elle est stockée, si un HSM est utilisé, qui peut la faire tourner et selon quel calendrier. Un fournisseur qui répond clairement à ces quatre questions, avec un contrôle total du sous-traitant à chaque étape, propose un modèle de gestion des clés défendable. Un fournisseur qui ne répond qu’à la première question, sur l’algorithme et la longueur de la clé, ne dit rien au sous-traitant sur le contrôle réel des CUI une fois chiffrées.

Comment un Data Control Plane garantit la détention des clés au niveau architectural

La gestion des clés détenues par le client ne tient ses promesses que si elle est intégrée à l’architecture de la plateforme, et non proposée en option que la plupart des déploiements ignorent. Un Data Control Plane qui considère la gestion des clés comme une propriété fondamentale garantit que le fournisseur ne pourra techniquement pas déchiffrer les CUI, quel que soit le canal utilisé (e-mail, partage de fichiers, API ou agents IA).

Le Data Control Plane de Kiteworks intègre les clés de chiffrement détenues par le client via un module matériel de sécurité, compatible avec les principaux fournisseurs de HSM, de sorte que la génération et le stockage des clés échappent totalement à Kiteworks. Les sous-traitants peuvent faire tourner leurs clés à la demande, choisir les algorithmes et versions TLS activés, et fonctionner sur une architecture à locataire unique où la gestion des clés n’est partagée avec aucun autre environnement client. Sur cette base, des contrôles zero-trust pilotés par la donnée encadrent chaque envoi, partage et accès, et chaque action est consignée dans un journal d’audit inviolable et non limité alimentant directement les outils SIEM, de sorte que la gestion des clés repose sur des preuves concrètes et non sur une simple mention dans une proposition commerciale.

Les sous-traitants souhaitant tester le modèle de gestion des clés de leur fournisseur actuel par rapport à ce standard peuvent réserver une démo personnalisée pour découvrir comment l’intégration d’un HSM contrôlé par le client s’applique à leurs propres exigences en matière de CUI et de contrôle à l’export.