In deel 1 zette ik het Cloud Sovereignty Framework neer en de vraag of SEAL‑4 überhaupt nodig is, en voor wie. In deel 2 begon ik onderaan, bij de datacenters. In deel 3 klom ik naar de infrastructuur. In deel 4 behandelde ik het platform: het control plane dat van datacenters met servers een cloud maakt.

In dit deel klimmen we weer een laag omhoog, naar de kerndiensten. Dit is de eerste laag die de klant daadwerkelijk ziet. Alles daaronder is onzichtbaar mits het werkt; vanaf hier praat je met de cloud. Compute, containers, opslag, netwerk, identiteit en sleutelbeheer: de dingen waar vrijwel elke applicatie op leunt, hoe simpel of hoe complex die ook is.

En omdat het ook hier om software gaat, is de reflex opnieuw: “dít kunnen we zelf.” Dat is deels waar, maar net als in de vorige laag zit de complexititeit niet in het bouwen van de software, maar om de operationele discipline er omheen. Daarom kijken we wederom naar dezelfde twee vragen: wat heb je nodig voor de bouw, en wat heb je nodig voor de operatie?

Wat zijn kerndiensten?

Kerndiensten zijn die diensten die nodig zijn vrijwel voor alle PaaS en SaaS diensten en klantapplicaties. We hebben het dan over virtuele machines, containers, opslag, network, identiteit, encryptie en sleutelbeheer. Dat klinkt beperkt en daarmee relatief eenvoudig. Wat dit complex maakt is dat een dienst meer is dan alleen dan de capability. Een virtuele machine starten is een capability en dat kan iedereen met een hypervisor wel organiseren. Een volwaardige compute-dienst is de toezegging dat je er over een aantal maanden of jaren nog duizenden per minuut kunt starten, in meerdere regio’s, en dat terwijl de onderliggende hardwaregeneraties vervangen worden zonder dat de klant het merkt.

Opslag is het duidelijkste voorbeeld. Objectopslag lijkt aan de buitenkant een emmer waar je bestanden in gooit. Aan de binnenkant is het een gedistribueerd systeem dat elk object opknipt en met erasure coding over racks en zones verspreidt, continu achtergrondcontroles doet op bitrot, kapotte schijven vervangt zonder dat er iemand naar kijkt, en dat tegelijk drie of meer consistentiemodellen moet bedienen. Hyperscalers geven hier een absurd hoge duurzaamheids SLA op. Die SLA is geen marketing, het is een ontwerpdoel waar jaren engineering en heel veel operationele data achter zit. Het is ook precies het soort eigenschap dat je niet kunt kopiëren door de broncode over te nemen, want het zijn de operationele processen die de SLA mogelijk maken.

Netwerk is hetzelfde verhaal in een ander jasje. Software-defined networking betekent dat elke klant zijn eigen adresruimte heeft, zijn eigen routering, zijn eigen firewallregels, en dat die van tienduizenden klanten tegelijk op dezelfde fysieke kabels liggen zonder ooit in elkaars verkeer te kijken.

Identiteit: de echte perimeter

Als het control plane de macht is, zoals ik in deel 4 betoogde, dan is identiteit de sleutel tot die macht. Identity is de enige kerndienst waar een storing of een compromittering meteen alles raakt: zonder identiteit kun je niet inloggen, niet autoriseren, en dus niets.

Dat maakt identiteit de dienst met de scherpste soevereiniteitsvraag van deze hele laag. Niet “waar staat mijn data”, maar “wie bepaalt wie ik ben”. Een organisatie die haar data netjes onder eigen controle heeft maar haar identiteitsprovider niet, heeft alsnog een soevereiniteitsrisico. Omgekeerd is een eigen identiteitsdienst optuigen technisch goed te doen (Keycloak en verwanten zijn volwassen), maar deze 24×7 overeind houden op het niveau waarop de rest van je organisatie ervan afhankelijk is, is een compleet andere discipline. Identity is de dienst waar zelf doen het aantrekkelijkst is vanuit een soevereiniteitsgedachte en het slechtst uitpakt als je het onderschat. Want wordt de identiteitsdienst gecompromiteerd, dan ben je alles behalve soeverein.

Voor het framework zit dit vooral bij SOV‑2 en SOV‑3: wie kan rechtmatig toegang afdwingen, en wie kan de deur dichtgooien. En anders dan bij de hardwarelaag is dit een vraag waar je architectonisch iets aan kunt doen: federatie, eigen identity provider, meerdere vertrouwensankers. Dit is een van de weinige plekken waar een soevereiniteitseis zich vertaalt in een concrete, uitvoerbare ontwerpkeuze in plaats van in een vinkje in een aanbesteding.

Sleutels: waar soevereiniteit wiskunde wordt

