Quelles sont les meilleures pratiques pour gérer les clés SSH au sein d'une équipe ?

Dans mon entreprise, nous utilisons LDAP pour disposer d'un ensemble cohérent de comptes sur toutes les machines, puis nous utilisons un outil de gestion de la configuration (dans notre cas, cfengine) pour distribuer les données de la base de données. authorized_keys pour chaque utilisateur sur l'ensemble des serveurs. Les fichiers clés eux-mêmes sont conservés (avec d'autres informations sur la configuration du système) dans un dépôt git afin que nous puissions voir quand les clés entrent et sortent. cfengine distribue également un fichier sudoers qui contrôle qui a le droit d'exécuter quoi en tant que root sur chaque hôte, en utilisant les utilisateurs et les groupes de l'annuaire LDAP.

L'authentification par mot de passe est complètement désactivée sur nos serveurs de production, l'authentification par clé SSH est donc obligatoire. La politique encourage l'utilisation d'une clé séparée pour chaque ordinateur portable/de bureau/quoi que ce soit et l'utilisation d'une phrase de passe sur toutes les clés afin de réduire l'impact de la perte ou du vol d'un ordinateur portable.

Nous avons également un hôte bastion qui est 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"

L'ajout d'une nouvelle clé ou le retrait d'une ancienne nécessite un peu de cérémonial dans cette configuration. Je dirais que pour l'ajout d'une nouvelle clé, il est souhaitable que ce soit une opération qui laisse une trace d'audit et qui soit visible par tout le monde. Cependant, en raison des frais généraux que cela implique, je pense que les gens négligent parfois de retirer une ancienne clé lorsqu'ils n'en ont plus besoin et nous n'avons pas de véritable moyen de suivre cette opération, sauf pour faire le ménage lorsqu'un employé quitte l'entreprise. Cela crée également des frictions supplémentaires lors de l'intégration d'un nouvel ingénieur, puisqu'il doit générer une nouvelle clé et l'envoyer à tous les hôtes avant de pouvoir être totalement productif.

Cependant, le plus grand avantage est d'avoir un nom d'utilisateur distinct pour chaque utilisateur, ce qui facilite un contrôle d'accès plus granulaire lorsque nous en avons besoin et donne à chaque utilisateur une identité qui apparaît dans les journaux d'audit, ce qui peut être très utile pour essayer de retracer un problème de production à partir d'une action de l'administrateur système.

Dans cette configuration, il est gênant d'avoir des systèmes automatisés qui prennent des mesures contre les hôtes de production, car leurs clés SSH "bien connues" peuvent servir de voie d'accès alternative. Jusqu'à présent, nous avons simplement fait en sorte que les comptes utilisateurs de ces systèmes automatisés n'aient que 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 ayant un accès à la production) puisse également effectuer ces mêmes actions de manière semi-anonyme en utilisant la clé de l'application.

Personnellement, j'aime l'idée que chaque membre du personnel dispose d'une clé sur une machine ssh bastion dédiée, sur laquelle il dispose d'un compte utilisateur de base. Ce compte utilisateur possède une clé ssh qui donne accès à tous les serveurs qu'il doit utiliser. (Ces autres serveurs devraient également être protégés par un pare-feu de sorte que seul l'accès ssh à partir de la machine bastion soit autorisé).

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

En tant qu'administrateur système sur ce réseau, vous avez un nombre minimum de clés à gérer (une par développeur), vous pouvez facilement contrôler l'accès ssh à travers le réseau (puisque tout passe par la machine Bastion) et si les développeurs veulent plusieurs clés ou une seule qu'ils partagent entre leurs machines, ce n'est pas un vrai problème puisque vous n'avez qu'une seule machine à mettre à jour. (à moins que les clés ssh du bastion ne soient compromises, mais c'est bien plus improbable que l'une des clés de l'utilisateur).

Il m'est arrivé de devoir fournir à une équipe de 40 développeurs un accès par clé SSH à ~120 serveurs clients distants.

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

Personnellement, j'opterais pour un système par utilisateur, ce qui permet d'avoir instantanément des comptes à rendre et de fixer des restrictions beaucoup plus facilement - je ne sais pas ce qu'en pensent les autres ?

Une approche dont j'ai entendu parler, mais que je n'ai pas utilisée moi-même, consiste à ce que chaque utilisateur dispose d'un paquet (par exemple, .deb, .rpm) qui contient sa configuration de clé publique ssh, ainsi que tous les fichiers point qu'il souhaite personnaliser (.bashrc, .profile, .vimrc, etc.). Ces fichiers sont signés et stockés dans un référentiel de l'entreprise. Ce paquet peut également être responsable de la création du compte utilisateur, ou il peut compléter quelque chose d'autre qui crée le compte (cfengine/Puppet, etc.) ou un système d'authentification central comme LDAP.

Ces paquets sont ensuite installés sur les hôtes par le mécanisme que vous préférez (cfengine/Puppet etc., travail cron). Une approche consiste à avoir un métapaquet qui dépend des paquets par utilisateur.

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

Si vous avez des systèmes hétérogènes et que vous devez maintenir à la fois des fichiers .rpm et .deb, alors je peux voir cela comme un peu ennuyeux, bien que des outils comme alien puissent rendre cela un peu plus facile.

Comme je l'ai dit, je ne l'ai pas fait moi-même. Pour moi, l'avantage de cette approche est qu'elle complète un système LDAP central et une gestion centrale des comptes d'utilisateurs, en ce sens qu'elle permet à un utilisateur de mettre facilement à jour son paquetage pour y inclure son fichier .vimrc, par exemple, sans devoir faire gérer ce fichier par des outils tels que Puppet, auxquels l'utilisateur n'a pas forcément accès.