Secrets-Management mit Vault: API-Keys, DB-Passwörter und JWT-Secrets richtig verwalten

Was sind Secrets und was ist Secrets-Management?

Secrets sind alle Zugangs-Daten, die ein Programm zur Laufzeit braucht und die nicht in den Quellcode gehören. API-Keys (Stripe, OpenAI, Brevo), Datenbank-Passwörter, JWT-Signatur-Schlüssel, OAuth-Client-Secrets, SSH-Private-Keys, TLS-Zertifikate, Verschlüsselungs-Schlüssel für Backups, Web-Hooks-Token. Jedes Mal, wenn ein Programm gegenüber einem anderen System Ich-bin-es sagen muss, geht das über ein Secret.

Secrets-Management ist die Praxis und das Tooling, das diese Werte zentral speichert, zugriffs-kontrolliert verteilt, regelmässig rotiert und beim Abruf protokolliert. Statt jeden Secret in einer .env-Datei auf jedem Server zu lagern, holt das Programm den Wert beim Start aus einer Vault-Instanz über einen kurz-lebigen Token.

Die Anti-Patterns sind die Mehrheit der Datenpannen Mai 2026. Erstens: .env-Files im Git-Repository – auch in privaten Repos ein Risiko, weil neue Entwicklerinnen, Praktikanten oder kompromittierte Notebooks plotzlich Zugriff haben. Zweitens: Hardcoded-Strings im Quellcode – der schlimmste Fall, weil ein veröffentlichter Open-Source-Push die Schlüssel weltweit verteilt. Drittens: Klartext-Backups der Konfigurations-Dateien – der Backup-Server wird zur Schatzkarte aller Schlüssel. Viertens: Geteilte Passwörter in Slack, E-Mail, Notion – niemand weiss, wer noch Zugriff hat, wenn ein Mitarbeitender geht.

Mai 2026 ist HashiCorp Vault unter Business Source Licence 1.1 das de-facto-Standard-Werkzeug. Es ist nicht mehr Apache 2.0, sondern hat eine Open-Source-Klausel mit Wettbewerbs-Klausel – für den Eigengebrauch im KMU ist das praktisch irrelevant, für kommerzielle SaaS-Reseller ein Punkt zu prüfen. Alternativen: OpenBao (Apache 2.0 Fork von Vault), Bitwarden Secrets Manager (OSS), Infisical (OSS), 1Password Secrets, AWS Secrets Manager, Azure Key Vault.

Warum es wichtig ist

Vier Argumente machen Secrets-Management nicht-verhandelbar. Erstens 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, Mail-Spam-Wellen oder Daten-Diebstahl führen. Die Schäden gehen schnell über CHF 10 000 hinaus.

Zweitens regulatorisch: Das revFADP / revDSG verlangt seit September 2023 eine Meldepflicht bei Datenpannen – innert kurzer Frist an den EDÖB. Ab Mai 2026 ist die Frist explizit auf 72 Stunden festgelegt, in Anlehnung an die EU-DSGVO-Praxis. Wer einen kompromittierten API-Key der Bank-Integration hat, hat eine meldepflichtige Datenpanne. Ohne Audit-Trail im Secrets-Manager lässt sich nicht sagen, welche Daten betroffen waren – die Meldung wird unsicher und damit potenziell unvollständig.

Drittens Compliance: PCI-DSS verlangt Rotation von Schlüsseln alle 90 Tage. ISO 27001 verlangt im Annex A.10 zentrale Schlüssel-Verwaltung. Wer Stripe-Zahlungen abwickelt oder ISO-Zertifizierung anstrebt, kommt um Secrets-Management nicht herum. Auch SOC 2 Type II verlangt nachweisbare Rotation und zugriffs-Logs.

Viertens Berufsgeheimnis: Der API-Key für das LLM, das Mandanten-Daten verarbeitet, ist selbst ein Berufsgeheimnis-relevanter Wert. Wer den Schlüssel verliert, gibt einem Unbekannten Zugang zu allen Mandanten-Anfragen der letzten Monate. Cross-Link: ndsg-revfadp-ki, schatten-ki-im-unternehmen – die Schatten-KI-Problematik beginnt oft mit einem geleakten API-Key, den ein Praktikant für ein privates Projekt benutzt.

