Est-il sûr de stocker des mots de passe critiques dans des variables d'environnement de serveur?

23

J'ai un cluster de serveurs, chacun avec des fichiers de configuration qui contiennent actuellement des mots de passe en texte brut pour les systèmes sensibles et critiques (files d'attente de messages, magasins de données et autres services).

Certaines personnes déplacent les mots de passe critiques des fichiers de configuration vers une variable d'environnement des comptes d'utilisateurs sous lesquels s'exécutent les processus serveur. De cette façon, les fichiers de configuration peuvent être validés pour le contrôle de version et l'administrateur système n'a besoin de créer une variable d'environnement appropriée que lorsque le système serveur est configuré. Naturellement, l'accès aux comptes qui gèrent ces services est très restreint.

Est-ce vraiment la meilleure façon d'éviter les mots de passe dans les fichiers de configuration en texte brut, ou existe-t-il une meilleure façon?

passwords environment-variables Steve HHH
la source
3
eh bien, gardez à l'esprit que si vous la stockez en tant que variable, elle est en texte brut à la fois au repos et lorsqu'un utilisateur l'interroge. cela signifie que si vous perdez un peu le contrôle du niveau serveur, vous avez remis un mot de passe à l'attaquant. J'utiliserais probablement la cryptographie et décrypterais les informations de mot de passe si nécessaire.
Frank Thomas
Bonnes pensées, Frank. Si vous deviez utiliser la cryptographie, quel type de système utiliseriez-vous? Quelque chose basé sur une clé RSA / SSH, un outil de trousseau ou autre chose? Nous utilisons actuellement des systèmes Linux> 2.6 comme CentOS et Amazon.
Steve HHH

Réponses:

11

Si vous êtes sur un système Linux, regardez / proc / * / environ et décidez si les variables d'environnement sont un bon endroit pour stocker des informations sensibles ou non. / proc / self est le processus actuel:

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

Peu importe que la chose qui définit la variable d'environnement soit probablement en train de lire un fichier quelque part.

La chose à retenir est que l'utilisation d'un mot de passe signifie que le mot de passe est disponible pour le programme. Si ce mot de passe n'est pas fourni par un utilisateur qui le tape à chaque fois qu'un programme en a besoin, ce mot de passe doit être accessible en fonction uniquement de l'accès au programme. Vous pouvez crypter le mot de passe localement et faire décrypter le programme à l'aide d'une clé, mais tout ce que cela fait est de masquer le mot de passe contre une divulgation accidentelle; quelqu'un qui a le même accès que le programme peut faire les mêmes choses que le programme, ce qui inclut la lecture de la clé de chiffrement.

La bonne façon de procéder consiste à exécuter l'application en tant que compte restreint et à stocker le mot de passe dans un fichier protégé par des autorisations au niveau du système de fichiers. J'espère que vous pouvez «inclure» un fichier ou similaire afin de garder le mot de passe hors d'un système de contrôle de version (en supposant que le VCS n'a pas de contrôle de sécurité). Pour vous protéger contre la divulgation par inadvertance, masquez le mot de passe comme vous le souhaitez - encodez en base64, utilisez pgp pour crypter, tout ce qui a du sens dans l'ensemble d'options de votre programme serveur. Si vous écrivez un programme pour ce faire, le mieux que vous puissiez faire est de demander à un utilisateur le mot de passe uniquement lorsque cela est nécessaire, puis de purger ce mot de passe de la mémoire dès qu'il est utilisé.

dannysauer
la source
2
Pour les versions récentes de Linux, les variables d'environnement sont probablement aussi sécurisées que les fichiers .
Kenny Evitt
3
Oui, un fichier avec le mode 0600 appartenant à l'utilisateur exécutant le programme est accessible aux mêmes personnes qui peuvent accéder à l'environnement du programme. Mais, comme je l'ai mentionné, l'environnement est probablement configuré en lisant un fichier, donc la copie de données dans l'environnement augmente simplement le nombre de places disponibles. Et l'environnement est, par défaut, dupliqué sur les processus enfants. Et un certain nombre de programmes ont des moyens externes pour interroger les variables d'environnement, en raison de bogues ou de décisions de conception intentionnelles (pensez à phpinfo ()). Si un fichier est impliqué d'une manière ou d'une autre, pourquoi augmenter la surface d'attaque?
dannysauer
1
La commande tr que vous avez donnée n'a pas fonctionné pour moi - c'est le cas:cat /proc/self/environ | tr '\0' '\n'
robocat
Je suis dans mon téléphone, donc c'est difficile à dire ... Ça devrait être un zéro; avez-vous tapé la lettre "o"?
dannysauer
8

En fin de compte, si vous avez des données à lire et à écrire , vous allez finir par protéger quelque chose avec un mot de passe (ou si vous êtes vraiment paranoïaque, avec une carte à puce matérielle physique et un code PIN), non quel que soit le nombre de couches de cryptage dont vous disposez.

Cela se résume à la question fondamentale de la sécurité du système par rapport à la commodité. Vous pouvez ajouter une "défense en profondeur" en ayant beaucoup, beaucoup de couches de contrôles de sécurité qu'un acteur malveillant devrait violer pour accéder aux "marchandises", mais quand un acteur légitime veut lire ou modifier certaines données, ils doivent passer par un tas de cerceaux. L'alternative est les mots de passe en texte brut dans les fichiers texte.

