Gérer ses secrets et variables d'environnement proprement en production

Un secret exposé peut suffire à compromettre une application entière. Une clé API divulguée permet parfois d’utiliser un service à vos frais, tandis qu’un mot de passe de base de données peut donner accès aux données de production. Les fuites les plus fréquentes viennent d’un secret commité dans Git, écrit directement dans le code, affiché dans les logs ou intégré à une image Docker.

Le principe fondamental consiste à séparer la configuration du code, conformément à l’approche 12-factor. Le dépôt doit contenir la logique de l’application et les modèles de configuration, jamais les identifiants réels. Les secrets doivent être injectés au moment du déploiement, avec des droits d’accès limités et une procédure de rotation claire.

Ne jamais commiter de secret

Un fichier .env contenant des valeurs réelles ne doit jamais entrer dans l’historique Git. Ajoutez-le au fichier .gitignore dès la création du projet :

.env
.env.*
!.env.example

Cette configuration ignore les variantes comme .env.production tout en autorisant le suivi de .env.example. Vérifiez néanmoins les règles de votre dépôt, car un fichier déjà suivi par Git reste suivi même après son ajout à .gitignore.

Si un secret a déjà été poussé, considérez-le immédiatement comme compromis. Il faut le révoquer auprès du service concerné, en générer un nouveau, mettre à jour la production puis vérifier les journaux d’accès. Supprimer le secret du dernier commit ou réécrire l’historique Git ne suffit pas : il peut rester dans un clone, un cache, une sauvegarde ou une copie réalisée par un tiers.

La réécriture de l’historique reste utile pour limiter l’exposition résiduelle, mais elle intervient après la révocation. Pour réduire le risque, intégrez également un outil de détection de secrets aux contrôles locaux et à la CI. Ces scanners recherchent notamment les clés connues, les chaînes à forte entropie et les formats de tokens courants. Un résultat doit être vérifié rapidement, sans recopier la valeur détectée dans un ticket ou un message.

Variables d’environnement : une base simple et efficace

Pour de nombreuses applications, les variables d’environnement constituent un bon point de départ. Conservez les valeurs réelles dans un fichier .env non versionné et fournissez un fichier .env.example sans information sensible :

APP_ENV=production
DATABASE_URL=
API_TOKEN=
SESSION_SECRET=

Ce modèle documente les variables attendues sans exposer leur contenu. Évitez les fausses valeurs qui ressemblent à de vraies clés, car elles compliquent les scans et peuvent finir utilisées par erreur.

Sur un serveur Linux, limitez la lecture du fichier au seul propriétaire :

chmod 600 .env

Le compte qui exécute l’application doit être le seul à pouvoir accéder au fichier. Évitez de lancer le service avec un compte administrateur lorsque ce n’est pas nécessaire. Les sauvegardes contenant ce fichier doivent bénéficier des mêmes protections.

L’application peut charger le fichier au démarrage avec sa bibliothèque de configuration. Avec Docker Compose, utilisez env_file :

services:
  app:
    image: talcloud-app:latest
    env_file:
      - .env

Le fichier .env doit être présent sur le serveur de déploiement, hors du dépôt et avec des permissions strictes. Ne fournissez jamais un endpoint de diagnostic qui retourne toutes les variables d’environnement. Lorsqu’une configuration doit être affichée, utilisez une liste blanche de valeurs non sensibles.

Protéger les secrets dans Docker

N’inscrivez jamais un secret dans un Dockerfile, y compris pour une étape de construction. Les instructions ENV, les fichiers copiés et les arguments ARG peuvent rester accessibles dans les couches, le cache ou les métadonnées de l’image. Supprimer ensuite le fichier dans une autre instruction ne garantit pas sa disparition.

Préférez une injection au runtime avec des variables d’environnement ou un mécanisme de secrets. Les Docker secrets et les systèmes équivalents montent généralement la valeur sous forme de fichier accessible au conteneur, ce qui évite de la placer directement dans la définition de l’image.

Si une dépendance privée exige un token pendant le build, utilisez un montage de secret temporaire compatible avec votre outil de construction. Vérifiez aussi les scripts : une commande en mode verbeux, un printenv ou un message de débogage peut afficher les identifiants dans les logs de CI.

Enfin, ne publiez pas une image sans contrôler son contenu. Recherchez les fichiers .env, clés privées, archives et configurations locales susceptibles d’avoir été copiés par une instruction trop large. Un fichier .dockerignore réduit ce risque, mais ne remplace pas une revue du processus de build.

Générer des secrets forts

Un bon secret doit être aléatoire, suffisamment long et impossible à deviner. N’utilisez ni mot du dictionnaire, ni nom de projet, ni date, ni valeur réutilisée. Pour générer une valeur aléatoire encodée en hexadécimal :

openssl rand -hex 32

Pour obtenir une valeur encodée en Base64 :

openssl rand -base64 48

La longueur nécessaire dépend du système, mais 32 octets aléatoires conviennent à de nombreux tokens applicatifs. Vérifiez les contraintes de caractères du service destinataire avant de choisir l’encodage.