Wie eine Vault-Pipeline aufgebaut ist

Wir gehen eine produktionsreife Pipeline durch.

Vault-Server: Self-hosted Vault läuft auf einer eigenen, gehärteten VM (Hetzner Dedicated, Infomaniak), idealerweise mit drei Nodes im HA-Cluster und Auto-Unseal über AWS KMS oder GCP KMS. Storage ist Raft (eingebaut) oder Consul. Vault startet im sealed Zustand und braucht ein Unseal – entweder manuell mit Shamir-Secret-Sharing-Keys oder automatisch via Cloud-KMS.

Secrets-Engines: Vault organisiert Secrets in „Engines". KV v2 ist die einfachste für statische Werte (API-Keys, DB-Passwörter). PKI-Engine erzeugt kurz-lebige TLS-Zertifikate. Database-Engine erzeugt dynamische DB-Credentials, die nach 1 Stunde Gültigkeit verfallen. AWS-Engine erzeugt kurzlebige AWS-IAM-Credentials. Transit-Engine bietet Verschlüsselung-as-a-Service, ohne die Schlüssel auszugeben.

Authentisierung: Jede Anwendung authentisiert sich bei Vault mit einer von vielen Methoden. AppRole für Server-zu-Server, Kubernetes-Service-Accounts für K8s-Workloads, OIDC für menschliche Nutzer mit SSO-Integration, GitHub für Entwickler-Tooling. Das Resultat ist immer ein kurz-lebiger Token (typisch 1 Stunde TTL), mit dem die Anwendung Secrets abruft.

Rotation: Statische Secrets werden alle 90 Tage rotiert (PCI-DSS-Anlehnung). Vault kann das automatisieren – z.B. für Datenbank-Passwörter erzeugt es ein neues Passwort, schreibt es in die DB, und alte Tokens verfallen. Dynamische Secrets werden gar nicht rotiert, sondern leben nur für den Job-Lauf (Minuten bis Stunden).

Audit-Trail: Vault loggt jeden Secret-Zugriff: Wer (token-id), wann (timestamp), welcher Path (engine plus secret-pfad), Erfolg oder Fehler. Audit-Logs gehen in eine SIEM-Pipeline (Grafana Loki, Splunk, ELK) und werden 10 Jahre aufbewahrt – parallel zur Aufbewahrungs-Pflicht des Audit-Trails nach Art. 957a OR. Die Audit-Engine kann nicht abgeschaltet werden, ohne Vault selbst zu sealen.

Compromise-Antwort: 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.

Tool-Vergleich Mai 2026: HashiCorp Vault BSL 1.1 ist die volle Lösung mit allen Engines, geeignet ab ca. 20 Anwendungen. OpenBao ist der Apache-2.0-Fork und Mai 2026 funktionell gleichwertig für die meisten Use Cases. Bitwarden Secrets Manager ist die OSS-Lösung für kleine Setups, integriert mit Bitwarden-Vault. 1Password Secrets ist die SaaS-Variante für Teams, die schon 1Password für Passwörter nutzen. AWS Secrets Manager und Azure Key Vault sind die Cloud-native Optionen – wer auf AWS oder Azure hosted, nimmt das passende. Infisical ist eine entwicklerfreundliche OSS-Alternative mit guter CLI- und SDK-Unterstützung.

Secrets-Management-Einführung in 5 Schritten

1. 01Inventar: Welche Secrets existieren wo? Listen Sie alle .env-Files, Konfigurations-Dateien, Konstanten im Code, geteilten Passwörter in Slack oder Notion.
2. 02Tool wählen: OpenBao oder HashiCorp Vault für mittelgrosse Setups, Bitwarden Secrets oder 1Password Secrets für kleine Teams, AWS oder Azure native bei Cloud-Hosting.
3. 03Vault aufsetzen: HA-Cluster mit 3 Nodes, Auto-Unseal via Cloud-KMS oder Shamir-Keys, Audit-Engine zu Loki oder Splunk, AppRole für Server-Auth.
4. 04Anwendungen migrieren: Jede Anwendung holt Secrets beim Start aus Vault statt aus .env. Library-Support: vault-agent für File-basierte Apps, Vault-SDK für Code-Integration.
5. 05Rotation und Compromise-Prozess: Alle 90 Tage statische Schlüssel rotieren, dynamische Secrets für DBs und Cloud-APIs einrichten, Compromise-Runbook schreiben (innert 72h melden).

