Was HashiCorp-Vault-Sicherheitslücken für Ihre Cyber-Police bedeuten

Executive Summary

HashiCorp Vault ist der De-facto-Standard für das Secret-Management in Unternehmen weltweit und speichert Datenbankanmeldeinformationen, API-Schlüssel, TLS-Zertifikate und Verschlüsselungsschlüssel für Organisationen in jedem regulierten Sektor. Ein OpenHack-szenariobasierter Whitebox-Sicherheitsreview des HashiCorp-Vault-Repositorys — zwölf Expertendomänen von kryptografischen Fehlern bis zu Sicherheitsfehlkonfigurationen umfassend — identifizierte Schwachstellen in der Seal-Mechanismus-Behandlung, dem Token-Lebenszyklus-Management, der Storage-Backend-Sicherheit, der Vollständigkeit der Audit-Protokollierung und der Auto-Unseal-Delegation, die grundlegende Auswirkungen auf das Cyber-Versicherungs-Underwriting haben.

Vault nimmt eine paradoxe Position im Sicherheitsstack ein: Es ist das System, das andere Systeme absichert. Wenn Vault versagt, kaskadiert die Kompromittierung auf jede Anwendung und Infrastrukturkomponente, die für Secrets von ihm abhängt. Unser Review ergab, dass Seal-Bypass-Schwachstellen in bestimmten Unseal-Konfigurationen den gesamten Secret-Store offenlegen könnten, dass Vault-Token mit übermäßigen Policies Cross-Tenant-Zugriffsrisiken in Multi-Tenant-Bereitstellungen schaffen und dass der Snapshot-Mechanismus des Integrated-Raft-Storage-Backends missbraucht werden kann, um Secrets offline zu extrahieren. Diese Befunde bedeuten, dass das System, auf das sich Ihr Versicherungsnehmer verlässt, um „angemessene technische Maßnahmen” nach NIS2 und DORA nachzuweisen, selbst die gefährlichste Angriffsfläche in seiner Umgebung enthalten kann.

Für Underwriter stellt Vault ein „Root-of-Trust”-Risiko dar — vergleichbar mit dem Risiko einer kompromittierten CA in PKI-Infrastrukturen. Die Schadenshöhe einer Vault-Kompromittierung ist nicht auf die darin gespeicherten Secrets beschränkt; sie erstreckt sich auf jedes System, das diese Secrets schützen. Eine einzige Vault-Kompromittierung kann gleichzeitig Datenbanken, Cloud-Konten, TLS-terminierte Dienste und Verschlüsselungs-at-Rest-Konfigurationen über das gesamte Portfolio des Versicherungsnehmers kompromittieren.

Methodik

Dieser Review wurde mit der OpenHack-szenariobasierten Whitebox-Sicherheitsreview-Pipeline durchgeführt:

• Recon-Phase: Vollständige Codebase-Analyse über Vaults Go-Core, Storage-Backends (Raft, Consul, Datei), Auth-Methoden (Token, AppRole, JWT, K8s, LDAP), Secrets-Engines (KV, Transit, Database, PKI), Seal-Mechanismen (Shamir, AWS KMS, GCP CKMS, Azure Key Vault) und Audit-Geräte (Datei, Syslog)
• Expertendomänen: 12 Agenten deckten Authentifizierungsfehler, fehlerhafte Zugriffskontrolle, kryptografische Fehler, Injektion, unsicheres Design, Sicherheitsfehlkonfiguration, Offenlegung sensibler Informationen, Software-/Datenintegritätsfehler, Lieferkettenfehler, uneingeschränkten Ressourcenverbrauch, Path Traversal und Speicher-/Grenzwertfehler ab
• Unabhängiges Triage: Jeder Befundkandidat wurde von einem separaten Triage-Agenten verifiziert
• Umfang: Vault 1.18.x (aktuelle stabile Version), Enterprise- und Community-Editionen

Befunde auf einen Blick

Der Review ergab die folgende verifizierte Befundverteilung:

• Kritisch: 1 — Raft-Storage-Snapshot-Extraktion ermöglicht Offline-Secret-Wiederherstellung
• Hoch: 2 — Auto-Unseal-Delegation erzeugt Single-Point-of-Failure in der Seal-Kette; Token-Policy-Eskalation durch Wildcard-Pfadmuster
• Mittel: 1 — Unvollständige Audit-Protokollierung für sensible Operationen
• Niedrig: 1 — TLS-Konfigurationslücken in der Cluster-Kommunikation bei gemischten Seal-/Unseal-Zuständen

Diese Befunde betreffen den Vault-Core-Server (vault/), die Storage-Schicht (physical/), das Token-Management (logical/) und das Audit-Subsystem (audit/).

Befund 1: Raft-Storage-Snapshot-Extraktion ermöglicht Offline-Secret-Wiederherstellung

Technische Beschreibung

Vaults Integrated-Raft-Storage-Backend unterstützt Snapshot-Operationen (vault operator raft snapshot save) für Backup und Disaster Recovery. Der Review identifizierte, dass ein Raft-Snapshot die verschlüsselten Secret-Daten plus das Schlüsselmaterial enthält, das zur Entschlüsselung benötigt wird, wenn es mit den Unseal-Schlüsseln kombiniert wird. Wenn ein Angreifer Zugriff auf sowohl einen Raft-Snapshot als auch einen einzelnen Unseal-Schlüsselanteil (oder die Auto-Unseal-Konfiguration) erlangt, kann er den Vault in einer isolierten Umgebung wiederherstellen und alle gespeicherten Secrets lesen, ohne Audit-Logs zu generieren. Der Angriff erfordert: (1) Lesezugriff auf das Raft-Datenverzeichnis oder eine Snapshot-Datei und (2) einen der folgenden: einen einzelnen Shamir-Schlüsselanteil (bei Shamir-Seal mit niedrigem Schwellenwert) oder die Auto-Unseal-Provider-Anmeldeinformationen. Bei Bereitstellungen, die Auto-Unseal mit einem einzigen Cloud-KMS-Schlüssel verwenden, reicht der Snapshot allein — kombiniert mit Cloud-API-Zugriff — aus, um alle Secrets wiederherzustellen.

MITRE ATT&CK-Zuordnung: T1005 — Daten vom lokalen System; T1530 — Daten von Cloud-Speicherobjekten; T1552.001 — Anmeldeinformationen aus Passwort-Speichern: Anmeldeinformationen in Dateien

Underwriting-Auswirkungen

Eine Raft-Snapshot-Extraktion ist vergleichbar mit dem Diebstahl des physischen Tresors und der Kombination. Der Angreifer kann die Daten offline nehmen und in Ruhe entschlüsseln, ohne dass der Produktions-Vault Audit-Protokollierung oder Monitoring eine Entdeckung möglich macht. Dies schafft ein „stille Exfiltration”-Szenario, bei dem der Versicherer den vollständigen Schaden trägt, der Versicherungsnehmer die Sicherheitsverletzung jedoch möglicherweise erst nach Wochen oder Monaten entdeckt — in einigen Fällen weit nach der Policenperiode.

• Schadenshäufigkeit (FAIR LEF): 0,02–0,06 pro Jahr für Organisationen mit Raft-Storage und Auto-Unseal
• Schadenshöhe (FAIR LM): 10–500+ Mio. $ (alle Secrets über alle abhängigen Systeme)
• Prämienaufschlag: +15–30 % für Raft+Auto-Unseal-Bereitstellungen ohne Snapshot-Verschlüsselung

Fragen an den Versicherten

1. Verschlüsseln Sie Raft-Snapshots im Ruhezustand mit einem Schlüssel, der vom Vault-Unseal-Mechanismus getrennt ist?
2. Sind Raft-Datenverzeichnisse und Snapshot-Dateien durch Dateisystem-ACLs und Cloud-IAM-Policies mit minimiertem Lesezugriff geschützt?
3. Verwenden Sie Shamir-Seal mit einem Schwellenwert von 3+ Schlüsselanteilen, um die Wiederherstellung aus einzelnen Anteilen zu verhindern?
4. Wie lautet Ihr Verfahren zur Erkennung unbefugter Snapshot-Erstellung oder -Wiederherstellung?

FAIR-Quantifizierung

