Amazon gaat data in S3-buckets op AWS voortaan standaard versleutelen

Amazon gaat alle data in S3-buckets voortaan standaard versleutelen met AES-256. Die serversideversleuteling was al langer beschikbaar voor S3, maar stond nooit standaard aan. Beheerders kunnen nog wel zelf bepalen of ze alternatieve encryptie willen toepassen.

Amazon schrijft dat het de standaardencryptie per direct inschakelt voor alle gebruikers. In de praktijk betekent dat dat alle nieuwe objects die naar een Simple Storage Service- of S3-bucket op Amazon Web Services worden geüpload, automatisch worden versleuteld aan de serverkant. Dat gebeurt met AES-256.

Standaard wordt AWS' eigen scheme voor encryptie gebruikt, dat Amazon simpelweg SSE-S3 noemt. Daarnaast is het echter ook mogelijk om eigen encryptiesleutels in te zetten, wat SSE-C of Customer heet, of AWS Key Management Service-keys te gebruiken, afgekort SSE-KMS. Beheerders van een bucket kunnen ook objects op de client versleutelen via software zoals de S3 Encryption Client.

Server-side encryption voor S3, ook wel SSE-S3 genoemd, was al sinds 2011 optioneel te gebruiken in AWS-buckets. Het was ook geen verborgen functie; beheerders konden het eenvoudig inschakelen vanuit de instellingen. Maar het is nu voor het eerst dat de encryptie de standaard wordt.

Amazon zegt dat hoewel het inschakelen eenvoudig was, beheerders bij nieuwe buckets toch altijd moesten controleren of hun nieuwe buckets correct geconfigureerd waren en continu moesten blijven verifiëren of dat het geval was. Amazon zegt dat de feature vooral interessant is voor bedrijven die het belangrijk vinden dat hun AWS-data standaard at rest versleuteld blijft zodat ze aan de eisen kunnen blijven voldoen.

Update: een verkeerde aanname over de veiligheid van dergelijke gevonden data is weggehaald omdat deze encryptiemethodiek daar niets mee te maken heeft.

Reacties (45)

Wat ook meespeelt, is dat op deze manier datalekken vanuit openstaande AWS-buckets mogelijk minder voor zullen komen.

Dit is pertinent onjuist. Ook een encrypted bucket zal als je die publiek zet gewoon leesbaar zijn voor iedereen. Het enige dat encryptie doet is dat het de data encrypted naar de fysieke disk schrijft. Je zal zelf je encryptie moeten regelen (en de sleutel buiten AWS houden) om de data echt buiten het zicht van AWS te houden.

Ik zou je willen verzoeken om toch eens goed in de AWS documentatie te duiken en dan met name AWS kms, key policies en ook AWS HSM. Als je nog tijd hebt, kijk ook eens naar AWS Artifact waarin alle certificeringen in staan vwb deze services.

lees wellicht ook de AWS Agreement ook nog even waarin duidelijk hun rechten en jouw rechten staan.

Wat je hier insinueert klopt niet. Wellicht bedoel je het anders maar je schept nu een beeld alsof men zomaar bij je data kan.

Achtergrond: meer dan 7 jaar werkzaam als consultant bij verschillende AWS consulting partners

volgens mij, en ik ben al 10 jaar bezig als freelancer op dit soort gebieden, is een bucket die open staat naar het internet niet veiliger door dit soort encryptie ;-)

Zolang de bucket "open is" (d.m.v. een access key, of gebrekkige IAM, of iemand met super user access) kan men bij de data. encrypted of niet.

Het enige wat dit doet is de data encrypten op harde schijf, zodat; als de server uit staat, en iemand de harde schijf jat ofzo ze niet bij de data kunnen. Ofwel: weinig kans dat dat gebeurt. Dus dit is niet heel interessant qua encryptie beveiliging.

Het enige wat je kunt doen om echte encryptie / veilig te zijn is de data encrypten VOOR het de S3 bucket bereikt. Dus voordat het de client verlaat ;-)

De welbekende end2end encryption.

