HashiCorp Vault: Industrie-Standard für Secrets-Management seit 2015

Was ist HashiCorp Vault?

HashiCorp Vault ist Mai 2026 das Industrie-Standard-Werkzeug für zentrales Secrets-Management. Es wurde 2015 von HashiCorp eingeführt und ist seitdem die Referenz für den Umgang mit API-Keys, Datenbank-Passwörtern, TLS-Zertifikaten und Verschlüsselungs-Schlüsseln in Unternehmens-Stacks. Praktisch jede Fortune-500-Firma mit DevOps-Reife setzt Vault ein, und auch im CH-KMU-Mittelstand ist Vault die häufigste Wahl ab etwa 20 Anwendungen aufwärts.

Im August 2023 hat HashiCorp die Lizenz von Mozilla Public License 2.0 (MPL-2.0, voll Open-Source) auf Business Source License 1.1 (BSL 1.1) umgestellt. BSL 1.1 ist nicht mehr Open-Source im OSI-Sinne, sondern eine Source-Available-Lizenz mit Wettbewerbs-Klausel: Anwender dürfen den Code lesen, modifizieren und kommerziell einsetzen -- aber nicht ein konkurrierendes Vault-as-a-Service-Produkt verkaufen. Für interne Eigennutzung im KMU ist das praktisch irrelevant. Für Hosting-Provider und SaaS-Plattformen, die Vault als Teil ihres Angebots verkaufen wollen, ist es ein Stopper. Reaktion der Community: der Linux-Foundation-Fork OpenBao, der auf Vault 1.14 (letzter MPL-Stand) basiert und weiter unter MPL-2.0 entwickelt wird.

Die Architektur von Vault basiert auf vier Konzepten. (1) Secrets-Engines speichern oder erzeugen Secrets. KV v2 für statische Werte, Database-Engine für dynamische DB-Credentials, PKI-Engine für kurzlebige TLS-Zertifikate, AWS-Engine für dynamische AWS-IAM-Tokens, Transit-Engine für Verschlüsselung-as-a-Service. (2) Auth-Methoden ermitteln, wer ein Token bekommen darf. AppRole für Server-zu-Server, Kubernetes Service Account für K8s-Workloads, OIDC für menschliche Nutzer mit SSO-Integration, GitHub-Token für Entwickler-Tooling. (3) Policies regeln, welcher Token welche Secrets-Pfade lesen oder schreiben darf -- HCL-basierte Regelsprache mit Allow/Deny und Capability-Listen. (4) Audit Devices protokollieren jeden Vault-Zugriff: wer, wann, welcher Pfad, Erfolg oder Fehler -- die Audit-Engine kann nicht abgeschaltet werden, ohne Vault selbst zu sealen.

Vault startet immer im sealed-Zustand und braucht ein Unseal, bevor es Secrets ausgibt. Unseal-Modi: (a) Shamir Secret Sharing mit 5 Keys an 5 verschiedene Personen, 3 davon nötig zum Unsealen; (b) Auto-Unseal via Cloud-KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) -- der Unseal-Schlüssel liegt im Cloud-KMS und wird beim Start automatisch geholt. Auto-Unseal ist Mai 2026 der Standard, weil manuelles Shamir-Unsealen bei Server-Reboots operativ schmerzhaft ist.

Warum es für CH-KMU mit > 5 Services Pflicht ist

Drei regulatorische und drei praktische Argumente machen Vault Mai 2026 zur Pflicht-Schicht ab einer bestimmten Setup-Grösse.

Regulatorisch: Art. 8 revFADP verlangt Schutzmassnahmen nach dem Stand der Technik. Klartext-Secrets in .env-Files auf jedem Server ist 2026 nicht mehr Stand der Technik. PCI-DSS v4.0 verlangt Rotation von Schlüsseln alle 90 Tage und zentrale Schlüssel-Verwaltung -- ohne Vault oder Äquivalent ist das nicht praktikabel umsetzbar. ISO 27001 verlangt im Annex A.10 zentrale Schlüssel-Verwaltung. SOC 2 Type II verlangt nachweisbare Rotation und Zugriffs-Logs.

