In deel 1 beschreef ik het Cloud Sovereignty Framework en de vraag of SEAL‑4 überhaupt nodig is, en voor wie. In deel 2 begon ik onderaan, bij de datacenters. In deel 3 behandelde ik de infrastructuur, waar de toeleveringsketen van chips pijnlijk duidelijk maakte dat Europa daar vooralsnog toeschouwer is. In dit deel behandel ik het platform, de laag die de infrastructuur automatiseert en beveiligt. Dit is de laag waar de cloud zich onderscheidt van reguliere hosting. Het platform is wat van datacenters met servers een cloud maakt: het verdeelt capaciteit, houdt bij wat waar draait, herstelt storingen, houdt zichzelf en klantomgevingen veilig, isoleert klanten van elkaar en bepaalt wie wat mag. Omdat deze laag uit software bestaat, kan je hier aan de slag zonder eerst voor miljarden een fabriek te bouwen, hetgeen het theoretisch makkelijker maakt om deze laag zelf te bouwen. Het is echter niet de bouw maar de operatie die deze laag complex maakt, doordat hier constante ontwikkelingen plaatsvinden.

Zoals beloofd stel ik ook hier dezelfde twee vragen: Wat heb je nodig voor de bouw en wat heb je nodig voor de operatie?

Wat doet het platform eigenlijk?

Het platform is niet één ding. Het is nuttig om het onderscheid te maken tussen control plane en data plane. De data plane is waar het werk gebeurt voor klanten. Hier leven hun virtuele machines, opslag, netwerk, enzovoorts. De control plane is het besturingssysteem van de cloud zelf. Het verwerkt aanvragen zoals “geef mij vier VM’s met deze specificaties in deze regio”, zoekt er capaciteit bij, richt de netwerken in, koppelt de opslag, houdt de gewenste toestand bij en grijpt in als de werkelijkheid daarvan afwijkt. De control plane omvat verder systemen voor toegangsbeheer, logging, monitoring, encryptie en nog veel meer om de cloud draaiende en veilig te houden.

Het onderscheid tussen control plane en data plane is geen technisch detail. De data plane is waar de data van klanten leeft en waar elke klant controle heeft over de eigen omgeving. De control plane daarentegen staat onder controle van de cloud provider en dient zo ingericht te zijn dat de cloud provider geen toegang heeft tot klantdata. Of in ieder geval dat wanneer dat onverhoopt toch nodig is, dat dit gecontroleerd gebeurt en er een auditlog van gemaakt wordt, zodat alle acties traceerbaar zijn. Dat is belangrijk om na te kunnen gaan wat er fout is gegaan of hoe een lek heeft kunnen ontstaan bij een (security) incident, maar ook omdat aangetoond kan worden dat voldaan wordt aan allerlei wet- en regelgeving, en globale-, lokale-, of industrie-certificeringen zoals ISO 27001 en 27018, SOC 1 tot 3, BIR 2012 (NL), PCI-DSS en SOX. Hyperscale clouds hebben vele van dit soort certiceringen en behoren daarmee tot de meest geaudite systemen op de planeet.

Dat clouds zoveel geaudit wordt is enorm belangrijk. Want wie het control plane beheerst, beheerst de cloud. Dat betekent dat cloud providers moeten kunnen aantonen dat ze er alles aan doen om de systemen van hun klanten in de lucht te houden tijdens allerlei soorten incidenten en te beschermen tegen cyberaanvallen, zonder dat ze klantdata zien tenzij strikt noodzakelijk. En dit is waar in het soevereiniteitsdebat de vraag gesteld wordt “wie kan mijn diensten uitzetten?” Dat gaat namelijk feitelijk over de platformlaag en grotendeels over SOV‑3 en SOV‑6 uit het framework, over operationele autonomie en beheer.

Virtualisatie: waar het platform op de infrastructuur leunt

Het platform virtualiseert de infrastructuur, maar het kan dat alleen veilig doen door te steunen op wat er in de hardware aan beveiliging zit. Dat is de directe voortzetting van deel 3.

De hardware root of trust die ik daar beschreef (Cerberus, Nitro, Titan, en in open vorm Caliptra) verifieert de firmware voordat de machine opstart. Het platform bouwt daarop verder met measured boot: elke schakel in de opstartketen meet de volgende en legt die meting vast, zodat de hypervisor pas draait als bewezen is dat er onderweg niets veranderd is. Zonder die hardwarelaag is een veilige hypervisor een aanname; met die laag is het een cryptografisch controleerbaar feit. Dat is de reden waarom je deze lagen niet los kunt kopen: een soeverein platform op niet-geattesteerde hardware is een slot op een deur zonder muur.

