Versleutelingsmodi en afdwingen tijdens transport

AWS-beveiliging gebruiken voor developers

Rahul Singh

Technical Product Manager

Twee zekerheden, één standaard

Een applicatie stuurt een object naar een Amazon S3-bucket. Een groene beugel met het label in transit beslaat de netwerksprong, en een tweede groene beugel met het label at rest beslaat het opgeslagen object, met daarboven een opmerking dat SSE-S3 geldt tenzij het verzoek anders aangeeft.

At rest: de bytes op schijf
In transit: de bytes op het netwerk

Twee zekerheden, één standaard

At rest: de bytes op schijf
In transit: de bytes op het netwerk
Al geregeld: SSE-S3 op elk nieuw object
Nog jouw keuze: Welke modus, en wie de sleutel heeft, bepaal jij

Waar de platte tekst stopt

Server-side

AWS ontvangt leesbare bytes
S3 versleutelt bij het wegschrijven

Een server-side flow. Je proces houdt platte tekst vast, stuurt die via een TLS-verbinding, en Amazon S3 versleutelt bij het schrijven. Een balk eronder volgt de bytes, gesplitst door een stippellijn bij S3: het stuk ervoor heet "your bytes: readable here" en is rood, het stuk erna heet "ciphertext" en is groen.

Waar de platte tekst stopt

Server-side

AWS ontvangt leesbare bytes
S3 versleutelt bij het wegschrijven

Client-side

Jij versleutelt vóór het vertrekt
AWS slaat alleen ciphertext op

Een client-side flow. Je proces versleutelt eerst, stuurt ciphertext via een TLS-verbinding, en Amazon S3 slaat op wat het ontving. Een balk eronder volgt de bytes, gesplitst door een stippellijn binnen je proces: het korte stuk ervoor heet "your bytes: readable here" en is rood, alles erna heet "ciphertext" en is groen.

Vier modi, één verschil

Zelfde algoritme, vier sleuteleigenaren

De modus gaat mee als header op de PUT
SSE-S3: AWS-sleutel, niets te beheren
SSE-KMS: jouw sleutel, CloudTrail, en een key policy aan de sleutel die bepaalt wie antwoord krijgt

Vier gestapelde kaarten met SSE-S3, SSE-KMS, DSSE-KMS en SSE-C. Links een rail van AWS-controle boven naar jouw controle onder; elke kaart toont alleen de request-headerwaarde die die modus kiest.

Vier modi, één verschil

Zelfde algoritme, vier sleuteleigenaren

De modus gaat mee als header op de PUT
SSE-S3: AWS-sleutel, niets te beheren
SSE-KMS: jouw sleutel, CloudTrail, en een key policy aan de sleutel die bepaalt wie antwoord krijgt
DSSE-KMS: twee onafhankelijke lagen
SSE-C: jouw sleutel bij elk verzoek, jouw risico bij verlies

Vier gestapelde kaarten met SSE-S3, SSE-KMS, DSSE-KMS en SSE-C. Links een rail van AWS-controle boven naar jouw controle onder; elke kaart toont alleen de request-headerwaarde die die modus kiest.

De kostenbezwaar tegen SSE-KMS

Twee rijen. Zonder Bucket Keys gaan zes pijlen van Amazon S3 naar AWS KMS, één per objectverzoek. Met Bucket Keys vertrekt één pijl vanuit een bucket-sleutel binnen S3. Een noot onderaan vermeldt dat Bucket Keys niet beschikbaar zijn met DSSE-KMS.

Zonder: één KMS-call per object
Met Bucket Keys: één kortlevende sleutel, hergebruikt
Niet beschikbaar met DSSE-KMS
Tot 99% minder KMS-verzoeken

Versleutel het veld, niet de tabel

At rest staat al aan

Een query geeft platte tekst terug aan iedereen met leesrechten

Eén DynamoDB-item met vijf attributen. Twee attributen bevatten ciphertext en hebben blauwe rails, terwijl de partition key, sort key en timestamp platte tekst blijven. Een groen vak onderaan stelt dat de hele tabel at rest versleuteld is.

Versleutel het veld, niet de tabel

At rest staat al aan

Een query geeft platte tekst terug aan iedereen met leesrechten

AWS Database Encryption SDK

Versleutel gekozen attributen in je code
Partition en sort keys, de velden waarmee DynamoDB items vindt, blijven platte tekst omdat het daarop indexeert

TLS wordt aangeboden, niet vereist

Aangeboden, niet afgedwongen

S3 beantwoordt HTTP en HTTPS beide

Twee scenario's. Zonder voorwaarde op de bucket bereiken zowel een HTTPS- als een HTTP-client het object. Met de deny-voorwaarde stopt het HTTP-pad bij een rood kruis en maakt nooit verbinding.

TLS wordt aangeboden, niet vereist

Aangeboden, niet afgedwongen

S3 beantwoordt HTTP en HTTPS beide

Maak het verplicht

Bucket policy: weiger als aws:SecureTransport false is
Legitieme clients merken niets

Twee scenario's. Zonder voorwaarde op de bucket bereiken zowel een HTTPS- als een HTTP-client het object. Met de deny-voorwaarde stopt het HTTP-pad bij een rood kruis en maakt nooit verbinding.

Welke autoriteit staat voor de naam in

Publieke naam

ACM: publiek vertrouwd, gratis, verlengt zichzelf

Naam die alleen jouw netwerk oplost

AWS Private CA: je eigen certificaatautoriteit
Nooit vertrouwd op het publieke internet

Twee gestapelde kaarten met wie het certificaat kan uitgeven. De bovenste kaart, publieke naam, toont reports punt example punt com als naam en ACM als uitgever, overal vertrouwd. De onderste kaart, interne naam, toont admin punt example punt internal, alleen binnen je VPC, en AWS Private CA als uitgever.

De private helft kun jij verliezen

Wie beheert het

ACM: AWS bewaart het
EC2-sleutelpaar, of een SSH-sleutel: jij bewaart de private helft, éénmalig

Twee gestapelde kaarten met wie welke helft beheert. De bovenste kaart, publieke helft, zegt dat die op AWS of de instance staat. De onderste oranje kaart, private helft, geeft drie regels: je krijgt één kopie en geen reserve, bewaar in Secrets Manager met een groen vinkje, en nooit in een repo, laptop of chat, met een oranje kruis.

De private helft kun jij verliezen

Wie beheert het

ACM: AWS bewaart het
EC2-sleutelpaar, of een SSH-sleutel: jij bewaart de private helft, éénmalig

Als het van jou is

Secrets Manager, niet in een repo
Vervang periodiek

Drie antwoorden, niet één

Drie genummerde kaarten voor modus, sleutelcontrole en transport, elk met de header of condition key die het beantwoordt. Een regel eronder merkt op dat alleen de derde check buiten de versleutelingsinstellingen valt.

Modus: wat het object schreef
Sleutelcontrole: wie het kan ontsleutelen, in dit account of een ander
Transport: verplicht, of alleen aangeboden

Laten we oefenen!

AWS-beveiliging gebruiken voor developers