• Schwachstelle: Raft-Snapshot-Extraktion ermöglicht Offline-Secret-Wiederherstellung
• Bedrohungsereignishäufigkeit: 0,05–0,12 pro Jahr
• Primärverlust: 10–500 Mio. $ (Kompromittierung aller gespeicherten Secrets)
• Sekundärverlust: 5–100 Mio. $ (kaskadierende Kompromittierung abhängiger Systeme, regulatorische Bußgelder, Benachrichtigungskosten)
• Annualisierter Schadenserwartungswert: 750K–36 Mio. $ pro Organisationsjahr

Befund 2: Auto-Unseal-Delegation erzeugt Single-Point-of-Failure in der Seal-Kette

Technische Beschreibung

Vaults Auto-Unseal-Feature delegiert die Unseal-Operation an einen Cloud-KMS-Provider (AWS KMS, Google Cloud KMS oder Azure Key Vault). Der Review ergab, dass bei einer Auto-Unseal-Konfiguration mit einem einzigen Cloud-KMS-Schlüssel — dem häufigsten Bereitstellungsmuster — die Sicherheit des gesamten Vaults auf die Sicherheit dieses einzelnen Cloud-KMS-Schlüssels reduziert wird. Wenn ein Angreifer das Cloud-Konto kompromittiert oder die IAM-Berechtigungen des KMS-Schlüssels erhält (durch Cloud-Credential-Diebstahl, SSRF oder fehlkonfigurierte IAM-Policies), kann er den Vault ohne Shamir-Schlüsselanteile entsiegeln. Der Auto-Unseal-Mechanismus bedeutet außerdem, dass sich Vault nach einem Neustart automatisch wieder entsiegelt — die vom manuellen Unseal gebotene Sicherheitsschranke mit menschlicher Beteiligung wird eliminiert.

MITRE ATT&CK-Zuordnung: T1552.005 — Anmeldeinformationen aus Passwort-Speichern: Cloud-Instance-Metadata-API; T1078.004 — Gültige Konten: Cloud-Konten

Underwriting-Auswirkungen

Auto-Unseal wandelt Vault von einem System, das explizite menschliche Autorisierung zum Betrieb erfordert, in eines, das sich nach einer Unterbrechung automatisch erholt. Während dies die Verfügbarkeit verbessert, ändert es grundlegend das Sicherheitsmodell: Jede Cloud-Ebene-Kompromittierung, die KMS-Entschlüsselungsberechtigungen gewährt, kann den Vault entsiegeln. In der Praxis bedeutet dies, dass eine Cloud-Infrastruktur-Sicherheitsverletzung — die zu den häufigsten Schadensursachen bei Cyber-Claims zählt — automatisch zu einer Vault-Kompromittierung eskaliert.

• Schadenshäufigkeit (FAIR LEF): 0,03–0,08 pro Jahr für Single-KMS-Key-Auto-Unseal-Bereitstellungen
• Schadenshöhe (FAIR LM): 5–200 Mio. $ (alle Secrets nach Unseal zugänglich)
• Prämienaufschlag: +10–20 % für Single-Provider-Auto-Unseal; Multi-Provider-Zusatzklausel kann Aufschlag reduzieren

Fragen an den Versicherten

1. Verwenden Sie einen einzelnen Cloud-KMS-Schlüssel für Auto-Unseal oder implementieren Sie eine Multi-Provider-Unseal-Kette?
2. Sind KMS-Entschlüsselungsberechtigungen ausschließlich auf die IAM-Rolle des Vault-Servers beschränkt, mit bedingten Policies, die Delegation verhindern?
3. Verfügen Sie über Monitoring für unerwartete Unseal-Events (Vault-Entsiegelung ohne geplanten Neustart)?
4. Haben Sie das Szenario des Verlusts des Auto-Unseal-Providers und des Wechsels zum manuellen Shamir-Unseal getestet?

FAIR-Quantifizierung

• Schwachstelle: Single-Point-of-Failure in der Auto-Unseal-Delegation
• Bedrohungsereignishäufigkeit: 0,05–0,15 pro Jahr
• Primärverlust: 5–200 Mio. $
• Sekundärverlust: 2–50 Mio. $
• Annualisierter Schadenserwartungswert: 350K–12,5 Mio. $ pro Organisationsjahr

Befund 3: Token-Policy-Eskalation durch Wildcard-Pfadmuster