Datzelfde geldt voor de isolatie tussen klanten. De hypervisor scheidt VM’s van elkaar, maar leunt daarbij volledig op geheugenbeveiliging in de processor. En de moderne stap verder, Confidential Computing, gaat nog een niveau dieper. Met technologie als AMD SEV‑SNP en Intel TDX wordt het geheugen van een VM versleuteld met een sleutel die de hypervisor zelf niet heeft. De beheerder van het platform kan de machine starten, stoppen en verplaatsen, maar niet in het geheugen kijken.

In het soevereiniteitsdebat dit minder aandacht dan zou moeten. De angst achter SOV‑2 en SOV‑7 is namelijk dat iemand met beheerrechten (of iemand die die rechten juridisch afdwingt) bij je data kan. Confidential Computing haalt precies die mogelijkheid technisch weg. Het is dezelfde redenering als bij hardware-integriteit in deel 3: je hoeft de beheerder niet te vertrouwen als de wiskunde het overneemt. Het maakt herkomst niet irrelevant, maar het verschuift de vraag van “wie is de eigenaar” naar “wie kan er technisch bij”, en dat is de vraag die er in de praktijk toe doet.

Een derde stuk dat vaak vergeten wordt: bij hyperscalers draait een groeiend deel van het control plane helemaal niet meer op de CPU van de server, maar op aparte hardware. Netwerkvirtualisatie, opslagverkeer en beveiligingsregels worden daar afgehandeld, fysiek gescheiden van de omgeving waar de klant zijn code draait. Daarmee is er geen software van de klant die op dezelfde processor draait als de beheerlaag. Dat is architectuur als beveiliging, en het is een van de duidelijkste voorbeelden van wat schaal je oplevert: zo’n kaart ontwikkel je alleen als je er honderdduizenden van gebruikt.

Toegang: hoe je zorgt dat niemand te veel rechten heeft

Nu de vraag die in mijn ogen het hart van deze laag raakt. Want als het control plane de macht is, dan is de mens met toegang tot het control plane het risico.

De reflex in kleine organisaties is een groep vertrouwde beheerders met brede rechten, gescreend en van onbesproken gedrag. Dat werkt, tot iemand een fout maakt, tot iemands account overgenomen wordt, of tot iemand onder druk gezet wordt. Screening beschermt tegen slechte intenties, niet tegen gestolen credentials, en de meeste incidenten beginnen niet bij een kwaadwillende medewerker maar bij een gecompromitteerde legitieme sessie.

Hyperscalers lossen dat structureel anders op, en het principe is confronterend simpel: standaard heeft niemand rechten. Geen enkele engineer heeft permanente toegang tot productie. Wat er in plaats daarvan staat, is een stapel maatregelen die samenwerken:

• Just-in-time access- Toegang wordt aangevraagd voor een specifieke taak, een specifiek systeem en een beperkte tijdsduur, met een expliciete reden die aan een ticket of incident gekoppeld is. Na afloop vervalt de toegang automatisch. Een compromittering van een engineer-account levert daarmee op een willekeurig moment niets op, want er hangt niets aan.
• Goedkeuring door een ander – Voor gevoelige acties is een min-of-meer willekeurig gekozen tweede persoon nodig die de aanvraag goedkeurt. Dat is geen bureaucratie maar hetzelfde principe als twee sleutels voor een kluis: één persoon kan niet op eigen houtje toegang krijgen.
• Geen menselijke toegang tot klantdata – De beheerinterfaces zijn zo ontworpen dat een engineer diagnostiek kan doen zonder de inhoud te zien. Waar dat onvermijdelijk is, zit er een expliciete, goedgekeurde en gelogde procedure omheen, en bij Confidential Computing is het technisch buitengesloten.
• Break-glass als uitzondering, niet als achterdeur – Er is altijd een noodprocedure, maar het gebruik daarvan zet alarmen af, is achteraf volledig te reconstrueren en wordt standaard onderzocht.
• Geen mensen aan de knoppen, maar code – Dit is misschien wel het belangrijkste en tegelijk het minst begrepen. Beheer gebeurt niet door in te loggen en commando’s te typen, maar door een wijziging aan te bieden aan een geautomatiseerde pijplijn: code review, geautomatiseerde tests, gefaseerde uitrol over zones en regio’s, automatische terugrol bij afwijkende signalen. De engineer heeft geen rechten op het systeem; de pijplijn heeft ze. Daarmee is elke wijziging per definitie beoordeeld, gelogd en herleidbaar tot een persoon en een reden.

