AWS Secrets Manager vs. Azure Key Vault vs. GCP Secret Manager: 2026 Deep Dive

Die Wahl der richtigen Cloud-Secret-Management-Lösung im Jahr 2026 umfasst mehr als nur Feature-Checklisten. Es geht um direkte Kostenauswirkungen, operativen Overhead, Integrationstiefe innerhalb eines spezifischen Cloud-Ökosystems und Compliance-Anforderungen. Diese Analyse durchdringt das Marketing, um AWS Secrets Manager (einschließlich Parameter Store für spezifische Anwendungsfälle), Azure Key Vault (Standard-, Premium- und Managed HSM-Tiers) und Google Secret Manager (mit Cloud KMS Interoperabilität) detailliert darzustellen. Der Fokus liegt hier auf technischer Differenzierung und strategischer Eignung für Enterprise-Anwendungsfälle.

Kernfunktionen & Design-Paradigmen

AWS Secrets Manager (ASM) priorisiert Automatisierung und breite Integration. Seine Kernfunktion ist das Speichern, Abrufen und Rotieren von Secrets. Secrets können von Datenbank-Credentials bis hin zu API-Keys reichen. ASM integriert sich direkt mit RDS, Redshift und DocumentDB für die native Rotation. Während KMS Secrets im Ruhezustand verschlüsselt, kümmert sich ASM um den Lebenszyklus. AWS Parameter Store, oft für Secrets übersehen, kann kleinere, weniger sensible Secrets (bis zu 10KB) zu geringeren Kosten speichern und fungiert als hierarchischer Konfigurationsspeicher mit optionaler KMS-Verschlüsselung. Die Unterscheidung ist kritisch: Parameter Store ist für Konfiguration, Secrets Manager für Credentials.

Azure Key Vault (AKV) ist ein vereinheitlichter Dienst für Secrets, Keys und Zertifikate. Diese Konsolidierung reduziert den Management-Overhead für Umgebungen, die stark auf PKI basieren oder Hardware-gestützten Key Storage benötigen. AKV bietet Standard (Software-gestützte Keys) und Premium (FIPS 104-2 Level 2 validierte HSM-gestützte Keys). Azure Managed HSM ist ein dedizierter, Single-Tenant, FIPS 140-2 Level 3 validierter HSM-Service, der eine höhere Absicherungsebene für kritische kryptographische Operationen, einschließlich importierbarer Keys, bietet. Die architektonische Wahl zwischen diesen Tiers beeinflusst direkt die Sicherheitslage und die Kosten.

Google Secret Manager (GSM) ist von Anfang an auf Einfachheit und globale Zugänglichkeit ausgelegt. Secrets sind globale Ressourcen, werden automatisch versioniert und integrieren sich eng mit Cloud IAM. Die primäre Verschlüsselung von GSM wird von Cloud KMS gehandhabt, wobei Customer-Managed Encryption Keys (CMEK) und Customer-Supplied Encryption Keys (CSEK) unterstützt werden. Es zeichnet sich durch die Zugriffskontrolle pro Secret und einen starken Fokus auf die Secret-Versionierung aus, was einen grundlegenden Aspekt seines Betriebs darstellt. Im Gegensatz zu AKV verwaltet GSM nicht nativ Zertifikate, sondern konzentriert sich rein auf die Secret- und Key-Speicherung.

Sicherheitsmerkmale: HSM, Verschlüsselung & Zero Trust

Alle drei Dienste bieten Verschlüsselung im Ruhezustand und während der Übertragung (TLS 1.2/1.3). Der Unterschied liegt in der Unterstützung für kryptographische Operationen und der Key-Provenienz. AWS Secrets Manager verlässt sich auf AWS KMS, das FIPS 140-2 Level 2 validierte Hardware Security Modules verwendet. Secrets in ASM werden mithilfe eines Datenschlüssels verschlüsselt, der von einem KMS Customer Master Key (CMK) abgeleitet wird. Explizit bietet ASM keine direkte FIPS 140-2 Level 3 Lösung auf der Secret-Management-Ebene, obwohl KMS selbst mit diesem Sicherheitsniveau bereitgestellt werden kann.