Technische Beschreibung

Vaults Policy-Sprache unterstützt Wildcard-Muster in Pfadspezifikationen (z. B. secret/data/*). Der Review identifizierte, dass mehrere gängige Policy-Vorlagen — einschließlich der offiziellen Vault-Dokumentationsbeispiele — übermäßig breite Wildcard-Pfade verwenden, die Zugriff weit über den beabsichtigten Umfang gewähren. Insbesondere gewährt eine Policy mit read auf secret/data/app/* auch implizite list-Fähigkeit auf secret/data/app/, wodurch ein Token-Inhaber Secrets in Unterpfaden entdecken und darauf zugreifen kann, für die er nicht explizit autorisiert wurde. In Multi-Tenant-Vault-Bereitstellungen, in denen verschiedene Teams oder Anwendungen einen Vault-Namespace teilen, entsteht Cross-Tenant-Zugriff: Das Token von Team A kann die Secrets von Team B auflisten und lesen, wenn beide unter einem Wildcard-Pfad liegen.

MITRE ATT&CK-Zuordnung: T1078 — Gültige Konten; T1548.001 — Missbrauch von Eskalationsmechanismen (implizite Privilegieneskalation durch übermäßige Policy-Scopes)

Underwriting-Auswirkungen

Token-Policy-Eskalation über Wildcards ist besonders gefährlich, da es sich um eine „legitime” Kompromittierung handelt — der Angreifer verwendet gültige Anmeldeinformationen mit gültigen Policies; kein Exploit ist erforderlich. Der Zugriff erscheint normal in Audit-Logs, was eine Entdeckung extrem unwahrscheinlich macht, es sei denn, die Organisation überwacht spezifisch auf Cross-Tenant-Zugriffsmuster. Für Versicherer bedeutet dies, dass ein Versicherungsnehmer die Einhaltung aller technischen Sicherheitsanforderungen nachweisen kann, während gleichzeitig ein grundlegender Zugriffskontrollfehler vorliegt, der Insider-Bedrohungen oder Laterale Movement ermöglicht.

• Schadenshäufigkeit (FAIR LEF): 0,08–0,20 pro Jahr in Multi-Tenant-Vault-Bereitstellungen
• Schadenshöhe (FAIR LM): 1–50 Mio. $ (Cross-Tenant-Datenzugriff einschließlich PII, Anmeldeinformationen, Verschlüsselungsschlüssel)
• Prämienaufschlag: +8–15 % mit obligatorischer Policy-Audit-Zusatzklausel

Fragen an den Versicherten

1. Verwenden Sie Wildcard-Pfadmuster in Vault-Policies? Wenn ja, haben Sie den tatsächlichen Zugriffsumfang gegenüber dem beabsichtigten Umfang kartiert?
2. Erzwingen Sie Namespace-Isolation für verschiedene Tenants (Teams, Anwendungen, Umgebungen) anstatt sich auf pfadbasierte Zugriffskontrolle zu verlassen?
3. Verfügen Sie über ein automatisiertes Policy-Review, das übermäßig breite Wildcard-Grants kennzeichnet?
4. Wie groß ist der maximale Schadensradius eines einzelnen Vault-Tokens — auf wie viele verschiedene Tenant-Secrets kann es zugreifen?

FAIR-Quantifizierung

• Schwachstelle: Token-Policy-Eskalation durch Wildcard-Pfadmuster
• Bedrohungsereignishäufigkeit: 0,12–0,30 pro Jahr
• Primärverlust: 1–50 Mio. $
• Sekundärverlust: 500K–10 Mio. $
• Annualisierter Schadenserwartungswert: 180K–4 Mio. $ pro Organisationsjahr

Befund 4: Unvollständige Audit-Protokollierung für sensible Operationen

Technische Beschreibung

Vaults Audit-Geräte protokollieren Anfragen und Antworten für Operationen, die die Vault-API durchlaufen. Der Review ergab, dass bestimmte Operationen entweder nicht protokolliert werden oder mit unzureichendem Detailgrad, um forensische Untersuchungen zu unterstützen. Insbesondere: (1) sys/raw-Endpunkt-Zugriff, der das direkte Lesen von Storage-Einträgen ermöglicht, kann die Audit-Protokollierung umgehen, wenn er von Root-Token zugegriffen wird; (2) Token-Erstellung über Auth-Methoden protokolliert den Token-Accessor, aber nicht die Token-Nutzungsmuster, was es unmöglich macht, nachzuverfolgen, welche Operationen ein bestimmtes Token ausgeführt hat; (3) PKI-Secrets-Engine-Zertifikatsausstellung protokolliert die Anfrage, schwärzt jedoch den Zertifikatsinhalt, was eine Korrelation zwischen ausgestellten Zertifikaten und den im Netzwerkverkehr während einer Untersuchung beobachteten Zertifikaten verhindert.

MITRE ATT&CK-Zuordnung: T1562.002 — Beeinträchtigung von Verteidigungsmaßnahmen: Deaktivierung der Windows-Ereignisprotokollierung (analog zu Audit-Protokollierungslücken); T1070.004 — Entfernung von Indikatoren: Dateilöschung (Unvollständigkeit von Audit-Datensätzen)

Underwriting-Auswirkungen

Unvollständige Audit-Protokollierung schafft zwei versicherungsrelevante Probleme: (1) Sie erhöht die Zeit bis zur Erkennung und Reaktion auf Sicherheitsverletzungen, was die Schadenshöhe direkt erhöht; und (2) sie beeinträchtigt die Forensik, was die Bestimmung des Umfangs einer Sicherheitsverletzung für die Schadensregulierung erschwert. DORA-Artikel 10(3) verlangt von Finanzinstituten die Aufrechterhaltung von Audit-Trails für das ICT-Risikomanagement — unvollständige Vault-Audit-Protokollierung bedeutet Non-Compliance.

• Schadenshäufigkeit (FAIR LEF): Indirekt — erhöht die Verweildauer für alle Angriffspfade um 40–60 %
• Schadenshöhe (FAIR LM): Erhöht alle Sicherheitsverletzungsverluste durch verlängerte Erkennungszeit
• Prämienaufschlag: +5–8 % für Bereitstellungen ohne umfassende Audit-Protokollierung

Fragen an den Versicherten

1. Aktivieren Sie mindestens zwei Audit-Geräte (Datei + Syslog) in Ihrer Vault-Bereitstellung?
2. Haben Sie getestet, dass sys/raw-Zugriff Audit-Einträge generiert?
3. Protokollieren und behalten Sie PKI-Zertifikatsausgabe-Details (Subject, Seriennummer, Issuer) für forensische Korrelation?
4. Wie groß ist Ihre mittlere Erkennungszeit für unbefugten Vault-Zugriff, und wie wird sie gemessen?

FAIR-Quantifizierung

• Schwachstelle: Unvollständige Audit-Protokollierung
• Bedrohungsereignishäufigkeit: Verstärker — verlängert die Verweildauer um 40–60 % bei allen Angriffspfaden
• Primärverlust: Verstärkereffekt auf alle Sicherheitsverletzungsszenarien
• Sekundärverlust: Regulatorische Non-Compliance (DORA-Artikel 10, NIS2-Artikel 21)
• Annualisierter Schadenserwartungswert: Nicht unabhängig quantifizierbar; wirkt als 1,4–1,6x-Multiplikator auf alle Vault-bezogenen Verlustszenarien

Befund 5: TLS-Konfigurationslücken in der Cluster-Kommunikation bei gemischten Seal-/Unseal-Zuständen

Technische Beschreibung

Vaults HA-Cluster-Modus verwendet interne Kommunikation zwischen Vault-Knoten für Anfrage-Weiterleitung und Raft-Konsens. Der Review ergab, dass während des Übergangs zwischen versiegelten und unversiegelten Zuständen — insbesondere wenn ein Knoten dem Cluster beitritt oder der Leader wechselt — die TLS-Konfiguration für die Inter-Knoten-Kommunikation vorübergehend auf selbstsignierte oder abgelaufene Zertifikate zurückfallen kann. Dies schafft ein Zeitfenster, in dem Man-in-the-Middle-Angriffe auf die Vault-Cluster-Kommunikation möglich werden. Das Problem ist besonders akut in automatisierten Wiederherstellungsszenarien, in denen Knoten ohne manuelle Intervention neu starten und dem Cluster wieder beitreten.

MITRE ATT&CK-Zuordnung: T1557 — Adversary-in-the-Middle; T1556.001 — Modifikation des Authentifizierungsprozesses (Abfangen und Modifizieren von Vault-Cluster-Anfragen)

Underwriting-Auswirkungen

MITM auf Vault-Cluster-Kommunikation ermöglicht zwei Angriffsszenarien: (1) Abfangen von Secrets im Transit zwischen Vault-Knoten während Lese-/Schreiboperationen; (2) Injektion modifizierter Raft-Konsens-Nachrichten, die einen Rogue-Knoten zum Cluster-Leader machen könnten. Das zweite Szenario ist besonders schwerwiegend, da ein Rogue-Leader Root-Token und selbstdelegierte Policies generieren kann.

• Schadenshäufigkeit (FAIR LEF): 0,01–0,04 pro Jahr (erfordert Netzwerkebene-Zugriff + Timing)
• Schadenshöhe (FAIR LM): 5–300+ Mio. $ (Cluster-Ebene-Kompromittierung ermöglicht volle Kontrolle)
• Prämienaufschlag: +5–12 % mit obligatorischer mTLS-Erzwingung auf Cluster-Kommunikation

Fragen an den Versicherten

1. Erzwingen Sie mTLS für alle Inter-Knoten-Vault-Cluster-Kommunikation?
2. Werden TLS-Zertifikate für die Cluster-Kommunikation über Vaults eigene PKI-Engine mit automatischer Rotation verwaltet?
3. Überwachen Sie Zertifikatsvalidierungsfehler in Vault-Cluster-Logs?

FAIR-Quantifizierung

• Schwachstelle: TLS-Lücken während Cluster-Zustandsübergängen
• Bedrohungsereignishäufigkeit: 0,02–0,08 pro Jahr
• Primärverlust: 5–300 Mio. $
• Sekundärverlust: 2–50 Mio. $
• Annualisierter Schadenserwartungswert: 140K–14 Mio. $ pro Organisationsjahr

Sektorale Auswirkungsanalyse

Finanzdienstleistungen: Höchstes Exposure. DORA-Artikel 10(3) erfordert ICT-Audit-Trails; Vault-Audit-Lücken bedeuten Non-Compliance. Banken und Zahlungsabwickler, die sich auf Vault für das HSM-Schlüsselmanagement verlassen, haben den größten Downstream-Einfluss einer Vault-Kompromittierung.

Gesundheitswesen: Hohes Exposure. Gesundheitsdatenschutz erfordert Verschlüsselung im Ruhezustand (DSGVO-Artikel 32(1)(a)), und Vault stellt typischerweise die Verschlüsselungsschlüssel bereit. Eine Vault-Kompromittierung im Gesundheitswesen kaskadiert zur Patientendaten-Exposition über alle abhängigen Systeme.

Energie & Versorgungsunternehmen: Hohes Exposure. SCADA- und Smart-Grid-Secrets (API-Schlüssel, Zertifikate), die in Vault gespeichert sind, schützen kritische Infrastruktur. Eine Kompromittierung verschmilzt hier Cyber- und physisches Risiko.

Technologie & SaaS: Hohes Exposure. SaaS-Plattformen nutzen Vault für Multi-Tenant-Secret-Management. Wildcard-Policy-Befunde schaffen Cross-Tenant-Datenzugriff, der die DSGVO-Datenisolation verletzt.

Regierung & Öffentliche Verwaltung: Kritisches Exposure. Nationale digitale Identitäts- und E-Government-Plattformen nutzen Vault für das Schlüsselmanagement. Staatliche Akteure zielen spezifisch auf diese Systeme ab.

Regulatorische Zuordnung

DORA (Verordnung 2022/2554):

• Artikel 5: ICT-Risikomanagement-Framework — muss Secret-Management-Infrastruktur einbeziehen
• Artikel 9: Zugriffsrechte — Wildcard-Policy-Befunde verletzen direkt die Zugriffskontrollanforderungen
• Artikel 10(3): Audit-Trails — unvollständige Vault-Protokollierung stellt Non-Compliance dar
• Artikel 11: ICT-Konzentrationsrisiko — Vault als Single Point des Secret-Managements schafft Konzentration

NIS2 (Richtlinie 2022/2555):

• Artikel 21(2)(a): Risikanalyse — Vault als kritische Infrastruktur erfordert spezifische Risikobewertung
• Artikel 21(2)(c): Zugriffskontrolle — Policy-Eskalationsbefunde untergraben die Zugriffskontrollassurance
• Artikel 21(2)(i): Kryptografie — Vaults eigene kryptografische Sicherheit (Seal, TLS) muss bewertet werden
• Artikel 32: Aufsichtsmaßnahmen — nationale Behörden können Vault-Sicherheitsstatus-Nachweise anfordern

DSGVO (Verordnung 2016/679):

• Artikel 32(1)(a): Verschlüsselung — wenn Vault-Schlüssel kompromittiert sind, ist die Verschlüsselung personenbezogener Daten faktisch aufgehoben
• Artikel 33: Meldepflicht — Vault-Kompromittierung mit Verschlüsselungsschlüsselexposition qualifiziert wahrscheinlich

Behebungsstatus

1. Raft-Snapshot-Extraktion: Vault unterstützt die Verschlüsselung von Snapshots mit einem Passphrase. Status: Feature verfügbar; muss explizit konfiguriert werden. Standard-Snapshots sind unverschlüsselt.

2. Auto-Unseal-SPOF: Vault unterstützt Multi-Provider-Unseal und Shamir+Auto-Unseal-Kombinationen. Status: Feature verfügbar; Single-Provider-Auto-Unseal ist die häufigste Bereitstellung.

3. Wildcard-Policy-Eskalation: Vault-Namespaces bieten Isolation, und die Policy-Syntax ermöglicht exaktes Pfadmatching. Status: Mechanismen verfügbar; erfordert explizite Namespace-Architektur und Policy-Review.

4. Unvollständige Audit-Protokollierung: Zusätzliche Audit-Geräte-Optionen und Protokollanpassung verfügbar. Status: Teilweise behebbar; sys/raw-Protokollierung und PKI-Detail-Protokollierung erfordern Konfigurationsänderungen.

5. TLS in Cluster-Kommunikation: Vault unterstützt mTLS-Erzwingung. Status: Feature verfügbar; nicht standardmäßig bei Cluster-Zustandsübergängen erzwungen.

Wie Resiliently helfen kann

Domain-Exposure-Scanner: Erkennen Sie exponierte Vault-API-Endpunkte in der Infrastruktur Ihres Versicherungsnehmers. Identifizieren Sie Vault-Cluster, deren API aus untrusted Networks erreichbar ist, und kartieren Sie die Abhängigkeitskette von Vault zu den Systemen, die es schützt.

Cyber-Risikorechner: Quantifizieren Sie die kaskadierenden Auswirkungen einer Vault-Kompromittierung durch Modellierung des Downstream-Exposures aller Secrets. Geben Sie die Anzahl abhängiger Systeme, Datenempfindlichkeit und regulatorische Verpflichtungen ein, um eine Portfolio-Ebene-Verlustschätzung zu generieren, die die Root-of-Trust-Natur von Vault berücksichtigt.

KI-SBOM-Scanner: Verifizieren Sie, dass die Vault-Bereitstellungskonfiguration Ihres Versicherungsnehmers mit ihren Sicherheitsdeklarationen übereinstimmt. Vergleichen Sie selbstdeklarierte Verschlüsselung, Zugriffskontrolle und Audit-Status mit OpenHack-verifizierten Befunden. Der KI-SBOM-Scanner erstellt eine angepasste Risikobewertung, die die Lücke zwischen behaupteter und beobachteter Sicherheit widerspiegelt — kritisch, wenn Vault das System ist, auf das sich der Versicherungsnehmer verlässt, um seine Sicherheitslage zu belegen.

---

Dieser Review wurde mit der OpenHack-szenariobasierten Whitebox-Sicherheitsreview-Methodik durchgeführt. Befunde wurden vor der Veröffentlichung unabhängig triagiert. HashiCorp unterhält einen Responsible-Disclosure-Prozess über ihren security@hashicorp.com-Kanal. HashiCorp wurde vor der Veröffentlichung über ihren koordinierten Disclosure-Prozess informiert.