SSH Access Gateway für viele Server

Verwaltung mehrerer Server, derzeit über 90 mit 3 Entwicklern über Ansible. Alles funktioniert super, aber es gibt gerade ein riesiges Sicherheitsproblem. Jeder Entwickler verwendet seinen eigenen lokalen SSH-Schlüssel, um direkt auf die Server zuzugreifen. Jeder Entwickler verwendet einen Laptop, und jeder Laptop kann möglicherweise kompromittiert werden, wodurch das gesamte Netzwerk von Prod-Servern für Angriffe geöffnet wird.

Ich suche nach einer Lösung, um den Zugriff zentral zu verwalten und somit den Zugriff für einen bestimmten Schlüssel zu blockieren. Nicht unähnlich, wie Schlüssel zu Bitbucket oder Github hinzugefügt werden.

Auf den ersten Blick würde ich annehmen, dass die Lösung ein Tunnel von einer Maschine, dem Gateway, zum gewünschten Prod-Server ist ... während die Anfrage über das Gateway einen neuen Schlüssel aufnimmt und verwendet, um Zugriff auf den Prod zu erhalten Server. Das Ergebnis wäre, dass wir den Zugriff für jeden Entwickler innerhalb von Sekunden schnell und effizient beenden können, indem wir nur den Zugriff auf das Gateway verweigern.

Ist das eine gute Logik? Hat jemand schon eine Lösung gefunden, um dieses Problem zu vereiteln?

Das ist zu kompliziert (Überprüfen, ob ein Schlüssel Zugriff auf einen bestimmten Produktserver hat). Verwenden Sie den Gatewayserver als Sprunghost, der jeden gültigen Schlüssel akzeptiert (aber den Zugriff auf einen bestimmten Schlüssel, der den Zugriff auf alle Server der Reihe nach aufhebt, problemlos entfernen kann), und fügen Sie dann jedem entsprechenden Server nur die zulässigen Schlüssel hinzu. Stellen Sie danach sicher, dass Sie den SSH-Port jedes Servers nur über den Jump-Host erreichen können.

Dies ist der Standardansatz.

Ingenieure sollten nicht direkt von ihrem Laptop aus laufen, es sei denn, dies ist eine Entwicklungs- / Testumgebung.

Verfügen Sie stattdessen über einen zentralen Server, der die Runbooks von Git abruft. Dies ermöglicht zusätzliche Kontrollen (vier Augen, Codeüberprüfung).

Kombiniere dies mit einer Bastion oder einem Sprunghost, um den Zugriff weiter einzuschränken.

Netflix hat Ihr Setup implementiert und eine kostenlose Software veröffentlicht, um diese Situation zu verbessern.

Sehen Sie dieses Video unter https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access oder diese Präsentation unter https://speakerdeck.com/rlewis/how-netflix-gives- all-its-engineer-ssh-zugriff-auf-in-produktion laufende-instanzen mit dem kernpunkt:

Wir werden unsere SSH-Bastion-Architektur überprüfen, die im Kern SSO zur Authentifizierung von Ingenieuren verwendet, und dann pro Benutzer Anmeldeinformationen mit kurzlebigen Zertifikaten für die SSH-Authentifizierung der Bastion für eine Instanz ausstellen. Diese kurzlebigen Anmeldeinformationen verringern das Risiko, dass sie verloren gehen. Wir werden erläutern, wie dieser Ansatz es uns ermöglicht, Ingenieure zu überwachen und automatisch darauf hinzuweisen, anstatt sie zu verlangsamen, bevor der Zugriff gewährt wird.

Ihre Software finden Sie hier: https://github.com/Netflix/bless

Einige interessante Tipps, auch wenn Sie nicht die gesamte Lösung implementieren:

• Sie verwenden SSH-Zertifikate anstelle von Schlüsseln. Sie können weit mehr Metadaten in das Zertifikat einfügen, wodurch eine Vielzahl von Einschränkungen pro Anforderung und auch einfachere Prüfungen möglich sind
• Verwendung von Zertifikaten mit sehr kurzer Gültigkeitsdauer (z. B. 5 Minuten) (die SSH-Sitzungen bleiben auch nach Ablauf des Zertifikats geöffnet)
• Verwenden von 2FA, um das Schreiben von Skripten zu erschweren und Entwickler zu zwingen, andere Lösungen zu finden
• Ein bestimmtes Submodul, das sich außerhalb der Infrastruktur befindet und durch die von der Cloud, auf der es ausgeführt wird, angebotenen Sicherheitsmechanismen ordnungsgemäß geschützt ist, verarbeitet die Generierung von Zertifikaten dynamisch, sodass jeder Entwickler auf jeden Host zugreifen kann

OneIdentity (ex-Balabit) SPS ist genau das, was Sie in diesem Szenario benötigen. Mit dieser Appliance können Sie die Benutzeridentitäten auf praktisch allen Computern verwalten, das Benutzerverhalten nachverfolgen, überwachen und alarmieren sowie alle Aktivitäten der Benutzer für spätere Überprüfungen indizieren.

Mein Vorschlag ist, SSH-Zugriff von Benutzercomputern zu verbieten.

Stattdessen solltest du

1. Hosten Sie Playbooks in Git.
2. Verwandle den "Access Server" in einen Jenkins Server.
3. Gewähren Sie nur den Benutzern, die Jenkins benötigen, Zugriff auf devops.
4. Führen Sie Ansible-Spiele auf den Jenkins über Build-Jobs über HTTP aus.
5. Deaktivieren Sie Jenkins CLI bei Bedarf als zusätzliche Sicherheitsmaßnahme.

Das Beispielausführungsmodell,

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

ODER

2. Klassischer Shell-Ausführungstyp. Fügen Sie Ihre Build-Schritte manuell hinzu, einschließlich der Prüfung von Git.

Wenn Sie nur über begrenzte Serverressourcen verfügen, kann derselbe Jenkins-Server auch Git (scm-manager) hosten, obwohl ein zusätzliches Sicherheitsrisiko besteht, wenn einer der Entwicklercomputer infiziert ist. Sie können dies möglicherweise abschwächen, indem Sie den Jenkins-Server vom Internet trennen und Ansible-Abhängigkeiten lokal auflösen.