Wann Secrets-Management Pflicht ist

Sobald mehr als ein Mitarbeitender Zugriff auf produktive Systeme hat, ist zentrales Secrets-Management Pflicht – nicht Empfehlung. Die Grenze ist nicht „grosse Firma vs. kleine", sondern „Mehr-Personen vs. Solo-Entwickler".

Konkrete Trigger: (a) Sie nutzen kostenpflichtige APIs (Stripe, OpenAI, Anthropic, Brevo) mit monatlichen Kosten über CHF 200 – ein geleakter Key kann Schaden in Mehrhundert-Franken-Bereich anrichten. (b) Sie haben Mitarbeitende, die wechseln – jeder Wechsel braucht eine Schlüssel-Rotation. (c) Sie sind nach PCI-DSS, ISO 27001 oder SOC 2 zertifizierungs-pflichtig. (d) Sie verarbeiten Personendaten unter revDSG mit Meldepflicht bei Pannen. (e) Sie unterliegen dem Berufsgeheimnis nach Art. 321 StGB. (f) Sie nutzen mehrere Server, auf denen die gleichen Secrets liegen müssten – Single-Source-of-Truth ist effizienter als manuelle Sync.

Für Mai-2026-KMU-Setups: Eine 5-Personen-Treuhand mit 10 APIs und 3 Servern ist klar in der Pflicht. Eine Solo-Entwicklerin mit zwei Hobby-Projekten kann mit einer verschlüsselten .env-Datei plus separater Schlüssel-Datei leben – aber sobald die Hobby-Projekte Kunden-Daten berühren, gilt das Treuhand-Niveau.

Wann ein leichteres Setup reicht

Solo-Entwicklung ohne Mandanten-Daten, reine Demo-Setups, lokale Lern-Projekte – hier ist ein voller Vault-Cluster überproportional. Ein verschlüsseltes Passwort-Manager-Eintrag (Bitwarden, 1Password) plus eine .env.encrypted-Datei mit GPG reicht. Die Trennung von Schlüssel und Daten ist das Kern-Prinzip – der voll-installierte Vault wird damit zur Pflicht erst ab Multi-Personen-Setup.

Problematisch ist der gegenteilige Fehler: Vault für ein 2-Personen-Hobby-Projekt einsetzen. Der laufende Betrieb (3 HA-Nodes, Auto-Unseal-Konfiguration, Audit-SIEM, Rotation) kostet 1 bis 2 Tage Wartung pro Quartal. Wer das ohne Notwendigkeit aufsetzt, bezahlt die Komplexität, ohne den Wert zu nutzen.

Zweite Falle: Vault aufsetzen, aber Anwendungen weiterhin mit .env-Files versorgen. Dann ist Vault nur Theater – die Secrets liegen weiterhin in Klartext auf den Servern. Die Migration der Anwendungen auf direkte Vault-API-Abrufe ist der kritische Schritt, ohne den das ganze Setup wertlos ist.

Dritte Falle: Auto-Unseal mit AWS KMS, ohne dass Sie AWS sonst nutzen. Das macht Sie von einem zusätzlichen Cloud-Provider abhängig, nur um Vault zu starten. Wer nicht ohnehin auf AWS oder GCP ist, sollte manuelles Unseal mit Shamir-Keys einrichten – 5 Schlüssel an 5 verschiedene Personen, 3 davon nötig zum Unsealen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. HashiCorp Vault – official documentation · 2026-05
2. OpenBao – Apache-2.0 fork of Vault, project documentation · 2026-04
3. NIST SP 800-57 – Recommendation for Key Management Part 1 · 2026-02
4. OWASP Secrets Management Cheat Sheet · 2026-03
5. EDÖB – Meldung von Verletzungen der Datensicherheit · 2026-04
6. Gartner Magic Quadrant for Privileged Access Management 2026 · 2026-03