Cloud security uitgelegd: wie beveiligt wat

Wat is cloud security?

Cloud security gaat over alles wat bij een cloudleverancier draait: servers, opslag, applicaties en de gegevens die erin staan. Je beschermt dezelfde dingen als in een eigen omgeving: toegang, data, configuratie, monitoring en incidenten. Het is dus geen aparte wereld naast gewone security, maar hetzelfde vak met een andere verdeling van het werk. Een deel ligt bij de leverancier en een deel bij jou.

NIST omschrijft cloud computing als een model waarin je via het netwerk op aanvraag toegang krijgt tot een gedeelde pool van configureerbare computerbronnen, zoals netwerken, servers, opslag, applicaties en diensten, die snel beschikbaar komen met minimale beheerinspanning. Vacatures voor dit werk vind je bij cloud security.

Het NCSC zegt dat clouddiensten niet per se veiliger of onveiliger zijn dan een eigen IT-omgeving, maar dat de risico's, kosten en mogelijkheden vaak wel verschillen. De vraag is dus minder of de cloud veilig is, en meer wat je erin zet en hoe je het inricht. De rest van deze pagina laat zien hoe die taken verdeeld zijn.

Wat is de cloud volgens NIST?

NIST beschrijft de cloud met vijf kenmerken:

• On-demand self-service. Je neemt zelf en automatisch bronnen af, zoals servertijd en opslag.
• Brede netwerktoegang. De diensten zijn via het netwerk bereikbaar, voor allerlei soorten apparaten.
• Resource pooling. De bronnen van de leverancier worden gedeeld over meerdere afnemers (multi-tenant).
• Snelle elasticiteit. De capaciteit kan snel omhoog en omlaag, soms automatisch.
• Gemeten gebruik. Het gebruik wordt gemeten, bewaakt en gerapporteerd.

NIST onderscheidt drie dienstmodellen. De tabel laat zien wat jij als klant krijgt en wat jij daarvan beheert.

NIST onderscheidt ook vier uitrolmodellen. Een private cloud is bedoeld voor één organisatie. Een community cloud is voor een gemeenschap van organisaties met gedeelde belangen, en een public cloud staat open voor het publiek. Een hybrid cloud koppelt twee of meer clouds zo aan elkaar dat data en applicaties kunnen worden overgedragen. Bron: NIST SP 800-145.

Het dienstmodel bepaalt hoeveel je zelf beheert. Bij IaaS beheer je de virtuele machine tot en met het besturingssysteem en de applicaties erop, bij SaaS vooral wie er toegang heeft en welke instellingen aan staan. Hoe verder je naar SaaS gaat, hoe minder techniek je beheert, maar niet minder verantwoordelijkheid.

Wie is waarvoor verantwoordelijk?

Het shared responsibility model zegt dat de leverancier en de klant elk een deel van de beveiliging dragen. AWS noemt het deel van de leverancier "security of the cloud": de infrastructuur waarop alle AWS-diensten draaien, met hardware, software, netwerken en faciliteiten. Het deel van de klant, "security in the cloud", hangt af van de diensten die de klant kiest en bestaat uit de configuratie die de klant zelf moet doen. Bron: AWS, shared responsibility model.

Bij Amazon EC2, een IaaS-dienst, beheert de klant het gastbesturingssysteem, de geïnstalleerde applicaties en de configuratie van de firewall van AWS, de security group. Bij abstracte diensten zoals Amazon S3 en DynamoDB beheert AWS de infrastructuur, het besturingssysteem en de platformen. De klant blijft dan verantwoordelijk voor de eigen data, inclusief de versleutelingsopties, het classificeren van bedrijfsmiddelen en het instellen van rechten via IAM. Hoe dat werkt, lees je in het artikel over identity and access management. Volgens AWS varieert de verdeling met onder meer de gekozen diensten en regio's. Praktijkkennis van AWS komt daar bovenop.

