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 führt zu den weitreichendsten Datenpannen - nicht weil Verschlüsselung gebrochen wurde, sondern weil Schlüssel falsch verwaltet wurden. Dieser Artikel erklärt die wichtigsten Cloud-KMS-Lösungen und Best Practices.

Grundkonzepte

Key-Hierarchie und Envelope-Encryption:

Schlüssel-Typen:
  CMK  (Customer Master Key):
  → Verbleibt IMMER im KMS, verlässt ihn nie!
  → Wird genutzt um DEKs zu verschlüsseln
  → Kann auf HSM (Hardware Security Module) gesichert sein

  DEK  (Data Encryption Key):
  → Verschlüsselt die eigentlichen Daten (symmetrisch, AES-256)
  → Wird selbst mit CMK verschlüsselt (Envelope Encryption!)
  → Plaintext DEK: nur kurz im Speicher, dann verworfen
  → Encrypted DEK: neben den Daten gespeichert (ciphertext-DEK)

Envelope Encryption (AWS-Prinzip):
  1. DEK generieren (zufällig, 256-bit)
  2. Daten mit DEK verschlüsseln: Encrypted_Data = AES256(Data, DEK)
  3. DEK mit CMK verschlüsseln: Encrypted_DEK = KMS.Encrypt(DEK, CMK)
  4. Speichern: Encrypted_Data + Encrypted_DEK (zusammen!)
  5. DEK (plaintext) aus Speicher löschen!

  Entschlüsseln:
  1. Encrypted_DEK → KMS.Decrypt → DEK (plaintext)
  2. DEK → AES256_Decrypt(Encrypted_Data) → Daten
  3. DEK wieder verwerfen

Vorteil:
  → CMK verlässt KMS nie → sicher im HSM
  → KMS-Calls: nur für DEK-Ver/Entschlüsselung (günstig!)
  → Bulk-Data direkt verschlüsselt (kein KMS-Overhead per Byte)

AWS KMS

AWS Key Management Service:

Key-Typen:
  AWS-Managed Key:     automatisch von AWS erstellt/rotiert
                       (z.B. aws/s3, aws/ebs, aws/rds)
  Customer-Managed Key (CMK): vom Kunden erstellt und kontrolliert
  AWS-Owned Key:       AWS intern, für Kunden unsichtbar

CMK erstellen:
  # AWS CLI:
  aws kms create-key \
    --description "Produktion-Datenbankschlüssel" \
    --key-usage ENCRYPT_DECRYPT \
    --key-spec SYMMETRIC_DEFAULT  # AES-256-GCM

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

  # Mit HSM-Backup (FIPS 140-2 Level 3):
  aws kms create-key --origin AWS_CLOUDHSM \
    # Benötigt: CloudHSM-Cluster als Custom Key Store

Key-Policy (Zugriffskontrolle):
  # JSON Key Policy:
  {
    "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": "*"
      }
    ]
  }

  # WICHTIG: Root-Account IMMER in Key-Policy (Kontozugang sichern!)

Automatische Key-Rotation:
  # 365-Tage-Rotation aktivieren:
  aws kms enable-key-rotation --key-id alias/prod-db-key
  # → AWS rotiert automatisch jährlich
  # → Alte Schlüsselversionen für Entschlüsselung behalten!

BYOK (Bring Your Own Key):
  # Eigenen Schlüssel in AWS KMS importieren:
  # 1. Wrapping-Key von AWS anfordern:
  aws kms get-parameters-for-import \
    --key-id <KEY-ID> \
    --wrapping-algorithm RSAES_OAEP_SHA_256 \
    --wrapping-key-spec RSA_2048

  # 2. Eigenen Key-Material mit Wrapping-Key verschlüsseln
  # 3. Importieren:
  aws kms import-key-material \
    --key-id <KEY-ID> \
    --encrypted-key-material fileb://encrypted_key.bin \
    --import-token fileb://import_token.bin \
    --expiration-model KEY_MATERIAL_EXPIRES \
    --valid-to 2027-12-31T23:59:59Z

S3 serverseitige Verschlüsselung mit CMK:
  # Bucket-Richtlinie: SSE-KMS 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 - Keys, Secrets, Certificates:

Objekt-Typen:
  Keys:         Kryptografische Schlüssel (RSA, EC, AES via Premium)
  Secrets:      Passwörter, API-Keys, Connection Strings
  Certificates: TLS/SSL-Zertifikate inkl. automatischer Erneuerung

Tiers:
  Standard: Software-Keys (HSM-optional für Secrets)
  Premium:  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"  # HSM-Keys

    soft_delete_retention_days = 90
    purge_protection_enabled   = true  # KRITISCH: verhindert Datenverlust!

    network_acls {
      bypass         = "AzureServices"
      default_action = "Deny"  # Nur explizit erlaubte IPs!
      ip_rules       = ["10.0.0.0/8"]
    }
  }

  # Access Policy für App:
  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 aus Key Vault in Anwendung (Python):
  from azure.identity import ManagedIdentityCredential
  from azure.keyvault.secrets import SecretClient

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

  # Secret abrufen (keine hartcodierten Credentials!):
  db_password = client.get_secret("database-password").value
  api_key = client.get_secret("external-api-key").value

