Eine Einführung in den Tresorraum

Die Architektur von Vault ist täuschend einfach. Seine Hauptkomponenten sind:

Geheimnisse ** Eine Anzahl von __secret-Engines, __e für jeden unterstützten Geheimtyp

Art

Durch das Delegieren der gesamten geheimen Abwicklung an Vault können wir einige Sicherheitsprobleme verringern:

wenn nötig und verwerfen ** Wir können kurzlebige Geheimnisse verwenden, wodurch das "Fenster von" eingeschränkt wird

Gelegenheit “, wo ein Angreifer ein gestohlenes Geheimnis verwenden kann

Vault verschlüsselt alle Daten mit einem Verschlüsselungsschlüssel, bevor sie in den Laden geschrieben werden. Dieser Verschlüsselungsschlüssel wird durch einen weiteren Schlüssel - den Hauptschlüssel, der nur beim Start verwendet wird - verschlüsselt.

Ein wichtiger Punkt bei der Implementierung von Vault ist, dass der Hauptschlüssel nicht auf dem Server gespeichert wird. Dies bedeutet, dass nicht einmal Vault nach dem Start auf die gespeicherten Daten zugreifen kann. An diesem Punkt wird gesagt, dass sich eine Vault-Instanz in einem versiegelten Zustand befindet.

Später gehen wir die Schritte durch, die zum Generieren des Hauptschlüssels und zum Entsiegeln einer Vault-Instanz erforderlich sind.

Nach dem Versiegeln kann Vault API-Anforderungen akzeptieren. Für diese Anforderungen ist natürlich eine Authentifizierung erforderlich, sodass wir wissen, wie Vault Clients authentifiziert und entscheidet, was sie tun können oder nicht.

Um auf Geheimnisse in Vault zugreifen zu können, muss sich ein Client mit einer der unterstützten Methoden authentifizieren. Die einfachste Methode verwendet Tokens. Hierbei handelt es sich lediglich um Zeichenfolgen, die bei jeder API-Anforderung mit einem speziellen HTTP-Header gesendet werden.

Bei der Erstinstallation generiert Vault automatisch ein "Root-Token".

Dieses Token ist das Äquivalent als Root-Superuser in Linux-Systemen. Daher sollte seine Verwendung auf ein Minimum beschränkt sein. Als bewährte Methode sollten Sie dieses Stammtoken verwenden, um andere Token mit weniger Berechtigungen zu erstellen und sie dann zu widerrufen. Dies ist jedoch kein Problem, da wir später ein anderes Root-Token mit nicht gesiegelten Schlüsseln generieren können.

Vault unterstützt auch andere Authentifizierungsmechanismen wie LDAP-, JWT- und TLS-Zertifikate. Alle diese Mechanismen bauen auf dem grundlegenden Token-Mechanismus auf: Sobald Vault unseren Client überprüft, wird ein Token bereitgestellt, mit dem wir auf andere APIs zugreifen können.

Mit Token sind einige Eigenschaften verknüpft. Die Haupteigenschaften sind:

Wenn nichts anderes gesagt wird, bilden die von Vault erstellten Token eine Eltern-Kind-Beziehung. Ein untergeordnetes Token kann höchstens dieselbe Berechtigungsstufe wie das übergeordnete Element besitzen.

Das Gegenteil trifft nicht zu: Wir können - und tun dies in der Regel - ein untergeordnetes Token mit restriktiven Richtlinien. Ein weiterer wichtiger Aspekt dieser Beziehung:

Wenn ein Token ungültig wird, werden auch alle untergeordneten Token und ihre Nachkommen ungültig gemacht

Hier haben wir die HCL-Syntax (Hashicorp’s Configuration Language) verwendet, um unsere Richtlinie zu definieren. Vault unterstützt auch JSON für diesen Zweck. In unseren Beispielen halten wir uns jedoch an HCL, da es einfacher zu lesen ist.

Ein weiterer wichtiger Aspekt der Politik ist, dass sie die Lazy-Evaluation nutzen. Dies bedeutet, dass wir eine bestimmte Richtlinie aktualisieren können und alle Token sofort betroffen sind.

