Moduri de criptare și tranzit impus

Securitatea AWS pentru dezvoltatori

Rahul Singh

Technical Product Manager

Două garanții, o setare implicită

O aplicație trimite un obiect către un bucket Amazon S3. O paranteză verde etichetată în tranzit acoperă saltul de rețea, iar o a doua paranteză verde etichetată la repaus acoperă obiectul stocat, deasupra unei note conform căreia SSE-S3 se aplică dacă cererea nu specifică altfel.

La repaus: octeții de pe disc
În tranzit: octeții din rețea

Două garanții, o setare implicită

La repaus: octeții de pe disc
În tranzit: octeții din rețea
Deja făcut: SSE-S3 pe fiecare obiect nou
Rămâne la tine: ce mod alegi și cine deține cheia

Unde se termină textul simplu

Pe server

AWS primește octeți lizibili
S3 criptează la scriere

Un flux pe server. Procesul tău deține text simplu, îl trimite printr-o conexiune TLS, iar Amazon S3 criptează la scriere. O bară dedesubt urmărește octeții, împărțită de un separator punctat la S3: porțiunea dinainte este etichetată "octeții tăi: lizibili aici" și apare în roșu, porțiunea de după este etichetată "text cifrat" și apare în verde.

Unde se termină textul simplu

Pe server

AWS primește octeți lizibili
S3 criptează la scriere

Pe client

Tu criptezi înainte să plece
AWS stochează doar text cifrat

Un flux pe client. Procesul tău criptează mai întâi, trimite text cifrat printr-o conexiune TLS, iar Amazon S3 stochează ce a primit. O bară dedesubt urmărește octeții, împărțită de un separator punctat chiar în procesul tău: porțiunea scurtă dinainte este etichetată "octeții tăi: lizibili aici" și apare în roșu, tot ce urmează este etichetat "text cifrat" și apare în verde.

Patru moduri, o singură diferență

Același algoritm, patru proprietari de chei

Modul călătorește ca antet în cererea PUT
SSE-S3: cheie AWS, nimic de administrat
SSE-KMS: cheia ta, CloudTrail și o politică de chei atașată cheii care spune cui îi va răspunde

Patru carduri suprapuse, denumite SSE-S3, SSE-KMS, DSSE-KMS și SSE-C. O bară pe partea stângă coboară de la control AWS în partea de sus la controlul tău în partea de jos, iar fiecare card afișează doar valoarea antetului de cerere care selectează acel mod.

Patru moduri, o singură diferență

Același algoritm, patru proprietari de chei

Modul călătorește ca antet în cererea PUT
SSE-S3: cheie AWS, nimic de administrat
SSE-KMS: cheia ta, CloudTrail și o politică de chei atașată cheii care spune cui îi va răspunde
DSSE-KMS: două straturi independente
SSE-C: cheia ta la fiecare cerere, responsabilitatea ta dacă o pierzi

Obiecția legată de cost pentru SSE-KMS

Două rânduri. Fără Bucket Keys, șase săgeți pornesc de la Amazon S3 către AWS KMS, câte una pentru fiecare cerere de obiect. Cu Bucket Keys, o singură săgeată pornește de la o cheie la nivel de bucket păstrată în S3. O notă dedesubt precizează că Bucket Keys nu este disponibilă cu DSSE-KMS.

Fără: un apel KMS per obiect
Cu Bucket Keys: o cheie temporară, reutilizată
Nu este disponibilă cu DSSE-KMS
Până la 99% mai puține cereri KMS

Criptează câmpul, nu tabelul

Criptarea la repaus e deja activă

O interogare returnează text simplu oricui are acces de citire

Un element DynamoDB cu cinci atribute. Două atribute conțin text cifrat și au bare albastre, în timp ce cheia de partiție, cheia de sortare și marca temporală rămân în text simplu. O casetă verde dedesubt precizează că întregul tabel este criptat la repaus.

Criptează câmpul, nu tabelul

Criptarea la repaus e deja activă

O interogare returnează text simplu oricui are acces de citire

AWS Database Encryption SDK

Criptează atributele alese direct în codul tău
Cheia de partiție și cheia de sortare, câmpurile după care DynamoDB caută elementele, rămân în text simplu pentru că sunt indexate

TLS este oferit, nu obligatoriu

Oferit, nu impus

S3 răspunde la fel la HTTP și HTTPS

Două scenarii. Fără nicio condiție pe bucket, atât un client HTTPS, cât și unul HTTP ajung la obiect. Cu condiția de refuz, calea HTTP se oprește la un X roșu și nu se conectează niciodată.

TLS este oferit, nu obligatoriu

Oferit, nu impus

S3 răspunde la fel la HTTP și HTTPS

Transformă-l într-o cerință

Politică de bucket: refuză când aws:SecureTransport este false
Clienții legitimi nu observă nimic

Ce autoritate garantează pentru nume

Nume public

ACM: de încredere publică, gratuit, se reînnoiește automat

Nume rezolvat doar de rețeaua ta

AWS Private CA: o autoritate de certificare proprie
Niciodată de încredere pe internetul public

Două carduri suprapuse, intitulate cine poate emite certificatul. Cardul de sus, nume public, indică reports punct example punct com drept numele rezolvat și ACM drept emitent, de încredere peste tot. Cardul de jos, nume intern, indică admin punct example punct internal, rezolvat doar în interiorul VPC-ului tău, și AWS Private CA drept emitent.

Jumătatea privată e responsabilitatea ta

Cine o deține

ACM: AWS o păstrează
Pereche de chei EC2, sau orice cheie SSH: tu deții jumătatea privată, o singură dată

Două carduri suprapuse, intitulate cine deține fiecare jumătate. Cardul de sus, jumătatea publică, arată că aceasta se află pe AWS sau pe instanță. Cardul portocaliu de jos, jumătatea privată, prezintă trei rânduri: primești o singură copie, fără rezervă; o păstrezi în Secrets Manager, cu bifă verde; și niciodată într-un repo, pe un laptop sau în chat, marcat cu un X portocaliu.

Jumătatea privată e responsabilitatea ta

Cine o deține

ACM: AWS o păstrează
Pereche de chei EC2, sau orice cheie SSH: tu deții jumătatea privată, o singură dată

Dacă e a ta

Secrets Manager, nu un repo
Înlocuiește-o periodic

Trei răspunsuri, nu unul

Trei carduri numerotate pentru mod, control al cheii și tranzit, fiecare arătând antetul sau cheia de condiție care răspunde la el. O linie dedesubt precizează că doar a treia verificare se află în afara setărilor de criptare.

Mod: ce a scris obiectul
Control al cheii: cine îl poate decripta, în acest cont sau în altul
Tranzit: obligatoriu sau doar oferit

Hai să exersăm!

Securitatea AWS pentru dezvoltatori