Frage Ansible Sicherheits Best Practices


Ich werde Ansible in meinem Datencenter vorstellen und suche nach einer bewährten Sicherheitsmethode, um herauszufinden, wo sich die Steuerungsmaschine befindet und wie die SSH-Schlüssel verwaltet werden.

Frage 1: Die Kontrollmaschine

Wir brauchen natürlich eine Kontrollmaschine. Auf der Steuerungsmaschine sind öffentliche SSH-Schlüssel gespeichert. Wenn ein Angreifer Zugriff auf die Kontrollmaschine hat, hat er möglicherweise Zugriff auf das gesamte Datenzentrum (oder auf die von Ansible verwalteten Server). Ist es also besser, eine dedizierte Kontrollmaschine im Datenzentrum oder eine Fernsteuerungsmaschine zu haben (wie meinen Laptop, der entfernt mit dem Datenzentrum verbunden ist)?

Wenn die beste Methode ist, meinen Laptop zu verwenden (der natürlich gestohlen werden könnte, aber ich könnte meine öffentlichen Schlüssel sicher online in der Cloud oder offline auf einem tragbaren verschlüsselten Gerät speichern), was, wenn ich einige Webschnittstellen mit verwenden muss Ansible, wie Ansible Tower, Semaphore, Rundeck oder Foreman, die auf einer zentralen Maschine in das Rechenzentrum installiert werden müssen? Wie kann man es sichern und vermeiden, dass es ein "Single Point of Attack" wird?

Frage 2: Die SSH-Schlüssel

Angenommen, ich muss Ansible verwenden, um einige Aufgaben auszuführen, die von root ausgeführt werden müssen (wie das Installieren von Softwarepaketen oder etwas Ähnlichem). Ich denke, die beste Vorgehensweise besteht nicht darin, den root-Benutzer auf kontrollierten Servern zu verwenden, sondern einen normalen Benutzer für Ansible mit sudo-Berechtigungen hinzuzufügen. Aber wenn Ansible fast jede Aufgabe ausführen muss, muss es Zugriff auf alle Befehle über sudo haben. Also, was ist die beste Wahl:

  • Lassen Sie Ansible den Benutzer root verwenden (mit seinem öffentlichen Schlüssel, der in ~/.ssh/authorized_keys
  • Erstellen Sie einen unprivilegierten Benutzer, der für Ansible mit sudo-Zugriff reserviert ist
  • Lassen Sie den Benutzer von Ansible alle Befehle über sudo ausführen, indem Sie ein Passwort angeben (das eindeutig ist, muss jedem Sysadmin bekannt sein, der Ansible zur Steuerung dieser Server verwendet)
  • Lassen Sie den Benutzer von Ansible alle Befehle über sudo ausführen, ohne ein Passwort anzugeben
  • irgendwelche anderen Hinweise?

24
2018-01-03 20:51


Ursprung


Sie möchten ein dediziertes Management-Subnetz (oder VLAN). Ihr ansässiger Steuerungscomputer befindet sich in diesem Subnetz. Wenn Sie mit dem Steuerungscomputer kommunizieren müssen, verbinden Sie sich mit diesem Subnetz. Lassen Sie nicht zu, dass es sich um root handelt - Neil McGuigan
Der Ansible Control Host wird im internen LAN sein und von außen nicht erreichbar sein, aber ich denke, das ist nicht genug. - Mat


Antworten:


Der Bastion-Host (das ansible Kontrollzentrum) gehört zu einem separaten Subnetz. Es sollte nicht direkt von außen zugänglich sein, es sollte nicht direkt zugänglich sein von die verwalteten Server!

Ihr Laptop ist das am wenigsten sichere Gerät von allen. Eine blöde E-Mail, eine blöde Flash-Schwachstelle, ein blöder Gast Wifi und es wird geknackt.

Für Server erlauben Sie keinen Root-Zugriff über ssh überhaupt. Viele Audits spotten darüber.

Zu guter Letzt sollte jeder Admin sein eigenes persönliches Konto auf jedem Zielserver verwenden und es mit Passwörtern sudo machen lassen. Auf diese Weise wird kein Passwort zwischen zwei Personen geteilt. Sie können überprüfen, wer was auf jedem Server getan hat. Es liegt an Ihnen, ob persönliche Accounts die Anmeldung am Passwort, nur am ssh-Schlüssel oder beides erfordern.

Zu klären ansible benötigt keinen einzigen Ziel-Login-Namen. Jeder Admin könnte und sollte einen persönlichen Ziel-Login-Namen haben.

Eine Randnotiz: Versuchen Sie niemals, ein Konto mit dem Namen eines Wortes (wie "ansible" oder "admin" oder "cluster" oder "management" oder "operator") zu erstellen, wenn es ein Passwort hat. Der einzige gute Name für ein Konto mit einem Passwort ist der Name eines Menschen, wie "jkowalski". Nur ein menschliches Wesen kann für die Handlungen verantwortlich sein, die über das Konto ausgeführt werden und verantwortlich dafür sind, ihr Kennwort falsch zu sichern, "ansible" kann nicht.


6
2018-01-04 00:07



Danke, Sie haben mich davon überzeugt, einen zentralisierten Bastion-Host in einem separaten Subnetz im Rechenzentrum zu verwenden. Mir ist auch bewusst, dass es am besten ist, einen persönlichen Benutzer pro Sysadmin zu verwenden, aber jetzt habe ich eine andere Frage (vielleicht wäre das besser bei einer separaten Serverfault-Frage): wie man Benutzer und SSH-Schlüssel auf Linux-Hosts ohne NIS, NFS zentralisiert Aktien oder so etwas? Bitte beachten Sie, dass ich bereits Active Directory für Windows-Server habe. - Mat
Ok, denke besser an meine Frage Ich habe zwei mögliche Antworten: benutze LDAP Schlüsselspeicher oder Userify (siehe zwei Antworten unten). Aber ... Brauche ich es wirklich? Nein, wenn ich meinen eigenen Benutzer verwende, um neue Benutzer und Schlüssel über Ansible selbst zu verteilen! :-) - Mat
@Mat, völlig einverstanden - wie ich unten gesagt habe, brauchst du wirklich kein Userify oder ähnliches, bis dein Team größer wird. (Es macht es jedoch viel schöner.) LDAP ist ein wenig mühsam zu installieren (Forschung pam_ldap und nss_ldap), aber wir haben eingebaute Tools in Sekunden mit Ansible, Chef, Puppet, etc. zu integrieren. Außerdem ist es kostenlos für <20 Server. - Jamieson Becker