Berufsgeheimnis: StGB Art. 321 verlangt, dass kein Dritter unautorisiert auf Mandantendaten zugreift. Ein API-Key für das LLM, das Mandanten-Anfragen verarbeitet, ist selbst ein Berufsgeheimnis-relevanter Wert. Wer den Schlüssel verliert, gibt einem Unbekannten Zugang zu allen Mandanten-Anfragen der letzten Monate. Vault liefert Audit-Trail darüber, wer wann welchen Secret abgerufen hat -- das ist die Grundlage einer Compromise-Analyse.

Meldepflicht 72 Stunden: Das revFADP / revDSG verlangt Meldepflicht innert 72 Stunden bei Datenpannen mit hohem Risiko. Ohne Vault-Audit-Trail lässt sich nicht sagen, welche Daten betroffen waren -- die Meldung an den EDÖB wird unsicher und damit potenziell unvollständig. Mit Vault kann man genau zeigen: dieser Token hat zwischen 14:23 und 14:47 die folgenden 12 Secrets abgerufen, kein anderer Token wurde aktiv.

Praktisch: GitHub-Scans finden Mai 2026 täglich tausende kompromittierter API-Keys in öffentlichen Repositories. Ein versehentlicher git push mit einer .env-Datei kann innert Minuten zu Krypto-Mining-Schäden, Spam-Wellen oder Daten-Diebstahl führen. Vault verhindert das strukturell -- Anwendungen holen Secrets zur Laufzeit aus Vault, sie liegen nie im Repository.

Compromise-Antwort in Minuten: Bei einem Secret-Compromise (z.B. ein Entwickler hat versehentlich einen API-Key in einen Slack-Thread kopiert) wird der Wert sofort revoked und neu generiert. Vault macht das in einem Schritt -- alle Anwendungen, die den Token noch nutzen, bekommen einen 403 und holen sich beim nächsten Zyklus den neuen Wert. Ohne Vault müsste man manuell jede Anwendung neu starten.

Dynamic Secrets: Vault kann Datenbank-Credentials erst beim Job-Lauf erzeugen und nach 1 Stunde verfallen lassen. Das reduziert das Angriffs-Fenster bei einem Compromise auf Minuten statt Wochen. Statische Datenbank-Passwörter in Konfig-Dateien sind 2026 nicht mehr Stand der Technik.

Setup, Engines und Beispiel-Integration

Ein produktives Vault-Setup besteht aus drei Nodes im HA-Cluster mit Raft-Storage (eingebaut) oder Consul-Storage. Hetzner-Dedicated oder Infomaniak Public Cloud sind gute Plattformen.

Docker-Compose für Single-Node-KMU-Setup:

```yaml version: "3.8" services: vault: image: hashicorp/vault:1.17 container_name: vault restart: unless-stopped cap_add: - IPC_LOCK environment: - VAULT_ADDR=http://0.0.0.0:8200 - VAULT_LOCAL_CONFIG={"storage":{"raft":{"path":"/vault/data","node_id":"vault-1"}},"listener":{"tcp":{"address":"0.0.0.0:8200","tls_disable":1}},"ui":true,"api_addr":"http://vault:8200","cluster_addr":"https://vault:8201","disable_mlock":true,"seal":{"awskms":{"region":"eu-central-1","kms_key_id":"alias/vault-unseal"}}} ports: - "127.0.0.1:8200:8200" volumes: - ./vault-data:/vault/data - ./vault-logs:/vault/logs command: vault server -config=/vault/config/vault.hcl ```

Initialisierung beim ersten Start: vault operator init -recovery-shares=5 -recovery-threshold=3 erzeugt 5 Recovery-Keys (3 zum Unsealen nötig). Bei Auto-Unseal via AWS KMS wird der Master-Key dort gehalten; die Recovery-Keys sind Backup, falls KMS-Zugriff verloren geht.