Betekent wel extra development werk en niet alleen een vinkje op de S3 bucket voor "nu hebben we encryption!! WOOT!"

Gaat dit artikel niet net om dat vinkje? By default gebruik je toch AWS managed keys als je dit aanzet?

Daar zit wel een verschil in inderdaad. Dat vinkje stond niet standaard aan, omdat het niet echt veel toevoegd aan de veiligheid maar wel CPU cycles opvreet bij Amazon. Ik vind het dan ook echt een onzin feature, maar goed.

de boel verbinden met een KMS key of managed keys, vault, whatever is al beter. Maar ook dan: als je toegang hebt via access keys, etc. Dan kan je die decryption key opvragen en alsnog de data lezen. Maar het wordt wel wat lastiger gemaakt.

Nee voor alle managers en developers hier is het vervelende verhaal toch echt: Pas je software aan zodat er vanaf de versturende partij al encrypte data over de lijn gaat en in die staat ook wordt opgeslagen in je bucket. En dat je DAAR ook KMS, of managed keys of vault, etc gebruikt: top. Maar laat dat niet over aan S3 of minio, dat is minimale effort zonder echt de verwachte voordelen ;-)

Je verhaal klopt niet helemaal. Ook al heeft een access key toegang zul je in geval dat de Bucket middels KMS is versleuteld ook permissie moeten hebben tot de key.

Verder kun je binnen AWS je eigen keys en/of HSM gebruiken. Dat voldoet aan FIPS 140-2 Level 3.

Je insinueert, misschien onbewust, dat je data laten versleutelen door AWS niet het beoogde effect heeft of op een of andere manier “minder” is. Het is een beetje kort door de bocht om te zeggen dat je data zelf versleutelen voordat je het verzendt veiliger is. Dat is van zoveel factoren afhankelijk, en dan heb ik nog niet eens over de praktische kant gehad. In sommige edge cases zal dat veiliger zijn.

Je eigen keys gebruiken is inderdaad een stuk veiliger.

Maar het artikel gaat over het aanzetten van de default encryption. En die heeft, mijns inziens, weinig toe te voegen op safety niveau. Het zorgt er niet voor dat het encrypted over de lijn naar de client gaat bijv. Echt alleen maar voor als de server of schijf gejat wordt.

En ja, om echt encryption voordeel te halen moet je echt zelf vanaf verzending als encrypten.

Als je data veilig wilt opslaan is zelf versleutelen voordat je het naar een (externe) opslaglocatie wegschrijft sowieso de op één na beste manier. De allerbeste is om de cliënt die de data aandraagt, al de versleuteling toe te laten passen. Je moet dan alleen wel ook een infrastructuur opzetten om te zorgen dat (alleen de) andere gebruikers die deze data nodig hebben het weer kunnen ontsleutelen. Je zult dan dus de private key waarmee je het bestand hebt versleuteld, moeten versleutelen met de public keys van die gebruikers en daarna aan hen opsturen of dit ergens in een database bewaren.

Volgens mij legt BugBoy prima uit dat je ook versleutelde bestanden per ongeluk publiek beschikbaar kunt stellen. En dat je dan nog altijd de encryptie sleutels goed moet hebben beschermd.

Als je S3 encryptie aanzet, dan hoef je zelf helemaal geen sleutels te beheren. Dat doet AWS voor jou en dat gebeurt volledige transparant. Het biedt dus echt nul meerwaarde voor het beschermen van je buckets richting het internet. Het is puur dat de fysieke drager encrypted is.

Je hebt de keuze via AWS om wel zelfs je keys te beheren (KMS), maar zelfs dan is het nog prima mogelijk om een bucket publiek open te zetten. Daar moet je wel moeite voor doen en je wordt tig-keer gewaarschuwd, maar het kan gewoon.

Tweakers slaat hier de plank mis, maar past het artikel blijkbaar niet aan. Nu verwacht ik van Tweakers ook niet dat ze specialist zijn op gebied van AWS. Maar met een reactie direct onder het artikel (vrijwel direct na plaatsing), zou je verwachten dat ze toch ergens navraag zouden doen.

