Passerelle d'accès SSH pour de nombreux serveurs

Gestion de plusieurs serveurs, plus de 90 actuellement avec 3 devops via Ansible. Tout fonctionne très bien, mais il existe actuellement un énorme problème de sécurité. Chaque développeur utilise sa propre clé ssh locale pour accéder directement aux serveurs. Chaque devop utilise un ordinateur portable, et chaque ordinateur portable pourrait potentiellement être compromis, ouvrant ainsi l'ensemble du réseau de serveurs de production à une attaque.

Je suis à la recherche d'une solution pour gérer l'accès de manière centralisée, et donc bloquer l'accès pour une clé donnée. Pas différent de la façon dont les clés sont ajoutées à bitbucket ou github.

Du haut de ma tête, je suppose que la solution serait un tunnel d'une machine, la passerelle, vers le serveur de prod souhaité ... tout en passant la passerelle, la demande ramasserait une nouvelle clé et l'utiliserait pour accéder au prod serveur. Le résultat serait que nous pouvons rapidement et efficacement supprimer l'accès à n'importe quel devop en quelques secondes en refusant simplement l'accès à la passerelle.

Est-ce une bonne logique? Quelqu'un a-t-il déjà vu une solution pour déjouer ce problème?

C'est trop compliqué (vérifier si une clé a accès à un serveur de prod spécifique). Utilisez le serveur de passerelle comme hôte de saut qui accepte chaque clé valide (mais peut facilement supprimer l'accès à une clé spécifique qui supprime à son tour l'accès à tous les serveurs), puis ajoutez uniquement les clés autorisées à chaque serveur respectif. Après cela, assurez-vous que vous pouvez accéder au port SSH de chaque serveur uniquement via l'hôte de saut.

C'est l'approche standard.

Les ingénieurs ne doivent pas exécuter ansible directement depuis leur ordinateur portable, sauf s'il s'agit d'un environnement de développement / test.

Au lieu de cela, disposez d'un serveur central qui extrait les runbooks de git. Cela permet des contrôles supplémentaires (quatre yeux, révision du code).

Combinez cela avec un bastion ou un hôte de saut pour restreindre davantage l'accès.

Netflix a implémenté votre configuration et a publié des logiciels gratuits pour aider cette situation.

Voir cette vidéo https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access ou cette présentation sur https://speakerdeck.com/rlewis/how-netflix-gives- all-its-engineer-ssh-access-to-instances-running-in-production avec le point central:

Nous passerons en revue notre architecture de bastion SSH, qui utilise essentiellement SSO pour authentifier les ingénieurs, puis émet des informations d'identification par utilisateur avec des certificats de courte durée pour l'authentification SSH du bastion auprès d'une instance. Ces informations d'identification de courte durée réduisent le risque associé à leur perte. Nous verrons comment cette approche nous permet d'auditer et d'alerter automatiquement après coup, au lieu de ralentir les ingénieurs avant d'accorder l'accès.

Leur logiciel est disponible ici: https://github.com/Netflix/bless

Quelques pistes intéressantes même si vous n'implémentez pas toute leur solution:

• ils utilisent des certificats SSH au lieu de simplement des clés; vous pouvez mettre beaucoup plus de métadonnées dans le certificat, ce qui permet de nombreuses contraintes par exigences et permet également des audits plus simples
• en utilisant la validité des certificats à très court terme (comme 5 minutes) (les sessions SSH restent ouvertes même après l'expiration du certificat)
• utiliser 2FA pour rendre également les scripts difficiles et forcer les développeurs à trouver d'autres solutions
• un sous-module spécifique, en dehors de leur infrastructure et correctement sécurisé grâce aux mécanismes de sécurité offerts par le cloud où il s'exécute, gère la génération dynamique de certificats afin que chaque développeur puisse accéder à n'importe quel hôte

OneIdentity (ex-Balabit) SPS est exactement ce dont vous avez besoin dans ce scénario. Avec cette appliance, vous pouvez gérer les identités des utilisateurs sur pratiquement toutes les machines, suivre le comportement des utilisateurs, surveiller et alerter, et indexer tout ce que les utilisateurs font pour des révisions ultérieures.

Ma suggestion est de interdire l'accès SSH à partir des machines des utilisateurs.

Au lieu de cela, vous devriez

1. Hébergez des playbooks dans Git.
2. Transformez le "serveur d'accès" en serveur Jenkins.
3. Accordez uniquement l'accès Jenkins nécessaire aux utilisateurs devops.
4. Exécutez Ansible joue sur les travaux de build Jenkins via HTTP.
5. Comme mesure de sécurité supplémentaire, désactivez Jenkins CLI si nécessaire.

L'exemple de modèle d'exécution,

1. Plugin Jenkins Ansible: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

OU

2. Shell classique - type d'exécution du travail. Ajoutez vos étapes de génération manuellement, y compris la vérification de git.

Si vous êtes limité avec les ressources du serveur, le même serveur Jenkins peut également héberger Git (scm-manager), bien qu'il existe un risque de sécurité supplémentaire si l'une des machines du développeur est infectée. Vous pourrez peut-être atténuer cela en déconnectant le serveur Jenkins d'Internet et en résolvant les dépendances Ansible localement.