Blog

Cloud pentest: zo test u uw AWS, Azure of Google Cloud omgeving op kwetsbaarheden

Wat is een cloud pentest? Ontdek hoe u uw AWS, Azure of Google Cloud test op kwetsbaarheden. Regels per provider, kosten en NIS2-vereisten.
Cloud pentest architectuuroverzicht met beveiligingslagen voor AWS Azure en Google Cloud omgevingen

TL;DR: Een cloud pentest is een geautoriseerde aanvalssimulatie die de configuraties, identiteiten en toegangsrechten van uw cloudomgeving test op kwetsbaarheden. Anders dan een traditionele pentest draait het niet om netwerkperimeters, maar om IAM-misconfiguraties, overgeprivilegieerde rollen en onbeveiligde API’s. Voor Vlaamse KMO’s die op Azure of AWS werken, is een cloud pentest steeds relevanter, onder meer door NIS2-verplichtingen en GDPR-eisen aan cloudbeveiliging.

Meer dan 60% van de Belgische bedrijven werkt inmiddels in de cloud. Microsoft 365, Azure, AWS: de kans is groot dat ook uw bedrijfskritische data en applicaties ergens in een cloudomgeving draaien. Maar wie denkt dat de cloudprovider automatisch voor de beveiliging zorgt, komt bedrogen uit.

Volgens Gartner is tot eind 2025 meer dan 99% van alle cloud-inbreuken te wijten aan fouten aan de kant van de klant, niet aan tekortkomingen van de provider. Dat is waar een cloud pentest het verschil maakt. In dit artikel leest u wat een cloud pentest precies inhoudt, hoe het verschilt van een traditionele pentest, wat de regels zijn per provider, en wat het kost.

Wat is een cloud pentest en waarom is het anders dan een traditionele pentest?

Een cloud penetratietest is een geautoriseerde, offensieve evaluatie die specifiek de configuraties, identiteiten en beveiligingslagen van uw cloudomgeving analyseert. Het doel: kwetsbaarheden actief opsporen en exploiteren om aan te tonen hoe weerbaar uw organisatie werkelijk is.

Het fundamentele verschil met een traditionele penetratietest zit in de aanvalsvectoren. Bij een klassieke infrastructurele pentest ligt de nadruk op het doorbreken van netwerkperimeters en het exploiteren van softwarekwetsbaarheden om toegang te krijgen tot Active Directory-domeinen. In cloudomgevingen is de perimeter verschoven van het fysieke netwerk naar Identity and Access Management (IAM) en Role-Based Access Control (RBAC).

Concreet betekent dit dat aanvallers in de cloud zelden een firewall doorbreken. In plaats daarvan ketenen ze logische misconfiguraties en overgeprivilegieerde rollen aan elkaar om lateraal te bewegen of rechten te escaleren. Een service-account met te ruime rechten, een publiek toegankelijke storage-bucket, een API zonder snelheidslimieten: dat zijn de openingen die een cloud pentester zoekt.

Daar komt bij dat cloudomgevingen kortstondige en serverless workloads bevatten (denk aan Lambda-functies of Azure Functions) die traditionele, statische scanmethoden inefficiënt maken. Een cloud pentest vereist daarom gespecialiseerde tooling en methodologie.

De scope van een cloud pentest omvat de componenten die onder uw eigen controle vallen: IAM-configuratie, netwerksegmentatie binnen Virtual Private Clouds, permissiestructuren van storage, API-endpoints, containerplatformen en serverless-functies. Fysieke datacenters, hypervisors en het onderliggende netwerk van de provider vallen er expliciet buiten.

De meest voorkomende kwetsbaarheden in cloudomgevingen

Volgens de Cloud Security Alliance (CSA) Top Threats en de OWASP Cloud Top 10 zijn misconfiguraties en identiteitsgerelateerde zwakheden de primaire oorzaak van cloud-inbreuken. De meest kritieke kwetsbaarheden die pentesters aantreffen, vallen in vijf categorieën.

Overgeprivilegieerde IAM-rollen en service-accounts. Het toekennen van te ruime rechten aan gebruikers of geautomatiseerde processen is het meest voorkomende probleem. Aanvallers misbruiken permissies om overgeprivilegieerde rollen aan resources te koppelen en zo controle over de gehele omgeving te verkrijgen. Statische API-sleutels die via publieke code-repositories lekken, geven rechtstreeks toegang tot administratieve endpoints.