Die bisher beschriebenen Richtlinien werden auch als Zugriffssteuerungslisten-Richtlinien oder ACL-Richtlinien bezeichnet. Vault unterstützt außerdem zwei zusätzliche Richtlinientypen: EGP- und RGP-Richtlinien. Diese sind nur in den kostenpflichtigen Versionen verfügbar und erweitern die grundlegende Richtliniensyntax um die Unterstützung Sentinel .

Wenn verfügbar, können wir in unseren Richtlinien zusätzliche Attribute wie Tageszeit, mehrere Authentifizierungsfaktoren, Herkunft des Client-Netzwerks usw. berücksichtigen. Beispielsweise können wir eine Richtlinie definieren, die den Zugriff auf ein bestimmtes Geheimnis nur während der Geschäftszeiten ermöglicht.

Weitere Einzelheiten zur Richtliniensyntax finden Sie in der Dokumentation zu Vault .

Später verwenden wir denselben Pfad, um dasselbe Paar oder dieselben Paare abzurufen. Mehrere Paare können unter demselben Pfad gespeichert werden.

Vault unterstützt drei Arten von Schlüsselwertgeheimnissen:

Versionen ** Cubbyhole , ein spezieller Typ von nicht versionierten Schlüsselpaaren, deren Werte

sind auf ein bestimmtes access-token (mehr dazu später) beschränkt.

Schlüsselwert-Geheimnisse sind von Natur aus statisch, daher gibt es kein Konzept für einen damit verbundenen Ablauf. Der Hauptanwendungsfall für diese Art von Geheimnis ist das Speichern von Anmeldeinformationen für den Zugriff auf externe Systeme, z. B. API-Schlüssel.

In solchen Szenarien handelt es sich bei den Aktualisierungen der Berechtigungsnachweise um einen halbmanuellen Prozess, bei dem normalerweise neue Berechtigungsnachweise angefordert werden müssen und die Vault-Befehlszeile oder die Benutzeroberfläche zur Eingabe der neuen Werte verwendet wird.

Alle diese folgen demselben Verwendungsmuster. Zunächst konfigurieren wir die geheime Engine mit den Details, die erforderlich sind, um eine Verbindung zum zugehörigen Dienst herzustellen.

Dann definieren wir ein oder mehrere Rollen, die die eigentliche geheime Schöpfung beschreiben.

Nehmen wir als Beispiel die geheime Datenbank-Engine. Zunächst müssen wir Vault mit allen Benutzerdatenbankverbindungsdetails konfigurieren, einschließlich der Anmeldeinformationen eines bereits vorhandenen Benutzers mit Administratorrechten, um neue Benutzer zu erstellen.

Dann erstellen wir eine oder mehrere Rollen (Vault-Rollen, nicht Datenbankrollen), die die tatsächlichen SQL-Anweisungen enthalten, die zum Erstellen eines neuen Benutzers verwendet werden. Dazu gehören in der Regel nicht nur die Anweisung zur Benutzererstellung, sondern auch alle erforderlichen grant -Anweisungen, die für den Zugriff auf Schemaobjekte (Tabellen, Ansichten usw.) erforderlich sind.

Wenn ein Client auf die entsprechende API zugreift, erstellt Vault mit den angegebenen Anweisungen einen neuen temporären Benutzer in der Datenbank und gibt seine Berechtigungsnachweise zurück ** . Der Client kann dann diese Anmeldeinformationen verwenden, um während des Zeitraums, der durch das Time-to-Live-Attribut der angeforderten Rolle definiert wird, auf die Datenbank zuzugreifen.

Sobald ein Berechtigungsnachweis seine Ablaufzeit erreicht, widerruft Vault automatisch alle mit diesem Benutzer verknüpften Berechtigungen. Ein Client kann Vault auch dazu auffordern, diese Berechtigungsnachweise zu erneuern. Der Erneuerungsprozess wird nur durchgeführt, wenn er vom jeweiligen Datenbanktreiber unterstützt und von der zugeordneten Richtlinie zugelassen wird.

Geheime Engines des Typs behandeln kryptografische Funktionen wie Verschlüsselung, Entschlüsselung, Signieren usw. Alle diese Vorgänge verwenden kryptografische Schlüssel, die intern von Vault generiert und gespeichert werden ** . Wenn dies nicht ausdrücklich gesagt wird, wird Vault niemals einen bestimmten kryptographischen Schlüssel verfügbar machen.

