Est-il sûr de stocker les mots de passe en tant que variables d'environnement (plutôt qu'en texte brut) dans les fichiers de configuration?

Je travaille sur quelques applications dans les rails, django (et un peu de php), et l'une des choses que j'ai commencé à faire dans certaines d'entre elles est de stocker la base de données et d'autres mots de passe en tant que variables d'environnement plutôt que du texte brut dans certains fichiers de configuration ( ou dans settings.py, pour les applications django).

En discutant de cela avec l'un de mes collaborateurs, il a suggéré que c'était une mauvaise pratique - que ce n'est peut-être pas aussi parfaitement sûr que cela puisse paraître à première vue.

Alors, j'aimerais savoir - est-ce une pratique sûre? Est-il plus sûr de stocker les mots de passe sous forme de texte brut dans ces fichiers (en veillant bien sûr à ne pas laisser ces fichiers dans des dépôts publics ou quoi que ce soit)?

Sur un plan plus théorique, j'ai tendance à penser aux niveaux de sécurité de la manière suivante (par ordre croissant de force):

• Pas de sécurité. Texte brut. Quiconque sait où chercher peut accéder aux données.
• Sécurité par obfuscation. Vous stockez les données (texte brut) à un endroit délicat, comme une variable d'environnement, ou dans un fichier censé ressembler à un fichier de configuration. Un attaquant finira par comprendre ce qui se passe ou tombera dessus.
• Sécurité fournie par un cryptage facile à briser (pensez au chiffrement césar!).
• Sécurité fournie par un cryptage qui peut être rompu avec quelques efforts.
• Sécurité fournie par un cryptage qui n'est pas pratique pour casser le matériel actuel.
• Le système le plus sûr est celui que personne ne peut utiliser! :)

Les variables d'environnement sont plus sécurisées que les fichiers en clair, car elles sont volatiles / jetables et non enregistrées; c'est-à-dire que si vous définissez uniquement une variable d'environnement locale, comme "set pwd = peu importe", puis exécutez le script, avec quelque chose qui quitte votre shell de commande à la fin du script, alors la variable n'existe plus. Votre cas tombe dans les deux premiers, qui, je dirais, sont assez peu sûrs. Si vous deviez faire cela, je ne recommanderais pas de déployer en dehors de votre réseau intranet / domestique immédiat, et uniquement à des fins de test.

Comme mentionné précédemment, les deux méthodes ne fournissent aucune couche de «sécurité» supplémentaire une fois que votre système est compromis. Je crois que l'une des raisons les plus fortes de favoriser les variables d'environnement est le contrôle de version : j'ai vu beaucoup trop de configurations de base de données, etc. être accidentellement stockées dans le système de contrôle de version comme GIT pour que tous les autres développeurs puissent le voir (et oups! moi aussi ...).

Ne pas stocker vos mots de passe dans des fichiers rend impossible leur stockage dans le système de contrôle de version.

Chaque fois que vous devez stocker un mot de passe, celui-ci n'est pas sécurisé. Période. Il n'y a aucun moyen de stocker un mot de passe non chiffré en toute sécurité. Maintenant, quelle variable d'environnement par rapport aux fichiers de configuration est la plus "sécurisée" est peut-être discutable. À mon humble avis, si votre système est compromis, peu importe où il est stocké, un pirate informatique diligent peut le retrouver.

Désolé, je n'avais pas assez de représentants pour commenter, mais je voulais également ajouter que si vous ne faites pas attention, votre shell pourrait également capturer ce mot de passe dans son historique des commandes. Donc, exécuter quelque chose comme $ pwd=mypassword my_progmanuellement n'est pas aussi éphémère que vous auriez pu l'espérer.

Je pense que lorsque cela est possible, vous devez stocker vos informations d'identification dans un fichier gitignored et non en tant que variables d'environnement.

Une des choses à considérer lors du stockage des informations d'identification dans des variables ENV (environnement) par rapport à un fichier est que les variables ENV peuvent très facilement être inspectées par n'importe quelle bibliothèque ou dépendance que vous utilisez.

