Cloud security in hybride omgevingen

Hybride cloud-security is geen verzameling tools die je in twee of drie cloud-omgevingen aanzet. Het is een operating-model waarin shared responsibility, identity-as-perimeter, configuration-drift en multi-cloud-governance in samenhang belegd zijn, ongeacht waar het applicatielandschap draait. Wie het anders benadert, koopt platforms in plaats van een architectuur en ontdekt na een incident dat de verantwoordelijkheid wel verdeeld is, maar de regie nergens belegd. De vraag is niet welke hyperscaler-cloud het beste beveiligd is. De vraag is welk operating-model jij voert over alle omgevingen heen.

Waarom de vendor-keuze niet het antwoord is

In veel boardroom-discussies wordt cloud-security versmald tot een vergelijking tussen aanbieders. Welke hyperscaler-cloud heeft de beste guardrails, welk SaaS-platform de strakste compliance-certificering, welke private cloud de meest segmentatie. Die vergelijking is niet onzinnig, maar hij stelt de verkeerde vraag voorop. De aanbieders verschillen onderling minder dan hun marketing suggereert, en op het niveau van de basisbouwstenen leveren ze grotendeels vergelijkbare bouwblokken. Het verschil zit in wat jouw organisatie ermee doet.

Het shared responsibility-model maakt dat expliciet. De aanbieder is verantwoordelijk voor de security of the cloud, jij voor de security in the cloud. Klinkt helder, is het niet. De grens loopt per servicetype anders. Bij infrastructuur-as-a-service ligt vrijwel de hele configuratielaag bij jou, inclusief netwerk, identity en logging. Bij platform-as-a-service verschuift de grens omhoog. Bij SaaS verschuift hij nog verder, maar de data-classificatie, toegangsbeleid en exit-strategie blijven jouw werk. CSA Cloud Controls Matrix legt deze grens domein voor domein vast en laat zien hoe weinig vanzelfsprekend de verdeling is wanneer je het concreet maakt op control-niveau.

In een hybride omgeving lopen die grenzen door elkaar. Eén applicatie kan een front-end op een hyperscaler-cloud hebben, een database op een private platform, een identity-store in een derde SaaS-omgeving en een log-aggregatie op een vierde plek. Per component is de verantwoordelijkheidsverdeling anders. Wie de keten als geheel niet in beeld heeft, beheert de pijpen los van elkaar en mist de plekken waar verantwoordelijkheid in het niemandsland valt.

Wat het operating-model in samenhang houdt

Vier ankerpunten bepalen of een hybride cloud-architectuur in de praktijk overeind blijft. Niet als checklist, maar als samenhangende set waarin elk anker het volgende mogelijk maakt.

Asset-zicht dat aansluit op de werkelijke omgeving. Niet de CMDB van vorig kwartaal, maar een gefedereerd register dat applicaties, identiteiten, datastores en netwerkpaden over alle clouds heen toont. Zonder dat zicht is elke vervolgcontrol gebaseerd op aannames. NIST SP 800-204 onderstreept dat continue inventarisatie de basisvoorwaarde is voor elke microservices- en cloud-control die daarop volgt.

Identity-as-perimeter als ontwerpkeuze. In een omgeving zonder vaste netwerkrand is identiteit het enige consistente controlepunt. Een gebruiker, een service-account, een workload-identiteit, een api-key, allemaal volgens dezelfde lifecycle en met hetzelfde rigueur ingericht. Wie hier compromissen sluit, schuift het probleem door naar detectie en incident-response, waar het duurder en trager wordt.

Configuratie-discipline tegen drift. Cloud-omgevingen bewegen. Een infrastructure-as-code-baseline van zes maanden oud wijkt vrijwel altijd af van de realiteit, omdat tijdelijke wijzigingen permanent worden. Drift-detectie en geautomatiseerde herstelacties zijn geen luxe, ze zijn de enige manier om controle te houden in een omgeving waarin honderden ingenieurs dagelijks wijzigingen doorvoeren.

Multi-cloud-governance op control-niveau, niet op platform-niveau. Beleid moet vertaalbaar zijn naar elke omgeving waarin een applicatielandschap kan draaien. Een control die alleen werkt in één cloud is geen control, dat is een vendor-feature. ENISA Cloud Security-richtlijnen formuleren dit als de eis dat security-controls portable en auditeerbaar moeten zijn over leveranciers heen, juist omdat lock-in een operationeel risico is dat niet alleen op inkoop drukt.

De vier ankers werken in samenhang. Asset-zicht zonder identity-discipline geeft je een lijst zonder grip. Identity zonder configuratie-discipline laat goede toegangsregels stuk lopen op een misconfigured bucket. Configuratie-discipline zonder multi-cloud-governance werkt in één omgeving en valt om bij de volgende. En multi-cloud-governance zonder asset-zicht is beleid op papier dat niemand kan handhaven.

