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

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, les jeux sont faits. La réponse ici est non, il n'y a pas de moyen absolument sûr de stocker des mots de passe dans un tel environnement . Il n'y a pas de sécurité absolue y moyen 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. .

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

D'autres mesures peuvent très certainement ajouter obscurité au processus. En chiffrant les mots de passe, l'attaquant devra chercher 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 autres utilisateurs accéder à votre clé (elle ne présente donc aucun avantage par rapport aux autorisations du système de fichiers, si ce n'est qu'elle est complexe à attaquer - et à utiliser). Ces mesures retarder une attaque, mais certainement pas l'empêcher contre un attaquant déterminé.

Maintenant. traiter les mots de passe comme publics pendant un moment. Que pouvez-vous faire pour limiter les dégâts ?

Une solution ancienne et éprouvée consiste à restreindre ce que ces informations d'identification peuvent faire. Sur un système UNIX, un bon moyen de le faire est de configurer un utilisateur séparé pour votre script et limiter les capacités de cet utilisateur tant sur le serveur accédant que sur le serveur accédé. Vous pouvez limiter les capacités des utilisateurs au niveau de SSH sur le 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 script dans les serveurs . Ainsi, vous obtenez une interface plus petite et plus facile à contrôler, et surtout à...

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

Bien entendu, nombre de ces mécanismes ne sont pas utiles si vous n'avez aucun contrôle sur les serveurs, comme votre question semble l'impliquer. Si c'est le cas, je vous conseille de entrer en contact avec les personnes qui administrent les serveurs et 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 totalement sûr. (Cela inclut les variables d'environnement, qui peuvent être consultées par d'autres personnes sur le serveur). Le mieux que vous puissiez faire est de les stocker dans un format crypté - keepass, un fichier crypté par GPG, ou quelque chose de ce genre. Mais à un moment donné, vous devrez décrypter le mot de passe pour que votre script puisse l'utiliser, et à ce moment-là, vous serez vulnérable.

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

Vous pourriez crypter les mots de passe dans votre base de données avec un second mot de passe et stocker ce mot de passe sur une (3ème) machine séparée et avoir un système en place où le script qui a besoin de mots de passe de la base de données se connecte d'abord à cette 3ème machine pour obtenir le mot de passe de décryptage, décrypte 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 fait son travail.

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

Mais le fait est qu'une tierce partie pourrait contrôler la troisième machine, par exemple votre patron ou votre responsable de la sécurité, ou la tierce partie qui contrôle les serveurs que vous ne contrôlez pas.

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