Oft werden SSH-Zugriffe auf Remote-Servern durch einen selbsterstellten SSH-Schlüssel eines Benutzers ermöglicht. Der öffentliche Teil des SSH-Schlüssels wird dabei manuell in die authorized_keys-Datei in das entsprechende Homeverzeichnis auf dem Server geschrieben. Die Pflege dieser Schlüssel erfolgt damit ausschließlich händisch und meist ohne Vier-Augen-Prinzip.
Schluss mit eigenmächtig
Im Rahmen der Umbauarbeiten unserer automatisierten Infrastruktur im Rechenzentrum haben wir uns auch diesem Problem grundsätzlich gewidmet. Wir haben uns ein bisschen von großen Plattformen inspirieren lassen und sind unter anderem auf diesen Artikel gestoßen: Umsetzung der SSH-CA bei Facebook.
Nachdem wir die Anforderungen eingesammelt, verfeinert und abgestimmt hatten, suchten wir in den Tiefen der freien Software nach geeigneten Tools, um unsere CA (Certificate Authority) aufzusetzen. Fündig wurden wir bei Vault, dessen umfangreiche Funktionen - wie API, SEAL/UNSEAL via gesplittetem Masterkey, eingebaute UI (Benutzeroberfläche) und SSH-CA-Plugin - wir uns in der Umsetzung zunutze machten.
Rollen, Rechte, Zonen und Ablauf
Beim Einsammeln der Anforderungen wurde uns schnell klar, dass wir es mit teilweise recht unterschiedlichen Berechtigungen und Laufzeiten zu tun haben: So wollen wir insbesondere die Rolle der Administration von der Bereitschaft sauber trennen. Und die Bereitschaft wiederum wird im Schichtbetrieb durch unterschiedliche Mitarbeiter sichergestellt. Im Labor rollen wir Systeme aus, die bei erfolgloser Evaluierung nicht einfach vergessen werden und keineswegs vor sich “hindümpeln” dürfen. Auch die Zusammenarbeit mit externen Personen muss sich sauber dokumentieren und in den Rechten abbilden lassen.
Also soll jeder nur dann Zugriff auf Systeme haben, wenn er sie braucht und dafür freigegeben wurde. Und Freigaben sollen im Vier- (oder Sechs-, Acht- ...) Augenprinzip erfolgen.
Daraus haben sich mit unseren Anforderungen folgende Rollen ergeben:
- Administration
- Bereitschaft
- Labor
- Development (Festangestellte & Freelancer)
- Application
Neben den Rollen mussten wir Zonen definieren, für die die Rollen zuständig sind. Dadurch konnten wir eine Rechtetrennung herstellen, etwa für Development und Bereitschaft: Die Bereitschaft muss auf alle Systeme im Störungsfall zugreifen können, während das Development nur auf die jeweilige Dev-Umgebung zugreifen darf.
Weiterhin haben wir sinnvolle Schlüsselgültigkeiten definiert, die sich beispielsweise an Projektlaufzeiten oder Bereitschaftsdiensten orientieren.
Beispielworkflow Bereitschaft
Übergabe der Bereitschaft zwischen aktuellem und kommendem Mitarbeiter:
- Der kommende Mitarbeiter erstellt auf seinem Client einen SSH-Schlüssel (ein bereits erstellter Schlüssel kann wiederverwendet werden):
ssh-keygen -t ecdsa -f [USER]_[ROLLE]_ecdsa
- Der kommende Mitarbeiter übermittelt dem aktuellem Mitarbeiter seinen eben erstellten öffentlichen Schlüssel.
- Der Vault wird geöffnet (unsealed). Aktueller Mitarbeiter und kommender Mitarbeiter öffnen mittels ihrer Teile vom Master Key den Vault.
- Der aktuelle Mitarbeiter loggt sich beim Vault mit Credentials ein.
- Der aktuelle Mitarbeiter signiert den Public Key des kommenden Mitarbeiters.
KeyID: [USERKÜRZEL] bsp.: JOHNDOEValidprinzipals: [ZONE] bsp. : BereitschaftExtentions: "permit-pty": ""TTL: X days
- Der aktuelle Mitarbeiter übermittelt dem kommenden Mitarbeiter den gerade signierten öffentlichen Schlüssel. Dieser muss ihn dann anstelle des unsignierten öffentlichen Schlüssels speichern. (Hinweis: Will man den Schlüssel wiederverwenden, sollte der unsignierte öffentliche Teil gesondert gespeichert werden.)
- Nach erfolgreichem Signieren wird der Vault durch den aktuellen Mitarbeiter wieder geschlossen (sealed).
Im Hintergrund passiert jetzt die Magie, dass der Schlüsseltausch auf den Servern in Verbindung mit Vault automatisch passiert.
Der aktuelle Mitarbeiter kann beruhigt schlafen gehen, weil der kommende Mitarbeiter jetzt der aktuelle Mitarbeiter ist und der ehemals aktuelle Mitarbeiter ab sofort keinen Zugriff mehr auf die Maschinen hat, da die Gültigkeit der Keys abgelaufen ist.