Cloud Key Management: AWS KMS, Azure Key Vault und HashiCorp Vault im Vergleich

Cloud Key Management ist eine der kritischsten Sicherheitsdisziplinen in modernen Cloud-Architekturen. Falsch konfiguriertes Key Management fuehrt zu den weitreichendsten Datenpannen - nicht weil Verschluesselung gebrochen wurde, sondern weil Schluessel falsch verwaltet wurden. Dieser Artikel erklaert die wichtigsten Cloud-KMS-Loesungen und Best Practices.

Grundkonzepte

Key-Hierarchie und Envelope Encryption

Cloud Key Management basiert auf zwei zentralen Schluesseltypen:

Customer Master Key (CMK): Verbleibt immer im KMS und verlaesst ihn nie. Wird genutzt, um Data Encryption Keys zu verschluesseln. Kann auf einem HSM (Hardware Security Module) gesichert sein.

Data Encryption Key (DEK): Verschluesselt die eigentlichen Daten (symmetrisch, AES-256). Wird selbst mit dem CMK verschluesselt (Envelope Encryption). Der Plaintext-DEK existiert nur kurz im Speicher und wird dann verworfen. Der verschluesselte DEK wird neben den Daten gespeichert.

Ablauf der Envelope Encryption

1. DEK generieren (zufaellig, 256-Bit)
2. Daten mit DEK verschluesseln: Encrypted_Data = AES256(Data, DEK)
3. DEK mit CMK verschluesseln: Encrypted_DEK = KMS.Encrypt(DEK, CMK)
4. Speichern: Encrypted_Data + Encrypted_DEK zusammen
5. DEK (Plaintext) aus Speicher loeschen

Zum Entschluesseln wird der Vorgang umgekehrt: Der verschluesselte DEK wird ueber den KMS entschluesselt, die Daten damit wiederhergestellt und der DEK erneut verworfen.

Der Vorteil: Der CMK verlaesst den KMS nie und bleibt sicher im HSM. KMS-Aufrufe fallen nur fuer die DEK-Ver- und Entschluesselung an, waehrend die Bulk-Daten direkt verschluesselt werden - ohne KMS-Overhead pro Byte.

AWS KMS

AWS Key Management Service unterscheidet drei Schluesseltypen:

Schluesseltyp	Beschreibung	Verwaltung
AWS-Managed Key	Automatisch von AWS erstellt und rotiert (z.B. aws/s3, aws/ebs)	AWS
Customer-Managed Key (CMK)	Vom Kunden erstellt und kontrolliert	Kunde
AWS-Owned Key	AWS-intern, fuer Kunden nicht sichtbar	AWS

CMK erstellen

# CMK erstellen (AES-256-GCM)
aws kms create-key \
  --description "Produktion-Datenbankschluessel" \
  --key-usage ENCRYPT_DECRYPT \
  --key-spec SYMMETRIC_DEFAULT

# Multi-Region Key (fuer DR-Szenarien)
aws kms create-key --multi-region \
  --description "Multi-Region-Key fuer globale App"

Fuer FIPS 140-2 Level 3 kann ein CloudHSM-Cluster als Custom Key Store verwendet werden: --origin AWS_CLOUDHSM.

Key Policy (Zugriffskontrolle)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Key Admin",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789:role/KeyAdminRole"},
      "Action": ["kms:Create*", "kms:Describe*", "kms:Delete*",
                 "kms:Enable*", "kms:Disable*", "kms:RotateKey"],
      "Resource": "*"
    },
    {
      "Sid": "Key Usage",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789:role/AppRole"},
      "Action": ["kms:Encrypt", "kms:Decrypt",
                 "kms:GenerateDataKey", "kms:ReEncrypt*"],
      "Resource": "*"
    }
  ]
}

Der Root-Account sollte immer in der Key-Policy enthalten sein, um den Kontozugang zu sichern.

Automatische Key-Rotation und BYOK

Automatische Rotation (365 Tage) wird per aws kms enable-key-rotation --key-id alias/prod-db-key aktiviert. AWS rotiert jaehrlich und behaelt alte Schluesselversionen fuer die Entschluesselung historischer Daten.

Fuer BYOK (Bring Your Own Key) wird ein Wrapping-Key von AWS angefordert, der eigene Schluessel damit verschluesselt und anschliessend importiert. So behaelt der Kunde die Kontrolle ueber das Schluesselmaterial.

S3-Verschluesselung mit CMK erzwingen

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnencryptedObjectUploads",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
      "StringNotEquals": {
        "s3:x-amz-server-side-encryption": "aws:kms"
      }
    }
  }]
}

Azure Key Vault

Azure Key Vault verwaltet drei Objekt-Typen: Keys (kryptografische Schluessel), Secrets (Passwoerter, API-Keys, Connection Strings) und Certificates (TLS/SSL-Zertifikate mit automatischer Erneuerung). Der Standard-Tier bietet Software-Keys, der Premium-Tier HSM-gesicherte Keys (FIPS 140-2 Level 2/3).

Key Vault erstellen (Terraform)

resource "azurerm_key_vault" "prod" {
  name                = "kv-prod-app-westeu"
  resource_group_name = azurerm_resource_group.main.name
  location            = "westeurope"
  tenant_id           = data.azurerm_client_config.current.tenant_id
  sku_name            = "premium"

  soft_delete_retention_days = 90
  purge_protection_enabled   = true  # Verhindert Datenverlust

  network_acls {
    bypass         = "AzureServices"
    default_action = "Deny"
    ip_rules       = ["10.0.0.0/8"]
  }
}