Wat je hier ziet is dat “niemand met te veel rechten” niet een kwestie van vertrouwen is, maar van ontwerp. En hier zit een ongemakkelijk punt voor de soevereiniteitsdiscussie. De eis die je in aanbestedingen vaak ziet, “alleen EU-personeel met EU-nationaliteit mag toegang hebben tot het beheer”, meet nationaliteit. Wat er werkelijk toe doet is of er überhaupt iemand is die iets kan zonder tweede persoon, zonder ticket, zonder logging en zonder tijdslimiet. Een kleine soevereine “cloud” met tien volledig Nederlandse beheerders die permanente rootrechten hebben, is aantoonbaar kwetsbaarder dan een omgeving waar niemand standaard rechten heeft, ongeacht paspoort.

En hier zit nog een ander operationeel aspect aan. Als je toegang op deze manier kunt waarborgen, is het mogelijk om beheerders te hebben over de hele wereld, hetgeen voor 24×7 operatie een groot voordeel is, omdat je daarmee kosten kunt beperken (bijvoorbeeld geen extra kosten voor nachtdienst) en de beste experts in de wereld operaties kan laten uitvoeren op een veilige, gecontroleerde manier.

Automatisering en monitoring: waarmee de schaal mogelijk wordt

In deel 1 schreef ik dat het securitysignaal van een hyperscaler wereldwijd is en dat een afgeschermd nationaal eiland slechts een fractie daarvan ziet. Op de platformlaag wordt concreet waarom dat zo veel uitmaakt, want het zijn juist automatisering en monitoring die elkaar hier versterken.

Monitoring zonder automatisering levert alarmen op die door mensen afgehandeld moeten worden. Dat schaalt niet. Meer systemen betekent meer alarmen betekent meer ruis betekent alarmmoeheid, en alarmmoeheid is hoe echte incidenten gemist worden. Automatisering zonder monitoring is blind. Je rolt fouten net zo efficiënt uit als verbeteringen. En dit is ook waarom de monitoring data zo belangrijk is. Het is de motor van constante verbeteringen.

De combinatie is wat het verschil maakt. Bij een hyperscaler is het platform zelf de bron van de waarheid. Het weet exact welke configuratie er hoort te draaien en elke afwijking daarvan is per definitie verdacht. Een server die van de norm afwijkt wordt niet onderzocht maar automatisch uit rotatie gehaald en opnieuw opgebouwd. Een gedragspatroon dat afwijkt (een beheeraccount dat op een ongebruikelijk tijdstip een ongebruikelijke API aanroept) is detecteerbaar juist omdat het normale gedrag zo strak gedefinieerd is.

Daar komt het volumeargument bovenop, en dat is geen marketing maar statistiek. Detectie van afwijkend gedrag vereist een betrouwbaar beeld van normaal gedrag. Hoe meer signaal, hoe scherper dat beeld en hoe kleiner de afwijking die je nog betrouwbaar kunt opmerken. Een omgeving met duizend servers ziet te weinig om subtiele patronen boven de ruis uit te tillen. Een omgeving met miljoenen ziet ze wel, en kan een detectieregel die bij één klant werkt binnen minuten wereldwijd uitrollen. Datzelfde geldt voor patchen. Bij volledig geautomatiseerd vlootbeheer kan in uren tot dagen de hele vloot bijgewerkt zijn, met bewijs dat het overal gebeurd is. Bij (deels) handmatig patchen duur dit veel langer en moet bewijs verzameld worden.

En dan is er nog het personele argument, dat ik in deel 1 al aanstipte. Een securityteam dat 24/7 dekking moet bieden heeft, met vakantie, ziekte en verloop, al gauw acht tot tien mensen nodig voor één functie. Voor een volwaardig operationeel securitycentrum met detectie, respons, threat intelligence, forensics en red teaming zit je op tientallen tot honderden mensen. Bij de hyperscalers zijn dat er duizenden. Voor een Europese speler met een paar duizend medewerkers in totaal is dat niet een kwestie van willen, maar van kunnen, in een arbeidsmarkt waar deze mensen structureel schaars zijn.

