Gestionnaire de secrets
Sécurité
Service centralisé qui conserve chiffrés les secrets d'une infrastructure (mots de passe, clés d'API, certificats, jetons), ne les délivre qu'aux identités autorisées et journalise chaque accès. Il les sort du code et des fichiers de configuration, où ils finissent tôt ou tard dans un dépôt Git.
Stockage chiffré : Les secrets sont chiffrés au repos, en général sous une clé maîtresse elle-même protégée par un KMS ou un HSM. Le déchiffrement n'a lieu qu'à la demande d'un client authentifié, et le secret n'existe en clair que le temps de la réponse.
Accès et audit : Chaque lecture passe par une politique qui précise quelle identité lit quel chemin, avec quelles opérations. Chaque accès laisse une trace dans un journal d'audit : en cas de fuite, on sait qui a lu quoi et quand.
Rotation et secrets dynamiques : Certains gestionnaires génèrent des identifiants à la volée, avec une durée de vie courte, puis les révoquent à l'expiration du bail. Le mot de passe de base de données « temporaire » se révèle à l'usage celui qui a le plus d'ancienneté dans l'équipe ; un identifiant qui expire seul au bout d'une heure règle la question sans réunion.
Le secret zéro : Pour obtenir un secret, il faut d'abord s'authentifier, donc détenir un premier secret. On contourne ce problème en s'appuyant sur l'identité fournie par la plateforme : rôle IAM du cloud, compte de service Kubernetes ou jeton OIDC.
Ce qui arrive si on s'en passe
Sans gestionnaire de secrets, les mots de passe, clés d'API et jetons restent écrits dans le code ou les fichiers de configuration. Un seul commit suffit à les inscrire dans l'historique Git, où ils persistent même après suppression du fichier : toute copie du dépôt (clone, sauvegarde, poste de travail) les livre en clair. Aucun journal n'indique qui a lu quel secret ni quand, ce qui rend une fuite indétectable et son périmètre impossible à établir. La rotation devient une opération manuelle et dispersée, donc souvent repoussée : un identifiant exposé reste valide longtemps, et le révoquer peut casser des services dont la dépendance n'était documentée nulle part. Enfin, chaque personne ou machine qui lit la configuration détient tous les secrets qu'elle contient, sans restriction au strict nécessaire.
Explication de la marmotte
Imagine un immeuble où chaque employé a besoin de codes : celui du coffre, celui de la porte du garage, celui de l'ordinateur. Si chacun les note sur des post-it collés partout, le premier visiteur curieux repart avec tout. Un gestionnaire de secrets, c'est un gardien avec une armoire fermée à clé. Quand un programme a besoin d'un code, il vient le demander au gardien, qui vérifie d'abord son badge. Si le badge est bon, il donne le code, parfois un code qui ne marche qu'une heure, et il note sur un registre qui est venu et quand. Comme ça, plus de post-it qui traînent, et en cas de fuite, on sait où chercher.
Où ce terme est utilisé
- Les secrets dans les dépôts Git (6 occurrences)
- Calculer le coût total de possession d'un contrôle de sécurité (3 occurrences)
- Déployer Vault ou OpenBao pour supprimer les secrets en clair (3 occurrences)
- Comment automatiser la recertification des accès sensibles (2 occurrences)
- Comment mener un exercice de simulation d'incident (2 occurrences)
- Comptes de service Git à révoquer réellement (2 occurrences)
- DORA et résilience opérationnelle numérique financière (2 occurrences)
- Générer un SBOM CycloneDX dans un pipeline CI (2 occurrences)
- IT4IT 3.0 : flux de valeur et modèle de données de la DSI (2 occurrences)
- PAM, JIT et comptes break-glass sécurisés (2 occurrences)