Credential-Verwaltung mit Hashicorp Vault

Je nach Sicherheitsparadigma im Unternehmen teilen die Mitglieder eines Administratoren-Teams einen gemeinsamen Account oder statten die persönlichen Accounts mit Admin-Rechten aus. Im ersten Fall muss jedes Mitglied das gemeinsame Passwort zu diesem Account kennen. Dies führt mitunter zu unglücklichen Situationen, wenn ein eingeweihter Mitarbeiter das Team oder gar das Unternehmen verlässt. Im zweiten Fall arbeiten die Admins bei all ihren Alltagsaufgaben mit einem Benutzeraccount, der mit Rechten weit über das normale Maß hinaus ausgestattet ist.

Hinzu kommt der Einsatz von Cloud-Infrastrukturen samt dynamischer Ressourcenverwaltung, die sich an den tatsächlichen Bedarfen der jeweiligen Dienste orientiert. Bei hohem Andrang führen dabei kurzfristig bereitgestellte zusätzliche Instanzen die notwendigen Berechnungen durch. Solche dynamischen Umgebungen teilen sich in der Regel Benutzeraccounts zu Datenbanken oder APIs, geheime Schlüssel zur Verschlüsselung der Kommunikation oder Zugang zu gemeinsam genutzten Dateisystemen. Das jeweilige Passwort ist dann in einer weithin verfügbaren Konfigurationsdatei hinterlegt, die beim Aufsetzen der Instanz zur Konfiguration genutzt wird. Alternativ wird das gemeinsam genutzte Admin-Passwort zum Login verwendet und die restlichen Konfigurationen teilautomatisiert fertiggestellt.

In beiden Szenarien verwenden verschiedene Instanzen dieselben Geheimnisse, um die anstehende Arbeit durchführen zu können. Das führt zum einen zu Schwierigkeiten bei der Zurechenbarkeit von durchgeführten Arbeiten, also etwa der Nachvollziehbarkeit, wer sich wann mit dem Administrations-Account auf einem System angemeldet hat. Nutzen Cloud-Instanzen dieselben Zugangsdaten beim Datenbankzugriff, lässt sich im Zweifel nicht feststellen, welche Instanz für fehler- oder schadhafte Aktionen verantwortlich ist. Zum anderen können sich nach der Verteilung der Geheimnisse bestehende Strukturen verändern. Dann ergeben sich neue Probleme: Was passiert mit dem alten Passwort? Müssen Sie alle Systeme mit einem neuen Passwort ausstatten oder genügt es, dies erst bei zukünftigen Instanzen umzusetzen?

Installation und Konfiguration

Das US-Unternehmen Hashicorp [1] ist im Umfeld dynamischer Dienste vor allem durch seine Werkzeuge Vagrant und Packer bekannt. Vault [2] (deutsch: Tresor) ermöglicht den Zugriff auf gemeinsam genutzte Ressourcen und Dienste, kryptografische Schlüssel sowie dynamischen Zugang zu Benutzeraccounts. Vault wird als quelloffene Client-Server-Anwendung hauptsächlich in der Programmiersprache Go entwickelt. Die Installation aus den Quellen bei GitHub funktioniert problemlos, für gängige Betriebssysteme stellt das Unternehmen fertige Pakete zur Verfügung. Nach der Installation sollte sich das Programm im Ausführungs-Pfad befinden, um die Nutzung zu vereinfachen.

Vault verwaltet die Geheimnisse in einem eigenen Serverprozess. Dieser lässt sich über die gut dokumentierte HTTP-API ansteuern. Der Vault-Client vermittelt dabei zwischen Kommandozeilen-Argumenten und der API auf dem Server. Bevor Sie das erste Geheimnis sicher hinterlegen können, ist jedoch die Konfiguration des Servers notwendig. Wir gehen dabei von einem zentralen Dienst auf einem öffentlich erreichbaren Serversystem aus. Zugriffsregeln im Paketfilter erhöhen zwar die Sicherheit. Sie sollten diese jedoch so wählen, dass der Zugriff aus einer genutzten Cloud-Infrastruktur möglich ist. Eine eingerichtete Subdomain, wie etwa "vault.example.com", ermöglicht die einfache Konfiguration des Clients. Die Verbindung zwischen Vault-Client und -Server sollten Sie über SSL absichern, dazu benötigen Sie ein Zertifikat für die entsprechende Subdomain.

Haben Sie die Subdomain eingerichtet und liegt das SSL-Zertifikat bereit, kann die erste Konfiguration des Servers erfolgen. Diese erstellen Sie in der eigens entwickelten Hashicorp Configuration Language (HCL). Da HCL kompatibel zu JSON ist, ist das Format schnell zugänglich. Die Konfigurationsdatei "vault.example.com.config" könnte aussehen wie in Listing 1.

backend "file" {
      path = "/opt/vault/store.db"
}
listener "tcp" {
      address = "0.0.0.0:8200"
      tls_cert_file = "/opt/vault/server.pem"
      tls_key_file = "/opt/vault/key.pem"
      tls_min_version = "tls12"
}

