AWS S3 – Client- und Serverseitige Verschlüsselung

AWS S3 bietet Ihnen mit client- und serverseitiger Verschlüsselung fünf verschiedene Möglichkeiten, Daten in Amazon Simple Storage Service zu schützen. Jede Methode unterscheidet sich hinsichtlich Schlüsselverwaltung, Betriebskomplexität, Prüftiefe und Kosten. Die richtige Wahl hängt davon ab, wen Sie aussperren möchten: nur externe Angreifer oder auch AWS selbst. Dieser Leitfaden beschreibt alle S3-Verschlüsselungsoptionen, ihre jeweiligen Anwendungsfälle, die Durchsetzung mithilfe von Bucket-Richtlinien, die in CloudTrail angezeigten Informationen und die Entscheidung zwischen nativer Schlüsselverwaltung, BYOK und HYOK.

Kurzantwort: Welche AWS S3-Verschlüsselungsoption sollten Sie verwenden?

Für die meisten Workloads: Verwenden Sie SSE-KMS mit einem vom Kunden verwalteten KMS-Schlüssel. Sie erhalten AES-256-Verschlüsselung ruhender Daten, ein vollständiges CloudTrail-Audit-Protokoll aller Verschlüsselungs- und Entschlüsselungsvorgänge, die mit einer IAM-Identität verknüpft sind, die Möglichkeit, Schlüssel unabhängig zu deaktivieren, und eine automatische jährliche Schlüsselrotation. Für höchste Schlüsselsouveränität (AWS darf Ihren Schlüssel niemals speichern): Verwenden Sie clientseitige Verschlüsselung mit Ihrem eigenen Hauptschlüssel. Für die einfachste Einrichtung ohne Schlüsselverwaltungsaufwand und ohne Audit-Trail-Anforderung: SSE-S3 (seit Januar 2023 der S3-Standard). Um Ihren eigenen Schlüssel pro Anfrage ohne KMS bereitzustellen: SSE-C.

Wichtige Erkenntnisse

• S3 verschlüsselt seit Januar 2023 standardmäßig: Alle neuen Objekte in einem S3-Bucket werden automatisch mit SSE-S3 (AES-256) verschlüsselt, auch ohne explizite Konfiguration. Bereits vorhandene Objekte werden nicht nachträglich verschlüsselt.
• Es gibt fünf Verschlüsselungsoptionen, die sich in zwei Kategorien unterteilen: Serverseitig (SSE-S3, SSE-KMS, SSE-C) bedeutet, dass S3 die Verschlüsselung nach dem Empfang der Daten durchführt. Clientseitig bedeutet, dass die Verschlüsselung vor dem Hochladen erfolgt, sodass S3 niemals Klartextdaten erhält.
• SSE-KMS ist die empfohlene Standardeinstellung für regulierte Arbeitslasten: Es bietet einen Audit-Trail für jeden einzelnen Vorgang in CloudTrail, unterstützt vom Kunden verwaltete Schlüssel mit BYOK und ermöglicht es Ihnen, einen Schlüssel zu deaktivieren oder zu löschen, um die Entschlüsselung sofort zu verhindern, ohne Objekte zu löschen.
• BYOK und HYOK erfüllen unterschiedliche Souveränitätsanforderungen: BYOK (Import Ihres eigenen Schlüsselmaterials in AWS KMS) speichert den Schlüssel während der Nutzung in AWS und gewährleistet dessen Herkunft. HYOK (clientseitige Verschlüsselung mit Ihrem eigenen Hauptschlüssel) bedeutet, dass AWS den Schlüssel zu keinem Zeitpunkt berührt.
• Für die Verschlüsselung während der Übertragung ist eine separate Bucket-Richtlinie erforderlich: Die Standardverschlüsselung von S3 schützt nur ruhende Daten. Um TLS für alle Anfragen zu erzwingen, setzen Sie `aws:SecureTransport=false` in Ihrer Bucket-Richtlinie.

Was ist AWS S3-Verschlüsselung und warum ist sie wichtig?

Amazon S3 (Simple Storage Service) ist der Objektspeicherdienst von AWS. Er speichert Daten als Objekte in Containern, sogenannten Buckets. Jedes Objekt kann bis zu 5 TB groß sein. S3 wird häufig für Backups, Data Lakes, Anwendungsressourcen, Protokollarchive und regulierte Datensätze eingesetzt, darunter Workloads aus dem Gesundheitswesen (HIPAA), dem Finanzsektor (PCI DSS) und dem öffentlichen Sektor (FedRAMP).

Die Verschlüsselung in S3 schützt vor zwei unterschiedlichen Bedrohungsmodellen. Die Verschlüsselung ruhender Daten schützt auf der Festplatte gespeicherte Objekte vor dem Auslesen bei unbefugtem Zugriff auf das Speichermedium. Die Verschlüsselung während der Übertragung schützt Objekte während der Datenübertragung zwischen Clients und dem S3-Dienst. Beide Verschlüsselungsarten sind für die meisten Compliance-Frameworks erforderlich und erfordern separate Konfigurationen in S3.

S3 verwendet AES-256 mit Galois-Zähler-Modus (AES-256-GCM) für alle symmetrischen Verschlüsselungsoperationen. GCM bietet authentifizierte Verschlüsselung: Jedem verschlüsselten Objekt wird ein eindeutiges Authentifizierungs-Tag hinzugefügt, das sowohl die Unversehrtheit der Daten als auch die Verwendung des korrekten Schlüssels zur Entschlüsselung bestätigt. Dies schützt sowohl vor passivem Abhören als auch vor aktiver Manipulation des gespeicherten Chiffretextes.

