Vault für Entwickler: Geheimnisse in Webanwendungen schützen
Fast jede Webanwendung sorgt selbst für das sichere Speichern von Zugangsdaten. Vault ist eine Alternative, die in Entwicklungsumgebungen ohne großen Administrationsaufwand funktioniert.
(Bild: Michal Jarmoluk, gemeinfrei)
- Dominik Schadow
Nahezu jede Webanwendung enthält Geheimnisse, etwa in Form von Zugangsdaten zu Drittsystemen wie Datenbanken oder Fileshares. Jede Anwendung steht damit vor der Herausforderung, sie sicher zu speichern. Mit dem Projekt Vault von Hashicorp steht hierfür ein umfangreiches und erweiterbares Open-Source-Tool zur Verwaltung von eben jenen Geheimnissen und zum Schutz der darin gespeicherten Daten zur Verfügung ("Manage Secrets and Protect Sensitive Data"). Im Dezember 2018 hat das Projekt Version 1.0 erreicht und liegt damit erstmals in einer stabilen Edition vor. Höchste Zeit für die ersten Schritte mit Vault in einer Entwicklungsumgebung.
Der Artikel konzentriert sich auf den erstmaligen Einsatz von Vault im Unternehmen und stellt dazu eine bottom-up-Variante aus der Entwicklung vor. Vault kommt zunächst im unkritischen internen Entwicklungsbereich zur Verwendung, das heißt in der typischen Dev-Umgebung. Int- und vor allem Prod-Umgebungen bleiben zunächst außen vor. Der Vorteil des Vorgehens ist das Sammeln von Erfahrungen mit Vault, ohne die Risiken eines zentralen Safes mit Zugängen zu den kritischen Unternehmenssystemen im Internet zu exponieren. Nachdem Anwender genügend Erfahrungen mit Vault gesammelt haben und die eher traditionellen Ops-Themen rund um dessen sicheren Betrieb, Zugänge und Verfügbarkeit geklärt sind, kann man die Int- und Prod-Umgebungen ebenfalls auf Vault umstellen.
Die Grundlagen von Vault
Vault speichert alle Daten ausschließlich verschlüsselt im konfigurierten Storage-Backend. Storage-Backends sind beispielsweise in-memory (und damit flüchtig), das Filesystem oder etwa Consul. Consul – eigentlich ein Tool für Service Discovery, Monitoring und Konfiguration – stellt hierbei eine verteilte und hochverfügbare Speichervariante für Vault zur Verfügung. In welcher Form man die Daten im Storage-Backend speichern kann und welche Möglichkeiten zur Verfügung stehen, hängt zusätzlich von der Secrets-Engine ab. Eine einfache Variante stellt das Key-Value-Format dar, das Daten in der Form password=Andgd838/d3K speichert.
Datenbanken sind ebenfalls denkbare Secret Engines, die zusätzliche Features wie eine dynamische Passwortgenerierung erlauben. Hier fragt ein User (beziehungsweise eine Anwendung) nach den Zugangsdaten für eine Datenbank und erhält sie mit einer Time-To-Live (TTL) versehen individuell für die Anfrage zurück. Nach Ablauf der TTL kümmert sich Vault um die Deaktivierung des Zugangs. Gleiches ist beispielsweise auch für Cloud-Zugänge umsetzbar.
Wie alles in Vault sind Geheimnisse über Pfade erreichbar. Der Key-Value-Store ist per default über den Pfad secret erreichbar. Alles darunter lässt sich frei erstellen. Die von Spring vorgesehene Variante secret/APPLIKATIONSNAME beziehungsweise mit optionalem Profil secret/APPLIKATIONSNAME/PROFIL ist für Nicht-Spring-Webanwendungen gleichermaßen zu empfehlen. Um dort Daten abzulegen, können Entwickler sie in der Kommandozeile übergeben::
vault write secret/dummy-application
database.user="dummy-user" database.password="dummy-password"
Es bietet sich an, mit dem einfachen Key-Value-Store zu beginnen und die Geheimnisse aus den Webanwendungen zunächst statisch in Vault abzulegen. Wer bei Webanwendungen wie in den folgenden Beispielen auf Spring Boot setzt, findet besonders einfache und umfangreiche Integrationsmöglichkeiten von Vault vor. Die vollständigen Sourcen dazu sind auf GitHub verfügbar. Über die Vault-REST-Schnittstellen können jedoch auch andere Webanwendungen auf Vault zugreifen und dort abgelegte Geheimnisse nutzen.
Vault in der Entwicklung
Für den schnellen und einfachen Einsatz in der Entwicklung stellt Vault einen Dev-Modus zur Verfügung. Hierfür können Nutzer Vault mit vault server -dev starten. Die verwendete Kommandozeile ist direkt für Vault authentifiziert, es gibt nur einen Key, und Vault steht geöffnet für die Entwicklung bereit. Was sich für eine Entwicklungsumgebung praktisch anhört, hat in der täglichen Praxis einen entscheidenden Nachteil: Vault speichert alle Daten nur in-memory, ein Neustart von Vault oder des Servers löscht alle enthaltenen Entwicklungsdaten. Der Dev-Modus ist damit nach Erfahrung des Autors nur für die ersten (lokalen) Schritte mit Vault brauchbar, nicht aber für den Einsatz in der Entwicklung.
Wer Vault in einem Entwicklungsteam einsetzen möchte, muss auf den Prod-Modus zurückgreifen und etwas mehr Aufwand in dessen Konfiguration und Betrieb investieren. Der Lohn der Mühe ist eine vollständige Vault-Installation mit aller Flexibilität für Entwickler.
Die folgende Beschreibung und Konfiguration geht von einem Vault-Einsatz in einem internen Entwicklungsteam aus. Hochverfügbarkeit spielt keine Rolle. Geheimnisse sollen sicher in Vault landen, allerdings bei geringem Konfigurations- und Administrationsaufwand. Das erfordert gewisse Abstriche bei der Sicherheit, die in Produktion unverzeihlich wären, in der Entwicklung aber durchaus akzeptabel sind. Wichtig ist allerdings, dass Vault nur die Daten der unkritischen Umgebungen enthält; keinesfalls dürfen Entwickler Produktionsdaten darin ablegen.
