Gedeelde verantwoordelijkheid, gedeelde verwarring: van wie is security in de cloud?

Als bedrijven naar de cloud verhuizen, gaan ze er vaak van uit dat de provider — AWS, Azure of Google Cloud — de security wel regelt. Het is tenslotte hun datacenter, hun servers, hun infrastructuur.

De werkelijkheid ligt genuanceerder. Cloudsecurity draait om een model van gedeelde verantwoordelijkheid: de provider beveiligt de onderliggende infrastructuur, maar jij als klant blijft verantwoordelijk voor wat je erin zet.

En daar begint helaas de verwarring — en soms ook het datalek.

Elke grote cloudprovider heeft zijn eigen versie van dit model, maar de kern is steeds dezelfde:

De provider is verantwoordelijk vóór de cloud, jij bent verantwoordelijk ín de cloud.

De provider neemt de fysieke datacenters, het netwerk, de hardware en de basisdiensten van het platform voor zijn rekening.

De klant is verantwoordelijk voor configuratie, gegevensbeheer, toegangsbeheer en de security van zijn applicaties.

Oftewel: AWS beveiligt de servers — maar hoe jouw workloads en gebruikers daarmee omgaan, is aan jou.

Een van de redenen dat de verwarring blijft hangen, is dat de grens tussen infrastructuur en gebruik steeds verschuift.

Bij Infrastructure as a Service (IaaS) beheert de provider de hardware, maar beheer jij het besturingssysteem, de runtime en alles daarboven.

Bij Platform as a Service (PaaS) raak je de controle over het besturingssysteem kwijt, maar blijf je verantwoordelijk voor de security van je applicatie en je toegangsbeheer.

Bij Software as a Service (SaaS) beheer je alleen nog je gebruikersdata en je toegangsbeleid — en zelfs dat gaat vaak mis.

Dat glijdende schaaltje creëert een grijs gebied: veel organisaties nemen aan dat security “bij het platform hoort”, om er vervolgens achter te komen dat dat niet zo is. Niet volledig, in elk geval.

Zelfs volwassen teams onderschatten hun eigen aandeel. Klassieke valkuilen:

1. Te veel vertrouwen op standaardinstellingen. Cloudproviders leveren veilige standaarden — maar die passen zelden op elk gebruik. Verkeerd ingestelde storage buckets of te ruime IAM-rollen liggen aan de basis van talloze datalekken.

2. Identity en toegangsbeheer verwaarlozen. Het grootste risico in de cloud is niet je infrastructuur — het is wie waarbij kan. Least privilege niet volgen of access keys niet roteren wordt zo een incident.

3. Data die niet of slecht versleuteld is. Encryptie die “beschikbaar” is, betekent niet dat encryptie “aan” staat. Het is aan jou om het in te schakelen, sleutels te beheren en je beleid consistent te houden.

4. Gebrek aan zicht. Veel bedrijven rollen uit over meerdere regio's of zelfs meerdere clouds zonder centrale logging of monitoring. Gaat er iets mis, dan kost het achterhalen waar het misging dagen.

Jarenlang haalden lekkende AWS S3-buckets het nieuws — van medische dossiers tot overheidsgegevens.

De ironie? S3 was nooit onveilig. Het probleem zat in hoe klanten het gebruikten. Buckets stonden per ongeluk publiek, of credentials belandden in een code repository.

AWS bood encryptie, toegangsbeheer en audit trails — maar de verantwoordelijkheid om die goed te gebruiken lag volledig bij de klant.

Security in de cloud gaat niet alleen over techniek — het gaat over afstemming. Wil je het gedeelde model laten werken, dan moeten beide kanten open en samenwerkend opereren.

Hoe je dat doet:

1. Bepaal je securitygrenzen vroeg. Breng in kaart wie wat beheert — van patchen en back-ups tot IAM en sleutelrotatie. Neem dat op in je architectuurdocumentatie.

2. Gebruik de tools van je provider verstandig. AWS Security Hub, Azure Defender en GCP Security Command Center bestaan niet voor niets. Koppel ze vroeg aan en automatiseer waar het kan.

3. Automatiseer compliance en audits. Met Terraform, CloudFormation of Pulumi leg je je securitybeleid vast als code — zodat je instellingen over al je omgevingen consistent blijven.

4. Blijf je teams opleiden. De cloud ontwikkelt zich sneller dan de meeste interne trainingen. Zorg dat je engineers zowel het model van de provider als je eigen beleid begrijpen.

De term gedeelde verantwoordelijkheid wordt vaak gelezen als verdeelde verantwoordelijkheid. Dat is het niet. Het gaat om samenwerken.

Cloudproviders leggen een veilig fundament — encryptie, redundantie, toegangsbeheer — maar jouw team bouwt alles wat daarbovenop komt.
Je eigen kant verwaarlozen brengt niet alleen je applicatie in gevaar, maar de hele vertrouwensketen.

Naarmate de cloud dieper verankerd raakt, zijn het niet de organisaties die diensten consumeren die het redden — maar die welke begrijpen welk contract van verantwoordelijkheid daarbij hoort.

De cloud is op zichzelf niet onveilig. Onveilig is het verkeerd begrijpen van hoe hij werkt.

De bedrijven die floreren in het cloudtijdperk zijn de bedrijven die gedeelde verantwoordelijkheid niet als last zien, maar als kans — om beter te ontwerpen, slimmer te controleren en effectiever samen te werken met hun cloudpartners.

Want uiteindelijk werkt gedeelde verantwoordelijkheid alleen als beide kanten hem ook echt delen.