Cloud Soevereiniteit: wat betekent dit nu eigenlijk?

De definities

Laten we beginnen met de definitie van soevereiniteit. Volgens Wikipedia is soevereiniteit het recht van een bestuursorgaan om het hoogste gezag uit te oefenen, zonder dat het daarover verantwoording hoeft af te leggen aan een ander orgaan. In moderne staten wordt dit vastgelegd in de grondwet: de basisafspraken over het handelen van die staat. Zet je dit in een internationale context, dan betekent het dat landen elkaars grenzen respecteren en dat elk land zelf beslist over wat er binnen die grenzen gebeurt. Simpel gezegd: andere landen mogen zich niet bemoeien met binnenlandse aangelegenheden.  

Het woord bemoeien is hierin interessant, want dit is ook relevant als we het hebben over Cloud.  

Er is veel te zeggen over wat Cloud precies is, welke vormen er zijn en waarom het zo’n populair begrip is geworden. Dit lees je ook in o.a. dit blogartikel. Voor nu beperken we ons tot de betekenis van Cloud binnen de context van soevereine Cloud: een plek waar data wordt opgeslagen en verwerkt. Als we dat combineren met soevereiniteit, dan komt het erop neer dat data op een plek landt waar de bemoeienis over die data duidelijk is.  

En die data speelt een rol in vrijwel alles wat we dagelijks doen: van apps op je telefoon en formulieren op websites, tot videovergaderingen binnen je organisatie. Al die toepassingen genereren data en die data belandt uiteindelijk in de Cloud.  

De belofte van de Soevereine Cloud

Steeds meer leveranciers claimen dat ze een ‘Soevereine Cloud hebben: een omgeving waarin jouw data opgeslagen en verwerkt wordt, zonder inmenging van derden. Maar is dat daadwerkelijk zo? Is er een certificering, een norm, of een toetsbare manier om vast te stellen of je data echt beschermd is tegen ‘bemoeienis’ van buitenaf? Om dat goed te kunnen bepalen, is het belangrijk om te begrijpen hoe data in een Cloud landt. Waar komt het binnen? Welke lagen doorloopt het? En wie heeft allemaal toegang?

Het pad van data binnen de Cloud

Wanneer je kijkt naar hoe data zich in de Cloud beweegt, zie je al snel dat die niet zomaar ergens ‘landt’. Data legt een route af, via verschillende lagen en componenten, voordat het uiteindelijk wordt opgeslagen en verwerkt. Dit data-pad kun je goed inzichtelijk maken met een gelaagd model, vergelijkbaar met het bekende OSI-model dat wordt gebruikt voor datacommunicatiestandaarden.  

In de context van een Soevereine Cloud biedt zo’n gelaagd model een nuttig kader. Per laag kun je namelijk toetsen in hoeverre er sprake is van bemoeienis, oftewel: wie heeft de controle, toegang of invloed op die specifieke laag?  

In Figuur 1 is het data-pad visueel weergegeven: van de gebruiker tot aan de applicatie die draait in de Cloud. Daarbij zijn de verschillende onderdelen van de Cloud-omgeving benoemd, zodat per stap bekeken kan worden waar data wordt verwerkt en wie daar mogelijk bij kan.  

Figuur 1. Visuele weergave van datapad

‍

Bovenstaande figuur toont 10 lagen van Cloud waarin data wordt verwerkt. Hieronder wordt elke laag toegelicht.

Laag 1 - Transport

Het pad dat data aflegt in de Cloud, begint bij de gebruiker. Via een apparaat, zoals een laptop of smartphone, wordt data gegenereerd en verstuurd. Ook Internet of Things (IOT)-apparaten, zoals slimme auto’s, beveiligingssystemen of home-automation oplossingen kunnen zelfstandig data versturen. Vanuit deze bronnen wordt data getransporteerd naar de Cloud. In de meeste gevallen gebeurt dat via het publieke internet. Maar in sectoren waar veiligheid en betrouwbaarheid cruciaal zijn, zoals defensie, worden vaak besloten netwerken of eigen infrastructuren gebruikt. Maar eenvoudiger is ook mogelijk: hoe vaak kom je niet een project tegen op een industrieterrein waar glasvezel wordt aangelegd. Deze glasvezelverbinding kan ook gebruikt worden om een lokaal bedrijfspand direct te verbinden met een datacenter en daarmee datatransport te realiseren zonder gebruik van internet. Dit verhoogt de beveiliging aanzienlijk.  