Waar configuration-drift in de praktijk pijn doet

Configuration-drift is de stille kostenpost van hybride omgevingen. Een storage-bucket die voor een migratie tijdelijk publiek werd gezet en daarna nooit teruggedraaid. Een security-group die voor een tweedaagse troubleshoot-sessie werd opengezet en zes maanden later nog open staat. Een service-account dat ooit voor een proof-of-concept werd aangemaakt en inmiddels productieworkloads aanspreekt. Elk afzonderlijk is dat een klein incident. Bij elkaar opgeteld is het de meest voorkomende oorzaak van publieke incidenten in hybride omgevingen.

De reden dat drift hardnekkig is, ligt zelden bij de techniek. De technische middelen om drift te detecteren en herstellen zijn al jaren beschikbaar. Het probleem zit in de governance-laag eromheen. Wie ziet de drift-rapportage. Wie heeft mandaat om wijzigingen terug te draaien. Wie spreekt het team aan dat het wel meldt maar niet oplost. In organisaties waar dit niet expliciet belegd is, blijft drift detecteerbaar maar onbeheersbaar. CSA Cloud Controls Matrix benoemt dit type bevinding onder change-management-controls die operationeel moeten worden afgedwongen, niet alleen procedureel gedocumenteerd.

Een tweede laag van drift zit in identiteiten. Service-accounts en workload-identities groeien in aantal en in rechten, zelden krimpen ze. Periodieke recertificering werkt voor menselijke gebruikers maar slecht voor machine-identiteiten, omdat de eigenaar vaak niet meer in dienst is of het account is overgegaan naar een andere applicatie. NCSC schrijft in zijn richtlijnen voor cloud-beveiliging expliciet dat machine-identity-management als aparte discipline moet worden ingericht, met andere processen dan menselijke access-reviews. In de praktijk wordt dit punt het vaakst overgeslagen, met als gevolg dat het privilege-niveau van applicaties structureel hoger ligt dan het ontwerp aangeeft.

Wat dit vraagt van de governance-laag

Multi-cloud-governance is geen extra documentlaag bovenop bestaand beleid. Het is een operationele discipline die op vier vragen scherp antwoord geeft, voor elke applicatie, op elk moment.

Welk control-niveau verwacht je van deze applicatie. Niet op platform-niveau, maar gekoppeld aan de classificatie van de data en de bedrijfsfunctie. Een applicatie die persoonsgegevens verwerkt valt onder hetzelfde regime ongeacht welke cloud hem draait.

Hoe weet je dat de control feitelijk werkt. Niet op basis van een vinkje in een policy-engine, maar via meetbare bewijslast op runtime. Een logregel die aangetoond bewaard wordt, een access-decision die getest is, een herstelactie die in een drift-scenario daadwerkelijk uitgevoerd is.

Wie is aanspreekbaar als de control faalt. Niet in de zin van schuld, maar in de zin van mandaat. Wie mag besluiten dat een productieworkload tijdelijk wordt teruggezet, een bucket gesloten, een identity gerevoceerd.

Wat is de exit-route als de leverancier verandert. Een control die alleen in deze cloud werkt, is een schuld die je nog niet hebt afgelost. De portabiliteit hoeft niet vandaag bewezen, maar moet wel ontworpen zijn.

Deze vier vragen vormen samen het scharnier tussen architectuur en operatie. Een operating-model dat deze vragen kan beantwoorden voor elk applicatielandschap in elke omgeving, blijft werken onder druk. Een dat het niet kan, is een verzameling configuraties die toevallig nog werkt.

Wat dit betekent voor jou als CIO

Je verantwoordelijkheid in een hybride omgeving is breder dan in de tijd dat het applicatielandschap in één datacenter draaide, en hij is anders verdeeld. Een deel van de uitvoering ligt bij leveranciers, een deel bij interne teams, een deel bij de applicatie-eigenaren. Wat niet bij iemand anders ligt, is de samenhang. De vraag of de ketting als geheel houdt, is de jouwe.

Dat vraagt dat je het gesprek over cloud-security weghaalt bij de tool-keuze en terugbrengt naar het operating-model. Welk asset-zicht heb je over alle omgevingen heen. Hoe is identity ingericht als consistent controlepunt. Hoe wordt drift gedetecteerd en hersteld. Hoe vertaalt beleid zich naar controls die in elke cloud werken en meetbaar zijn. Pas wanneer die vier ankers expliciet belegd zijn, gaat de discussie over welke cloud welke applicatie draait, weer ergens over.

De vendor-keuze blijft een keuze. Maar het is niet de keuze die bepaalt of jullie hybride cloud veilig is. Die keuze is hoe je het geheel als één omgeving regeert.