Microsoft kondigde onlangs nieuwe mogelijkheden aan voor Sovereign Cloud. Denk aan meer controle over encryptiesleutels, lokaal draaiende workloads en omgevingen die zonder verbinding met de publieke cloud kunnen functioneren. Interessante ontwikkelingen, zeker voor organisaties die hun afhankelijkheid van Amerikaanse technologie willen verkleinen.
De aankondiging nam niet alle bestaande scepsis weg. Dat is begrijpelijk. Want hoewel Microsoft steeds meer mogelijkheden biedt om de controle over je IT-omgeving te vergroten, blijven er afhankelijkheden bestaan. Die verdwijnen niet omdat je data in Nederland staat of omdat je zelf je encryptiesleutels beheert.
Neem encryptie. De mogelijkheid om bepaalde root-encryptiesleutels buiten de infrastructuur van Microsoft te beheren, geeft organisaties meer zeggenschap over de bescherming van hun gegevens. Dat is een relevante verbetering, maar zegt nog weinig over de beschikbaarheid van de diensten die op die gegevens draaien.
Je kunt je encryptiesleutels volledig zelf beheren en voor de werking van je applicaties alsnog afhankelijk zijn van Microsoft. Bijvoorbeeld voor licenties, identity, updates of ondersteuning.
Ook bij dataresidentie speelt dit. Data die fysiek in Nederland wordt opgeslagen, kan nog steeds onderhevig zijn aan buitenlandse wetgeving. Dat betekent overigens niet dat Amerikaanse autoriteiten daarmee automatisch toegang hebben tot die data. De juridische werkelijkheid is ingewikkelder, en de technische en contractuele maatregelen die een leverancier neemt, doen er wel degelijk toe.
Met disconnected operations gaat Microsoft een stap verder. Bepaalde Azure Local-omgevingen kunnen met een lokale control plane functioneren zonder actieve verbinding met de publieke Azure-cloud. Dat vermindert de operationele afhankelijkheid behoorlijk.
Zo’n omgeving valt niet automatisch uit zodra de verbinding wegvalt. Technisch kan die blijven draaien, maar zonder verbinding kunnen ondersteuning en updates na verloop van tijd wegvallen. Wat dat voor je licenties, contracten en beheer betekent, moet je vooraf uitzoeken. Ook is niet iedere functionaliteit die Microsoft heeft aangekondigd al algemeen beschikbaar.
Dat zijn zaken die je moet uitzoeken voordat je conclusies trekt over de mate van onafhankelijkheid die je hebt bereikt.
Ik merk dat gesprekken over digitale soevereiniteit nogal eens vastlopen op de herkomst van een leverancier. Alsof een Amerikaanse leverancier per definitie niet voldoet en een Europese partij vanzelf veiliger is.
Zo eenvoudig ligt het niet.
Een Europese cloudprovider kan voor bepaalde eisen een betere keuze zijn, bijvoorbeeld omdat de juridische en bestuurlijke verhoudingen overzichtelijker zijn. Maar ook Europese partijen maken gebruik van technologie, hardware en software van leveranciers buiten Europa. Bovendien moet je bij iedere aanbieder kijken naar de financiële stabiliteit, de technische mogelijkheden, de beveiliging en de mate waarin je diensten kunt verplaatsen.
Andersom kunnen Amerikaanse leveranciers maatregelen bieden waarmee je specifieke risico's voldoende beperkt.
De eisen verschillen bovendien per organisatie en per workload. Voor een interne samenwerkingstool kan een bepaalde afhankelijkheid prima acceptabel zijn, terwijl je voor een systeem dat essentieel is voor een publieke dienst veel strengere eisen stelt.
Dat vraagt om een risicoafweging die verder gaat dan de vestigingsplaats van een leverancier. Je moet weten welke onderdelen van je dienstverlening afhankelijk zijn van externe partijen, wat de gevolgen zijn wanneer die partijen wegvallen en welke maatregelen je zelf kunt nemen. Dat geldt ook bij Nederlandse en Europese leveranciers.
Een onderwerp dat in de discussie terecht naar voren komt, is de mogelijkheid om zelfstandig te blijven functioneren.
Stel dat een leverancier bepaalde diensten niet meer mag leveren. Door sancties, veranderende wetgeving of een ander geopolitiek besluit. Wat betekent dat voor de systemen waar jouw organisatie op draait?
Bij een lokaal draaiende applicatie kan bijvoorbeeld nog steeds een afhankelijkheid bestaan van een externe identityprovider. Als gebruikers zich niet meer kunnen aanmelden, heb je weinig aan het feit dat de servers in je eigen datacenter staan. Een vooraf ingerichte en geteste tweede IAM-inrichting kan dan helpen, als de applicatie die uitwijkmogelijkheid ondersteunt.
Hetzelfde geldt voor softwarelicenties en ondersteuning. Je wilt weten hoe lang een omgeving zelfstandig kan functioneren, welke rechten je contractueel hebt en wat er gebeurt wanneer je geen updates meer kunt ontvangen.
Daar komt de mogelijkheid om over te stappen bij. Veel organisaties hebben een exitstrategie, maar het daadwerkelijk verplaatsen van een applicatie is vaak een stuk ingewikkelder dan het verplaatsen van de data alleen. Denk aan koppelingen, specifieke platformdiensten, beheerprocessen en de kennis die nodig is om alles elders weer werkend te krijgen.
Voor kritieke workloads zou ik daarom niet alleen willen weten of er een exitstrategie bestaat, maar ook of die ooit is getest. Wat kost een overstap, hoelang duurt die en welke functionaliteit verlies je onderweg?
Daar heb je als organisatie veel meer aan dan aan een algemene uitspraak over hoe soeverein een cloudomgeving zou zijn.
We werken bij InSpark veel met Microsoft-technologie en zien van dichtbij hoeveel er op dit gebied verandert. De nieuwe mogelijkheden van Sovereign Cloud zijn relevant voor organisaties die hun afhankelijkheden willen verminderen zonder afscheid te nemen van hun bestaande Microsoft-omgeving.
Dat kan een verstandige keuze zijn. Zeker als je al veel investeringen hebt gedaan in Microsoft-technologie en de risico's met aanvullende maatregelen voldoende kunt beperken.
Maar er zijn ook situaties waarin de eisen verder gaan dan wat Microsoft kan bieden. Dan moet je naar andere oplossingen kijken.
Samen met KPN hebben we daarvoor verschillende mogelijkheden, van hybride architecturen en Azure Local tot Nederlandse infrastructuur en private-cloudoplossingen. Afhankelijk van de eisen kunnen ook andere technologieën een rol spelen.
Ik vind dat we daar als Microsoft-partner open over moeten zijn. Onze kennis van Microsoft helpt ons om goed te beoordelen wat er mogelijk is, maar mag er niet toe leiden dat iedere vraag uiteindelijk hetzelfde technische antwoord krijgt.
Het uitgangspunt moet zijn wat een organisatie nodig heeft, niet welk platform er al staat.
Wat ik vooral uit de discussie naar aanleiding van Microsofts aankondiging haal, is dat er behoefte is aan meer duidelijkheid over wat de verschillende soevereiniteitsmaatregelen daadwerkelijk opleveren.
Dat vraagt ook wat van leveranciers en hun partners. Juist omdat we dagelijks met Microsoft-technologie werken, kunnen we concreet aangeven wat mogelijk is en waar de grenzen liggen. Welke onderdelen blijven afhankelijk van een externe verbinding? Wat zijn de gevolgen van het wegvallen van een leverancier? En wat gebeurt er als je over vijf jaar een andere richting op wilt?
Voor organisaties betekent het dat ze hun eigen eisen concreter moeten maken. Welke processen moeten onder alle omstandigheden kunnen blijven functioneren? Welke risico's zijn acceptabel? En voor welke onderdelen is het noodzakelijk om zelfstandig te kunnen opereren?
Daarbij helpt het om verschillende scenario's daadwerkelijk te testen. Schakel verbindingen uit, onderzoek de gevolgen voor identity en beheer en probeer eens een kritieke workload te verplaatsen naar een andere omgeving. Dan wordt vrij snel duidelijk waar je nog afhankelijk bent van anderen.
De ontwikkelingen bij Microsoft bieden nieuwe mogelijkheden om die afhankelijkheden te verminderen. Dat is positief. Maar of ze voldoende zijn, hangt af van de situatie waarin je ze toepast en combineert.
En precies die afweging verdient wat mij betreft meer aandacht in het gesprek over digitale soevereiniteit.