Ik zeg dit niet om kleine partijen af te schrijven, maar om te laten zien dat schaal op zichzelf een factor is. Om een serieuze Europese cloud te hebben, moet je niet alleen de supply chain en operatie onder controle hebben, maar is schaal een voorwaarde voor succes. Dat levert een kip-ei probleem op, want de schaal is nodig om lagere kosten en hogere kwaliteit te realiseren, maar die schaal haal je alleen maar als je kosten-kwaliteit verhouding niet te ver uit de pas loopt met wat de Amerikaanse clouds kunnen leveren.

De bouwvraag: welke opties zijn er?

Er zijn verschillende routes om de control plane op te bouwen. Zo zou je kunnen beginnen met een virtualisatieplatform zoals VMWare en Nutanix, of een open source alternatief daarvoor zoals Proxmox. Ook zou je op basis van Kubernetes aan de slag kunnen gaan en KubeVirt gebruiken voor als je toch virtuele machines moet ondersteunen (en dat moet je). Aangezien Kubernetes open source is, en ook nog eens een defacto standard voor cloud-native applicaties, zijn er voldoende opties. Maar een virtualisatie- en containerplatform is nog geen cloud. Ten eerste is een dergelijke omgeving vooral bedoeld voor één organisatie en niet een multi-tenant omgeving voor vele organisaties. Ten tweede doet de control plane meer dan alleen wat gevirtualiseerde compute, opslag en network optuigen. Het is het hart van de cloud en er zit een ribbenkast aan zaken omheen om de cloud robuust en veilig te houden, en om Andere diensten bovenop aan te kunnen bieden. Hier zijn wel een aantal opties voor.

OpenStack is de bekendste. Het project startte in 2010 en het wordt beheerd door de Open Infrastructure Foundation. Het is uitgegroeid tot een verzameling van losjes gekoppelde diensten: Nova voor compute, Neutron voor netwerken, Cinder en Swift voor opslag, Keystone voor identiteit, Ironic voor bare metal. Een aantal Europese providers gebruikt OpenStack: OVHcloud, T-Systems, Cleura en kleinere nationale spelers. De kracht is de modulariteit en het feit dat het bewezen is op grote schaal. De prijs is complexiteit: OpenStack is berucht om zijn operationele zwaarte, en de kennis om het op grote schaal draaiend te houden is een schaars en duur goed. Het is geen product dat je installeert, het is een discipline die je opbouwt.

OpenNebula is de tegenpool van OpenStack. Het veel eenvoudiger van opzet en ontworpen om met een klein team een aanzienlijke omgeving te beheren. Het schaalt prima naar duizenden hosts en is sterk in edge- en gedistribueerde scenario’s. Precies daarom is het interessant voor een Europese speler die niet de personele diepte van een hyperscaler heeft. Wat het niet doet, is de breedte van diensten leveren die klanten van een hyperscaler verwachten.

Apache CloudStack valt in dezelfde categorie als OpenNebula. Het is een volwassen alternatief dat vooral bij hostingproviders gebruikt wordt en aanzienlijk eenvoudiger te bedienen is dan OpenStack.

Dat deze platformen open source zijn heeft het voordeel dat er iets is waarop voortgebouwd kan worden. Maar dit verschilt wezenlijk van hoe een hyperscaler werkt. De platformsoftware is bij een hyperscaler sterk geintegreerd met de hardware, wat het geheel sneller, robuuster en veiliger maakt dan het bij elkaar brengen van onderdelen die niet op elkaar afgestemd zijn. Dat is geen open source, maar zoals aangegeven zijn er allerlei andere waarborgen voor klanten die misschien wel belangrijker zijn.

De eerlijke conclusie voor de bouwvraag: op de platformlaag is SEAL‑4 technisch haalbaar. De software kan Europees zijn, de code kan in Europa geschreven worden, en de open projecten liggen er. Wat ontbreekt is niet de blauwdruk, maar de jaren aan operationele ervaring die nodig zijn om zo’n platform op hyperscale betrouwbaar te maken. Dat is niet te kopen, dat moet je meemaken. En dan kom je bij de operatie en de toeleveringsketen.

De operatie en toeleveringsketen