Sleutelbeheer is de kerndienst waar het soevereiniteitsdebat het dichtst bij een echt antwoord komt, en waar het tegelijk het vaakst misgaat. De redenering uit deel 3 en 4 geldt hier onverkort: je hoeft de leverancier niet te vertrouwen als de wiskunde het overneemt. Als de versleutelingssleutel van jouw data in een HSM zit die jij beheert, is de vraag “kan een buitenlandse overheid bij mijn data” niet langer juridisch maar technisch. Zonder sleutel is de data ruis, hoe rechtmatig het verzoek ook is.

Hier zit bovendien het vrolijkste nieuws voor Europa: in HSM’s staat Europa er goed voor. Thales (Frans) en Utimaco (Duits) zijn echte spelers in een markt waar de rest van de keten overweldigend niet-Europees is. Dit is een van de weinige plaatsen op de kaart uit deel 3 waar Europa geen toeschouwer is maar meespeelt.

En dan de nuance, want die is er altijd. Sleutels volledig buiten de cloud houden klinkt als maximale soevereiniteit, maar er zitten twee serieuze nadelen aan. Ten eerste hebben een heleboel diensten de sleutel nodig om überhaupt te kunnen functioneren. Een zoekfunctie kan niets zoeken als de data die het doorzoekt versleuteld is. Hetzelfde geldt voor indexeren, analyseren, backups maken, en tegenwoordig heel belangrijk AI. Om bruikbaar te zijn moet data in de cloud ontsleuteld kunnen worden en moet de cloud dus toegang hebben tot de sleutelopslag. Confidential Computing kan hier een rol spelen, maar is nog niet zover dat we dit eenvoudig voor alles kunnen gebruiken. Ten tweede wordt de eigen sleutelbeheer omgeving de enige single point of failure. Wie zijn sleutels kwijtraakt, raakt zijn data kwijt, en dat is geen theoretisch risico maar een van de meest voorkomende manieren waarop organisaties permanent data verliezen. Sleutelbeheer geheel zelf doen kan precies de juiste keuze zijn, maar dan wel als bewuste risicoafweging en niet als reflex.

Kubernetes

Hoewel Kubernetes strikt genomen geen kerndienst is, het draait immers boven de andere kerndiensten, verdient het hier toch een plekje. Containers en daarmee containerorchestratie speelt een steeds belangrijkere rol als kerndienst, omdat steeds meer applicaties gemoderniseerd worden naar containers. Ook cloud provider zelf draaien steeds meer van hun PaaS en SaaS diensten containers.

Voor soevereiniteit is Kubernetes tegelijk het beste en het meest misleidende argument van deze hele laag. Het beste, omdat het een van de weinige echte open standaarden is die de industrie heeft: de API is dezelfde bij elke provider en bij jezelf op kantoor. Dat is geen de‑facto standaard zoals S3, maar een daadwerkelijk gezamenlijk beheerd project onder een neutrale stichting, met conformance-tests die meten of een specifieke distributie zich ook echt als Kubernetes gedraagt. Wie zijn applicaties hierop bouwt, heeft een uitgang die niet van de goede wil van zijn leverancier afhangt. Dat is SOV‑3 in de praktijk in plaats van op papier.

En meteen het meest misleidende, want “het draait op Kubernetes, dus het is portabel” is zelden helemaal waar. Zodra je cluster gebruikmaakt van de load balancer, de opslagklassen, de identiteitskoppeling, de secrets-store en de monitoring van je provider, hangt er onder die neutrale API alsnog een serie leverancierspecifieke haken. De applicatie verhuist prima; het platform eromheen verhuist niet vanzelf mee. Portabiliteit is geen eigenschap die je krijgt, het is er een die je test. Wie nooit geprobeerd heeft zijn cluster ergens anders op te bouwen, weet simpelweg niet of hij kan vertrekken. CNCF projecten als Radius en Dapr zijn gericht op deze afhankelijkheid nog verder te beperken en applicaties echt portabel te maken, maar die worden nog weinig gebruikt.

Quantum-safe: de verbouwing die je nu moet organiseren

En dan is er iets wat in het hele soevereiniteitsdebat opvallend weinig aandacht krijgt, terwijl het de fundering onder alle bovenstaande redeneringen raakt. Al die “je vertrouwt de wiskunde”-argumenten uit deel 3, deel 4 en deze post leunen op asymmetrische cryptografie die door een voldoende grote quantumcomputer gebroken wordt. Dit raakt RSA en elliptische krommen die de basis vormen van TLS, code-signing, attestatie, en de hardware root of trust, van vrijwel elke sleuteluitwisseling in de stack.

Wanneer die quantum machine er staat, weet niemand. Dat het een risico is dat je nu moet organiseren, is desondanks geen speculatie, en wel om twee redenen die los staan van elke voorspelling.

