AWS KMS verstehen: AWS Managed Key vs. Customer Managed Key (CMK) für S3-Verschlüsselung

Du richtest einen neuen S3-Bucket ein, aktivierst die Verschlüsselung — und stehst vor der Frage: AWS Managed Key oder Customer Managed Key? Die Entscheidung klingt trivial, hat aber direkte Auswirkungen auf Kosten, Compliance-Anforderungen und die Fähigkeit, im Ernstfall Schlüssel zu rotieren oder zu widerrufen. Wer hier ohne Verständnis des zugrundeliegenden Mechanismus wählt, merkt die Konsequenzen oft erst beim nächsten Audit.

TL;DR: AWS KMS Schlüsseltypen auf einen Blick

Merkmal AWS Managed Key Customer Managed Key (CMK)
Erstellt von AWS automatisch Du (manuell oder per IaC)
Schlüsselrotation Automatisch, jährlich (nicht deaktivierbar) Optional, konfigurierbar (jährlich aktivierbar)
Schlüsselrichtlinie (Key Policy) Nicht anpassbar Vollständig anpassbar
Cross-Account-Zugriff Nicht möglich Möglich über Key Policy
Kosten Keine monatliche Gebühr; API-Aufrufe werden berechnet Monatliche Schlüsselgebühr + API-Aufrufe
Audit via CloudTrail Ja Ja, mit mehr Granularität
Schlüssel deaktivieren/löschen Nicht möglich Möglich (mit Wartezeit beim Löschen)

Wie AWS KMS funktioniert — Grundlagen vor dem ersten Schritt

AWS KMS ist kein Verschlüsselungsdienst im klassischen Sinne — er speichert und verwaltet kryptografische Schlüssel und führt kryptografische Operationen in Hardware Security Modules (HSMs) durch. Der eigentliche Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) wird von KMS generiert, aber niemals im Klartext außerhalb des HSM gespeichert.

Bei S3-seitige Verschlüsselung (SSE-KMS) läuft der Prozess so ab: S3 fordert bei jedem Schreibvorgang einen DEK von KMS an. KMS liefert den DEK im Klartext (für S3 intern) sowie eine verschlüsselte Kopie des DEK. S3 verschlüsselt das Objekt mit dem Klartext-DEK, speichert die verschlüsselte DEK-Kopie als Metadatum des Objekts und verwirft den Klartext-DEK sofort. Beim Lesezugriff ruft S3 KMS auf, um die verschlüsselte DEK-Kopie zu entschlüsseln — erst dann kann S3 das Objekt entschlüsseln und ausliefern.

Das bedeutet: Jeder S3-Lesezugriff auf ein SSE-KMS-verschlüsseltes Objekt erzeugt einen KMS-API-Aufruf. Bei hohem Durchsatz summiert sich das.

sequenceDiagram participant Client participant S3 participant KMS Client->>S3: PUT Objekt S3->>KMS: GenerateDataKey (KMS Key ID) KMS-->>S3: Klartext-DEK + verschlüsselter DEK S3->>S3: Objekt mit Klartext-DEK verschlüsseln S3->>S3: Verschlüsselten DEK als Metadatum speichern S3-->>Client: 200 OK Client->>S3: GET Objekt S3->>KMS: Decrypt (verschlüsselter DEK) KMS-->>S3: Klartext-DEK S3->>S3: Objekt entschlüsseln S3-->>Client: Entschlüsseltes Objekt
  1. PUT-Anfrage: S3 empfängt das Objekt und fordert einen DEK von KMS an.
  2. GenerateDataKey: KMS generiert einen DEK, gibt Klartext-DEK und verschlüsselten DEK zurück.
  3. Verschlüsselung: S3 verschlüsselt das Objekt mit dem Klartext-DEK und speichert die verschlüsselte DEK-Kopie als Objektmetadatum.
  4. GET-Anfrage: S3 liest das Objekt und sendet die verschlüsselte DEK-Kopie an KMS zur Entschlüsselung (Decrypt-Aufruf).
  5. Entschlüsselung: KMS entschlüsselt den DEK; S3 entschlüsselt das Objekt und liefert es aus.