Azure Key Vault Premium verwendet nCipher (jetzt Entrust) HSMs für Keys und bietet FIPS 140-2 Level 2 Validierung. Azure Managed HSM, ein Managed Service innerhalb von AKV, liefert dedizierte Thales Luna Network HSMs, die FIPS 140-2 Level 3 Validierung bieten. Dies ist ein erheblicher Vorteil für stark regulierte Branchen, die eine hohe kryptographische Isolation und den Nachweis der Hardware-gestützten Key-Generierung benötigen. Zum Vergleich: Eine Single-Tenant Managed HSM Instanz beginnt bei ca. 5000 $/Monat zuzüglich Transaktionskosten.

Google Secret Manager verwendet Cloud KMS für alle kryptographischen Operationen. Cloud KMS selbst bietet FIPS 140-2 Level 1 Validierung für Software-gestützte Keys und FIPS 140-2 Level 2 für Hardware-gestützte Keys, verfügbar über spezifische Keyring-Konfigurationen. GSM Secrets werden mit einem Envelope Encryption Schema verschlüsselt, bei dem ein Data Encryption Key (DEK) das Secret verschlüsselt und ein Key Encryption Key (KEK) von Cloud KMS den DEK verschlüsselt. Für Kunden, die FIPS 140-2 Level 3 benötigen, existiert die explizite Option nicht direkt innerhalb von GSM, sondern stützt sich auf separate Angebote im Zusammenhang mit dedizierten HSMs oder kundenspezifischen Key-Management-Systemen, die mit Google Cloud integriert sind – was die Komplexität erhöht.

IAM Granularität & Auditierbarkeit

Identity und Access Management (IAM) ist entscheidend. AWS Secrets Manager integriert sich mit AWS IAM Policies auf Secret-Ebene. Sie können granulare Berechtigungen (z.B. secretsmanager:GetSecretValue, secretsmanager:RotateSecret) für spezifische Principals oder Rollen auf einzelne Secrets über ressourcenbasierte oder identitätsbasierte Policies definieren. CloudTrail erfasst alle API-Aufrufe und bietet eine vollständige Audit-Trail für den Secret-Zugriff und die Modifikation. Diese granulare Kontrolle ist eine Stärke von AWS und ermöglicht feinkörnige Zero-Trust-Implementierungen.

Azure Key Vault verwendet Azure Role-Based Access Control (RBAC) auf Vault-Ebene und auch ein älteres Zugriffsrichtlinienmodell (obwohl RBAC bevorzugt wird). RBAC ermöglicht Rollenzuweisungen in verschiedenen Scopes (Management Group, Subscription, Resource Group, individueller Vault) mit vordefinierten Rollen (z.B. Key Vault Reader, Key Vault Secrets Officer) oder benutzerdefinierten Rollen. Für den Zugriff auf einzelne Secrets kann RBAC direkt auf ein Secret angewendet werden. Azure Monitor Logs (über Diagnostic Settings) erfassen alle Key Vault Operationen, einschließlich des Secret-Zugriffs, und unterstützen die Integration mit Azure Sentinel für SIEM. Die Umstellung auf RBAC hat die IAM-Verwaltung für AKV vereinfacht.

Google Secret Manager nutzt Google Cloud IAM extensiv. Berechtigungen werden auf Projekt-, Ordner- oder individueller Secret-Ebene mit primitiven Rollen (z.B. roles/secretmanager.secretAccessor, roles/secretmanager.secretVersionManager) oder benutzerdefinierten Rollen definiert. Diese Fähigkeit zur versionsbasierten Zugriffskontrolle pro Secret, kombiniert mit IAM, bedeutet präzise Kontrolle darüber, welche Principals auf eine spezifische Version eines Secrets zugreifen können. Cloud Audit Logs (Admin Activity, Data Access) erfassen alle Secret-Management-Operationen und bieten detaillierte, unveränderliche Logs für Compliance und Forensik. Googles IAM-Bedingungsfunktion ermöglicht eine weitere Feingranularität basierend auf Attributen wie IP-Quelle oder Tageszeit.

