„Architektur

Vault ist ein komplexes System, das aus vielen verschiedenen Teilen besteht. Um sowohl den Benutzern als auch den Entwicklern von Vault zu helfen, ein mentales Modell zu erstellen, wie es funktioniert, dokumentiert diese Seite die Systemarchitektur.

Bevor wir die Architektur beschreiben, stellen wir ein Glossar mit Begriffen zur Verfügung, um zu verdeutlichen, worum es hier geht:

• Speicher-Backend – Ein Speicher-Backend ist für die dauerhafte Speicherung von verschlüsselten Daten verantwortlich. Backends werden von Vault nicht als vertrauenswürdig eingestuft und es wird lediglich erwartet, dass sie für eine dauerhafte Speicherung sorgen. Das Speicher-Backend wird beim Starten des Vaultservers konfiguriert.

• Barriere – Die Barriere ist kryptographischer Stahl und Beton um den Vault. Alle Daten, die zwischen Vault und dem Speicher-Backend fließen, passieren die Barriere. Die Barriere stellt sicher, dass nur verschlüsselte Daten herausgeschrieben werden und dass die Daten auf dem Weg hinein überprüft und entschlüsselt werden. Ähnlich wie bei einem Banktresor muss die Barriere „entsiegelt“ werden, bevor auf etwas im Inneren zugegriffen werden kann.

• Secrets Engine – Eine Secrets Engine ist für die Verwaltung von Secrets zuständig.Einfache Secrets Engines wie die „kv“ Secrets Engine geben bei einer Abfrage einfach das gleiche Secret zurück. Einige Secrets-Engines unterstützen die Verwendung von Richtlinien, um bei jeder Abfrage dynamisch ein Geheimnis zu erzeugen. Auf diese Weise können einzigartige Geheimnisse verwendet werden, die es Vault ermöglichen, feinkörnige Widerrufe und Richtlinienaktualisierungen durchzuführen. Ein Beispiel: Eine MySQL-Geheimnis-Engine könnte mit einer „Web“-Richtlinie konfiguriert werden. Wenn das „Web“-Geheimnis gelesen wird, wird ein neues MySQL-Benutzer/Kennwort-Paar mit einer begrenzten Anzahl von Privilegien für den Webserver generiert.

• Audit-Gerät – Ein Audit-Gerät ist für die Verwaltung von Audit-Protokollen verantwortlich.Jede Anfrage an Vault und jede Antwort von Vault durchläuft das konfigurierte Audit-Gerät. Dies bietet eine einfache Möglichkeit, Vault mit mehreren Audit-Protokollierungszielen unterschiedlicher Typen zu integrieren.

• Auth-Methode – Eine Auth-Methode wird verwendet, um Benutzer oder Anwendungen zu authentifizieren, die sich mit Vault verbinden. Nach der Authentifizierung gibt die Auth-Methode die Liste der anwendbaren Richtlinien zurück, die angewendet werden sollen. Vault nimmt einen authentifizierten Benutzer und gibt ein Client-Token zurück, das für künftige Anfragen verwendet werden kann. Die Methode userpass auth verwendet beispielsweise einen Benutzernamen und ein Kennwort zur Authentifizierung des Benutzers. Alternativ ermöglicht die github Auth-Methode Benutzern die Authentifizierung über GitHub.

• Client Token – Ein Client Token (auch bekannt als „Vault Token“) ist konzeptionell mit einem Session Cookie auf einer Website vergleichbar. Sobald sich ein Benutzer authentifiziert, gibt Vault ein Client-Token zurück, das für zukünftige Anfragen verwendet wird. Das Token wird vonVault verwendet, um die Identität des Kunden zu überprüfen und die geltenden ACL-Richtlinien durchzusetzen. Dieses Token wird über HTTP-Header übergeben.

