6 min de lecture

Gestion des secrets - 01 - Les 7 problèmes des secrets en .env

Les 7 vrais problèmes des fichiers .env : pas de rotation, pas d'audit, pas de chiffrement, partage risque et plus.

sécurité secrets .env bonnes pratiques DevOps
Gestion des secrets et vaults 2 / 10
  1. 01 Gestion des secrets - 00 - Pourquoi ton .env finira par te trahir
  2. 02 Gestion des secrets - 01 - Les 7 problèmes des secrets en .env
  3. 03 Gestion des secrets - 02 - Les solutions : du .env au vault manager
  4. 04 Gestion des secrets - 03 - Google Secret Manager : le guide pratique
  5. 05 Gestion des secrets - 04 - AWS Secrets Manager et ses alternatives
  6. 06 Gestion des secrets - 05 - HashiCorp Vault : le couteau suisse du secret management
  7. 07 Gestion des secrets - 06 - SOPS + age : chiffrer ses secrets dans git
  8. 08 Gestion des secrets - 07 - Secrets dans CI/CD : GitLab, GitHub et les bonnes pratiques
  9. 09 Gestion des secrets - 08 - Rotation des secrets : comment ne rien casser
  10. 10 Gestion des secrets - 09 - Glossaire
← Precedent Suivant →

01 - Les 7 problèmes des secrets en .env

Ce que tu vas apprendre

  • Les 7 failles concrètes du fichier .env
  • Pour chaque problème, un scénario réel et ce qui se passe quand ca tourne mal
  • Ce qu'une vraie solution apporte a chaque fois

Prerequisites

Avoir lu l'introduction de cette serie.

Le .env fait le job, mais il le fait mal

Le fichier .env est devenu le standard de facto pour gerer les secrets en développement. Tous les frameworks le supportent : dotenv pour Node, Bun le charge nativement, Docker Compose le lit avec env_file. C'est simple, c'est partout, et c'est exactement pour ca qu'on ne remet jamais en question ses limites.

Pourtant, ces limites sont reelles. Voici les 7 problèmes que j'ai rencontres sur paltemps.fr et sur d'autres projets.

1. Pas de chiffrement au repos

Ton .env est un fichier texte brut. Fais un cat .env sur ton serveur : tout est lisible, en clair. Si quelqu'un accede a ton disque (backup non chiffre, image Docker mal configuree, faille dans un service adjacent), il a tous tes secrets d'un coup.

bash# Sur ton VPS
cat /app/.env
# ANTHROPIC_API_KEY=sk-ant-api03-XXXX
# SMTP_PASS=monmotdepasse
# Tout est la, en clair

Un vault manager stocke les secrets chiffres avec AES-256 ou équivalent. Meme avec un acces au stockage, les donnees sont illisibles sans la clé de dechiffrement. Comme on l'a vu dans la serie sur le chiffrement symetrique, c'est la base de la protection des donnees au repos.

2. Pas de contrôle d'acces

Toute personne avec un acces SSH a ta machine peut lire le .env. Il n'y a pas de granularité : c'est tout ou rien. Le stagiaire qui a besoin de la clé Unsplash pour le front voit aussi le mot de passe admin et les credentials SMTP.

En pratique, sur un VPS partage entre plusieurs services, ca veut dire que n'importe quel processus avec les bons droits fichier peut lire tous les secrets. Un conteneur Docker compromis qui a acces au volume ou le .env est monte ? Il récupéré tout.

Les vault managers implementent du contrôle d'acces fin. Tel service a acces a telle clé, tel développeur voit tel secret. Le principe du moindre privilege, applique aux secrets.

3. Pas de trace d'audit

Qui a lu le .env la dernière fois ? Quand ? Depuis quelle IP ? Tu n'en sais rien. Le fichier ne garde aucune trace. Si un secret fuite, tu ne peux pas remonter a la source.

C'est un vrai problème quand tu travailles en équipe. Un jour, ta clé API Anthropic apparaît sur un forum. Tu as 4 développeurs qui ont le .env. Lequel l'a copie au mauvais endroit ? Sans audit trail, tu ne le sauras jamais.