De eerste is harvest now, decrypt later. Versleuteld verkeer dat vandaag wordt afgetapt en opgeslagen, kan in de toekomst alsnog ontsleuteld worden. Voor het overgrote deel van de data maakt dat niets uit, maar voor staatsgeheimen, medische dossiers, justitiële informatie en alles wat decennialang vertrouwelijk moet blijven, is de aanval feitelijk al aan de gang. Dit is precies de categorie waar het SEAL‑4-gesprek over gaat. Wie SEAL‑4 eist vanwege langdurige vertrouwelijkheid en ondertussen geen quantum-safe migratieplan heeft, verdedigt de voordeur tegen een juridisch risico terwijl de achterdeur cryptografisch openstaat.

De tweede reden is de looptijd van de verbouwing zelf. Cryptografie zit niet op één plek; het zit overal. In protocollen, in firmware, in certificaten met lange geldigheidsduur, in HSM’s, in chips die er tien jaar staan, in applicaties die niemand meer durft aan te raken. Je vervangt dat niet met een patchronde. De standaarden zijn er inmiddels wel (o.a. ML‑KEM, ML‑DSA en SLH‑DSA) dus de discussie gaat niet meer over welke wiskunde, maar over de inventarisatie en de volgorde. De EU-aanbeveling en de bijbehorende routekaart zetten daar ook concrete jaartallen op, met de zwaarste use cases voorop.

Praktisch betekent dat drie dingen, in deze volgorde. Weten wáár je cryptografie zit, want de meeste organisaties hebben geen volledig beeld en dat is het echte werk. Zorgen dat je systemen crypto-agile zijn, dus dat een algoritme vervangen kan worden zonder de applicatie open te breken. Dat is een architectuurprincipe, geen product. En hybride uitrollen, waarbij klassieke en post-quantum sleuteluitwisseling naast elkaar draaien, zodat je niets verliest als een van beide tegenvalt.

Voor deze laag is dat concreet. Je sleutelbeheerdienst moet post-quantum algoritmen ondersteunen, je HSM’s moeten ze aankunnen, en je certificaatketen moet vervangbaar zijn. Dat het Europese HSM-aanbod hier meespeelt, is meer dan een leuke bijkomstigheid: het is een van de weinige plekken waar “Europees” en “toekomstbestendig” samenvallen zonder dat je iets inlevert.

En dan de nuchtere kanttekening, want die hoort erbij. Hyperscalers zijn hier al jaren mee bezig en rollen post-quantum sleuteluitwisseling grotendeels ongemerkt uit over hun hele vloot. Dat is opnieuw schaalvoordeel: een migratie die voor een individuele organisatie een meerjarig programma is, is voor hen een uitrol over een pijplijn zoals beschreven in deel 4. Een kleine soevereine cloud moet diezelfde verbouwing zelf doen, met eigen mensen, voor een fractie van het aantal klanten. Dat is precies het soort verborgen kostenpost wat vaak over het hoofd wordt gezien.

De toeleveringsketen bij het bouwen

Goed nieuws en slecht nieuws.

Het goede nieuws: de bouwstenen liggen open op tafel. OpenStack, Kubernetes, Ceph, Keycloak, een volwassen ecosysteem van open cryptografie waarin de post-quantum algoritmen inmiddels gewoon meekomen. Een Europese partij die kerndiensten wil bouwen, hoeft geen enkel fundamenteel probleem opnieuw op te lossen. Net als bij OCP in deel 3 zijn de ontwerpen er; en net als bij OCP is dat maar de helft van het verhaal.

Het slechte nieuws is dat het verschil tussen open source en een dienst precies datgene is wat je niet kunt downloaden. Quotabeheer, capaciteitsplanning, throttling die eerlijk is onder druk, degradatiegedrag dat voorspelbaar is als een zone wegvalt, facturering die tot op de seconde klopt, en een foutmodel dat klanten begrijpen. Dat zijn de dingen waar jarenlang aan geschaafd is met data die je alleen krijgt als je op schaal draait. Je bouwt geen kerndienst, die slijp je in je organisatie.

Kubernetes is daar meteen de scherpste illustratie van. De software is gratis en van iedereen, maar een beheerde dienst eromheen betekent dat je voor duizenden klusters tegelijk garandeert dat een upgrade niet omvalt, dat een kapotte node binnen minuten vervangen is, en dat een beveiligingslek in de container-runtime binnen dagen overal gedicht is. Dat is geen product dat je bouwt, dat is een operatie die je opzet.