resource "azurerm_key_vault_access_policy" "app" {
  key_vault_id = azurerm_key_vault.prod.id
  tenant_id    = data.azurerm_client_config.current.tenant_id
  object_id    = azurerm_user_assigned_identity.app.principal_id

  key_permissions    = ["Get", "WrapKey", "UnwrapKey"]
  secret_permissions = ["Get", "List"]
}

Secret-Zugriff aus der Anwendung

from azure.identity import ManagedIdentityCredential
from azure.keyvault.secrets import SecretClient

credential = ManagedIdentityCredential()
vault_url = "https://kv-prod-app-westeu.vault.azure.net/"
client = SecretClient(vault_url=vault_url, credential=credential)

db_password = client.get_secret("database-password").value
api_key = client.get_secret("external-api-key").value

Zertifikate koennen ueber Key Vault automatisch erstellt, erneuert und deployt werden - mit Anbindung an Issuer wie DigiCert oder Let's Encrypt.

HashiCorp Vault

HashiCorp Vault ist die plattformunabhaengige Alternative: On-Premises, AWS, Azure und GCP werden gleichermassen unterstuetzt. Die groessten Vorteile gegenueber nativen Cloud-KMS-Diensten sind Dynamic Secrets (Credentials werden on-demand generiert und verfallen automatisch) und das Lease-System.

Dynamic Secrets (Datenbank)

Statt statischer Datenbank-Passwoerter generiert Vault temporaere Credentials mit begrenzter Lebensdauer:

# PostgreSQL-Plugin aktivieren
vault secrets enable database

vault write database/config/postgres \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db:5432/appdb" \
  username="vault-admin" password="admin-password"

# Role: generiert temporaeren DB-User (gueltig fuer 1 Stunde)
vault write database/roles/app-role \
  db_name=postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# App ruft Credentials ab
vault read database/creds/app-role

Nach einer Stunde sind die Credentials ungueltig. Ein Angreifer mit gestohlenem Credential hat damit nur ein kurzes Zeitfenster.

Transit Encryption (Encryption-as-a-Service)

Vault kann als zentraler Verschluesselungsdienst genutzt werden, ohne dass die Anwendung selbst Schluessel verwalten muss:

vault secrets enable transit
vault write transit/keys/myapp-key type=aes256-gcm96

# Verschluesseln
vault write transit/encrypt/myapp-key \
  plaintext=$(echo "sensitiver Text" | base64)

# Entschluesseln
vault write transit/decrypt/myapp-key \
  ciphertext="vault:v1:...encrypted..."

Fuer Kubernetes-Umgebungen authentifiziert sich die App ueber den Service Account - ohne statische Tokens oder Credentials.

Key-Management Best Practices

Key-Rotation

Automatische Rotation sollte mindestens jaehrlich erfolgen. Bei Verdacht auf Kompromittierung ist eine sofortige On-Demand-Rotation noetig. Wichtig: Rotation bedeutet nicht automatisch die Neuverschluesselung aller Daten - dafuer ist eine separate DEK Re-Encryption erforderlich. Altes Schluesselmaterial muss fuer die Entschluesselung historischer Daten aufbewahrt werden.

Least Privilege fuer Keys

Rolle	Berechtigungen
Entwicklung	Keine Produktions-Keys
Read-Only	Nur Entschluesselung, kein Key-Management
Audit	Nur Describe/List, kein Encrypt/Decrypt
Break-Glass	Separater Admin-Key fuer Notfaelle (MFA-geschuetzt)

BYOK vs. HYOK

BYOK (Bring Your Own Key): Eigenes Schluesselmaterial wird in den Cloud-KMS importiert. Das bietet mehr Kontrolle und Auditierbarkeit, allerdings hat der Cloud-Provider weiterhin HSM-Zugang. Empfohlen fuer regulatorische Compliance-Anforderungen.

HYOK (Hold Your Own Key / Double Encryption): Der Schluessel verbleibt on-premises im eigenen HSM. Der Cloud-Provider kann die Daten niemals entschluesseln. Dieses Modell eignet sich fuer sehr hohe Anforderungen (Behoerden, Staatsgeheimnisse), bringt aber Nachteile bei Latenz, HSM-Betrieb und Cloud-Auto-Scaling mit sich.

Compliance-Anforderungen

Standard	Anforderung
FIPS 140-2 Level 2	Physischer Schutz (AWS KMS Standard, Azure Key Vault Premium)
FIPS 140-2 Level 3	Tamper-Evidence, kritische Sicherheitsparameter (AWS CloudHSM)
BSI TR-02102	RSA >= 3000-Bit (bis 2030), empfohlen 4096-Bit; AES-256 im GCM-Modus

Monitoring und Alerting

Alle KMS-API-Calls sollten geloggt werden (AWS CloudTrail, Azure Monitor Diagnostic Logs). Alerts empfehlen sich fuer unerwartete Entschluesselungsanfragen, Key-Management-Operationen ausserhalb der Geschaeftszeiten und Deny-Responses auf Key-Zugriffe - letztere deuten auf Konfigurationsfehler oder Angriffsversuche hin.

---

Unsicher beim Key Management? AWARE7 unterstuetzt beim Aufbau einer sicheren Schluesselinfrastruktur: von der Architektur-Beratung ueber Penetrationstests bis zur ISO-27001-Zertifizierung.

ISO 27001 Beratung anfragen | Cloud-Penetrationstest beauftragen | Sicherheitsberatung entdecken