AWS zet dit automatisch aan voor iedereen. Dat zou inhouden als Tweakers gelijk heeft dat alle publieke buckets nu ineens ontoegankelijk zouden worden. Dan ligt ongeveer het halve internet eruit vrees ik.

Ik weet niet welke partners, maar ik zou geen zaken doen met die partijen.

Prima dat aws standaard server sode encryption aan zet.
Maar als jij als admin public access aanzet, ligt je data gewoon op straat. Unencrypted.

Yikes, ik zou je juist aanraden hetzelfde te doen. SSE is enkel voor data at rest (e.g. het staat encrypted op disk). Wanneer je de api aanroept van S3, en je hebt toegang tot de Bucket omdat er een public access policy actief is, dan decrypt de S3 service het object alvorens het terug te geven.

@BugBoy heeft hier gewoon gelijk. Het is een fout stuk tekst en zou eruit gehaald moeten worden. Het is gewoon compleet onjuist.

De sleutels van AWS KMS liggen bij Amazon en daar kan ik met enkel mijn accountgegevens bij. Als ik dat kan, dan kan AWS het technisch ook. Dat ze het niet zomaar zullen doen zal allemaal vast in policies staan en de boel zal ook wel zo dichtgetimmerd zijn dat de gemiddelde ontwikkelaar/support medewerker niet bij mijn data kan. Ook zal er waarschijnlijk logging plaats vinden wie er toch bij komt (kan je zelf ook inregelen).

Policies zijn vaak procedures waar men zich aan houdt. Dat wil niet zeggen dat het technisch niet mogelijk is. Als Al Qaeda zijn data in AWS S3 buckets met KMS zou versleutelen, dan denk ik dat de NSA vrolijk mee zou lezen.

Ik geef aan dat als je echt wilt dat het helemaal uit het zicht blijft, dan moet je end-to-end versleuteling gebruiken. Mocht jij een document hebben waarin staat dat het niet mogelijk is, dan ben ik erg benieuwd hoe ze dit technisch geregeld hebben. In mijn optiek heeft degene met een sleutel altijd toegang als die zou willen.

Leg eens uit wat je bedoelt. Wat precies klopt niet en waarom?

Idd een grote wasseneus maar doet het goed voor marketing,

Enige manier waar dit bij helpt is als een disk geswapped word omdat die defect is en iemand hem probeert het DC uit te smokkelen,

Maar al deze hardware verlaat het datacenter alleen via de shredder, dus success om daar nog data van af te halen.

[Reactie gewijzigd door Scriptkid op 7 januari 2023 10:02]

Nou niet helemaal een wassen neus. Altijd gevaarlijk een metafoor, maar toch:

Als ik mijn telefoon midden in een café bewaar op een barkruk zonder toezicht, maar vastgemaakt met een ketting, is het wachten totdat iemand mijn telefoon oppakt. En dan is het net iets minder schadelijk als die telefoon beschermd is met een wachtwoord en de persoon die mijn telefoon oppakt in ieder geval moeite moet doen mijn prive informatie in te zien.

Maar uiteraard, als mijn informatie écht interessant is omdat ik een BNer of minister ben, dan is het wachten totdat iemand mijn wachtwoord (encryptie) kraakt dmv brute force en mijn bestanden niet meer prive zijn.

Maar je hebt gelijk, het is nog veel handiger bestanden niet openbaar te hebben staan, de equivalent van je telefoon midden in een cafe laten liggen.

[Reactie gewijzigd door Stpan op 7 januari 2023 11:03]

Ja, leuk geprobeerd maar de kern hier is dat:

- je nooit zult weten van welke buckets er data op een specifieke schijf staat;
- de schijf niet aan een ketting ligt in een café maar pracktisch in ford knox..

Eens, wat een onzin dat stuk tekst.
Het enige wat je met server side encryptie oplost is voorkomen impact van faul play aan de kant van AWS of zijn partners (bv de partij die disks shred aan het einde van hun leven - als ze daar al wat mee kunnen gezien het distributed is)

Enkel client side encryption zou de impact van het openstellen van een s3 bucket minimaliseren.

