Plattformen für Secrets Management im Vergleich
Die Wahl einer Plattform für Secrets Management bestimmt für Jahre die Lizenzkosten, das Betriebsmodell, die API-Kompatibilität und die Datenhoheit. Diese Seite stellt OpenBao neben HashiCorp Vault Enterprise, Vault Community (BSL), Infisical, AWS Secrets Manager und Azure Key Vault.
Der Vergleich auf einen Blick
| OpenBao | Vault Enterprise | Vault Community (BSL) | Infisical | AWS Secrets Manager | Azure Key Vault | |
|---|---|---|---|---|---|---|
| Lizenz | MPL 2.0 | Kommerziell | BSL 1.1 | MIT | Proprietär | Proprietär |
| Kostenmodell | Kostenlos plus Betrieb | Preis pro Client | Kostenlos (BSL-beschränkt) | Gratis-Stufe plus kostenpflichtig | Pro Secret und Monat | Pro Operation |
| API-Kompatibilität | Vault-API | Vault-API | Vault-API | Eigene API | Eigene API | Eigene API |
| Dynamische Secrets | Ja | Ja | Ja | Eingeschränkt | Nein | Nein |
| PKI und Zertifikate | Ja | Ja | Ja | Nein | Nein | Ja |
| Transit-Verschlüsselung | Ja | Ja | Ja | Nein | Nein | Ja |
| HSM-Unterstützung | Ja | Ja | Nein | Nein | CloudHSM | Azure HSM |
| Datenhoheit | Deine Infrastruktur | Deine Infrastruktur | Deine Infrastruktur | SaaS oder selbst betrieben | AWS-Regionen | Azure-Regionen |
| Von VSHN betrieben | Ja | Nein | Nein | Nein | Nein | Nein |
Was Vault Enterprise kostet
HashiCorp rechnet Vault Enterprise pro Client ab: jede Anwendung, jeder Dienst und jede Person, die sich authentifiziert, zählt als Client. Die Preise sind nicht öffentlich. Nach verfügbaren Marktdaten und Kundenberichten liegen die Schätzungen bei einem bis drei US-Dollar pro Client und Monat, wobei Enterprise-Verträge üblicherweise bei 50'000 US-Dollar pro Jahr beginnen.
IBM hat die Übernahme von HashiCorp im Februar 2025 abgeschlossen. Zur Einordnung: seit IBM 2019 Red Hat übernommen hat, sind die Red-Hat-Abopreise durchgehend um rund 10 Prozent pro Jahr gestiegen. Für Vault Enterprise ist dasselbe Muster zu erwarten.
OpenBao verursacht keine Lizenzkosten für die Software. Managed Operations von VSHN kosten einen festen Monatsbetrag, unabhängig von der Client-Zahl.
Geschätzte Jahreskosten nach Client-Zahl
| Clients | Vault Enterprise (geschätzt) | OpenBao plus Betrieb durch VSHN |
|---|---|---|
| 100 | 1'200 bis 3'600 USD pro Jahr | Fester Monatsbetrag, auf Anfrage |
| 500 | 6'000 bis 18'000 USD pro Jahr | Fester Monatsbetrag, auf Anfrage |
| 2'000 | 24'000 bis 72'000 USD pro Jahr | Fester Monatsbetrag, auf Anfrage |
Vorbehalt: die Preise für Vault Enterprise sind nicht öffentlich. Die Schätzungen oben stützen sich auf verfügbare Marktdaten und Kundenberichte. Für eine aktuelle Offerte wende dich an HashiCorp.
Enterprise-Funktionen von Vault in OpenBao
Stand: OpenBao 2.6.2 und die Vault-Dokumentation von HashiCorp vom 13. September 2026. Jeder Eintrag bei Vault verlinkt die Seite, auf der HashiCorp festhält, dass die Funktion eine Enterprise-Lizenz verlangt. Bei OpenBao führt der Link zur Dokumentation dieses Release, sofern es dort etwas zu zeigen gibt.
25 Funktionen führt HashiCorp als reine Enterprise-Funktionen. Drei davon deckt OpenBao 2.6.2 gleichwertig ab, eine vierte auf Kubernetes, eine weitere teilweise. Drei weitere bringt 2.7.0, seit dem 9. September 2026 in der Beta: Control Groups, External Keys (das Gegenstück von OpenBao zu Managed Keys) und Konsistenz-Header. Die übrigen 17 kommen in der Dokumentation nicht vor. Zwei davon wiegen wenig, wenn Werkzeuge rund um OpenBao laufen: die Reihenfolge eines Upgrades und einen Zeitplan für die Rotation der Root-Zugangsdaten übernimmt dann eine GitOps-Pipeline oder ein geplanter Job, bei Vault Enterprise erledigt beides der Server selbst.
| Funktion | Vault Enterprise | OpenBao 2.6.2 | Einschätzung |
|---|---|---|---|
| Namespaces | Enterprise | Seit 2.3.1 enthalten | Gleichwertig |
| PKCS#11-Auto-Unseal mit HSM | Enterprise | Eingebaut. Ab 2.7.0 ein separat installiertes Plugin, weiterhin kostenlos | Gleichwertig |
| Standby-Knoten beantworten Lesezugriffe | Enterprise, als Performance-Standby | Jeder Standby-Knoten liest standardmässig mit, seit 2.5.0 | Gleichwertig |
| Seal Wrap | Enterprise Plus (HSMs) | Seal Wrapping pro Mount, aber ohne die FIPS-140-Bestätigung, die HashiCorp vorweist | Teilweise |
| Automatische Raft-Snapshots | Enterprise | Zeitgesteuerte Snapshots nach S3 mit Ablauffrist über den CronJob im Helm Chart. Ausserhalb von Kubernetes ein eigener Cron-Job | Gleichwertig auf Kubernetes |
| Control Groups | Enterprise | In der Beta von 2.7.0 | Beta 2.7.0 |
| Managed Keys | Enterprise | External Keys, in der Beta von 2.7.0 und mit anderer API | Beta 2.7.0 |
| Konsistenz-Header | Enterprise | In der Beta von 2.7.0 | Beta 2.7.0 |
| Performance-Replikation | Enterprise | Nicht dokumentiert. Das Design für Lesezugriffe auf Standby-Knoten schliesst Replikation zwischen Clustern ausdrücklich aus | Nicht in 2.6.2 |
| Disaster-Recovery-Replikation | Enterprise | Nicht dokumentiert | Nicht in 2.6.2 |
| Sentinel-Policies | Enterprise | Nur ACL-Policies. CEL prüft Rollen in PKI und JWT, ein engerer Mechanismus | Nicht in 2.6.2 |
| Step-up-MFA in Policies | Enterprise | Nur MFA beim Login, wie bei Vault Community | Nicht in 2.6.2 |
| Lease-Count-Quotas | Enterprise | Nur Rate-Limit-Quotas | Nicht in 2.6.2 |
| Redundancy Zones | Enterprise | Nicht dokumentiert. Autopilot stabilisiert neue Knoten, räumt ausgefallene weg und meldet den Zustand | Nicht in 2.6.2 |
| Automatische Upgrades | Enterprise | Nicht eingebaut. Das Helm Chart überlässt die Reihenfolge beim Upgrade dem Betrieb: zuerst die Standby-Knoten, zuletzt den aktiven Knoten | Nicht in 2.6.2 |
| Zeitgesteuerte Rotation der Root-Zugangsdaten | Enterprise | Root-Zugangsdaten rotieren per API-Aufruf, ein Zeitplan ist nicht eingebaut | Nicht in 2.6.2 |
| Filter für Audit-Logs | Enterprise | Nicht dokumentiert | Nicht in 2.6.2 |
| Entropy Augmentation | Enterprise | Nicht dokumentiert | Nicht in 2.6.2 |
| FIPS-140-3-Builds | Enterprise | Nicht dokumentiert | Nicht in 2.6.2 |
| SCIM-Provisionierung | Enterprise, als Beta | Nicht dokumentiert | Nicht in 2.6.2 |
| Secrets Sync | Enterprise | Nicht dokumentiert. Offener Feature Request, noch ohne Umsetzung | Nicht in 2.6.2 |
| KMIP-Server (KMIP Secrets Engine) | Enterprise mit ADP-Modul | Nicht dokumentiert. Das KMIP-Seal ist etwas anderes: dort entsiegelt sich OpenBao als KMIP-Client | Nicht in 2.6.2 |
| Transform (Tokenisierung, formaterhaltende Verschlüsselung) | Enterprise mit ADP-Transform-Modul | Beim Fork entfernt | Nicht in 2.6.2 |
| Key Management Secrets Engine | Enterprise mit ADP-Modul | Nicht dokumentiert | Nicht in 2.6.2 |
| Zertifikatsbezug über SCEP | Enterprise | Nicht dokumentiert | Nicht in 2.6.2 |
Wofür sich Vault Enterprise weiterhin lohnt. Die grösste Lücke ist die Replikation zwischen Clustern. OpenBao kennt weder Performance- noch Disaster-Recovery-Replikation, ein OpenBao über mehrere Standorte bleibt also ein einziger Cluster. Danach folgen Sentinel-Policies, die Module für Advanced Data Protection (ein KMIP-Server, Tokenisierung mit Transform, Schlüsselverteilung an Cloud-KMS), ein FIPS-140-3-Build, wenn ein Vertrag oder eine Vorschrift ihn verlangt, und Secrets Sync in die Secret-Speicher der Clouds.
Was als Grund weggefallen ist. Namespaces, PKCS#11-Auto-Unseal und Standby-Knoten, die Lesezugriffe beantworten, liefert OpenBao ohne Lizenzgebühr, auf Kubernetes auch zeitgesteuerte Snapshots. Control Groups und Managed Keys folgen mit 2.7.0: beide stecken bereits in der Beta und sind mit dem stabilen Release verfügbar.
Der Fork: warum es OpenBao gibt
Im August 2023 wechselte HashiCorp die Lizenz von Vault von MPL 2.0 auf BSL 1.1, die Business Source License. BSL 1.1 schränkt die Nutzung in konkurrierenden gehosteten Diensten ein. IBM kündigte die Übernahme von HashiCorp im April 2024 an und schloss sie im Februar 2025 ab.
OpenBao entstand als Antwort auf den Lizenzwechsel. Das Projekt wird unter der Linux Foundation gepflegt, nutzt MPL 2.0 und ist vollständig API-kompatibel zu Vault. Der Wechsel von Vault zu OpenBao ist eine Konfigurationsänderung und keine Neuentwicklung. Bestehende Vault-Clients, Skripte und Terraform-Ressourcen laufen unverändert.
Vault Enterprise
HashiCorp Vault Enterprise ist das ausgereifte kommerzielle Angebot mit der längsten Geschichte.
Stärken: Performance-Replikation und Disaster-Recovery-Replikation zwischen Clustern, Sentinel-Policies, die Secrets Engines für KMIP, Transform und Key Management, FIPS-140-3-Builds, ein Support-SLA und eine grosse Gemeinschaft von Betreibern. Die Tabelle oben stellt alle 25 Enterprise-Funktionen OpenBao gegenüber.
Kein Unterscheidungsmerkmal mehr: Namespaces, PKCS#11-Auto-Unseal mit HSM und Standby-Knoten, die Lesezugriffe beantworten, dazu auf Kubernetes zeitgesteuerte Snapshots. OpenBao liefert sie ohne Lizenzgebühr.
Grenzen: der Preis pro Client wächst linear mit der Verbreitung. Die BSL-1.1-Lizenz schränkt bestimmte Anwendungsfälle ein. IBMs Preisgeschichte bei Red Hat zeigt konstante jährliche Erhöhungen, was die langfristige Kostenplanung erschwert. Und du hängst für den gesamten Secrets-Stack an einem einzigen Anbieter.
Passt, wenn: deine Organisation ohnehin auf Vault Enterprise festgelegt ist, Replikation zwischen Clustern, Sentinel-Policies, Tokenisierung oder einen FIPS-140-3-Build braucht und die Lizenzkosten sowie die Abhängigkeit von IBM akzeptiert.
Vault Community (BSL)
Die Community-Edition von Vault ist kostenlos zu betreiben, aber die BSL-1.1-Lizenz schränkt den Einsatz in konkurrierenden Dienstangeboten ein.
Stärken: kostenloser Betrieb, dieselbe API wie Vault Enterprise und OpenBao, breite Dokumentation und viel Material aus der Community.
Grenzen: BSL 1.1 ist nach der Definition der OSI keine Open-Source-Lizenz. Die Einschränkungsklausel erzeugt rechtliche Unschärfe für SaaS-Anbieter und für interne Plattformteams, die Vault als geteilten Dienst anbieten. Für Fehlerbehebungen und Sicherheitspatches bleibst du auf HashiCorp, heute IBM, angewiesen. Und PKCS#11-Auto-Unseal steht nicht zur Verfügung: HashiCorps Dokumentation stellt es hinter Enterprise, eine Community-Installation kann sich also nicht aus einem HSM entsiegeln. Für eine regulierte Organisation, der vorgegeben wurde, wo ihr Schlüsselmaterial liegen muss, entscheidet diese eine Zeile über die Edition.
Passt, wenn: du Vault Community intern betreibst, die BSL-Einschränkungen deinen Fall nicht berühren und du den Betriebsaufwand selbst trägst.
Infisical
Infisical ist eine Secrets-Plattform mit Fokus auf Entwicklungsteams. Der Ansatz unterscheidet sich von Vault: ein Web-Dashboard, native Integrationen und eingebaute Rotation.
Stärken: eingängige Weboberfläche, native Integrationen mit GitHub Actions, Kubernetes, Docker und CI-Systemen, eingebaute Secret-Rotation für gängige Dienste und die MIT-Lizenz für die selbst betriebene Variante.
Grenzen: Infisical kennt keine dynamischen Secrets, jedes Secret ist ein gespeicherter Wert und keiner, der pro Anfrage erzeugt wird. Keine PKI und keine Zertifikatsverwaltung. Keine Transit-Engine. Keine HSM-Unterstützung. Infisical und Vault lösen unterschiedliche Probleme: Infisical ist ein Secrets-Speicher, Vault eine Secrets-Plattform.
Passt, wenn: dein Team einen entwicklerfreundlichen Secrets-Speicher mit Oberfläche braucht und weder dynamische Secrets noch PKI oder Transit-Verschlüsselung.
Die Hyperscaler: AWS Secrets Manager und Azure Key Vault
Beide sind eng in ihr jeweiliges Cloud-Ökosystem eingebettet.
Stärken: keine Infrastruktur zu betreiben, native IAM-Anbindung, enge Verzahnung mit cloud-nativen Diensten wie Lambda, EC2 oder App Service, eingebaute Audit-Spuren.
Grenzen: die Jurisdiktion eines US-Unternehmens gilt unabhängig von der Datenregion. Keine dynamischen Secrets. Keine Transit-Engine. Keine Portabilität, denn was im AWS Secrets Manager liegt, erreicht ein Azure-Workload nur über Aufrufe zwischen den Clouds. AWS verlangt 0,40 US-Dollar pro Secret und Monat sowie 0,05 US-Dollar je 10'000 API-Aufrufe, Azure Key Vault rechnet pro Operation ab. Die Kosten wachsen mit der Zahl der Secrets und der Zugriffshäufigkeit.
Passt, wenn: dein gesamter Workload auf einem einzigen Hyperscaler läuft, US-Jurisdiktion akzeptabel ist und du nur statische Secret-Speicherung mit IAM-Zugriffskontrolle brauchst.
Wann was passt
OpenBao mit Betrieb durch VSHN, wenn du Vault-API-Kompatibilität ohne Lizenzkosten pro Client willst, Datenhoheit auf Schweizer Infrastruktur brauchst oder von Vault Enterprise weg willst und einen direkten Ersatz unter MPL 2.0 suchst.
Vault Enterprise, wenn deine Organisation Replikation zwischen Clustern, Sentinel-Policies, die Engines für Transform oder KMIP oder einen FIPS-140-3-Build braucht, ohnehin unter Vertrag steht und den Preis pro Client sowie die Abhängigkeit von IBM akzeptiert.
Vault Community (BSL), wenn du intern betreibst, den Betrieb selbst trägst und die BSL-Einschränkungen deinen Fall nicht berühren.
Infisical, wenn du vor allem einen entwicklerfreundlichen Secrets-Speicher mit Weboberfläche und CI-Integrationen brauchst und weder dynamische Secrets noch eine PKI-Engine.
AWS Secrets Manager oder Azure Key Vault, wenn deine Workloads ausschliesslich auf einem Hyperscaler laufen, US-Jurisdiktion akzeptabel ist und einfache Secret-Speicherung mit nativer IAM-Anbindung genügt.
Nächster Schritt
Migration von Vault auf OpenBao abklären oder Lizenzkosten für deine Client-Zahl vergleichen? Buche eine Beratung. Wir schauen uns dein aktuelles Setup an und legen einen konkreten Kostenvergleich vor.