Zunächst konfigurieren Sie das Backend des Servers, also die Stelle, an der Vault die Geheimnisse sicher hinterlegt. Hier lassen sich unterschiedliche Ziele wählen, die von Amazon S3 über eine MySQL-Datenbank oder das Dateisystem bis hin zum Arbeitsspeicher jeden Bedarf bedienen können. Für unsere ersten Versuche wählen wir das File-Backend, das die Datei einfach auf der lokalen Festplatte ablegt.

Die einzige derzeit unterstützte Listener-Konfiguration ist übrigens TCP. In diesem Konfigurationsblock konfiguriert "address" die lokale Adresse und den Port, die der Serverprozess nutzen soll. Die Optionen "tls_cert_file" und "tls_cert_key" definieren den Speicherort des SSL-Zertifikats sowie des zugehörigen geheimen Schlüssels. Zur Optimierung der Vertraulichkeit sollten Sie Versionen vor TLS 1.2 gar nicht erst zulassen. Das ermöglicht die Option tls_min_version mit dem Wert "tls12".

Sie fragen sich bestimmt, ob das Speichern beliebiger Geheimnisse in einer Datei auf der lokalen Festplatte oder etwa in Amazon S3 sicher sein kann. Die Antwort lautet "Ja", denn Vault speichert die anvertrauten Geheimnisse grundsätzlich verschlüsselt. Der Schlüssel liegt dabei im weiteren Verlauf ausschließlich im Arbeitsspeicher des Systems. Um dies sicherzustellen und ein Swapping des Passworts auf die Festplatte zu vermeiden, nutzt Vault unter Linux die mlock-Funktion des Kernels. Da diese root vorbehalten ist, starten Sie den Vault-Server mit dem folgenden Befehl:

$ sudo vault server --config vault.example.com.config

Bild 1: Die Unterschlüssel und Root-Token nach der Initialisierung. Von den fünf Schlüsseln sind stets drei zum Öffnen des Vaults nötig.

Server einrichten

Nach dem ersten Start des Servers müssen Sie diesen für die Verwendung vorbereiten. Das passiert mit demselben Vault-Programm, mit dem Sie auch den Server gestartet haben. Zur komfortablen Nutzung bietet sich an, die Adresse des Vault-Servers in einer Umgebungsvariablen zu speichern. Unter Linux funktioniert das für die aktuelle Terminalsitzung mittels:

$ export VAULT_ADDR="https://vault.example.com:8200"

Vergewissern Sie sich mit dem folgenden Befehl, dass Sie auf den Server zugreifen können und dieser bisher nicht initialisiert wurde:

$ vault status

Das Ergebnis der Statusabfrage sollte "* server is not yet initialized" lauten. Nun können Sie den Server initialisieren. Dabei generiert Vault den Schlüssel, den es zum Schutz der Geheimnisse verwendet. Da der Schlüssel niemals auf die Festplatte geschrieben wird, müssen Sie ihn nach jedem Neustart des Servers zum Entsperren des Tresors eingeben. Es offenbart sich eine weitere Funktion, die die Sicherheit des Vault-Servers weiter erhöht: Der Schlüssel selbst wird nach der Initialisierung niemals angezeigt. Vault nutzt nämlich das von Adi Shamir entwickelte Verfahren "Shamir's Secret Sharing".

Vault teilt den genutzten Schlüssel in der Standard-Konfiguration auf fünf Unterschlüssel auf, die gemeinsam den Hauptschlüssel beschreiben. Nach einem Neustart des Servers benötigt Vault dann mindestens drei der fünf Unterschlüssel, um den Hauptschlüssel wieder erzeugen zu können. Somit lässt sich die Verantwortung über den Hauptschlüssel auf alle Mitarbeiter eines Teams aufteilen. Initialisieren Sie den Tresor also mit dem Befehl:

$ vault init

Der Dialog zeigt neben den fünf erzeugten Unterschlüsseln auch das Wurzel-Token an. Dieses Token autorisiert Ihre Aktionen auf dem Server. Verteilen Sie die Unterschlüssel und notieren Sie sich das angezeigte Token.

Wenn Sie nun den Status des Tresors abfragen, erhalten Sie Informationen zum Zustand. Dieser ist noch versiegelt, was Sie daran erkennen, dass in der Status-Ausgabe "Sealed: true" angezeigt ist. Im nächsten Schritt öffnen Sie den Tresor. Wie beschrieben sind dafür drei Unterschlüssel notwendig. Vault fordert Sie nach der Ausführung des folgenden Befehls zur Eingabe Ihres Unterschlüssels auf:

$ vault unseal

Wurden die benötigten Unterschlüssel durch mehrfachen Aufruf von "unseal" verfügbar gemacht, erzeugt Vault den Hauptschlüssel und der Zustand des Tresors ist jetzt als "unsealed" gekennzeichnet. Ab diesem Zeitpunkt können Sie Geheimnisse hinterlegen und wieder abfragen. Bevor wir Vault tatsächlich verwenden, erfahren Sie im nächsten Schritt, welche existierenden Backends es zum Verwalten der Geheimnisse, zur Authentifikation und zur Auditierung gibt.