Wie vandaag begint te bouwen heeft overigens één voordeel dat de gevestigde partijen niet hebben: je kunt crypto-agility er vanaf dag één in ontwerpen in plaats van er twintig jaar aan legacy doorheen te moeten trekken. Dat is een van de weinige echte greenfield-voordelen op deze laag, en het zou hoog op de eisenlijst moeten staan van iedereen die zo’n bouw overweegt.

En de keten eronder blijft staan. Elke VM en elke node die je uitdeelt, draait op de hardware uit deel 3. Elke soevereine kerndienst is een Europese software‑laag op een niet‑Europees fundament. Dat maakt de software‑laag niet waardeloos maar SOV‑5 laat zich hier niet repareren.

De toeleveringsketen bij het exploiteren

Hier zit de echte rekening, en het is dezelfde als in deel 4: niet de bouw maar de operatie.

Klanten gebruiken de cloud niet alleen voor de functionaliteit, maar ook voor de betrouwbaarheid. Dat gaat niet alleen over dat de operatie ervoor zorgt dat er zelden onderbrekingen zijn in de dienstverlening, maar ook over de stabiliteit van hoe klanten diensten afnemen. Belangrijk daarbij is van belang hoelang diensten beschikbaar blijven en interfaces daarvan onveranderd blijven. Voor kerndiensten speelt dit nog meer dan voor meer experimentele diensten of diensten gericht op een veld waar de ontwikkelingen zich in een enorm tempo opvolgen (zoals momenteel AI).

Voor Kubernetes komt er een bijzonderheid bij die de andere diensten niet hebben: je bent niet de baas over je eigen releasekalender. Het upstream-project bepaalt het tempo, en jij mag volgen. Dat is de prijs van een open standaard, en het is een prijs die je alleen kunt betalen met een team dat structureel meedraait in dat project in plaats van er alleen uit consumeert. Doordat AI nu met grote regelmaat en snelheid gaten vindt in bestaande software maakt dit nog complexer, omdat je vaker met een zero-day lek geconfronteerd kan worden.

Daarnaast draagt deze laag de certificeringslast uit deel 4 door naar buiten. ISO 27001, SOC, PCI‑DSS en de rest gelden per dienst, niet per bedrijf. Elke nieuwe kerndienst moet die molen door en daarna periodiek opnieuw. Dat is geen bijkomstigheid maar een vaste, aanzienlijke kostenpost die schaal nodig heeft om betaalbaar te blijven.

En dan is er portabiliteit, in mijn ogen het meest onderschatte soevereiniteitsinstrument van deze hele laag. Een aantoonbare exit binnen redelijke tijd doet voor werkelijke soevereiniteit meer dan de meeste herkomstvereisten: het maakt van “wie kan mijn diensten uitzetten” een vraag met een antwoord in plaats van een angst. Gelukkig wordt een geteste exit steeds vaker een onderdeel van aanbestedingen en dit is mijns inziens een belangrijker vraag dan die van herkomst. Want in een oorlogsscenario zou je applicaties misschien wel willen verplaatsen naar een ander continent. Er zijn een aantal initiatieven om een standaard te maken voor kerndiensten, maar behoudens Kubernetes zijn deze nog niet klaar, laat staan algemeen geaccepteerd.

Wat betekent dit voor SEAL‑4?

Dit is de eerste laag in deze serie waar SEAL‑4 niet bij voorbaat onhaalbaar is. Software kun je in Europa schrijven, cryptografie beheersen we, in HSM’s hebben we echte thuisspelers, en met Kubernetes ligt er een open standaard waar geen enkele leverancier eigenaar van is. Wie hier een SEAL‑4‑ambitie neerlegt, vraagt niet het onmogelijke. De keten eronder is waar een groot deel van de uitdaging ligt, want die is grotendeels niet‑Europees en dus is SOV‑5 hier niet volledig af te vinken. De andere uitdaging zit niet in het ontwerp maar in de operatie, de schaal en het tempo, en dat zijn precies de dingen die serieuze investeringen en jaren van arbeid kosten in plaats van een besluit.

En dat brengt ons weer bij hetzelfde advies uit de vorige delen: gebruik het framework niet dogmatisch. Kijk waar een bepaald SEAL niveau echt nodig is, hetgeen aan de ene kant gaat over welke applicaties welk niveau nodig hebben en aan de andere kant over welke delen van de applicatie (inclusief aanpalende functies zoals beveiligingsdiensten) welk niveau nodig hebben. Een applicatie kan vereisen om in omgeving met een hoog SEAL niveau te draaien, maar die kan vaak best gebruik maken van (vervangbare) diensten er omheen zoals een DDoS beveiliging.

In het volgende deel klimmen we opnieuw een laag omhoog, naar de diensten op hoger niveau: databases, messaging, analytics en AI. Dat is de laag waar klanten hun daadwerkelijke voordeel halen, maar ook waar lock‑in echt begint.