Avec un vault, chaque acces a un secret est enregistre. Qui a lu quoi, quand, depuis quelle IP, avec quelle méthode d'authentification. Tu peux retracer la fuite.

4. Pas de rotation

Changer une clé API dans un .env, ca veut dire : se connecter en SSH au serveur, éditer le fichier, redemarrer l'application. Si tu as plusieurs serveurs, tu repetes l'opération sur chacun. Si tu en oublies un, tu as une app en erreur.

bash# La "rotation" en mode .env
ssh user@vps1 "sed -i 's/OLD_KEY/NEW_KEY/' /app/.env && docker compose restart"
ssh user@vps2 "sed -i 's/OLD_KEY/NEW_KEY/' /app/.env && docker compose restart"
ssh user@vps3 "sed -i 's/OLD_KEY/NEW_KEY/' /app/.env && docker compose restart"
# Tu as oublie vps4. Ton monitoring te reveille a 3h.

Le résultat : personne ne fait de rotation. Les clés restent en place pendant des mois, parfois des annees. Si une est compromise, l'attaquant a tout le temps du monde.

Les solutions cloud (Google Secret Manager, AWS Secrets Manager) permettent la rotation automatique. Tu changes le secret a un endroit, toutes les apps le recuperent au prochain démarrage ou meme a chaud.

5. Le problème du partage

Comment transmettre le .env a un nouveau développeur ? Les options classiques :

  • Par Slack/Discord : le secret reste dans l'historique du canal, accessible a tous les membres
  • Par email : transit en clair (sauf PGP, mais qui utilise ca au quotidien ?), stocke sur les serveurs mail
  • Sur un Google Drive partage : un lien qui finit par fuiter

Aucune de ces méthodes n'est sécurisée. Et le pire : tu n'as aucun moyen de revoquer l'acces une fois le secret transmis. Si le dev quitte l'équipe, il a toujours le .env dans son historique Slack.

Avec un vault, tu donnes un acces au développeur. Quand il part, tu revoques l'acces. Il ne garde rien.

6. Pas de versioning

Quelle version du .env tourne en production ? Celle d'hier ? Celle d'il y a 3 semaines ? Tu as change la clé SMTP mardi, mais est-ce que le serveur de staging a aussi ete mis à jour ?

Le .env n'a pas d'historique (sauf si tu le commit dans git, ce qui est un autre problème). Si tu fais une erreur en editant, pas de rollback facile. Tu te retrouves a fouiller tes messages Slack pour retrouver l'ancienne valeur.

Les vault managers gardent un historique de chaque version d'un secret. Tu peux voir les 10 dernières valeurs, revenir a une version antérieure, comparer ce qui a change.

7. Rayon d'explosion maximal

Un seul fichier contient tout. Cle API Anthropic, mot de passe admin, credentials SMTP, tokens Unsplash et Pexels. Si ce fichier fuite, c'est pas un secret qui est compromis : c'est l'integralite de ton application.

C'est le contraire du principe de moindre privilege. Dans un vault, chaque secret est isole. Une fuite de la clé Unsplash ne compromet pas le mot de passe admin. Tu peux segmenter tes secrets par service, par environnement, par niveau de sensibilite.

Le bilan

Ces 7 problèmes ne sont pas theoriques. Ils correspondent a des situations que j'ai vecues ou que j'ai vu arriver autour de moi. Le .env est un bon point de depart. Mais des que tu as plus d'un serveur, plus d'un développeur, ou des secrets sensibles (et une clé API qui te coûte de l'argent, c'est sensible), il faut passer a autre chose.

La question, c'est : a quoi ? Le prochain article presente l'échelle des solutions, de la plus simple (.env chiffre) a la plus robuste (HashiCorp Vault).

Navigation : Precedent : 00 - Introduction | Suivant : 02 - Les solutions

Sources

Retrouve d'autres articles techniques sur paltemps.fr.

Publie le · Mis a jour le

Articles liés

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.

Découvrir Pal'Temps