Multi-cloudstrategie voor defensie: Leveranciersafhankelijkheid vermijden in militaire systemen

Afhankelijkheid van één cloud is een strategisch risico voor defensiesystemen dat analytisch vergelijkbaar is met leveranciersafhankelijkheid in elk ander kritiek capability-domein. Wanneer de volledige cloudinfrastructuur van een defensieprogramma op één provider draait, kan die provider invloed uitoefenen via prijsstelling, dienstverlening of contractuele wijzigingen bij programmaverlenging. Geopolitieke ontwikkelingen kunnen de toegang tot buitenlandse cloudinfrastructuur bemoeilijken of elimineren. Een grote cloudstoring — AWS us-east-1-uitval heeft grote delen van het commerciële internet getroffen — kan defensieoperationele capaciteiten die afhankelijk zijn van die infrastructuur degraderen of elimineren.

Multi-cloudstrategie pakt dit strategische risico aan door workloads te verdelen over meerdere providers, portabiliteit op architectuurniveau te handhaven en diepe verstrengeling met propriëtaire clouddiensten te vermijden die migratie onbetaalbaar duur zou maken. Dit artikel onderzoekt hoe multi-cloudimplementatiepatronen werken, hoe cloud-agnostische Infrastructure-as-Code-tools portabiliteit ondersteunen, en hoe de compliancecomplexiteit van het handhaven van classificatiecontroles bij meerdere providers wordt beheerd.

Strategisch risico van afhankelijkheid van één cloud

Geopolitiek risico is het meest onderscheidend defensierelevante risico bij cloudproviderafhankelijkheid. De relatie tussen defensieorganisaties en cloudproviders wordt bemiddeld door politieke en juridische structuren die kunnen veranderen. EU-wetgeving inzake gegevenssoevereiniteit (GDPR, nationale veiligheidsuitzonderingen, EUCS) creëert voortdurende juridische onzekerheid over de langetermijnwettigheid van het opslaan van defensiegegevens bij in de VS gevestigde providerinfrastructuur. Voor defensieprogramma's met levenscycli van 10-20 jaar kan een cloudarchitectuurbeslissing die vandaag wordt genomen op basis van de huidige politieke en juridische omgeving halverwege de operationele levensduur van het programma onhoudbaar worden.

Operationeel risico door storingen is een meer directe zorg. Grote cloudproviders ervaren significante uitval: AWS us-east-1-uitval in 2021 en 2023 verstoorde grote delen van het commerciële internet urenlang. Microsoft Azure heeft meerdere uren durende wereldwijde uitval gehad. Voor defensiesystemen met beschikbaarheidsvereisten (een logistiek beheersysteem dat een actieve operatie moet ondersteunen, een cyber-situationeel bewustzijnsplatform dat operationeel moet zijn tijdens een dreigingsrespons), is afhankelijkheid van één cloudprovider zonder terugvalcapaciteit operationeel onaanvaardbaar.

Prijshefboom is een commercieel risico met strategische implicaties. Cloudproviders kunnen prijzen verhogen bij contractverlenging; omschakelingskosten bij diep verstrengelde architecturen maken het moeilijk om te reageren. De ervaring van het DoD met de JEDI- en JWCC-cloudinkoopwedstrijden weerspiegelde bewustzijn van dit risico — de multi-leveranciersstructuur van JWCC was expliciet bedoeld om leveranciersafhankelijkheid voor DoD-cloudworkloads te voorkomen.

Multi-cloudimplementatiepatronen

Actief-actief gesplitste workloads verdelen verschillende workloadtypen over verschillende cloudproviders op basis van de comparatieve voordelen van elke provider: een defensieprogramma kan geclassificeerde applicaties draaien bij de provider met de sterkste geclassificeerde cloudaccreditaties, analyse- en ML-workloads bij de provider met de beste ML-infrastructuur, en samenwerkingstools bij een derde EU-soevereine provider voor redenen van gegevensverblijf. Dit patroon extraheert maximale waarde uit de sterktes van elke provider maar vereist zorgvuldige applicatiearchitectuur om gegevenskoppeling tussen providers te vermijden.

Primair-secundair noodherstel draait productieworkloads op een primaire provider met een warme stand-by omgeving op een secundaire provider. De secundaire omgeving wordt op voldoende gereedheid gehouden om over te nemen binnen een gedefinieerde RTO (hersteltijddoelstelling) als de primaire uitvalt. Dit patroon is operationeel eenvoudiger dan actief-actief — de secundaire omgeving is in wezen een kopie van de primaire — maar vereist regelmatige failover-tests om te verifiëren dat de secundaire daadwerkelijk kan overnemen onder realistische omstandigheden.

Het geschikte patroon voor een gegeven defensieprogramma hangt af van de beschikbaarheidsvereisten, operationele kritiekheid en het classificatieniveau van de workloads. Programma's met extreem hoge beschikbaarheidsvereisten (missiekritieke operationele systemen) kunnen actief-actief vereisen voor de meest kritieke diensten. Programma's met lagere beschikbaarheidsvereisten maar sterke soevereiniteitszorgen kunnen primair-secundair aannemen met de secundaire bij een EU-soevereine provider.

Cloud-agnostische IaC: Terraform en Crossplane

