Avoir un système qui expire les clés SSH tous les 90 jours
J'ai un client qui nous oblige maintenant à changer chaque mot de passe tous les 90 jours en raison de son interprétation du RGPD. C'est très bien pour le système Web que nous développons pour eux, car nous pouvons simplement mettre en œuvre ces règles. Mais ils exigent également que nous changions les mots de passe sur nos clés SSH utilisées pour accéder aux serveurs, ce qui n'est pas très bien.
- Est-il possible de changer le mot de passe sur une clé SSH existante?
Sinon, existe-t-il des outils que nous pouvons utiliser pour gérer cela? Je pense:
une. Créez de nouvelles clés.
b. Distribuez toutes les clés publiques aux serveurs existants.
c. Supprimez les clés publiques existantes.
ré. Archivez les anciennes clés privées.J'ai lu ici quelques articles sur Puppet, mais si je comprends bien, ils visent uniquement à résoudre le problème de la distribution des clés publiques entre les serveurs et de ne pas créer de nouvelles clés tous les n jours. Dois-je aller plus loin dans mes recherches sur les marionnettes?
Quelle est la norme communautaire en matière de rétention de mot de passe et de clés ssh? Comment faites-vous?
Le client a tort ici et ne comprend pas de quoi il parle. Changer la phrase secrète d'une clé privée est une idée très mauvaise, car elle a des propriétés de sécurité très contre-intuitives.
Normalement, les utilisateurs pensent que les mots de passe qu'ils ont modifiés ne sont plus secrets. Ils peuvent devenir des mots de passe jetables pour des sites de faible valeur, des descripteurs/pseudonymes en ligne, des punchlines pour des blagues, etc., et tout papier sur lequel ils sont écrits peut devenir un rebut qui est exposé.
Pour une phrase secrète utilisée pour crypter une clé privée, ce n'est pas ainsi que cela fonctionne! La phrase secrète doit être gardée secrète pour toujours sauf si tous les privilèges associés à la clé ont été révoqués (et ce qui suit ne s'applique pas aux clés ssh, mais si la phrase secrète concerne une clé utilisée non seulement pour la signature, mais pour recevoir des messages privés, alors pour toujours signifie vraiment pour toujours). Cela est dû à la possibilité que le fichier de clé privée chiffrée ait été obtenu par un attaquant ou stocké quelque part (comme dans une sauvegarde) où il pourrait être obtenu par un attaquant à l'avenir. Si la phrase secrète est révélée, elle est alors compromise.
Dans un certain sens, une clé privée qui a traversé N phrases de passe au cours de sa vie est 1/N aussi sécurisée, car la connaissance de toute personne parmi les phrases de passe passées est suffisant pour compromettre la clé si l'attaquant a eu accès au fichier de clé privée chiffrée.
Maintenant, revenons à votre problème.
Si le client ne s'était pas accroché à cette idée fausse de "mots de passe ssh" et n'y avait pas creusé, la bonne chose à faire serait de ne jamais le leur faire comprendre et de suivre les meilleures pratiques pour la manipulation des clés vous-même. Mais maintenant qu'ils l'ont fait, vous devez probablement faire quelque chose pour les satisfaire. Vous pouvez essayer d'expliquer en quoi les phrases secrètes chiffrant les clés privées ont des propriétés de sécurité différentes des mots de passe, mais étant donné à quel point le client se trompe sur beaucoup de choses ici (l'expiration du mot de passe est une mauvaise idée en général), je doute que cela fonctionne.
Cela vous laisse la tâche d'automatiser un système de distribution de nouvelles clés. Je voudrais décourager fortement vous d'automatiser un système de génération centralisée des nouvelles clés, car les clés privées ne doivent jamais être déplacées entre machines. Au lieu de cela, vous devriez avoir des processus/rappels/scripts pour permettre aux employés/sous-traitants de votre côté qui ont besoin d'accéder à générer de nouvelles clés privées et à publier les clés publiques correspondantes, et à disposer du système de distribution de clés publiques (marionnette ou autre) qui vous utilisez Poussez-les vers les systèmes dont ils ont besoin pour accéder.
De plus: Une chose qui pourrait convaincre le client d'abandonner ceci est de mentionner qu'il n'y a fondamentalement aucun moyen de faire en sorte que la nouvelle clé privée ait une phrase de passe différente de l'ancienne, ou même qu'elle ait un mot de passe du tout.
La réponse à votre première question: "Est-il possible de changer le mot de passe sur une clé SSH existante?" est oui. Avec openssh c'est aussi simple que ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
Le problème est que le mot de passe est dans/sur le fichier de clé privée, qui est un format simple qui ne prend pas en charge une date d'expiration. De plus, une grande partie du concept d'authentification basée sur les clés dans ssh est que la clé privée n'est pas gérée de manière centralisée, elle ne devrait exister que sur le poste de travail de l'utilisateur, ce qui rend pratiquement impossible l'application d'une stratégie d'expiration de mot de passe sur la clé privée.
Au lieu de cela: dans tous les environnements dans lesquels je me suis rendu avant que la politique de mot de passe ne se trouve sur l'objet de compte d'utilisateur, pas sur la méthode utilisée pour accéder audit compte. Lorsqu'un mot de passe est expiré ou qu'un compte est verrouillé, toutes les méthodes d'accès sont verrouillées, y compris la clé ssh.
Ajoutez une authentification multifacteur lorsque vous avez besoin de plus de sécurité sur un compte.
Mais je suis curieux de savoir ce que d'autres personnes ont fait pour répondre à vos préoccupations valables.
En utilisant AuthorizedKeysCommand un mécanisme d'expiration pourrait être implémenté côté serveur. De la simple vérification de l'horodatage du fichier à quelque chose de plus compliqué.
Une possibilité qui peut ou non être suffisante est d'utiliser une autorité de certification utilisateur SSH, qui vous permet de définir une durée de vie sur la clé signée. Quelle que soit l'automatisation que vous mettez en place, la signature des clés peut refuser de signer pendant plus de 90 jours. Ensuite, ajoutez la clé publique de votre autorité de certification utilisateur à TrustedUserCAKeys dans/etc/ssh/sshd_config et définissez AuthorizedKeysFile sur none.
Vous pouvez utiliser un outil comme Hashicorp's Vault pour créer des clés SSH signées de courte durée . Chaque utilisateur obtiendrait une nouvelle clé chaque jour (ou ainsi). Vous vous authentifieriez auprès de Vault pour obtenir le certificat en utilisant tout ce que vous utilisez aujourd'hui, comme un serveur LDAP.
L'effort de mise en place n'est pas immense, mais selon mon expérience, plus grand que ce à quoi @Mark a fait référence dans son commentaire. Vous remplacez essentiellement un problème (exigences du client désemparées) par un autre ( gestion des partitions ).
Mais cela permet quelques autres scénarios comme la génération facile de certificats X509 internes et la gestion des mots de passe de base de données, les secrets d'application dans un fichier texte. Vous jugez l'effort et le retour sur investissement.
Notez également que la version open source n'a pas de capacités DR (elle a tout le reste).
Vous pouvez utiliser un agent clé qui incorpore des mots de passe à usage unique basés sur le temps (TOTP). Maintenant, votre "mot de passe" change chaque minute.
Cependant, tout le monde ici a raison: c'est idiot.