Verschlüsselungsmodi und Schutz in der Übertragung

AWS-Sicherheit für Entwickler:innen nutzen

Rahul Singh

Technical Product Manager

Zwei Garantien, eine Voreinstellung

Eine Anwendung sendet ein Objekt an einen Amazon-S3-Bucket. Eine grüne Klammer „in transit" markiert den Netzwerk-Hop, eine zweite grüne Klammer „at rest" das gespeicherte Objekt; darüber der Hinweis, dass SSE-S3 gilt, sofern die Anfrage nichts anderes angibt.

At rest: die Bytes auf dem Datenträger
In transit: die Bytes im Netzwerk

Zwei Garantien, eine Voreinstellung

At rest: die Bytes auf dem Datenträger
In transit: die Bytes im Netzwerk
Schon aktiv: SSE-S3 für jedes neue Objekt
Deins: Welcher Modus und wer den Schlüssel hält, entscheidest du

Wo der Klartext endet

Serverseitig

AWS empfängt lesbare Bytes
S3 verschlüsselt beim Schreiben

Ein serverseitiger Ablauf. Dein Prozess hält Klartext, sendet ihn über TLS, und Amazon S3 verschlüsselt beim Schreiben. Ein Balken unten zeigt die Bytes, mit gestrichelter Trennlinie bei S3: davor „deine Bytes: hier lesbar" (rot), danach „ciphertext" (grün).

Wo der Klartext endet

Serverseitig

AWS empfängt lesbare Bytes
S3 verschlüsselt beim Schreiben

Clientseitig

Du verschlüsselst vor dem Senden
AWS speichert nur Ciphertext

Ein clientseitiger Ablauf. Dein Prozess verschlüsselt zuerst, sendet Ciphertext über TLS, und Amazon S3 speichert, was es erhält. Ein Balken unten zeigt die Bytes, mit gestrichelter Trennlinie in deinem Prozess: der kurze Abschnitt davor „deine Bytes: hier lesbar" (rot), alles danach „ciphertext" (grün).

Vier Modi, ein Unterschied

Gleicher Algorithmus, vier Schlüsselhalter

Der Modus reist als Header auf dem PUT
SSE-S3: AWS-Schlüssel, nichts zu verwalten
SSE-KMS: dein Schlüssel, CloudTrail und eine Schlüsselrichtlinie am Schlüssel, die festlegt, wem er antwortet

Vier gestapelte Karten mit SSE-S3, SSE-KMS, DSSE-KMS und SSE-C. Eine Leiste links läuft von AWS-Kontrolle oben zu deiner Kontrolle unten; jede Karte zeigt nur den Request-Header, der den Modus wählt.

Vier Modi, ein Unterschied

Gleicher Algorithmus, vier Schlüsselhalter

Der Modus reist als Header auf dem PUT
SSE-S3: AWS-Schlüssel, nichts zu verwalten
SSE-KMS: dein Schlüssel, CloudTrail und eine Schlüsselrichtlinie am Schlüssel, die festlegt, wem er antwortet
DSSE-KMS: zwei unabhängige Ebenen
SSE-C: dein Schlüssel bei jeder Anfrage – und dein Risiko, ihn zu verlieren

Der Kosteneinwand gegen SSE-KMS

Zwei Reihen. Ohne Bucket Keys gehen sechs Pfeile von Amazon S3 zu AWS KMS, einer pro Objektanfrage. Mit Bucket Keys verlässt ein einzelner Pfeil einen Bucket-Schlüssel innerhalb von S3. Hinweis: Bucket Keys gibt es nicht mit DSSE-KMS.

Ohne: ein KMS-Call pro Objekt
Mit Bucket Keys: ein kurzlebiger Schlüssel, wiederverwendet
Nicht verfügbar mit DSSE-KMS
Bis zu 99% weniger KMS-Anfragen

Feld verschlüsseln, nicht die Tabelle