Zertifikat-Automatisierung (Let's Encrypt / DigiCert):
  # Key Vault erstellt, erneuert und deployt TLS-Zertifikate automatisch:
  resource "azurerm_key_vault_certificate" "app_cert" {
    name         = "app-tls-cert"
    key_vault_id = azurerm_key_vault.prod.id

    certificate_policy {
      issuer_parameters { name = "DigiCert" }
      key_properties {
        exportable = false  # Private Key verbleibt in Key Vault!
        key_type   = "RSA"
        key_size   = 4096
        reuse_key  = false
      }
      secret_properties { content_type = "application/x-pkcs12" }
      x509_certificate_properties {
        subject            = "CN=app.example.com"
        validity_in_months = 12
        key_usage = ["cRLSign", "dataEncipherment", "digitalSignature", "keyEncipherment"]
      }
      lifetime_action {
        action { action_type = "AutoRenew" }
        trigger { days_before_expiry = 30 }
      }
    }
  }

HashiCorp Vault

HashiCorp Vault - Platform-agnostisch:

Warum Vault:
  → Cloud-agnostisch: On-Premises + AWS + Azure + GCP
  → Dynamic Secrets: Credentials on-demand generieren (kein statisches Passwort!)
  → Lease-System: Credentials verfallen automatisch
  → Secret Zero Problem gelöst: AppRole, K8s Auth, AWS IAM Auth

Vault-Server starten (Dev/Test):
  vault server -dev -dev-root-token-id="root"
  export VAULT_ADDR='http://127.0.0.1:8200'
  export VAULT_TOKEN='root'

Key-Value Store (Static Secrets):
  # Secret schreiben:
  vault kv put secret/myapp \
    db-password="s3cur3P@ss" \
    api-key="abc123xyz"

  # Secret lesen:
  vault kv get secret/myapp
  vault kv get -field=db-password secret/myapp

Dynamic Secrets (Datenbank):
  # 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 temporären DB-User:
  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 (gültig für 1 Stunde!):
  vault read database/creds/app-role
  # Key         Value
  # username    v-app-role-xyz123
  # password    randomGeneratedPassword!
  # lease_id    database/creds/app-role/abc...
  # lease_duration  1h0m0s

  # Nach 1h: Credentials ungültig! Angreifer mit gestohlenem Credential: wertlos.

Transit Encryption (Encryption-as-a-Service):
  # Vault als Verschlüsselungsdienst:
  vault secrets enable transit
  vault write transit/keys/myapp-key type=aes256-gcm96

  # Daten verschlüsseln:
  vault write transit/encrypt/myapp-key \
    plaintext=$(echo "sensitiver Text" | base64)

  # Antwort:
  # ciphertext: vault:v1:...encrypted...

  # Entschlüsseln:
  vault write transit/decrypt/myapp-key \
    ciphertext="vault:v1:...encrypted..."
  # plaintext: aGVsbG8=  (base64-dekodieren für Klartext)

Kubernetes-Integration:
  # App in K8s authentifiziert sich ohne statischen Token:
  vault auth enable kubernetes

  vault write auth/kubernetes/config \
    token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
    kubernetes_host="https://kubernetes.default.svc:443" \
    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

  vault write auth/kubernetes/role/myapp \
    bound_service_account_names=myapp-sa \
    bound_service_account_namespaces=production \
    policies=myapp-policy \
    ttl=1h

Key-Management Best Practices

Übergreifende KMS-Best-Practices:

Key-Rotation:
  □ Automatische Rotation: mindestens jährlich (AWS: enable-key-rotation)
  □ On-Demand-Rotation: nach Verdacht auf Kompromittierung
  □ Rotation ≠ Neuverschlüsselung aller Daten (DEK re-encryption nötig!)
  □ Altes Key-Material: behalten für Entschlüsselung historischer Daten

Least Privilege für Keys:
  → Entwicklung: keine Produktions-Keys
  → Read-Only-Keys: nur für Entschlüsselung, kein Key-Management
  → Audit-Rolle: nur Describe/List, kein Encrypt/Decrypt
  → Break-Glass: separater Admin-Key für Notfälle (MFA-geschützt)

BYOK/HYOK Entscheidung:
  BYOK (Bring Your Own Key):
  → Eigenes Key-Material in Cloud-KMS importieren
  → Mehr Kontrolle, aber: Cloud-Provider hat HSM-Zugang
  → Für: regulatorische Compliance, Auditierbarkeit

  HYOK (Hold Your Own Key) / Double Encryption:
  → Schlüssel verbleibt ON-PREMISES (HSM im eigenen RZ)
  → Cloud-Provider kann Daten NIEMALS entschlüsseln
  → Für: sehr hohe Anforderungen (Behörden, Staatsgeheimnisse)
  → Nachteile: Latenz, eigener HSM-Betrieb, kein Cloud-Auto-Scaling für Verschlüsselung

Compliance-Anforderungen:
  FIPS 140-2 Level 1-4:
  → Level 2: physischer Schutz (AWS KMS Standard, Azure Key Vault Premium)
  → Level 3: Tamper-Evidence, kritische Sicherheitsparameter (AWS CloudHSM)
  → Level 4: vollständige Tamper-Response (selten, für Regierungsbehörden)

  BSI TR-02102 (Deutschland):
  → RSA: ≥ 3000-Bit (bis 2030), empfohlen 4096-Bit
  → EC: ≥ 250-Bit, empfohlen P-256/P-384 (NIST) oder Brainpool P-256r1
  → AES: 256-Bit im GCM-Modus
  → PBKDF2, bcrypt, Argon2 für Passwort-Hashing

Monitoring und Alerting:
  → AWS CloudTrail: alle KMS-API-Calls loggen
  → Azure Monitor: Key Vault Diagnostic Logs
  → Alert: unerwartete Entschlüsselungsanfragen
  → Alert: Key-Management-Operationen außerhalb der Geschäftszeiten
  → Alert: Deny-Responses auf Key-Zugriff (Konfigurationsfehler oder Angriff?)