Verschlüsselung während der Übertragung: Erzwingen von TLS für alle S3-Anfragen

S3 unterstützt HTTPS (TLS) für alle API-Anfragen. TLS verschlüsselt die Verbindung zwischen Client und S3-Endpunkt und schützt so Objektdaten und Metadaten der Anfrage während der Übertragung. S3 erzwingt HTTPS jedoch nicht standardmäßig; ein S3-Bucket ohne entsprechende Richtlinie akzeptiert sowohl HTTP- als auch HTTPS-Anfragen.

Um TLS für alle Anfragen an einen Bucket zu erzwingen, wenden Sie eine Bucket-Richtlinie an, die jede Anfrage ablehnt, bei der die aws:SecureTransport Der Bedingungsschlüssel ist falsch. Die folgende Richtlinie lehnt alle GetObject-Anfragen ab, die kein HTTPS verwenden:

{
  "Id": "EnforceSSLOnly",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonSSLRequests",
      "Action": "s3:*",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      },
      "Principal": "*"
    }
  ]
}

Wenden Sie diese Richtlinie auf jeden S3-Bucket an, der sensible Daten enthält. Beachten Sie, dass die Resource Der Block muss sowohl den Bucket-ARN als auch den Objekt-ARN abdecken (mit /*) um sowohl Bucket-Level- als auch Objekt-Level-API-Aufrufe über HTTP zu verweigern.

Serverseitige Verschlüsselung (SSE): Drei Optionen erklärt

Serverseitige Verschlüsselung bedeutet, dass S3 Ihre Daten über HTTPS empfängt und sie vor dem Speichern auf der Festplatte verschlüsselt. S3 speichert den verschlüsselten Text. Wenn Sie das Objekt anfordern, entschlüsselt S3 es (mit dem entsprechenden Schlüssel) und sendet es Ihnen über HTTPS zurück. Die Ver- und Entschlüsselung erfolgt innerhalb des S3-Dienstes. Ihre Anwendung muss keine kryptografischen Operationen durchführen.

SSE-S3: S3-verwaltete Schlüssel (Standard seit Januar 2023)

SSE-S3 (Serverseitige Verschlüsselung mit von Amazon S3 verwalteten Schlüsseln) ist seit Januar 2023 die Standardverschlüsselungsmethode für alle neuen S3-Objekte. AWS generiert für jedes Objekt einen eindeutigen AES-256-GCM-Datenverschlüsselungsschlüssel. Dieser Datenschlüssel wird anschließend mit einem regelmäßig geänderten Hauptschlüssel verschlüsselt, der vollständig von AWS verwaltet wird. Sie haben weder Einblick in noch Kontrolle über die Schlüssel.

SSE-S3 eignet sich für Workloads, bei denen die Verschlüsselung ruhender Daten erforderlich ist, aber keine kundenspezifische Protokollierung der Schlüsselnutzung oder unabhängige Schlüsselkontrolle benötigt wird. Es verursacht keinen zusätzlichen Betriebsaufwand und keine Kosten über den Standard-S3-Speicher hinaus. Der Nachteil: Der Zugriff auf den Verschlüsselungsschlüssel kann weder deaktiviert, rotiert noch protokolliert werden. Es wird kein CloudTrail-Protokoll über die Entschlüsselung einzelner Objekte erstellt. Die Berechtigung zur Entschlüsselung eines Objekts kann nur durch Löschen des Objekts selbst widerrufen werden.

SSE-KMS: KMS-verwaltete Schlüssel mit Audit-Trail und Kundenkontrolle

SSE-KMS nutzt den AWS Key Management Service (KMS) zur Verwaltung der Verschlüsselungsschlüssel Ihrer S3-Objekte. Beim Hochladen eines Objekts mit SSE-KMS generiert S3 mithilfe von KMS einen Datenverschlüsselungsschlüssel (DEK). KMS gibt zwei Versionen zurück: einen Klartext-DEK (zum Verschlüsseln des Objekts) und einen verschlüsselten DEK (der zusammen mit dem verschlüsselten Objekt in S3 gespeichert wird). S3 verwirft den Klartext-DEK unmittelbar nach der Verschlüsselung. Beim Herunterladen des Objekts sendet S3 den verschlüsselten DEK an KMS. KMS entschlüsselt ihn und gibt den Klartext-DEK zurück, damit S3 das Objekt entschlüsseln und an Sie senden kann.

Jeder Aufruf von GenerateDataKey und Decrypt an KMS erzeugt einen CloudTrail-Protokolleintrag, der den KMS-Schlüssel-ARN, den anfragenden IAM-Principal, den S3-Bucket- und Objektschlüssel sowie einen Zeitstempel enthält. Dadurch erhalten Sie einen vollständigen, identitätsverknüpften Prüfpfad für jedes Verschlüsselungs- und Entschlüsselungsereignis jedes durch SSE-KMS geschützten S3-Objekts.

SSE-KMS unterstützt zwei Schlüsseltypen, die sich hinsichtlich ihrer Sicherheits- und Kontrolleigenschaften deutlich unterscheiden:

AWS-verwalteter KMS-Schlüssel (aws/s3): AWS erstellt diesen Schlüssel automatisch, sobald Sie SSE-KMS für einen Bucket aktivieren, ohne einen CMK anzugeben. AWS verwaltet den Schlüssel vollständig, einschließlich der Rotation (alle drei Jahre für aws/s3-Schlüssel). Sie können den Schlüssel in KMS einsehen, aber weder seine Richtlinie ändern, ihn deaktivieren noch löschen. Sie erhalten CloudTrail-Protokollierung, haben aber keine unabhängige Kontrolle über den Schlüssel.

Kundenseitig verwalteter KMS-Schlüssel (CMK): Sie erstellen diesen Schlüssel in KMS, bevor Sie SSE-KMS aktivieren. Sie definieren die Schlüsselrichtlinie, legen fest, wer den Schlüssel für die S3-Verschlüsselung und -Entschlüsselung verwenden darf, aktivieren die automatische jährliche Rotation und können den Schlüssel jederzeit deaktivieren oder löschen. Durch die Deaktivierung des CMK wird sofort verhindert, dass S3 mit diesem Schlüssel verschlüsselte Objekte entschlüsselt, ohne diese Objekte zu löschen. Dies ist die empfohlene Option für regulierte Workloads.

SSE-C: Vom Kunden bereitgestellte Verschlüsselungsschlüssel

SSE-C (Server-Side Encryption with Customer-Provided Keys) erfordert, dass Sie für jeden PutObject- (Upload) und GetObject-Anfrageheader (Download) einen 256-Bit-AES-Verschlüsselungsschlüssel angeben. S3 verwendet Ihren Schlüssel zur AES-256-Verschlüsselung bzw. -Entschlüsselung und verwirft ihn anschließend sofort aus dem Speicher. S3 speichert lediglich einen zufällig gesalzenen HMAC-Fingerabdruck (Hash-Based Message Authentication Code) des Schlüssels, um zukünftige Anfragen zu validieren.

Die Konsequenz: Geht der Schlüssel verloren, ist der Zugriff auf alle damit verschlüsselten Objekte dauerhaft verloren. Es gibt keinen Mechanismus zur Schlüsselwiederherstellung. SSE-C muss HTTPS verwenden; S3 lehnt SSE-C-Anfragen über HTTP ab.

SSE-C eignet sich, wenn Sie S3 für Verschlüsselungsvorgänge benötigen, Ihren Schlüssel aber nicht in AWS KMS speichern können oder wollen. Sie übernehmen die volle Verantwortung für Schlüsselverwaltung, -rotation, -speicherung und -verteilung an alle Systeme, die auf die Objekte zugreifen müssen. SSE-C generiert keine KMS-CloudTrail-Ereignisse, da es KMS nicht verwendet.

Clientseitige Verschlüsselung: Verschlüsselung vor dem Upload

Clientseitige Verschlüsselung bedeutet, dass Ihre Anwendung oder Ihr Client die Daten verschlüsselt, bevor sie Ihre Umgebung verlassen. Die von S3 empfangenen und gespeicherten Daten sind bereits verschlüsselt; S3 hat niemals Zugriff auf den Klartext. Dies ist das einzige S3-Verschlüsselungsmodell, bei dem AWS unter keinen Umständen auf Ihre Daten zugreifen kann, auch nicht bei rechtlichen Anordnungen gegen AWS.

Das AWS SDK für Java (und andere Sprachen) bietet einen S3-Verschlüsselungsclient, der clientseitige Verschlüsselung implementiert. Es gibt zwei Optionen für die Schlüsselverwaltung:

Clientseitig mit AWS KMS CMK: Ihre Anwendung ruft KMS auf, um einen Klartext- und einen verschlüsselten Datenschlüssel zu generieren. Anschließend verschlüsselt sie das Objekt mit dem Klartextschlüssel, verwirft diesen und lädt den verschlüsselten Text zusammen mit dem verschlüsselten Datenschlüssel als Objektmetadaten hoch. Zum Herunterladen und Entschlüsseln ruft Ihre Anwendung den verschlüsselten Datenschlüssel aus den Objektmetadaten ab, entschlüsselt ihn mit KMS, verwendet den zurückgegebenen Klartextschlüssel zum Entschlüsseln des Objekts und verwirft diesen. AWS KMS ist am Schlüssel-Wrapping beteiligt, sodass die Schlüsseloperationen in CloudTrail protokolliert werden. AWS hat jedoch niemals Zugriff auf die Klartext-Objektdaten.

Clientseitig mit einem selbstverwalteten Hauptschlüssel: Ihre Anwendung verwendet ihren eigenen Hauptschlüssel (gespeichert in Ihrem HSM, Schlüsselverwaltungssystem oder Anwendungsschlüsselspeicher), um den Datenverschlüsselungsschlüssel zu verschlüsseln und zu entschlüsseln. AWS ist an keiner Schlüsseloperation beteiligt. Dies ist das HYOK-Modell (Hold Your Own Key): Der Verschlüsselungsschlüssel befindet sich vollständig außerhalb von AWS. Selbst wenn AWS gezwungen wäre, Zugriff auf Ihren S3-Bucket zu gewähren, ist der gespeicherte Chiffretext ohne den Hauptschlüssel, der niemals in AWS gelangt ist, nutzlos.

Native Tastensteuerung vs. BYOK vs. HYOK: Welches Modell erfüllt Ihre Anforderungen?

Die wichtigste Verschlüsselungsentscheidung für jede S3-Workload betrifft nicht den zu verwendenden AES-Modus, sondern die Schlüsselverwaltung. Die drei für S3 verfügbaren Schlüsselverwaltungsmodelle weisen sehr unterschiedliche Sicherheitseigenschaften, Betriebsanforderungen und Compliance-Implikationen auf.

Abmessungen	Nativer Schlüssel (SSE-S3 oder AWS-verwalteter KMS-Schlüssel)	BYOK (vom Kunden verwalteter KMS-Schlüssel mit importiertem Schlüsselmaterial)	HYOK (Clientseitige Verschlüsselung mit selbstverwaltetem Hauptschlüssel)
Wer generiert den Verschlüsselungsschlüssel?	AWS	Kunde (in KMS importiert)	Kunde (tritt nie auf AWS zu)
AWS-Zugriff auf Klartextschlüssel	Ja	Ja, während des aktiven KMS-Betriebs.	Nein
CloudTrail-Auditprotokoll pro Objekt	SSE-S3: Nein. AWS-verwaltetes KMS: Ja	Ja (GenerateDataKey + Decrypt-Ereignisse)	KMS-Variante: Ja (Schlüsselverpackung/-entpackung). Selbstverwaltet: Nein
Unabhängige Tastendeaktivierung/-widerruf	SSE-S3: Nein. AWS-verwaltetes KMS: Nein.	Ja (CMK sofort deaktivieren oder löschen)	Ja (Widerruf in Ihrem Schlüsselverwaltungssystem)
Automatische Schlüsseldrehung	SSE-S3: Ja (AWS-verwaltet). AWS-verwaltetes KMS: Alle 3 Jahre	Ja (jährlich für CMK) oder manuell für importiertes Material	Vollständig vom Kunden verwaltet
Operative Komplexität	Niedrig	Medium	Hoch
KMS API-Kosten pro S3-Operation	SSE-S3: Keine. AWS-verwaltetes KMS: 0.03 $/10 Aufrufe	0.03 $/10 Anrufe	KMS-Variante: 0.03 $/10 Calls. Selbstverwaltet: Keine.
Am besten geeignet,	Allgemeine Arbeitslasten; Priorität der Einfachheit	Regulierte Sektoren; HIPAA, PCI DSS, FedRAMP	Zero-Trust-Speicher; Air-Gap; klassifizierte Daten

IAM-Modell: Zugriff nach dem Prinzip der minimalen Berechtigungen für die S3-Verschlüsselung

Verschlüsselung allein verhindert keinen unberechtigten Zugriff. Eine korrekte IAM-Konfiguration legt fest, wer S3-Objekte lesen (und somit entschlüsseln) darf. Ein gut konzipiertes IAM-Modell für SSE-KMS-S3-Workloads trennt die Verwaltung der Verschlüsselungsschlüssel vom Datenzugriff mithilfe von drei Kontrollebenen.

S3-Bucket-Richtlinie: Steuert, welche IAM-Prinzipale S3-API-Aufrufe (GetObject, PutObject, ListBucket, DeleteObject) für den Bucket und seine Objekte durchführen dürfen. Für die Durchsetzung von SSE-KMS fügen Sie eine Verweigerungsbedingung hinzu, die Folgendes erfordert: s3:x-amz-server-side-encryption Kopfzeile aws:kms bei allen PutObject-Anfragen, um sicherzustellen, dass keine unverschlüsselten Objekte hochgeladen werden können.

KMS-Schlüsselrichtlinie: Steuert, für welche IAM-Prinzipale der CMK verwendet werden kann kms:GenerateDataKey (wird zum Verschlüsseln von Objekten benötigt) und kms:Decrypt (Zum Entschlüsseln von Objekten erforderlich). Der S3-Dienst ruft KMS im Namen des anfragenden IAM-Prinzipals auf; der Prinzipal benötigt sowohl S3- als auch KMS-Berechtigungen, damit der Vorgang erfolgreich ist. Trennen Sie die Rolle des Schlüsseladministrators (der Schlüsselrichtlinien verwalten, rotieren und deaktivieren kann) von der Rolle des Schlüsselbenutzers (der über S3 verschlüsseln/entschlüsseln kann).

IAM-Identitätsrichtlinie: Die IAM-Richtlinie des aufrufenden Principals muss sowohl die S3-Aktion als auch die KMS-Aktion zulassen. Für eine schreibgeschützte Rolle, die auf S3-Objekte zugreifen, aber niemals neue hochladen soll, gewähren Sie die entsprechende Berechtigung. s3:GetObject und kms:Decrypt Nur. Für eine Schreibrolle hinzufügen s3:PutObject und kms:GenerateDataKeyGewähren Sie niemals kms:CreateKey, kms:DeleteKeyden kms:DisableKey zu Anwendungsrollen.

Service Control Policies (SCPs): Befinden sich Ihre AWS-Konten in einer AWS-Organisation, bieten SCPs eine zusätzliche Schutzebene über den IAM-Richtlinien. Mithilfe einer SCP können Sie S3-PutObject-Vorgänge ohne Verschlüsselungsheader blockieren und so verhindern, dass Benutzer der Organisation versehentlich unverschlüsselte S3-Objekte speichern, unabhängig von den individuellen IAM-Konfigurationen ihrer Konten.

Schlüsselrotation für S3-Verschlüsselung

Die Schlüsselrotation für S3 SSE-KMS erfolgt über die KMS-Schlüsselrotation und nicht durch die erneute Verschlüsselung jedes S3-Objekts. Wenn die automatische jährliche Rotation für einen vom Kunden verwalteten CMK aktiviert ist, generiert KMS neues kryptografisches Material und kennzeichnet es als aktive Version. Alle neuen S3-PutObject-Operationen verwenden das neue Schlüsselmaterial. Vorhandene Objekte bleiben mit der Schlüsselmaterialversion verschlüsselt, die zum Zeitpunkt ihres Uploads aktiv war; KMS speichert alle vorherigen Versionen und verwendet die korrekte Version zum Entschlüsseln dieser älteren Objekte.

Das bedeutet, dass Sie Ihre S3-Objekte für die Schlüsselrotation nie erneut hochladen oder verschlüsseln müssen. CMK-ARN und Schlüssel-ID bleiben unverändert; die Rotation erfolgt transparent für S3 und Ihre Anwendungen. Das Rotationsereignis wird in CloudTrail unter dem entsprechenden Eintrag protokolliert. RotateKey Ereignistyp.

Bei BYOK-Schlüsseln mit importiertem Schlüsselmaterial ist die automatische Rotation über KMS nicht verfügbar. Sie müssen neues Schlüsselmaterial extern generieren, es in denselben CMK importieren, als primäres Schlüsselmaterial festlegen und den Übergangszeitraum selbst verwalten. Bei SSE-C sind Sie vollständig für die Rotation verantwortlich: Sie müssen in Ihren Anfragen neue Schlüssel angeben und bestehende Objekte neu verschlüsseln, wenn Sie den sie schützenden Schlüssel ändern möchten.

CloudTrail-Protokollierung für S3-Verschlüsselungsereignisse

CloudTrail-Protokollierung bildet das Rückgrat der Auditierung für die SSE-KMS-Verschlüsselungskonformität. Jeder KMS-API-Aufruf, der von S3 im Auftrag eines anfragenden Principals durchgeführt wird, erzeugt einen CloudTrail-Eintrag, der den KMS-Schlüssel-ARN, den IAM-Principal (Benutzer, Rolle oder Dienst), die Quell-IP-Adresse, den S3-Bucket-Namen und den Objektschlüssel sowie einen Zeitstempel enthält.

Die beiden zu überwachenden Ereignisse sind GenerateDataKey (generiert beim Hochladen eines Objekts mit SSE-KMS) und Decrypt (Wird generiert, wenn ein Objekt heruntergeladen und entschlüsselt wird). Die Benachrichtigung über diese Ereignisse ermöglicht verschiedene Sicherheitsanwendungsfälle: Erkennung unerwarteter Benutzer, die sensible Objekte entschlüsseln; Identifizierung ungewöhnlich hoher Entschlüsselungsvolumina, die auf Datenexfiltration hindeuten könnten; Überprüfung der Einhaltung von Datenzugriffsrichtlinien; und Erstellung von Beweismaterial für behördliche Prüfungen.

Konfigurieren Sie CloudTrail so, dass es neben Verwaltungsereignissen auch S3-Datenereignisse übermittelt, da Aktivitäten auf S3-Objektebene (GetObject, PutObject, DeleteObject) standardmäßig nicht in den Verwaltungsereignisprotokollen erfasst werden. Leiten Sie CloudTrail-Protokolle in einen separaten, schreibgeschützten S3-Bucket in einem dedizierten Sicherheitskonto um, um Manipulationen zu verhindern.

Kostenüberlegungen zur S3-Verschlüsselung

SSE-S3 verursacht keine zusätzlichen Kosten für S3-Speicher oder -Anfragen. SSE-KMS hingegen verursacht Kosten für KMS-API-Aufrufe: AWS KMS berechnet 0.03 US-Dollar pro 10,000 API-Aufrufe (GenerateDataKey für Uploads, Decrypt für Downloads). Bei einer Arbeitslast von 1 Million Objekten pro Monat betragen die KMS-API-Kosten ca. 6 US-Dollar pro Monat und CMK pro Region. Kundenseitig verwaltete KMS-Schlüssel kosten zusätzlich 1 US-Dollar pro Schlüssel und Monat.

Bei hohem Anfrageaufkommen (mehrere zehn Millionen S3-Operationen pro Monat) werden die Kosten der KMS-API relevant. S3 begegnet diesem Problem mit einer Bucket-basierten Schlüsselfunktion: Wenn Sie die Option „S3 Bucket Key“ für einen SSE-KMS-Bucket aktivieren, generiert S3 aus Ihrem CMK einen kurzlebigen Bucket-basierten Datenschlüssel und verwendet diesen, um lokal individuelle Objekt-DEKs zu erzeugen. Dadurch werden die KMS-API-Aufrufe um bis zu 99 % reduziert. Der Bucket-Key-Ansatz senkt die Kosten für S3-Workloads mit hohem Durchsatz erheblich, ohne die Verschlüsselungseigenschaften zu beeinträchtigen.

SSE-C verursacht keine AWS-Kosten für die Schlüsselverwaltung, jedoch tragen Sie die vollen Betriebskosten für Speicherung, Verteilung, Rotation und Schutz des Schlüssels außerhalb von AWS. Clientseitige Verschlüsselung mit einem selbstverwalteten Hauptschlüssel verursacht ebenfalls keine AWS-Schlüsselverwaltungskosten, erfordert aber eine eigene Infrastruktur für das Schlüssellebenszyklusmanagement.

Erzwingen der S3-Verschlüsselung mit Bucket-Richtlinien

Die Verschlüsselungskonfiguration eines Buckets legt das Standardverhalten für neue Objekte fest, verhindert aber nicht, dass ein Aufrufer explizit ein unverschlüsseltes Objekt hochlädt, es sei denn, Sie fügen eine Ablehnungsrichtlinie hinzu. Um sicherzustellen, dass alle Objekte verschlüsselt werden und nur die von Ihnen gewählte Methode verwendet wird, kombinieren Sie zwei Ablehnungsanweisungen in der Bucket-Richtlinie.

Um SSE-KMS mit einem bestimmten CMK zu erzwingen:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyWrongKMSKey",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/your-key-id"
        }
      }
    }
  ]
}

Die erste Anweisung untersagt alle Uploads, die nicht SSE-KMS verwenden. Die zweite Anweisung beschränkt Uploads zusätzlich darauf, dass ausschließlich Ihr spezifischer CMK-ARN verwendet wird, um zu verhindern, dass versehentlich der Standard-aws/s3-Schlüssel oder ein anderer CMK für Ihren regulierten Daten-Bucket verwendet wird.

Vollständiger Vergleich aller S3-Verschlüsselungsoptionen

Die folgende Tabelle fasst alle S3-Verschlüsselungsoptionen hinsichtlich der für eine Sicherheits- und Compliance-Entscheidung relevanten Dimensionen zusammen:

Option	Verschlüsselung in Ruhe	Verschlüsselung während der Übertragung	Schlüsselverwaltung durch	CloudTrail pro Objekt	Unabhängige Tastensteuerung	AWS sieht Klartext
SSE-S3	Ja (AES-256-GCM)	Nein (separate Richtlinie)	AWS	Nein	Nein	Ja
SSE-KMS (AWS-verwalteter Schlüssel)	Ja (AES-256-GCM)	Nein (separate Richtlinie)	AWS	Ja	Nein	Ja
SSE-KMS (Kundengesteuertes CMK)	Ja (AES-256-GCM)	Nein (separate Richtlinie)	Kunde (im KMS)	Ja	Ja	Ja
SSE-C	Ja (AES-256-GCM)	Nein (separate Richtlinie)	Kunde (außerhalb von AWS)	Nein	Ja	Ja (während der Operation)
Clientseitig + KMS CMK	Ja (AES-256-GCM)	Nein (separate Richtlinie)	Kunde (Schlüsselverpackung in KMS)	Ja (nur Tastenumwicklung)	Ja	Nein
Clientseitiger + selbstverwalteter Schlüssel	Ja (AES-256-GCM)	Nein (separate Richtlinie)	Kunde (vollständig außerhalb von AWS)	Nein	Ja	Nein
aws:SecureTransport-Richtlinie	Nein	Ja (TLS)	AWS (TLS-Zertifikat)	Nein	Nein	N / A

Multi-Cloud- und Hybrid-Verschlüsselungsarchitektur für S3

Organisationen, die S3 zusammen mit Azure Blob Storage, Google Cloud Storage oder lokalem Objektspeicher verwenden, stehen vor der Herausforderung der Konsistenz im Schlüsselmanagement: Jede Cloud-Plattform verfügt über einen eigenen nativen Schlüsselverwaltungsdienst, und die Verwaltung separater Schlüsselinventare, Rotationsrichtlinien und Audit-Trails über verschiedene Anbieter hinweg vervielfacht die operative Komplexität und den Aufwand für die Einhaltung der Vorschriften.

Drei Muster bieten eine konsistente Lösung für die Multi-Cloud-S3-Verschlüsselung:

• Cloud-native Lösung pro Cloud mit einheitlichem CLM: Nutzen Sie SSE-KMS für S3, Azure-verwaltete Schlüssel für Blob und Cloud KMS für GCS. Implementieren Sie jedoch eine Zertifikats- und Schlüssellebenszyklusmanagement-Plattform, die den Schlüsselbestand aggregiert, die Einhaltung der Rotationsrichtlinien überwacht und einen einheitlichen Prüfpfad über alle Cloud-Anbieter hinweg bereitstellt. Dadurch bleibt die native Performance erhalten und gleichzeitig wird Transparenz in der Governance gewährleistet.
• Zentralisierte BYOK-Verwaltung in jeder Cloud: Generieren Sie alle Schlüsselmaterialien aus einem einzigen externen Schlüsselverwaltungssystem. Importieren Sie abgeleitete Schlüssel in AWS KMS (für SSE-KMS BYOK), Azure Key Vault (für Azure BYOK) und GCP Cloud KMS (für GCP BYOK). Alle Clouds verwenden Schlüssel, die auf dieselbe autoritative Quelle zurückgeführt werden können. Schlüsselrotation und Lebenszyklusrichtlinie werden zentral verwaltet.
• Clientseitige Verschlüsselung mit einem gemeinsamen Hauptschlüssel: Verschlüsseln Sie alle Daten clientseitig vor dem Upload mit demselben Hauptschlüssel, unabhängig davon, in welcher Cloud die Daten gespeichert werden. Der Cloud-Anbieter ist vollständig von der Schlüsselhierarchie ausgeschlossen. Dies ist das stärkste Multi-Cloud-Souveränitätsmodell, erfordert jedoch, dass Ihre Anwendung alle kryptografischen Operationen selbst durchführt und Ihr externes Schlüsselverwaltungssystem für jeden Lese- und Schreibvorgang hochverfügbar ist.

Für Organisationen, die Verschlüsselungsschlüssel in S3 und anderen Cloud- und On-Premise-Quellen verwalten, bietet CBOM Secure von Encryption Consulting die automatisierte Erkennung und Inventarisierung kryptografischer Assets, einschließlich KMS-Schlüssel, S3-Bucket-Verschlüsselungskonfigurationen und Zertifikatsinventar im CycloneDX-Format für Compliance-Berichte. Unsere Beratungsleistungen zum Datenschutz in der Cloud entwickeln die passende Schlüsselverwaltungsarchitektur für Ihre spezifischen Multi-Cloud-Compliance-Anforderungen.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein Beratungsunternehmen für angewandte Kryptografie mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Konzeption, Implementierung und Prüfung von S3-Verschlüsselungskonfigurationen, die den Anforderungen von HIPAA, PCI DSS, FedRAMP, NIST 800-53 und anderen Compliance-Rahmenwerken entsprechen.

• Hinweis zum Datenschutz in der Cloud: Wir analysieren Ihre aktuelle S3-Verschlüsselungskonfiguration, identifizieren Schwachstellen (unverschlüsselte Buckets, fehlende Bucket-Richtlinien, SSE-S3, wo SSE-KMS erforderlich ist, fehlende CloudTrail-Datenereignisse) und entwerfen die Zielarchitektur inklusive Schlüsselverwaltungsmodell, IAM-Modell, Durchsetzung von Bucket-Richtlinien und Rotationsplan. Weitere Informationen finden Sie in unserem Beratungsdienste.
• HSM als Dienstleistung: Für BYOK- und clientseitige Verschlüsselungsszenarien, bei denen Ihr Schlüsselmaterial in einem FIPS-validierten HSM außerhalb von AWS generiert werden muss, bietet Encryption Consulting die entsprechende Lösung an. HSM als Service bietet eine dedizierte FIPS 140-2 Level 3 HSM-Infrastruktur für die Schlüsselgenerierung mit Integration in AWS KMS Schlüsselimport-Workflows.
• CBOM Secure: AWS-Umgebungen mit vielen S3-Buckets weisen häufig inkonsistente Verschlüsselungskonfigurationen auf. (Anmerkung: Der letzte Satz "Encryption Consulting" scheint nicht relevant für die Übersetzung zu sein und wurde daher entfernt.) CBOM Secure Erkennt und inventarisiert alle S3-Bucket-Verschlüsselungseinstellungen, KMS-Schlüsselkonfigurationen und Zugriffsrichtlinien Ihrer AWS-Konten und generiert eine kryptografische Stückliste im CycloneDX-Format, die Lücken aufzeigt und die Erstellung von Prüfnachweisen unterstützt.
• PKI als Dienstleistung: Für Organisationen, die private PKI-Zertifikate für die S3-Clientauthentifizierung benötigen (gegenseitiges TLS zu S3-Zugriffspunkten oder S3 über VPC-Endpunkte), bietet Encryption Consulting die entsprechenden Lösungen an. PKI als Service bietet eine verwaltete private Zertifizierungsstelle mit ACME-automatisierter Zertifikatslebenszyklusverwaltung.
• PQC-Bereitschaft: Das NIST finalisierte im August 2024 die Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). NIST IR 8547 deutet darauf hin, dass RSA und ECC für neue Anwendungsfälle um das Jahr 2030 als veraltet gelten werden. Obwohl das von S3 verwendete AES-256-GCM als quantenresistent gilt, muss die Schlüsselverwaltungsinfrastruktur (KMS-Schlüsselkapselung, TLS-Verbindungen zu S3-Endpunkten) auf Post-Quanten-Algorithmen umgestellt werden. (Encryption Consulting) PQC-Bereitschaft Der Service bildet Ihre gesamte kryptografische S3-Sicherheitslage auf den Migrationszeitplan ab.

Um Ihre S3-Verschlüsselungsarchitektur zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

AWS S3 verschlüsselt nun standardmäßig alle neuen Objekte, wodurch das Risiko der versehentlichen Speicherung unverschlüsselter Daten beseitigt wird. Die Standardverschlüsselung mit SSE-S3 bietet jedoch kein Audit-Trail, keine unabhängige Schlüsselverwaltung und keine Möglichkeit, den Zugriff auf Daten ohne deren Löschung zu widerrufen. Für regulierte Workloads ist SSE-KMS mit einem kundenverwalteten CMK die minimal erforderliche Konfiguration: Sie fügt ein objektbezogenes Audit-Trail hinzu, ermöglicht die Deaktivierung des Schlüssels, um die S3-Entschlüsselungsfunktion sofort zu widerrufen, und unterstützt BYOK, falls kundengeneriertes Schlüsselmaterial benötigt wird.

Clientseitige Verschlüsselung ist die richtige Wahl, wenn das Bedrohungsmodell erfordert, dass AWS niemals Zugriff auf Klartextdaten erhält, auch nicht unter rechtlicher Verpflichtung. Sie erhöht zwar die Komplexität der Anwendung, bietet aber die stärkste verfügbare Datensouveränität in jeder Cloud-Umgebung.

Die Entscheidung über die Schlüsselkontrolle, das IAM-Design, die Durchsetzung der Bucket-Richtlinien und die CloudTrail-Konfiguration sind genauso wichtig wie die Verschlüsselungsmethode selbst. Verschlüsselung ohne die dazugehörigen Kontrollmechanismen ist reine Show: Man kann zwar behaupten, die Daten seien verschlüsselt, aber man kann nicht sagen, wer sie wann entschlüsselt hat und ob diese Person dazu berechtigt war.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen SSE-S3, SSE-KMS und SSE-C in Amazon S3?

SSE-S3 lässt AWS alle Verschlüsselungsschlüssel automatisch generieren, verwalten und rotieren, ohne dass der Kunde Einblick oder Kontrolle darüber hat. SSE-KMS nutzt AWS KMS und bietet einen CloudTrail-Prüfprotokoll für jeden Ver- und Entschlüsselungsvorgang, wobei zwischen von AWS verwalteten und vom Kunden verwalteten Schlüsseln gewählt werden kann. SSE-C erfordert die Angabe eines 256-Bit-AES-Schlüssels in jedem Anfrageheader; S3 verwendet diesen und verwirft ihn sofort, wobei lediglich ein HMAC-Fingerabdruck gespeichert wird. Der Hauptunterschied liegt in der Prüftiefe und der Kontrolle: SSE-S3 bietet keines von beidem; SSE-KMS bietet beides; SSE-C bietet Kontrolle ohne KMS-Prüfprotokoll.

Was ist clientseitige Verschlüsselung in Amazon S3 und wann sollte ich sie verwenden?

Clientseitige Verschlüsselung bedeutet, dass Sie Daten vor dem Hochladen in S3 verschlüsseln. S3 speichert daher ausschließlich den verschlüsselten Text, und AWS verarbeitet niemals Klartext. Nutzen Sie diese Methode, wenn regulatorische Anforderungen die Verschlüsselung vor dem Verlassen Ihrer Umgebung vorschreiben, wenn Ihr Bedrohungsmodell AWS als potenziellen Zugriffspunkt einschließt (HYOK-Modell) oder wenn Sie Zero-Trust-Speicher benötigen, bei dem kein Cloud-Anbieter auf Ihre Daten zugreifen kann. Der Nachteil besteht darin, dass die Anwendung die volle Verantwortung für die Schlüsselverwaltung, -rotation und -verteilung an alle Systeme trägt, die Objektzugriff benötigen.

Verschlüsselt AWS S3 Daten standardmäßig?

Ja. Seit Januar 2023 wendet Amazon S3 automatisch SSE-S3 (AES-256-GCM) auf alle neuen Objekte in jedem S3-Bucket an, auch ohne explizite Konfiguration. Bereits im Bucket gespeicherte Objekte werden nicht nachträglich verschlüsselt. Sie können die Standardeinstellung auf Bucket-Ebene auf SSE-KMS ändern, um ein CloudTrail-Audit-Protokoll und die Kontrolle der Kundenschlüssel zu aktivieren.

Was ist BYOK für Amazon S3 und wie funktioniert es?

BYOK (Bring Your Own Key) für S3 bedeutet, dass Sie Schlüsselmaterial in Ihrem eigenen HSM oder Schlüsselverwaltungssystem generieren, es als kundenseitig verwalteten Schlüssel mit importiertem Schlüsselmaterial in AWS KMS importieren und SSE-KMS für Ihren S3-Bucket so konfigurieren, dass dieser CMK verwendet wird. AWS KMS verwendet Ihr importiertes Material, um die Datenverschlüsselungsschlüssel zu generieren, die Ihre Objekte schützen. Sie behalten das Quellschlüsselmaterial und können es aus KMS löschen, um eine weitere Entschlüsselung ohne Unterstützung des AWS-Supports sofort zu verhindern.

Wie kann ich die Verschlüsselung aller S3-Objekte mithilfe einer Bucket-Richtlinie erzwingen?

Fügen Sie in Ihrer S3-Bucket-Richtlinie eine Deny-Anweisung hinzu, die s3:PutObject-Anfragen blockiert, bei denen der Header s3:x-amz-server-side-encryption nicht auf aws:kms (für SSE-KMS) oder AES256 (für SSE-S3) gesetzt ist. Fügen Sie eine zweite Deny-Anweisung hinzu, indem Sie die Bedingung aws:SecureTransport auf „false“ setzen, um jegliche HTTP-Anfragen (ohne TLS) zu blockieren. Diese beiden Bedingungen verhindern zusammen sowohl unverschlüsselte Uploads als auch unverschlüsselte Verbindungen zum Bucket.

Wie wird die AWS S3-Verschlüsselung in den CloudTrail-Audit-Protokollen angezeigt?

SSE-KMS generiert bei jedem PutObject ein GenerateDataKey-CloudTrail-Ereignis und bei jedem GetObject ein Decrypt-Ereignis. Jedes Ereignis enthält den KMS-Schlüssel-ARN, den anfragenden IAM-Principal, den S3-Bucket- und Objektschlüssel, die Quell-IP-Adresse und einen Zeitstempel. SSE-S3 und SSE-C generieren keine KMS-Ereignisse. Aktivieren Sie S3-Datenereignisse in CloudTrail separat von Verwaltungsereignissen, da API-Aufrufe auf S3-Objektebene standardmäßig nicht in den Verwaltungsereignisprotokollen erfasst werden.