image

Met je hoofd in de wolken

vrijdag 13 september 2013, 12:20 door Homme Bitter, 11 reacties
Laatst bijgewerkt: 24-09-2013, 11:50

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.

Reacties (11)
13-09-2013, 14:11 door Anoniem
Een Public Cloud Systeem waarin deze aspecten zijn geimplementeerd is het Freemove Quantum Exchage Systeem, zie wuala.com/FreemoveQuantumExchange. Een voorbeeld public groep is te vinden op wuala.com/pgpstore . Private groepen werken op dezelfde manier, maar zijn niet zichtbaar op het web.

Vertrouwelijkheid is bijvoorbeeld geimplementeerd met DSA / Elgamal 2048bit Public-Key Encryptie gebruikmakend van True Quantum Randomness. Ook wordt symmetrische informatie-theoretische encryptie met private keys + public true randomness ondersteund.

Integriteit is geimplemteerd doordat er (optioneel) interne en/of externe hashes aangemaakt worden.

Beschikbaarheid is geimplementeerd met gescheiden bron- en kanaalcodering, doordat deze Secure Cloud Storage groepen alleen als communicatie systeem gebruikt worden. De groepsleden hebben altijd de beschikking over de source informatie. Als het cloudstorage systeem niet meer beschikbaar is dan is alleen het kanaal niet meer beschikbaar. De groepsleden kunnen dan elk willekeurig ander kanaal gebruiken om te blijven communiceren, bijvoorbeeld een ander cloud storage systeem.
13-09-2013, 21:03 door schele
Redactie, kan die Wuala spammer hierboven die onder ieder half gerelateerd cloud topic begint te spugen geblocked worden ofzo? Is irritant.

Redelijk informatief artikel verder.
14-09-2013, 11:31 door Anoniem
Door Anoniem: Een Public Cloud Systeem waarin deze aspecten zijn geimplementeerd is het Freemove Quantum Exchage Systeem, zie wuala.com/FreemoveQuantumExchange. Een voorbeeld public groep is te vinden op wuala.com/pgpstore . Private groepen werken op dezelfde manier, maar zijn niet zichtbaar op het web.

Vertrouwelijkheid is bijvoorbeeld geimplementeerd met DSA / Elgamal 2048bit Public-Key Encryptie gebruikmakend van True Quantum Randomness. Ook wordt symmetrische informatie-theoretische encryptie met private keys + public true randomness ondersteund.

Integriteit is geimplemteerd doordat er (optioneel) interne en/of externe hashes aangemaakt worden.

Beschikbaarheid is geimplementeerd met gescheiden bron- en kanaalcodering, doordat deze Secure Cloud Storage groepen alleen als communicatie systeem gebruikt worden. De groepsleden hebben altijd de beschikking over de source informatie. Als het cloudstorage systeem niet meer beschikbaar is dan is alleen het kanaal niet meer beschikbaar. De groepsleden kunnen dan elk willekeurig ander kanaal gebruiken om te blijven communiceren, bijvoorbeeld een ander cloud storage systeem.
Klinkt op zich goed, hoewel dit inderdaad wel erg naar ad-pushing ruikt...

Wel blijven nog steeds een aantal punten openstaan die Homme noemt.
Met name de juridische verplichtingen rond het "verwijderen van data" is een ingewikkeld probleem. Of zijn daar ook maatregelen voor genomen, zodat je zelf volledige controle over al je back-ups hebt?
14-09-2013, 13:25 door Anoniem
Door Anoniem: Een Public Cloud Systeem waarin deze aspecten zijn geimplementeerd is het Freemove Quantum Exchage Systeem, zie wuala.com/FreemoveQuantumExchange.

Dit is alleen maar storage en filetransfer, vergelijkbaar met wetransfer en dropbox. Gegevens bewerken die hier opgeslagen staan is niet mogelijk. Vergelijkbare security is ook met wetransfer en dropbox te bereiken als je op de clients PKI encryptie gebruikt en de ontvanger(s) en zender public keys van elkaar hebben.
16-09-2013, 11:54 door Anoniem
@Anoniem:

> Wel blijven nog steeds een aantal punten openstaan die Homme noemt.
> Met name de juridische verplichtingen rond het "verwijderen van data" is een ingewikkeld probleem.
> Of zijn daar ook maatregelen voor genomen, zodat je zelf volledige controle over al je back-ups hebt?

