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.