Alles van waarde is weerloos en dat geldt dus ook voor data! Laten we de provider voor het gemak de databewaarder of schatkistbewaarder noemen. Dat betekent dus dat de databewaarder alles, ja alles in het werk moet stellen om goed voor jouw data te zorgen.
We staan met zijn allen aan het begin van cloud-security bewustzijn. Accountants, SaaS-aanbieders en klanten hebben daar allemaal hun eigen rol en eigen taak in. Eerder schreef ik al over transparantere en uniformere informatie ten aanzien van de databeveiliging. De reacties naar aanleiding van dit artikel waren overweldigend. Echter uit de hoek van de SaaS-leveranciers is het veel te stil gebleven, daar is kennelijk meer voor nodig.
In dit artikel wil ik een ander onderdeel van de sla (service level agreement) aansnijden dat eveneens met cloud-security te maken heeft. Het gaat dit keer over de opslag van de data. De data waar je voor verantwoordelijk bent en blijft. Uit de vele reacties blijkt, dat velen dit nog niet wisten en indien zij dit geweten zouden hebben, wellicht beter onderzoek hadden gedaan naar de best bij hun passende provider.
Data is weerloos
Alles van waarde is weerloos en dat geldt dus ook voor data! Dat betekent dat de databewaarder (de provider dus) alles in het werk moet stellen om ervoor te zorgen dat jouw data zo goed mogelijk beveiligd is en zelfs als hij de pijp aan Maarten geeft, je in staat moet stellen deze data weer in bezit te krijgen. Nu zijn er een aantal oorzaken waarom Maarten de pijp kan krijgen: faillissement, stop zetten dienst verlening, de pijp uitgaan van de accountant waar de data op de server stond, etc etera.
Cloud-escrow is (nog) geen officiële term, maar ik beschrijf hier wat de inhoud van cloud-escrow zou kunnen zijn en hoe het zou kunnen werken en verwacht daar natuurlijk jullie reacties op over uitvoering en haalbaarheid.
Iedere kleine databewaarder (provider, waarvan de grootte nader te definiëren is) zou een contract met een data center moeten sluiten, waarbij de onderdelen van de overeenkomst als volgt kunnen zijn:
– Data-eigenaar krijgt toegang tot zijn data door middel van dezelfde interfaces indien de kleine databewaarder in gebreke is gebleven.
– Om dit te bereiken worden data dagelijks en automatisch door de kleine databewaarder namens zijn klant geüpload.
– De prijs van de backup moet zijn inbegrepen in het online abonnement tussen klant en databewaarder (back to back contract).
– Er kan een risicoverzekering afgesloten worden om de gevolgen van de ingebrekestelling op te vangen.
– De datacenters moeten dan wel bereid zijn deze dienst aan te bieden. Maar hoe ga je dan om met dubbele opslag kosten?
Conclusie: risk management en exit strategie.
In een sla mag je verwachten dat er benoemd staat wat er gebeurt met de data in het geval dat de databewaarder in gebreke is gebleven. Met een cloud-escrow zou je veel leed kunnen voorkomen. Check daarom vooraf even de volgende zaken voordat je een contract met een databewaarder afsluit:
– Staat jouw data op meerder fysieke servers op verschillende locaties?
– Beoordeel of je de data weer tot je beschikking krijgt in het geval van discontinuïteit, via ander datacenter of via overdracht naar eigen of nieuwe omgeving.
– Beoordeel of je in dat geval je data op eenzelfde platform bij een andere provider of on premise kunt plaatsen binnen de termijn die je in de sla wordt gegund.
– Check of je de financiële gevolgen van discontinuïteit van de diensten van de databewaarder kunt afdekken bij een verzekeraar.
– Hoe is de communicatie door databewaarder op zijn website over dit onderwerp?
Ik ben het met je eens dat je als afnemer de verantwoordelijkheid moet nemen en eea bij je provider moet gaan checken (via sla of iets anders) Maar ik ben van mening dat dit weinig gaat bijdragen aan de benodigde Risk Management !
Je hebt een aantal vragen gesteld over een aantal punten waar je (onder andere) aandacht aan moet besteden als je gebruik wil maken van een Cloud dienst. Maar er zijn nog meer vragen!
En weet je hoe dat komt? Het komt doordat de Cloud nog niet gestandaardiseerd is! Als ik het over standaardisatie heb dan heb ik het over vele aspecten van deze verandering, afbakken van de grenzen, definities etc . En zolang deze standaardisatie niet gerealiseerd is, blijven we dit soort artikelen over Cloud, met overweldigende reacties erop schrijven.
Gelukkig krijgen de vage kanten van Cloud meer aandacht en grondige aanpak.
FedRAMP is een voorbeeld van dit soort aanpak. Ik verwacht dat er de komende tijd nog meer van dit soort acties voor andere aspecten van Cloud(data management, juridische zaken etc) gerealiseerd worden.
Hierdoor zal het bewandelen van de weg naar deze grote verandering (Cloud) eenvoudiger worden dan wat het nu is. Maar in ieder geval moeten we een iets niet vergeten, ook als de afstand naar Cloud korter is geworden en de standaardisatie gerealiseerd is: het bewust zijn van jij als klant is een MUST!
Andre,
Dat cloud-escrow nog geen officiële term is zit misschien in het feit dat de term cloud nog teveel definities kent. Of dat hier teveel verschillende invullingen aan gegeven worden waardoor het ook moeilijk wordt om Service Level Agreements op te stellen. Want uiteindelijk worden hier wel de rechten en plichten van beide partijen in vastgelegd maar is serviceniveau uiteindelijk vaak moeilijk te beoordelen. Dit komt niet alleen door het ontbreken van standarisatie binnen de verschillende cloud modellen maar vooral en in de eerste plaats door de services en applicaties zelf. Want welke garanties kunnen aanbieders, zeker bij SaaS concepten geven als daar alleen maar onzekerheden tegenover staan?
Stellen dat data onder beheer van een onafhankelijke derde partij komt of in ieder geval de toegang daartoe is geregeld lijkt me ook nogal omslachtig. Ik vraag me namelijk af in hoeverre je als eigenaar de verantwoordelijkheid af kunt wentelen op andere partijen. Eigenaar heeft nu eenmaal verplichtingen die vastgelegd zijn in verschillende wetten. Een vaste prijs voor backup is nog wel haalbaar als dit op vaste frequentie en generiekgaat. Maar er zal een gedifferentieerd prijskaartje zitten aan het veiligstellen van individuele bestanden, mailboxen en databases om gebruikersfouten te herstellen.
Wat je uiteindelijk beschrijft en wilt is op een eenvoudigere manier te behalen zonder concessies te doen aan de voordelen van Cloud. Dat is namelijk alleen de techniek uitbesteden, bijvoorbeeld in de vorm van IaaS of PaaS. Inderdaad zegt Reza een waar woord om te stellen dat er al vele artikelen geschreven zijn en ook nog vele zullen volgen omdat er geen standaard oplossing is. Toch zijn ondanks de wijzigingen in techniek de basisprincipes van service management onveranderd gebleven. Je hebt dus gelijk met je punten maar deze zijn niet uniek voor de Cloud als delivery model en spelen ook bij uitbesteding. En uiteindelijk is een SLA ook maar een stuk papier waar je niets aan hebt als de diensten het niet doen. Leuk misschien om later de schade te verhalen maar vaak is dat een lange juridische weg waar alleen de advocaten beter van worden.
byoc, be your own cloud, zeker als consumer is het cloudgebeuren een mooie integratie met de desktop. Tenzij je natuurlijk net al je data bij MegaUpload bent kwijt geraakt, of op het onbeveiligde dropbox moment alles kwijt geraakt bent, of een ander het ook heeft. Escrow of niet, maar als vergelijk : als ik 100 euro schuld heb aan de bank is het mijn probleem, als ik 100 miljoen schuld aan ze heb is het opeens hun probleem, rara hoe kan dat…..
Cloud Escrow is op 18 november 2011 door Escrow Alliance geïntroduceerd. Zie ook eerder artikel op Computable: ‘Escrow Alliance introduceert Cloud Escrow’.
De hosting branche, verenigd in de DHPA, heeft in samenwerking met ICTrecht en de stichting continuiteit internetdiensten een cloud en hosting escrow model ontwikkeld .
Deze regeling voorziet in volledige continuïteit van dienstverlening in geval van falen van een deelnemer.
ICTrecht heeft hiervoor een in juridisch opzicht unieke en innovatieve oplossing ontwikkeld. De verwachting is dat de DHPA-escrowregeling eind maart 2012 live gaat.
Cloud-escrow en risk management, misschien dat ik dat inderdaad duidelijker had kunnen verwoorden. Als je er voor kunt zorgen dat je data toegankelijk/opvraagbaar en elders op te slaan is als je huidige databewaarder er tussen uitvalt, dan heb je voor dat punt je risico van data verlies gemitigeerd.
Dat kan daardoor dus onderdeel zijn van je risk management. Een situatie zoals zich bij Mega-upload voordeed, was dan voor de gebruikers die te goeder trouw hun data daar hadden staan niet te voorkomen, omdat niet duidelijk is wat de intenties van Mega-upload werkelijk zijn geweest.
Het onderstreept daarmee wel mijn opmerking dat je vooraf je de databewaarder moet onderzoeken tot het niveau dat voor jou mogelijk is om te onderzoeken.
@Andre,
Ten behoeve van risk management, ga ja je huisarts checken voordat je huisarts je gaat checken?? Of vertrouw je hem omdat hij de vergunning heeft anders had hij de praktijk niet mogen opzetten?
Cloud is gebaseerd op ‘ontzorgen’! Je geeft aan dat ik t.b.v. risk management ervoor moet zorgen dat mijn data ook ergens anders beschikbaar moet kunnen zijn als mijn leverancier uitvalt! Als dit zo is dan zal ik je nog een rij van componenten en zaken geven die je nog bij andere leverancier beschikbaar moet stellen als je provider uitvalt(dus niet alleen je data).
Dit is geen ontzorging en niet de bedoeling van cloud.
Zoals eerder besproken, om deze ellende te voorkomen moet cloud gestandaardiseerd worden! Dit betekent dat de leveranciers (zoals je huisarts) aan bepaalde eisen moeten voldoen (capaciteit, betrouwbaarheid, juridische zaken, beveiliging, kennis, etc) voordat ze zich cloud provider mogen noemen. Hierna kan ik als klant gerust mijn ict aan hen overlaten. Deze regels moeten ervoor zorgen dat niet elke willekeurige cloud provider als paddenstoel uit de grond komt.
@Reza, in een omgeving die volwassen is, hoef je dat niet te doen, dat ben ik dus met je eens. Zo zijn er meer dingen waar ik het met je eens ben. De Cloud is nog niet volwassen en er is op dit moment nog sprake van risico’s zoals dat bij een kleine ict er met enkele servers die voor jou de data beheert, of een accountant die boekhoudingen van kleine ondernemers op zijn servers uitvoert. Ze doen dat met een predicaat Cloud computing omdat dat zo lekker klinkt.
We moeten inderdaad toe naar standaardisatie en keurmerken waarop de klant mag vertrouwen, met als aanvulling dat de certificaten met een interval van bijvoorbeeld 3 maanden door externe partijen worden getoetst en de resultaten daarvan opvraagbaar zijn. Er zijn op dit moment ontwikkelingen inzake de standaardisatie die verder gaan dan ISAE 16 en binnenkort worden gepubliceerd.
Zou je, inhakend op jouw opmerking, een certificaat zoals bijv ISAE 16
gelijk willen schakelen aan een vergunning om SaaS en overige Cloud diensten te leveren???
Ontzorging is goed en doel, maar er moet nog veel georganiseerd worden.
Risk management zie ik absoluut breder en dit is slechts 1 facet dat ik belicht heb.
Office 365 heeft nu twee weg authenticatie http://t.co/ESriiy2c, weer een goede stap in beveiliging van data in de cloud.