Tryby szyfrowania i wymuszanie transmisji

Bezpieczeństwo AWS dla deweloperów

Rahul Singh

Technical Product Manager

Dwie gwarancje, jeden domyślny tryb

Aplikacja wysyła obiekt do zasobnika Amazon S3. Zielony nawias oznaczony „podczas przesyłania" obejmuje etap sieciowy, a drugi zielony nawias oznaczony „w spoczynku" obejmuje zapisany obiekt. Poniżej znajduje się uwaga, że SSE-S3 stosuje się, chyba że żądanie mówi inaczej.

W spoczynku: bajty na dysku
Podczas przesyłania: bajty w sieci

Dwie gwarancje, jeden domyślny tryb

W spoczynku: bajty na dysku
Podczas przesyłania: bajty w sieci
Już zrobione: SSE-S3 dla każdego nowego obiektu
Nadal twoje: wybór trybu i to, kto trzyma klucz

Gdzie kończy się jawny tekst

Po stronie serwera

AWS otrzymuje czytelne bajty
S3 szyfruje podczas zapisu

Przepływ po stronie serwera. Twój proces przechowuje jawny tekst, wysyła go przez połączenie TLS, a Amazon S3 szyfruje podczas zapisu. Pasek poniżej śledzi bajty, podzielony przerywaną linią przy S3: odcinek przed nią jest oznaczony „twoje bajty: czytelne tutaj" i pokazany na czerwono, odcinek po niej jest oznaczony „szyfrogram" i pokazany na zielono.

Gdzie kończy się jawny tekst

Po stronie serwera

AWS otrzymuje czytelne bajty
S3 szyfruje podczas zapisu

Po stronie klienta

Szyfrujesz dane, zanim je wyślesz
AWS przechowuje tylko szyfrogram

Przepływ po stronie klienta. Twój proces najpierw szyfruje dane, wysyła szyfrogram przez połączenie TLS, a Amazon S3 zapisuje to, co otrzymał. Pasek poniżej śledzi bajty, podzielony przerywaną linią wewnątrz twojego procesu: krótki odcinek przed nią jest oznaczony „twoje bajty: czytelne tutaj" i pokazany na czerwono, wszystko po niej jest oznaczone „szyfrogram" i pokazane na zielono.

Cztery tryby, jedna różnica

Ten sam algorytm, czterech właścicieli klucza

Tryb jest przekazywany jako nagłówek żądania PUT
SSE-S3: klucz AWS, nic do zarządzania
SSE-KMS: twój klucz, CloudTrail i zasady klucza określające, komu odpowie

Cztery ułożone karty z nazwami SSE-S3, SSE-KMS, DSSE-KMS i SSE-C. Pionowa linia po lewej biegnie od kontroli AWS u góry do twojej kontroli u dołu, a każda karta zawiera tylko wartość nagłówka żądania wybierającą dany tryb.

Cztery tryby, jedna różnica

Ten sam algorytm, czterech właścicieli klucza

Tryb jest przekazywany jako nagłówek żądania PUT
SSE-S3: klucz AWS, nic do zarządzania
SSE-KMS: twój klucz, CloudTrail i zasady klucza określające, komu odpowie
DSSE-KMS: dwie niezależne warstwy
SSE-C: twój klucz przy każdym żądaniu, za którego utratę odpowiadasz sam

Zarzut kosztowy wobec SSE-KMS

Dwa wiersze. Bez Bucket Keys sześć strzałek biegnie z Amazon S3 do AWS KMS, po jednej dla każdego żądania obiektu. Z Bucket Keys wychodzi tylko jedna strzałka z klucza na poziomie zasobnika przechowywanego wewnątrz S3. Uwaga poniżej wskazuje, że Bucket Keys nie są dostępne z DSSE-KMS.

Bez Bucket Keys: jedno wywołanie KMS na obiekt
Z Bucket Keys: jeden krótkotrwały klucz, używany wielokrotnie
Niedostępne z DSSE-KMS
Nawet o 99% mniej żądań do KMS