> Frage 1: Die Kontrollmaschine

Bei Userify (vollständige Offenlegung: wir bieten Software zur Verwaltung von SSH-Schlüsseln an), beschäftigen wir uns ständig damit, da wir auch das größte SSH-Schlüssel-Warehouse betreiben. Im Allgemeinen empfehlen wir die lokale Installation, anstatt die Cloud zu verwenden, da Sie mehr Kontrolle haben, Ihre Oberfläche reduzieren, Sie können sie wirklich auf nur bekannte vertrauenswürdige Netzwerke beschränken.

Das Wichtige, an das man sich erinnern sollte, ist, dass in einem richtig gebauten System es sollte wirklich keine bedeutenden Geheimnisse geben, die durchgesickert werden können zu einem Angreifer. Wenn jemand einen Gabelstapler in Ihr Datacenter fährt und mit Ihrem Server fortfährt, erhalten Sie nicht viel, außer für einige schwer verschlüsselte Passwörter, wahrscheinlich einige stark verschlüsselte Dateien, und einige öffentliche Schlüssel ohne ihre entsprechenden privaten Schlüssel. Mit anderen Worten, nicht so viel.

Wie Sie bemerken, sind die wirklichen Bedrohungsvektoren hier Was passiert, wenn ein Angreifer die Kontrolle über diese Maschine erlangt? und verwendet es, um eigene Benutzerkonten und (öffentliche) Schlüssel bereitzustellen. Dies ist ein Risiko für praktisch jede Cloud-Plattform (z. B. Linode). Sie sollten sich am stärksten darauf konzentrieren, den Zugriff auf die Steuerungsebene zu verhindern, dh die Angriffsfläche zu minimieren (nur einige Ports freizugeben und diese Ports so weit wie möglich zu sperren) und vorzugsweise Software zu verwenden, die gegen Privileeskalation und verschiedene Angriffe geschützt ist ( SQL-Injection, XSS, CSRF usw.) Aktivieren Sie den 2FA / MFA-Zugriff auf die Steuerungsebene und konzentrieren Sie sich darauf, diese Steuerungsebene so weit wie möglich zu sperren.

Ist es also besser, eine dedizierte Kontrollmaschine im Datenzentrum oder eine Fernsteuerungsmaschine zu haben (wie meinen Laptop, der entfernt mit dem Datenzentrum verbunden ist)?

Es ist definitiv besser eine dedizierte Kontrollmaschine in einem sicheren Rechenzentrum zu haben, weil Sie sie isolieren und sperren können, um das Risiko eines Diebstahls oder unbefugten Zugriffs zu verhindern / minimieren.

