HashiCorp Vault: Die Referenz-Architektur für zentrales Secrets Management & Encryption
Fabian Peter 5 Minuten Lesezeit

HashiCorp Vault: Die Referenz-Architektur für zentrales Secrets Management & Encryption

In einer Multi-Cloud-Welt ist Sicherheit keine Frage des Ortes, sondern der Identität. Wer sich auf Cloud-spezifische Tools wie AWS Secrets Manager verlässt, fragmentiert seine Sicherheitsstrategie und schafft blinde Flecken. HashiCorp Vault ist der Industriestandard, um dieses Chaos zu ordnen. Es fungiert als zentraler Broker für Vertrauen: Es verwaltet nicht nur statische Geheimnisse, sondern generiert dynamische Credentials „Just-in-Time" und bietet Encryption-as-a-Service, um sensible Daten zu schützen, bevor sie jemals in einer Datenbank landen.
hashicorp-vault secrets-management dynamic-secrets encryption-as-a-service identity-based-security cloud-security kubernetes

TL;DR

In einer Multi-Cloud-Welt ist Sicherheit keine Frage des Ortes, sondern der Identität. Wer sich auf Cloud-spezifische Tools wie AWS Secrets Manager verlässt, fragmentiert seine Sicherheitsstrategie und schafft blinde Flecken. HashiCorp Vault ist der Industriestandard, um dieses Chaos zu ordnen. Es fungiert als zentraler Broker für Vertrauen: Es verwaltet nicht nur statische Geheimnisse, sondern generiert dynamische Credentials „Just-in-Time" und bietet Encryption-as-a-Service, um sensible Daten zu schützen, bevor sie jemals in einer Datenbank landen.

1. Das Architektur-Prinzip: Identity-based Security

Traditionelle Sicherheit basierte auf IPs und Netzwerken (Firewalls). In Kubernetes, wo Pods kommen und gehen, funktioniert das nicht mehr.

Vault etabliert Identität als neue Sicherheitsgrenze.

  • Universal Auth: Egal ob ein Kubernetes Pod, eine AWS EC2 Instanz oder ein Entwickler via LDAP – Vault authentifiziert die Anfrage gegen vertrauenswürdige Quellen (z.B. Kubernetes Service Accounts).
  • Der Broker: Erst nach erfolgreicher Authentifizierung tauscht Vault diese Identität gegen ein kurzlebiges Token, das Zugriff auf genau definierte Geheimnisse gewährt. Die Applikation muss keine statischen Passwörter mehr in Config-Dateien speichern.

2. Kern-Feature: Dynamic Secrets (Das Ende statischer Passwörter)

Das größte Risiko in der IT sind langlebige Credentials (“Rotation Fatigue”). Ein Datenbank-Passwort, das seit 3 Jahren gilt, ist ein Sicherheitsrisiko.

AWS Secrets Manager kann zwar rotieren, aber Vault geht einen Schritt weiter mit Dynamic Secrets.

  1. Ein Service (z.B. Order-Service) fragt Vault: “Ich brauche Zugriff auf die Postgres-Datenbank”.

  2. Vault verbindet sich zur Datenbank, legt in diesem Moment einen neuen User mit Passwort an (z.B. v-token-order-123).

  3. Vault gibt diese Credentials an den Service zurück.

  4. Nach Ablauf der Zeit (TTL, z.B. 1 Stunde) löscht Vault den User automatisch wieder.

    Das Resultat: Es gibt kein “Master-Passwort” mehr, das gestohlen werden kann. Credentials existieren nur solange, wie sie gebraucht werden.

3. Encryption as a Service (Transit Engine)

Entwickler sollten keine Kryptografie programmieren (“Don’t roll your own crypto”). Fehler bei der Implementierung von AES sind vorprogrammiert.

Vault bietet die Transit Engine.

Applikationen senden Daten (z.B. Kreditkartennummern) an die Vault API und erhalten den verschlüsselten Ciphertext zurück. Nur Vault besitzt den Schlüssel. Die Applikation speichert nur den Ciphertext in der Datenbank. Selbst wenn die Datenbank gestohlen wird (“SQL Dump”), sind die Daten nutzlos, da der Schlüssel sicher im Vault verbleibt.

4. Betriebsmodelle im Vergleich: AWS Secrets Manager/KMS vs. ayedo Managed Vault

Hier entscheidet sich, ob Ihre Sicherheit an einen Anbieter gekettet ist oder ob Sie eine globale Sicherheits-Plattform betreiben.

Szenario A: AWS Secrets Manager & KMS (Die fragmentierte Lösung)