Cela peut être fait par malveillance ou non. Par exemple, un auteur de bibliothèque pourrait envoyer des traces de pile ainsi que les variables ENV à lui-même pour le débogage (ce n'est pas la meilleure pratique, mais c'est possible).

Si vos informations d'identification se trouvent dans un fichier, il est beaucoup plus difficile de les atteindre.

Plus précisément, pensez à un npm dans le nœud. Pour qu'un npm regarde vos informations d'identification si elles sont dans l'ENV est une simple question de process.ENV. Si par contre ils sont dans un fichier, c'est beaucoup plus de travail.

La question de savoir si votre fichier d'informations d'identification est contrôlé par version ou non est une question distincte. Le fait de ne pas contrôler la version de votre fichier d'informations d'identification l'expose à moins de personnes. Il n'est pas nécessaire que tous les développeurs connaissent les informations d'identification de production. Puisque cela respecte le principe du moindre privilège, je suggérerais que git ignore votre fichier d'informations d'identification.

Cela dépend de votre modèle de menace.

Essayez-vous d'empêcher vos utilisateurs de répandre des mots de passe sur tous leurs systèmes de fichiers où ils risquent d'être oubliés et mal gérés? Si tel est le cas, alors oui, car les variables d'environnement sont moins persistantes que les fichiers.

Essayez-vous de vous protéger contre quelque chose de malveillant qui cible directement votre programme? Si tel est le cas, non, car les variables d'environnement n'ont pas le même niveau de contrôle d'accès que les fichiers.

Personnellement, je pense que les utilisateurs négligents sont plus fréquents que les adversaires motivés, alors j'opterais pour l'approche variable d'environnement.

AFAICT, il y a deux raisons pour lesquelles les gens recommandent de stocker des secrets dans des variables d'environnement:

1. Il est trop facile de valider par inadvertance des fichiers plats secrets dans un dépôt. (Et s'il s'agit d'un dépôt public, vous portez un toast.)
2. Cela empêche l'encombrement des mots de passe, c'est-à-dire que le fait d'avoir la même clé dans de nombreux fichiers de répertoire de projet différents est en soi un risque de sécurité car les développeurs finiront par perdre la trace de l'emplacement des secrets.

Ces deux problèmes peuvent être mieux résolus. Le premier devrait être résolu par un hook de validation git qui vérifie les choses qui ressemblent à des mots de passe (par exemple, gitleaks ). J'aimerais que Linus intègre un tel outil dans le code source de la bibliothèque git mais, hélas, cela ne s'est pas produit. (Inutile de dire que les fichiers secrets doivent toujours être ajoutés .gitignore, mais vous avez besoin d'un crochet au cas où quelqu'un oublierait de le faire.)

Ce dernier peut être résolu en ayant un fichier de secrets d'entreprise mondial, qui est idéalement stocké sur un lecteur partagé en lecture seule. Donc, en Python, vous pourriez avoir quelque chose comme from company_secrets import *.

Plus important encore, comme l'ont souligné d'autres, il est beaucoup trop facile de pirater des secrets stockés dans des variables d'environnement. Par exemple, en Python, un auteur de bibliothèque pourrait insérer send_email(address="[email protected]", text=json.dumps(os.environ)), puis vous êtes grillé si vous exécutez ce code. Le piratage est beaucoup plus difficile si vous avez un fichier sur votre système appelé ~/secret_company_stuff/.my_very_secret_company_stuff.

Utilisateurs de Django uniquement:
Django (en mode DEBUG) affiche la valeur brute d'une variable d'environnement dans le navigateur s'il y a une exception (en mode DEBUG). Cela semble très peu sûr si, par exemple, un développeur se met accidentellement DEBUG=Trueen production. En revanche, Django DOES paramètres de mot de passe Occultation des variables en recherchant les chaînes API, TOKEN, KEY, SECRET, PASSou SIGNATUREdans le cadre des settings.pynoms de variables de fichier.