Dat het de platform software open source kan zijn en daarmee Europees gemaakt kan worden is natuurlijk mooi. Maar hoewel de software an sich belangrijk is, gaat het in deze laag vooral de constante verbeteringen om de operatie nog robuuster, nog veiliger, en met nog minder overhead te kunnen maken. Open source is daar een belangrijke component in, ook voor hyperscalers, maar niet de enige. Het open source deel bestaat uit de Linux-kernel, KVM, de container-runtimes, cryptografische bibliotheken, honderden pakketten die elk hun eigen afhankelijkheden meebrengen. Formeel gezien is dat geen SOV‑5-probleem, want een open licentie kent geen jurisdictie en kan niet met terugwerkende kracht ingetrokken worden. Praktisch gezien is het wel degelijk een afhankelijkheid, alleen een andere dan het framework meet. Want een licentie kun je niet intrekken, maar de mensen die de code onderhouden kun je wel kwijtraken, overnemen, of onder druk zetten.

Verder gaat het om de operatie van de schil eromheen: capaciteitsplanning die maanden vooruit kijkt, geautomatiseerde uitrol van nieuwe hardware zonder downtime, live migration van honderdduizenden workloads tijdens onderhoud, foutdomeinen die zo ontworpen zijn dat een defecte hardware geen klant raakt, en een control plane dat zelf ook nog eens over drie availability zones verdeeld is en een quorum vormt (precies de reden waarom er in deel 2 drie zones stonden en geen twee). Die laag is bij de hyperscalers geen open source, en dat is meteen het echte gat.

De maintainer als kritieke component… en risico

Dit is de laag waar de toeleveringsketen niet uit fabrieken bestaat maar uit mensen, en dat maakt hem lastiger te meten en makkelijker te negeren.

Het beeld dat de meeste bestuurders van open source hebben, is dat van een wereldwijde massa vrijwilligers die elkaars werk controleert: veel ogen, dus weinig bugs. Voor de grootste projecten klopt dat ook. Voor het overgrote deel van wat er in je stack zit, klopt het niet. Het Census II-onderzoek van Harvard en de Linux Foundation keek naar de vijftig meest gebruikte niet-npm-componenten en vond dat bij 23% van die projecten één enkele ontwikkelaar meer dan 80% van de toegevoegde regels code schreef, en dat bij 94% van de projecten minder dan tien ontwikkelaars goed waren voor meer dan 90% van de code. Dat is de werkelijke vorm van deze afhankelijkheid. Niet een land dat een kraan dichtdraait, maar een handvol mensen dat het volhoudt. En dat is precies waar het XZ Utils-incident van 2024 op inhaakte: een bijdrager bouwde jarenlang geduldig vertrouwen op bij een uitgeputte solo-maintainer van een breed gebruikte compressiebibliotheek, nam het onderhoud over en plaatste er een achterdeur in die tot in de authenticatieketen van vrijwel elke Linux-distributie zou hebben gereikt. Het werd ontdekt doordat een ingenieur van Microsoft een prestatieafwijking van een halve seconde bij het inloggen te vreemd vond en ging graven. Toeval, met andere woorden. De kwetsbaarheid zat niet in de code, maar in het onderhoudsmodel: één overbelaste vrijwilliger op een pakket waar de halve wereld op leunt.

Voor het soevereiniteitsdebat is dit belangrijker dan het lijkt. Een EU-aanbesteding kan eisen dat de leverancier Europees is en dat het beheer in de EU plaatsvindt, en beide vinkjes kunnen groen staan terwijl de kritieke afhankelijkheid bestaat uit een niet-Europese vrijwilliger die geen contract, geen SLA en geen opvolger heeft. En dan hebben we het nog niet eens gehad over een scenario waar kwaadwillenden zich op de open source software supply chain richten. Dat is met AI (gelukkig) steeds beter op te sporen, maar vooralsnog is dat niet 100% waterdicht. Closed source in eigen beheer kan daarom in sommige gevallen veiliger zijn.

Wie draagt er dan werkelijk bij?

De cijfers zijn hier confronterender dan de open-sourceretoriek suggereert. Neem de Linux-kernel, het fundament van elk cloudplatform dat we in dit deel besproken hebben. In 2025 werd 84,3% van alle kernelcommits geschreven door mensen die daarvoor betaald worden, verdeeld over ruim 1.780 organisaties. Slechts zo’n 16% kwam van onafhankelijke of niet-toewijsbare bijdragers. De kernel is dus geen vrijwilligersproject meer, maar een industrieel samenwerkingsverband, en de vraag wie er bijdraagt is daarmee de vraag welke bedrijven erin investeren. Google, Intel, Meta en Oracle tekenenen voor meer dan 60% van de bijdragen, en daar komen partijen als AMD, Huawei, en Red Hat nog bovenop.