Terraform (van HashiCorp, nu een BSL-gelicentieerd product met een open-source fork bij OpenTofu) is het standaard Infrastructure-as-Code-tool voor cloud-agnostische resource-inrichting. Terraform-providers bestaan voor alle grote cloudplatforms (AWS, Azure, GCP, OVHcloud en tientallen anderen), en Terraform-configuratiesyntaxis is cloud-agnostisch — dezelfde Terraform-configuratiestructuur wordt gebruikt ongeacht welke provider wordt ingericht. Dit betekent dat een IaC-engineer die bekend is met Terraform met de resources van elke provider kan werken zonder een providerspecifieke IaC-taal te leren.

Voor multi-cloudarchitecturen stelt het werkruimte- en modulesysteem van Terraform dezelfde applicatie-infrastructuur in staat op verschillende providers te worden geïnstantieerd: een Terraform-module voor een "drielaagse webapplicatie" kan providerspecifieke implementaties hebben (één voor AWS, één voor Azure, één voor OVHcloud) die dezelfde interface bieden. De infrastructuurrepository van het programma wisselt tussen providerimplementaties door de modulebron te veranderen — de configuratie op applicatieniveau verandert niet.

Crossplane is een CNCF-gediplomeerd project dat een op Kubernetes gebaseerd besturingsvlak biedt voor cloudinrichting. Waar Terraform een CLI-tool is die infrastructuurstatus beheert in een declaratief bestand, draait Crossplane als een Kubernetes-controller en beheert cloudresources als Kubernetes-aangepaste resources. Het Crossplane Composition-systeem maakt cloudresource-abstractie mogelijk: een Composition definieert een samengesteld resourcetype (bijv. een "DefenceDatabase") dat wordt gekoppeld aan providerspecifieke resources, waardoor applicatieteams een DefenceDatabase kunnen aanvragen zonder te weten of het wordt ondersteund door AWS RDS, Azure Database for PostgreSQL of een on-premises PostgreSQL-instantie.

Crossplane is bijzonder waardevol voor defensieprogramma's die een platform-engineeringmodel aannemen: een centraal platformteam beheert de Crossplane-composities en providerconfiguraties, en applicatieteams verbruiken cloudresources via self-service door standaard Kubernetes-manifesten toe te passen. Het platformteam handhaaft de providerspecifieke implementaties en kan providers wisselen of toevoegen zonder de interface te wijzigen die aan applicatieteams wordt blootgesteld.

Gegevensportabiliteit: Open formaten en S3-compatibele opslag

Cloudleveranciersafhankelijkheid op de gegevenslaag — waarbij gegevens worden opgeslagen in propriëtaire formaten of diensten zonder standaard exportmechanisme — is de moeilijkste vorm van lock-in om aan te ontsnappen. Dit vermijden vereist expliciet gegevensportabiliteitsontwerp:

S3-compatibele objectopslag is de praktische standaard voor cloud-agnostische gegevensopslag. De API van Amazon S3 is de de-facto standaard voor objectopslag geworden, met S3-compatibele API's van Azure Blob Storage (via S3-compatibel eindpunt), GCP Cloud Storage, OVHcloud Object Storage en on-premises oplossingen zoals MinIO (veel gebruikt in air-gapped omgevingen). Applicaties die S3-compatibele API's gebruiken voor objectopslag kunnen tussen providers wisselen door de eindpunt-URL en inloggegevens te wijzigen — de applicatiecode verandert niet.

Standaard SQL via beheerde PostgreSQL-compatibele databases vermijdt de lock-in van propriëtaire databasediensten (DynamoDB, Azure Cosmos DB, Google Spanner). PostgreSQL-compatibele beheerde diensten zijn beschikbaar op alle grote cloudplatforms (AWS Aurora PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL, OVHcloud Managed PostgreSQL). Applicaties die standaard SQL en het PostgreSQL-protocol gebruiken, kunnen tussen providers migreren met alleen configuratiewijzigingen.

Compliancecomplexiteit: Classificatiecontroles bij providers

De meest significante operationele uitdaging in multi-clouddefensiearchitecturen is het consistent handhaven van classificatiecontroles bij meerdere providers, elk met verschillende servicemogelijkheden, verschillende compliancecertificeringen en verschillende tools voor het implementeren van beveiligingscontroles.

Classificatiecontroles — toegangscontroles gekoppeld aan veiligheidsmachtigingsniveau, auditlogboekregistratie van alle toegang tot geclassificeerde gegevens, encryptiesleutelbeheer, gegevensverblijfshandhaving — moeten equivalent worden geïmplementeerd op elke provider die wordt gebruikt voor geclassificeerde workloads. Dit betekent dat het compliance-engineeringteam de relevante tools en diensten op elke provider moet begrijpen, verifiëren dat de controles correct zijn geïmplementeerd en getest op elke provider, en equivalente compliancedocumentatie bij alle providers moet handhaven. Dit is aanzienlijk complexer dan het handhaven van controles bij één provider.

De praktische aanpak is het bouwen van een provider-agnostische compliancelaag: een set Terraform/Crossplane-modules en Kubernetes-admission-controllerbeleid dat de vereiste compliancecontroles implementeert ongeacht welke cloudprovider de onderliggende resources inricht. De compliancelaag specificeert: encryptie in rust is vereist (en dwingt dit af via opslagklasseconfiguratie), encryptiesleutelbeheer moet door de klant beheerde sleutels gebruiken (en configureert CMK-beleid op elke provider), toegangslogs moeten worden doorgestuurd naar de SIEM (en configureert auditlogdoorsturen). Het applicatieteam richt infrastructuur in via deze compliancelaag, niet rechtstreeks via de provider-API, zodat compliancecontroles niet kunnen worden omzeild.