AWS Managed Keys: Wann sie ausreichen

AWS Managed Keys werden automatisch erstellt, wenn ein AWS-Dienst zum ersten Mal KMS-Verschlüsselung für dein Konto in einer Region aktiviert. Für S3 heißt der Schlüssel-Alias aws/s3. Du siehst ihn in der KMS-Konsole, kannst ihn aber weder bearbeiten noch löschen.

Der entscheidende Vorteil: null Verwaltungsaufwand. AWS rotiert den Schlüssel automatisch jährlich, du brauchst keine Key Policy zu pflegen, und die Kosten beschränken sich auf die API-Aufrufe. Für interne Workloads ohne Cross-Account-Anforderungen und ohne regulatorische Vorgaben zur Schlüsselkontrolle ist das oft die pragmatische Wahl.

Die harte Grenze: Du kannst einem anderen AWS-Konto keinen Zugriff auf einen AWS Managed Key gewähren. Cross-Account-Zugriff auf verschlüsselte S3-Objekte ist damit strukturell nicht möglich — nicht konfigurierbar, nicht umgehbar.

# AWS Managed Key für S3 in der aktuellen Region anzeigen
aws kms describe-key \
  --key-id alias/aws/s3 \
  --region us-east-1

Customer Managed Keys (CMK): Wann du die Kontrolle brauchst

Ein CMK gibt dir vollständige Kontrolle über die Key Policy, Rotation, Zugriffsprotokolle und den Lebenszyklus des Schlüssels. Das ist keine Komfortfunktion — es ist eine Compliance-Anforderung in vielen regulierten Umgebungen.

Konkrete Szenarien, in denen ein CMK notwendig ist:

  • Cross-Account-Zugriff: Ein anderes AWS-Konto muss auf verschlüsselte S3-Objekte zugreifen.
  • Schlüsselwiderruf: Du musst im Notfall den Zugriff auf alle verschlüsselten Daten sofort unterbinden können (Schlüssel deaktivieren).
  • Granulare Zugriffskontrolle: Nur bestimmte IAM-Rollen oder AWS-Dienste dürfen kryptografische Operationen mit diesem Schlüssel durchführen.
  • Regulatorische Anforderungen: Nachweisbare Schlüsselverwaltung und Audit-Trail mit vollständiger Granularität.

CMK erstellen und für S3 konfigurieren

# Symmetrischen CMK erstellen
aws kms create-key \
  --description 'CMK fuer S3-Bucket Produktionsdaten' \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS \
  --region us-east-1
# Alias für den CMK setzen (KEY_ID aus vorherigem Befehl ersetzen)
aws kms create-alias \
  --alias-name alias/s3-produktion \
  --target-key-id <KEY_ID> \
  --region us-east-1
# S3-Bucket mit CMK-Verschlüsselung (SSE-KMS) konfigurieren
aws s3api put-bucket-encryption \
  --bucket mein-produktions-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/"
      },
      "BucketKeyEnabled": true
    }]
  }'

Der Parameter BucketKeyEnabled: true ist hier nicht optional — dazu gleich mehr im Abschnitt zu Kosten.

Key Policy: Minimale Konfiguration mit Least Privilege

🔽 Key Policy Beispiel anzeigen 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Schluessel-Administration",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/KeyAdminRole"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3-Dienst-Nutzung",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/S3AppRole"
      },
      "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
      ],
      "Resource": "*"
    }
  ]
}

Wichtig: Ohne einen expliziten Statement, der dem Root-Account oder einem Administrator-Principal Zugriff gewährt, kannst du dich aus deinem eigenen Schlüssel aussperren. AWS dokumentiert dieses Verhalten explizit — eine Key Policy ohne Root-Zugriff ist ein bekanntes Operational-Risiko.

AWS KMS Kosten verstehen — und warum S3 Bucket Keys entscheidend sind

Preise und Limits ändern sich — prüfe immer die offizielle AWS KMS Preisseite für aktuelle Werte. Das grundlegende Kostenmodell ist jedoch stabil:

  • AWS Managed Keys: Keine monatliche Schlüsselgebühr. API-Aufrufe werden ab einem bestimmten Freivolumen berechnet.
  • Customer Managed Keys: Monatliche Gebühr pro Schlüssel (anteilig berechnet). API-Aufrufe werden ab einem bestimmten Freivolumen berechnet.