• Geheimnis – Ein Geheimnis ist der Begriff für alles, was von Vault zurückgegeben wird und vertrauliches oder kryptografisches Material enthält. Nicht alles, was von Vault zurückgegeben wird, ist ein Geheimnis, zum Beispiel gelten Systemkonfiguration, Statusinformationen oder Richtlinien nicht als Geheimnisse. Geheimnisse sind immer mit einem Lease verbunden, d.h. Clients können nicht davon ausgehen, dass der geheime Inhalt unbegrenzt genutzt werden kann. Vault widerruft ein Geheimnis am Ende der Lease, und ein Operator kann eingreifen, um das Geheimnis zu widerrufen, bevor die Lease abgelaufen ist. Dieser Vertrag zwischen Vault und seinen Clients ist von entscheidender Bedeutung, da er Änderungen an Schlüsseln und Richtlinien ohne manuelle Eingriffe ermöglicht.

• Server – Vault hängt von einer lang laufenden Instanz ab, die als Server fungiert. Der Vault-Server stellt eine API zur Verfügung, mit der die Clients interagieren, und verwaltet die Interaktion zwischen allen Secrets-Engines, die Durchsetzung von ACLs und den Widerruf von Secrets-Leases. Eine serverbasierte Architektur entkoppelt die Clients von den Sicherheitsschlüsseln und -richtlinien, ermöglicht eine zentralisierte Audit-Protokollierung und vereinfacht die Verwaltung für die Betreiber.

„High-Level Overview

Ein Überblick über Vault auf höchster Ebene sieht wie folgt aus:

Lassen Sie uns beginnen, dieses Bild zu zerlegen. Es gibt eine klare Trennung der Komponenten, die sich innerhalb oder außerhalb der Sicherheitsbarriere befinden. Nur das Speicher-Backend und die HTTP-API liegen außerhalb, alle anderen Komponenten befinden sich innerhalb der Barriere.

Das Speicher-Backend ist nicht vertrauenswürdig und wird verwendet, um verschlüsselte Daten dauerhaft zu speichern.Wenn der Vault-Server gestartet wird, muss ihm ein Speicher-Backend zur Verfügung gestellt werden, damit die Daten über Neustarts hinweg verfügbar sind. Die HTTP-API muss ebenfalls beim Start vom Vault-Server gestartet werden, damit Clients mit ihr interagieren können.

Nach dem Start befindet sich der Vault in einem versiegelten Zustand. Bevor eine Operation mit dem Vault durchgeführt werden kann, muss er entsiegelt werden. Dies geschieht durch die Bereitstellung der unsealkeys. Bei der Initialisierung des Tresors wird ein Verschlüsselungsschlüssel erzeugt, der zum Schutz aller Daten verwendet wird. Dieser Schlüssel ist durch einen Hauptschlüssel geschützt. Standardmäßig verwendet Vault eine Technik, die als Shamir’s secret sharingalgorithm bekannt ist, um den Hauptschlüssel in 5 Anteile aufzuteilen, von denen 3 erforderlich sind, um den Hauptschlüssel zu rekonstruieren.

Die Anzahl der Anteile und der erforderliche Mindestschwellenwert können beide angegeben werden.Shamir’s Technik kann deaktiviert und der Hauptschlüssel direkt zum Entsiegeln verwendet werden. Sobald Vault den Verschlüsselungsschlüssel abruft, kann es die Daten im Speicher-Backend entschlüsseln und in den entsiegelten Zustand übergehen. Nach der Entsiegelung lädt Vault alle konfigurierten Prüfgeräte, Authentifizierungsmethoden und Secrets-Engines.

Die Konfiguration dieser Prüfgeräte, Authentifizierungsmethoden und Secrets-Engines muss in Vault gespeichert werden, da sie sicherheitsrelevant sind. Nur Benutzer mit den richtigen Berechtigungen sollten in der Lage sein, sie zu ändern, was bedeutet, dass sie nicht außerhalb der Barriere spezifiziert werden können. Durch die Speicherung im Vault werden alle Änderungen durch das ACL-System geschützt und durch Audit-Protokolle nachverfolgt.

Nachdem der Vault entsiegelt wurde, können Anfragen von der HTTP-API an den Core verarbeitet werden. Der Kern wird verwendet, um den Fluss der Anfragen durch das System zu verwalten, ACLs durchzusetzen und sicherzustellen, dass Audit-Protokolle erstellt werden.