Voor zover ik uit de documentatie op de gegeven links kan opmaken wordt er alleen encrypte informatie opgeslagen in open of gesloten groepen. In dat geval zijn er volgens mij juridisch geen additionel verplichtingen. De gebruikers zijn daarbij zelf verantwoordelijk voor het beheren van de files in de (open of gesloten) groep.
17-09-2013, 08:15 door Anoniem
@Anoniem:

> Ook wordt symmetrische informatie-theoretische encryptie met private keys + public true randomness ondersteund.

Ik neem aan dat hiermee https://wuala.com/FreemoveQuantumExchange/Aspects/Information/Programs/ITIP/Example bedoeld wordt en met public true randomness bijvoorbeeld de server op http://qrng.physik.hu-berlin.de/
17-09-2013, 13:57 door Patio
Anoniem schreef: zodat je zelf volledige controle over al je back-ups hebt?

Dat heb je toch altijd? Als je een backup maakt heb je daar alle rechten op en kun je mee doen wat je wil. Vernietigen, uitbreiden of gewoon een punt door een komma vervangen in een bedrag en het geheel daarna terugzetten waar het stond. Wel uitkijken met auteursrecht en ander juridisch geneuzel
18-09-2013, 13:42 door [Account Verwijderd]
[Verwijderd]
04-10-2013, 05:50 door Anoniem
Als je je data voor jezelf wilt houden, dan hangt de computer niet aan internet.
Cloudcomputing en 'beveiliging' is dus iets wat per definitie niet samen gaat...
14-10-2013, 16:26 door Patio
Door Anoniem: Als je je data voor jezelf wilt houden, dan hangt de computer niet aan internet.
Cloudcomputing en 'beveiliging' is dus iets wat per definitie niet samen gaat...

Tenzij je alles versleuteld opslaat gecodeerd via een alleen bij jou bekende methode en/of applicatie(s) cq procedure(s). Zelfs het gebruikte besturingssysteem kun je voor jezelf houden.
29-06-2014, 11:32 door Anoniem
Door Anoniem:
Door Anoniem: Een Public Cloud Systeem waarin deze aspecten zijn geimplementeerd is het Freemove Quantum Exchage Systeem, zie wuala.com/FreemoveQuantumExchange. Een voorbeeld public groep is te vinden op wuala.com/pgpstore . Private groepen werken op dezelfde manier, maar zijn niet zichtbaar op het web.

Vertrouwelijkheid is bijvoorbeeld geimplementeerd met DSA / Elgamal 2048bit Public-Key Encryptie gebruikmakend van True Quantum Randomness. Ook wordt symmetrische informatie-theoretische encryptie met private keys + public true randomness ondersteund.

Integriteit is geimplemteerd doordat er (optioneel) interne en/of externe hashes aangemaakt worden.

Beschikbaarheid is geimplementeerd met gescheiden bron- en kanaalcodering, doordat deze Secure Cloud Storage groepen alleen als communicatie systeem gebruikt worden. De groepsleden hebben altijd de beschikking over de source informatie. Als het cloudstorage systeem niet meer beschikbaar is dan is alleen het kanaal niet meer beschikbaar. De groepsleden kunnen dan elk willekeurig ander kanaal gebruiken om te blijven communiceren, bijvoorbeeld een ander cloud storage systeem.
Klinkt op zich goed, hoewel dit inderdaad wel erg naar ad-pushing ruikt...

Wel blijven nog steeds een aantal punten openstaan die Homme noemt.
Met name de juridische verplichtingen rond het "verwijderen van data" is een ingewikkeld probleem. Of zijn daar ook maatregelen voor genomen, zodat je zelf volledige controle over al je back-ups hebt?

Backups van cloud (storage) systemen worden altijd gemaakt. De maatregel welke je als groep kunt nemen is wel of niet encrypt opslaan.

Wanneer je niet encrypt opslaat dan is de data in principe ¨onverwijderbaar¨ geworden omdat backups ook offline bewaard kunnen worden en verwijderde data op een andere server/link op een ander moment teruggezet kan worden.

Alleen wanneer je encrypt opslaat zonder dat de cloud service provider de data kan decrypten is een cloud service provider niet in staat broninformatie terug te zetten.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.