Cloudomgevingen bevatten vaak kwetsbaarheden in identiteit, configuratie, applicaties en infrastructuur; een cloud penetration tester onderzoekt die met schriftelijke toestemming als security professional.
Laatst bijgewerkt: juli 2026.
De rol lijkt op klassieke penetratietesting, maar de nadruk ligt anders. In cloudomgevingen ontstaan veel risico’s door IAM-rollen, permissies, storage-instellingen, netwerksegmentatie, logging, sleutelbeheer en automatisering via infrastructure as code. Een cloudtester zoekt daarom minder vaak naar één losse CVE en vaker naar een keten van configuratiefouten: een te ruime rol, een publiek opslagobject, ontbrekende logging en een serviceaccount dat meer rechten heeft dan nodig.
Dat maakt het werk technisch, maar ook methodisch. Een goede cloudtest begint met scope, toestemming en begrip van het gedeelde verantwoordelijkheidsmodel van de gekozen provider. AWS, Microsoft Azure en Google Cloud beveiligen hun onderliggende platformen, terwijl de klant verantwoordelijk blijft voor keuzes rond accounts, identiteiten, data, workloads, netwerktoegang en configuratie. Een tester moet die grens scherp kunnen uitleggen, omdat bevindingen anders snel verkeerd worden toegewezen.
Wat het werk in de praktijk inhoudt
Een cloud penetration tester beoordeelt hoe een aanvaller zich door een cloudomgeving zou kunnen bewegen. Dat begint meestal met inventarisatie van accounts, subscriptions, projecten, tenants, workloads, opslaglocaties, identiteiten en externe koppelingen. Daarna volgt onderzoek naar configuratiefouten, privilege escalation, exposed services, secrets in code, zwakke CI/CD-instellingen en onvoldoende detectie.
De uitkomst is geen verzameling losse screenshots. Werkgevers en opdrachtgevers verwachten een reproduceerbare aanvalsketen met zakelijke impact en haalbare mitigaties. Een bevinding als “storage bucket publiek toegankelijk” is pas nuttig wanneer duidelijk is welke data geraakt kan worden, welke policy of control ontbreekt, hoe misbruik aantoonbaar is binnen de scope, en welke cloud-native maatregel het risico verlaagt. Voor Azure kan dat bijvoorbeeld Azure Policy, Microsoft Defender for Cloud of conditional access zijn; voor AWS kan het gaan om service control policies, S3 Block Public Access, IAM Access Analyzer of CloudTrail-detectie.
In Nederlandse en Europese omgevingen speelt compliance nadrukkelijk mee. De AVG vraagt om dataminimalisatie en zorgvuldige omgang met persoonsgegevens tijdens tests. In de zorg kan NEN 7510 relevant zijn, bij overheidspartijen de BIO, en bij bredere governance ISO/IEC 27001 en ISO/IEC 27002. Ook het beleid voor coordinated vulnerability disclosure van NCSC-NL is belangrijk wanneer bevindingen buiten een formele opdracht ontstaan. Dit artikel is geen juridisch advies, maar een cloudtester moet deze kaders wel kennen om scope, logging, bewaartermijnen, rapportage en communicatie professioneel in te richten.
Voor wie deze loopbaan logisch is
De overstap naar cloud pentesting is vaak logisch voor securityanalisten, systeembeheerders, netwerkengineers, cloud engineers, DevOps-specialisten en ethische hackers die al ervaring hebben met infrastructuur of applicatiebeveiliging. Zij-instromers kunnen ook instappen, maar hebben eerst solide basiskennis nodig van netwerken, Linux, identity, scripting, websecurity en risicodenken.
Technische nieuwsgierigheid is nodig, maar schrijfvaardigheid weegt zwaarder dan veel starters verwachten. Een tester die een ingewikkelde privilege-escalatie kan demonstreren maar geen helder rapport kan schrijven, helpt een organisatie minder dan iemand die risico, bewijs, oorzaak en herstel concreet kan verbinden. In sollicitaties wordt daarom vaak gekeken naar voorbeeldrapporten, labverslagen, threat models en de manier waarop iemand ethische grenzen beschrijft.
Een veelgemaakte fout is om alleen tools te leren zonder het IAM- en policy-model van de cloudprovider te begrijpen. Een andere fout is testen zonder schriftelijke toestemming, labs draaien in productie-accounts of rapporten opleveren zonder cloud-native remediatie. De correctie is eenvoudig maar niet vrijblijvend: werk uitsluitend binnen expliciete scope, gebruik gescheiden labomgevingen, documenteer aannames, en koppel elke bevinding aan concrete controls van de gebruikte provider.
Welke cloud kies je eerst?
Een beginnende cloud penetration tester hoeft niet tegelijk Azure, AWS en Google Cloud te beheersen. Die aanpak leidt vaak tot oppervlakkige kennis. De betere keuze is één platform diep leren, de onderliggende concepten begrijpen en daarna pas uitbreiden naar multi-cloud. De eerste cloud kan het beste worden gekozen op basis van doelwerkgevers, sector, bestaande ervaring en beschikbare labs.
Wie al werkt in een Microsoft-omgeving of zich richt op organisaties met veel Entra ID, Microsoft 365 en Azure-workloads, kan starten met Azure-fundamenten en daarna Azure security verdiepen. Een logisch certificeringspad is eerst basiskennis zoals AZ-900 en vervolgens Microsoft Certified: Azure Security Engineer Associate via examen AZ-500. Wie vooral AWS-omgevingen tegenkomt, kan beginnen met AWS Cloud Practitioner en daarna AWS Certified Security – Specialty, waarbij IAM, Organizations, logging, storage en network controls centraal staan. Voor GCP past Professional Cloud Security Engineer bij rollen waarin Google Cloud-projecten, service accounts, IAM bindings en organization policies de kern vormen.
Vendor-neutrale kennis blijft nuttig omdat governance, risicobeheer en architectuur niet ophouden bij één provider. Certificeringen zoals CCSP helpen vooral bij cloud security governance en architectuurdenken, terwijl CISSP breder is en beter past bij professionals die securitymanagement, risicobeheer en ontwerpprincipes willen aantonen. Voor wie nog aan de basis bouwt, kan CompTIA Security+ een bruikbare opstap zijn naar gespecialiseerde cloudbeveiliging.
Een realistisch leerpad
Een sterk leerpad combineert theorie, labwerk en rapportage. Eerst moeten netwerkconcepten, identity, webapplicatiebeveiliging, Linux, scripting en logging voldoende stevig zijn. Daarna volgt het gekozen cloudplatform: accounts of tenants, IAM, storage, compute, serverless, containerdiensten, netwerkbeveiliging, monitoring en key management. Pas daarna worden red-teamtechnieken, exploit chains en detectie-aanbevelingen echt waardevol.
- Kies één cloudprovider die aansluit bij de stack van de gewenste werkgever of sector.
- Richt een gescheiden labaccount of tenant in zonder productiegegevens.
- Leer IAM, logging, storage en netwerkcontrols voordat aanvalstools worden gebruikt.
- Bouw kwetsbare labscenario’s met synthetische data en duidelijke kostenlimieten.
- Schrijf per scenario een kort rapport met impact, bewijs, oorzaak en hersteladvies.
Voor veilige labs zijn gescheiden accounts of tenants belangrijk. Gebruik geen productie-abonnement, geen echte klantdata en geen persoonlijke geheimen in code. Doelbewust kwetsbare omgevingen zoals AWSGoat en AzureGoat kunnen nuttig zijn, zolang ze geïsoleerd worden uitgerold en na afloop worden verwijderd. Budgetlimieten, MFA, logging en duidelijke naming conventions horen ook bij een professioneel lab, omdat een tester moet leren veilig te experimenteren.
Ethical hacking blijft een bruikbare basis, vooral voor web- en infrastructuurdenken. Een traject rond CEH kan helpen om klassieke testmethodiek, reconnaissance en kwetsbaarheidsanalyse te structureren, maar cloud pentesting vraagt daarna verdieping in provider-specifieke identity en configuratie. Certificaten vervangen geen praktijkervaring; ze maken vooral zichtbaar dat iemand begrippen, methodes en controls kan plaatsen.
Tooling: nuttig, maar alleen met begrip van de omgeving
Tools versnellen onderzoek, maar ze mogen de methode niet bepalen. In AWS kunnen Pacu, Prowler, ScoutSuite en CloudSploit helpen bij reconnaissance, configuratie-audits en het toetsen van bekende misconfiguraties. In Azure zijn AzureHound en BloodHound nuttig om identity-relaties en mogelijke privilege paths te analyseren, naast Microsoft Defender for Cloud, Entra ID-logs en Azure Policy voor verdedigende context. Voor Kubernetes-omgevingen komen tools zoals kube-bench, kube-hunter en kubectl-analyse pas goed tot hun recht wanneer de tester begrijpt hoe clusters, serviceaccounts, RBAC en admission controls zijn ingericht.
De toolkeuze verschilt per fase. Reconnaissance vraagt om inventarisatie en permissieanalyse. Configuratie-audits vragen om policychecks en vergelijking met kaders zoals CSA CCM, CIS Benchmarks, ISO/IEC 27001 en interne security baselines. Exploitatie vraagt om terughoudendheid en duidelijke scope, vooral wanneer data of beschikbaarheid geraakt kan worden. Post-exploitatie hoort beperkt en controleerbaar te zijn, met aandacht voor logging en detectie. De rapportage moet vervolgens beschrijven welke signalen in CloudTrail, Azure Activity Logs, Google Cloud Audit Logs of SIEM-regels zichtbaar hadden moeten zijn.
Onderstaande labhandeling toont hoe een veelvoorkomende S3-configuratiefout veilig kan worden gecontroleerd en hersteld in een eigen AWS-lab. Dit hoort uitsluitend te gebeuren in een account waarvoor expliciete toestemming bestaat.
Example — S3-public access controleren en blokkeren
aws s3api get-public-access-block \
--bucket klantdata-lab-logs
aws s3api put-public-access-block \
--bucket klantdata-lab-logs \
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
De eerste opdracht controleert of publieke toegang al geblokkeerd is voor de labbucket. De tweede opdracht zet de vier S3 Block Public Access-instellingen aan. In een rapport zou de tester vervolgens vastleggen welke data bereikbaar was, welke policy dit mogelijk maakte, welke AWS-control het probleem oplost en welke monitoring nodig is om herhaling te detecteren.
Compliance en scope in Nederland en Europa
Cloud pentesting raakt bijna altijd aan gegevensbescherming en contractuele afspraken. De AVG maakt dataminimalisatie belangrijk: verzamel tijdens een test alleen bewijs dat nodig is om de bevinding aan te tonen. Een screenshot van metadata of een beperkte bestandslijst is vaak beter dan het downloaden van volledige datasets. Als persoonsgegevens toch zichtbaar worden, moet vooraf duidelijk zijn hoe logging, opslag, versleuteling, toegang en verwijdering van testbewijs zijn geregeld.
Bij organisaties in de publieke sector kan de BIO invloed hebben op de manier waarop risico’s worden geclassificeerd en gerapporteerd. In zorgomgevingen kan NEN 7510 richting geven aan beheersmaatregelen rond beschikbaarheid, integriteit en vertrouwelijkheid van gezondheidsinformatie. ENISA-publicaties en de CSA Cloud Controls Matrix kunnen helpen om cloudrisico’s te ordenen, terwijl de officiële documentatie van AWS, Microsoft Azure en Google Cloud nodig blijft voor correcte implementatiedetails.
Ook responsible disclosure hoort bij professioneel gedrag. Wanneer een tester buiten een opdracht een kwetsbaarheid aantreft, zijn de CVD-richtlijnen van NCSC-NL relevant voor zorgvuldige melding. Binnen een opdracht moet de procedure al in het testplan staan: contactpersonen, escalatiekanalen, vensters voor testen, uitgesloten systemen, stopcriteria en afspraken over bewijsverzameling. Zonder die afspraken kan een technisch correcte test alsnog operationeel of juridisch problematisch worden.
Portfolio en eerste baan
Hiring managers kijken doorgaans naar aantoonbare vaardigheid, niet alleen naar certificaten. Een sterk portfolio bevat labscenario’s waarin de kandidaat een misconfiguratie vindt, de impact uitlegt, misbruik beperkt demonstreert en daarna hersteladvies geeft met provider-native controls. Een voorbeeld kan zijn: een te brede IAM-policy leidt tot toegang tot een storage-account, logging toont onvoldoende detail, en het herstel bestaat uit least privilege, policyvoorwaarden, alerting en periodieke access review.
Rapportkwaliteit is een onderscheidende factor. Een goed rapport maakt duidelijk wat de scope was, welke aannames golden, welke stappen reproduceerbaar zijn, welke data niet is ingezien, welke risico’s prioriteit hebben en welke herstelmaatregelen praktisch uitvoerbaar zijn. Ethisch handelen moet zichtbaar zijn in de manier waarop bewijs wordt verzameld, hoe voorzichtig met data wordt omgegaan en hoe beperkingen worden benoemd.
De eerste rol hoeft niet meteen “cloud penetration tester” te heten. Security engineer, cloud security analyst, SOC-analist met cloudfocus, DevSecOps engineer of vulnerability management-specialist kunnen goede opstappen zijn. Vanuit zulke rollen ontstaat toegang tot echte omgevingen, changeprocessen, logging, incidentrespons en architectuurbesluiten. Die context maakt latere pentestbevindingen scherper en geloofwaardiger.
Certificeringen die passen bij verschillende fases
Certificeringen zijn vooral nuttig wanneer ze aansluiten op de fase waarin iemand zich bevindt. Voor starters draait het om securityfundamenten, netwerkbegrip en basisrisicomanagement. Voor professionals met cloudbasis gaat het om provider-specifieke security, IAM en monitoring. Voor gevorderde testers worden architectuur, governance en bredere risicokaders belangrijker.
| Fase |
Focus |
Passende richting |
| Instap |
Securitybasis, netwerken, risico en terminologie |
Security+-achtige basiskennis en praktische labs |
| Cloudbasis |
IAM, storage, logging, netwerkcontrols en gedeelde verantwoordelijkheid |
Azure-, AWS- of GCP-fundamenten plus hands-on configuratie |
| Specialisatie |
Cloud security engineering, aanvalsketens en remediatie |
AZ-500, AWS Security – Specialty of Google Professional Cloud Security Engineer |
| Verbreding |
Governance, architectuur, compliance en risicomanagement |
CCSP, CISSP of vergelijkbare architectuurgerichte certificering |
Wie gestructureerd meerdere securityonderwerpen wil combineren, kan een trainingsaanpak zoals Unlimited Security Training van Readynez gebruiken om basiskennis, cloudbeveiliging en certificeringsvoorbereiding te plannen. Het blijft belangrijk om iedere trainingsstap te koppelen aan eigen labs, rapportage-oefeningen en realistische scenario’s.
Waar deze loopbaan naartoe kan groeien
Cloud penetration testing kan doorgroeien richting red teaming, cloud security architecture, incident response, DevSecOps, security consulting of governance. De richting hangt af van de combinatie van technische diepte en communicatievermogen. Een tester die sterk is in aanvalsketens kan zich ontwikkelen richting cloud red team. Iemand die bevindingen goed vertaalt naar structurele controls kan doorgroeien naar security architectuur of risk advisory.
De kern blijft hetzelfde: begrijpen hoe cloudsystemen echt werken, zorgvuldig omgaan met toestemming en data, en bevindingen vertalen naar herstel dat engineers kunnen uitvoeren. De meest effectieve volgende stap is daarom klein maar concreet: kies één cloud, bouw een veilige labomgeving, documenteer drie reproduceerbare aanvalsscenario’s en schrijf bij elk scenario een professioneel rapport met mitigaties. Dat portfolio zegt meer over geschiktheid voor cloud pentesting dan een losse lijst met tools ooit kan doen.