Zoom je uit naar open source in het algemeen, dan wordt het beeld niet anders. De Open Source Contributor Index, die bedrijven rangschikt naar het aantal actieve bijdragers op GitHub, wordt medio 2026 aangevoerd door 8 Amerikaanse bedrijven, gevolgd door Huawei en op plaats 10 SUSE. Reken je die tien tegen elkaar af, dan komt ruim 90% van de actieve bijdragers uit Amerikaanse bedrijven, ongeveer 4,8% uit China en ongeveer 4,5% uit Europa, en dat laatste percentage bestaat vrijwel volledig uit één bedrijf: SUSE.

Bij OpenStack, het platform waar de Europese cloudsector het meest op leunt, ligt de verdeling gunstiger: Red Hat en SUSE zijn er groot, en Europese providers als OVHcloud, T‑Systems, Cleura en het Duitse SysEleven dragen daadwerkelijk bij. Maar OpenStack is ook een project waar de commerciële energie sinds het vertrek van een aantal grote Amerikaanse en Chinese sponsors juist is teruggelopen, en dat is niet zonder risico als je er je hele platformlaag op bouwt. OpenNebula is een van de weinige echt Europese cloudprojecten met een Europese onderneming eromheen, maar de contribuerende gemeenschap is naar verhouding klein, en dat is precies het patroon uit Census II in het klein.

Één belangrijke nuance bij al deze cijfers: ze meten werkgever, niet nationaliteit. Een Duitse ontwikkelaar in dienst van Google in München telt in deze statistiek als Google. Er is opvallend weinig betrouwbare data over waar bijdragers fysiek zitten, en dat is op zichzelf al een bevinding: de discussie over “wie schrijft de code die wij draaien” wordt gevoerd zonder dat iemand er goede meetgegevens over heeft. Wat we wél weten is wie de rekening betaalt, en dat is overweldigend niet-Europees.

Wat betekent dat nu echt?

Ik wil twee verkeerde conclusies voorkomen:

• De paniekconclusie: “de code is Amerikaans, dus we zijn niet soeverein”. Zo werkt open source niet. De GPL en de Apache-licentie zijn onherroepelijk voor code die al vrijgegeven is, en de kernelbroncode staat op honderdduizenden plekken. Niemand kan Linux uitzetten. Als Intel morgen zou stoppen met bijdragen, blijft alles draaien wat er draait.
• De geruststellingsconclusie: “het is open source, dus het is van iedereen en er is geen probleem”. Ook dat klopt niet, want de afhankelijkheid zit niet in de code van vandaag maar in de ontwikkeling van morgen. Wie de bijdragen domineert, bepaalt de richting: welke hardware ondersteund wordt, welke beveiligingsfuncties er komen, welke architectuur prioriteit krijgt en hoe snel een kwetsbaarheid gepatcht is. Als Europa 4,5% van de bijdragen levert, heeft Europa 4,5% van de stem over waar het fundament van zijn eigen cloud heen beweegt. En het praktische risico is scherper dan het principiële: raakt een project onderhouden door een handvol mensen wiens werkgever de stekker eruit trekt, dan heb je code die formeel vrij is maar feitelijk een risico vormt.

Er is bovendien een asymmetrie die zelden benoemd wordt: de Amerikaanse hyperscalers financieren een groot deel van het open-source-onderhoud waar de Europese providers gratis van profiteren. Elke Europese OpenStack-cloud draait op een kernel die voor het overgrote deel door Intel, Google, Red Hat, Oracle, Meta en AMD onderhouden wordt. Dat is geen verwijt aan die providers, het is hoe open source hoort te werken, maar het maakt de retoriek van “onafhankelijk van de Amerikanen” wel wat minder stevig dan ze klinkt.

Wat je eraan kunt doen

Het goede nieuws is dat dit, anders dan een chipfabriek, een probleem is dat met relatief bescheiden bedragen wél op te lossen valt. De maatregelen zijn bekend en grotendeels dezelfde beweging als bij hardware in deel 3: van herkomst naar integriteit, en van consumeren naar bijdragen.

