Quelles sont les meilleures pratiques pour gérer les clés SSH dans une équipe?

Je travaille avec de petites équipes (<10) de développeurs et d’administrateurs ayant les caractéristiques suivantes:

• La plupart des membres de l’équipe ont> 1 ordinateur personnel, dont la plupart sont portables
• Les membres de l'équipe ont accès à 10 à 50 serveurs, généralement avec sudo

Je pense que cela est assez typique pour la plupart des startups et des groupes informatiques de taille moyenne.

Quelles sont les meilleures pratiques pour gérer les clés SSH dans une telle équipe?

Devez-vous partager une clé unique pour toute l’équipe?

Chaque personne devrait-elle avoir sa propre clé sur un compte partagé ("Ubuntu" sur chaque serveur)?

Comptes séparés?

Chaque membre de l'équipe doit-il conserver une clé distincte pour chacun de ses ordinateurs portables ou de bureau?

Dans mon entreprise, nous utilisons LDAP pour créer un ensemble de comptes cohérent sur toutes les machines, puis nous utilisons un outil de gestion de la configuration (dans notre cas, cfengine) pour distribuer les authorized_keysfichiers de chaque utilisateur sur tous les serveurs. Les fichiers de clés eux-mêmes sont conservés (avec d'autres informations de configuration du système) dans un référentiel git afin que nous puissions voir quand les clés vont et viennent. cfengine distribue également un sudoersfichier qui contrôle les utilisateurs autorisés à exécuter quoi en tant qu’utilisateur root sur chaque hôte, à l’aide des utilisateurs et des groupes du répertoire LDAP.

L'authentification par mot de passe est complètement désactivée sur nos serveurs de production. L'authentification de clé SSH est donc obligatoire. La stratégie encourage l'utilisation d'une clé distincte pour chaque ordinateur portable / ordinateur de bureau / quoi que ce soit, ainsi que l'utilisation d'une phrase secrète sur toutes les clés pour réduire l'impact d'un ordinateur portable perdu / volé.

Nous avons également un hôte bastion utilisé pour accéder aux hôtes du réseau de production, ce qui nous permet d’avoir des règles de pare-feu très restrictives autour de ce réseau. La plupart des ingénieurs ont une configuration SSH spéciale pour rendre cela transparent:

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

Ajouter une nouvelle clé ou en supprimer une ancienne nécessite un peu de cérémonie dans cette configuration. Je dirais que pour ajouter une nouvelle clé, il est souhaitable que ce soit une opération qui laisse une trace d'audit et qui soit visible pour tout le monde. Cependant, en raison des frais généraux impliqués, je pense que les gens négligent parfois de retirer une ancienne clé lorsqu'elle n'est plus nécessaire et nous n'avons aucun moyen réel de le suivre, si ce n'est de nettoyer lorsqu'un employé quitte l'entreprise. Cela crée également des frictions supplémentaires lors de l'intégration d'un nouvel ingénieur, qui doit générer une nouvelle clé et la transmettre à tous les hôtes avant qu'ils ne puissent être complètement productifs.

Cependant, l’avantage principal est de disposer d’un nom d’utilisateur distinct pour chaque utilisateur, ce qui facilite le contrôle plus granulaire de l’accès lorsque nous en avons besoin et donne à chaque utilisateur une identité qui apparaît dans les journaux d’audit, ce qui peut s'avérer très utile lorsque vous essayez de suivre un utilisateur. problème de production à une action sysadmin.

Sous cette configuration, il est gênant de disposer de systèmes automatisés qui agissent contre les hôtes de production, car leurs clés SSH "bien connues" peuvent servir de chemin d'accès alternatif. Jusqu'ici, nous venons de faire en sorte que les comptes d'utilisateur de ces systèmes automatisés ne disposent que de l'accès minimal dont ils ont besoin pour faire leur travail et nous avons accepté qu'un utilisateur malveillant (qui doit déjà être un ingénieur disposant d'un accès en production) puisse également effectuer les mêmes actions en même temps. anonymement en utilisant la clé de l'application.