Secret Rotation & Integrations-Ökosystem

AWS Secrets Manager bietet eine integrierte Rotation für RDS, Redshift, DocumentDB und andere Dienste über Lambda-Funktionen. Dies ist wohl seine stärkste praktische Funktion. Benutzerdefinierte Rotationen für andere Dienste sind mit Python Lambda-Funktionen realisierbar. Für Kubernetes ermöglicht der AWS Secrets & Configuration Provider für den CSI-Treiber das direkte Mounten von Secrets in Pods. IaC-Tools wie Terraform unterstützen ASM für die Secret-Erstellung, das Abrufen und die Rotationskonfiguration. Dynamische Secrets für Datenbanken, die unterschiedliche Credentials pro Verbindung erfordern, werden üblicherweise mithilfe der Rotations-Hooks von ASM oder benutzerdefinierten Lambda-Funktionen implementiert.

Azure Key Vault verfügt über Rotationsfähigkeiten für Zertifikate, aber keine native automatisierte Secret-Rotation für beliebige Credentials. Für Datenbankpasswörter sind hierfür in der Regel benutzerdefinierte Azure Functions erforderlich oder die Integration in CI/CD-Pipelines, um Secrets regelmäßig zu aktualisieren. AKV integriert sich mit dem Azure Kubernetes Service (AKS) CSI-Treiber zum Mounten von Secrets. Terraform bietet umfassende Unterstützung für die Verwaltung von AKV-Vaults, Keys und Secrets. Die dynamische Secret-Generierung ist innerhalb der nativen Funktionen von AKV weniger explizit; sie wird typischerweise von der verbrauchenden Anwendung oder einem externen Credential-Brokering-Service gehandhabt.

Google Secret Manager unterstützt das Festlegen eines Rotationsplans für Secrets, der eine Pub/Sub-Nachricht auslöst. Diese Nachricht kann dann eine Cloud Function aufrufen, um die eigentliche Credential-Aktualisierung und die Secret-Versionsrotation durchzuführen. Dieses Design ist flexibel, erfordert aber für die meisten Backends benutzerdefinierten Code. Für Kubernetes ermöglicht der Google Secret Manager CSI-Treiber, Secrets als Dateien in Pods verfügbar zu machen. Terraform verwaltet GSM-Secrets effektiv, und seine Integration mit Cloud KMS bietet starke Optionen zur Key Control. Dynamische Secrets sind möglich, stützen sich aber wiederum auf Cloud Functions, die durch Rotationsereignisse ausgelöst werden.

Preisvergleich (ungefähre Listenpreise 2026)

Preismodelle sind entscheidend und oft komplex, da sie die Speicherung pro Secret und die Kosten pro API-Aufruf umfassen. Diese Zahlen dienen als Veranschaulichung und unterliegen regionalen Unterschieden und Enterprise-Rabatten.

Feature	AWS Secrets Manager	Azure Key Vault (Premium)	GCP Secret Manager
Speicherung pro Secret/Monat (erste 10k)	0,40 $	3,00 $ (Keys, Secrets, Zertifikate)	0,06 $
API-Aufrufe pro 10k Operationen	0,05 $	0,03 $ (Secrets & Keys)	0,03 $
Obligatorische Rotationsgebühr	0,05 $/Secret/Monat (wenn aktiviert)	N/A (benötigt Custom-Lösung)	N/A (Pub/Sub + Cloud Function verursacht Kosten)
Managed HSM (optional)	N/A direkt	~5000 $/Monat dedizierte HSM-Instanz + Operationen	N/A direkt
Beispiel: 1000 Secrets, 1 Million API-Aufrufe/Monat	400 $ (Speicherung) + 500 $ (API) = 900 $ (+ bis zu 50 $ für Rotation)	3000 $ (Speicherung) + 300 $ (API) = 3300 $	60 $ (Speicherung) + 300 $ (API) = 360 $
Beispiel: 100 Secrets, 100.000 API-Aufrufe/Monat	40 $ (Speicherung) + 5 $ (API) = 45 $	300 $ (Speicherung) + 3 $ (API) = 303 $	6 $ (Speicherung) + 3 $ (API) = 9 $

