Soevereine cloud voor defensieministeries: dataresidency, control planes en nationale cloudarchitectuur

Door Corvus Intelligence Engineering Team · Over het team →

25 juni 2026 Bijgewerkt: 25 juni 2026 12 min leestijd

Elk defensieministerie dat workloads naar de cloud heeft verplaatst, stuit uiteindelijk op dezelfde spanning: commerciële hyperscalers leveren functies — beheerde databases, AI/ML-platformen, wereldwijd netwerken — die geen nationale aanbieder kan evenaren, maar dezelfde hyperscalers zijn buitenlandse bedrijven die vallen onder het juridische apparaat, de exportcontroles en de toegangseisen van de inlichtingendiensten van hun thuisregering. De term “soevereine cloud” beschrijft de poging die spanning op te lossen zonder een van de uitersten te aanvaarden: noch volledige hyperscalerafhankelijkheid, noch een technologisch bevroren nationaal mainframe. De architectuur die daaruit voortkomt is nooit eenvoudig, en de afwegingen zijn zelden duidelijk totdat ze in productie al zijn gemaakt.

Dit artikel onderzoekt de technische architectuur van soevereine cloud voor defensieministeries — niet als een aanbestedingschecklist, maar als een engineeringprobleem. We behandelen wat soevereiniteit in elk van haar drie dimensies feitelijk betekent, hoe u een nationale control plane ontwerpt die verstoring door leveranciers overleeft, welke hyperscalercomponenten onaanvaardbaar soevereiniteitsrisico introduceren, hoe de open-source soevereine stack er in productie uitziet en hoe u soevereiniteitsbeperkingen balanceert met de operationele capabiliteitseisen van de moderne defensie. Voor context over de bredere beveiligingseisen van workloads zie onze gids over cloudbeveiliging voor militaire workloads.

1. Wat cloudsoevereiniteit voor een defensieministerie betekent

De term “soevereine cloud” wordt door leveranciers voor bijna alles gebruikt — een datacenter in eigen land, een contractuele toezegging over dataresidency, een lokale rechtspersoon — en bijna niets van wat hij in leveranciersmarketing betekent, is voldoende voor een serieuze architectuurbeoordeling bij een defensieministerie. Echte cloudsoevereiniteit voor defensie omvat drie verschillende eisen die onafhankelijk van elkaar moeten worden beoordeeld, omdat het voldoen aan de ene niet inhoudt dat aan de andere is voldaan.

Dataresidency is de garantie dat geclassificeerde of gevoelige gegevens uitsluitend binnen het nationale grondgebied of een goedgekeurde jurisdictionele grens worden opgeslagen, verwerkt en verzonden — en dat het ministerie, niet de cloudleverancier, de encryptiesleutels beheerst die hen beschermen. Dataresidency is de meest besproken soevereiniteitseis en het gemakkelijkst te faken: een contractuele toezegging dat gegevens in het land blijven, is juridisch niet afdwingbaar tegen een dagvaarding van de inlichtingendienst van een buitenlandse regering en biedt geen technische bescherming tegen een verkeerd geconfigureerde replicatietaak die gegevens naar een beschikbaarheidszone buiten het land kopieert.

Operationele soevereiniteit is het vermogen het cloudplatform te blijven exploiteren zonder de voortdurende medewerking van een buitenlandse leverancier — inclusief het vermogen het faillissement van een leverancier, commerciële sancties, wijzigingen in exportcontroles of de dwang van een buitenlandse regering op een leverancier om dienstverlening te weigeren of te verslechteren te overleven. Operationele soevereiniteit vereist dat het ministerie elke component van het platform alleen met documentatie en broncode kan exploiteren, zonder doorlopende afhankelijkheid van propriëtaire leverancierondersteuning die kan worden ingetrokken.

Soevereiniteit over de toeleveringsketen is de controle over de software- en hardwarecomponenten waarmee de cloud wordt gebouwd en geëxploiteerd. Een platform dat is gebouwd op auditabele open-sourcesoftware op servers van een niet-geallieerde fabrikant voldoet aan geen van beide dimensies: de softwarelaag is wellicht auditabel, maar de hardwarefirmware misschien niet. Een volledige analyse van de ketensoevereiniteit dekt processorfirmware, besturingssystemen van netwerkapparatuur, firmware van opslagcontrollers en de softwarebibliotheken waarvan elke component in de soevereine stack afhankelijk is.

De meeste hedendaagse soevereine cloudarchitecturen van defensieministeries voldoen gedeeltelijk aan dataresidency, gedeeltelijk aan operationele soevereiniteit en minimaal aan ketensoevereiniteit. Het doel van het expliciet maken van de drie dimensies is een eerlijke risicobeoordeling mogelijk te maken, in plaats van valse geruststelling uit een “soevereine cloud”-certificering die alleen de meest zichtbare dimensie behandelt.

2. Afdwinging van dataresidency

Technische maatregelen voor dataresidency werken op drie lagen: residency van encryptiesleutels, afdwinging van gegevenslocatiebeleid, en audit en verificatie. Alle drie zijn vereist; elke afzonderlijke laag is onvoldoende.