Wenn sich ein Client zum ersten Mal mit Vault verbindet, muss er sich authentifizieren. Vault bietet konfigurierbare Authentifizierungsmethoden, die Flexibilität bei den verwendeten Authentifizierungsmechanismen bieten. Für Betreiber können menschenfreundliche Mechanismen wie Benutzername/Passwort oder GitHub verwendet werden, während Anwendungen öffentliche/private Schlüssel oder Token zur Authentifizierung verwenden können. Eine Authentifizierungsanfrage fließt durch den Kern und in eine Authmethode, die feststellt, ob die Anfrage gültig ist und eine Liste zugehöriger Richtlinien zurückgibt.

Richtlinien sind einfach eine benannte ACL-Regel. Die „root“-Richtlinie ist zum Beispiel eingebaut und erlaubt den Zugriff auf alle Ressourcen. Sie können eine beliebige Anzahl von benannten Richtlinien mit feiner Kontrolle über Pfade erstellen. Vault arbeitet ausschließlich im Whitelist-Modus, d. h., wenn der Zugriff nicht ausdrücklich über eine Richtlinie gewährt wird, ist die Aktion nicht erlaubt. Da einem Benutzer mehrere Richtlinien zugeordnet sein können, ist eine Aktion erlaubt, wenn eine der Richtlinien sie zulässt. Richtlinien werden in einem internen Richtlinienspeicher gespeichert und verwaltet. Dieser interne Speicher wird über das System-Backend manipuliert, das sich immer auf sys/ befindet.

Wenn eine Authentifizierung stattfindet und eine Authentifizierungsmethode einen Satz anwendbarer Richtlinien bereitstellt, wird ein neues Client-Token generiert und vom Token-Speicher verwaltet. Dieses Client-Token wird an den Client zurückgesendet und für künftige Anfragen verwendet, ähnlich wie ein Cookie, das von einer Website nach der Anmeldung eines Benutzers gesendet wird. Der Client-Token kann je nach Konfiguration der Authentifizierungsmethode mit einem Lease verbunden sein. Das bedeutet, dass das Client-Token möglicherweise regelmäßig erneuert werden muss, um eine Ungültigkeit zu vermeiden.

Nach der Authentifizierung werden die Anfragen unter Angabe des Client-Tokens gestellt. Das Token wird verwendet, um zu überprüfen, ob der Client autorisiert ist und um die entsprechenden Richtlinien zu laden. Die Richtlinien werden verwendet, um die Client-Anfrage zu autorisieren. Die Anfrage wird dann an die Secrets Engine weitergeleitet, die je nach Typ verarbeitet wird. Wenn die Secrets Engine ein Geheimnis zurückgibt, registriert der Kern es beim Ablaufmanager und fügt eine Lease-ID hinzu. Die Lease-ID wird von den Clients verwendet, um ihr Geheimnis zu erneuern oder zu widerrufen. Wenn ein Client die Lease ablaufen lässt, widerruft der Ablaufmanager automatisch das Geheimnis.

Der Kern verarbeitet die Protokollierung von Anfragen und Antworten an den Audit-Broker, der die Anfrage an alle konfigurierten Audit-Geräte weiterleitet. Außerhalb des Anfrageflusses führt der Kern bestimmte Hintergrundaktivitäten aus. Die Lease-Verwaltung ist von entscheidender Bedeutung, da sie es ermöglicht, abgelaufene Client-Tokens oder Geheimnisse automatisch zu widerrufen. Darüber hinaus behandelt Vault bestimmte partielle Fehlerfälle durch die Verwendung von Write-Ahead-Logging mit einem Rollback-Manager. Dies wird transparent innerhalb des Kerns verwaltet und ist für den Benutzer nicht sichtbar.

„Getting in Depth

Dies war ein kurzer Überblick über die Architektur von Vault auf hoher Ebene. Es gibt mehr Details für jedes der Untersysteme.

Für weitere Details, konsultieren Sie entweder den Code, fragen Sie im IRC oder wenden Sie sich an die Mailingliste.