WA-verzekering in de cloud

Regelmatig worden we verrast door discontinuïteit in de digitale dienstverlening, want hoewel we er steeds afhankelijker van worden vergeten we nog dat elke keten zo sterk is als de zwakste schakel. En die schakel is niet altijd technisch, maar is wellicht financieel, want zeker in de Cloud markt zitten veel start-ups die prachtige oplossingen hebben, maar de zaken aan de achterkant niet altijd goed geregeld hebben.

Beloven van continuïteit is makkelijker dan deze waar maken, zeker als voorzorgsmaatregelen nagelaten worden uit kostenoverwegingen. Het investeringsdal voor een uitwijk is soms gewoon te diep en wordt daardoor nog weleens half ingericht. Zeker bij veel SaaS-oplossingen is er nog weleens onduidelijkheid waar de data landt, wie nu precies de eigenaar is van de systemen en hoe de rechten en plichten precies liggen. SaaS-oplossingen worden ook bedrijfskritischer. Het begon met horizontale toepassingen (hr/payroll, boekhouding et cetera) maar breidt zich uit naar de bedrijfs- en branchspecifieke toepassingen (logistiek, onderwijs, gezondheidszorg). Uitval raakt dus al niet meer één afdeling maar de hele business, wat dus niet acceptabel is.

Back-door garanties

Niet zelden maken de SaaS-leveranciers gebruik van IaaS-diensten die geleverd worden door andere partijen. Hierdoor ontstaat een complex juridisch landschap waar ‘back-end agreements’ niet altijd goed geregeld zijn. Kiezen van een cloud oplossing is vanuit technisch perspectief al geen sinecure maar wordt met alle onduidelijkheden in het eigenaarschap nog wat complexer:

1.   Eerste-lijns provider levert de functionele service (ip-eigendom)

2.   Tweede-lijns provider levert de technische service (hw-eigendom)

3.   Derde-lijns provider levert de facilitaire service (dc-eigendom)

Natuurlijk kan met een klassieke escrow-overeenkomst zeker gesteld worden dat de broncode van een SaaS-oplossing beschikbaar komt, maar wat heb je uiteindelijk aan een lege applicatie als je data onbereikbaar bij een derde partij ligt of de kennis ontbreekt om de service te continueren?

Een online dienst is meer dan broncode, zonder hardware heb je er niets aan om over de data nog maar niet te spreken. En een curator kan deze data gijzelen om de schuldeisers te dienen, Nebula-arrest is een achterdeur gebleken om de eventuele escrow- overeenkomst te negeren. Onderbreking van SaaS-dienst bij faillissement is moeilijker te mitigeren dan falende schijven of andere technische ongemakken door de juridische issues die nog vaak vergeten worden.

Garantie tot aan de voordeur

De duivel zit altijd in de details en een escrow-agent kan helpen om deze te identificeren en op te lossen. Er ligt namelijk nog een boa constrictor in het gras als de SaaS-provider de techniek uitbesteed heeft aan een IaaS-provider. Eindgebruiker heeft meestal alleen een cont(r)act met de eerste-lijn en weet vaak niet eens wie de achterliggende providers zijn. Geen ongebruikelijke constructie binnen de lokale markt waar niche spelers het vooral met niche spelers doen. Ook de Dutch Hosting Provider Association laat hier nog veel vrijblijvendheid voor de provider over.

Probleem bij SaaS is dat het niet om een gebruiksovereenkomst voor software gaat, maar om een dienst waarbij de data-opslag is inbegrepen. En dat vergroot dus de afhankelijkheid want data blijft uiteindelijk de belangrijkste asset van een bedrijf. En als een SaaS-provider gebruik maakt van diensten van derden staat aan de onderkant van service keten vaak een ‘databak’ waarbij eigenaarschap van de container wel bekend is, maar wie er allemaal instorten niet. De logische scheiding zit meestal aan bovenkant omdat multi-tenancy in de hele keten een zeldzaamheid is.

Trias politica

Misschien heeft de IaaS-provider de disaster recovery en back-up goed ingericht, iets waarvan je pas echt zeker bent als dit getest is, maar is dit een misplaatste investering als een curator alles stilzet. Het kan handig zijn om daarom de uitwijk te laten landen op een juridisch andere entiteit zodat deze niet gegijzeld kan worden. Replicatie binnen het datacenter is goedkoper dan tussen datacentra en je wilt niet dat jouw data bij de concurrent komt. De escrow-agent kan hier acteren als vertrouwde derde partij, door niet alleen de broncodes te bewaren, maar ook zeker te stellen dat uitwijk voldoende garanties biedt. Want nu ik het over vertrouwen heb, ervaring leert dat controle nog altijd beter is en vreemde ogen dwingen.

Tenslotte kost testen tijd en geld en is het niet moeilijk te raden waar het eerst op bezuinigd wordt als het economisch wat minder gaat. Let wel dat je met een SaaS-escrow uiteindelijk alleen maar tijd koopt want uiteindelijk zul je toch moeten migreren. Misschien zelfs wel heel primitief met steekkarretje een rack te verhuizen naar een ander datacenter.

Belangrijk dat er daarom gedacht wordt aan systeemdocumentatie, wijzigingen en nog wat van die details die vaak vergeten worden. Dat betekent dat de rol van de escrow-agent bij SaaS wat verder gaat dan een kopietje van de software in een kluis leggen. Er moet kennis aanwezig zijn om niet alleen de contracten te controleren maar ook technische inrichtingen en in het uiterste geval zelfs om hele ‘sloepenrol’ ter hand te nemen bij ontscheping als een partij in de lijn failliet gaat.

Titanic

Ook al zie je tot aan de horizon geen ijsberg, het is toch goed om aan reddingsboten te denken want een faillissement kan niet alleen onverwachts zijn maar de impact ervan ook catastrofaal. Nu zijn alle juridische aspecten in dit verhaal niet ‘my cup of tea’ omdat ik meer van de koffie ben, met een wolkje melk. Deze blog is derhalve mede tot stand gekomen in samenspraak met Herman Kui van Escrow4All.

—

Auteur: Ewout Dekkinga, IT Architect Unisys
Bron: Computable