At rest ist bereits aktiv

Eine Abfrage liefert Klartext an alle mit Leserechten

Ein DynamoDB-Item mit fünf Attributen. Zwei Attribute enthalten Ciphertext und haben blaue Leisten; Partitionsschlüssel, Sortierschlüssel und Zeitstempel bleiben Klartext. Ein grünes Feld unten sagt, dass die ganze Tabelle „at rest" verschlüsselt ist.

Feld verschlüsseln, nicht die Tabelle

At rest ist bereits aktiv

Eine Abfrage liefert Klartext an alle mit Leserechten

AWS Database Encryption SDK

Verschlüssele ausgewählte Attribute in deinem Code
Partitions- und Sortierschlüssel – die Felder, nach denen DynamoDB sucht – bleiben Klartext, da darauf indexiert wird

TLS ist angeboten, nicht vorgeschrieben

Angeboten, nicht erzwungen

S3 beantwortet HTTP und HTTPS gleichermaßen

Zwei Szenarien. Ohne Bedingung am Bucket erreichen HTTPS- und HTTP-Client das Objekt. Mit der Deny-Bedingung endet der HTTP-Pfad an einem roten Kreuz und verbindet nicht.

TLS ist angeboten, nicht vorgeschrieben

Angeboten, nicht erzwungen

S3 beantwortet HTTP und HTTPS gleichermaßen

Zur Pflicht machen

Bucket-Richtlinie: verweigern, wenn aws:SecureTransport false ist
Legitime Clients merken nichts

Zwei Szenarien. Ohne Bedingung am Bucket erreichen HTTPS- und HTTP-Client das Objekt. Mit der Deny-Bedingung endet der HTTP-Pfad an einem roten Kreuz und verbindet nicht.

Welche Instanz bürgt für den Namen

Öffentlicher Name

ACM: öffentlich vertrauenswürdig, gratis, erneuert sich selbst

Name, den nur dein Netz auflöst

AWS Private CA: deine eigene Zertifizierungsstelle
Im öffentlichen Internet nie vertrauenswürdig

Zwei gestapelte Karten mit der Frage, wer das Zertifikat ausstellt. Oben: öffentlicher Name, „reports.example.com" als Name und ACM als Aussteller, überall vertraut. Unten: interner Name, „admin.example.internal", nur innerhalb deiner VPC aufgelöst, Aussteller AWS Private CA.

Die private Hälfte kannst du verlieren

Wer sie hält

ACM: AWS verwahrt sie
EC2-Schlüsselpaar oder beliebiger SSH-Schlüssel: du hältst die private Hälfte, einmalig

Zwei gestapelte Karten zur Frage, wer welche Hälfte hält. Oben, öffentliche Hälfte: liegt auf AWS oder der Instanz. Unten, orange, private Hälfte: du bekommst eine Kopie, kein Ersatz; im Secrets Manager aufbewahren (grüner Haken), niemals im Repo, auf dem Laptop oder im Chat (orangefarbenes Kreuz).

Die private Hälfte kannst du verlieren

Wer sie hält

ACM: AWS verwahrt sie
EC2-Schlüsselpaar oder beliebiger SSH-Schlüssel: du hältst die private Hälfte, einmalig

Wenn sie dir gehört

Secrets Manager statt Repo
Regelmäßig ersetzen

Drei Antworten, nicht eine

Drei nummerierte Karten für Modus, Schlüsselkontrolle und Übertragung, jeweils mit dem Header oder dem Bedingungsschlüssel dazu. Eine Zeile unten merkt an, dass nur die dritte Prüfung außerhalb der Verschlüsselungs-Einstellungen liegt.

Modus: was das Objekt geschrieben hat
Schlüsselkontrolle: wer es entschlüsseln kann – in diesem Konto oder einem anderen
Übertragung: vorgeschrieben oder nur angeboten

Lass uns üben!

AWS-Sicherheit für Entwickler:innen nutzen