TL; DR
Il existe un certain nombre de raisons pour utiliser des variables d'environnement au lieu de fichiers de configuration, mais deux des plus courantes à ignorer sont la valeur utilitaire de la configuration hors bande et la séparation améliorée entre les serveurs, les applications ou les rôles organisationnels. Plutôt que de présenter une liste exhaustive de toutes les raisons possibles, j'aborde uniquement ces deux sujets dans ma réponse, et j'aborde légèrement leurs implications en matière de sécurité.
Configuration hors bande: séparation des secrets du code source
Si vous stockez tous vos secrets dans un fichier de configuration, vous devez distribuer ces secrets à chaque serveur. Cela signifie soit vérifier les secrets dans le contrôle de révision avec votre code, soit disposer d'un référentiel ou d'un mécanisme de distribution entièrement séparé pour les secrets.
Crypter vos secrets n'aide pas vraiment à résoudre ce problème. Tout ce que cela fait, c'est de supprimer le problème, car vous devez maintenant vous soucier également de la gestion et de la distribution des clés!
En bref, les variables d'environnement sont une approche pour déplacer des données par serveur ou par application hors du code source lorsque vous souhaitez séparer le développement des opérations. Ceci est particulièrement important si vous avez publié du code source!
Améliorez la séparation: serveurs, applications et rôles
Bien que vous puissiez certainement avoir un fichier de configuration pour conserver vos secrets, si vous stockez les secrets dans le code source, vous avez un problème de spécificité. Avez-vous une branche ou un référentiel distinct pour chaque ensemble de secrets? Comment vous assurez-vous que le bon ensemble de secrets parvient aux bons serveurs? Ou réduisez-vous la sécurité en ayant des «secrets» qui sont les mêmes partout (ou lisibles partout, si vous les avez tous dans un seul fichier), et constituent donc un plus grand risque si les contrôles de sécurité d'un système échouent?
Si vous voulez avoir des secrets uniques sur chaque serveur, ou pour chaque application, les variables d'environnement éliminent le problème d'avoir à gérer une multitude de fichiers. Si vous ajoutez un nouveau serveur, une nouvelle application ou un nouveau rôle, vous n'avez pas besoin de créer de nouveaux fichiers ou de mettre à jour d'anciens: vous mettez simplement à jour l'environnement du système en question.
Réflexions sur la sécurité
Bien qu'une exploration approfondie de la sécurité noyau / mémoire / fichier soit hors de portée pour cette réponse, il convient de souligner que les variables d'environnement par système correctement implémentées ne sont pas moins sécurisées que les secrets "chiffrés". Dans les deux cas, le système cible doit encore conserver le secret déchiffré en mémoire à un moment donné pour l'utiliser.
Il convient également de souligner que lorsque des valeurs sont stockées dans une mémoire volatile sur un nœud donné, aucun fichier sur disque ne peut être copié et attaqué hors ligne. Ceci est généralement considéré comme un avantage pour les secrets en mémoire, mais ce n'est certainement pas concluant.
Le problème des variables d'environnement par rapport aux autres techniques de gestion des secrets concerne davantage les compromis de sécurité et d'utilisabilité que les absolus. Votre kilométrage peut varier.