Dit is inderdaad een flinke misser van Tweakers. Dergelijke datalekken zijn nooit ontstaan doordat de data at rest onversleuteld was, maar omdat de toegangspolicies te ruim waren. En dat verandert niet met deze change vanuit AWS. Dit gaat namelijk puur om encryptie op de harddisks van AWS.

Wat overigens wel flink zou helpen is om een eenvoudigere versie van het permissiemodel standaard te maken. Als je niet weet waar je mee bezig bent is het met de huidige access policies vrij makkelijk om een fout te maken.

AWS is een ramp om te gebruiken, ik heb nog nooit zo'n verwarrende en ingewikkelde interface gebruikt.
Ook met deze S3 buckets encrypten - je kunt het inschakelen, maar het is erg vaag beschreven (documentatie staat op meerdere plekken en vol met warnings) en ik begrijp dan ook goed dat veel buckets openstaan.

Ik geef liever de voorkeur aan andere interfaces en kijk ook uit naar alternatieven die S3-compatibel zijn.
Voor mij dus nooit meer AWS, of het moet al in samenspraak met een andere tool zijn die de API gebruikt.
Ik heb helaas die beslissing niet genomen, maar voor mijn eigen projecten kijk ik wel naar DigitalOcean en Linode - die zijn ook beter in prijs.

Het is eigenlijk onbegrijpelijk dat je buckets open staan en je mag wel enige vorm van bekwaamheid hebben als je met data omgaat. Sterker nog, je moet dingen bewust publiekelijk maken wil je dat andere erbij kunnen. Gewoon als default zijn dingen private.

Verder heb je gewoon veel keuzes en opties. Dat is benodigd omdat er veel use-cases zijn en die zijn allemaal mogelijk mits je weet wat je doet en wilt. Als je niet die rijkelijke functionaliteit hebt, dan loop je tegen beperkingen aan. Dat het dan inherent wat complexer wordt, is geen excuus om dan maar wat te rommelen.

Ik vind dat nieuws outlets en mensen ook te makkelijk steeds de vinger wijzen naar AWS en niet de onbekwaamheid van engineers en organisaties. AWS doet echt onwijs veel om dingen hun gebruikers te beschermen. Zet voor de grap maar eens een aws auth key op github. Dan wordt je door AWS binnen seconden geblokkeerd/genotificeerd dat je auth key publiekelijk is.

Als je goed met je infrastructuur omgaat, dan deploy je ook niet met de hand. Dan gebruik je AWS CloudFormation (of liever Terraform) voor je deployments. Die kan je dan ook veel eenvoudiger reviewen en dan zijn dit soort "ongelukjes" wat minder gebruikelijk.

Maar vaak zie je toch dat een developer even snel wat instelt en dan is beveiliging vaak lastig. Uiteindelijk gaat het naar productie en niemand die er meer naar kijkt. Triest, maar zo gaat het wel vaak. Overigens kennen alle fatsoenlijke object-storages (zoals S3) iets als pre-signed URLs, waarmee je een object tijdelijk "publiek" kan laten downloaden.

Om nog verder te gaan, als je het gewoon goed hebt ingeregeld in je organisatie (waar die documenten dan o zo belangrijk zijn..) dan heb je gewoon policies opgezet door mensen die het wel snappen. Zodoende kunnen non-admin (wat je 'devs' dan zijn) niet eens een bucket aanmaken die public is.
En zelfs dan hoor je gewoon iets van audit/security te doen.

Om wat context te geven, ik kan met mijn standaard account niet eens een public bucket op zetten. Ik kan eventueel na akkoord van "Trust" een public bucket krijgen. En sowieso provisionen we niets met user accounts maar met 'service accounts' zoals je aangeeft.

Daarnaast hebben we diverse alerts binnen AWS, en hebben zelfs queries op shodan staan om te zien als er toch iets per ongeluk fout is gegaan.

Al met al is het allemaal niet zo moeilijk. Je moet er alleen maar om geven en er in willen investeren.

