Gestion des Secrets dans les Pipelines CI/CD de Défense : Vault, HSM et Rotation des Clés

Chaque système logiciel de défense dépend de secrets : les certificats TLS qui authentifient les identités des services, les clés API qui autorisent l'accès aux services externes, les mots de passe de bases de données qui protègent les données opérationnelles, les clés de chiffrement qui protègent les informations classifiées, et les clés de signature de code qui vérifient l'intégrité des firmwares et des logiciels. Si ces secrets sont traités avec négligence — stockés dans des fichiers de configuration, intégrés dans des référentiels de code source, transmis en tant que variables d'environnement en texte clair, ou laissés inchangés indéfiniment — ils deviennent des vecteurs d'attaque qui contournent tous les autres contrôles de sécurité.

La gestion des secrets dans les pipelines CI/CD de défense ne vise pas principalement à prévenir les erreurs des développeurs (bien qu'elle le fasse aussi). Il s'agit de mettre en œuvre une architecture de sécurité où les secrets ne sont jamais en texte clair en dehors de leur contexte d'utilisation autorisé, où chaque utilisation de secret est auditée, où les secrets ont des durées de vie définies et sont automatiquement renouvelés, et où la compromission d'un secret individuel a un rayon d'impact limité grâce à une expiration courte et un accès limité.

Types de Secrets dans les Pipelines de Défense

Les pipelines CI/CD de défense rencontrent une plus grande variété de types de secrets que leurs équivalents commerciaux, car les systèmes qu'ils déploient ont des exigences plus strictes en matière de contrôle d'accès et d'authentification :

Les certificats TLS authentifient les identités des services dans les déploiements mTLS et protègent les communications réseau. Dans un cluster Kubernetes de défense avec un maillage de services, chaque microservice a son propre certificat — potentiellement des milliers de certificats au total, tous nécessitant une rotation avant expiration. Les certificats pour les services externes doivent être liés à une CA autorisée ; les certificats de services internes peuvent être liés à une CA interne gérée par Vault ou le plan de contrôle du maillage de services.

Les clés API et les jetons d'accès autorisent les appels de service à service, l'accès aux flux de renseignements sur les menaces externes, l'accès à l'API SIEM et l'intégration avec les backends des systèmes classifiés. Ce sont généralement des secrets statiques (non générés dynamiquement) et les plus susceptibles d'apparaître dans les référentiels de code source par erreur de développeur.

Les identifiants de bases de données protègent l'accès aux bases de données opérationnelles et classifiées. Les identifiants de base de données statiques — une paire nom d'utilisateur et mot de passe qui ne change jamais — représentent un risque de sécurité significatif : si les identifiants sont compromis, l'accès persiste jusqu'à ce qu'ils soient manuellement renouvelés, ce qui peut ne pas se produire pendant des mois ou des années. Les identifiants dynamiques avec des durées de vie courtes sont nettement plus sécurisés.

Les clés de signature de code sont utilisées pour signer les versions logicielles, les images de conteneurs, les packages de firmware et les bundles de configuration. Ces clés sont extrêmement sensibles — une clé de signature de code compromise permet à un attaquant de signer du code malveillant qui sera approuvé par tous les systèmes qui font confiance à la clé. Les clés de signature de code doivent être protégées par du matériel HSM et nécessiter une autorisation multi-parties pour leur utilisation.

HashiCorp Vault : Secrets Dynamiques et Journal d'Audit

HashiCorp Vault est la plateforme de gestion des secrets standard pour les environnements DevSecOps de défense. Vault fournit un stockage centralisé et audité pour les secrets, une API unifiée pour la récupération des secrets, et un moteur de secrets dynamiques qui génère des identifiants limités dans le temps et à usage spécifique plutôt que d'exiger des applications qu'elles stockent des secrets statiques à longue durée de vie.

Les secrets dynamiques sont la fonctionnalité de sécurité la plus puissante de Vault. Au lieu de stocker un mot de passe de base de données statique que les applications récupèrent, Vault génère dynamiquement un nouvel utilisateur de base de données avec des identifiants limités dans le temps chaque fois qu'une application demande l'accès. Les identifiants expirent automatiquement et l'utilisateur de la base de données est révoqué après la période de bail (généralement 1 à 24 heures). Un attaquant qui capture des identifiants de base de données dynamiques dispose d'une fenêtre étroite pour les exploiter avant leur expiration ; un attaquant avec des identifiants statiques dispose d'un accès indéfini jusqu'au renouvellement manuel.

Les moteurs de secrets dynamiques de Vault couvrent PostgreSQL, MySQL, MSSQL, MongoDB, Cassandra, Elasticsearch (pour la gestion des journaux), PKI (émission de certificats), AWS IAM (identifiants cloud) et plus. Pour les environnements de défense, le moteur de secrets PKI — qui permet à Vault d'agir comme une CA intermédiaire émettant des certificats TLS de courte durée à la demande — est particulièrement précieux : les certificats émis avec des TTL de 24 heures éliminent la fenêtre d'abus de certificat si un certificat est compromis.

Le journal d'audit de Vault enregistre chaque appel API à Vault : chaque demande de secret, chaque tentative d'authentification, chaque recherche de politique. Le journal d'audit est en ajout uniquement et ne peut pas être modifié par les administrateurs de Vault. Pour les environnements de défense, le journal d'audit fournit la piste de preuves requise par l'accréditation : qui a accédé à quel secret, quand et depuis quel système. Les journaux d'audit de Vault doivent être transmis au SIEM pour corrélation avec les événements d'application et de réseau.

Modules de Sécurité Matériels : Quand le Vault Logiciel est Insuffisant

HashiCorp Vault sécurise ses propres clés de chiffrement (la clé maîtresse utilisée pour desceller Vault et chiffrer son magasin de secrets) en utilisant une approche de chiffrement de clé logicielle. Pour la plupart des environnements, c'est une sécurité adéquate. Pour les environnements de défense avec des exigences FIPS 140-2 niveau 3 — qui s'appliquent aux systèmes de sécurité nationale et aux systèmes gérant du matériel cryptographique classifié — les clés racines doivent être protégées par du matériel, pas par du logiciel.

FIPS 140-2 niveau 3 exige une sécurité physique avec preuve de manipulation, une authentification basée sur l'identité pour les opérateurs, et des paramètres de sécurité critiques (clés privées) qui ne sont jamais exportés en texte clair. Les magasins de clés logiciels, aussi bien chiffrés soient-ils, ne satisfont pas cette exigence car la clé de chiffrement elle-même existe en mémoire logicielle où elle est potentiellement accessible à un attaquant logiciel privilégié.

Le descellement automatique HSM pour Vault est l'architecture standard : la clé maîtresse de Vault est enveloppée par une clé HSM, et Vault se descelle automatiquement en envoyant sa clé maîtresse enveloppée au HSM pour déballage au démarrage. Le HSM effectue le déchiffrement dans sa limite inviolable — la clé maîtresse n'existe jamais en texte clair en dehors du HSM. Cette architecture satisfait les exigences FIPS 140-2 niveau 3 pour la couche de protection des clés racines.

L'intégration HSM prise en charge pour HashiCorp Vault Enterprise inclut Thales (anciennement SafeNet) Luna, nCipher nShield, AWS CloudHSM et Azure Dedicated HSM. Pour les environnements de défense à air comprimé, les options HSM sur site (Thales Luna, nCipher nShield) sont requises — les services HSM basés sur le cloud ne sont pas accessibles depuis des réseaux à air comprimé.

Rotation des Clés Sans Interruption

La rotation des clés — remplacer une clé cryptographique existante par une nouvelle — est essentielle pour l'hygiène de sécurité : elle limite la fenêtre d'exposition si une clé est compromise et satisfait les exigences réglementaires pour les limites de durée de vie des clés. Mais la rotation des clés qui nécessite une interruption des applications ou une coordination manuelle complexe est souvent reportée indéfiniment, annulant sa valeur de sécurité.

La gestion des versions de clés de Vault permet une rotation sans interruption pour les secrets et les clés de chiffrement. Lorsque le moteur de chiffrement de transit de Vault (qui fournit le chiffrement en tant que service pour les applications) fait pivoter une clé, il crée une nouvelle version de clé tout en conservant les versions plus anciennes pour le déchiffrement des données chiffrées avec des versions précédentes. Les applications chiffrant de nouvelles données utilisent la version de clé actuelle ; le texte chiffré existant peut toujours être déchiffré en utilisant l'ancienne version jusqu'à ce que l'application soit mise à jour pour le rechiffrer. La rotation est transparente pour l'application — elle n'a pas besoin d'être mise hors ligne.

Les périodes de grâce pour la rotation des certificats permettent un déploiement progressif des nouveaux certificats : le nouveau certificat est distribué et approuvé avant que l'ancien ne soit révoqué, de sorte qu'il n'y a pas de fenêtre où certains services ont le nouveau certificat et d'autres ne l'ont pas encore reçu. Le moteur de secrets PKI de Vault prend en charge la configuration des TTL de certificats et des périodes de renouvellement pour automatiser cette gestion de période de grâce.

Intégration CI/CD : Modèles d'Injection de Secrets

Les secrets doivent atteindre les applications et les composants d'infrastructure qui en ont besoin sans être exposés dans les journaux de pipeline CI/CD, les vidages de variables d'environnement ou les couches d'images de conteneurs. Trois modèles d'intégration dominent les environnements CI/CD de défense :

Le sidecar d'agent Vault (dans Kubernetes) déploie un conteneur Vault Agent aux côtés du conteneur d'application. L'agent Vault s'authentifie auprès de Vault en utilisant l'identité du compte de service Kubernetes du pod, récupère les secrets configurés et les écrit dans un volume partagé en mémoire ou les injecte dans l'environnement du conteneur d'application. Les secrets n'apparaissent jamais dans la spécification du pod ou l'image du conteneur — ils sont injectés à l'exécution depuis Vault.

External Secrets Operator est un opérateur Kubernetes qui synchronise les secrets depuis des magasins de secrets externes (Vault, AWS Secrets Manager, Azure Key Vault) vers Kubernetes Secrets. Il fournit une approche déclarative et compatible GitOps : la ressource personnalisée ExternalSecret dans la configuration GitLab/Kubernetes déclare quels secrets sont nécessaires et d'où ils proviennent ; l'opérateur gère la récupération et la synchronisation. Les Kubernetes Secrets créés par l'opérateur peuvent être montés normalement dans les pods.

Pour les pipelines GitLab CI, l'intégration GitLab-Vault (intégration GitLab CI/CD Vault, utilisant l'authentification JWT) permet aux tâches de pipeline de s'authentifier auprès de Vault en utilisant leur identité JWT GitLab et de récupérer les secrets pour la durée de la tâche de pipeline. Les secrets sont disponibles en tant que variables d'environnement dans la tâche et ne sont jamais stockés dans la configuration GitLab CI ou le référentiel.