Das S3 Bucket Key Feature — der wichtigste Kostenhebel

Ohne S3 Bucket Keys erzeugt jeder einzelne S3-GET- und PUT-Vorgang einen separaten KMS-API-Aufruf. Bei einem Bucket mit hohem Lesedurchsatz kann das die KMS-Kosten schnell in unerwartete Höhen treiben.

S3 Bucket Keys lösen dieses Problem: S3 generiert einen kurzlebigen Bucket-Level-DEK direkt aus dem KMS-Schlüssel und verwendet diesen für eine Gruppe von Objektverschlüsselungen — ohne für jedes Objekt einzeln KMS aufzurufen. AWS dokumentiert, dass S3 Bucket Keys die KMS-Anfragen für SSE-KMS deutlich reduzieren können.

graph TD subgraph OhneBucketKey["Ohne S3 Bucket Key"] A1["GET Objekt 1"] --> K1["KMS Decrypt #1"] A2["GET Objekt 2"] --> K2["KMS Decrypt #2"] A3["GET Objekt 3"] --> K3["KMS Decrypt #3"] end subgraph MitBucketKey["Mit S3 Bucket Key"] B1["GET Objekt 1"] --> BK["Bucket-Level DEK
(im S3-Speicher"] B2["GET Objekt 2"] --> BK B3["GET Objekt 3"] --> BK BK --> K4["KMS Decrypt
(einmalig)"] end
  1. Ohne Bucket Key: Jeder S3-Objektzugriff (GET/PUT) löst einen separaten KMS-API-Aufruf aus — lineare Kostenskalierung mit dem Datendurchsatz.
  2. Mit Bucket Key: S3 hält einen kurzlebigen Bucket-Level-Schlüssel im Speicher. Mehrere Objektoperationen teilen sich einen KMS-Aufruf — deutlich reduzierte API-Aufruffrequenz.

Bucket Keys aktivieren, wenn noch nicht geschehen:

aws s3api put-bucket-encryption \
  --bucket mein-produktions-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/"
      },
      "BucketKeyEnabled": true
    }]
  }'
# Aktuellen Verschlüsselungsstatus des Buckets prüfen
aws s3api get-bucket-encryption \
  --bucket mein-produktions-bucket

Erfahrung aus der Praxis: Der Cross-Account-Fallstrick

Symptom: Ein Daten-Pipeline-Team meldet, dass ihre Lambda-Funktion in Konto B keine Objekte aus einem S3-Bucket in Konto A lesen kann — obwohl die Bucket Policy den Zugriff explizit erlaubt und die IAM-Rolle in Konto B die korrekten S3-Berechtigungen hat.

Erste Diagnose: Das Team prüft die Bucket Policy, die IAM-Rolle, die VPC-Endpunkte. Alles sieht korrekt aus. Der Fehler lautet AccessDenied — wenig hilfreich.

Tatsächliche Ursache: Der Bucket in Konto A verwendet SSE-KMS mit einem AWS Managed Key (aws/s3). AWS Managed Keys erlauben keinen Cross-Account-Zugriff — die Key Policy ist nicht anpassbar. Die Lambda-Funktion in Konto B kann den DEK nicht entschlüsseln lassen, weil KMS den Aufruf von einem fremden Konto-Principal ablehnt.

Fix: Den Bucket auf einen CMK in Konto A umstellen, die Key Policy des CMK um einen Statement für die IAM-Rolle in Konto B erweitern, und sicherstellen, dass die IAM-Rolle in Konto B kms:Decrypt auf den CMK-ARN in Konto A hat.

# CloudTrail-Logs auf KMS-Fehler prüfen (letzten 1 Stunde)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --region us-east-1 \
  --query 'Events[?contains(CloudTrailEvent, `AccessDenied`)].{Zeit:EventTime,Nutzer:Username,Event:CloudTrailEvent}' \
  --output table