Microsoft schrijft in de Azure-documentatie dat je bij elk type clouddeployment eigenaar blijft van je data en identiteiten. Volgens Microsoft blijven vier onderdelen altijd bij de klant: data (classificatie, bescherming, versleutelingskeuzes en naleving van eisen voor datagovernance), endpoints (laptops, desktops en mobiele apparaten die de clouddiensten gebruiken), accounts (aanmaken, beheren en verwijderen van gebruikers) en toegangsbeheer (rolgebaseerde toegang, multifactorauthenticatie en voorwaardelijke toegang). Dat laatste hangt samen met de zero trust-benadering, waarin netwerk en identiteit samen bepalen wie toegang krijgt. Zie ook Microsoft Azure.

Microsoft geeft daarnaast een matrix met per laag wie wat beheert. Dit is de indeling van Microsoft zelf.

Die indeling geldt niet voor elke leverancier en elke dienst. Microsoft bedoelt "verantwoordelijkheid" hier in governance-zin: wie verwacht wordt elke maatregel in te richten, te beheren en te bewaken. Het zijn illustratieve richtlijnen, geen juridische conclusies, en de afspraken tussen klant en Microsoft veranderen er niet door. Bron: Microsoft, shared responsibility in the cloud.

De leverancier beveiligt de basis, jij beveiligt wat je erop zet en hoe je het instelt.

Welke risico's horen bij de cloud?

Het NCSC noemt twee cloudrisico's. Het eerste is dat gegevens bij de cloudleverancier niet voldoende beschermd zijn. Het tweede is dat een verstoring bij de clouddienst het werk stil kan leggen. Wie gegevens of processen uitbesteedt, is afhankelijk van de beschikbaarheid, integriteit en vertrouwelijkheid (BIV) van die dienst. Het NCSC adviseert goede afspraken met de provider te maken, omdat je anders grip verliest op je gegevens, processen en verantwoordelijkheden. Bron: NCSC, cloud uitgelegd.

OWASP zet Security Misconfiguration op plaats 2 in de Top 10:2025. Het beschrijft dat als een systeem, applicatie of cloudservice die vanuit beveiligingsoogpunt verkeerd is ingesteld. Voorbeelden zijn ontbrekende hardening in de applicatiestack en onjuist ingestelde rechten op clouddiensten. Bron: OWASP Top 10:2025.

Veel cloudrisico's zitten in de instellingen die de klant beheert en minder in het datacenter van de leverancier. Een te ruime rol of een opslagplek die openstaat, is een instelling, en die beheert de klant. De OWASP-spiekbrief over threat modeling noemt voor cloudomgevingen onder meer de verdeling van verantwoordelijkheden, virtuele netwerken, IAM-rollen, opslagbuckets en dynamische omgevingen zoals containers, serverless en infrastructuur als code. Bron: OWASP Threat Modeling Cheat Sheet.

Bij een cloudleverancier hoort ook leveranciersbeheer: wie de leverancier is, welke afspraken er zijn en wat de exitstrategie is. Voor de wettelijke kant verwijzen we naar het artikel over NIS2 en de Cyberbeveiligingswet.

Wat is CSPM?

CSPM staat voor Cloud Security Posture Management: de inrichting van een cloudomgeving doorlopend toetsen aan beveiligingsstandaarden. Twee producten laten zien hoe dat werkt. We beschrijven wat hun documentatie zegt, zonder oordeel over de producten.

Volgens Microsoft is CSPM een kernonderdeel van Microsoft Defender for Cloud. Defender for Cloud toetst de cloudinfrastructuur voortdurend aan beveiligingsstandaarden en geeft aanbevelingen om misconfiguraties en risico's te verminderen, voor Azure, AWS en GCP. De secure score is gebaseerd op een deel van de aanbevelingen van de Microsoft Cloud Security Benchmark. Een hogere score betekent een lager geïdentificeerd risiconiveau. Bron: Microsoft Defender for Cloud, CSPM.