Publiek toegankelijke storage-buckets. Ongeautoriseerde schrijf- of anonieme leesrechten op AWS S3, Azure Blob Storage of vergelijkbare diensten leiden direct tot datalekken. De Capital One-inbreuk in 2019 is hiervan het bekendste voorbeeld: een aanvaller exfiltreerde persoonlijke gegevens van meer dan 100 miljoen klanten uit AWS S3-buckets, via een misgeconfigureerde Web Application Firewall met te ruime IAM-rechten.

Onbeveiligde API’s en metadata-endpoints. API’s die gevoelige gegevens retourneren zonder strikte authenticatie zijn kwetsbaar. Aanvallers proberen via Server-Side Request Forgery (SSRF) toegang te krijgen tot de Instance Metadata Service om tijdelijke credentials te oogsten.

Container escapes en Kubernetes-misconfiguraties. Overgeprivilegieerde pods die met root-toegang op de host draaien, stellen aanvallers in staat om uit de container te ontsnappen. Bij Azure Kubernetes Service (AKS) of Google Kubernetes Engine (GKE) komt dit regelmatig voor.

Gebrekkige netwerksegmentatie. Virtual Private Clouds die onvoldoende gescheiden zijn, of peering-verbindingen zonder strikte toegangscontroles, vergroten de blast radius van een geslaagde aanval aanzienlijk.

Cloud pentest per provider: AWS, Azure en Google Cloud

De uitvoering van een cloud pentest is gebonden aan strikte regels per provider. Die regels zijn de afgelopen jaren versoepeld, maar er gelden nog steeds duidelijke restricties.

AWS pentesting

Amazon Web Services vereist geen voorafgaande toestemming voor pentests op de meeste standaarddiensten, waaronder EC2, RDS, CloudFront, Lambda, API Gateway en Fargate. Alleen voor Command and Control-simulaties, phishing-scenario’s en load- of stresstests moet u vooraf toestemming aanvragen via het Simulated Event-formulier (minimaal 14 werkdagen vooraf).

Strikt verboden op AWS: Denial of Service (DoS/DDoS) simulaties en social engineering van AWS-personeel. De volledige richtlijnen vindt u in het AWS Customer Support Policy for Penetration Testing.

Azure pentesting

Microsoft Azure vereist sinds enkele jaren geen voorafgaande notificatie meer voor pentests op in-scope assets, waaronder Virtual Machines, App Services, Functions, Azure SQL, AKS en Entra ID. DDoS-testen zijn alleen toegestaan via goedgekeurde partners. Overmatig fuzzing-verkeer, social engineering van Microsoft-personeel en credential-reuse van derden zijn verboden.

Voor Vlaamse KMO’s is Azure bijzonder relevant: de Vlaamse markt wordt sterk gedomineerd door het Microsoft-ecosysteem, en sinds november 2025 is de Azure Belgium Central-regio in Brussel operationeel. Dat maakt het mogelijk om workloads lokaal op Belgische bodem te hosten.

Google Cloud pentesting

Google Cloud Platform vereist geen voorafgaande melding voor pentests op Compute Engine, Cloud Storage, Cloud Functions, GKE en App Engine. Verboden activiteiten: verstoring van gedeelde infrastructuur, testen van andere tenants, verspreiden van malware en phishing gericht op Google-medewerkers.

Google investeert ook in België: het datacenter in Saint-Ghislain wordt in 2026-2027 verder uitgebreid. Voor KMO’s met workloads op Google Cloud is dat relevant voor data residency en latentie.

Het shared responsibility model: wie is waarvoor verantwoordelijk?

Het fundament van cloudbeveiliging is het gedeelde verantwoordelijkheidsmodel. De verdeling van beveiligingstaken hangt af van de servicelaag die u gebruikt.

Bij Infrastructure as a Service (IaaS), zoals virtuele machines op Azure of EC2-instances op AWS, is de provider verantwoordelijk voor de fysieke beveiliging, stroomvoorziening en hypervisors. U bent verantwoordelijk voor het gastbesturingssysteem, patches, applicaties, firewallregels en IAM. De pentest richt zich dan op netwerkexploitatie, OS-kwetsbaarheden en lokale misconfiguraties.