CloudTrail ist die einzige zuverlässige Diagnoseschicht für KMS-Zugriffsfehler — der S3-Fehler selbst verrät nicht, ob das Problem auf S3- oder KMS-Ebene liegt.

IAM-Berechtigungen für KMS-Operationen

Damit eine IAM-Rolle SSE-KMS-verschlüsselte S3-Objekte lesen und schreiben kann, braucht sie sowohl S3- als auch KMS-Berechtigungen. Fehlende KMS-Berechtigungen führen zu AccessDenied-Fehlern, die auf den ersten Blick wie S3-Berechtigungsfehler aussehen.

🔽 IAM-Policy für S3 SSE-KMS Zugriff anzeigen 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3Zugriff",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::mein-produktions-bucket/*"
    },
    {
      "Sid": "KMSZugriff",
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/"
    }
  ]
}

Schlüsselrotation für CMKs aktivieren und prüfen

AWS Managed Keys rotieren automatisch. Bei CMKs musst du die Rotation explizit aktivieren — sie ist standardmäßig deaktiviert.

# Automatische jährliche Rotation für einen CMK aktivieren
aws kms enable-key-rotation \
  --key-id arn:aws:kms:us-east-1:123456789012:key/<KEY_ID> \
  --region us-east-1
# Rotationsstatus prüfen
aws kms get-key-rotation-status \
  --key-id arn:aws:kms:us-east-1:123456789012:key/<KEY_ID> \
  --region us-east-1

Nach der Rotation bleibt das alte Schlüsselmaterial erhalten — bestehende Objekte können weiterhin entschlüsselt werden. Neue Verschlüsselungsoperationen verwenden das neue Schlüsselmaterial. Das ist kein stiller Override, sondern dokumentiertes KMS-Verhalten.

Entscheidungshilfe: Welcher Schlüsseltyp passt zu deinem Anwendungsfall?