Wenn ich meinen Laptop verwenden sollte (der natürlich gestohlen werden könnte, aber ich könnte meine öffentlichen Schlüssel sicher online in der Cloud oder offline auf einem tragbaren verschlüsselten Gerät speichern lassen), Was ist, wenn ich einige Webschnittstellen verwenden muss? mit Ansible, wie Ansible Tower, Semaphore, Rundeck oder Foreman, die auf einer zentralen Maschine in das Rechenzentrum installiert werden müssen?

Sie müssen keine Webschnittstelle ausführen oder sekundäre Kontrollebene, um Ihre Schlüssel zu verwalten (sogar Userify), bis Sie aufgrund einer größeren Anzahl von Benutzern und unterschiedlichen Autorisierungsstufen auf Servern groß genug werden, um mit Verwaltungsproblemen zu beginnen, oder zusätzliche Handholdings für Ihre Benutzer benötigen Wissen oder Zugang zu Ansible, um Schlüssel zu aktualisieren. Userify war zunächst nicht viel mehr als ein Haufen Shell-Skripte (heute wären sie vermutlich Ansible!) Und daran ist überhaupt nichts falsch, bis Sie anfangen, zusätzliche Management-Kontrolle und einfache Methoden für die Verwaltung / Rotation ihrer Benutzer zu benötigen eigene Schlüssel. (Bitte sehen Sie sich Userify an, wenn Sie an diesen Punkt kommen!)

Wie kann man es sichern und vermeiden, dass es ein "Single Point of Attack" wird?

Nun, natürlich schauen Sie sich alle Ressourcen im Internet an, um Dinge zu sperren, aber vor allem Beginnen Sie mit einer sicheren Grundlage:

1. Gestalten Sie Ihre Lösung von Anfang an mit Sicherheit. Wählen Sie Technologie (d. H. Datenbank oder Sprachen), die traditionell weniger Probleme hatten, und codieren Sie dann mit Sicherheit von Anfang an. Bereinigen Sie alle eingehenden Daten, auch von vertrauenswürdigen Benutzern. Paranoia ist eine Tugend.

2. Irgendwann wird alles kaputt gemacht. Minimiere den Schaden, wenn dies geschieht: Versuche, wie bereits erwähnt, die Handhabung von geheimem Material zu minimieren.

3. Halten Sie es einfach. Machen Sie nicht die neuesten exotischen Sachen, es sei denn, Sie sind sicher, dass dies messbar und nachweisbar Ihre Sicherheit erhöht. Zum Beispiel haben wir X25519 / NaCl (libsodium) über AES für unsere Verschlüsselungsschicht gewählt (wir verschlüsseln alles, in Ruhe und in Bewegung), weil es ursprünglich von jemandem entworfen und geschrieben wurde, dem wir vertraut haben (DJB et al) und der von der Welt überprüft wurde Forscher wie Schneier und Googles Sicherheitsteam. Verwenden Sie Dinge, die zur Einfachheit tendieren, wenn sie neuer sind, da die Einfachheit es schwerer macht, tiefe Fehler zu verbergen.

4. Sicherheitsstandards erfüllen. Selbst wenn Sie nicht in ein Sicherheitsregime wie PCI oder die HIPAA-Sicherheitsregel fallen, lesen Sie sich diese Standards durch und finden Sie heraus, wie Sie sie erfüllen können oder zumindest sehr starke Kompensationskontrollen. Dies wird dazu beitragen sicherzustellen, dass Sie wirklich "Best Practices" treffen.

5. Führen Sie externe / unabhängige Penetrationstests durch und führen Sie Bug-Bounties aus um sicherzustellen, dass Sie diese Best Practices kontinuierlich befolgen. Alles sieht gut aus, bis Sie ein paar kluge und hochmotivierte Leute haben, die darauf loslegen ... Sobald das erledigt ist, werden Sie viel Vertrauen in Ihre Lösung haben.