Bij Platform as a Service (PaaS), zoals Azure App Services of Google App Engine, neemt de provider ook het besturingssysteem en de runtime voor zijn rekening. U bent verantwoordelijk voor applicatiecode, API-configuratie en databeveiliging. De pentest focust op API-kwetsbaarheden en authenticatieomzeiling.

Bij Software as a Service (SaaS), zoals Microsoft 365, beheert de provider de volledige stack. U bent verantwoordelijk voor gebruikersbeheer, apparaatcompliance en dataclassificatie. De pentest richt zich op identiteitsdiefstal en het omzeilen van Conditional Access en MFA. Een Microsoft 365 security audit legt precies deze risico’s bloot.

Een veelvoorkomend misverstand bij KMO’s is de aanname dat migratie naar een gerenommeerde cloudprovider de organisatie automatisch ontslaat van beveiligingsverplichtingen. Onderzoek toont aan dat circa 82% van de CISOs beveiligingsincidenten heeft meegemaakt die direct te herleiden waren tot verwarring over de grenzen van dit verantwoordelijkheidsmodel.

Hoe verloopt een cloud pentest in de praktijk?

Een cloud pentest volgt een gestructureerd proces van vier fasen. Een goede voorbereiding bepaalt in grote mate het rendement van de test.

Fase 1: scoping en autorisatie. Samen met de klant bepalen we welke cloudomgevingen, accounts en resources in scope vallen. We stellen een Rules of Engagement-document op met noodcontactpersonen, testvensters (bijvoorbeeld buiten kantooruren) en procedures om de test direct te staken bij onvoorziene incidenten. Bij Vlaamse KMO’s die Azure gebruiken, begint de scoping vaak bij de Entra ID-tenant en de gekoppelde subscriptions.

Fase 2: voorbereiding door de klant. De grey-box testmethode heeft in de praktijk de voorkeur: de tester krijgt vooraf een gelimiteerd setje credentials om een realistisch scenario te simuleren van een gecompromitteerde medewerker. De klant levert architectuurschema’s, IAM-beleidsdefinities, API-specificaties en een expliciete lijst van in-scope resources aan. Voor de configuratie-audit volstaat een rol met uitsluitend leesrechten (zoals Azure Security Reader of AWS ReadOnlyAccess).

Fase 3: uitvoering. De test combineert geautomatiseerde configuratiescans met handmatige exploitatie. Gespecialiseerde tools zoals Prowler (AWS), AzureHound (Azure/Entra ID) en ScoutSuite (multi-cloud) scannen de configuratie tegen CIS-benchmarks en compliance-standaarden. Daarnaast voert de pentester handmatige aanvalssimulaties uit: IAM-rechten escaleren, credentials oogsten, detectie ontwijken en kwetsbaarheden in opeenvolgende stappen aan elkaar schakelen. Er worden uitsluitend niet-destructieve proof-of-concept payloads gebruikt.

Fase 4: rapportage en remediatie. Het rapport bevat een management summary en technisch detail per bevinding, inclusief risicoclassificatie, bewijs en concrete aanbevelingen. Wie zich voorbereidt op een cybersecurity audit, kan het cloud pentest-rapport direct als input gebruiken.

Een belangrijk aandachtspunt: agressieve scanners kunnen API-rate-limits overschrijden, waardoor legitieme applicaties geen verbinding meer maken. Professionele testers configureren strikte snelheidsbeperkingen en voeren bij voorkeur tests uit op een staging-omgeving die een exacte kopie is van productie.

Cloud pentest en GDPR: wat u moet weten over data residency

Wanneer een Vlaamse KMO een cloudomgeving laat pentesten, is de GDPR direct van toepassing. Cloudomgevingen bevatten vrijwel altijd persoonsgegevens: klantendatabases, personeelsbestanden in Microsoft 365, facturatiedata.

De penetratietester treedt onder de GDPR op als Verwerker (Processor). Op grond van Artikel 28 GDPR is het afsluiten van een verwerkersovereenkomst (Data Processing Agreement) wettelijk verplicht voordat de test start. Die overeenkomst bevat onder meer het verbod op verwerking van persoonsgegevens voor eigen doeleinden, strikte procedures bij het ontdekken van een datalek, en de afspraak dat alle testgegevens na afronding definitief worden vernietigd.

