De afgelopen jaren is het aantal datareguleringen wereldwijd aanzienlijk gestegen – net als de hoogte van de boetes die toezichthouders kunnen opleggen. Toch nemen meldingen van datalekken uit de cloud met de dag toe – zowel in aantallen als in omvang.
Lekkende Amazon Web Services (AWS) S3-buckets zijn een van de meest voorkomende plaatsen delict voor onbeveiligde data in de cloud. Een bucket is een opslagbron in AWS’ S3-opslagdienst, die zowel databestanden als hun respectievelijke beschrijvende metadata opslaat. Het probleem is dat hierbij te vaak sprake is van verkeerd geconfigureerde toegangsrechten, waardoor de data openbaar toegankelijk wordt.
U kunt zich voorstellen dat het hierbij gaat om zeer uiteenlopende gegevens. Een recent incident haalde de kranten omdat een bepaald softwarebedrijf gevoelige data van meerdere marihuanaverstrekkers in de Verenigde Staten én informatie over klanten van de drug had blootgelegd. De gelekte data bestond uit persoonlijke gegevens van klanten en medewerkers, wat neerkwam op persoonlijk identificeerbare informatie (PII) van meer dan 30.000 personen. De onbeveiligde Amazon S3-bucket werd voor het eerst ontdekt op de avond vóór Kerst en werd pas op 14 januari gesloten.
Dezelfde onderzoekers die het marihuanalek ontdekten, vonden ook een onbeveiligde AWS-bucket die eigendom was van een onbekend bedrijf uit het Verenigd Koninkrijk. De data bestond uit zeer gevoelige bestanden van meerdere Britse adviesbureaus, met gedetailleerde informatie over duizenden Britse professionals. Die gegevens bestonden uit scans van paspoorten, belastingdocumentatie, sollicitaties inclusief referentiechecks en strafbladen, en adresbewijzen. In dit geval hadden de hackers moeite om de eigenaar van de AWS-bucket te achterhalen en er contact mee op te nemen, waardoor ze het lek direct hebben moeten doorgeven aan AWS en het Britse Computer Emergency Response Team (CERT-UK), de organisatie die verantwoordelijk is voor het monitoren van en het omgaan met databeveiliging in het VK.
Een Brits reclameproductiebedrijf reageerde veel sneller. Deze organisatie handelde zeer snel om een AWS S3-bucket met een breed scala aan productiebestanden van hun werk voor grote klanten, waaronder Unilever-merk Dove, veilig te stellen. Zodra het bedrijf op de hoogte was van het probleem, werd openbare toegang tot de bucket gesloten, ook al denkt men dat de data al toegankelijk was sinds 2018. Dit lek bestond uit meer dan 1.500 bestanden met gevoelige data waaronder bankgegevens en scans van paspoorten van (onder meer) deelnemers van Dove’s ‘Real Strength’-campagne voor mannen – meer exposure dan zij verwacht hadden toen ze tekenden om hun oksels aan de wereld te laten zien…
Het is nog de vraag of deze ontdekkingen zullen leiden tot GDPR-boetes. Maar gezien de frequentie van deze issues hebt u vast medelijden met degenen die verantwoordelijk zijn voor het beoordelen van elk datalek.
De voorbeelden zijn eindeloos. Wat veroorzaakt dan dit op het oog eenvoudige issue van organisaties die bestanden openbaar laten?
Het vierde Cloud Security Alliance Top Threats rapport (2019) toont aan dat cybersecurity-professionals niet blind zijn voor het probleem. 241 experts uit de branche noemen datalekken, verkeerde configuratie van cloudinfrastructuur en een gebrek aan cloud security infrastructuur en strategie als top drie risico’s van cloudgebruik. Toch begrijpen te veel organisaties nog te weinig van het model van gedeelde verantwoordelijkheid en de implicaties daarvan. Gedeelde verantwoordelijkheid legt vast waar de verantwoordelijkheid van de cloudserviceprovider ophoudt (beveiliging ‘van’ de cloud), en waar de verantwoordelijkheid van de klant begint (security ‘in’ de cloud). Een klein voorzetsel maakt een groot verschil!
Nieuw onderzoek van het Ponemon Institute toont aan dat slechts 32 procent van de organisaties gelooft dat het beveiligen van data in de cloud hun eigen verantwoordelijkheid is. In veel gevallen wordt deze gedeelde verantwoordelijkheid nog verder vertroebeld door de complexiteit van de leveringsketen, zoals we in de hiervoor genoemde voorbeelden zagen. Het is vaak de derde partij die alle noodzakelijke maatregelen had moeten nemen om de data ‘in’ de cloud te beveiligen – niet de eigenaar van de data. Er is maar al te vaak sprake van impliciet vertrouwen, wat misplaatst blijkt te zijn – met alle gevolgen van dien. Deze lekken worden een extra bevestiging dat beveiliging van de leveringsketen een kernelement van een securitystrategie moet zijn. En de cloud security strategie is hier geen uitzondering op.
Openbaar toegankelijke S3-buckets zijn geen fout van AWS – ze zijn vaak het resultaat van een fout door de eigenaar van de bucket. Amazon biedt AWS-gebruikers gedetailleerde instructies om hen te helpen S3-buckets te beveiligen, dus speelt educatie een belangrijke rol in het overwinnen van cloud security problemen. Maar er zijn ook diverse tools die het instellen van beleidsregels voor cloudgebruik kunnen automatiseren en gebruikers kunnen opleiden tijdens hun gebruik. Deze tools zijn over het algemeen vrij eenvoudig en maken gebruik van vooraf gedefinieerde regels om data in de cloud te vergrendelen. De oplossing voor onbeveiligde AWS-buckets is echt eenvoudiger dan het op het eerste oog lijkt.
Ondanks de snelheid waarmee organisaties nu naar de cloud verplaatsen, zijn security-mindsets en -strategieën (in een notendop: het concept van perimeter) nog steeds gefocust op een on-premise security perimeter. In het verleden vroegen we mensen om alstublieft geen post-its op hun scherm te plaatsen met daarop een wachtwoord dat voor het hele kantoor zichtbaar was. Mijn zesde zintuig vertelt mij dat dat probleem niet is verdwenen, maar nu verbleekt in vergelijking met de blootstelling van hele datasets in publiekelijk toegankelijke cloudbuckets.
