Ketenaansprakelijkheid in cloud computing

Onze informatiehuishouding bestaat steeds vaker uit gekoppelde keten van deelprocessen. Deze ketens maken dat iedere onderliggende schakel een risico vormt in het hele proces. Zeker de cloud-ontwikkeling heeft geleid tot een versnippering van informatiediensten over een scala van aanbieders. Het begrip ketenaansprakelijkheid is vooral bekend uit de aannemerij, zodat de belasting alle loonbelasting en sociale premies in de ‘keten van aannemers’ kan vorderen. Deze invorderingswet uit 1990 was in het leven geroepen om de gehele keten – van opdrachtgever tot onderaannemer – hiervoor aansprakelijk te stellen.

Naast het belang van de belastingdienst, is het natuurlijk van belang voor de opdrachtgever, opdat hij weet dat als de aannemer werkzaamheden delegeert naar derden, de eindverantwoordelijkheid bij de uitvoerder blijft liggen, zelfs als een onderaannemer failliet gaat. In de wereld van cloud leidt deze ketenaansprakelijkheid in toenemende mate tot interessante situaties.

Cloudketens

Het traditionele denken rond het cloud operations model was gebaseerd op het aloude hosting: een partner neemt alle verantwoordelijkheden van jouw informatiehuishouding over. En natuurlijk ook de verantwoordelijkheid voor de gegarandeerde service levels. De leverancier kon die verantwoordelijkheid ook nemen omdat álle services immers door hem werden geleverd. Het cloud-model is niet meer dan het standaardiseren van vele (basis-) services op basis van een enorm grote operationele schaalbaarheid en flexibiliteit.

Met de diversificatie van cloud-providers ontstonden standaard services voor allerhande specifieke informatiediensten. Denk aan financiële en boekhoudkundige taken, customer relationship taken, HR taken en zo verder. Deze aanbieders werden zo groot en goed, dat zij hun diensten zeer concurrerend kunnen aanbieden. Het is dus begrijpelijk dat als een algemene ‘cloud-aanbieder’ een breed contract afsluit met een klant, dat delen daarvan in de keten van clouds wordt doorgezet. Tenzij de eindklant zelf dat ‘cloud partner-management’ voor zijn rekening neemt.

Toleranties

In de wereld van fysieke producten kennen we het begrip tolerantie. Dit geeft aan hoever een product mag afwijken van de officiële maatvoering. Als een gat een diameter van 5 centimeter heeft met een tolerantie van 2 procent dan kan en mag het gat een maat hebben tussen de 4,9 en 5,1 centimeter. Echter als er in dat gat een staaf van 5 centimeter moet passen en die staaf heeft ook een tolerantie van 2 procent ontstaat een probleem. Want die staaf mag ook variëren tussen de 4,9 en 5, 1 centimeter en zal dus lang niet altijd passen.

Dat is de grote uitdaging in de wereld van werktuigbouw en eindproduct-realisatie; er kan een lange keten van toleranties ontstaan als tientallen producten samengesteld moeten worden in een assemblage. En hoe langer die keten is, hoe nauwkeuriger de producten moeten worden geproduceerd opdat alle onderdelen ‘altijd’ op elkaar passen. Voor reserveonderdelen zijn die eisen zelfs vaak nog hoger.

Service-toleranties

Ook de informatiewereld is opgebouwd uit informatieproducten die samen een eindservice of eindproduct vormen. Hoe langer die keten van service-opbouw is, hoe belangrijker de toleranties worden die elk serviceproduct op zich mag hebben ten opzichte van de andere gelinkte service. Nu is de digitale wereld in dat opzicht fantastisch, omdat de tolerantie niet analoog is en het verschil tussen de waarde van een nul en een één best groot mag zijn. De nauwkeurigheid is immers vertaald naar de software en een digitaal uitgedrukte waarde.

