HashiCorp Vault (Gestion des Secrets)

Définition

HashiCorp Vault est une plateforme de gestion centralisée des secrets qui stocke, chiffre et distribue les informations sensibles d'un système d'information : mots de passe de bases de données, clés d'API, certificats X.509, clés SSH, jetons d'accès cloud ou clés de chiffrement. Là où ces secrets se retrouvent habituellement disséminés dans des fichiers de configuration, des variables d'environnement, des dépôts Git ou des scripts d'exploitation, Vault impose un point de passage unique, authentifié, autorisé et journalisé.

Sa valeur ne se limite pas au coffre-fort. Vault introduit deux mécanismes structurants pour la sécurité : les secrets dynamiques, générés à la demande avec une durée de vie limitée, et le chiffrement as-a-service, qui permet aux applications de chiffrer des données sans jamais manipuler la clé maîtresse. Le produit est désormais édité sous licence BUSL (depuis 2023) au sein d'IBM, ce qui a donné naissance au fork open source OpenBao, compatible avec la majorité des API.

Fonctionnement technique

Vault repose sur un storage backend (Raft intégré, Consul, S3…) dans lequel toutes les données sont écrites chiffrées. La clé de chiffrement est elle-même protégée par une clé maîtresse qui n'existe jamais en clair sur disque : c'est le principe du seal/unseal. Au démarrage, Vault est scellé et inopérant ; il faut le desceller soit via le partage de secret de Shamir (par exemple 3 fragments sur 5 détenus par des opérateurs distincts), soit via l'auto-unseal délégué à un HSM ou à un KMS cloud (AWS KMS, Azure Key Vault, GCP KMS).

L'accès s'articule ensuite autour de trois couches :

• Les méthodes d'authentification (auth methods) : une identité — humaine ou machine — prouve qui elle est via OIDC, LDAP, Kerberos, un compte de service Kubernetes, un rôle IAM AWS ou la méthode AppRole. Vault émet en retour un token à durée de vie bornée.
• Les politiques (policies) : écrites en HCL, elles décrivent finement les chemins accessibles et les verbes autorisés. Exemple : path "database/creds/appli-web" { capabilities = ["read"] }. Le modèle est en deny by default.
• Les moteurs de secrets (secrets engines) : montés sur des chemins, ils déterminent la nature du secret servi — kv pour du stockage statique versionné, database, aws, pki, ssh, ou transit pour le chiffrement à la volée.

Chaque secret délivré est associé à un bail (lease) : passé son TTL, Vault révoque automatiquement l'identifiant auprès du système cible. Toutes les opérations sont écrites dans un audit device (fichier, syslog, socket) avec hachage HMAC des valeurs sensibles, ce qui fournit une piste d'audit exploitable en SIEM sans exposer les secrets eux-mêmes.

Exemples concrets

• Base de données : une application demande database/creds/readonly et reçoit un couple utilisateur/mot de passe PostgreSQL créé pour l'occasion, valable une heure, puis supprimé. Aucun mot de passe partagé, aucun secret figé dans le code.
• PKI interne : le moteur pki agit comme autorité de certification intermédiaire et émet des certificats TLS de courte durée pour le maillage de services, en remplacement des certificats manuels à trois ans.
• CI/CD : un pipeline GitLab s'authentifie via JWT et obtient des credentials AWS temporaires limités au déploiement concerné, éliminant les clés d'accès statiques stockées en variables de projet.
• Chiffrement applicatif : le moteur transit chiffre des numéros de carte ou des données de santé ; l'application ne détient jamais la clé, ce qui limite drastiquement l'impact d'une compromission de serveur applicatif.

Liens avec les autres concepts

Vault s'inscrit dans une démarche Zero Trust : l'identité machine remplace la confiance implicite accordée au réseau. Il constitue également une brique de PAM (gestion des accès à privilèges) orientée machine-to-machine, complémentaire des solutions dédiées aux comptes d'administration humains. Sur le plan réglementaire, l'audit trail et la rotation automatique répondent directement aux exigences de la NIS 2, de l'ISO 27001 (contrôles A.5.17 et A.8.24 sur les informations d'authentification et la cryptographie) et du RGPD pour les mesures techniques de protection. Il traite enfin de front le risque de secret sprawl, cause récurrente de fuites via des dépôts Git publics, en amont des scanners type gitleaks ou trufflehog.

Bonnes pratiques

• Bannir les tokens root en exploitation courante : les révoquer après l'initialisation et régénérer un token temporaire via les unseal keys en cas de besoin.
• Privilégier les secrets dynamiques aux secrets statiques dès que le système cible le permet ; à défaut, activer la rotation automatique du moteur kv ou des root credentials.
• Réduire les TTL au strict nécessaire et surveiller les baux orphelins, source de comptes résiduels.
• Séparer les périmètres avec les namespaces (édition Enterprise) ou des instances distinctes par environnement, et appliquer une politique par application plutôt qu'une politique globale.
• Externaliser les journaux d'audit vers un SIEM et alerter sur les échecs d'authentification, les descellements imprévus et les accès hors plage horaire.
• Sécuriser la haute disponibilité : cluster Raft à trois nœuds minimum, sauvegardes chiffrées testées, et procédure de disaster recovery documentée — un Vault indisponible bloque l'ensemble du SI.
• Protéger les fragments Shamir dans des supports physiquement distincts et détenus par des personnes différentes, avec une procédure de quorum formalisée.