Residency van encryptiesleutels is de belangrijkste technische maatregel, omdat zij bepaalt of gegevens buiten de goedgekeurde grens kunnen worden ontsleuteld, zelfs nadat zij fysiek zijn geëxfiltreerd. De eis is dat de hardware security module (HSM) of key management service (KMS) die de encryptiesleutels vasthoudt, fysiek binnen het nationale grondgebied staat en onder de operationele controle van het ministerie of een nationaal geaccrediteerde organisatie valt — niet de beheerde KMS van een buitenlandse cloudleverancier, waar het uiteindelijke sleutelmateriaal in hardware ligt die de leverancier beheerst. In de praktijk betekent dit:

Een on-premises HSM (Thales Luna, Utimaco SecurityServer of gelijkwaardig) voor de hoogste classificatieniveaus, waarbij de HSM fysiek is beveiligd en geauditeerd onder het fysieke beveiligingsbeleid van het ministerie
Een KMS van een nationale cloudaanbieder, ondersteund door HSM-hardware in eigen land, voor lagere classificatieniveaus waar beheerde sleuteldiensten acceptabel zijn
Envelope-encryptie: data-encryptiesleutels (DEK's) worden per object of per volume gegenereerd en versleuteld met key-encryptiesleutels (KEK's) die in de HSM worden vastgehouden — de HSM houdt nooit ruwe gegevens vast, alleen sleutelmateriaal
Logregistratie van sleuteltoegang die gescheiden van en onafhankelijk is van de auditlog van het opslagsysteem, zodat ongeautoriseerde pogingen tot sleuteltoegang zichtbaar blijven, ook als de opslaglaag is gecompromitteerd

Afdwinging van gegevenslocatiebeleid vereist dat opslagdiensten — objectopslag, blockvolumes, database-instanties — op het niveau van de platformconfiguratie worden beperkt tot beschikbaarheidszones in eigen land, niet slechts door een beleidsverklaring. In een OpenStack-implementatie betekent dit het configureren van affinity-regels voor beschikbaarheidszones in Cinder en Swift die de plaatsing van replica's buiten de gedefinieerde zone verhinderen. In een hyperscalerimplementatie betekent dit het gebruik van service control policies (AWS) of Azure Policy-definities die het aanmaken van elke opslagresource in regio's buiten het land weigeren, toegepast op het niveau van het management-account of de managementgroep, zodat individuele workloadteams ze niet kunnen omzeilen.

Audit en verificatie is het doorlopende operationele proces dat bevestigt dat de maatregelen voor dataresidency werken zoals ontworpen. De auditlaag moet onafhankelijk zijn van de opslaglaag — de entiteit die gegevens opslaat, kan niet de enige entiteit zijn die verifieert waar gegevens worden opgeslagen. Vereiste componenten:

Geautomatiseerde dagelijkse verificatie dat alle opslageindpunten die workloads gebruiken, uitkomen op IP-adressen in eigen land, met waarschuwing bij elk nieuw eindpunt
Monitoring van netwerkstromen die elk uitgaand verkeer van opslagdiensten naar IP-bereiken buiten het land markeert
Driemaandelijkse technische audit door derden van de maatregelen voor dataresidency, met rapportage van bevindingen aan de beveiligingsautoriteit van het ministerie
Configuratie-as-code voor al het gegevenslocatiebeleid, onder versiebeheer in een onveranderlijke repository, zodat beleidswijzigingen een detecteerbare diff genereren voordat zij effect hebben

Contractuele maatregelen — gegevensverwerkingsovereenkomsten, datalokalisatieclausules — zijn een noodzakelijke aanvulling op technische maatregelen, maar moeten nooit het primaire mechanisme zijn. Contracten begrenzen wat een meewerkende leverancier zal doen; zij begrenzen niet wat een leverancier doet onder juridische dwang van zijn thuisregering, en zij bieden geen bescherming tegen technische misconfiguratie.

3. Ontwerp van de nationale control plane

De control plane van een cloudplatform — de verzameling diensten die orkestratie, identiteit en secrets beheren — is waar het meest ingrijpende soevereiniteitsrisico ligt. In een Kubernetes-omgeving zijn de componenten van de control plane de API-server, het etcd-cluster, de scheduler, de controller manager en de admission-webhooks die beleid afdwingen op het moment van workloadcreatie. Als een van deze componenten draait op infrastructuur die door het operationele personeel van een buitenlandse hyperscaler wordt beheerd, heeft dat personeel de technische mogelijkheid (zelfs als het contractueel verboden is) workloadconfiguraties te wijzigen, secrets uit etcd te extraheren of de planning te verstoren op instructie van hun thuisregering.

Een ontwerp met een nationale control plane plaatst al deze componenten op infrastructuur die fysiek en organisatorisch onder controle van het ministerie staat. De praktische architectuur:

Kubernetes-API-server en etcd. Rol een zelfbeheerde Kubernetesdistributie uit — kubeadm voor maximale flexibiliteit, k0s voor vereenvoudigde exploitatie of Talos Linux voor een onveranderlijke OS-benadering — op bare metal of op VM's op hypervisors die het ministerie beheerst. Het etcd-cluster vereist drie of vijf knooppunten voor quorum, draaiend op dedicated hardware die niet wordt gedeeld met workloadnodes. Etcd-gegevens moeten in rust worden versleuteld met de KMS-providerplugin die op de nationale HSM is aangesloten. Maak back-ups van etcd-snapshots naar versleutelde objectopslag in eigen land, met geautomatiseerde hersteltests.

# Example kube-apiserver flag for national KMS encryption provider
--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