Maar er zijn nog andere toleranties en die komen naar voren als we naar de beschikbaarheid en performance kijken. Immers hoe langer de keten wordt, hoe meer veranderingen in beschikbaarheid en performance hun invloed zullen hebben op het eindresultaat. Als de beschikbaarheid 99,99 procent moet zijn dan mag de eindservice 8,76 uur per jaar niet beschikbaar zijn. Echter voor twee gekoppelde, onderliggende services waaruit de eindservice is opgebouwd, mag de uitval per deelservice niet meer dan de helft zijn, dus 4,38 uur of te wel 99,9995 procent.

Ketenaansprakelijkheid

De keten van diensten eist op die wijze steeds hogere servicelevels, hoe verder je van de eindservice afkomt. En verstoringen die door derden in de keten ontstaan, zijn steeds lastiger te beheersen, zeker als er geen reserve of uitwijk beschikbaar is. Deze ketenaansprakelijkheid uit zich natuurlijk ook in het steeds lastiger kunnen beheersen van de kosten die moeten worden verhaald als een servicelevel niet (meer) wordt gehaald en er door de eindaannemer vergoedingen moeten worden betaald aan de eindafnemer.

In de nieuwe architecturen van cloud-processen is deze beperking operationeel en juridisch een steeds belangrijker aandachtspunt. Dat gold natuurlijk al voor de onderliggende informatie functies als data-storage, processing power en netwerk-beschikbaarheid. Als van de drie er één faalt, is de informatiedienst al niet meer beschikbaar. In de oude storagewereld was deze keten van storingen al een bekende. Als een klant belde en zei: ‘ik kan niet bij mijn data!’ dan wisten we al dat de kans dat het echt in de storage zat, beperkt was en waren applicaties, netwerken, servers en interfaces de eerste verdachten.

Principe

Het aloude principe van ketenaansprakelijkheid is niet verdwenen met de cloud. Integendeel, omdat zoveel kleinere informatiebouwstenen zo makkelijk en goedkoop van een cloud-leverancier kunnen worden betrokken, neemt de afhankelijkheid tussen de verschillende servicelevels van die ‘informatie-onderdelen’ toe en kan dus leiden tot striktere – en dus duurdere – servicelevels. Natuurlijk kan het een optie zijn om bepaalde verstoringen in de ‘streaming-clouddienst’ op te vangen door ‘on-premise’ een minimale tijd door te kunnen produceren, zelfs als de informatie-aanvoer stopt.

In de fysieke productiewereld kunnen numeriek bestuurde machines of robots bij netwerkstoringen op de reeds lokaal aanwezige productiedata nog vele uren door produceren. Dat kan natuurlijk in kantoor en andere proceswerkzaamheden ook worden georganiseerd. Op die wijze zal uitval ‘ergens in de keten’ minder doorwerken in de eindservice. Ik ken vele klanten die zich op die wijze ‘verzekeren’ van continuïteit in hun eindproces. Het oude principe van business continuity blijft geldig, ook als dat via streaming clouddiensten – of zoals ik soms zeg – via het mainframe van het internet – wordt gerealiseerd.

Op het gebied van cyber zijn er zelfs speciale oplossingen voorhanden om na een cyberaanval weer te kunnen ‘opstaan’ en de business op te starten. Zelfs als malware je data heeft weten te versleutelen en de daders ‘losgeld’ eisen. Met zeer effectieve ‘air-gap’ oplossingen wordt de productiedata die nodig is om na zo’n aanval toch weer te starten, in een bunker en fysiek ontkoppeld van de buitenwereld opgeslagen. En mocht je hele productie- en backup-omgeving te zijn gehackt en gecompromitteerd, dan kun je als laatste toch de middelvinger opsteken naar de hacker en vanuit je veilige omgeving met een kopie weer een nieuwe productie-omgeving in de lucht krijgen. Trouwens niet alleen handig tegen hackers, maar ook om minder afhankelijk te worden van (publieke) cloud-leveranciers.

Door: Hans Timmerman (foto), CTO van Dell EMC Nederland