AWS bietet solide Tools, aber sie sind Insel-Lösungen.

  • Kosten-Skalierung: AWS Secrets Manager kostet $0.40 pro Secret pro Monat plus API-Gebühren. Bei einer Microservices-Architektur mit tausenden dynamischen Secrets wird das schnell teuer.
  • Kein Multi-Cloud: KMS-Schlüssel aus AWS können keine Daten in Azure oder On-Prem entschlüsseln. Sie müssen für jede Umgebung separate Sicherheitskonzepte bauen.
  • Statik: Der Fokus liegt auf dem Speichern von Geheimnissen, nicht auf der dynamischen Erzeugung. Echte “Just-in-Time” Zugriffe sind mit AWS-Boardmitteln komplex zu bauen.

Szenario B: HashiCorp Vault mit Managed Kubernetes von ayedo

Im ayedo App-Katalog ist Vault die zentrale Festung.

  • Unified Interface: Eine API, ein Workflow. Egal ob die App auf AWS EKS oder im lokalen Rechenzentrum läuft – sie spricht immer mit Vault.
  • Agent Injector: Vault integriert sich nativ in Kubernetes. Ein “Sidecar”-Container injiziert Geheimnisse direkt in das Dateisystem des Pods oder als Umgebungsvariable. Die Applikation muss oft nicht einmal wissen, dass Vault existiert.
  • Kosten-Kontrolle: Da Vault als Software in Ihrem Cluster läuft, zahlen Sie für die Infrastruktur, nicht pro Secret. Sie können Millionen von dynamischen Credentials generieren, ohne dass die Rechnung explodiert.

Technischer Vergleich der Betriebsmodelle

Aspekt AWS Secrets Manager / KMS ayedo (Managed Vault)
Geheimnis-Typ Primär Statisch (Rotation möglich) Dynamisch (Just-in-Time User)
Verschlüsselung KMS (Transparent für AWS Services) Transit Engine (API für Apps)
Multi-Cloud Nein (Nur AWS) Ja (Läuft überall)
Kosten Pay-per-Secret + API Calls Infrastruktur (Flat)
Integration AWS SDK / IAM K8s Sidecar / Universal API
Strategisches Risiko Hoher Lock-in (KMS Abhängigkeit) Volle Souveränität

FAQ: Vault & Security Strategy

Ist Vault nicht extrem komplex zu betreiben?

Ja, Vault gilt als eines der komplexesten Tools im Cloud-Native-Stack (“Day 2 Operations”, Unsealing, High Availability). Genau deshalb ist es Teil des Managed Stacks von ayedo. Wir kümmern uns um das Auto-Unsealing (automatisches Entsperren nach Neustart), Backups und Upgrades, sodass Sie Vault einfach als API konsumieren können.

Warum reicht nicht der External Secrets Operator (ESO)?

ESO (siehe separater Artikel) ist großartig, um vorhandene Secrets von A nach B zu synchronisieren. Vault ist jedoch eine Secret Engine. ESO kann keine Datenbank-User dynamisch anlegen oder Daten verschlüsseln (Transit). In vielen Architekturen nutzen wir beides: Vault als die Quelle der Wahrheit und ESO, um Vault-Secrets in Namespaces zu verteilen.

Was passiert, wenn Vault ausfällt?

Da Vault im Zentrum aller Applikationen steht, ist es eine kritische Komponente. Im ayedo Stack wird Vault deshalb im High-Availability (HA) Modus mit einem Raft-Storage-Backend betrieben. Mehrere Instanzen laufen verteilt über Nodes (und AZs). Fällt der Leader aus, übernimmt sofort ein Standby-Node.

Kann Vault auch Zertifikate ausstellen (PKI)?

Ja. Vault kann als vollständige Certificate Authority (CA) fungieren. Es kann kurzlebige TLS-Zertifikate für Microservices, VPNs oder SSH-Zugriffe ausstellen. Das macht es zu einer mächtigen Alternative zu AWS Private CA (die sehr teuer ist).

Fazit

Sicherheit darf kein nachträglicher Gedanke und keine Insel-Lösung sein. Wer AWS Secrets Manager nutzt, löst ein Speicherproblem. Wer HashiCorp Vault nutzt, löst ein Architekturproblem. Vault ermöglicht “Zero Trust” bis in den Kern der Applikation, unabhängig davon, auf welcher Wolke sie schwebt. Mit dem ayedo Managed Stack erhalten Sie diese mächtige Sicherheits-Infrastruktur betriebsbereit – den “Fort Knox” für Ihre digitalen Assets, ohne den operativen Aufwand des Tresorbaus.

Ähnliche Artikel