Multi-cloud in 2026: van spreiding naar aantoonbare beheersing

Managementsamenvatting

Een nieuw NIST-ontwerp maakt duidelijk waarom multi-cloud niet automatisch gelijkstaat aan veerkracht of onderhandelingsmacht. NIST identificeert 23 beveiligings- en compliance-uitdagingen die uniek zijn aan, of aanzienlijk worden versterkt door, het combineren van autonome cloudomgevingen. De scherpste frictie zit bij identiteit, telemetry, configuratie, databeveiliging en aantoonbare compliance [1]. Voor architecten verschuift de ontwerpvraag daarom van “hoe verdelen we workloads?” naar “hoe bewijzen we dat verantwoordelijkheden en beheersmaatregelen over alle providergrenzen blijven werken?” Standaardiseer het bewijsmodel, de semantiek en besluitrechten; forceer geen technische gelijkheid waar clouddiensten wezenlijk verschillen. Multi-cloudvolwassenheid blijkt uit bestuurbaarheid, niet uit het aantal leveranciers.

Op 21 augustus 2026 publiceerde het Amerikaanse National Institute of Standards and Technology de eerste publieke ontwerpversie van NIST IR 8613, *Multi-Cloud Architecture Challenges: Security and Compliance Implications*. Het document komt van de NIST Multi-Cloud Security Public Working Group en is nadrukkelijk een probleemanalyse: geen definitieve norm, productvergelijking of kant-en-klare referentiearchitectuur. Reacties zijn mogelijk tot 5 oktober 2026; conclusies en formuleringen kunnen dus nog veranderen [1].

Juist die status maakt het document relevant. De werkgroep benoemt 23 geconsolideerde uitdagingsterreinen en herleidt die tot drie structurele oorzaken: beveiligingsrelevante verschillen tussen cloud-native diensten, organisatorische en personele complexiteit, en moeite om centrale beveiligingsfuncties over providergrenzen heen te laten werken. De gevolgen concentreren zich volgens NIST in vijf domeinen: identity and access management, telemetry en logging, configuratie- en wijzigingsbeheer, databeveiliging en compliance/autorisation [1].

De belangrijkste trendcall is daarom niet “meer multi-cloud”. Het nieuwe inzicht is dat multi-cloudarchitectuur een bewijsarchitectuur nodig heeft: een expliciet model dat laat zien welke partij welke control uitvoert, met welke gegevens dat wordt aangetoond en waar providerafwijkingen bewust zijn geaccepteerd. Dat raakt alle zes architectuurdisciplines.

1. Business Architecture: maak complexiteit een expliciete bedrijfskeuze

Multi-cloud ontstaat vaak geleidelijk: een acquisitie brengt een tweede platform mee, een AI-dienst is alleen bij een andere provider aantrekkelijk, of een gereguleerde workload vraagt om een specifieke regio. Zo kan een verzameling verstandige lokale besluiten uitgroeien tot een bedrijfsbreed besturingsprobleem. NIST onderscheidt terecht een door de afnemer georkestreerde multiple-cloudstrategie van een door een leverancier beheerde multi-clouddienst. In het eerste geval blijft de afnemer verantwoordelijk voor onderlinge verbindingen, securitybeleid, governance en databewegingen [1].

Dat onderscheid hoort in de operating model-keuze te staan. Benoem per cloudservice niet alleen een service owner en budgethouder, maar ook de eigenaar van provider-overstijgende risico’s. Leg besluitrechten vast voor identiteit, logging, sleutels, datalokalisatie, herstel en uitzonderingen. Een RACI op procesniveau is onvoldoende als niet zichtbaar is welke control door de provider, een intern platformteam of de producteigenaar wordt uitgevoerd.

De economische dimensie verdient dezelfde aandacht. NIST beschrijft dubbele tooling, vertaalarbeid en gespecialiseerde kennis als een blijvende “platform tax” van multi-cloud [1]. De FinOps Open Cost and Usage Specification (FOCUS) 1.4 normaliseert kosten- en gebruiksdata over cloud, SaaS, AI en andere technologieleveranciers en voegt datasets toe voor factuurreconciliatie en contractuele verplichtingen [2]. Dat lost beveiliging niet op, maar helpt wel om de echte bedrijfskosten van spreiding vergelijkbaar te maken.

