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 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 comme variables d'environnement plutôt que du texte brut dans certains fichiers de configuration (ou dans settings.py, pour Django apps).
En discutant de cela avec l'un de mes collaborateurs, il a suggéré qu'il s'agissait d'une mauvaise pratique - que ce n'était peut-être pas aussi parfaitement sécurisé qu'il pourrait le paraître à première vue.
Donc, je voudrais savoir - est-ce une pratique sûre? Est-il plus sûr de stocker les mots de passe en 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)?
À un niveau 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 obscurcissement. Vous stockez les données (texte en clair) quelque part délicat, comme une variable d'environnement, ou dans un fichier qui doit ressembler à un fichier de configuration. Un attaquant finira par comprendre ce qui se passe ou tombera dessus.
- Sécurité assurée par un cryptage banal à briser (pensez au chiffre César!).
- Sécurité fournie par le cryptage qui peut être brisée avec un certain effort.
- Sécurité fournie par le chiffrement qui n'est pas pratique pour briser le matériel actuel.
- Le système le plus sécurisé 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, non enregistrées; c'est-à-dire si vous définissez uniquement une variable d'environnement locale, comme "set pwd = que ce soit", puis exécutez le script, avec quelque chose qui quitte votre commande Shell à la fin du script, alors la variable n'existe plus. Votre cas tombe dans les deux premiers, ce qui, je dirais, est assez précaire. Si vous deviez faire cela, je ne recommanderais pas le déploiement 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 n'offrent aucune couche de "sécurité" supplémentaire une fois que votre système est compromis. Je crois que l'une des principales raisons 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., accidentellement stockées dans le système de contrôle de version comme GIT pour que tous les autres développeurs puissent les voir (et oups! ça m'est aussi arrivé ...).
Ne pas stocker vos mots de passe dans des fichiers, il est impossible pour eux d'être stockés dans le système de contrôle de version.
Chaque fois que vous devez enregistrer un mot de passe, il n'est pas sécurisé. Période. Il n'y a aucun moyen de stocker un mot de passe non crypté en toute sécurité. Maintenant, laquelle des variables d'environnement par rapport aux fichiers de configuration est 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'ai pas eu suffisamment de représentants pour commenter, mais je voulais également ajouter que si vous ne faites pas attention, votre shell peut également capturer ce mot de passe dans l'historique de ses commandes. Donc, exécuter quelque chose comme $ pwd=mypassword my_prog manuellement n'est pas aussi éphémère que vous auriez pu l'espérer.
Cela dépend de votre modèle de menace.
Essayez-vous d'empêcher vos utilisateurs de saupoudrer des mots de passe sur tous leurs systèmes de fichiers où ils sont susceptibles d'être oubliés et mal gérés? Si oui, 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 c'est le cas, alors 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 des variables d'environnement.
Je pense que si possible, vous devez stocker vos informations d'identification dans un fichier gitignored et non en tant que variables d'environnement.
L'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 de manière malveillante ou non. Par exemple, un auteur de bibliothèque peut envoyer par e-mail des traces de pile ainsi que les variables ENV pour le débogage (ce n'est pas la meilleure pratique, mais c'est possible).
Si vos informations d'identification sont 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 ENV, c'est une simple question de process.ENV. Si d'un autre côté, 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 la version ou non est une question distincte. Aucune version contrôlant votre fichier d'informations d'identification ne l'expose à moins de personnes. Il n'est pas nécessaire que tous les développeurs connaissent les informations d'identification de production. Étant donné que cela respecte le principe du moindre privilège, je suggère que git ignore votre fichier d'informations d'identification.