Cloudcomputing is iets waar je tegenwoordig niet alleen maar van hoort, maar wat je bij veel bedrijven ook ingevoerd ziet worden. Omdat je bij cloudcomputing op een andere manier met je gegevens en bedrijfsvoering omgaat, is het wel nuttig om ook te kijken naar de andere eisen die je dan aan je security moet gaan stellen.

Om dit artikel nog een beetje leesbaar te houden, wil ik het beperken tot gebruik van "public" cloudfaciliteiten. Wat je in je eigen datacenter doet, of tussenvormen, laat ik buiten beschouwing. Onder cloudfaciliteiten beschouw ik niet alleen "virtual machines" maar ook het gebruik van diensten van externe partijen, zoals dropbox, webmail, Office365, back-ups, (mongoDB) databases en dergelijke.

Wat betreft security wil ik de drie volgende pijlers bekijken: Vertrouwelijkheid, data-integriteit en beschikbaarheid. Je wilt kunnen bepalen wie wel en niet bij je gegevens kan, zowel binnen je eigen organisatie als bij de leverende partij. Je wilt er op kunnen vertrouwen dat je gegevens kloppen en dat de bewerkingen die je er in de cloud op uit voert ook goed gedaan worden. Beschikbaarheid klinkt misschien als een buitenbeentje, maar als je bedrijfsvoering onderuit gaat omdat je cloud niet beschikbaar is doordat iemand iets heeft gesaboteerd, loop je schade. Dat maakt het een risico wat je moet meenemen in je plannen. Als laatste wil ik ook de juridische dingen die een raakvlak hebben met je security bekijken.

Vertrouwelijkheid

Het grote verschil met je eigen systemen gebruiken en de "public cloud", is dat je gebruik maakt van diensten van andere partijen, die ook jouw gegevens op en over hun platform hebben lopen. Je wilt dus zeker weten dat die gegevens niet ergens terecht komen waar ze niet horen. Dat kan zijn omdat je daar volgens wet- en regelgeving in beperkt wordt, of omdat je aan certificeringen moet voldoen zoals ISO 27000, of omdat je dat van een beurswaakhond moet doen. Het kan ook zo zijn dat je niet wilt dat je concurrent bij je spulletjes kan, of omdat je denkt dat de NSA of de Chinese overheid of zo met jouw gegevens aan de haal gaat en die aan je concurrent geeft.

Ongeacht wat voor jou precies de motivatie is, je wilt je data classificeren en kijken langs welke paden en op welke systemen je data kan verschijnen. Soms kan je je data versleutelen, zodat iemand die je data kan lezen er niets aan heeft, maar soms kan je je data niet versleuteld houden, bijvoorbeeld omdat je er bewerkingen of zoekacties op los laat. Als jij een versleutelde verbinding opzet met een database die in de cloud draait, is er onderweg misschien niets af te luisteren, maar op de databaseservers staat je data onversleuteld. Als daar iemand een kopie van kan trekken, omdat hij je cloudprovider hackt, of omdat je data in een land staat waar de overheid zomaar kopietjes mag maken, ben je alsnog kwetsbaar. Kijk dus goed naar hoe en waar je data staat en bepaal vooraf of dat met je eisen en wensen in overeenstemming is.

Integriteit

Wat voor je eigen systemen geldt, geldt ook voor een cloudprovider. Omdat je in de cloud vaak kiest voor clusteroplossingen, moet je opletten dat je daardoor geen corruptie krijgt in je gegevens. Als je gegevens op een enkele server staan die altijd op dezelfde plek in je eigen datacenter hangt, is het makkelijk om te zien of ze beschikbaar zijn en weet je van te voren hoe en wanneer ze verwerkt en bewerkt worden. In een cluster kan het maar zo zijn dat er meerdere servers met dezelfde gegevens zijn uitgerust en als die niet goed synchroniseren, of traag zijn in hun synchronisatie, kan je rare gevolgen krijgen. Je zal daar in het ontwerp van je programmatuur rekening mee moeten houden.

Beschikbaarheid