Que ferais-je si je voulais vraiment protéger certaines informations dans un système critique:

  1. Utilisez Full Disk Encryption pour que le contenu de l'ensemble du stockage persistant soit crypté.

  2. Limitez l'accès physique aux machines. Verrouillez le châssis de la machine avec un mécanisme de verrouillage sécurisé et contrôlez l'accès physique aux clés. Embaucher des muscles (gardes armés) pour être des gardiens d'accès.

  3. Appliquez le contrôle d'accès obligatoire (MAC) à granularité fine dans le système d'exploitation de l'appareil. Vous pouvez commencer avec quelque chose comme SELinux sur GNU / Linux et le définir sur Enforcing, puis adapter la politique aux besoins exacts du logiciel de production, en accordant à ces comptes exactement (et uniquement) les autorisations dont ils ont besoin pour les fichiers dont ils ont besoin.

  4. Si vous allez avoir des mots de passe spécifiques au système et un contrôle de version pour les fichiers de configuration, vous voulez vraiment éviter l'erreur possible d'avoir un mot de passe en texte brut commis par erreur dans le contrôle de version, car il peut être difficile de déloger un mot de passe divulgué d'un Cache de VCS. Les variables d'environnement sont l'une des nombreuses options viables pour cela. L'autre est une invite de mot de passe au démarrage du programme, mais redémarrer la machine et restaurer l'état opérationnel est un effort manuel et ne peut pas être fait de manière autonome, il y a donc à nouveau cette commodité contre la sécurité.

  5. Assurez-vous d'avoir des spécialistes en réseau à portée de main pour s'occuper des autorisations de pare-feu, afin de minimiser votre exposition à une attaque sur le réseau. Auditez (test de pénétration et test en boîte blanche le code) tout logiciel qui s'interface avec des systèmes externes, en particulier l'Internet public. "Interfaces" comprend non seulement les connexions réseau directes, mais également la lecture ou l'écriture de données "non fiables" (données dont les octets proviennent de l'extérieur de la RAM / disque / CPU du serveur sécurisé).

Ce n'est pas une liste complète, mais surtout le point 4 est probablement pertinent pour vous, bien que si vous n'effectuez pas au moins les étapes 1 à 3, l'examen des points 4 et 5 ne vous aidera pas beaucoup, car votre Le système n'est pas sécurisé à un niveau assez fondamental.

allquixotic
la source
Je sauterais # 1. Si le système est en cours d'exécution, le système de fichiers est monté et non chiffré. S'il ne fonctionne pas, votre contrôle d'accès physique doit être adéquat. S'il doit être redémarré, vous avez besoin de quelqu'un pour fournir la clé de déchiffrement à chaque démarrage (ce qui est ennuyeux), ou vous devez demander à la machine de le fournir - dans ce cas, les informations d'identification sont généralement également disponibles pour toute personne ayant accès au disque dur. . La plupart des machines "serveur" n'utilisent généralement pas le chiffrement de disque en raison de ce coût de compromis. :)
dannysauer
"Cela se résume à la question fondamentale de la sécurité du système par rapport à la commodité" - cité dans ma réponse - qui s'applique également à votre commentaire. Vous ne pouvez pas maximiser la sécurité et la commodité en même temps.
allquixotic
1
# 1 est important dans le cas où une partie du bélier frappe le disque (échange) ou s'il frappe un secteur ssd qui devient "mauvais" plus tard et s'éloigne du système d'exploitation mais tient toujours ce morceau de bélier. même lorsque le disque est actuellement déverrouillé, ce bloc de données finit par être brouillé sur les plateaux.
akira
3

Passer un mot de passe dans une variable d'environnement est aussi sûr que de le lire dans un fichier. Seuls les processus exécutés sous le même utilisateur peuvent lire l'environnement d'un processus , et ces processus sont autorisés à lire les mêmes fichiers de toute façon.

Notez que cela est différent de la transmission d'un mot de passe sur la ligne de commande. Les arguments de ligne de commande sont lisibles par tous les processus s'exécutant sur la même machine (sauf mesures de renforcement), et pas seulement par les processus s'exécutant sous le même utilisateur.

Si vous passez une variable dans l'environnement, faites attention si le programme lance d'autres programmes. Ces autres programmes hériteront de l'environnement de leurs parents. Ne faites donc pas cela si vous craignez que les autres programmes ne divulguent accidentellement le contenu de leur environnement.

La faille dans votre scénario est «créer une variable d'environnement appropriée lorsque le système serveur est configuré». Une variable d'environnement est une propriété dynamique d'un processus. Vous ne pouvez pas le créer lors de la configuration d'un système, pas si en configurant vous voulez dire quelque chose qui survit à un redémarrage. Ce que vous voulez dire, c'est probablement que l'administrateur s'est arrangé pour que cette variable soit présente dans l'environnement lorsqu'un certain utilisateur se connecte. Cela se fait via un fichier de configuration (généralement ~/.pam_environmentou ~/.profileou un fichier lu ~/.profile). Cette solution ne supprime donc pas le mot de passe des fichiers de configuration.

Configurer les choses pour que les mots de passe soient dans l'environnement de connexion d'un utilisateur n'est pas une bonne idée. Cela signifie que chaque processus exécuté en tant qu'utilisateur aura le secret, il est donc vulnérable à une fuite n'importe où.

Un mot de passe doit être placé dans un fichier distinct des fichiers de configuration qui sont sous contrôle de version et des mécanismes de déploiement normaux. Il est correct de mettre le mot de passe dans l'environnement à un moment donné si cela vous convient, mais cela devrait être fait pour un ensemble de programmes aussi petit que possible.

Gilles 'SO- arrête d'être méchant'
la source