Werken in de cloud biedt aanzienlijke voordelen voor bedrijven, maar brengt ook nieuwe risico’s met zich mee die vaak buiten het bereik van de gebruikelijke cybersecurity vallen. Ook zorgt het beveiligen van virtuele machines, containers, Kubernetes- en serverloze workloads in openbare, private of hybride clouds voor meer complexiteit. Dit vraagt om meer inzicht. Maar hoe is die kennis het best te verkrijgen?
Cloudbeveiliging is het onderdeel van cybersecurity dat specifiek gericht is op het behoud van de vertrouwelijkheid, integriteit en beschikbaarheid van gegevens, applicaties en services op servers die geheel of gedeeltelijk worden beheerd door een of meerdere externe partijen. De eigenaar van de data heeft geen controle over én geen toegang tot de onderliggende hardware.
Ook vindt de communicatie doorgaans plaats via het openbare internet. Hierdoor gelden andere risico’s voor cloudbeveiliging dan bij het beheren van data op een eigen on-premises-server. Bovendien brengen de huidige containers die virtuele servers hebben vervangen – Docker en Kubernetes – hun eigen unieke beveiligingsuitdagingen met zich mee. Vanwege dit verschil in it-architectuur moeten organisaties bij cloudbeveiliging rekening houden met een aantal aspecten:
- Cloudprovider
- Gebruiker (eigenaar van de data)
- (Data)communicatie tussen de cloudprovider en de gebruiker
- Containersoftwarestack
Welke uitdagingen levert dit op?
Gartner voorspelt dat de grootste dreiging voor cloudbeveiliging in de komende jaren ontstaat door ‘wanbeheer van identiteiten, toegang en rechten’. Er wordt verwacht dat tegen 2023 minimaal de helft van alle incidenten hier zijn oorzaak in vindt. Daarnaast vormen kwetsbaarheden of een verkeerde configuratie van de containerstack zelf (container escapes) een technische uitdaging, zeker als het beveiligingsteam weinig ervaring heeft met Docker- en Kubernetes-technologie.
Van een gerenommeerde provider mag verwacht worden dat de gegevens opgeslagen zijn in geïsoleerde databases en dat de tenants van elkaar worden afgeschermd. Toch kan het voorkomen dat er een kwetsbaarheid in de computerstack ontdekt wordt, die een aanvaller in staat stelt om privé-clouds te compromitteren, zoals CVE-2020-3056. Op dat moment is er een aantal belangrijke vragen dat beantwoord moet worden door het beveiligingsteam. Zo is het nuttig te achterhalen wat er gebeurt met de workloads. Daarnaast is er een inventarisatie te maken van welke tools beschikbaar zijn om te waarschuwen voor onbevoegde toegang of om containers te doorzoeken op mogelijke dreigingen nu de kwetsbaarheid aan het licht is gekomen.
Hoe verbeter je cloudsecurity?
De hierboven genoemde uitdagingen zijn alleen op te lossen met een goed inzicht in en controle over de gecontaineriseerde workloads. De oplossingen voor workload-beveiliging moeten ook lichtgewicht zijn om geen invloed te hebben op de prestaties. Hierbij zijn functies als een veilige externe shell, node firewall control, netwerkisolatie en het ophalen van bestanden ook zeer handig.
Pre-runtime-beveiligingen die zowel de host scannen als ervoor zorgen dat deze en het containerbeeld infectievrij zijn, blijven belangrijk. Deze vorm van beveiliging is echter niet toereikend, omdat ze de container niet kunnen beschermen tegen aanvallen zodra deze in gebruik is. Ze bieden ook geen mogelijkheden voor een soc-team om op jacht te gaan naar dreigingen of een incident respons te plegen.
Om de client voldoende bescherming te bieden, dien je ook, los van een betrouwbare endpoint-beveiliging op de communicerende apparaten, de gebruikerstoegang optimaal te beheren en te vergrendelen. Het toestaan van beheerders en andere onnodige gebruikers op cloudplatforms is vragen om een datalek. Specifieke oplossingen zoals identity and access management (iam) en role-based access control (rbac) bieden uitkomst.
Voor het beschermen van de communicatie tussen de cloud en de client zijn er in ieder geval twee zaken belangrijk. Allereerst dienen de data zowel in rust als tijdens het communicatieverkeer versleuteld te zijn. Ook moet er een plan klaarliggen voor de operationele continuïteit in geval van een denial of service aanval.
Conclusie
Natuurlijk moet je erop kunnen rekenen dat elke gerenommeerde cloudprovider zijn eigen beveiligingsverantwoordelijkheden serieus neemt. Maar naarmate er meer externe apparaten en personen bij betrokken zijn, wordt ook het aanvalsoppervlakte groter. Bovendien kan het voorkomen dat de containers die zelf worden geïmplementeerd bugs, verkeerde configuraties of andere kwetsbaarheden bevatten. Om de beveiliging van cloud-workloads te garanderen, is het daarom belangrijk dat een beveiligingsteam op de hoogte is van deze dreigingen, bijvoorbeeld middels een geschikte beveiligingsoplossing voor container-workloads.
“De eigenaar van de data heeft geen controle over én geen toegang tot de onderliggende hardware.”
Ik meen me te herinneren dat het economische eigendomsrecht van de datadrager grotendeels bepalend is voor de juridische rechten op de data. Jouw data op mijn computer is mijn data als deze niet op enigerlei wijze beschermd is middels rechten zoals het auteursrecht. Als IT-er kijken we vaak niet verder dan de technische risico’s maar zoals al een keer uiteengezet in een opinie zijn er nog wat andere gevaren waar je rekening mee moet houden bij de cloud.
@oudlid
De wetgeving loopt achter de actualiteit aan. De wetgeving waar jij naar verwijst, is nog uit het pre-cloud tijdperk.
Wellicht moet het eigendomsrecht worden aangepast, en moet het eigendom van de gegevens worden losgekoppeld van de fysieke gegevensdrager. Zodra iets in de cloud staat, is het, zeker voor de gebruiker, totaal niet duidelijk waar iets staat.
Er zijn wetten die cloudaanbieders dwingen om hun opslag in een bepaalde regio te hebben. Europese gegevens mogen bijvoorbeeld niet op Amerikaans grondgebied opgeslagen zijn, zodat de Amerikaans inlichtingsdiensten er geen toegang toe hebben. Dus “onze” data staat “veilig” in Europa opgeslagen, maar waar precies is niet duidelijk.
Neem bijvoorbeeld Apple’s iCloud. Apple heeft zelf opslagfabrieken, maar maakt ook gebruik van Amazon. Van wie is jouw iPhone backup, van jou, de gebruiker, van Apple, de dienstverlener die jou iCloud opslag verkoopt, of van willekeurig Apple of Amazon, het bedrijf dat “jouw” bits op een harde schijf heeft gezet?
Wil je het eigendomsrecht van gegevens en loskoppelen van gegevensdragers, dan zou encryptie een eis moeten zijn: de eigenaar van de gegevensdrager mag niks zinnigs met de gegevens kunnen doen.
Frank,
Zeker loopt allerlei wetgeving achter op technologische ontwikkelingen maar zolang deze (in het land waar je zaken doet) nog geldig is kun je er niet aan voorbij gaan. Niet alleen in welk land je data opgeslagen wordt is interessant maar ook door wie. Encryptie van data in ruste is vooral een maatregel tegen ongeautoriseerde toegang als je zelf de sleutels hebt want het eigendomsrecht van de data verschuiven naar de sleutels geeft je nog geen operationele continuïteit. Data portabiliteit middels een back-up is al een goede stap maar misschien moet je deze niet alleen technisch scheiden om zo een ongewenste versleuteling te voorkomen maar ook organisatorisch middels een ‘data-escrow’ zodat je uiteindelijk dus een service portabiliteit hebt.
Frank, economisch eigenaarschap van de datadrager en juridische rechten op de data zijn al in grote mate losgekoppeld van elkaar. Denk maar aan een cd met software code of een databank, en het gebruiksrecht van de softwarecode of die databank.