Où vivent les secrets : des fichiers de configuration au coffre-fort

Vous mettez en place une nouvelle application. Vous créez un fichier .env avec les identifiants de base de données, les clés API et les adresses des serveurs. Tout fonctionne sur votre machine. Vous le commitez dans Git pour que votre collègue puisse reproduire la même configuration. Quelques mois plus tard, l'application est en production, et quelqu'un pousse accidentellement ce fichier .env vers un dépôt public. En quelques minutes, votre mot de passe de base de données de production est sur Internet.

Ce scénario n'est pas rare. Il se produit parce que la façon la plus simple de stocker des secrets est aussi la plus dangereuse. Le chemin qui mène du stockage des secrets dans des fichiers de configuration à l'utilisation d'outils dédiés à la gestion des secrets est un chemin que chaque équipe emprunte, souvent après avoir appris à ses dépens.

Le problème des fichiers de configuration

Lorsque vous apprenez à construire des applications, mettre tout dans un seul fichier de configuration semble naturel. Votre .env, config.json ou application.properties devient un fourre-tout. Les adresses de serveurs, qui ne sont pas sensibles, côtoient les mots de passe de base de données, qui le sont extrêmement. Le fichier entier part dans Git, et toute personne ayant accès au dépôt peut tout voir.

Cette approche fonctionne bien lorsque vous êtes le seul développeur et que l'application tourne sur votre ordinateur portable. Mais dès que votre équipe grandit ou que l'application atteint de vrais utilisateurs, les fissures apparaissent. Chaque développeur qui clone le dépôt peut voir les mots de passe de production. Même si le dépôt est privé, les secrets sont stockés en permanence dans l'historique Git. Supprimer le fichier du dernier commit ne suffit pas à le retirer des commits plus anciens. Le secret est là pour toujours, accessible à quiconque sait parcourir l'historique Git.

L'étape suivante que la plupart des équipes franchissent consiste à séparer les secrets de la configuration classique. Le fichier de configuration reste dans Git, mais les valeurs sensibles deviennent des espaces réservés comme DB_PASSWORD=changeme. Les vraies valeurs vivent ailleurs : un fichier qui n'est pas commité, des variables d'environnement sur le serveur, ou un document partagé via un chat. C'est mieux que de stocker les secrets dans Git, mais cela introduit de nouveaux problèmes. Il n'y a pas d'enregistrement de qui a accédé au secret. Faire tourner un mot de passe signifie le mettre à jour manuellement à plusieurs endroits. Si le fichier de secrets est perdu ou corrompu, il n'y a pas de sauvegarde gérée pour le restaurer.

Ce que change un coffre-fort dédié aux secrets

Les équipes qui gèrent plusieurs applications et environnements finissent par chercher des outils construits spécifiquement pour les secrets. Vault, AWS Secrets Manager, Azure Key Vault et GCP Secret Manager sont conçus pour traiter correctement les données sensibles. Les secrets ne sont plus des fichiers sur le disque. Ils deviennent des objets que les applications récupèrent via une API.

Le passage des fichiers à un coffre-fort de secrets change trois choses fondamentales :

Voici un exemple rapide de la façon de stocker et de récupérer un mot de passe de base de données avec HashiCorp Vault :

# Stocker un secret
vault kv put secret/myapp DB_PASSWORD=supersecret

# Récupérer le secret
vault kv get secret/myapp

# Sortie :
# ====== Data ======
# Key              Value
# ---              -----
# DB_PASSWORD      supersecret

Contrôle d'accès. Avec un fichier de configuration, toute personne capable de lire le fichier peut voir le secret. Avec un coffre-fort, vous définissez quelle application ou quel pipeline peut accéder à quel secret. Un pipeline CI pour l'environnement de staging peut récupérer les identifiants de staging mais ne peut pas toucher aux secrets de production. Cette granularité est impossible avec des fichiers.

