Quelle est la meilleure solution pour gérer le mot de passe root de milliers de serveurs

Je suis administrateur système. Dans l'environnement de production, je dois gérer des milliers de serveurs. Mes collègues et moi utilisons un serveur de gestion central et distribuons sa clé publique via d'autres serveurs. Nous pouvons donc utiliser ce serveur de gestion pour passer à d'autres serveurs.

Parfois, nous devons utiliser le mot de passe root, par exemple lorsque le serveur est en panne, nous devons utiliser iLO pour déterminer la raison.

Actuellement, nous utilisons un mot de passe root partagé. C'est dangereux. J'ai également examiné une solution de serveur unique comme OPIE(Mots de passe à usage unique dans tout), mais comme nous avons tant de serveurs, ce n'est pas une très bonne idée.

ÉDITER:

Ce que je veux de la solution de gestion de mot de passe, c'est:

1. Il devrait être sûr, donc le mot de passe à usage unique est une excellente solution.
2. Le mot de passe peut être facilement entré, parfois nous devons attacher le moniteur au serveur, ou avec iLO comme je l'ai mentionné ci-dessus.
3. La solution devrait fonctionner même si le serveur est hors ligne (sans connexion réseau)

Ce n'est donc pas une très bonne idée de définir le mot de passe root sur une chaîne longue et aléatoire, bien qu'il soit généré à partir d'une commande connue (comme openssl passwd). C'est difficile à retenir, et parfois c'est difficile à générer (sans mon ordinateur portable)

Vous pouvez utiliser Puppet pour pousser le changement de mot de passe sur tous vos serveurs. Vous définiriez en rootutilisant le usertype comme ceci:

    user { 'root':
            ensure => present,
            password => '$1$blablah$blahblahblahblah',
    }

Pour générer le mot de passe crypté:

openssl passwd -1 -salt "blah"

Je suggérerais peut-être de le changer tous les mois environ - peut-être en utilisant un schéma que vos SA ont mémorisé. Vous pouvez également le distribuer via une méthode sécurisée ou le mettre dans un coffre-fort.

Vous pouvez toujours simplement définir un mot de passe désactivé. Cela empêcherait tout accès réseau à root, et si vous démarrez en mode utilisateur unique, la plupart des distributions démarreront directement sur un shell.

Ce n'est probablement pas un problème de sécurité aussi important que vous ne le pensez. Il est trivial de contourner le mot de passe root de toute façon, à moins que vous n'ayez verrouillé grub avec un mot de passe, à peu près n'importe qui pourrait simplement dire à grub de démarrer bash au lieu d'initrd.

Bien sûr, cela peut signifier que vous devriez plutôt trouver comment protéger par mot de passe votre chargeur de démarrage.

Vous pouvez utiliser des mots de passe à usage unique avec une gestion centrale. Je sais que cela ne convient pas à "doit fonctionner lorsque eth est hors ligne et que le serveur est accessible avec iLO".

Quoi qu'il en soit: la question est de savoir à quelle fréquence le serveur est hors ligne.

Vous pouvez donc penser à la configuration suivante:

Utilisez une solution OTP gérée de manière centralisée comme privacyidea ( http://www.privacyidea.org ). Vous pouvez attribuer plusieurs jetons OTP différents à l'utilisateur root. Chaque jeton a un code PIN OTP différent et est un appareil différent. Ainsi, tous vos collègues peuvent se connecter en tant qu'utilisateur root mais dans le journal d'audit, vous verrez quel jeton s'authentifier, afin que vous puissiez savoir quel collègue s'est connecté à quel moment.

Sur les serveurs, vous devez configurer pam_radius pour transmettre la demande d'authentification au RADIUS et au privacyIDEA.

Bummer. Maintenant, votre serveur est hors ligne. Dans ce cas, vous devez jouer avec votre pile de pam. Je pourrais penser à quelque chose comme:

auth sufficient pam_unix.so
auth required pam_radius.so use_first_pass

Pour que vous puissiez vous connecter avec un mot de passe fixe hors ligne, sinon le mot de passe est remis à pam_radius et est validé comme OTP contre privacyIDEA.

Voir ce howto https://www.howtoforge.com/manage-two-factor-authentication-in-your-serverfarm-with-privacyidea .