Wat betekent dit voor architecten? Behandel multi-cloud als een investeringsbesluit met expliciete baten, beheerkosten en risico-eigenaarschap. Voeg aan elk principe zoals “vermijd leveranciersafhankelijkheid” een toetsbare tegenvraag toe: welke extra besturings- en bewijslaag financieren we om die onafhankelijkheid veilig te dragen?

2. Solution Architecture: ontwerp voor verschillen, niet voor schijnbare equivalentie

Een database, identity service of eventplatform met een vergelijkbaar etiket is niet automatisch architectonisch equivalent. NIST waarschuwt dat cloud-native componenten die dezelfde functie lijken te hebben, cruciale verschillen kunnen vertonen in beveiligingspraktijken, beheergrenzen en beschikbare bewijslast [1]. Een universeel abstraherende laag kan zulke verschillen verbergen zonder ze op te lossen.

Voor solution architects betekent dit dat portability en control equivalence los van elkaar moeten worden beoordeeld. Een workload kan technisch verplaatsbaar zijn terwijl de doelomgeving andere sleutelhiërarchieën, auditmogelijkheden of herstelgaranties heeft. Andersom kan een oplossing bewust gebruikmaken van leveranciersspecifieke diensten, mits afhankelijkheid, exitpad en compenserende controls expliciet zijn.

Maak daarom per kritieke bouwsteen een capability- én controlmapping. Beschrijf naast functionele eisen ook welke identiteiten worden gebruikt, welke logs beschikbaar zijn, welke configuratiegegevens onafhankelijk verifieerbaar zijn, hoe geheimen worden beheerd en welke afhankelijkheden het herstelpad kent. Modelleer cross-cloud interacties als eigen trust boundaries; een API tussen twee clouds is niet alleen een integratiepunt, maar ook een overdracht van identiteit, data, observability en verantwoordelijkheid.

Wat betekent dit voor architecten? Gebruik geen “lowest common denominator” als standaardantwoord. Standaardiseer interfaces en bewijsverwachtingen waar dat waarde oplevert, maar documenteer leverancierspecifieke verschillen als eerste-klas architectuurbesluiten. Een afwijkingenregister met risico-eigenaar en herbeoordelingsdatum is waardevoller dan een diagram dat alle clouds gelijk tekent.

3. Data Architecture: bestuur databewegingen en bewijscontext samen

In een multi-cloudlandschap is een dataregister pas bruikbaar als het ook de route en beveiligingscontext van gegevens laat zien. NIST signaleert onder meer onzekerheid over exacte datalocaties, uiteenlopende beschermingsmechanismen en complexe situaties waarin data tussen clouds of regio’s wordt verplaatst of gerepliceerd [1]. Dat raakt classificatie, bewaartermijnen, soevereiniteit, sleutelbeheer en herstel.

De data-architectuur moet daarom verder gaan dan een catalogus van datasets. Voeg voor kritieke gegevensproducten lineage over providergrenzen, toegestane regio’s, encryptie-eigenaarschap, sleutelrotatie, replicatiegedrag en vernietigingsbewijs toe. Koppel die metadata aan de beleidsbeslissing die de verwerking toestaat. Een generieke classificatie “vertrouwelijk” heeft weinig effect als niet duidelijk is welke concrete controls in elke cloud bij die classificatie horen.

Ook telemetry is data. Logs van verschillende providers hebben vaak andere formats, identiteiten en retentieopties. Normalisatie is nodig om gebeurtenissen te correleren, maar broncontext mag niet verloren gaan. OpenTelemetry definieert gemeenschappelijke namen en semantische conventies voor observabilitydata [3]. Dat biedt een nuttige basis voor consistente betekenis, maar ontslaat teams niet van het bewaren van provider-specifieke velden die voor onderzoek of compliance relevant zijn.