Het probleem is dat in kleine organisaties hier vaak niet de geld, tijd en kennis voor aanwezig is. Vaak is het niet eens onwil, maar onwetendheid.

En daarvoor heb je in Azure , Azure policy,

Dan kun je alleen dat deployen wat compliant is . een policy er over dat storage niet public mag zijn en dan gebeurd het ook niet meer.

Heb je in AWS AWS Config 12-11-2014 voor.
Azure kwam daar bijna 3 jaar later pas mee.

[Reactie gewijzigd door InsanelyHack op 8 januari 2023 00:46]

Hoe kun je dan developers hebben die even snel wat instellen.

Dan snap je het dus zelf niet als it en ku. Je die devs dus niet de schuld geven

Ik snap niet helemaal wat je zegt. Ik denk dat dat heel logisch is. De cloud is enorm agile. Voordat je er erg in hebt is een experimentele deployment productie. Als je een deployment niet door de compliancy-fuik hebt gehaald dan kan je nog zo'n mooi framework hebben om compliant te zijn maar dan mist het zijn doel. Er is ook dan een gevaar dat juist iedereen denkt dat er weinig fout kan gaan om dat juist die protecties actief zijn terwijl ze dat niet zijn. Of zeg ik nu hele domme dingen?

Niet elk bedrijf heeft de kennis in huis om dat in te regelen. Soms is de hele R&D maar een paar man. Dan heb je geen tijd/kunde in huis hiervoor.

Het is eigenlijk onbegrijpelijk dat je buckets open staan en je mag wel enige vorm van bekwaamheid hebben als je met data omgaat. Sterker nog, je moet dingen bewust publiekelijk maken wil je dat andere erbij kunnen. Gewoon als default zijn dingen private.

Dat is helaas niet de default geweest, ze hebben dit al een hele lang tijd geleden aangepast, maar er waren en zijn gewoon ontzettend veel open buckets puur omdat het te moeilijk omschreven was en het niet eenvoudig werd aangegeven.

Ja, de beheerder blijft verantwoordelijk, maar zoals bij veel dingen bij AWS, staan dingen standaard 'niet zo goed'. Je moet er echt kennis van hebben, en dit vergeten de meeste developers.

Ik ben het hier volledig mee eens. Voor mijn baan werk ik ook veel met AWS en binnen de interface krijg je vaak allerlei toeters en bellen als je iets niet handig hebt ingesteld.

Bij S3 specifiek wordt het publiekelijk maken van een bucket aangeduid met rode tekst en waarschuwingsicoontjes overal bij de bucket, met redelijk duidelijke uitleg waarom een bucket publiek maken een slecht idee kan zijn, en ook hoe je dit kan oplossen.

Er zijn ook dingen als de AWS Trusted Advisor die je continu aanbevelingen geven op basis van de instellingen van je resources. Volgens mij heeft IAM ook zoiets, maar de naam ontgaat me op het moment.

Ik werk nog niet lang met AWS (minder dan een half jaar denk ik?), maar ik heb een redelijk idee gekregen van wat wel en niet handig is om te doen en de belangrijkste punten waar je op moet letten bij het opzetten van een nieuwe resource. Als je even nadenkt en de documentatie doorneemt voordat je iets live zet kan je al veel rotzooi voorkomen.

Ik werk (professioneel) veel met AWS en Azure en het is inderdaad niet voor de doorsnee consument bedoeld. Maar de AWS Console vind ik redelijk prettig in gebruik. AWS is absoluut niet bedoeld voor de consument, maar voor de professionele sector. Blijkbaar doen ze dat erg goed, want ze hebben by-far het grootste marktaandeel. In mijn ogen terecht, want AWS is echt rock-solid.