Mit der zugehörigen API können Clients Vault-Klartextdaten senden und eine verschlüsselte Version davon erhalten. Das Gegenteil ist auch möglich: Wir können verschlüsselte Daten senden und erhalten den ursprünglichen Text zurück.

Derzeit gibt es nur eine Engine dieses Typs: die Transit Engine.

Diese Engine unterstützt gängige Schlüsseltypen wie RSA und ECDSA sowie __Convergent Encryption. Bei Verwendung dieses Modus führt ein bestimmter Klartextwert immer zu demselben Cyphertext-Ergebnis. Diese Eigenschaft ist in manchen Anwendungen sehr nützlich.

Mit diesem Modus können Sie beispielsweise Kreditkartennummern in einer Transaktionsprotokolltabelle verschlüsseln. Bei der konvergenten Verschlüsselung wäre der Wert der verschlüsselten Kreditkarte bei jedem Einfügen einer neuen Transaktion gleich, wodurch die Verwendung normaler SQL-Abfragen für Berichte, Suchen usw. ermöglicht wird.

Vault verwendet eine Konfigurationsdatei im HCL- oder JSON-Format. Die folgende Datei definiert die gesamte Konfiguration, die zum Starten unseres Servers mit einem Dateispeicher und einem selbstsignierten Zertifikat erforderlich ist:

Lassen Sie uns jetzt Vault ausführen. Öffnen Sie eine Befehlsshell, wechseln Sie in das Verzeichnis mit unserer Konfigurationsdatei und führen Sie den folgenden Befehl aus:

Vault wird gestartet und zeigt einige Initialisierungsmeldungen an. Sie enthalten die Version, einige Konfigurationsdetails und die Adresse, unter der die API verfügbar ist. Das ist es - unser Vault-Server ist betriebsbereit.

Unser Vault-Server läuft jetzt, aber da dies der erste Lauf ist, müssen wir ihn initialisieren.

Öffnen wir eine neue Shell und führen Sie die folgenden Befehle aus,

Hier haben wir einige Umgebungsvariablen definiert, so dass wir sie nicht jedes Mal als Parameter an Vault übergeben müssen:

In unserem Fall verwenden wir VAULT CACERT__, damit wir mit HTTPS auf die API von Vault zugreifen können. Wir brauchen das, weil wir selbstsignierte Zertifikate verwenden.

Dies wäre für Produktionsumgebungen nicht erforderlich, in denen wir normalerweise auf von CA signierte Zertifikate zugreifen können.

Nachdem Sie den obigen Befehl ausgeführt haben, sollte eine Meldung wie folgt angezeigt werden:

Die fünf ersten Zeilen sind die Master-Schlüsselfreigaben, die wir später verwenden werden, um den Speicher von Vault aufzuheben. Bitte beachten Sie, dass Vault während der Initialisierung nur die Freigaben des Master-Schlüssels anzeigt - und nie mehr. ** Beachten Sie und bewahren Sie sie sicher auf. Andernfalls verlieren wir beim Neustart des Servers den Zugriff auf unsere Geheimnisse!

Beachten Sie auch das root token , da wir es später brauchen werden.

Im Gegensatz zu nicht verschließbaren Schlüsseln können ** Root-Token leicht zu einem späteren Zeitpunkt generiert werden. Da wir später Befehle ausgeben werden, für die ein Authentifizierungstoken erforderlich ist, speichern wir das Stammtoken jetzt in einer Umgebungsvariablen:

Lassen Sie uns unseren Serverstatus jetzt anzeigen, nachdem wir ihn mit dem folgenden Befehl initialisiert haben:

Wir können sehen, dass Vault immer noch versiegelt ist. Wir können auch den Fortschritt der Versiegelung verfolgen: „0/3“ bedeutet, dass Vault drei Anteile benötigt, aber bisher keine erhalten hat. Gehen wir voran und versorgen Sie es mit unseren Aktien.

Wir entfernen jetzt Vault, damit wir seine Geheimdienste nutzen können. Wir müssen drei der fünf Schlüsselaktien angeben, um den Entsiegelungsprozess abzuschließen:

Nach der Ausgabe druckt jeder Vault den Verlauf der Versiegelung einschließlich der benötigten Anzahl an Freigaben. Beim Senden der letzten Schlüsselfreigabe wird eine Nachricht wie folgt angezeigt:

Die Eigenschaft „Sealed“ ist in diesem Fall „false“. Dies bedeutet, dass Vault bereit ist, Befehle zu akzeptieren.

Zuerst speichern wir geheime Schlüssel-Wert-Paare und lesen sie zurück. Unter der Annahme, dass die zum Initialisieren von Vault verwendete Befehls-Shell noch geöffnet ist, verwenden wir den folgenden Befehl, um diese Paare unter dem Pfad secret/fakebank zu speichern:

Wir können diese Paare jetzt jederzeit mit dem folgenden Befehl wiederherstellen:

Dieser einfache Test zeigt uns, dass Vault so funktioniert, wie es sollte. Wir können jetzt einige zusätzliche Funktionen testen.

Bisher haben wir das Root-Token verwendet, um unsere Anfragen zu authentifizieren. Da ein Stamm-Token way zu mächtig ist, wird es als bewährte Methode angesehen, Token mit weniger Privilegien und kürzerer Lebensdauer zu verwenden.

Lassen Sie uns ein neues Token erstellen, das wir wie das Root-Token verwenden können, das jedoch nach einer Minute verfällt

$ export VAULT TOKEN=<token value> $ vault kv get secret/fakebank ======= Data ======= Key Value --- ----- api key abc1234 api__secret 1a2b3c4d

$ vault kv get secret/fakebank Error making API request.

URL: GET https://localhost:8200/v1/sys/internal/ui/mounts/secret/fakebank Code: 403. Errors:

$ cat > sample-policy.hcl <<EOF path "secret/fakebank" { capabilities =["read"]} EOF $ export VAULT__TOKEN=<root token> $ vault policy write fakebank-ro ./sample-policy.hcl Success! Uploaded policy: fakebank-ro

$ export VAULT TOKEN=<root token> $ vault token create -policy=fakebank-ro Key Value --- ----- token <token value> token accessor <token accessor value> token duration 768h token renewable true token policies ["default" "fakebank-ro"]identity policies []policies ["default" "fakebank-ro"]----

Lesen wir unsere geheimen Werte mit diesem Token:

So weit, ist es gut. Wir können Daten wie erwartet lesen. Mal sehen, was passiert, wenn wir versuchen, dieses Geheimnis zu aktualisieren:

Da in unserer Richtlinie das Schreiben nicht explizit zugelassen wird, gibt Vault einen Statuscode 403 - Access Denied zurück.

Als letztes Beispiel in diesem Artikel verwenden wir die Database Secret Engine von Vault, um dynamische Anmeldeinformationen zu erstellen. Wir gehen hier davon aus, dass wir lokal einen MySQL-Server haben und mit "root" -Privilegien darauf zugreifen können. Wir werden auch ein sehr einfaches Schema verwenden, das aus einer einzigen Tabelle besteht - account .

Das zum Erstellen dieses Schemas verwendete SQL-Skript und der privilegierte Benutzer sind hier verfügbar.

Nun konfigurieren wir Vault für die Verwendung dieser Datenbank. Die Datenbankgeheimnis-Engine ist standardmäßig nicht aktiviert. Daher müssen wir dies beheben, bevor wir fortfahren können:

$ vault write database/config/mysql-fakebank \ plugin name=mysql-legacy-database-plugin \ connection url="{{username}}:{{password}}@tcp(127.0.0.1:3306)/fakebank" \ allowed__roles="** " \ username="fakebank-admin" \ password="Sup&rSecre7!"

$ vault write database/roles/fakebank-accounts-ro \ db name=mysql-fakebank \ creation statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON fakebank.** TO '{{name}}'@'%';"

$ vault read database/creds/fakebank-accounts-ro Key Value --- ----- lease id database/creds/fakebank-accounts-ro/0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 lease duration 1h lease__renewable true password <password> username <username>

$ mysql -h 127.0.0.1 -u <username> -p fakebank Enter password: MySQL[fakebank]> select ** from account; …​ omitted for brevity 2 rows in set (0.00 sec) MySQL[fakebank]> delete from account; ERROR 1142 (42000): DELETE command denied to user 'v-fake-9xoSKPkj1'@'localhost' for table 'account'