De Belgische Gegevensbeschermingsautoriteit (GBA) beschouwt penetratietesten als een cruciaal instrument om aan de aantoonbaarheidsplicht van Artikel 32 GDPR te voldoen. Belangrijk: de GBA hanteert nultolerantie ten aanzien van papieren compliance. Verwerkersovereenkomsten moeten daadwerkelijk in de praktijk worden nageleefd.

Data residency voegt een extra dimensie toe. Onder de CLOUD Act kunnen Amerikaanse autoriteiten Amerikaanse cloudproviders dwingen om toegang te verlenen tot data, ongeacht waar de servers zich bevinden. Het opslaan van data in een Europees datacenter biedt daarmee geen sluitende bescherming tegen Amerikaanse datavorderingen.

Tijdens een cloud pentest controleert de tester daarom of back-uptrajecten, beheerconsoles of logs onbewust data buiten de Europese Economische Ruimte transporteren. Dat kan een GDPR-inbreuk vormen. De tester mag zelf onder geen beding persoonsgegevens kopiëren naar systemen buiten de EU. De opening van Azure Belgium Central in Brussel (november 2025) en Google’s datacenter-uitbreidingen in Saint-Ghislain verbeteren de mogelijkheden voor lokale dataverwerking aanzienlijk.

Cloud pentest en NIS2: verplichtingen voor Belgische bedrijven

De Belgische NIS2-wetgeving, in werking getreden op 18 oktober 2024, stelt strenge beveiligingseisen aan kritieke sectoren en hun toeleveringsketens. Cloudproviders, datacenteraanbieders en managed service providers vallen expliciet onder de richtlijn.

Voor KMO’s die clouddiensten afnemen, stelt NIS2 strikte eisen aan supply chain security. Organisaties moeten de beveiligingskwaliteit van hun directe leveranciers evalueren. Een cloud pentest dient hierbij als objectief bewijsmiddel: het toont aan dat uw cloud-workloads en configuraties proactief worden gecontroleerd op kwetsbaarheden. Dat is een kernvereiste onder de NIS2-risicobeheersmaatregelen.

Cloudproviders kunnen hun maatregelen mappen tegen het CyFun-referentiekader van het Centrum voor Cybersecurity België (CCB). Voor KMO’s die onder NIS2 vallen, is een cloud pentest geen luxe maar een bouwsteen van hun compliance-dossier.

Het niet naleven van de risicobeheersmaatregelen kan leiden tot boetes die voor essentiële entiteiten oplopen tot €10 miljoen of 2% van de wereldwijde jaaromzet.

Wat kost een cloud pentest?

De kosten van een pentest variëren sterk op basis van scope, complexiteit en diepgang van de handmatige exploitatie. Professionele cyberbeveiligingsbedrijven hanteren voor senior gecertificeerde ethische hackers (OSCP, CREST) een dagtarief tussen €1.200 en €1.800.

Een cloud configuration review van een enkelvoudige omgeving (bijvoorbeeld een Azure-tenant audit) neemt 3 tot 5 dagen in beslag en kost €4.500 tot €9.000. Een volledige cloud pentest met configuratie-audit én actieve exploitatie duurt 6 tot 12 dagen en kost €9.000 tot €20.000 of meer, afhankelijk van het aantal API’s, serverless workloads en de integratie met on-premise Active Directory. Multi-cloud assessments over AWS en Azure gecombineerd kosten €17.000 tot €35.000 of meer.

Ter vergelijking: een standaard web- of API-applicatietest binnen de cloud kost €3.500 tot €7.500 voor 3 tot 5 dagen. De kosten hangen sterk samen met het aantal unieke platformen, de aanwezigheid van Kubernetes-orchestratie en de omvang van de netwerkperimeters.

Een belangrijk signaal: tarieven onder €600 per dag duiden in de regel op volledig geautomatiseerde scans die als handmatige tests worden gepresenteerd. Daar mist u de diepgaande beveiligingswaarde van een echte pentest.