Personnellement, j'aime bien l'idée que chaque membre du personnel ait une clé sur une machine à bastion ssh dédiée sur laquelle il possède un compte utilisateur de base. Ce compte utilisateur a 1 clé ssh qui donne accès à tous les serveurs dont ils ont besoin. (ces autres serveurs doivent également être protégés par un pare-feu afin que seul l'accès ssh de la machine à bastion soit activé)

Ensuite, sur leurs machines de travail quotidiennes, ordinateurs portables, tablettes, etc., ils peuvent faire leur propre choix d'avoir une clé entre eux ou plusieurs clés.

En tant qu’administrateur système sur ce réseau, vous disposez d’un nombre minimal de clés (un par développeur), pouvez facilement surveiller l’accès SSH sur le réseau (comme toutes les routes à travers le bastion) et si le développeur souhaite plusieurs clés ou simplement qu’ils partagent avec leurs machines, ce n’est pas un problème car il n’ya qu’une machine à mettre à jour. (à moins que les bastions des clés ssh ne soient compromises, c’est beaucoup plus improbable que l’une des clés de l’utilisateur)

J'ai eu le cas de devoir fournir un accès par clé SSH pour une équipe de 40 développeurs à environ 120 serveurs clients distants.

J'ai contrôlé l'accès en obligeant les développeurs à se connecter via un "hôte de saut" unique. À partir de cet hôte, j'ai généré des clés privées / publiques et les ai déplacées vers les serveurs du client. Si les développeurs avaient besoin d'accéder à un ordinateur portable, ils pourraient utiliser la même paire de clés sur leur système local.

Personnellement, j'irais avec chaque utilisateur, alors vous avez instantanément la responsabilité et fixez les restrictions beaucoup plus facilement - je ne sais pas ce que les autres pensent?

Une approche dont j'ai entendu parler, mais que je n’ai pas utilisée moi-même, est que chaque utilisateur ait un paquet (par exemple, .deb, .rpm) qui contient sa configuration de clé publique ssh, ainsi que tous les fichiers de points qu’ils aiment personnaliser (.bashrc , .profile, .vimrc, etc.). Ceci est signé et stocké dans un référentiel d'entreprise. Ce paquet peut également être responsable de la création du compte utilisateur, ou peut compléter quelque chose d'autre créant le compte (cfengine / puppet etc.) ou un système d'authentification central tel que LDAP.

Ces paquets sont ensuite installés sur les hôtes via le mécanisme de votre choix (cfengine / puppet, etc., travail cron). Une approche consiste à créer un métapaquet qui dépend des packages par utilisateur.

Si vous souhaitez supprimer une clé publique, mais pas l'utilisateur, le package par utilisateur est mis à jour. Si vous souhaitez supprimer un utilisateur, vous supprimez le package.

Si vous avez des systèmes hétérogènes et que vous devez gérer à la fois les fichiers .rpm et .deb, je constate que cela est un peu gênant, bien que des outils comme extraterrestres puissent rendre cela plus facile.

Comme je le dis, je ne l'ai pas fait moi-même. L'avantage de cette approche, à mon sens, est qu'elle complète un système LDAP central et une gestion centralisée des comptes d'utilisateurs, en ce sens qu'elle permet à un utilisateur de mettre facilement à jour son paquet pour inclure son fichier .vimrc, par exemple, sans qu'il soit nécessaire de gérer ce fichier. par des outils tels que la marionnette, à laquelle un utilisateur peut ne pas avoir accès.

Vous devez choisir la voie la plus sûre et forcer chaque utilisateur à disposer de clés distinctes, et probablement pour chaque périphérique.

Si vous avez des clés partagées entre utilisateurs, même si vous êtes une petite équipe, la révocation d'une clé est un inconvénient pour tout le monde.

Si vous permettez à votre personnel d’avoir une clé pour tous leurs périphériques, ils peuvent choisir les serveurs auxquels ils peuvent se connecter avec ce périphérique. Par exemple, un ordinateur portable peut être limité à un ou deux serveurs, mais le bureau du bureau peut avoir accès à tous les serveurs.

Il y a quelques années, Envy Labs a écrit un outil appelé Keymaster (en partenariat avec le client Gatekeeper) afin de gérer un tel problème pour les équipes de développement.

Le projet n'a pas eu beaucoup d'amour au cours des deux dernières années, mais est-ce une chose avec laquelle vous pourriez bricoler et peut-être ramener à la vie?

Le repo est disponible dans github: https://github.com/envylabs/keymaster

Une approche pourrait être de configurer un serveur NIS avec / home share sur NFS. Cela se combinait avec sudo dans les serveurs et permettait uniquement aux utilisateurs de votre choix de se connecter à chaque serveur via la configuration SSH.

De cette façon, chaque membre de l'équipe n'utilisera qu'un seul utilisateur et sa clé pour accéder à tous les serveurs. Sudo et un mot de passe pour les tâches administratives.

Cordialement,

Rafael