graph TD Start(["S3 Bucket verschlüsseln"]) Start --> Q1{"Cross-Account-Zugriff nötig?"} Q1 -->|Ja| CMK1["Customer Managed Key"] Q1 -->|Nein| Q2{"Schlüssel deaktivieren
oder widerrufen nötig?"} Q2 -->|Ja| CMK2["Customer Managed Key"] Q2 -->|Nein| Q3{"Granulare Key Policy
oder Compliance-Nachweis?"} Q3 -->|Ja| CMK3["Customer Managed Key"] Q3 -->|Nein| AMK["AWS Managed Key
(aws/s3)"] CMK1 --> Ende(["CMK erstellen + Bucket Key aktivieren"]) CMK2 --> Ende CMK3 --> Ende AMK --> Ende2(["SSE-KMS aktivieren + Bucket Key aktivieren"])

AWS KMS für S3 — Zusammenfassung und nächste Schritte

Die Wahl zwischen AWS Managed Key und Customer Managed Key für S3-Verschlüsselung ist keine reine Kostenfrage. AWS Managed Keys sind ausreichend für interne Single-Account-Workloads ohne regulatorische Schlüsselkontrollanforderungen. Customer Managed Keys sind notwendig, sobald Cross-Account-Zugriff, Schlüsselwiderruf, granulare Zugriffssteuerung oder Compliance-Nachweise gefordert sind.

Unabhängig vom Schlüsseltyp: S3 Bucket Keys aktivieren, um KMS-API-Kosten bei hohem Durchsatz zu kontrollieren. CloudTrail für KMS-Ereignisse auswerten, wenn AccessDenied-Fehler auftreten — der S3-Fehler allein reicht für die Diagnose nicht aus.

Weiterführende Ressourcen:

Glossar: Schlüsselbegriffe

Begriff Erklärung
AWS Managed Key Von AWS automatisch erstellter und verwalteter KMS-Schlüssel für einen bestimmten Dienst; Key Policy nicht anpassbar.
Customer Managed Key (CMK) Vom Nutzer erstellter KMS-Schlüssel mit vollständig konfigurierbarer Key Policy und Lebenszyklus.
Data Encryption Key (DEK) Kurzlebiger symmetrischer Schlüssel, der von KMS generiert wird und die eigentlichen Daten verschlüsselt.
SSE-KMS Server-seitige S3-Verschlüsselung mit AWS KMS-verwalteten Schlüsseln.
S3 Bucket Key Feature, das KMS-API-Aufrufe pro Objekt reduziert, indem S3 einen kurzlebigen Bucket-Level-DEK zwischenspeichert.

Related Posts

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

EC2 ohne Internetzugang im eigenen VPC – Internet Gateway und Route Table korrekt einrichten

Du hast ein eigenes VPC erstellt, eine EC2-Instanz in einem öffentlichen Subnetz gestartet – und ping google.com läuft ins Leere. Kein Timeout-Fehler, keine Fehlermeldung, einfach nichts. Dieses Problem tritt fast immer auf, wenn ein Custom VPC ohne Internet Gateway oder mit einer unvollständigen Route-Table-Konfiguration aufgesetzt wird, weil AWS bei eigenen VPCs bewusst keine Standard-Internetverbindung mitliefert. TL;DR – EC2 Internetzugang im Custom VPC Schritt Aktion Warum notwendig 1 Internet Gateway erstellen und an VPC anhängen Ohne IGW gibt es keinen Pfad ins öffentliche Internet 2 Route Table aktualisieren (0.0.0.0/0 → IGW) Der Traffic muss explizit über das IGW geroutet werden 3 Subnetz mit Route Table verknüpfen Eine Route Table ohne Subnetz-Assoziation hat keine Wirkung 4 Öffentliche IP oder Elastic IP prüfen Ohne öffentliche IP kann das IGW keinen eingehenden Rückpfad aufbauen 5 Securi...
Mehr anzeigen

LSI vs. GSI in DynamoDB: Den richtigen Sekundärindex wählen

Man hat eine DynamoDB-Tabelle aufgebaut, die Abfragen über den Primärschlüssel laufen schnell — und dann kommt die Anforderung, dieselben Daten nach einem anderen Attribut zu filtern. Genau hier beginnt die Entscheidung zwischen einem Local Secondary Index (LSI) und einem Global Secondary Index (GSI) , und wer sie falsch trifft, zahlt entweder mit Flexibilitätsverlust oder mit unerwartetem Durchsatz-Overhead. TL;DR: LSI vs. GSI auf einen Blick Merkmal LSI GSI Erstellungszeitpunkt Nur bei Tabellenerstellung Jederzeit Partition Key Identisch mit Basistabelle Beliebiges Attribut Sort Key Anderes Attribut als Basistabelle Beliebiges Attribut (optional) Konsistenzmodell Strongly consistent möglich Nur eventually consistent Kapazität Teilt RCU/WCU mit Basistabelle Eigene RCU/WCU (Provisioned) oder On-Demand Datenmenge pro Partition Key Max. 10 GB Unbegrenzt Max. Anzahl pro Tabelle 5 20 (Standard...
Mehr anzeigen

ElastiCache Redis einsetzen: Wann ein Caching-Layer deine RDS-Datenbank entlastet

Du hast die Abfragen optimiert, Indizes gesetzt, Read Replicas hinzugefügt — und der RDS-Endpunkt ist immer noch der Engpass. Das passiert fast immer dann, wenn dieselben Zeilen hunderte Male pro Sekunde gelesen werden und jede Anfrage trotzdem den vollen Datenbankpfad durchläuft. Ein ElastiCache Redis-Layer löst genau dieses Problem, indem er häufig gelesene Ergebnisse im Arbeitsspeicher hält und RDS damit aus der kritischen Anfragekette herausnimmt. TL;DR: ElastiCache Redis als Caching-Layer vor RDS Aspekt Ohne Cache Mit ElastiCache Redis Lesepfad App → RDS (Disk/Buffer Pool) App → Redis (RAM) → RDS nur bei Cache Miss Latenz (typisch) Einige Millisekunden bis Dutzende ms Unter 1 ms bei Cache Hit RDS-Last bei hohem Traffic Linear steigend Deutlich reduziert bei hoher Hit-Rate Datenkonsistenz Immer aktuell Abhängig von TTL und Invalidierungsstrategie Operativer Aufwand Gering Mittel (Cache-Strategie,...
Mehr anzeigen