Subsidies voor Vlaamse KMO’s. Via de VLAIO KMO-portefeuille ontvangt u tot 45% subsidie (kleine ondernemingen) of 35% (middelgrote). Maximaal €7.500 per jaar. Sinds februari 2026 is de KMO-portefeuille exclusief voorbehouden voor cybersecurity-advies. Daarnaast biedt het VLAIO Cybersecurity Verbetertraject tot 50% subsidie voor begeleide trajecten van €7.100 tot €39.900, inclusief audit, awareness en technische maatregelen.

Veelgestelde vragen over cloud pentesting

Moet ik de cloudprovider op de hoogte brengen voor een pentest?

Bij AWS, Azure en Google Cloud is voorafgaande toestemming voor de meeste standaardtests niet meer vereist. Alleen voor specifieke scenario’s zoals DDoS-simulaties of phishing moet u vooraf toestemming aanvragen. Controleer altijd de actuele Acceptable Use Policy van uw provider.

Kan een cloud pentest mijn productieomgeving verstoren?

Ja, dat risico bestaat. Agressieve scanners kunnen API-rate-limits overschrijden. Professionele testers mitigeren dit door strikte snelheidsbeperkingen in te stellen en bij voorkeur op een staging-omgeving te testen. Als productietests noodzakelijk zijn, worden destructieve exploits vooraf uit de scope gehouden.

Wat is het verschil tussen een cloud configuration review en een cloud pentest?

Een configuration review is een passieve audit die controleert of uw instellingen voldoen aan best practices (zoals CIS-benchmarks). Een pentest gaat verder: het probeert misconfiguraties actief te exploiteren, detectiemechanismen te omzeilen en kwetsbaarheden aan elkaar te schakelen om een reëel risico aan te tonen.

Hoe vaak moet ik een cloud pentest laten uitvoeren?

Minimaal jaarlijks, en aanvullend na elke significante wijziging in uw cloudomgeving: migratie naar een nieuwe provider, toevoegen van nieuwe workloads, wijzigingen in IAM-structuur. Onder NIS2 wordt regelmatig testen verwacht als onderdeel van uw risicobeheersmaatregelen.

Is een cloud pentest verplicht onder NIS2?

NIS2 schrijft niet letterlijk een pentest voor, maar verplicht organisaties om de effectiviteit van hun beveiligingsmaatregelen regelmatig te testen en te evalueren. Een cloud pentest is een van de meest concrete manieren om hieraan te voldoen en dient als bewijsmiddel bij een conformiteitsbeoordeling.

Hoe kies ik een geschikt bedrijf voor een cloud pentest?

Let op certificeringen van het testteam (OSCP, CREST, CISSP), ervaring met uw specifieke cloudprovider, kennis van Belgische regelgeving (NIS2, GDPR, CyFun) en de kwaliteit van de rapportage. Vraag expliciet hoeveel procent van de testtijd handmatige analyse betreft versus geautomatiseerd scannen. Lees ook ons artikel over het kiezen van een pentest bedrijf in België voor een volledige checklist.

Conclusie: wanneer is een cloud pentest de juiste keuze?

Een cloud pentest is relevant zodra uw organisatie bedrijfskritische data of applicaties in de cloud heeft draaien, zeker als u onder NIS2 valt of als uw klanten om aantoonbare cloudbeveiliging vragen.

Volgens Eurostat werkt 61,62% van de Belgische bedrijven in de cloud. Uit het Verizon DBIR 2026 blijkt dat de exploitatie van softwarekwetsbaarheden met 31% voor het eerst de belangrijkste initiële toegangsmethode is geworden, terwijl AI-gestuurde tools aanvallers in staat stellen kwetsbaarheden binnen uren na publicatie te exploiteren. De gemiddelde kosten van een datalek bedragen volgens IBM’s Cost of a Data Breach Report 2025 wereldwijd $4,44 miljoen; cloud-inbreuken over meerdere omgevingen liggen nog hoger op $4,75 miljoen.

De kernvraag is niet of u kwetsbaarheden hebt, maar of u ze kent voordat iemand anders ze vindt.

Wilt u weten hoe uw cloudomgeving scoort? Plan een vrijblijvend kennismakingsgesprek en ontdek welke aanpak het beste bij uw situatie past.