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:

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.

ssh-keygen -t ecdsa -f [USER]_[ROLLE]_ecdsa

KeyID: [USERKÜRZEL] bsp.: JOHNDOE
Validprinzipals: [ZONE] bsp. : Bereitschaft
Extentions: "permit-pty": ""
TTL: X days

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.