Existe-t-il un moyen sûr de stocker les mots de passe utilisés pour ssh par un script?

Donc, d'abord, je sais, je devrais utiliser l'authentification par clé avec SSH. Pas besoin de m'expliquer ça.

Le problème ici est que j'ai un (gros) groupe de serveurs, et j'ai besoin d'un script pour pouvoir connecter chacun d'eux.

J'utilise une authentification par clé chaque fois que je le peux, mais ce n'est pas possible sur tous les serveurs (je n'ai aucun contrôle sur cela). Donc SSH avec login, ou parfois telnet.

Donc, pour certains, je viens de stocker les mots de passe dans une base de données, et mon script va les prendre en cas de besoin. Le problème est qu'il ne semble pas vraiment sûr de le faire de cette façon. Existe-t-il un moyen de le rendre un peu plus sûr?

Vous aimez un moyen spécifique de le stocker?

Si votre script peut se connecter à l'un de ces serveurs, toute personne ayant accès au script (ou un accès privilégié à la machine sur laquelle le script s'exécute) peut se connecter à l'un de ces serveurs.

Si le script doit s'exécuter de manière autonome, tous les paris sont désactivés. La réponse est non, il n'y a pas de moyen absolument sûr de stocker les mots de passe dans un tel environnement . Il n'y a aucun moyen absolument sûr et pratique de faire quoi que ce soit.

Au lieu d'essayer d'éviter l'inévitable, vous devriez vous concentrer sur la défense en profondeur .

Bien sûr, vous devez bien sûr protéger les mots de passe de manière adéquate . Cela signifie généralement de les conserver dans un fichier distinct de votre script et de configurer des autorisations de système de fichiers restrictives . C'est à peu près tout ce que vous pouvez faire sur ce front, du point de vue de la sécurité.

D'autres mesures peuvent très certainement ajouter de l' obscurité au processus. Le chiffrement des mots de passe obligera l'attaquant à rechercher la clé de déchiffrement. L'utilisation d'une sorte de stockage protégé par le système d'exploitation protège généralement contre les autres utilisateurs accédant à votre clé (il n'offre donc aucun avantage sur les autorisations du système de fichiers, autre que d'être complexe à attaquer - et à utiliser). Ces mesures retarderont une attaque, mais ne l'empêcheront certainement pas contre un attaquant déterminé.

Maintenant, considérons les mots de passe comme publics pendant un moment. Que pouvez-vous faire pour atténuer les dommages?

Une solution ancienne et testée consiste à restreindre ce que ces informations d'identification peuvent faire. Sur un système UNIX, une bonne façon de procéder consiste à configurer un utilisateur distinct pour votre script et à limiter les capacités de cet utilisateur , à la fois sur les serveurs d'accès et sur les serveurs auxquels vous avez accédé. Vous pouvez limiter les capacités des utilisateurs au niveau SSH, au niveau du shell ou éventuellement en utilisant un mécanisme de contrôle d'accès obligatoire comme SELinux .

Vous pouvez également envisager de déplacer la logique de script dans les serveurs . De cette façon, vous obtenez une interface plus petite qui est plus facile à contrôler, et surtout à ...

Moniteur . Surveillez toujours l'accès aux serveurs. De préférence, authentification du journal et commandes exécutées dans un journal d’ajout uniquement . N'oubliez pas de surveiller les modifications du fichier de script à l'aide auditd, par exemple.

Bien sûr, beaucoup de ces mécanismes ne sont pas utiles si vous n'avez aucun contrôle sur les serveurs, comme votre question semble impliquer. Si tel est le cas, je vous conseille de prendre contact avec les personnes administrant les serveurs et de leur faire connaître votre script et les pièges de sécurité potentiels.

La réponse courte est non.

La réponse longue est: non, il n'y a pas de moyen complètement sûr. (Cela inclut les variables d'environnement, qui peuvent être consultées par d'autres sur le serveur.) Le plus proche que vous pouvez obtenir est de les stocker dans un format crypté - keepass, un fichier crypté GPG ou autre chose dans ce sens. Mais à un moment donné, vous devez décrypter le mot de passe pour que votre script puisse l'utiliser, et à ce stade, vous serez vulnérable.

En d'autres termes, vous devez vous pencher longuement sur la sécurité approfondie, à la fois sur le serveur à partir duquel le script est exécuté, sur le réseau et sur les serveurs cibles.

Vous pouvez crypter les mots de passe dans votre base de données avec un deuxième mot de passe et stocker ce mot de passe sur une machine distincte (3e) et avoir un système en place où le script qui doit sortir les mots de passe de la base de données connecte d'abord cette 3e machine pour obtenir le mot de passe de décryptage , déchiffre le mot de passe dans la base de données avec le mot de passe qu'il a obtenu de la 3ème machine et ça marche.

Bien sûr, cela n'ajoute pas vraiment de sécurité supplémentaire, un attaquant disposant de privilèges suffisants pourrait également simplement demander le mot de passe à la 3e machine.

Mais le fait est qu'un tiers peut contrôler la 3e machine, par exemple votre patron ou responsable de la sécurité, ou le tiers contrôlant les serveurs que vous ne contrôlez pas.

De cette façon, vous pouvez leur dire, s'ils ont un problème, si vous quittez votre travail et qu'ils ne font pas confiance au gars qui vous remplace, ou s'ils veulent juste que vos scripts cessent d'accéder à leurs machines, ils peuvent débrancher le 3 l'ordinateur et vos scripts n'auront plus accès aux mots de passe.