Beachten Sie den deutlichen Unterschied bei den Speicherkosten. Der Premium-Tier von Azure Key Vault bietet zwar HSM-Überlegenheit, ist aber pro gespeichertem Secret deutlich teurer. GCP Secret Manager hat offensichtlich die niedrigsten Speicherkosten, was ihn für große Secret-Anzahlen mit moderatem API-Traffic attraktiv macht. AWS wird bei hohen API-Aufrufvolumina wettbewerbsfähig, da der Preis pro Aufruf im Vergleich zu den Speicherkosten relativ gering ist.

Betrachtungen zu Cross-Region & Disaster Recovery

AWS Secrets Manager ist ein regionaler Dienst. Für Disaster Recovery oder Multi-Region-Deployments müssen Secrets über Regionen hinweg repliziert werden. Sie können diese Replikation mithilfe von Lambda-Funktionen automatisieren, die durch CloudWatch Events bei Änderungen an Secrets ausgelöst werden, oder indem Sie individuelle Secrets in jeder Region definieren. Dies erfordert eine architektonische Planung, um Konsistenz zu gewährleisten und Split-Brain-Szenarien während eines Failovers zu verhindern.

Azure Key Vault ist ebenfalls ein regionaler Dienst. Während Secrets innerhalb derselben Region zur Sicherung geo-repliziert werden, erfordert die Cross-Region-Replikation weiterhin die manuelle oder skriptgesteuerte Bereitstellung von Vaults und Secrets in mehreren Regionen. Dies kann Azure Resource Manager (ARM)-Templates, Terraform oder Azure CLI-Skripte umfassen, um die Synchronisierung der Secrets sicherzustellen. Managed HSMs werden in einer bestimmten Region bereitgestellt und bieten keine automatische globale Cross-Region-Replikation, wodurch eine manuelle Konfiguration für DR erforderlich ist.

Google Secret Manager bietet Secrets als globale Ressourcen an. Wenn Sie ein Secret erstellen, ist es global zugänglich und seine Versionen werden in mehreren Google Cloud-Regionen gespeichert. Dies vereinfacht die Cross-Region-Disaster-Recovery aus Sicht des Secret-Managements erheblich. Die Data Plane ist global verfügbar und konsistent, was einen Großteil des DR-Planungsaufwands für den Secret-Zugriff eliminiert, obwohl Zugriffsrichtlinien in einigen Fällen regionsspezifisch bleiben.

Konfigurations-Snippets & IaC Best Practices

Der Einsatz von Infrastructure as Code (IaC) ist entscheidend für das Management von Secrets. Hier ein Terraform-Beispiel für die Erstellung eines Secrets in jeder Plattform:

# AWS Secrets Manager Secret
resource "aws_secretsmanager_secret" "db_credentials" {
  name                    = "production/app/db_credentials"
  description             = "Database credentials for the main application."
  recovery_window_in_days = 7
  rotation_lambda_arn     = aws_lambda_function.db_rotation_function.arn
  rotation_rules {
    automatically_after_days = 90
  }
}

resource "aws_secretsmanager_secret_version" "db_credentials_version" {
  secret_id     = aws_secretsmanager_secret.db_credentials.id
  secret_string = jsonencode({
    username = "admin"
    password = "super_secret_pw"
  })
}

# Azure Key Vault Secret
resource "azurerm_key_vault" "main" {
  name                          = "mykv-2026-prod"
  location                      = "eastus"
  resource_group_name           = azurerm_resource_group.main.name
  sku_name                      = "premium"
  tenant_id                     = data.azurerm_client_config.current.tenant_id
  enabled_for_disk_encryption   = true
  purge_protection_enabled      = true
  soft_delete_retention_days    = 90
}