AWS Security Hub CSPM geeft volgens de AWS-documentatie een overzicht van de beveiligingsstatus in AWS. Het toetst de omgeving aan standaarden zoals de AWS Foundational Security Best Practices en externe kaders van het Center for Internet Security (CIS), PCI DSS en NIST. Per ingeschakelde standaard berekent het een score. Voor de meeste controles gebruikt het regels van AWS Config, en bevindingen kunnen automatisering of tickets in gang zetten. Bron: AWS Security Hub CSPM.

Cloudomgevingen veranderen snel, omdat bronnen met code worden aangemaakt en opgeruimd. Daarom controleer je instellingen continu en niet eens per jaar. CSPM-tools doen dat automatisch: ze vergelijken de inrichting met een standaard en melden afwijkingen. Een CSPM-tool geeft bevindingen, geen oplossingen. Iemand moet beoordelen welke bevindingen echt een risico zijn, ze oplossen en zorgen dat de oorzaak verdwijnt. Een score is een hulpmiddel en geen doel.

CSPM is iets anders dan een SIEM of EDR. CSPM kijkt naar de inrichting: klopt de configuratie? Een SIEM verzamelt en correleert logs en meldingen: wat gebeurt er nu? EDR kijkt naar endpoints. In de praktijk gebruik je ze naast elkaar. Meer over meldingen volgen staat in het artikel over SIEM.

Een voorbeeld: een opslagbucket die te open staat

Stel dat een ontwikkelaar een opslagmap tijdelijk openzet om een bestand met een collega te delen, en vergeet die weer dicht te zetten. Een CSPM-controle ziet de afwijking en meldt die. De cloud security engineer beoordeelt de melding en zet de toegang dicht. Daarna kijkt die aan de hand van de logging van de dienst of er gelezen is.

Tot slot past de engineer de instelling aan in de infrastructuurcode of het beleid, zodat dezelfde afwijking niet opnieuw kan ontstaan. Wie met Terraform of een andere vorm van infrastructuur als code werkt, legt cloudinstellingen vast in code. Dat maakt controle en herstel herhaalbaar.

Dit past bij de verdeling hierboven. De leverancier beheert de opslagdienst en de infrastructuur eronder. De klant beheert de instelling, dus of de map open of dicht staat. Bij AWS is de klant verantwoordelijk voor het instellen van rechten, en bij Microsoft blijft toegangsbeheer bij de klant.

Welke functies werken met cloud security?

• Cloud security engineer. Je richt cloudomgevingen veilig in, beheert rechten en netwerken, volgt de bevindingen van CSPM en andere tools op en helpt ontwikkelteams veilig te bouwen. Zie de vacatures, de werkgevers die deze functie zoeken en de rolgids.
• Security architect. Je ontwerpt hoe de organisatie beveiliging in de cloud opzet. Zie de vacatures en het vakgebied security architecture.
• IT-auditor. Je beoordeelt of het cloudgebruik aan de eisen voldoet. Zie de vacatures.
• SOC-analist. Je ziet meldingen uit cloudomgevingen terug in het SIEM en beoordeelt ze. Zie de vacatures.
• Information security officer. Je let op de afspraken met leveranciers en op het beleid voor cloudgebruik. Zie de vacatures.

Bij een platform als AWS, Azure of Google Cloud Platform komt praktijkkennis van dat platform bovenop de algemene concepten.

Voor de certificering is er de CCSP van ISC2 (Certified Cloud Security Professional). Die heeft zes domeinen: Cloud Concepts, Architecture and Design; Cloud Data Security; Cloud Platform and Infrastructure Security; Cloud Application Security; Cloud Security Operations; en Legal, Risk and Compliance. Bron: ISC2, CCSP. Meer staat in het CCSP-artikel en op de skillpagina. Voor platformroutes zijn er de AWS Security Specialty en de Microsoft-certificeringen.