AWS Secrets Manager vs. HashiCorp Vault

Secret-Verwaltung als Cloud-Funktion oder als eigenständige Sicherheitsarchitektur

Secrets sind kein Randthema. Zugangsdaten, API-Keys, Tokens und Zertifikate definieren, wie Systeme miteinander sprechen dürfen – und wo Sicherheitsgrenzen tatsächlich verlaufen. AWS Secrets Manager und HashiCorp Vault adressieren dieses Problem aus zwei grundsätzlich unterschiedlichen Richtungen.

Der Unterschied liegt nicht in der Fähigkeit, Secrets verschlüsselt zu speichern. Er liegt in der Frage, ob Secret-Management Teil einer Cloud-Funktion ist oder eine eigenständige Sicherheitsarchitektur darstellt. Diese Entscheidung wirkt sich direkt auf Portabilität, Governance und langfristige Kontrolle aus.

AWS Secrets Manager: Secret-Handling als Cloud-Service

AWS Secrets Manager ist der verwaltete Dienst von AWS zur Speicherung und Nutzung sensibler Informationen wie Zugangsdaten, API-Keys oder Tokens. Secrets werden verschlüsselt gespeichert, versioniert und lassen sich automatisiert rotieren – insbesondere für AWS-native Dienste wie RDS.

Die Integration in IAM, CloudTrail, Lambda und weitere AWS-Services ist tief. Zugriffskontrollen folgen dem IAM-Modell, Audit-Logs sind zentral verfügbar, der operative Aufwand ist gering. Es gibt keine Server, keine eigene Hochverfügbarkeitslogik, keine Skalierungsfragen. Secret-Management wird konsumiert – ähnlich wie andere AWS-Sicherheitsdienste.

Für klar AWS-zentrierte Architekturen ist das konsistent und effizient. Genau diese Ausrichtung ist jedoch strukturell.

Cloud-spezifisch statt universell

AWS Secrets Manager ist kein universeller Secret-Layer. Er ist ein Cloud-spezifischer Dienst. Zugriffe erfolgen über AWS-APIs, Berechtigungen folgen der IAM-Logik, und Rotation ist primär für AWS-Services vorgesehen.

In Kubernetes-, Hybrid- oder Multi-Cloud-Umgebungen wird Secrets Manager damit zu einem externen Abhängigkeitspunkt. Anwendungen müssen Cloud-spezifische Zugriffspfade kennen oder über zusätzliche Komponenten angebunden werden. Secret-Nutzung ist technisch möglich, liegt aber außerhalb der eigentlichen Plattformlogik.

Secrets werden hier der Cloud untergeordnet – nicht der Anwendung oder der Sicherheitsarchitektur.

HashiCorp Vault: Secrets als Sicherheitsinfrastruktur

HashiCorp Vault verfolgt einen grundlegend anderen Ansatz. Vault ist eine Open-Source-Lösung zur zentralen Verwaltung von Secrets, Zertifikaten und kryptografischem Material. Es versteht sich nicht als reiner Speicher, sondern als aktiver Bestandteil der Sicherheitsarchitektur.

Vault unterstützt dynamische Secrets, zeitlich begrenzte Credentials, fein granulare Policies und umfassende Audit-Logs. Der Dienst lässt sich als eigenständige Komponente betreiben – On-Premises, in Kubernetes oder in Cloud-Umgebungen – und integriert sich über offene Schnittstellen in Anwendungen und Plattformen.

Secrets werden nicht statisch verteilt, sondern bei Bedarf erzeugt und automatisch widerrufen.

Architekturrolle: Speicher vs. Kontrollinstanz

Der architektonische Unterschied liegt in der Rolle von Secrets. AWS Secrets Manager speichert und verteilt sie. Vault kontrolliert ihren Lebenszyklus.

Zugriffe folgen klar definierten Policies, unabhängig vom Cloud-Provider. [Kubernetes]-Authentifizierung, Service-Identitäten, mTLS-Szenarien und kurzlebige Credentials sind integraler Bestandteil des Modells. Anwendungen erhalten nicht „ein Secret", sondern zeitlich und kontextuell begrenzten Zugriff.

Damit wird Secret-Management zu einem aktiven Sicherheitsmechanismus – nicht zu einer Konfigurationsfrage.

Bewusste Gestaltung statt Managed Shortcut

Diese Kontrolle erfordert bewusste Gestaltung. Vault ist kein Managed Shortcut. Hochverfügbarkeit, Storage-Backend, Monitoring, Backup-Strategien und Lifecycle-Management müssen aktiv umgesetzt werden. Das erhöht den initialen Aufwand deutlich.

Im Gegenzug entsteht ein konsistenter Secret-Layer über alle Umgebungen hinweg. Auditierbarkeit ist zentral, Policies sind einheitlich, und die Trennung zwischen Anwendung, Plattform und Infrastruktur bleibt erhalten. Sicherheitsentscheidungen werden nicht implizit durch einen Cloud-Anbieter getroffen, sondern explizit durch die eigene Architektur.

Relevanz für Kubernetes und regulierte Umgebungen

In Kubernetes-zentrierten Plattformen oder Umgebungen mit regulatorischen Anforderungen verschiebt sich die Bewertung deutlich. AWS Secrets Manager vereinfacht Secret-Handling innerhalb von AWS. Vault etabliert eine eigenständige Sicherheitskomponente, die Secrets, Identitäten und Zugriffskontrolle unabhängig von einzelnen Plattformen zusammenführt.

Gerade bei Anforderungen aus NIS-2, Datenschutz, Auditierbarkeit oder Mandantentrennung ist diese Unabhängigkeit entscheidend. Vault erlaubt es, Sicherheitsmodelle konsistent umzusetzen – auch dann, wenn Infrastruktur oder Anbieter wechseln.

Verdichteter Vergleich

Wann welcher Ansatz sinnvoll ist

AWS Secrets Manager ist sinnvoll für:

• rein AWS-zentrierte Architekturen
• enge Integration mit AWS-Diensten
• geringe Anforderungen an Plattformunabhängigkeit
• Fokus auf minimalen Betriebsaufwand

HashiCorp Vault ist sinnvoll für:

• [Kubernetes]- und Plattform-zentrierte Architekturen
• regulierte oder sicherheitskritische Umgebungen
• dynamische Credentials und Zero-Trust-Ansätze
• Organisationen mit Anspruch auf langfristige Souveränität

Fazit

Secrets sind keine Konfigurationsdetails. Sie definieren, wie weit Sicherheit an einen Anbieter ausgelagert wird.

AWS Secrets Manager ordnet Secret-Verwaltung der Cloud unter. HashiCorp Vault etabliert sie als eigenständige Sicherheitsarchitektur.

Der Unterschied ist nicht funktional, sondern strategisch. Wer Secrets als Cloud-Funktion betrachtet, akzeptiert Abhängigkeit. Wer sie als Infrastruktur begreift, behält Kontrolle – auch dann, wenn sich Plattformen, Anbieter oder regulatorische Rahmenbedingungen ändern.