resource "azurerm_key_vault_secret" "db_password" {
  name         = "db-password"
  value        = "super_secret_pw_az"
  key_vault_id = azurerm_key_vault.main.id
  content_type = "application/text"
}

# GCP Secret Manager Secret
resource "google_secret_manager_secret" "api_key_prod" {
  secret_id = "api-key-prod"
  project   = var.gcp_project_id
  replication {
    automatic = true
  }
  rotation {
    rotation_period = "2592000s" # 30 days
  }
}

resource "google_secret_manager_secret_version" "api_key_prod_version" {
  secret      = google_secret_manager_secret.api_key_prod.id
  secret_data = "gcp_super_secret_key"
}

Es ist entscheidend, sensible Werte wie secret_string oder value in Ihren IaC-State-Dateien zu verschlüsseln, falls kein Secrets-Backend wie HashiCorp Vault verwendet wird. In diesem Beispiel ist super_secret_pw der Kürze halber hart kodiert, sollte aber in der Praxis sicher übergeben werden, z.B. über Umgebungsvariablen oder ein separates Secrets-Management-Tool, das sie zur Bereitstellungszeit injiziert, oder durch die Nutzung des Secret-Speichers des Cloud-Anbieters selbst für die anfängliche Bereitstellung.

Fazit: Szenarien für die Wahl

Wählen Sie AWS Secrets Manager, wenn: Sie stark in AWS investiert sind, insbesondere RDS, Redshift oder DocumentDB verwenden und die native automatische Rotation schätzen. Die Preisgestaltung skaliert gut mit API-Aufrufen, sobald die Speicherkosten absorbiert sind. Wenn Sie eine umfassende, integrierte Lösung für sowohl Credentials als auch Konfiguration (mit Parameter Store) benötigen, bietet AWS ein starkes Ökosystem. Ziehen Sie dies für cloud-native AWS-Anwendungen in Betracht, bei denen Lambda-gesteuerte Automatisierung eine Kernstrategie ist.

Wählen Sie Azure Key Vault, wenn: Ihr Unternehmen hohe Compliance-Anforderungen hat (z.B. FIPS 140-2 Level 3 mit Managed HSM), eine bedeutende PKI-Landschaft oder einen vereinheitlichten Speicher für Keys, Secrets und Zertifikate benötigt. Azure-zentrierte Organisationen, die Azure Active Directory (jetzt Entra ID) und Azure-Dienste stark nutzen, werden die Integration von AKV als kohärent empfinden. AKV ist die Wahl für hybride Szenarien, in denen Keys von On-Premises-HSMs stammen und sicher in Azure importiert werden müssen.

Wählen Sie Google Secret Manager, wenn: Kosteneffizienz für eine große Anzahl von Secrets von größter Bedeutung ist oder Sie ein global verteiltes, einfaches Secret-Management-System mit automatischer Versionierung priorisieren. GSM ist ideal für Microservices-Architekturen auf GKE (Google Kubernetes Engine) und Serverless Functions (Cloud Functions, Cloud Run) innerhalb des GCP-Ökosystems. Seine pauschale, niedrige Speicherkosten machen es attraktiv für ein hohes Volumen an Secrets mit geringem Zugriff.

Letztendlich richtet sich die beste Wahl nach Ihrer bestehenden Cloud-Strategie, regulatorischen Anforderungen, dem Betriebsmodell und spezifischen Budgetbeschränkungen. Vermeiden Sie vorzeitige Optimierung; beginnen Sie mit dem nativen Angebot Ihres Cloud-Anbieters und skalieren Sie die Anforderungen nur bei Bedarf hoch.

Zugehörige Lektüre

• FortiGate 7.6 NGFW Design: Beyond the Basics
• Palo Alto Networks Prisma Cloud CNAPP Report 2026
• AWS CloudFront WAF Optimierungen für High-Traffic Anwendungen 2026
• Azure Sentinel SIEM Integrations Best Practices
• GCP Zero Trust: BeyondCorp Implementierungsstrategien