Toute équipe finit par avoir des identifiants éparpillés partout : un .env sur chaque ordinateur portable, un message épinglé dans Slack, un tableur intitulé « logins », une variable de CI définie par quelqu’un il y a deux ans. Un gestionnaire de secrets cloud sert à regrouper tout cela en un seul endroit, chiffré, à l’accès contrôlé et audité.
Ce guide explique ce que fait un gestionnaire de secrets cloud, comment choisir parmi les principales options, comment le déployer sans longue migration et quelle tâche il ne remplit pas : faire parvenir un secret à une personne qui n’a pas accès à votre compte cloud.
Ce que fait un gestionnaire de secrets cloud
Un gestionnaire de secrets stocke des valeurs sensibles et les remet sur demande aux identités autorisées. Les fonctions de base sont les mêmes d’un fournisseur à l’autre :
- Stockage chiffré au repos, avec des clés conservées dans le service de gestion de clés du fournisseur, et TLS pendant le transport.
- Accès fondé sur l’identité : chaque secret a une politique qui indique quels utilisateurs, rôles ou charges de travail peuvent le lire, le modifier ou le renouveler. Une application s’authentifie avec sa propre identité, pas avec un mot de passe maître.
- Journalisation d’audit de chaque lecture, écriture et rotation, avec qui, quoi et quand.
- Versions et rotation : une nouvelle valeur peut être préparée, les applications basculées dessus et l’ancienne version retirée. Beaucoup de gestionnaires renouvellent automatiquement les identifiants de base de données.
- Récupération à l’exécution : l’application récupère le secret au démarrage ou au moment où elle en a besoin, si bien que la valeur n’est jamais écrite dans le code, les images ou les fichiers de configuration.
Un secret, c’est tout ce qui donne un accès. La configuration qui se contente de décrire un comportement, comme un numéro de port ou un feature flag, a sa place dans la configuration ordinaire. Mélanger les deux encombre le coffre à secrets et rend la configuration dangereuse.
Comment en choisir un
Le choix dépend en général de l’endroit où tournent vos charges de travail et du nombre de clouds que vous utilisez.
| Option | Cas idéal | Points de vigilance |
|---|---|---|
| AWS Secrets Manager / Parameter Store | Charges de travail déjà sur AWS, identités IAM partout | Tarification par secret sur Secrets Manager ; Parameter Store coûte moins cher pour les valeurs simples |
| Google Secret Manager | Projets GCP, charges de travail Cloud Run et GKE | Choix de réplication régionale |
| Azure Key Vault | Charges de travail Azure, besoins de gestion du cycle de vie des certificats | Des coffres séparés par environnement pour garder des politiques simples |
| HashiCorp Vault | Multicloud ou sur site, identifiants dynamiques de courte durée | L’exploiter vous-même, sauf si vous prenez la version hébergée |
| Doppler, Infisical, 1Password Secrets Automation | Petites équipes qui veulent une synchronisation pratique pour les développeurs vers de nombreuses plateformes | Un éditeur de plus dans la chaîne de confiance |
Quatre questions règlent la plupart des choix. S’intègre-t-il à vos outils de déploiement et à votre environnement d’exécution sans code d’adaptation sur mesure ? Les charges de travail peuvent-elles s’y authentifier avec l’identité qu’elles ont déjà ? Renouvelle-t-il les types d’identifiants que vous détenez réellement ? Ses journaux d’audit arrivent-ils là où votre équipe de sécurité regarde déjà ? Le prix, les régions et les certifications de conformité viennent après ces quatre points.
Le déployer sans en faire un projet de six mois
- Faites l’inventaire et désignez des responsables. Listez chaque secret, l’endroit où il se trouve, ce qui l’utilise et qui en est responsable. Le responsable décide de la politique de rotation et de la liste des accès.
- Mettez d’abord en place les identités. Créez les rôles ou les comptes de service de chaque charge de travail et de chaque environnement avant de déplacer la moindre valeur. Des politiques d’accès du type « ce service, cet environnement, lecture seule » sont tout l’intérêt de l’exercice.
- Migrez par ordre de risque. D’abord les mots de passe des bases de données de production et les clés de paiement, puis les clés API de tiers, puis tout le reste. Retirez chaque valeur du code, des variables de CI et des fichiers de configuration au moment où vous la déplacez, et renouvelez-la au passage, car l’ancienne valeur a déjà été copiée un peu partout.
- Changez la façon dont les applications lisent les secrets. Remplacez les valeurs codées en dur et les fichiers d’environnement par un appel au SDK du gestionnaire au démarrage, ou injectez-les avec l’intégration native de la plateforme.
- Activez la rotation pour tout ce que le gestionnaire sait renouveler lui-même, et écrivez une fonction de rotation ou une procédure pour le reste.
- Alertez sur l’inhabituel. Un secret lu par une nouvelle identité, un pic de lectures ou une lecture depuis une région où vous ne déployez pas méritent une alerte d’astreinte.
Les erreurs courantes sont prévisibles : laisser les anciennes copies en place après la migration, donner à une charge de travail un accès en lecture à tout le coffre au lieu de ses seuls secrets, et écrire la valeur récupérée dans les journaux de l’application.
La lacune qu’un gestionnaire de secrets ne comble pas
Un gestionnaire de secrets est conçu pour les machines et pour les personnes présentes dans votre système d’identité. Il n’est pas conçu pour le moment où des identifiants doivent parvenir à quelqu’un d’extérieur : un prestataire qui a besoin d’un mot de passe de base de données temporaire, un client qui reçoit son premier accès administrateur, l’ingénieur d’un fournisseur qui a besoin d’un jeton pour un après-midi, une nouvelle recrue le premier jour, avant que son compte SSO existe.
Ces transmissions ont lieu de toute façon et, faute de voie officielle, elles passent par l’e-mail et la messagerie, précisément les endroits d’où les gestionnaires de secrets devaient faire sortir les identifiants. La voie officielle, c’est un lien secret à usage unique. La valeur est chiffrée dans votre navigateur avant d’être stockée, le message ne contient qu’un lien, la copie stockée est détruite à la première ouverture du lien, et le lien expire au bout d’un délai si personne ne l’ouvre.
Le schéma qui fonctionne : le gestionnaire de secrets est le système de référence, et le lien à usage unique est le moyen de remise quand une personne extérieure au système a besoin d’une valeur une seule fois. Générez les identifiants, stockez-les dans le gestionnaire, envoyez-les à la personne par un lien à usage unique et renouvelez-les quand son accès prend fin. Liens secrets ou gestionnaires de mots de passe applique le même raisonnement au gestionnaire de mots de passe de l’équipe, et le guide sur les identifiants entre équipes décrit la marche à suivre au quotidien.
Une courte liste de contrôle
- Chaque secret a un responsable, une politique d’accès et une règle de rotation.
- Les charges de travail s’authentifient avec leur propre identité, jamais avec une clé partagée.
- Après la migration, plus aucun secret ne se trouve dans le code, les images, les variables de CI ou les messageries.
- Les lectures sont journalisées à un endroit que quelqu’un consulte vraiment.
- Les personnes extérieures au système d’identité reçoivent les secrets par un lien à usage unique, pas dans un message.
Appliquez ces cinq points, et le gestionnaire de secrets n’est plus un produit que vous avez acheté : il devient la raison pour laquelle les identifiants ont cessé de fuir.