Szyfruj pole, nie tabelę

Szyfrowanie w spoczynku już działa

Zapytanie zwraca jawny tekst każdemu z uprawnieniami do odczytu

Jeden element DynamoDB z pięcioma atrybutami. Dwa atrybuty zawierają szyfrogram i mają niebieskie oznaczenia, podczas gdy klucz partycji, klucz sortowania i znacznik czasu pozostają jawnym tekstem. Zielony prostokąt poniżej wskazuje, że cała tabela jest szyfrowana w spoczynku.

Szyfruj pole, nie tabelę

Szyfrowanie w spoczynku już działa

Zapytanie zwraca jawny tekst każdemu z uprawnieniami do odczytu

AWS Database Encryption SDK

Szyfruj wybrane atrybuty w swoim kodzie
Klucz partycji i klucz sortowania, czyli pola, po których DynamoDB wyszukuje elementy, pozostają jawnym tekstem, bo służą do indeksowania

TLS jest oferowany, nie wymagany

Oferowane, nie wymuszone

S3 odpowiada zarówno na HTTP, jak i HTTPS

Dwa scenariusze. Bez warunku na zasobniku zarówno klient HTTPS, jak i HTTP uzyskują dostęp do obiektu. Z warunkiem odmowy ścieżka HTTP zatrzymuje się na czerwonym krzyżyku i nigdy się nie łączy.

TLS jest oferowany, nie wymagany

Oferowane, nie wymuszone

S3 odpowiada zarówno na HTTP, jak i HTTPS

Wymuś to jako wymóg

Zasady zasobnika: odmowa, gdy aws:SecureTransport ma wartość false
Uprawnieni klienci niczego nie zauważą

Który urząd poświadcza nazwę

Nazwa publiczna

ACM: publicznie zaufany, darmowy, odnawia się sam

Nazwa rozpoznawana tylko w twojej sieci

AWS Private CA: własny urząd certyfikacji
Nigdy nie zaufany w publicznym internecie

Dwie ułożone karty zatytułowane: kto może wystawić certyfikat. Górna karta, nazwa publiczna, podaje reports.example.com jako nazwę, którą rozpoznaje, oraz ACM jako wystawcę, zaufanego wszędzie. Dolna karta, nazwa wewnętrzna, podaje admin.example.internal, rozpoznawaną tylko wewnątrz twojego VPC, oraz AWS Private CA jako wystawcę.

Za prywatną połowę odpowiadasz sam

Kto go przechowuje

ACM: przechowuje go AWS
Para kluczy EC2 lub dowolny klucz SSH: ty przechowujesz prywatną połowę, i to tylko raz

Dwie ułożone karty zatytułowane: kto przechowuje którą połowę. Górna karta, połowa publiczna, mówi, że znajduje się w AWS lub na instancji. Dolna, pomarańczowa karta, połowa prywatna, zawiera trzy wiersze: dostajesz jedną kopię bez zapasowej, przechowuj ją w Secrets Manager (zielony znacznik), i nigdy w repozytorium, na laptopie ani w czacie (pomarańczowy krzyżyk).

Za prywatną połowę odpowiadasz sam

Kto go przechowuje

ACM: przechowuje go AWS
Para kluczy EC2 lub dowolny klucz SSH: ty przechowujesz prywatną połowę, i to tylko raz

Jeśli to twój klucz

Secrets Manager, nie repozytorium
Wymieniaj go regularnie

Trzy odpowiedzi, nie jedna

Trzy ponumerowane karty: tryb, kontrola klucza i transmisja, każda pokazuje nagłówek lub klucz warunku, który na nią odpowiada. Linia poniżej zaznacza, że tylko trzecia kontrola znajduje się poza ustawieniami szyfrowania.

Tryb: co zapisało obiekt
Kontrola klucza: kto może go odszyfrować, w tym koncie lub innym
Transmisja: wymagana czy tylko oferowana

Czas na praktykę!

Bezpieczeństwo AWS dla deweloperów