Azure is ook aardig, maar MS heeft er nogal een handje van om het roer af en toe om te gooien. Vooral het feit dat je allerlei speciale code en libraries nodig hebt om code in een orchestrated cluster te draaien is erg vervelend. Eerst Azure Cloud Services (nog uit het Azure Classic) tijdperk en dat kon je later omzetten naar Azure Service Fabric. Dat werktte dan weer niet voor wat oudere ASP.NET MVC software, dus dat moest je ook weer porteren naar een latere ASP.NET MVC versie. Nu gaat het eigenlijk allemaal naar ASP.NET Core en is de overstap naar Linux ook te prefereren (sneller en vooral heel veel goedkoper). Dan wordt ook AKS (Kubernetes) weer interessant en bouw je de code nog maar een keer weer om. Het voordeel van Kubernetes is dat je het dan ook vrij eenvoudig op andere clouds kan draaien (mits je niet afhankelijk bent van allerlei andere Azure services).

Bij AWS is dit soort zaken vaak veel strakker geregeld en wordt er veel minder ge-deprecate. Maar ook AWS heeft zo zijn miskleunen. AWS Cognito (identity management) is zo'n gedrocht. Bugs zijn allemaal by-design en worden nooit aangepakt. Dat verbleekt weer vergeleken met Azure AD.

[Reactie gewijzigd door BugBoy op 6 januari 2023 21:31]

Microsoft heeft Azure en .NET inderdaad in rap tempo geüpgrade. Maar, je hoeft niet over naar nieuwere Azure Services. Azure Cloud Services (Classic) is inderdaad deprecated maar de stekker gaat er pas volgend jaar uit, als je echt geen afscheid kan nemen kun je over op Cloud Services (extended support). Of je dat moet willen is een hele andere discussie.

Ik weet het. Wij gaan voor een oude ASP.NET MVC app toch naar die extended support versie. Je kan wel blijven draaien, maar de architectuur gaat te vaak om. AWS is meer basic en daardoor wat minder gevoelig voor dit soort zaken.

Er wordt hier toch appels met peren vergeleken. Je hebt Azure en AWS beiden bezorgen je de infrastructuur/services die nodig zijn om een service te draaien.
ASP.NET MVC, .Net Core, etc zijn allemaal frameworks dat is iets totaal anders. Dat deze snel veranderd zijn en niet meer gesupporteerd heeft op zich niks met Azure te maken. Je kan ook een ander (stabieler) (open source)framework gebruiken op Azure. Je bent niet verplicht ASP.Net te gebruiken

Azure Service Fabric vereist dat elke applicatie self-hosted is en dus valt ASP.NET MVC 4 af (want dat vereist te draaien vanuit IIS). Bij Azure Cloud Services was dat wel mogelijk, dus bij het overstappen van Azure Cloud Services naar Azure Service Fabric moet je wel zeker code-changes doorvoeren en soms zelfs volledige software migraties.

Daarbij vereisen zowel Azure Service Fabric en Azure Cloud Services speciale entrypoints om je programma te kunnen starten. Daarmee maken ze het nodeloos complex. Kubernetes toont aan dat het veel simpeler kan. Ik zou dan ook niemand aanraden om gebruik te maken van Azure Service Fabric.

10 jaar geleden was ASP.NET MVC 4 helemaal state-of-the-art en het is typische MS om het roer met enige regelmaat helemaal om te gooien. ODBC, OLEDB, ADO, ADO.NET, Linq-2-SQL, EF, EF.Core (voor data-access) en dan heb ik het nog niet eens gehad over de Janboel die ze er van gemaakt hebben op het front-end stuk. Was voorheen redelijk overzichtelijk: Win32, MFC, WinForms, WPF en daarna begon het drama. Nu ook weer met MAUI. Een totaal on-af product, maar al wel Xamarin zo ongeveer doodverklaren. Windows Phone is ook zo'n voorbeeld. Zelfs de doorgewinterde Windows ontwikkelaar wist op een gegeven moment niet meer wat te ondersteunen.

Ik programmeer al sinds 1996 -professioneel- Windows software, maar de laatste jaren lijkt MS toch echt zoekende te zijn. Vooral een front-end bouwen in MS is een drama geworden.

Kijk eens naar oplossingen als CDK of Terraform. Hoef je nooit meer de “geweldige” UI van AWS aan te raken.

