Handbuch Technik API Admin

Multi-Vault-Verwaltung

Mehrere Tresore auf einem Server betreiben. Jeder Vault ist ein eigenstaendiger, verschluesselter Container mit eigenen Recipients und eigener Zugriffskontrolle.

Konzept

Jeder Vault ist ein eigenes Verzeichnis unterhalb von --vault-root. Innerhalb dieses Verzeichnisses werden die age-Keys und verschluesselten Eintraege gespeichert. Vaults sind vollstaendig isoliert — es gibt keinen Cross-Vault-Zugriff. Ein Benutzer, der Zugriff auf Vault A hat, kann nicht auf Eintraege in Vault B zugreifen, selbst wenn beide auf demselben Server liegen.

Dieses Modell erlaubt es, auf einem einzigen PluriKey-Server verschiedene Anwendungsbereiche sauber zu trennen: private Passwoerter, Firmen-Zugangsdaten und Team-Credentials koennen koexistieren, ohne sich gegenseitig zu beeinflussen.

Vault erstellen

Mit dem CLI wird ein neuer Vault initialisiert. Der Befehl legt das Verzeichnis an und erzeugt die notwendigen Schluessel- und Metadaten-Dateien:

plurikey-cli vault init --name "firmen-vault" --vault-root /opt/plurikey/vaults

Der init-Prozess erstellt automatisch:

  • .age-recipients — Liste der age-Public-Keys, die Eintraege entschluesseln duerfen
  • .age-identities — Verschluesselte Private Keys fuer diesen Vault
  • vault.json — Vault-Metadaten (Name, Erstelldatum, Version)
  • entries/ — Verzeichnis fuer die verschluesselten Eintraege

Verzeichnisstruktur

/opt/plurikey/vaults/ ├── default/ │ ├── .age-recipients │ ├── .age-identities │ ├── entries/ │ │ ├── github.com.age │ │ └── mail.example.age │ └── vault.json ├── firmen-vault/ │ ├── .age-recipients │ ├── .age-identities │ ├── entries/ │ └── vault.json └── privat/ ├── ...

Recipients verwalten

Jeder Vault hat seine eigene Recipient-Liste. Nur Benutzer, deren age-Public-Key in .age-recipients eingetragen ist, koennen die Eintraege dieses Vaults entschluesseln.

# Recipient hinzufuegen
plurikey-cli vault add-recipient --vault "firmen-vault" --key "age1..."

# Alle Recipients eines Vaults anzeigen
plurikey-cli vault list-recipients --vault "firmen-vault"
Hinweis
Recipients sind age-Public-Keys. Jeder Empfaenger kann die Vault-Eintraege entschluesseln. Beim Hinzufuegen eines Recipients werden bestehende Eintraege automatisch fuer den neuen Key re-encrypted.

Zugriffskontrolle

Multi-Vault nutzt mehrere Ebenen der Zugriffskontrolle:

MechanismusBeschreibung
Vault-IsolationGetrennte Verzeichnisse, keine Cross-Vault-API
Recipientsage-Public-Keys pro Vault — nur eingetragene Keys koennen entschluesseln
DateisystemUnix-Permissions, chown pro Vault moeglich
API-Ebene--vault Parameter bei jedem Request — Server prueft Berechtigung

API-Zugriff

Wenn mehrere Vaults existieren, muss bei jedem API-Request der gewuenschte Vault angegeben werden. Der vault-Parameter ist Pflicht, sobald mehr als ein Vault konfiguriert ist:

# Eintraege eines bestimmten Vaults abrufen
curl http://localhost:8200/api/v1/entries?vault=firmen-vault

# Eintrag in einem Vault erstellen
curl -X POST http://localhost:8200/api/v1/entries?vault=firmen-vault \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com","username":"admin","password":"..."}'

# Alle verfuegbaren Vaults auflisten
curl http://localhost:8200/api/v1/vaults

Wird der vault-Parameter weggelassen und es existiert nur ein Vault, wird dieser automatisch verwendet. Bei mehreren Vaults liefert der Server einen 400 Bad Request mit Hinweis auf den fehlenden Parameter.

Best Practices

Empfehlungen
  • Ein Vault pro Verwendungszweck — z.B. privat, firma, team. Nicht alles in einen Vault werfen.
  • Separate Backup-Zeitplaene pro Vault — kritische Vaults haeufiger sichern als selten genutzte.
  • Recipients regelmaessig pruefen — ausgeschiedene Mitarbeiter muessen entfernt und Eintraege re-encrypted werden!
  • Vault-Namen: nur a-z, 0-9, Bindestrich. Keine Leerzeichen, Umlaute oder Sonderzeichen.