Beispiel: KV-Engine für API-Keys aktivieren ```bash vault secrets enable -path=kv kv-v2 vault kv put kv/openai api_key=sk-proj-xyz... vault kv put kv/stripe api_key=sk_live_xyz... webhook_secret=whsec_xyz... ```

Beispiel: Database-Engine für dynamische Postgres-Credentials ```bash vault secrets enable database vault write database/config/postgres-treuhand \ plugin_name=postgresql-database-plugin \ connection_url="postgresql://{{username}}:{{password}}@postgres.treuhand.local:5432/main" \ allowed_roles="readonly,readwrite" \ username="vault-admin" password="SecretAdmin2026" vault write database/roles/readonly \ db_name=postgres-treuhand \ creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \ default_ttl="1h" max_ttl="24h" ```

Anwendung ruft beim Start: GET /v1/database/creds/readonly -> bekommt User+Passwort+TTL 1 Stunde. Nach 1 Stunde verfällt der DB-User automatisch.

AppRole für Server-Auth ```bash vault auth enable approle vault write auth/approle/role/treuhand-app \ token_policies="treuhand-policy" \ token_ttl=1h token_max_ttl=4h vault read -field=role_id auth/approle/role/treuhand-app/role-id vault write -field=secret_id -f auth/approle/role/treuhand-app/secret-id ```

Die Anwendung erhält RoleID und SecretID. Beim Start: vault write auth/approle/login role_id=<role> secret_id=<secret> -> erhält ein Token mit 1h TTL und der Policy treuhand-policy.

Vault-Agent als Sidecar-Prozess vereinfacht die Integration für bestehende Anwendungen, die mit .env-Files arbeiten: Vault-Agent rendert eine Template-Datei mit aktuellen Secrets nach /run/secrets/.env, die Anwendung liest wie gewohnt.

Vault-Einführung in 5 Schritten

1. 01Inventar aller Secrets: .env-Files, Konfig-Dateien, Konstanten im Code, geteilte Passwörter in Slack/Notion auflisten; Sensitivitäts-Klassifikation (gering/mittel/hoch).
2. 02Vault-Cluster aufsetzen: 3 Nodes auf Hetzner Dedicated, Raft-Storage, Auto-Unseal via AWS KMS oder Shamir-Keys (3-of-5); Audit-Engine zu Loki/Splunk.
3. 03Secrets-Engines aktivieren: KV v2 für statische Werte, Database für dynamische DB-Creds, PKI für kurzlebige Zertifikate; pro Service eine separate Engine-Path.
4. 04Auth-Methoden konfigurieren: AppRole für Server-zu-Server (1h-Tokens), OIDC für menschliche Nutzer über SSO (Authentik/Authelia), Policies nach Least-Privilege.
5. 05Anwendungen migrieren: Vault-Agent als Sidecar für File-basierte Apps, SDK-Integration für Code-Anbindung; statische Secrets alle 90 Tage rotieren, Compromise-Runbook (72h-Meldung) dokumentieren.

Wann Vault einsetzen

Vault ist Mai 2026 in folgenden Konstellationen die richtige Wahl.

KMU mit > 5 Anwendungen und > 1 Mitarbeiter: ab dieser Grösse wird der manuelle Aufwand für Secrets-Rotation untragbar. Jeder Personalwechsel verlangt Rotation aller Schlüssel, die der Mitarbeiter kannte -- ohne Vault unmöglich nachzuvollziehen. Mit Vault: Token revoken, Mitarbeiter-OIDC-Account deaktivieren, fertig.

Anwendungen mit kostenpflichtigen API-Keys über CHF 200 pro Monat: Stripe, OpenAI, Anthropic, Brevo, Twilio. Ein geleakter Key kann Schaden im Hunderten-Franken-Bereich anrichten. Vault macht den Diff zwischen "key liegt in Git für immer" und "key liegt nur in Vault und wird alle 90 Tage rotiert".