Als je er voor kiest om die ene server uit te besteden en hem enkel te houden, heb je dat probleem niet, maar dan heb je nog steeds die ene server waar je afhankelijk bent. Als de hardware waar die dienst op draait stuk gaat, of er is een netwerkprobleem, dan is je dienst niet beschikbaar. Dan ben je ineens afhankelijk van niet alleen je eigen infrastructuur, maar ook die van je internetprovider en van je cloudprovider. Het kan misschien goedkoper zijn om zo'n oplossing te kiezen, maar je risico op uitval is groter dan als je de server zelf beheert in je eigen omgeving. Zelfs als je er voor kiest om je platform op te bouwen als een cluster, kan je nog steeds uitval krijgen als je gebruik maakt van clouddiensten. Er zijn genoeg voorbeelden van het uitvallen van een heel datacenter van grote cloudproviders, waardoor klanten die geen "geografische spreiding" hadden ingekocht alsnog zonder dienst zaten. Je eigen internetverbinding kan ook onderuit gaan. Ook hier moet je rekening mee houden.

Je plaatst een vitaal deel van je bedrijfsvoering onder beheer van een andere partij. Als die partij niet betrouwbaar blijkt, moet je er voor zorgen dat je daar maatregelen tegen hebt getroffen. Je kan je niet permitteren dat je ineens zonder je gegevens en dienstverlening zit als je leverancier om wat voor reden dan ook stopt. Als je je gegevens nog wel ergens in een back-up hebt, zal je ook binnen bepaalde tijd weer je systemen draaiend moeten hebben. Houdt er rekening mee dat dingen fout kunnen gaan en dat je dan direct een alternatief moet gaan hebben. Verzin scenario's die kunnen voorkomen en probeer in je plannen er voor te zorgen dat deze scenario's je niet verrassen en je -binnen grenzen- de risico's afdekt of mitigeert.

Juridisch

Je hebt vaak gegevens van anderen op je systemen staan. Soms moet je deze gegevens wissen of mensen inzage geven welke gegevens je van ze hebt en waar ze precies staan, dat is wettelijk nou eenmaal zo geregeld in Nederland. Als jij gegevens op een cloud hebt staan, moet je ook kunnen vertellen waar ze staan en zeker maken dat alle kopieën gewist of aangepast zijn. Als een cloudprovider back-ups maakt of je niet vertelt hoeveel kopieën er van jouw gegevens zijn, of waar ze staan, kan je niet aan die verplichting voldoen. Het zal niet zo'n vaart lopen over het algemeen als het gaat om wissen of corrigeren van gegevens in back-ups, maar er zijn gevallen te bedenken waarin dit belangrijk is. Zorg er voor dat je weet wanneer dit van toepassing is in de plannen die je maakt.

Omdat je niet meer de enige partij bent die een platform met gegevens er op beheert, wordt aansprakelijkheid en verantwoordelijkheid ook complexer. Als er een incident is, zal je moeten kijken wie er aansprakelijk is voor schade, wie er verantwoordelijk is voor het oplossen en voorkomen van dingen en je zal moeten zorgen dat je dit duidelijk omschreven hebt. Je wilt het van te voren al duidelijk hebben, want bij een incident moet je geen tijd of geld kwijt raken om je platform weer draaiende te krijgen. Een stukke server of een gehackt platform kan je ook op je eigen infrastructuur gebeuren, maar wie het moet oplossen en wie de schade betaalt kan heel anders worden als je platform op een public cloud draait. Dit is geen verrassing, maar het kost wel tijd en geld om goed geregeld te krijgen.

Samengevat komt het er op neer dat je migratie naar de cloud meer inhoud dan al je servers virtueel maken en ze bij een hostingpartij onder brengen. Je krijgt te maken met allerlei veranderde beveiligingseisen. De beschikbaarheid en betrouwbaarheid van de extra lagen die je door de cloud krijgt, hebben hun eigen aandachtspunten. Er zijn allerlei extra juridische dingen bij gekomen die je ook goed moet aftikken. Het kan in veel gevallen een prima verbetering zijn voor je omgeving, maar denk vooral goed na en laat mensen met verstand van zaken je plan nakijken voordat je van start gaat. Als je met je hoofd in de wolken zit, moet je wel zorgen dat je voeten stevig op de grond blijven staan.

Dit artikel is geschreven op persoonlijke titel van de auteur en reflecteert niet noodzakelijk de zienswijze van Security.NL.