Een eigen Rijkscloud is nog geen digitale soevereiniteit

Het debat is toe aan zijn derde fase

De discussie over digitale soevereiniteit heeft grofweg twee fasen doorlopen. De eerste ging over datalocatie: staat de data binnen de EU? De tweede ging over jurisdictie en eigendom: valt de leverancier onder Amerikaanse wetgeving zoals de CLOUD Act, of is het een Europese partij? Beide vragen zijn relevant, maar geen van beide raakt de kern.

Een Europese provider zonder Amerikaanse moeder verkleint de juridische blootstelling. Maar ook een Nederlandse cloud in een Nederlands datacenter kan tekortschieten wanneer de klant geen onafhankelijk sleutelbeheer, geen afdwingbare toegangscontrole en geen daadwerkelijk uitvoerbare exit heeft. Eerdere bijdragen op dit platform hebben al laten zien dat ‘sovereign cloud’ vaak vooral een marketinglabel is en dat datalocatie niet automatisch gelijkstaat aan controle.

De derde fase van het debat moet daarom gaan over afdwingbare en verifieerbare controle over data zelf: toegang, beschikbaarheid, cryptografisch sleutelbeheer en beslissingsbevoegdheid – onafhankelijk van de infrastructuur waarop die data draait. In die benadering, die ik in mijn onderzoek heb uitgewerkt als data‑centrische soevereiniteit, is infrastructuur operationeel onmisbaar, maar wordt zij een ondersteunende en in toenemende mate vervangbare laag. De soevereiniteit verhuist naar de data‑, sleutel‑ en beleidslaag.

Papier regelt gedrag, geen macht

Waarom is die verschuiving nodig? Omdat contracten, certificaten en compliance‑kaders één structurele beperking delen: ze reguleren wat partijen mógen doen, niet wat ze technisch kúnnen doen. De Algemene Rekenkamer waarschuwde in het rapport “Het Rijk in de cloud” al dat ministeries vaak beperkt inzicht hebben in hun clouddiensten en de bijbehorende risico’s, en dat het moeilijk is om te beoordelen of contractuele waarborgen in de praktijk afdwingbaar zijn.

Hetzelfde geldt voor nieuwe certificerings- en beoordelingsschema’s, zoals het Europese Cloud Sovereignty Framework met SEAL‑niveaus of nationale toetsingsinstrumenten. Ze zijn nuttig als inkoopinstrument en maken verschillen tussen aanbieders beter zichtbaar, maar een assurance‑niveau beschrijft vooral compliance‑condities. Het bepaalt niet bij wie de feitelijke macht over datatoegang, dienstcontinuïteit en beleidswijzigingen uiteindelijk ligt.

Zelfs bij de striktste soevereiniteitsvoorwaarden houdt een platformbeheerder wat je de restmacht kunt noemen: de invloed op dienstcontinuïteit, software‑updates, orchestratie‑lagen en de technische handhaving van toegangsbeleid. Encryptie lost dat niet volledig op. Encryptie beschermt vertrouwelijkheid, maar raakt niet aan de macht over beschikbaarheid en uitvoering. Wie de sleutels bezit maar niet kan verifiëren wat er met de toegang gebeurt, deelt in de praktijk de controle.

De soevereiniteitstest

Of soevereiniteit werkelijk bestaat, blijkt pas onder druk. Drie scenario’s vormen samen de test die elke cloudomgeving – publiek, privaat of als soeverein gelabeld – zou moeten doorstaan:

Kan een externe partij, bijvoorbeeld onder buitenlandse wetgeving met geheimhoudingsplicht, toegang tot data of metadata afdwingen zonder dat de eigenaar dit kan vaststellen?

Kan een leverancier de beschikbaarheid eenzijdig beperken – via dienstopschorting, gedwongen updates of eenzijdig gewijzigde voorwaarden?

Kan de organisatie haar data, sleutels en beleid meenemen zonder afhankelijk te blijven van diezelfde leverancier?

Vooral het eerste scenario wordt onderschat. Soevereiniteitsfalen vereist geen aantoonbaar datalek. Waar een overheid niet kan verifiëren óf haar gezag over de eigen data nog intact is – omdat toegang onder geheimhoudingsplicht buiten haar zicht kan plaatsvinden – is de soevereiniteit al voorwaardelijk geworden. Verifieerbaarheid is daarmee geen luxe‑eis maar een minimale voorwaarde.

