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 auf dem Server in das entsprechende Homeverzeichnis geschrieben. Die Pflege dieser Schlüssel erfolgt damit ausschließlich händisch und meist ohne 4 Augenprinzip.
Schluss mit eigenmächtig
Im Rahmen der Umbauarbeiten in unserer automatisierten Infrastruktur im Rechenzentrum, haben wir uns auch diesem Problem grundsätzlich gewidmet.
Wir haben uns ein bisschen von großen Plattformen inspieren lassen und sind u. a. 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 noch nach geeigneten Tools um unsere CA (Certificate Authority) aufzusetzen.
Fündig wurden wir bei Vault, dessen umfangreiche Funktionen wir uns in der Umsetzung zu nutzen machten (z. B. API, SEAL/UNSEAL via gesplitteten Masterkey, eingebaute UI, SSH-CA Plugin).
Rollen, Rechte, Zonen und Ablauf
Beim Einsammeln der Anforderungen wurde uns schnell klar, dass wir es mit teils recht unterschiedlichen Berechtigungen und Laufzeiten zu tun haben.
So wollten wir z. B. die Rolle der Administration von der Bereitschaft sauber trennen. Und die Bereitschaft wird im Schichtbetrieb durch unterschiedliche Mitarbeiter sichergestellt. Im Labor rollen wir Systeme aus, die bei nicht erfolgreicher Evaluierung auch nicht einfach vergessen werden sollen und vor sich “rumdümpeln”. Auch die Zusammenarbeit mit externen Mitarbeiter*innen muss sich sauber dokumentieren und in den Rechten abbilden lassen.
Also soll nur jeder dann Zugriff auf Systeme haben, wenn er sie braucht und dafür freigegeben wurde. Und Freigaben sollen im 4(6/8…)-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 für z. B. Development und Bereitschaft herstellen (in diesem Fall: die Bereitschaft muss auf alle Systeme im Störungsfall zugreifen können, während Development nur auf die jeweilige Dev-Umgebung zugreifen darf).
Weiterhin haben wir für uns sinnvolle Schlüsselgültigkeiten definiert, die sich z. B. an Projektlaufzeiten oder Bereitschaftsdiensten orientieren.
Beispielworkflow Bereitschaft
Übergabe Bereitschaft zwischen aktuellem Mitarbeiter und kommenden 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 übermittel 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 Publickey des kommenden Mitarbeiters.
KeyID: [USERKÜRZEL] bsp.: JOHNDOE
Validprinzipals: [ZONE] bsp. : Bereitschaft
Extentions: "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 Verbinung 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, weil die Gültigkeit der Keys abgelaufen ist.