Laag 2 - Data transport – Cloud Edge

Na het transport komt de data aan bij de zogeheten Cloud Edge: dit is het koppelpunt van de specifieke Cloud. Bij koppeling via het internet verloopt dit vaak via een edge-router van de Cloud-provider, met protocollen zoals BGP. Bij private, specifieke verbindingen is dit vaak via een ‘meet-me-room' in een datacenter, waar een fysieke lijn wordt afgemonteerd en gekoppeld wordt met de edge routers van de Cloud-provider.

Laag 3 - Data localiteit in datacenter

Vanuit de Cloud Edge wordt de data verder verspreid binnen de infrastructuur van de Cloud-provider. Die infrastructuur bestaat uit verschillende availability zones en datacenterlocaties. Dit kan zowel regionaal, maar ook internationaal zijn. Zeker bij de grotere hyperscalers geldt dat er internationaal gewerkt wordt en er dus sprake kan zijn van een veel verspreide localiteit van data.

Laag 4 - Applicatie

De applicatie die de data presenteert en verwerkt is in functionele zin een verwerker van de getransporteerde data. Aangestuurd door een gebruiker of procedure, vormt de applicatie een uitwisselaar van data.

Laag 5- Middleware  

Een applicatie vereist verschillende onderdelen, denk aan een database, specifieke applicatietalen zoals PHP, maar ook modules als een webserver of een loadbalancer. Al deze onderdelen zijn ter ondersteuning van de applicatie en zorgen dat data op een bepaalde manier verwerkt wordt.

Laag 6 - Operating System of Container

Voor het kunnen draaien van een applicatie en middleware is een operating system vereist. Dit operating system zorgt ervoor dat de fysieke rekenkracht (RAM en CPU) met opslag (harddisk) gebruikt kan worden voor het verwerken van alle data en operaties door de middleware en applicatie. Wanneer functionaliteit verder is gespecificeerd kan de middleware met applicatie worden samengevoegd in een container; die ook vanuit een orchestratie zorgt voor de koppeling aan de fysieke rekenkracht en opslag.

Laag 7 -Virtualisatie | Containerisatie | Bare metal

Het operating system of de container kan worden gevirtualiseerd. Met virtualisatie worden de fysieke rekenkracht en opslag verder opgedeeld in virtuele rekenkracht, waarmee er meerdere instanties van een operating system of container gebruik kunnen maken van dezelfde fysieke infrastructuur. Bij een zogenaamde bare metal toepassing, wordt de fysieke infrastructuur direct vanuit één operating systeem aangesproken.

Laag 8 - Hardware: Netwerk

De netwerkinfrastructuur bestaat uit routers, firewalls en switches die verschillende dataverbindingen leggen en zorgen voor transport vanuit de Cloud Edge naar de fysieke infrastructuur waarmee de verschillende lagen worden aangesproken. Deze apparatuur transporteert en verplaatst daarmee data.

Laag 9 - Hardware: Compute

De compute hardware vormt de uiteindelijke verwerkingskracht van Cloud. Men zegt wel vaker dat Cloud gewoon iemand anders zijn computer is, en in wezen is dit ook zo. Zonder de uiteindelijke server met compute bronnen kunnen een applicatie, operating system en dataverwerking niet plaats vinden.

Laag 10 - Hardware: Opslag

De opslag hardware zorgt voor het vastleggen van de data die niet tijdelijk is (die wordt immers in de compute t/m applicatielaag verwerkt). Deze opslagsystemen zijn de meest concrete en tastbare vorm van het opslaan van data in de Cloud. Wanneer je weet welk apparaat jouw Clouddata opslaat, kun je daarmee jouw data ‘aanraken’ en dan weet je waar precies ‘in de Cloud’ je data staat.

Vanuit bovengenoemde 10 lagen is te zien welk pad data volgt. Maar weten we daarmee precies de bemoeienis en daarmee de mate van soevereiniteit? Nee, want techniek is een oplossing, die als dienst – wat Cloud voor de eindgebruiker is – wordt aangeboden.