# encryption-config.yaml (excerpt)
resources:
  - resources: [secrets, configmaps]
    providers:
      - kms:
          name: national-hsm-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          cachesize: 1000
          timeout: 3s
      - identity: {}

Identity provider. Keycloak is de standaard open-source OIDC/SAML-identity provider voor soevereine clouduitrol. Rol Keycloak uit op dedicated nationale infrastructuur, geïntegreerd met de bestaande directory van het ministerie (Active Directory of LDAP via de federatieconnectoren van Keycloak). Configureer de Kubernetes-API-server om Keycloak als OIDC-authenticator te gebruiken:

# kube-apiserver OIDC flags
--oidc-issuer-url=https://keycloak.national.mil/realms/defense
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/keycloak-ca.crt

De beschikbaarheid van Keycloak ligt nu op het kritieke pad voor clusterauthenticatie. Rol Keycloak uit in een modus met hoge beschikbaarheid (minimaal drie Keycloak-instanties achter een interne load balancer, met een gedistribueerde cache voor sessiestatus) en documenteer de noodprocedure (break-glass) voor toegang tot de API-server wanneer Keycloak niet beschikbaar is — doorgaans een lokale kubeconfig met een clientcertificaat voor toegang als cluster-admin in noodsituaties, bewaard op een fysiek beveiligde locatie.

Secretbeheer. HashiCorp Vault (of zijn open-sourcefork OpenBao), uitgerold op nationale infrastructuur, levert de laag voor secretbeheer. Vault voert auto-unseal uit met de nationale HSM, waarmee het handmatige unseal-proces verdwijnt dat anders een single point of failure zou zijn voor het herstel van de control plane. De auditlog van Vault — elke lees- en schrijfbewerking op secrets — wordt in realtime naar de nationale SIEM gestuurd, buiten de blast radius van een gecompromitteerde Vault-uitrol.

4. Beoordeling van hyperscalerafhankelijkheid

De meeste cloudomgevingen van defensieministeries gebruiken minstens één hyperscaler voor een deel van hun infrastructuur — voor een soeverein-verbonden topologie, een zone voor noodherstel of legacy-workloads die nog niet zijn gemigreerd. Inzicht in welke hyperscalercomponenten soevereiniteitsrisico introduceren, is essentieel voor de beslissing per component tussen beheerd en zelf exploiteren.

Hoog soevereiniteitsrisico — moet worden vervangen of onafhankelijk worden geëxploiteerd:

Beheerde Kubernetes-control planes (EKS, AKS, GKE) — de API-server en etcd worden geëxploiteerd door hyperscalerpersoneel met bevoorrechte toegang; vervang door zelfbeheerde Kubernetes op IaaS-bouwstenen
Beheerde identity providers (AWS IAM, Azure Active Directory als primaire IdP) — gezaghebbende identiteitsbeweringen door buitenlands geëxploiteerde diensten; vervang door Keycloak of gelijkwaardig op nationale infrastructuur
Beheerde secretsopslag (AWS Secrets Manager, Azure Key Vault met door hyperscalers beheerde HSM's) — sleutelmateriaal in buitenlandse HSM's; vervang door zelfbeheerde Vault op een nationale HSM
Wereldwijde CDN- en edgenetwerken — verkeer geleid via points of presence buiten het land; schakel uit of beperk tot edge-nodes in eigen land

Gemiddeld soevereiniteitsrisico — acceptabel met aanvullende maatregelen:

Objectopslag van een hyperscaler in een beschikbaarheidszone in eigen land — acceptabel indien versleuteld met sleutels die het ministerie beheert uit een nationale HSM, met replicatie vergrendeld tot zones in eigen land
Beheerde databases van hyperscalers in zones in eigen land — acceptabel voor ongeclassificeerde gegevens indien het sleutelbeheer nationaal is en replicatie tussen regio's is uitgeschakeld
Virtueel netwerken van hyperscalers — VPC's, subnetten en securitygroups zijn risicoarme IaaS-bouwstenen; het soevereiniteitsrisico zit in de control plane die ze beheert, niet in de bouwstenen zelf

Lager soevereiniteitsrisico:

IaaS-compute (VM's) zonder beheerde agentframeworks — de hyperscaler levert de hardware; het ministerie exploiteert de softwarestack en beheerst alle encryptie
Blockopslag met door de klant beheerde sleutels uit een nationale KMS — de hyperscaler houdt versleutelde blokken vast die niet kunnen worden ontsleuteld zonder de sleutel die het ministerie vasthoudt

Het resultaat van de beoordeling is een risicokaart op componentniveau, geen binaire beslissing “hyperscaler gebruiken” of “hyperscaler niet gebruiken”. De meeste soevereine cloudarchitecturen zullen enkele hyperscalercomponenten behouden op de IaaS-laag, terwijl control-plane- en identiteitscomponenten worden vervangen door nationale alternatieven. Voor een breder beeld van implementatiemodellen en hun implicaties voor classificatie zie ons artikel over modellen voor geclassificeerde clouduitrol.

5. Architectuurpatronen: soeverein-verbonden versus volledig geïsoleerde (air-gapped) soevereine cloud

Er bestaan twee primaire architectuurpatronen voor soevereine clouduitrol, met substantieel verschillende profielen voor kosten, functies en operationele complexiteit.

De soeverein-verbonden topologie gebruikt een beschikbaarheidszone in het datacenter in eigen land van een hyperscaler als IaaS-laag, waarbij het ministerie zijn eigen control plane (Kubernetes, Keycloak, Vault) bovenop de compute- en opslagbouwstenen van de hyperscaler exploiteert. De hyperscaler levert hardwareverversingscycli, datacenterexploitatie en fysieke beveiliging; het ministerie levert softwareexploitatie, beheer van encryptiesleutels en alle control-plane-componenten.

Deze topologie geeft het ministerie toegang tot de schaaleconomie van de hyperscaler, de hardwarebetrouwbaarheid en beheerde opslag- en databasediensten (met passende controles), terwijl de operationele soevereiniteit op de softwarelaag in stand blijft. De soevereiniteitskloof ligt in de fysieke hardwarelaag: de datacentertechnici van de hyperscaler hebben fysieke toegang tot de servers, en de toeleveringsketen van de hyperscaler bepaalt welke hardware beschikbaar is. Voor de meeste defensieministeries buiten de risicovolste dreigingsomgevingen is dit een aanvaardbaar restrisico — mits de encryptie- en control plane-architectuur ervoor zorgt dat fysieke hardwaretoegang geen gegevens in klare tekst en geen toegang tot de control plane oplevert.

De sovereign-connected topologie maakt daarnaast burstcapaciteit mogelijk: wanneer de nationale cloudinfrastructuur van het ministerie op zijn limiet zit, kunnen workloads overvloeien naar de zone van de hyperscaler binnen het land, zonder jurisdictiegrenzen te overschrijden. Daarmee is dit de praktische keuze voor ministeries die zowel aan soevereiniteitseisen als aan moderne capaciteitseisen moeten voldoen, zonder de kapitaalsuitgaven van een nationale infrastructuur die op piekbelasting wordt gedimensioneerd.

Volkomen nationale cloud elimineert de afhankelijkheid van de hyperscaler volledig. Alle fysieke infrastructuur — servers, netwerkapparatuur, storage-arrays en het datacenter dat hen huisvest — wordt door het ministerie of een nationaal geaccrediteerde organisatie aanbesteed, in eigendom gehouden en geëxploiteerd. OpenStack levert de IaaS-laag bovenop deze hardware; Ceph levert gedistribueerde opslag; Kubernetes levert orkestratie.

De afwegingen zijn aanzienlijk. De kapitaalsuitgaven liggen aanzienlijk hoger dan bij een sovereign-connected topologie. Aanbestedingscycli voor servers en netwerkapparatuur zijn lang — doorgaans 12-24 maanden van eis tot operationele capaciteit. Hardwarevernieuwing vereist nieuwe aanbestedingscycli. De vereiste operationele bezetting is veel groter: het productief draaien van OpenStack, Ceph, Kubernetes en Keycloak vraagt een team met diepe expertise in alle vier componenten, wat op salarisniveau van de overheid zeer moeilijk te bemensen is. En de capaciteitskloof ten opzichte van hyperscalers groeit in de tijd, omdat hyperscalers zwaar investeren in beheerde AI/ML, data-analyse en serverloze platforms.

Volkomen nationale cloud is de juiste keuze voor workloads met de hoogste classificatie, workloads met harde air-gap-eisen (geen fysieke of netwerkverbinding met commerciële infrastructuur) en capaciteiten waar toeleveringsketensoevereiniteit op de hardwarelaag een harde eis is. Voor de algemene workloadportefeuille van een modern defensieministerie is het niet de juiste keuze — de operationele complexiteit en de capaciteitskloof zijn te hoge kosten voor soevereiniteitseisen die een goed ontworpen sovereign-connected topologie kan vervullen.

6. Open-source soevereine stack

De canonieke open-source soevereine cloudstack voor defensie is gebouwd op vier componenten die samen het volledige IaaS-, opslag-, orkestratie- en identiteitsplatform leveren, zonder propriëtaire afhankelijkheden en met volledig auditeerbare broncode.

OpenStack is de IaaS-laag: Nova voor compute, Neutron voor virtuele netwerken, Cinder voor blokopslag, Swift voor objectopslag, Glance voor imagebeheer, Keystone voor service-identiteit en -catalogus. OpenStack heeft een productiegeschiedenis van 15 jaar in telecom-, overheids- en wetenschappelijke rekenomgevingen. De operationele complexiteit is reëel — OpenStack-implementaties vergen een toegewijd platformteam en zorgvuldig wijzigingsbeheer — maar het ecosysteem van operators, integratoren en documentatie is volwassen. De Kolla-Ansible implementatietooling maakt een eerste uitrol beheersbaar; de blijvende operationele uitdaging is upgradebeheer, dat in een defensieomgeving, waar wijzigingscontroleprocessen traag zijn, zorgvuldig gepland moet worden.

Ceph is de gedistribueerde opslagbackend. Het levert blokopslag (RBD) voor Cinder-volumes, objectopslag (RGW) voor Swift-compatibele API's en een gedeeld bestandssysteem (CephFS) voor workloads die POSIX-semantiek vereisen. Cephs architectuur verdeelt gegevens over alle nodes in het cluster met configureerbare replicatiefactoren, wat tolerantie biedt tegen uitval van afzonderlijke nodes of schijven zonder propriëtaire storage-arrays. De operationele complexiteit concentreert zich op prestatieafstemming — Ceph vereist zorgvuldige hardwareselectie (NVMe SSD's voor OSD-journals, hoogbandbreedte-netwerken tussen nodes) en doorlopende prestatiebewaking om de “trage OSD”-cascades te vermijden die clusterprestaties onder zware schrijfbelasting kunnen aantasten.

Keycloak is de identity provider. Het ondersteunt OIDC, SAML 2.0, OAuth 2.0 en LDAP/AD-federatie, waardoor het het integratiepunt is voor alle authenticatie in de soevereine stack: authenticatie op de Kubernetes API-server, OpenStack Keystone-identiteitsfederatie, Vault-JWT-authenticatie en authenticatie van menselijke gebruikers. Keycloaks beheer-UI en REST API leveren de operationele tooling voor gebruikersbeheer, groepsbeheer en client-(applicatie)registratie. Het hoogbeschikbaarheidsimplementatiemodel — meerdere Keycloak-instanties die een gedistribueerde Infinispan-cache en een gedeelde PostgreSQL-database delen — is goed gedocumenteerd en bewezen in productie.

Kubernetes is de containerorkestratielaag. Geïmplementeerd met kubeadm of Talos Linux op OpenStack Nova-compute-instanties, levert Kubernetes de laag voor workloadplanning, servicediscovery en configuratiebeheer die applicatieteams consumeren. De belangrijkste architecturale eis voor de soevereine stack is dat de Kubernetesdistributie upstream-compatibel moet zijn — geen beheerde hyperscalervariant — zodat de control plane onder controle van het ministerie blijft. Voor containernetwerken is Cilium de voorkeurs-CNI voor defensieomgevingen vanwege zijn op eBPF gebaseerde policy-handhaving en diepe observeerbaarheid zonder sidecar-proxy. Voor opslagintegratie levert de Ceph CSI-driver de koppeling tussen Kubernetes PersistentVolumes en Ceph RBD.

De operationele complexiteit van deze stack moet niet worden onderschat. OpenStack, Ceph, Kubernetes en Keycloak in productie draaien vereist specialistische expertise in alle vier componenten, die bij overheidsorganisaties moeilijk te werven en te behouden is. Realistisch gezien heeft een ministerie dat deze stack uitrolt óf een groot intern platformteam nodig (20+ ingenieurs voor een implementatie op middelgrote schaal), óf een gecontracteerde soevereine integrator met diepe expertise in alle vier componenten. Het alternatief — de operationele complexiteit verlagen door voor enkele componenten een beheerde hyperscalerservice aan te nemen — moet worden afgewogen tegen de soevereiniteitseisen die het compromitteert. Voor de beveiligingscontroles die bovenop deze stack moeten draaien, zie ons artikel over CSPM voor defensiecloud.

7. Soevereiniteit in balans brengen met moderne cloudcapaciteiten

Het moeilijkste architecturale probleem voor soevereine cloud van een defensieministerie is niet de soevereiniteitscontrole zelf — het is het handhaven van die controles terwijl de moderne cloudcapaciteiten worden geleverd die defensieorganisaties steeds vaker vereisen: training en inferentie van AI/ML-modellen, realtime data-analyse, serverloze event-gedreven architecturen en wereldwijde samenwerkingsplatformen. Hyperscalers hebben miljarden geïnvesteerd in beheerde versies van deze capaciteiten, die de open-source soevereine stack op een tijdschaal van een decennium niet kan evenaren.

IaC-portabiliteit door Terraform provider-abstractie is het meest praktische mechanisme om deze spanning te beheersen. De strategie is alle infrastructuur te definiëren in provider-onafhankelijke Terraform-modules — interne abstracties die consistente invoer accepteren en consistente uitvoer produceren, ongeacht of de onderliggende provider OpenStack, AWS of Azure is. De module-interface voor een “compute-cluster” is dezelfde, of het nu uitrolt op OpenStack Nova of AWS EC2; alleen de providerbinding verandert. Deze abstractie bewaart de optie om workloads te migreren tussen de soevereine nationale stack en een sovereign-connected hyperscalerzone zonder de applicatie-infrastructuur opnieuw te ontwerpen.

# Example provider-agnostic compute module interface
module "compute_cluster" {
  source        = "internal/modules/compute-cluster"
  name          = "sensor-processing"
  instance_type = "c5.4xlarge"  # resolved per provider
  count         = 3
  subnet_id     = module.network.private_subnet_id
  security_groups = [module.security.workload_sg_id]
  user_data     = file("cloud-init/sensor-processor.yaml")
}

# Bind to provider via workspace variable
# terraform.tfvars.national:  provider = "openstack"
# terraform.tfvars.govcloud:  provider = "aws-govcloud"

Beheerde service-alternatieven voor de strategisch belangrijkste capaciteitskloven:

AI/ML-training: on-premises GPU-clusters met Kubeflow of MLflow, aanbesteed bij leveranciers met een aanvaardbare toeleveringsketenpositie; sovereign-connected burst naar GPU-instanties van de hyperscaler binnen het land voor trainingstaken die de on-premises capaciteit overschrijden
Data-analyse: Apache Spark op Kubernetes (via de Spark-operator) vervangt beheerde analyseservices; ClickHouse of Apache Druid voor realtime analytische queryworkloads
Beheerde databases: operators voor PostgreSQL (CloudNativePG), Redis (Redis Operator) en Kafka (Strimzi) leveren op zelfbeheerd Kubernetes een gebruikerservaring als van een beheerde service
Observeerbaarheid: Prometheus, Loki en Grafana leveren de stack voor metrieken, logging en visualisatie zonder propriëtaire afhankelijkheden van beheerde observeerbaarheid

Een capaciteitsroadmap voor soevereine cloud moet als een levend programma worden behandeld, niet als een eenmalige uitrol. De kloof tussen de capaciteiten van de soevereine stack en de beheerde services van hyperscalers is reëel maar niet statisch — het open-source-ecosysteem produceert doorlopend nieuwe soevereine alternatieven voor propriëtaire beheerde services. Een gestructureerde capaciteitsreview om de zes maanden — waarbij de huidige capaciteiten van de soevereine stack worden vergeleken met de huidige operationele eisen en de huidige hyperscaleralternatieven — stelt het ministerie in staat te prioriteren welke kloven te sluiten via adoptie van open source, welke via sovereign-connected toegang tot hyperscalerservices binnen het land, en welke te aanvaarden als resterende capaciteitsbeperkingen in ruil voor soevereiniteitsgaranties.

Kerninzicht: Soevereine cloud voor defensieministeries is geen product dat gekocht kan worden — het is een architecturale houding die ontworpen, gebouwd, geëxploiteerd en doorlopend onderhouden moet worden. De ministeries die erin slagen behandelen soevereiniteit als first-class engineering-eis naast prestaties, betrouwbaarheid en kosten, maken expliciete afwegingen tussen soevereiniteitsdimensies en capaciteit, en bouwen de operationele capaciteit om de soevereine stack op productiekwaliteit te draaien. Wie het als een compliance-vinkje behandelt — een “sovereign cloud”-leverancierscertificering verwerven zonder te beoordelen of de technische controles daadwerkelijk gegevensresidentie, operationele soevereiniteit en toeleveringsketensoevereiniteit leveren — ontdekt de kloof wanneer een geopolitieke verstoring of een wijziging van leveranciersbeleid haar blootlegt.

Soevereine cloud voor defensieministeries is uiteindelijk een risicobeheersbeslissing, geen technologiebeslissing. De hier beschreven architectuur — nationale control plane, technische controles voor gegevensresidentie, open-source soevereine stack, Terraform provider-abstractie voor portabiliteit — is een set instrumenten om een specifieke set risico's te beheersen. De juiste architectuur voor een willekeurig ministerie hangt af van welke risico's in zijn dreigingsomgeving het meest materieel zijn, welke operationele capaciteit met de beschikbare bezetting en het beschikbare budget realistisch onderhoudbaar is, en waar op de afwegingscurve tussen soevereiniteit en capaciteit zijn geclassificeerde workload-eisen vallen. Die kalibratie goed treffen vereist een eerlijke dreigingsbeoordeling en engineeringoordeel — geen leveranciersgarantie.

Bespreek Uw Project

Wij ontwerpen en bouwen soevereine cloudarchitecturen voor defensieministeries — van de uitrol van een nationale control plane en het afdwingen van gegevensresidentie tot het beheer van de open-source stack en IaC-portabiliteit.

Secure Cloud Services → Boek een briefing

Deze analyse is opgesteld door ingenieurs van Corvus Intelligence die missiekritieke software bouwen voor defensie- en overheidsorganisaties. Maak kennis met ons team →

Veelgestelde vragen

Wat is cloudsoeverereiniteit voor een defensieministerie?

Cloudsoevereiniteit voor een defensieministerie omvat drie verschillende maar samenhangende eisen. Dataresidency is de juridische en technische garantie dat geclassificeerde of gevoelige gegevens uitsluitend binnen het nationale grondgebied of goedgekeurde jurisdicties worden opgeslagen, verwerkt en verzonden — en dat het ministerie, niet een leverancier, de encryptiesleutels beheert. Operationele soevereiniteit is het vermogen om het cloudplatform zelfstandig te blijven exploiteren, onafhankelijk van de voortdurende medewerking, licenties of dienstverlening van een buitenlandse leverancier, inclusief het vermogen om sancties, het faillissement van een leverancier of geopolitieke verstoring te doorstaan. Soevereiniteit over de toeleveringsketen is de controle over de software- en hardwarecomponenten waarmee de cloud wordt gebouwd en geëxploiteerd — met de zekerheid dat geen enkele buitenlandse regering een leverancier kan dwingen achterdeuren in te bouwen of dienstverlening te weigeren. Een echt soevereine cloud voor defensie moet aan alle drie de dimensies tegelijk voldoen; architectuurkeuzes die aan dataresidency voldoen maar operationele soevereiniteit of ketensoevereiniteit opofferen, bieden zwakkere bescherming dan ze op papier lijken.

Wat is afdwinging van gegevensresidentie in de context van een defensiecloud?

Afdwinging van dataresidency in een defensiecloud betekent het implementeren van technische maatregelen die het fysiek en cryptografisch onmogelijk maken — niet slechts contractueel verboden — dat gegevens de gedefinieerde geografische of jurisdictionele grens verlaten. De belangrijkste lagen zijn: residency van encryptiesleutels (de HSM of KMS die de encryptiesleutels van de gegevens vasthoudt, moet fysiek in eigen land staan en onder nationale controle vallen, zodat met die sleutels versleutelde gegevens buiten de grens niet kunnen worden ontsleuteld, zelfs niet na fysieke exfiltratie); afdwinging van gegevenslocatiebeleid op de opslaglaag (objectopslag, blockvolumes en databasereplica's moeten worden beperkt tot beschikbaarheidszones in eigen land); besturing van uitgaand netwerkverkeer (firewallregels en DNS-beleid die gegevenspaden naar eindpunten buiten het land blokkeren); en audit en verificatie (doorlopende monitoring dat de maatregelen voor gegevens in rust en gegevens in beweging niet zijn omzeild, met bewerkingsbestendige logboeken die worden beoordeeld door het eigen security-operations-team van het ministerie in plaats van door dat van de leverancier).

Wat is een nationale control plane en waarom is die belangrijk?

De control plane van een cloudplatform is de verzameling diensten die de orkestratie van workloads, identiteit en secrets beheren — in een Kubernetes-omgeving zijn dat de API-server, etcd, de scheduler en de controller manager; in bredere cloudcontext omvat zij ook de identity provider, het secretbeheersysteem en de beheer-API's. Als de control plane draait op infrastructuur die door een buitenlandse hyperscaler wordt beheerd, hebben de operationele medewerkers van die hyperscaler in beginsel de mogelijkheid workloadconfiguraties te wijzigen, secrets te extraheren of de werking te verstoren op instructie van hun thuisregering. Een nationale control plane laat deze componenten draaien op infrastructuur die fysiek en organisatorisch onder controle van het ministerie staat, waarmee die afhankelijkheid verdwijnt. Zelfs bij gebruik van een datacenter van een hyperscaler in eigen land betekent een nationale control plane dat de Kubernetes-API-server, het etcd-cluster en de identity provider draaien op hardware die het ministerie bezit of beheerst, terwijl de hyperscaler alleen compute-, netwerk- en opslagbouwstenen levert.

Welke hyperscalercomponenten brengen het grootste soevereiniteitsrisico met zich mee?

De hyperscalercomponenten met het hoogste risico voor een defensieministerie zijn: beheerde Kubernetes-control planes (EKS, AKS, GKE), waar de API-server en etcd op hyperscalerinfrastructuur draaien en het operationele personeel van de hyperscaler bevoorrechte toegang heeft; beheerde identity providers, waar de gezaghebbende identiteitsbewering wordt gedaan door diensten die de hyperscaler beheerst; wereldwijde CDN- en edge-cachinglagen die verkeer leiden via points of presence buiten het land; replicatiefuncties tussen regio's die gegevens kunnen kopiëren naar beschikbaarheidszones buiten de goedgekeurde jurisdictie; en beheerde secretsopslag waarvan het sleutelmateriaal uiteindelijk in door hyperscalers beheerde HSM's ligt. Hyperscaler-IaaS-componenten — pure compute, blockopslag en virtueel netwerken zonder beheerde control plane — brengen aanzienlijk lager soevereiniteitsrisico met zich mee, omdat het ministerie de softwarestack er bovenop zelf exploiteert en alle encryptiesleutels zelfstandig beheert.

Wat is het verschil tussen sovereign-connected en volkomen nationale cloud?

De soeverein-verbonden topologie gebruikt een datacenter van een hyperscaler in eigen land met een door het ministerie beheerde control plane er bovenop. De hyperscaler levert IaaS — compute, opslag, netwerk — maar alle lagen voor orkestratie, identiteit en secretbeheer worden geëxploiteerd door het ministerie of een vertrouwde nationale integrator. Dit geeft toegang tot de schaalvoordelen en beheerde diensten van hyperscalers, tegen de prijs van een blijvende afhankelijkheid van de hardware-exploitatie en de toeleveringsketen van de hyperscaler. Een volledig nationale cloud elimineert de hyperscalerafhankelijkheid volledig — alle fysieke infrastructuur wordt verworven, bezit en geëxploiteerd door het ministerie of een nationale soevereine aanbieder. De afwegingen zijn aanzienlijk hogere kapitaaluitgaven, langere aanbestedingscycli, grotere operationele complexiteit en een capabiliteitskloof ten opzichte van de beheerde diensten van hyperscalers — maar maximale operationele en ketensoevereiniteit.

Welke open-source componenten vormen de kern van een soevereine cloudstack?

De canonieke open-source soevereine cloudstack bestaat uit: OpenStack voor IaaS (compute via Nova, objectopslag via Swift, blockopslag via Cinder, netwerken via Neutron, imagebeheer via Glance, identiteit via Keystone); Ceph als de gedistribueerde opslaglaag onder de Cinder-volumes en de Swift-objectopslag van OpenStack; Kubernetes als de laag voor containerorkestratie, uitgerold met een upstreamdistributie (geen beheerde hyperscalervariant), zodat de API-server en etcd onder controle van het ministerie blijven; en Keycloak als identity provider voor zowel menselijke gebruikers (via OpenID Connect en SAML) als workloads (via OAuth 2.0 client credentials). Samen leveren deze vier componenten de volledige cloudplatformstack zonder propriëtaire afhankelijkheden. De operationele complexiteit is aanzienlijk hoger dan bij het gebruik van beheerde hyperscalerdiensten, en het ministerie moet de expertise behouden om elke component te exploiteren en te patchen — maar de soevereiniteitsgaranties zijn absoluut, omdat de broncode van elke component auditabel is en geen enkele buitenlandse leverancier bevoorrechte operationele toegang heeft.

Hoe ondersteunt Terraform portabiliteit tussen soevereine cloudomgevingen?

De providerabstractie van Terraform maakt het mogelijk infrastructuur te beschrijven in provideronafhankelijke modules, waarbij providerspecifieke implementaties op het niveau van de rootmodule worden gewisseld. Een portabiliteitspatroon voor soevereine cloud definieert interne module-interfaces — een compute-clustermodule, een module voor een beheerde database, een module voor een objectopslagbucket — die dezelfde inputs accepteren en dezelfde outputs produceren, ongeacht of de onderliggende provider een OpenStack-implementatie is, een nationale cloudaanbieder of een zone in eigen land van een hyperscaler. Wanneer het ministerie van het onderliggende platform moet migreren wegens leveranciersrisico, regelgevingswijziging of capabiliteitsevolutie, verandert alleen de providerbinding — de workloadmoduledefinities, deployment-pipelines en infrastructuurtests blijven ongewijzigd. De praktische grens van deze portabiliteit ligt bij beheerde diensten: een module die een hyperscalerspecifieke beheerde databasedienst omhult, kan niet zonder meer naar OpenStack worden geport zonder de onderliggende dienst te vervangen door een gelijkwaardige zelfbeheerde uitrol.

Wat zijn de belangrijkste risico's van soevereine cloud voor een defensieministerie?

De belangrijkste risico's zijn: de capabiliteitskloof (nationale cloudaanbieders en open-sourcestacks blijven vaak jaren achter bij hyperscalers op beheerde AI/ML-diensten, serverless-platformen en wereldwijde netwerkprestaties — dit beperkt de moderne capabiliteitsroadmap); operationele complexiteit (OpenStack, Ceph, Kubernetes en Keycloak intern draaien vergt diepe expertise die bij de overheid moeilijk te werven en te behouden is); toeleveringsketenrisico in hardware (servers, netwerkapparatuur en opslaghardware van niet-nationale leveranciers dragen hun eigen ketensoevereiniteitsrisico's — ook een volledig nationale cloud kan op de hardwarelaag worden gecompromitteerd); en valse soevereiniteit (een cloud die op papier aan dataresidency voldoet, maar waar het hyperscalerpersoneel bevoorrechte toegang heeft of die buitenlandse HSM's gebruikt voor sleutelbeheer, biedt zwakkere garanties dan haar architectuurdocumentatie suggereert). Risicobeheer vereist dat soevereiniteit wordt behandeld als een spectrum met meerdere onafhankelijk verifieerbare dimensies, niet als een binaire certificering.

Hoe moeten geclassificeerde en ongeclassificeerde workloads in een soevereine cloud worden gescheiden?

Geclassificeerde en ongeclassificeerde workloads moeten op de fysieke laag worden gescheiden — aparte Kubernetes-clusters op aparte nodepools, zonder gedeelde etcd, zonder gedeelde control plane en zonder gedeelde netwerkinfrastructuur tussen de classificatieniveaus. Logische scheiding binnen één cluster (namespace-isolatie, NetworkPolicy) is onvoldoende voor workloads op verschillende classificatieniveaus, omdat een kwetsbaarheid in de control plane of een container-escape namespacegrenzen kan overschrijden. In de praktijk betekent dit aparte OpenStack-tenants met fysiek gescheiden Ceph-opslagclusters per classificatieniveau, aparte Keycloak-realms of volledig aparte identity providers, en aparte CI/CD-pipelines met aparte ondertekeningssleutels, zodat een compromittering van de ongeclassificeerde buildpipeline geen kwaadaardige images in het geclassificeerde niveau kan brengen. Gegevensoverdracht tussen de niveaus moet via een formeel geëvalueerde cross-domain-oplossing lopen, niet via netwerkverbindingen.

Hoe zou de capaciteitsroadmap voor soevereine cloud van een defensieministerie eruit moeten zien?

Een realistische capabiliteitsroadmap voor soevereine cloud bij een defensieministerie kent drie fasen. Fase 1 (jaar 1-2) legt de fundering: de nationale IaaS-laag uitrollen (OpenStack of gelijkwaardig), workloads migreren van commerciële cloud naar infrastructuur in eigen land, maatregelen voor dataresidency en nationaal sleutelbeheer invoeren en de nationale Kubernetes-control plane uitrollen. Fase 2 (jaar 2-4) bouwt de platformlaag: Keycloak uitrollen voor gefedereerde identiteit, op Terraform gebaseerde IaC met providerabstractie invoeren, een interne containerregistry bouwen met toeleveringsketenmaatregelen (ondertekening van images, kwetsbaarheidsscans) en een soeverein-verbonden topologie vestigen met een hyperscalerzone in eigen land voor piekbelasting en veerkracht. Fase 3 (jaar 4+) richt zich op capabiliteitspariteit: soevereine beheerde database- en analysediensten bouwen of verwerven, AI/ML-trainingsinfrastructuur on-premises uitrollen, zero-trust-architectuur over alle niveaus implementeren en een framework voor geautomatiseerde doorlopende compliance opzetten dat alle componenten van de soevereine stack dekt.

Wat is het verschil tussen een soeverein-verbonden en een volledig nationale cloud?

Hoe zou de capabiliteitsroadmap van een defensieministerie voor soevereine cloud eruit moeten zien?