Pourquoi votre mot de passe de base de données ne devrait jamais se trouver dans un fichier de configuration

Vous construisez une nouvelle application. Au début, vous mettez toutes les données variables dans un seul fichier : nom de la base de données, adresse du serveur, URLs des API. Il part dans Git, est poussé vers le dépôt, puis déployé sur le serveur. Tout est au même endroit, et cela semble pratique. Ensuite, vous ajoutez un mot de passe de base de données dans ce même fichier. Puis un token d'API. Puis une clé de chiffrement. Soudain, ce simple fichier de configuration devient un risque de sécurité qui pourrait faire tomber tout votre système.

C'est le moment où vous réalisez que toutes les données de configuration ne se valent pas. Certaines données, si elles sont exposées, donnent à quelqu'un d'autre les clés de votre royaume. Ces données s'appellent un secret. Et traiter les secrets comme une configuration ordinaire est l'une des erreurs les plus courantes et les plus dangereuses que les équipes commettent.

La différence entre configuration et secret

Les données de configuration ordinaires incluent des éléments comme les noms de serveurs, les ports d'application ou les feature flags. Si quelqu'un en dehors de votre équipe sait que votre application tourne sur le port 8080, ce n'est pas une catastrophe. Il ne peut pas se connecter à votre base de données simplement parce qu'il connaît le numéro de port.

Les secrets sont différents. Un mot de passe de base de données, un token d'API ou une clé de chiffrement peuvent être utilisés par un attaquant pour usurper l'identité de votre système, accéder à vos données ou détruire votre infrastructure. L'impact d'une fuite de secret est immédiat et grave.

Pourtant, de nombreuses équipes traitent encore les secrets comme s'il s'agissait de configuration ordinaire. Elles mettent des mots de passe dans des fichiers .env et les commitent dans Git. Elles stockent des tokens d'API dans des fichiers de configuration d'application et les poussent vers le dépôt. Elles conservent des clés SSH dans des dossiers de projet et sauvegardent le tout dans le cloud. Ce n'est pas parce que l'équipe est négligente. C'est généralement parce qu'elle n'a pas encore subi les conséquences.

Que se passe-t-il quand un secret fuit

En 2022, plusieurs incidents très médiatisés ont impliqué des tokens AWS laissés dans des dépôts publics. Les attaquants ont utilisé ces tokens pour lancer des instances de minage de cryptomonnaies. Les factures se sont élevées à des dizaines de milliers de dollars en quelques heures. Dans d'autres cas, des mots de passe de base de données divulgués ont conduit au téléchargement et à la vente de données clients sur le dark web.

Ces incidents n'ont pas commencé par une attaque sophistiquée. Ils ont commencé par une simple erreur : traiter un secret comme un fichier de configuration. Le secret était là, visible pour quiconque pouvait accéder au dépôt. Une fois le dépôt rendu public, le secret était public aussi.

L'historique Git aggrave les choses. Même si vous supprimez un fichier contenant un secret, le secret reste dans l'historique des commits. Quiconque clone le dépôt peut exécuter git log et trouver le mot de passe que vous pensiez avoir supprimé. Il n'existe pas de moyen simple de nettoyer complètement l'historique Git, surtout si le dépôt a été partagé ou forké.

Comment la configuration et les secrets diffèrent en pratique

Les différences entre configuration et secrets affectent la manière dont vous les gérez dans votre travail quotidien et dans votre pipeline CI/CD.

Qui peut les voir : La configuration peut être visible par tous les développeurs de l'équipe. Les secrets ne doivent être visibles que par les personnes ou les systèmes qui en ont absolument besoin. Tous les développeurs n'ont pas besoin de connaître le mot de passe de la base de données de production.

Où ils sont stockés : La configuration peut vivre dans Git. Les secrets ne doivent jamais être stockés dans Git. Ils appartiennent à un système de stockage de secrets dédié qui les chiffre au repos et en transit.

Comment ils sont renouvelés : La configuration a rarement besoin d'être renouvelée. Vous changez un nom de serveur lorsque vous migrez une infrastructure, et c'est tout. Les secrets nécessitent un renouvellement régulier. Vous devriez renouveler les mots de passe de base de données tous les quelques mois, et immédiatement en cas de suspicion de fuite.

Comment les pipelines les gèrent : Dans un pipeline CI/CD, la configuration peut être lue directement à partir d'un fichier dans le dépôt. Le pipeline prend le fichier et l'utilise. Les secrets nécessitent une approche différente. Le pipeline doit les récupérer depuis un système de stockage sécurisé, les injecter dans le processus de build ou de déploiement, et s'assurer qu'ils n'apparaissent jamais dans les logs, les artefacts ou les fichiers déployés.

Les conséquences pratiques de la confusion entre les deux

Lorsque vous traitez les secrets comme de la configuration, vous créez une chaîne de problèmes difficiles à résoudre.

Premièrement, vous perdez le contrôle de qui y a accès. Si le secret est dans Git, toute personne ayant accès au dépôt a le secret. Cela inclut les sous-traitants, les anciens employés qui ont encore accès, et potentiellement les attaquants si le dépôt est public.

Deuxièmement, vous rendez le renouvellement difficile. Si le secret est dispersé dans plusieurs fichiers de configuration, branches et environnements de déploiement, le renouveler signifie trouver chaque copie et la mettre à jour. Vous en manquerez inévitablement une, et cet ancien mot de passe restera valide quelque part.

Troisièmement, vous brisez votre piste d'audit. Si un secret fuit, vous devez savoir qui y avait accès et quand. Si le secret était dans Git, la réponse est « tous ceux qui ont jamais eu accès au dépôt ». Ce n'est pas une piste d'audit utile.

Un moyen simple de faire la différence

Avant de mettre une donnée dans un fichier de configuration, posez-vous une question : « Si quelqu'un en dehors de mon équipe voit cela, peut-il l'utiliser pour accéder à mon système ? »

Si la réponse est non, c'est probablement de la configuration. Les noms de serveurs, les numéros de port, les feature flags et les niveaux de log sont de la configuration.

Si la réponse est oui, c'est un secret. Les mots de passe de base de données, les tokens d'API, les clés SSH, les clés de chiffrement et les identifiants de comptes de service sont des secrets.

Ce test simple évitera la plupart des erreurs courantes que les équipes commettent.

Checklist pratique pour la gestion des secrets

Lorsque vous configurez votre prochain projet ou que vous révisez le projet actuel, parcourez cette checklist :

• Tous les secrets sont-ils stockés en dehors de Git ? Utilisez un gestionnaire de secrets ou un coffre-fort dédié.
• Les secrets sont-ils injectés à l'exécution, et non intégrés dans les images ou les artefacts ?
• Vos pipelines CI/CD récupèrent-ils les secrets depuis une source sécurisée, et non depuis des fichiers du dépôt ?
• Les secrets sont-ils exclus des logs, des messages d'erreur et des sorties de débogage ?
• Avez-vous un calendrier de renouvellement pour chaque type de secret ?
• Existe-t-il un processus pour renouveler les secrets immédiatement en cas de suspicion de fuite ?
• Pouvez-vous révoquer l'accès aux secrets pour des personnes ou des systèmes spécifiques sans affecter les autres ?

Ce qu'il faut retenir

Si une donnée peut être utilisée par quelqu'un d'autre pour usurper votre identité ou celle de votre système, ce n'est pas de la configuration. C'est un secret. Traitez-le différemment. Stockez-le séparément. Renouvelez-le régulièrement. Et ne le commitez jamais dans Git. Le coût d'apprendre cette leçon à la dure est bien plus élevé que l'effort de bien faire les choses dès le départ.