Ik ben het eens dat zowel AWS als GCloud een drama zijn om te gebruiken als nieuwe gebruiker. Ze hebben veel te veel mogelijkheden, en dat is zo organisch gegroeid dat er enige logica ontbreekt. Gooi daar eigen marketing termen door en je zoekt je dol.

Wij gebruiken een kloon van S3, niet bij Amazon, en via de API is encryptie zo simpel als een Y/N variabele. Maar goed, wij encrypten serverside en zetten hem daarna pas door, dus de S3 encryptie staat uit.

Daarnaast is het echter ook mogelijk om eigen encryptiesleutels in te zetten, wat SSE-C of Customer heet, of AWS Key Management Service-keys te gebruiken, afgekort SSE-KMS.

Om deze functie gebruiken moet je je eigen sleutel aan Amazon geven.

Amazon zegt dat de feature vooral interessant is voor bedrijven die het belangrijk vinden dat hun AWS-data standaard at rest versleuteld blijft zodat ze een compliance-eisen kunnen blijven voldoen.

Ik ben heel benieuwd wie hier een goed verhaal bij heeft. Welke risico's dek je af door data te versleutelen en de sleutel af te geven aan de partij die de data bewaart? Ik kom niet verder dan het risico dat er een harddisk ongeformatteerd bij het oud vuil belandt. AWS heeft echter al beleid om gegevensdragers veilig af te voeren conform NIST 800-88.

Het zal vooral een feature zijn die je aanzet om aan bepaalde policies te voldoen.

Welke policy dan precies? De policies die ik ken hebben open normen die je zelf in moet vullen. De avg spreekt bijvoorbeeld van "passende technische en organisatorische maatregelen" tegen "ongeoorloofde of onrechtmatige verwerking en tegen onopzettelijk verlies, vernietiging of beschadiging". Als je data versleutelt maar de sleutel ernaast legt, tegen welk risico beschermt die maatregel dan?

Er is meer dan de AVG, zoals PCI DSS waar je aan moet voldoen als je credit-cards opslaat. Maar er zijn nog 1000-en andere policies en er zullen er vast wel een aantal zijn die het verplicht stellen dat de fysieke data-opslag versleuteld moet zijn. Daar voldoe je dan aan. Als de schijf onverhoopt toch op de vuilnisbelt beland (zal niet mogen met de policies van AWS), dan kan je er nog steeds niets mee.

Versleutelen met een sleutel in AWS KMS heeft nog wel enige meerwaarde. Als je toch per ongeluk een andere IAM role (bijv. een ander account) rechten geeft op je bucket, dan kan die er nog steeds niets mee. Je moet dan ook rechten hebben op de juiste KMS sleutel om die data te kunnen gebruiken. Dat is een aparte policy, dus dat kan potentieel nog iets doen.

"Data at rest" - dit dekt af dat de opslagmedia van die buckets, indien gestolen; niet gelezen kunnen worden. Compliance eisen gaan niet alleen over afvoer van spullen als ze aan het eind van hun levensduur zijn, diefstal is daar ook een aandachtpunt.

Alleen is het makkelijker een bank te beroven dan een harddisk uit een datacenter

Er zijn mogelijke nadelen aan deze verandering. Encryptie van data kan overhead toevoegen, aangezien het extra verwerkingskracht vereist en toegang tot data kan vertragen. Bovendien, als een bedrijf zijn eigen encryptiesleutels gebruikt (SSE-C) of sleutels van de AWS Key Management Service (SSE-KMS), is het verantwoordelijk voor het beheren en beveiligen van deze sleutels. Als de sleutels verloren gaan of in gevaar komen, kan het bedrijf niet meer toegang krijgen tot zijn eigen data.

Al met al lijkt het erop dat de voordelen van het inschakelen van server-side encryptie als standaard voor S3-buckets de mogelijke nadelen overschaduwen. Het biedt een extra beveiligingslaag voor data opgeslagen in deze buckets en kan helpen om datalekken te voorkomen.

Het is echter belangrijk voor bedrijven die S3 gebruiken om zorgvuldig hun encryptie-opties te overwegen en de optie te kiezen die het beste aansluit bij hun behoeften en de beveiliging van hun data garandeert