Piste d'audit. Les fichiers ne journalisent pas qui les a lus. Un coffre-fort enregistre chaque demande d'accès : qui a demandé, quel secret a été demandé et quand cela s'est produit. Si un secret fuit, vous pouvez retracer quelles applications ou utilisateurs y ont accédé autour du moment de l'incident.

Chiffrement au repos et en transit. Les fichiers de configuration stockent les secrets en texte clair sur le disque. Un coffre-fort chiffre les secrets lors de leur stockage et de leur envoi sur le réseau. Même si quelqu'un accède au stockage sous-jacent, il ne peut pas lire les secrets sans les clés de chiffrement.

Le coût opérationnel de l'utilisation d'un coffre-fort

Les outils de gestion de secrets ne sont pas gratuits, et le coût n'est pas seulement monétaire. Votre équipe doit apprendre à utiliser l'outil. Si le coffre-fort tombe en panne, les applications ne peuvent pas récupérer les secrets et peuvent cesser complètement de fonctionner. Vous avez besoin de stratégies pour la haute disponibilité, la mise en cache ou des mécanismes de repli afin qu'une panne du coffre-fort ne fasse pas tomber votre système de production.

Les coffres-forts de secrets gérés dans le cloud réduisent la charge opérationnelle mais introduisent une tarification par requête ou par secret. Une équipe qui effectue des milliers de demandes de secrets par minute doit déterminer si le coût est durable. Les options auto-hébergées comme Vault vous donnent plus de contrôle mais nécessitent un effort dédié pour la maintenance, la mise à niveau et la sécurisation.

Choisir ce qui convient à votre équipe

Il n'y a pas de réponse unique pour savoir où stocker les secrets. Le bon choix dépend de la taille de votre équipe, du nombre d'applications et de votre tolérance au risque.

Le diagramme suivant peut vous aider à décider quelle approche correspond à votre situation actuelle :

Une petite équipe avec une seule application et quelques environnements peut utiliser un fichier séparé qui n'est pas commité dans Git, à condition que tout le monde comprenne les risques. L'essentiel est d'être délibéré dans le choix, et non d'y tomber par défaut.

Une équipe avec plusieurs applications, plusieurs environnements et plusieurs développeurs bénéficiera d'un coffre-fort de secrets dédié. Le surcoût de sa mise en place est rentabilisé dès la première fois que vous devez faire tourner un identifiant dans tous les environnements ou enquêter sur qui a accédé à un secret qui a ensuite fuité.

Le principe important est la cohérence. Quelle que soit la méthode choisie, appliquez-la uniformément. Mélanger les approches, certains secrets dans des fichiers, d'autres dans des variables d'environnement, d'autres encore dans un coffre-fort, crée de la confusion et augmente le risque d'exposition accidentelle.

Liste de contrôle pratique pour le stockage des secrets

• Les secrets sont-ils séparés de la configuration classique ?
• Les secrets sont-ils exclus du contrôle de version (vérifiez .gitignore) ?
• Pouvez-vous faire tourner un identifiant sans modifier le code de l'application ?
• Savez-vous quelles applications et quels pipelines peuvent accéder à chaque secret ?
• Avez-vous des journaux montrant qui a accédé à un secret et quand ?
• Si votre coffre-fort de secrets tombe en panne, votre application peut-elle toujours démarrer ou échouer gracieusement ?

Et ensuite

Savoir où stocker les secrets n'est que la moitié du travail. La question suivante est de savoir comment votre pipeline récupère ces secrets sans les stocker dans la configuration du pipeline elle-même. Un pipeline CI/CD qui imprime les secrets dans les journaux, les stocke dans des variables d'environnement visibles par toutes les étapes, ou les met en cache dans des fichiers de l'espace de travail n'est pas mieux qu'un fichier de configuration commité dans Git. La méthode de stockage compte, mais la façon dont les secrets circulent dans votre processus de livraison compte tout autant.