Wat betekent dit voor architecten? Ontwerp één logisch bewijsmodel voor data, zonder te doen alsof alle fysieke implementaties identiek zijn. Eis dat lineage, classificatie en controlstatus samen kunnen worden bevraagd. Test bovendien of een auditor of incident responder vanuit één gegevenselement terug kan redeneren naar bron, verwerking, identiteit, regio en toegepaste sleutel.

4. Infrastructure Architecture: bouw een federatieve beheerslaag

Centrale controle klinkt aantrekkelijk, maar één dashboard is niet hetzelfde als volledige beheersing. Volgens NIST maken uiteenlopende providerprotocollen, scanmogelijkheden, logformaten en configuratiebaselines het moeilijk om een compleet beeld van assets, kwetsbaarheden en wijzigingen te krijgen [1]. Sommige gegevens blijven bovendien ontoegankelijk omdat ze binnen het beheerde deel van een clouddienst vallen.

Een robuuste infrastructuurarchitectuur combineert daarom centrale normen met federatieve uitvoering. Definieer een enterprise-brede assetidentiteit, minimale logvelden, tijdsynchronisatie, configuratie-evidence, wijzigingsmetadata en escalatiepad. Laat provideradapters deze begrippen vertalen naar lokale diensten. Meet niet alleen of data wordt verzameld, maar ook dekking, vertraging, volledigheid en herleidbaarheid.

Infrastructure as Code helpt om bedoelde configuraties reproduceerbaar te maken, maar bewijst niet vanzelf dat de werkelijke toestand overeenkomt. Combineer gewenste toestand, runtime-observatie en onafhankelijke controles waar mogelijk. Neem ook de beheerslaag zelf op in de dreigingsanalyse: een gecentraliseerd platform voor identity, secrets of telemetry kan consistentie verbeteren, maar creëert een concentratierisico en een potentieel groot blast radius.

Wat betekent dit voor architecten? Ontwerp de control plane met dezelfde zorg als de workloads. Leg vast welke functies centraal moeten zijn, welke lokaal mogen verschillen en hoe uitval van de centrale laag wordt opgevangen. Maak ontbrekende providerinzage zichtbaar als restrisico in plaats van die gaten met een groen dashboard te maskeren.

5. Cloud Architecture: definieer eerst wat “multi-cloud” betekent

De term multi-cloud wordt vaak gebruikt voor alles van twee SaaS-contracten tot één applicatie die actief over meerdere hyperscalers draait. NIST hanteert een smallere, bruikbare definitie en maakt onderscheid tussen meerdere clouds die de afnemer zelf orkestreert en een door een provider verpakte multi-clouddienst [1]. Zonder zo’n afbakening zijn principes, kosten en controls niet toetsbaar.

Begin daarom met een actuele cloudtopologie: providers, diensten, regio’s, management planes, identiteitsdomeinen, netwerkgrenzen, datastromen en geërfde controls. Markeer waar een bedrijfsdienst werkelijk providergrenzen overschrijdt en waar alleen sprake is van portfolio-diversiteit. Niet elke omgeving heeft dezelfde integratielaag nodig.

Maak vervolgens het evidence contract onderdeel van de cloud landing zone. Dit contract specificeert welke bewijsstukken elke omgeving moet leveren: assetinventaris, role mappings, beleidsversies, logdekking, configuratieafwijkingen, back-up- en herstelresultaten, datalocatie en providerattestaties. Harmoniseer de semantiek, niet noodzakelijk het gereedschap. Waar een provider geen vergelijkbaar bewijs kan leveren, volgt een expliciete uitzondering, compenserende maatregel of architectuurbesluit.

Wat betekent dit voor architecten? Meet volwassenheid niet aan het aantal ondersteunde clouds. Een betere maat is de tijd die nodig is om voor een kritieke bedrijfsdienst verantwoordelijkheid, actuele controlstatus en herstelbaarheid over alle betrokken providers aan te tonen. Multi-cloud zonder zo’n meetbare beheersketen is vooral gedistribueerde onzekerheid.