Compliance-Pflicht (PCI-DSS, ISO 27001, SOC 2): alle drei verlangen zentrales Secrets-Management. Vault ist die kanonische Antwort, die Auditoren ohne Diskussion akzeptieren.

Multi-Server-Setups mit gemeinsamen Secrets: drei Server, die alle das gleiche Stripe-Webhook-Secret brauchen. Ohne Vault: das Secret liegt in drei .env-Files, bei Rotation müssen drei Server angefasst werden, Sync-Risiko. Mit Vault: das Secret liegt einmal in Vault, alle drei Server holen es zur Laufzeit, Rotation in einem Schritt.

Datenbank-Zugriff mit Mandanten-Daten: statische DB-Passwörter sind 2026 nicht mehr akzeptabel. Vault Database Engine erzeugt pro Job-Lauf einen DB-User mit 1h TTL. Das Angriffsfenster bei Compromise schrumpft von Wochen auf Stunden.

Der Schwellenwert nach unten: Solo-Entwickler mit 1-2 Hobby-Projekten ohne Kunden-Daten braucht Vault nicht. Eine verschlüsselte .env.encrypted-Datei mit GPG plus 1Password Personal-Account reicht. Ab 2-Personen-Setups mit echten Mandanten-Daten beginnt der Vault-Bereich.

Wann Vault zu viel ist

Drei Fälle, in denen Vault Mai 2026 die falsche Wahl ist.

Solo-Setups oder Hobby-Projekte ohne Kundendaten: Vault braucht 1-2 Tage Wartung pro Quartal (Unseal-Key-Backup, HA-Cluster-Health, Audit-Log-Review). Bei einem Solo-Hobby-Projekt mit 2-3 Secrets ist das überdimensioniert. Pragmatische Alternative: 1Password Personal mit Secrets-Feature, oder Bitwarden Personal mit Secrets-Manager.

Reine Cloud-Native-Setups auf AWS oder Azure: wenn die gesamte Infrastruktur auf AWS oder Azure läuft, ist AWS Secrets Manager oder Azure Key Vault häufig die effizientere Wahl. Tiefe Integration mit IAM-Rollen, kein zusätzlicher Cluster zu betreiben, kein Unseal-Management. Vault gibt mehr Flexibilität (Multi-Cloud, on-prem), aber auch mehr Operations-Last.

Strikte OSS-Politik im Unternehmen: BSL 1.1 ist nicht Open-Source im OSI-Sinne. Wer eine strikte OSS-Politik hat oder ein Audit auf "nur OSI-zertifizierte Lizenzen" hat, kommt um OpenBao nicht herum -- den Linux-Foundation-Fork von Vault 1.14 unter MPL-2.0. Funktional Mai 2026 etwa 90 Prozent von Vault.

Generelle Fallen bei Vault-Deployments: (a) Auto-Unseal via Cloud-KMS ohne Backup-Recovery-Keys -- bei KMS-Ausfall ist der Cluster nicht startbar. (b) Audit-Logs nicht in eine SIEM-Pipeline gespiegelt -- bei Vault-Crash sind sie weg. (c) Policies zu permissiv -- ein Token mit "kv/*" liest alle Secrets, das widerspricht dem Least-Privilege-Prinzip. (d) Vault aufsetzen, aber Anwendungen weiter mit .env-Files versorgen -- Vault ist dann nur Theater, die Secrets liegen weiterhin in Klartext auf den Servern. (e) Token-TTL zu lang setzen (24h+) -- erhöht das Angriffs-Fenster bei Token-Diebstahl. Token-TTL 1h ist Standard.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. HashiCorp Vault -- official documentation · 2026-05
2. HashiCorp -- BSL 1.1 license FAQ · 2026-03
3. OpenBao -- Linux Foundation fork · 2026-04
4. NIST SP 800-57 -- Recommendation for Key Management Part 1 · 2026-02
5. OWASP Secrets Management Cheat Sheet · 2026-03