Een soevereine multicloud poly-cloud strategie is een architectuurbenadering waarbij een organisatie meerdere cloudleveranciers inzet die elk aantoonbaar voldoen aan Europese jurisdictionele en beveiligingsvereisten, terwijl werklasten onderling portabel blijven via open standaarden. Anders dan een generieke multicloudstrategie, plaatst de soevereine variant juridische beheersbaarheid, niet kostenoptimalisatie, centraal in elke architectuurbeslissing.
Multicloud, hybride cloud en poly-cloud: drie strategieën, één juridisch vraagstuk
De terminologie wordt vaak door elkaar gebruikt, maar vanuit soevereiniteits- en jurisdictieperspectief zijn de verschillen bepalend voor het complianceprofiel van een organisatie.
Een multicloudstrategie verdeelt werklasten over meerdere cloudproviders, doorgaans per provider afgebakend: e-mail bij leverancier A, opslag bij leverancier B. Soevereiniteit is hier een afgeleid kenmerk, niet het ontwerpdoel. Een hybride cloudstrategie combineert publieke cloud met on-premise infrastructuur, waarbij het on-premise gedeelte de soevereine ankerlaag vormt. De publieke cloudcomponent kan echter nog steeds onderhevig zijn aan extraterritoriale wetgeving zoals de Amerikaanse CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) of de Patriot Act, als de leverancier een Amerikaanse rechtspersoon is of operationele afhankelijkheden heeft van een Amerikaanse moedermaatschappij.
Een poly-cloudstrategie gaat een stap verder: werklasten worden op basis van expliciete criteria, denk aan gevoeligheidsniveau, latency-eisen en certificeringsverplichting, dynamisch verdeeld over leveranciers. Er is een orchestratielaag die technische overdraagbaarheid bewaakt. Vanuit soevereiniteitsoptiek is dit de meest robuuste benadering, mits iedere leverancier in de configuratie minimaal SEAL-2 haalt.
SEAL-niveaus als architectuureis: minimaal SEAL-2 als drempel
Het EU Cloud Sovereignty Framework, uitgewerkt in het EUCS-schema van ENISA, kent drie SEAL-niveaus die bepalen in hoeverre een cloudleverancier beschermd is tegen niet-EU-jurisdictie.
| SEAL-niveau | Kernvereisten | Typische leveranciers |
|---|---|---|
| SEAL-1 | Basisbeveiliging, geen jurisdictionele vereisten | AWS, Azure, Google Cloud |
| SEAL-2 | Data in EER, geen niet-EU-toegang, auditeerbaar, Europese rechtspersoon vereist | OVHcloud, Scaleway, STACKIT |
| SEAL-3 | SEAL-2 plus operationele onafhankelijkheid, EU-sleutelbeheer, versterkte auditrechten | Proximus/S3NS (beperkt), specifieke overheidsclouds |
Voor overheidsorganisaties en bedrijven in de gereguleerde sector, zoals financiële instellingen en gezondheidszorginstellingen, geldt SEAL-2 als ondergrens. SEAL-3 is vereist voor gerubriceerde overheidsinformatie. In een poly-cloudarchitectuur betekent dit dat elke afzonderlijke leverancier in de configuratie aan de toepasselijke SEAL-eis voldoet. Eén SEAL-1-leverancier in de mix maakt de gehele architectuur juridisch kwetsbaar, ook als de gevoelige data formeel bij een SEAL-2-aanbieder staat, omdat metadata, authenticatiestromen en API-koppelingen over leveranciersgrenzen heen lopen.
Het aandeel van hyperscalers (AWS, Azure, Google Cloud) op de Europese cloudmarkt bedroeg in 2023 gezamenlijk meer dan 65 procent (European Parliament Research Service, 2023). Tegelijkertijd schat de Europese Commissie dat in 2028 ongeveer 80 procent van de bedrijfsdata in de cloud wordt opgeslagen, tegenover 40 procent in 2022 (European Commission, European Data Strategy, 2022). De combinatie van deze twee trends maakt dat de jurisdictionele kwetsbaarheid van Europese organisaties zonder actief soevereiniteitsbeleid structureel toeneemt.
Interoperabiliteit en portabiliteit: voorkomen van lock-in via open standaarden
Portabiliteit is de technische tegenhanger van soevereiniteit: als een organisatie niet kosteloos en zonder dataverlies van leverancier kan wisselen, is de strategische autonomie in de praktijk beperkt, ook als de individuele leverancier SEAL-gecertificeerd is.
Drie kaders zijn hier bepalend. Ten eerste verplichten artikelen 23 tot en met 31 van de EU Data Act (Verordening EU 2023/2854) cloudleveranciers tot actieve ondersteuning van dataportabiliteit en overstap, inclusief verbod op buitensporige overstapkosten en verplichte technische bijstand. Ten tweede beschrijft het Gaia-X Trust Framework de technische en governancevereisten voor interoperabiliteit tussen Europese cloudleveranciers, inclusief federatieve identiteitsbeheer en gedecentraliseerde datadeling. Ten derde bieden CAMARA-API’s (ontwikkeld binnen de GSMA) gestandaardiseerde netwerkinterfaces die telecomgebaseerde clouddiensten portabel maken over providers heen.
In de praktijk betekent dit voor een compliance officer dat leverancierscontracten expliciet moeten verwijzen naar EUCS-portabiliteitsvereisten, dat data-export in open formaten (zoals S3-compatibele objectopslag of standaard containerformaten via OCI) contractueel is vastgelegd, en dat exit-procedures zijn getest voor elke leverancier in de multicloud-configuratie.
“Cloud sovereignty is not just about where data is stored, but about who has effective legal control over it under applicable law.” (ENISA, Cloud Cybersecurity Market Analysis 2023)
Verwerkersovereenkomsten en auditverplichtingen bij drie of meer leveranciers
Wanneer een organisatie drie of meer soevereine cloudleveranciers tegelijkertijd inzet, neemt de complexiteit van het verwerkerslandschap exponentieel toe. Iedere leverancier vereist een afzonderlijke verwerkersovereenkomst conform artikel 28 AVG, met specifieke bepalingen over subverwerkers, verwerkingslocaties en auditrechten. Bovendien eist NIS-2 (Richtlijn EU 2022/2555) dat organisaties de beveiligingsrisico’s in de volledige supply chain beheersen en kunnen aantonen.
Een werkbare aanpak voor compliance officers is het opzetten van een centraal verwerkersregister met per leverancier: het SEAL-niveau, de geldige certificeringen (ISO 27001, SOC 2 Type II, toepasselijke EUCS-erkenning), de auditfrequentie en de contactpersonen voor incidentrespons. Afwijkingen van de SLA, zoals onverwachte subverwerkers of wijzigingen in verwerkingslocaties, moeten automatisch een reviewproces activeren. Uit onderzoek van ENISA (2023) bleek dat 38 procent van de significante cyberincidenten bij Europese overheidsorganisaties verband hield met cloudconfiguraties of cloudleveranciers, wat het belang van actief leverancierstoezicht onderstreept.
Lessen uit de Cloud III DPS-aanbesteding: SEAL-3 in de praktijk
Het Cloud III Dynamic Purchasing System (Cloud III DPS), opgezet door de Europese Commissie en nationale aanbestedende diensten, heeft de markt voor soevereine clouddiensten concreet gestructureerd. De aanbesteding resulteerde in de toelating van leveranciers als OVHcloud, Scaleway, STACKIT en Proximus/S3NS voor opdrachten waarbij soevereiniteitsgaranties vereist zijn.
De praktijkervaring met SEAL-3 in een multicloud-opzet leert het volgende. OVHcloud en Scaleway bieden robuuste SEAL-2-compatibele diensten aan met aantoonbare Europese rechtspersoonlijkheid en datacenters binnen de EER. STACKIT (onderdeel van Schwarz Gruppe) positioneert zich specifiek voor de gereguleerde sector met strikte operationele scheiding. Proximus/S3NS (een joint venture van Proximus en Thales) streeft naar SEAL-3-compatibiliteit voor geclassificeerde Belgische overheidsopdrachten, maar de operationele beschikbaarheid van volledig SEAL-3-gecertificeerde diensten over het volledige dienstenpalet is begin 2024 nog beperkt.
De centrale les is dat SEAL-3 in een multicloud-configuratie technisch mogelijk is, maar dat het combineren van twee SEAL-3-leveranciers in één architectuur zorgvuldige afstemming vereist van sleutelbeheer (HSM-integratie over providers heen), logging (gecentraliseerde SIEM met audittrails van beide leveranciers) en juridische governance (gecoördineerde verwerkersovereenkomsten en gezamenlijke incidentresponsplannen). Veel overheidsorganisaties kiezen pragmatisch voor een gelaagde aanpak: SEAL-3 voor de meest gevoelige werklasten, SEAL-2 voor de overige.
“De Baseline Informatiebeveiliging Overheid vereist dat overheidsorganisaties aantoonbaar in control zijn over de volledige verwerkingsketen, ook wanneer verwerkingen zijn uitbesteed aan cloudleveranciers.” (Centrum Informatiebeveiliging en Privacybescherming, Handreiking BIO en clouddiensten)
On-premise als tertiaire back-upomgeving: integratie met BIO2 en NIS-2
Een volledig cloudgebaseerde soevereine strategie heeft één kwetsbaarheid die geen certificering wegneemt: afhankelijkheid van internetconnectiviteit en van de beschikbaarheid van de leverancier. BIO2 (Baseline Informatiebeveiliging Overheid versie 2) vereist dat overheidsorganisaties voor kritieke processen beschikken over een aantoonbaar herstelplan dat niet uitsluitend afhankelijk is van één of meerdere externe leveranciers.
De aanbevolen architectuur combineert twee soevereine cloudleveranciers (primaire en secundaire omgeving, beide minimaal SEAL-2) met een on-premise infrastructuur als tertiaire back-upomgeving. De on-premise laag dient meerdere doelen tegelijkertijd. Het is een air-gapped hersteloptie bij een cloudstoring of ransomware-aanval. Het is de omgeving voor lokaal gehoste AI-toepassingen die nooit op klantdata trainen. En het is de sleutelbeheeromgeving, met een Hardware Security Module (HSM) die de cryptografische root of trust beheert voor alle drie de omgevingen.
NIS-2 vereist voor aanbieders van essentiële diensten dat back-up- en herstelmaatregelen aantoonbaar zijn getest en gedocumenteerd. BIO2 voegt hieraan toe dat de herstelperiode (Recovery Time Objective) en het maximale dataverlies (Recovery Point Objective) per systeem zijn vastgesteld en contractueel zijn geborgd met alle betrokken leveranciers. In een soevereine multicloudarchitectuur betekent dit dat de RTO en RPO over alle drie de lagen, twee cloud en één on-premise, gecoördineerd zijn, en dat failover-scenario’s jaarlijks worden getest met documentatie van de uitkomsten.
Implementatievolgorde voor compliance officers en IT-beslissers
Een soevereine multicloud poly-cloud strategie is geen eenmalig project maar een doorlopende governance-inspanning. De implementatie verloopt logisch in drie fasen. In de eerste fase wordt het huidige cloudlandschap gemapt op SEAL-niveaus en worden de jurisdictionele risico’s per leverancier in kaart gebracht. Dit levert een gap-analyse op die bepaalt welke werklasten direct moeten worden gemigreerd. In de tweede fase worden leveranciers geselecteerd op basis van SEAL-criterium, portabiliteitsstandaard (EU Data Act, Gaia-X Trust Framework) en auditbaarheid, en worden verwerkersovereenkomsten herzien. In de derde fase worden de orchestratielaag en het centrale verwerkersregister operationeel gemaakt, en worden BIO2- en NIS-2-compliancedossiers bijgewerkt met de nieuwe architectuurdocumentatie.
FAQ: soevereine multicloud poly-cloud strategie
Wat is het praktische verschil tussen een multicloud- en een poly-cloudstrategie?
Bij een multicloudstrategie gebruikt een organisatie meerdere cloudplatforms voor vergelijkbare werklasten, vaak per leverancier afgebakend. Een poly-cloudstrategie gaat verder: werklasten worden bewust over meerdere leveranciers verdeeld op basis van specifieke vereisten zoals soevereiniteit, latency of certificering, en er is een geïntegreerde orchestratielaag die overdraagbaarheid waarborgt.
Wat betekent SEAL-2 concreet voor een cloudleverancier?
SEAL-2 binnen het EUCS-framework vereist dat de cloudleverancier aantoonbaar voldoet aan Europese wetgeving, dat data binnen de EER blijft, dat toegang door niet-EU-entiteiten contractueel en technisch is uitgesloten, en dat de dienst onafhankelijk auditeerbaar is. Dit sluit leveranciers met operationele afhankelijkheden van Amerikaanse moedermaatschappijen in beginsel uit van SEAL-2-certificering.
Welke rol speelt de EU Data Act bij het wisselen van cloudleverancier?
Artikelen 23 tot en met 31 van de EU Data Act (Verordening 2023/2854) verplichten cloudleveranciers om klanten het recht te geven op dataportabiliteit en overstap naar een andere aanbieder, zonder buitensporige overstapkosten. Leveranciers moeten open standaarden hanteren voor data-export en zijn verplicht technische bijstand te verlenen tijdens de migratie.
Is SEAL-3 realistisch haalbaar in een multicloud-opzet na de Cloud III-aanbesteding?
De Cloud III DPS-uitkomsten laten zien dat SEAL-3 in een multicloud-opzet technisch zeer complex is. Leveranciers als OVHcloud, Scaleway, STACKIT en Proximus/S3NS bieden SEAL-3-compatibele diensten aan, maar het combineren van twee SEAL-3-leveranciers in één architectuur vereist zorgvuldige afstemming van sleutelbeheer, logging en auditrechten. In de praktijk kiezen veel overheidsorganisaties voor SEAL-3 voor de meest gevoelige werklasten en SEAL-2 voor de rest.
Hoe verhoudt BIO2 zich tot NIS-2 bij het inrichten van een soevereine cloudarchitectuur?
BIO2 is de Nederlandse implementatiestandaard voor overheidsorganisaties en vereist aantoonbare beheersing van de verwerkingsketen inclusief cloudleveranciers. NIS-2 is de Europese richtlijn die supply chain security en incidentrapportage verplicht voor aanbieders van essentiële en belangrijke diensten. BIO2 en NIS-2 vullen elkaar aan: BIO2 stelt operationele baselines, NIS-2 voegt risicobeheer en meldplicht toe. Een soevereine cloudarchitectuur moet aan beide voldoen.