6. Security Architecture: van controlcatalogus naar bewijsbare controlketen

Security Architecture krijgt in het NIST-ontwerp de meest directe waarschuwing. IAM, logging, configuratie, databeveiliging en autorisatie beïnvloeden elkaar; een zwakke identiteit kan bijvoorbeeld loggingcorrelatie, least privilege en incidentrespons tegelijk ondermijnen [1]. De aanvalsketen kan bovendien providergrenzen overschrijden: een publiek endpoint in de ene omgeving, een te ruime policy in een tweede en een kwetsbaarheid in een derde vormen samen een risico dat lokaal niet zichtbaar is.

NIST SP 800-207A biedt een nuttige aanvulling. Deze publicatie verschuift zero trust voor cloud-native applicaties van vertrouwen op netwerklocatie naar beleid op basis van gebruiker-, applicatie- en service-identiteiten, afgedwongen ongeacht de locatie van workloads [4]. Dat is richtinggevend, maar federatie alleen voorkomt geen privilege sprawl. Rollen, claims, tijdelijke toegang, machine-identiteiten en intrekking moeten over providers heen aantoonbaar op elkaar aansluiten.

Ontwerp daarom een controlketen: beleidsdoel, implementatie per provider, meetpunt, bewijsrecord, eigenaar en reactie bij afwijking. Laat correlation identifiers en tijdstempels providergrenzen overleven. Test aanvalspaden en herstelprocedures end-to-end, niet alleen per cloud. En behandel providerattestaties als één bewijssoort, niet als vervanging voor alle operationele waarneming.

Een belangrijk tegensignaal is dat centrale beveiliging niet overal haalbaar of wenselijk is. Volledige uniformiteit kan specifieke providerbescherming verzwakken of een nieuw single point of compromise creëren. Het doel is daarom consistente assurance: aantoonbaar vergelijkbare uitkomsten, met bewuste verschillen in techniek.

Wat betekent dit voor architecten? Verbind threat models, control mappings en audit evidence in één traceerbaar model. Prioriteer daarbij de vijf naden die NIST noemt. Begin met de bedrijfsdiensten waarbij identiteit, data of herstel meerdere providers kruisen; daar is de kans op onzichtbare gaten het grootst.

Conclusie

Het nieuwe NIST-ontwerp is geen bewijs dat iedere organisatie een multi-cloudstrategie nodig heeft. Het is juist een waarschuwing tegen de gedachte dat spreiding op zichzelf veerkracht, onafhankelijkheid of compliance oplevert. De materieel nieuwe architectuuropgave is het bouwen van een federatieve bewijslaag: gemeenschappelijke definities, besluitrechten en bewijsverwachtingen, gecombineerd met expliciete providerafwijkingen.

Voor enterprise-architecten is de praktische volgorde helder. Baken eerst de echte multi-cloudbedrijfsdiensten af. Leg vervolgens eigenaarschap en trust boundaries vast. Harmoniseer identity-, telemetry-, configuratie-, data- en compliancebewijs. Test tenslotte de keten over providergrenzen heen. Pas wanneer een organisatie snel kan aantonen wie verantwoordelijk is, welke control werkt en hoe herstel plaatsvindt, wordt multi-cloud een bestuurde architectuur in plaats van een verzameling contracten.

Bronnen

[1] NIST, *IR 8613 ipd — Multi-Cloud Architecture Challenges: Security and Compliance Implications*, 21 augustus 2026. https://csrc.nist.gov/pubs/ir/8613/ipd

[2] FinOps Foundation, *Introducing FOCUS 1.4: Invoice Reconciliation, Commitment Details, and Specification Maturity*, 10 juni 2026. https://www.finops.org/insights/introducing-focus-1-4/

[3] OpenTelemetry, *Semantic Conventions*. https://opentelemetry.io/docs/concepts/semantic-conventions/

[4] NIST, *SP 800-207A — A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments*, 13 september 2023. https://csrc.nist.gov/pubs/sp/800/207/a/final