In moderne security‑architecturen zie je dat inzicht terug. Zero‑Trust‑modellen en soevereiniteitsrichtlijnen van grote leveranciers plaatsen controlepunten rond data, identiteit en beleidsbeslissingen, niet rond de gps‑coördinaten van de serverruimte. De locatie helpt, maar bepaalt niet wie er uiteindelijk op de knop kan drukken.

Vijf voorwaarden voor soevereine data

Wat moet er dan wél geregeld zijn, ongeacht welke cloud eronder draait? Op basis van mijn analyse ontstaat een praktisch kader met vijf voorwaarden voor soevereine data:

Onafhankelijke beslissingsbevoegdheid over toegang, gebruik en bewaartermijn van data.

Exclusief of aantoonbaar onafhankelijk cryptografisch sleutelbeheer.

Technisch afdwingbare toegangs‑ en intrekkingsmechanismen die niet door de platformbeheerder te overrulen zijn.

Onafhankelijkheid van eenzijdige platformbeslissingen, zodat het wegvallen of wijzigen van een dienst niet automatisch het verlies van datacontrole betekent.

Verifieerbare, manipulatiebestendige logging van wie wanneer welke toegang heeft gehad.

De benodigde technische mechanismen zijn niet langer uitsluitend theoretisch. Confidential computing (hardware‑gebaseerde bescherming van data tijdens verwerking), remote attestation (cryptografisch aantonen dat een workload draait in een vertrouwde omgeving) en multi‑party sleutelbeheer kunnen ieder een deel van de noodzakelijke controle en verifieerbaarheid realiseren. Beleidsdocumenten over digitale autonomie en datasoevereiniteit schuiven ondertussen steeds meer op richting dit type datagovernance in plaats van puur infrastructuureigendom.

Soevereiniteit zelf kent daarbij geen gradaties: de uiteindelijke beslissingsmacht houdt stand of zij faalt onder druk. Wat wél gradueel is, is de weerbaarheid van de architectuur die deze machtspositie moet beschermen. Voor ieder datadomein moet daarom worden bepaald welk niveau van technische en organisatorische weerbaarheid nodig is om soevereine controle daadwerkelijk te behouden. Identiteitsgegevens en brondata van basisregistraties vragen om andere waarborgen dan een intranetpagina of een facilitair systeem.

Wat dit betekent voor de markt

Voor de Nederlandse IT‑sector is dit geen abstracte discussie. Het kabinet start een sourcingtraject waarbij de markt wordt betrokken bij de opschaling naar een productieomgeving voor de Rijkscloud. Tegelijkertijd introduceerde DICTU een toetsingsinstrument dat clouddiensten langs vijf dimensies beoordeelt – juridisch, data & AI, technologisch, operationeel en menselijk – om de mate van soevereiniteit systematisch in kaart te brengen.

De partijen die in deze nieuwe werkelijkheid waarde toevoegen, zijn niet degenen die de zoveelste “soevereine” hostinglaag aanbieden, maar degenen die de controlelaag kunnen leveren én toetsen. Denk aan:

Onafhankelijk sleutelbeheer en secrets‑management.

Identiteits‑ en beleidslagen die toegang afdwingen bovenop hyperscalers en soevereine clouds.

Dataclassificatie en datagovernance die expliciet rekening houden met soevereiniteitsrisico’s.

Confidential‑computing‑oplossingen, manipulatiebestendige logging en periodiek geteste exit‑architecturen.

Wie als MSP, integrator of leverancier feitelijke controle kan aantonen in plaats van alleen contractuele controle te beloven, onderscheidt zich in elke aanbesteding die komt.

Niet waar, maar wie

De conclusie is nadrukkelijk niet dat de Rijkscloud een vergissing is. Eigen infrastructuur kan afhankelijkheden verminderen en de weerbaarheid vergroten. Maar infrastructuureigendom is geen voldoende voorwaarde voor soevereiniteit – het is een middel, geen doel. De echte opgave is architectonisch vastleggen welke macht geen enkele leverancier ooit mag behouden: over de sleutels, over de toegang, over de verifieerbaarheid.

Nederland moet niet alleen bepalen wáár de overheid haar systemen laat draaien, maar vooral wíe er onder druk over de data beslist. Pas als dat antwoord technisch afdwingbaar en controleerbaar vastligt, is soevereiniteit meer dan een label op een datacenter.

Door: Victor Angelier, IT‑architect, onderzoeker en adviseur op het gebied van digitale soevereiniteit en betrouwbare AI