Chaque service et chaque environnement doit disposer de son propre secret. Une clé partagée entre plusieurs applications transforme une fuite locale en compromission générale. Cette séparation améliore aussi la traçabilité : lorsqu’une clé est utilisée, il devient possible d’identifier précisément son propriétaire et son usage.

Organiser la rotation sans coupure

La rotation limite la durée d’exploitation d’un secret volé et réduit l’impact d’une fuite passée inaperçue. Elle doit avoir lieu périodiquement, mais aussi après le départ d’un collaborateur, une alerte de sécurité, une exposition dans les logs ou un changement important d’infrastructure.

Pour éviter une interruption, préparez d’abord la nouvelle clé. Configurez temporairement le service pour accepter l’ancienne et la nouvelle, puis déployez les consommateurs avec la nouvelle valeur. Surveillez les erreurs d’authentification et confirmez que l’ancienne clé n’est plus utilisée. Vous pouvez alors la révoquer.

Lorsque le service ne prend en charge qu’un seul secret, prévoyez une fenêtre contrôlée ou une stratégie intermédiaire, par exemple deux comptes techniques aux droits identiques. Documentez le propriétaire, la date de création, la dernière rotation et la procédure d’urgence, sans documenter la valeur elle-même.

Séparer développement, staging et production

Les environnements de développement, de staging et de production doivent employer des identifiants distincts. Une machine de développement ne doit jamais contenir un secret de production. Elle accueille davantage d’outils, de dépendances et de comptes utilisateurs, ce qui augmente sa surface d’exposition.

Appliquez aussi le principe du moindre privilège. Une application qui lit une base ne doit pas recevoir un compte administrateur. Un service de staging ne doit pas pouvoir appeler les ressources de production. Pour les tests locaux, utilisez des clés dédiées, des services simulés ou des données anonymisées.

Cette séparation facilite les révocations ciblées. La fuite d’un token de développement ne doit pas imposer une rotation générale de la production.

Utiliser un gestionnaire de secrets quand le besoin grandit

À mesure que l’équipe, le nombre de services ou les exigences d’audit augmentent, un gestionnaire centralisé devient pertinent. Des solutions comme Vault, Infisical ou OpenBao peuvent fournir un stockage chiffré au repos, des politiques d’accès, un journal d’audit et parfois des identifiants dynamiques à durée de vie courte.

Ces outils apportent aussi de la complexité : déploiement, sauvegarde, disponibilité, authentification des workloads et gestion des droits. Il faut éviter de centraliser tous les secrets dans un système insuffisamment maîtrisé.

Pour beaucoup de petites applications, un fichier .env bien protégé, des permissions strictes, des sauvegardes chiffrées et une rotation documentée suffisent au départ. Le passage à un gestionnaire doit répondre à un besoin concret de contrôle, d’automatisation ou de conformité.

Maîtriser les logs et les enjeux RGPD

Un secret ne doit jamais apparaître dans les logs, même temporairement. Masquez les en-têtes d’autorisation, cookies, chaînes de connexion, paramètres sensibles et corps de requêtes contenant des identifiants. Utilisez des valeurs comme [MASQUE] plutôt que les premiers caractères du secret, qui peuvent parfois faciliter son identification.

Les données personnelles exigent la même prudence. Dans le cadre du RGPD, collectez uniquement les informations nécessaires, définissez une durée de conservation et contrôlez qui peut consulter les journaux. Les erreurs applicatives doivent fournir assez de contexte pour diagnostiquer un incident sans recopier les données envoyées par l’utilisateur.

L’infrastructure complète cette protection sans remplacer les pratiques applicatives. TalCloud héberge ses serveurs en France et accompagne les projets soumis aux exigences du RGPD, avec stockage NVMe, protection Anti-DDoS Netrix et support humain. Les offres VPS démarrent à 4,99 € par mois. Quel que soit l’hébergeur, la sécurité des secrets reste une responsabilité partagée entre l’infrastructure, le déploiement et le code. Elle prolonge naturellement les bonnes pratiques présentées dans notre guide pour sécuriser une API en production.

Checklist avant la mise en production

• Le fichier .env est ignoré par Git et absent de l’historique.
• Un .env.example documente les variables sans contenir de valeurs sensibles.
• Les fichiers de secrets disposent de permissions minimales, comme 600.
• Aucun secret ne figure dans le code, le Dockerfile, les arguments de build ou l’image.
• Les secrets sont injectés au runtime.
• Les logs masquent les tokens, mots de passe, cookies et données personnelles.
• Chaque service et chaque environnement utilise des identifiants distincts.
• Les comptes techniques appliquent le moindre privilège.
• Les secrets sont longs, aléatoires et générés avec un outil cryptographique.
• Une procédure de rotation et de révocation existe.
• Un secret poussé par erreur est immédiatement révoqué puis régénéré.
• Les dépôts et pipelines sont contrôlés par un scanner de secrets.
• Les accès, sauvegardes et durées de conservation sont régulièrement vérifiés.