Frage 2: Die SSH-Schlüssel   Was ist die beste Wahl: Lassen Sie Ansible den root - Benutzer verwenden (mit seinem öffentlichen Schlüssel, der in ~/.ssh/authorized_keys / Lassen Sie den Benutzer von Ansible alle Befehle über sudo ausführen, indem Sie ein Passwort angeben (das eindeutig ist, muss jedem Sysadmin bekannt sein, der Ansible zur Steuerung dieser Server verwendet)

Versuchen Sie zu vermeiden, jemals Kennwörter auf Servern zu verwenden, auch nicht für Sudo. Das ist mit Geheimnissen zu tun und wird letztendlich Ihre Sicherheit untergraben (Sie können dieses sudo-Passwort nicht wirklich zwischen Rechnern variieren, Sie müssen es irgendwo speichern, das Passwort bedeutet, dass Sie keine Server-zu-Server-Automatisierung durchführen können Genau, worum es dabei geht: Wenn Sie SSH auf die Standardwerte belassen, können diese Kennwörter routinemäßig erzwungen werden, was die Schlüssel etwas bedeutungslos macht.Vermeiden Sie auch die Verwendung von root-Benutzern für jeden Zweck und insbesondere die Remote-Anmeldung.

Erstellen Sie einen unprivilegierten Benutzer, der für Ansible mit sudo access reserviert ist, und lassen Sie den Ansible-Benutzer alle Befehle über sudo ausführen, ohne ein Passwort anzugeben

Genau. Ein unprivilegierter Benutzer, den Sie mit Sudo-Rollen auf ansible zurücküberwachen können.Idealerweise erstellen Sie einen Standardbenutzer, der für Server-zu-Server- / Ansible-Kommunikation mit sudo-Zugriff (ohne Passwort) vorgesehen ist.

... NB, wenn Sie Userify verwenden, wäre die Art und Weise, wie ich vorschlagen würde, einen Userify-Benutzer für ansible zu erstellen (Sie können dies auch nach Projekt oder sogar Servergruppe aufteilen, wenn Sie mehrere ansible Control-Maschinen haben), generieren einen SSH-Schlüssel auf dem Steuerungsserver und den öffentlichen Schlüssel auf der Profilseite Userify. (Dieser Textkasten wird im Wesentlichen /home/ansible/.ssh/authorized_keys). Sie sollten das Ansible-Systemkonto von anderen Server-zu-Server-Systemkonten wie einem Remote-Backup-Konto, einer geheimen Verwaltung usw. getrennt halten. Dann laden Sie Ihre Benutzer ein und sie können ihre eigenen Schlüssel erstellen und verwalten und alles bleibt getrennt. Versuchen Sie jedoch genauso wie beim Sperren eines Ansible-Steuerungsservers, den Userify-Server (oder die von Ihnen bereitgestellte Lösung) auf die gleiche Weise zu sperren.

irgendwelche anderen Hinweise?

Ich denke du gehst definitiv den richtigen Weg und stellst die richtigen Fragen. Wenn Sie solche Dinge besprechen möchten, schreiben Sie mir eine E-Mail (Vorname Nachname bei Userify) und ich würde mich freuen, Sie zu unterhalten, egal in welche Richtung Sie letztendlich gehen. Viel Glück!


11
2018-01-04 02:44





Antwort 1: Die Kontrollmaschine

Ein wenig von beiden können Sie Ihren Laptop verwenden, um sich über einen Bastion-Host mit Servern zu verbinden. so etwas wie:

Host private1
  IdentityFile ~/.ssh/rsa_private_key
  ProxyCommand ssh user@bastion -W %h:%p

Host bastion
  IdentityFile ~/.ssh/bastion_rsa_key

Mehr über Bastion Hosts

Wo haben Sie einen Schlüssel für den Bastion-Server, und dann einen separaten Schlüssel für den Host dahinter. (persönlich würde ich gpg-agent / ssh-agent verwenden)

Antwort 2: Authentifizierung

Ich bin mir nicht sicher, wie sich "ansible" spezifische Best Practices von allen anderen Best Practices für ssh connection unterscheiden. Nein, Sie möchten ansible als Sie selbst ausführen, nicht als Dienstkonto und nicht als root-Konto.

Eine Kombination der folgenden Authentifizierungen:

Andere Gedanken:

  • Speichern Sie immer Geheimnisse / private Informationen in ansible-vault.
  • Ansible erfordert nicht, dass SUDO / Root ausgeführt wird, es sei denn, was Sie tun, erfordert sudo / root.
  • Ansible kann Berechtigungen auf verschiedene Arten erhöhen

Zuletzt haben Sie nichts über Windows erwähnt. Ich kann also nur annehmen, dass du das nicht benutzt. In diesem Fall würde ich jedoch die Delegate-Option verwenden, damit Ihr Laptop den Bastion-Host verwendet (delegate_to: bastion.hostname.fqdn) und kerberos / winrm https mit Kerberos-Tickets.

Falls Sie es verpasst haben, Best Practice für Computing, Tue niemals etwas als root, benutze immer benannte Accounts


3
2018-01-04 00:38