De operatie achter de techniek

Achter elke technische Cloud-laag zit een operationele werkelijkheid: technologie wordt beheerd door bedrijven en die bedrijven bestaan uit mensen. Deze operatie wordt uitgevoerd volgens richtlijnen die deels door het bedrijf zelf zijn opgesteld, maar altijd binnen de kaders van geldende wet- en regelgeving. Die regelgeving is geografisch bepaald. Een Nederlands bedrijf dat in Nederland actief is, valt onder Nederlandse en Europese wetgeving. Maar zodra datzelfde bedrijf zich vestigt in een ander continent, verandert het speelveld. Ook eigenaarschap kan daarin belangrijk zijn: denk aan EU investeerders die onderdeel zijn van een multinational met een niet Europese moedermaatschappij Dan gelden niet alleen de Nederlandse regels, maar ook de wetten van het land waarin het bedrijf zich bevindt. Dit leidt tot juridische complexiteit en maakt het essentieel om in de context van Soevereine Cloud te onderzoeken welke wetgeving van toepassing is op de locatie van operatie. Daarom is het voor het bepalen van de mate van soevereiniteit belangrijk om te begrijpen wie de Cloudomgeving beheert, waar die beheerd wordt en onder welke jurisdictie dat gebeurt.  

Als we weer kijken naar Figuur 1, dan zien we dat er meerdere partijen per laag betrokken kunnen zijn. Een internetprovider bijvoorbeeld is zelden ook de applicatiebeheerder, en bijna altijd is de laag 1 dienstaanbieder een andere dan de dienstaanbieder van laag 2 tot en met 10. En vanuit de onderliggende lagen zijn er veel opties beschikbaar, maar wel zijn er veel voorkomende gevallen:

• Cloud Service Providers organiseren de lagen 2 en 3 en 6 t/m 10.

• Managed Service Providers gebruiken één of meerdere Cloud Service Providers en beheren daarin 4 t/m 6.

• Fundaments kan voor specifieke oplossingen daarin een groot deel van de lagen faciliteren, zelfs 2 t/m 10. Dit maakt het voor het vaststellen van mate de bemoeienis eenvoudig in de soevereiniteitsdiscussie.

‍

Conclusie: soevereiniteit begint bij inzicht

Soevereine Cloud is een veelomvattende definitie en kan op heel veel verschillende manieren worden uitgelegd. Voor de eindgebruiker is het essentieel om te begrijpen waar data naartoe gaat, wie deze verwerkt en onder welke voorwaarden dat gebeurt. Kortom: wat is de mate van ‘bemoeienis’. Dit inzicht verkrijg je door naar de technische lagen van de Cloud te kijken en vast te stellen:  

• Waar bevindt de techniek zich?

• Welke partij is verantwoordelijk voor de operatie?

• Onder welke jurisdictie valt deze partij?

Deze combinatie van techniek, operatie en locatie bepaalt hoe een dienst wordt geleverd en welke beheersmaatregelen erop van toepassing zjin. Die maatregelen worden altijd vanuit de localiteit van de techniek en de locatilteit van het bestuur van een beheerorganisatie bepaald.  

Wanneer je de mate van bemoeienis helder hebt, kun je de soevereiniteit van een Cloud-dienst kwalificeren. Met de data van een gebruikersorganisatie kan dan worden bekeken  wat de risico’s zijn voor beschikbaarheid, vertrouwelijkheid en integriteit van opslag in een Cloud-dienst. Hierbij is het dus zaak om data goed te classificeren binnen organisatie. Wanneer dit ingewikkeld lijkt, dan is het kijken naar de applicatie een goed startpunt. De applicatie kan dan worden gekoppeld aan de Cloud-dienst waar deze wordt gehost en daarmee kan de mate van soevereiniteit van de applicatie en de data worden vastgesteld.

Bij Fundaments kunnen wij u ondersteunen met dataclassificatie om vanuit daar een datagedreven Cloud-strategie neer te zetten. Hierin kan iedere vorm van Cloud worden toegepast, waarbij Fundaments een deel ook kan realiseren als het gaat om de private cloud. Meer weten? Neem dan contact op!