Aan de technische kant: reproduceerbare builds, ondertekende artefacten, een software bill of materials die vastlegt wat er precies in een image zit, geautomatiseerde controle daarop bij elke uitrol, en een eigen gecontroleerde bouwketen in plaats van pakketten rechtstreeks van internet trekken.

Aan de menselijke kant: in kaart brengen welke componenten in je platform door minder dan een handvol mensen worden onderhouden (dat is te automatiseren), en daar structureel geld en menskracht in stoppen. Initiatieven als het Sovereign Tech Agency in Duitsland, dat rechtstreeks investeert in het onderhoud van kritieke open-sourcecomponenten, en het Nederlandse en Europese beleid om open source in de publieke sector te bevorderen, zijn hier veel effectiever besteed geld dan menig soeverein datacenterproject.

Dat is, denk ik, de meest onderschatte investeringskans in dit hele soevereiniteitsdebat. Een fabriek voor geavanceerde chips kost tientallen miljarden en een decennium. Een serieuze Europese positie in het onderhoud van de open source waar de platformlaag op draait, kost een paar honderd miljoen en een paar jaar, en levert directe zeggenschap op over de richting van de software die je hoe dan ook gaat draaien.

Wat betekent dit voor SEAL‑4?

De platformlaag kan in theorie Europees zijn. De software kan Europees zijn, de open bouwstenen liggen er, de code kan in Europa geschreven en beheerd worden, en de operatie kan volledig onder EU-recht vallen. Anders dan bij de hardware is er hier geen fysieke onmogelijkheid. Er zijn echter wel een aantal belangrijke kanttekeningen.

De beveiliging van deze laag zwaar op de laag eronder. Measured boot, attestatie en confidential computing zijn platformfuncties die alleen werken dankzij eigenschappen van hardware die overwegend niet-Europees is. Een soeverein platform op niet-soevereine hardware is prima verdedigbaar, maar het is conform het framework geen SEAL‑4.

Ten tweede is het echte onderscheid van een hyperscaler op deze laag niet de virtualisatie maar de operatie eromheen: de automatisering, het vlootbeheer, de detectiecapaciteit en de toegangsdiscipline. Dat is geen software die je installeert, het is een organisatie die je opbouwt, en daar gaan jaren overheen. Het bestaat uit geïnstutionaliseerde kennis en processen. Hier is ook nog wel wat goed nieuws. De mensen die dat opgebouwd hebben zijn niet uitsluitend Amerikanen in de VS. De hyperscalers hebben allerlei nationaliteiten in dienst en op meerdere plaatsen. Zo zijn er ook ontwikkelteams in verschillende Europese landen. De mensen die dit al eens gedaan hebben, wonen ook in Europa. Aandachtspunt daarbij is wel is dat kleinere Europese providers vaak bij lange na niet dezelfde beloningen kunnen bieden.

Ten derde is de open source waarop het hele verhaal rust maar in beperkte mate Europees. Je kunt een volledig Europees platform bouwen op een fundament waarvan meer dan negen van de tien bijdragen uit Amerikaanse bedrijven komen. Dat is geen kill-switch-risico, maar het is wel een zeggenschapsrisico, en op de langere termijn een continuïteitsrisico bij de kleinere componenten. Bijdragen is hier het enige echte antwoord: soevereiniteit in software koop je niet, die verdien je met commits.

Ten vierde, en dat is het punt dat ik het liefst zou willen dat de aanbestedingspraktijk overneemt: op deze laag is de belangrijkste beveiligingsvraag niet “wie is de eigenaar” maar “wie kan er technisch bij, en onder welke voorwaarden”. Zero standing access, goedkeuring door een tweede persoon, volledige logging en beheer via geautomatiseerde pijplijnen leveren aantoonbaar meer beveiliging op dan een nationaliteitseis. Ze zijn ook nog eens goed te meten en te auditen. Vraag beide, maar begin bij de tweede.

Daarmee eindigt deze laag waar de vorige twee ook eindigden: het framework is uitstekend in het blootleggen van waar de kwetsbaarheden zitten, en gevaarlijk zodra je het dogmatisch toepast. In het volgende deel klimmen we naar de kerndiensten: VM’s, containers, storage, networking, identity en keys, waar de belofte van soevereiniteit voor het eerst rechtstreeks in aanraking komt met wat klanten daadwerkelijk afnemen.