Cloudpenetratietesten is het gericht onderzoeken van risico’s in cloudaccounts, services en toegangsmodellen. Wie het vooral ziet als klassieke netwerkscans in een cloudaccount, mist vaak de echte risico’s, omdat cloudomgevingen draaien op identiteiten, toegangsrelaties, automatisering, logging en snel veranderende services.
Een cloudpenetratietester onderzoekt cloudomgevingen met toestemming om kwetsbaarheden te vinden voordat aanvallers dat doen. In België en de bredere EU betekent dat meer dan technische vaardigheid: de tester moet ook begrijpen hoe GDPR/AVG, NIS2, contractuele scope, responsible disclosure en cloudproviderbeleid het werk afbakenen.
De rol past bij securityanalisten, systeem- en netwerkbeheerders, cloud engineers en ethische hackers die offensieve technieken willen toepassen zonder de juridische en operationele grenzen te overschrijden. Hiring managers zoeken daarbij zelden alleen iemand die tools kan draaien. Ze zoeken een professional die een cloudomgeving kan lezen, aannames kan toetsen, bewijs veilig kan verzamelen en bevindingen kan vertalen naar risico’s die engineering-, compliance- en managementteams begrijpen.
Wat een cloudpenetratietester anders maakt dan een klassieke pentester
Bij een traditionele penetratietest draait veel aandacht rond netwerken, hosts, webapplicaties en perimeterbeveiliging. Die kennis blijft nuttig, maar in cloudomgevingen verschuift het zwaartepunt naar configuratie, identiteit en automatisering. Een open poort kan nog steeds relevant zijn, maar een te brede IAM-rol, een publiek toegankelijke storage bucket, een kwetsbare CI/CD-pipeline of een serverless functie met te veel rechten veroorzaakt vaak meer schade.
Het shared-responsibility model is daarbij bepalend. AWS, Microsoft Azure en Google Cloud beveiligen de onderliggende cloudinfrastructuur, terwijl de klant verantwoordelijk blijft voor de manier waarop accounts, data, workloads, toegangsrechten, applicaties en configuraties worden ingericht. Voor een pentester betekent dit dat de scope zorgvuldig moet aangeven welk deel van de omgeving getest mag worden, welke technieken zijn toegestaan en waar providergrenzen of klantverantwoordelijkheden liggen.
Ook de testomgeving verandert. Cloudresources kunnen tijdelijk zijn, automatisch worden uitgerold en binnen minuten verdwijnen. In de praktijk is het daarom verstandig om te werken met tijdelijke testaccounts, landing zones of afgescheiden subscriptions en projecten. Tags, reproduceerbare scripts en duidelijke logging helpen om bewijs te verzamelen zonder productie te verstoren of kosten onverwacht te laten oplopen.
Juridische en ethische grenzen in België en de EU
Cloudpenetratietesten zonder expliciete toestemming is juridisch riskant, ook wanneer de intentie goed is. Een professionele opdracht begint met schriftelijke toestemming, een duidelijke scope en afspraken over contactpersonen, tijdsvensters, toegestane technieken, noodprocedures en rapportage. Die afspraken beschermen zowel de opdrachtgever als de tester.
In een Belgische of EU-context spelen GDPR/AVG en NIS2 een belangrijke rol. GDPR/AVG is relevant wanneer persoonsgegevens kunnen worden geraakt tijdens tests, bijvoorbeeld in storage, logging, databases of SaaS-koppelingen. NIS2 verhoogt ondertussen de verwachtingen rond risicobeheer, incidentrespons en verantwoordelijkheid bij essentiële en belangrijke entiteiten. Wie zich verdiept in de organisatorische impact kan verder lezen over NIS2 en wat het betekent voor organisaties, maar voor de pentester blijft de praktische les eenvoudig: scope, bewijsvoering en rapportage moeten aantoonbaar beheerst zijn.
Responsible disclosure hoort eveneens bij het vak. Wanneer een kwetsbaarheid buiten een formele opdracht wordt gevonden, bepaalt het beleid van de betrokken organisatie hoe en waar die gemeld mag worden. In België is het belangrijk om geen verdere toegang te nemen dan nodig is om de kwetsbaarheid verantwoord aan te tonen. Een goede tester vermijdt destructieve acties, datadownloads en privilege escalation buiten afspraak, tenzij dit vooraf expliciet en schriftelijk is goedgekeurd.
Welke vaardigheden zijn nodig
Een cloudpenetratietester heeft een brede technische basis nodig, maar die basis moet cloudspecifiek worden toegepast. Kennis van netwerken, Linux, Windows, webapplicaties, scripting en kwetsbaarheidsanalyse blijft belangrijk. Daarbovenop komt inzicht in cloudarchitectuur, identity and access management, encryptie, logging, containerplatformen, serverless functies, API’s en CI/CD-processen.
IAM verdient bijzondere aandacht. In Azure gaat het bijvoorbeeld om Entra ID, rollen, managed identities, conditional access en privilege escalation via verkeerde toewijzingen. In AWS spelen IAM policies, roles, trust relationships en AWS STS een vergelijkbare rol. In Google Cloud draait veel rond service accounts, IAM bindings en project- of organisatierechten. Kandidaten die dit begrijpen, onderscheiden zich sneller dan kandidaten die vooral portscans en standaardrapporten tonen.
Logging en telemetry zijn even belangrijk. CloudTrail, Microsoft Defender for Cloud, Azure Activity Logs, Google Cloud Audit Logs en SIEM-detecties laten zien wat een aanvalspad zichtbaar maakt voor verdedigers. Een cloudpenetratietester die ook kan uitleggen welke signalen een aanval achterlaat, levert meer waarde dan iemand die alleen kwetsbaarheden opsomt. In moderne opdrachten wordt steeds vaker verwacht dat offensive testing en detection engineering elkaar versterken.
Een praktisch leerpad naar de rol
De meeste kandidaten groeien niet rechtstreeks in cloudpenetratietesten. Een realistisch pad begint met algemene securitykennis en een stevige cloudbasis, gevolgd door hands-on labs en gerichte specialisatie. Een systeembeheerder kan bijvoorbeeld starten met cloudfundamenten en IAM. Een SOC-analist kan sneller aansluiten via logging, aanvalspaden en detecties. Een webapplicatiepentester moet vooral leren hoe applicaties in cloudomgevingen worden uitgerold, gekoppeld en beheerd.
Een nuttig portfolio laat zien dat de kandidaat veilig en reproduceerbaar kan werken. Denk aan een multi-cloud lab met Terraform, write-ups over IAM-misconfiguraties, storage exposure, serverless permissies of Kubernetes-risico’s, en kleine bijdragen zoals een detectieregel in Sigma of KQL. Bug bounty-ervaring kan waardevol zijn, maar alleen wanneer duidelijk is dat de tests binnen toestemming en programma-scope vielen. Hiring managers letten vooral op de kwaliteit van de analyse: wat was de hypothese, welke impact was realistisch, welke beperkingen golden en hoe werd de oplossing uitgelegd?
Veelgemaakte fouten bij het leren zijn tool-first werken, geen tijd besteden aan identity flows, serverless en Kubernetes overslaan, en geen aandacht hebben voor logging. Ook ontbreekt vaak een eenvoudig sjabloon voor toestemming en scope. Een kandidaat die vooraf kan uitleggen hoe een test veilig wordt afgebakend, maakt een professionelere indruk dan iemand die alleen exploit-output kan tonen.
Certificeringen die kunnen helpen
Certificeringen vervangen geen praktijkervaring, maar ze helpen om kennis te structureren en geloofwaardigheid op te bouwen. Voor een algemene securitybasis zijn CompTIA Security+ en CEH herkenbare startpunten. Security+ bevestigt brede basiskennis, terwijl CEH de taal en methoden van ethisch hacken introduceert.
Wie richting cloudsecurity groeit, komt vaak uit bij cloud- en governancegerichte certificeringen. CCSP richt zich op cloudsecurityprincipes, architectuur, risicobeheer en compliance. CISSP is breder en past beter bij professionals die ook securitymanagement, architectuur of risicokaders willen begrijpen.
Daarnaast helpt een providergerichte volgorde om keuzes te maken. Wie vooral solliciteert bij Azure- en Microsoft 365-omgevingen kan beginnen met AZ-900 en daarna AZ-500 overwegen, met SC-100 als latere architectuurstap. In AWS-first omgevingen ligt een pad via AWS Certified Cloud Practitioner naar AWS Certified Security – Specialty voor de hand. In Google Cloud-omgevingen kan Cloud Digital Leader of Associate Cloud Engineer voorafgaan aan Professional Cloud Security Engineer. Een bredere vergelijking van providergerichte opties staat in cloud security certificeringen voor AWS, Azure en Google Cloud.
Hoe cloudproviderbeleid de test stuurt
AWS, Azure en Google Cloud publiceren elk richtlijnen voor security testing en acceptable use. Die documenten bepalen niet de volledige pentest-scope, maar ze geven wel aan welke activiteiten toegestaan zijn, welke services gevoelig liggen en wanneer extra voorzichtigheid nodig is. Voor publicatie moet een tester altijd de actuele officiële richtlijnen controleren, omdat providerbeleid kan veranderen.
In de praktijk betekent dit dat een pentestplan niet mag stoppen bij de klanttoestemming. De tester moet ook nagaan of de beoogde acties passen binnen het platformbeleid. Denk aan voorzichtigheid bij denial-of-service tests, social engineering, fysieke aanvallen, grootschalige scanning, malwareachtige payloads of activiteiten die gedeelde infrastructuur kunnen beïnvloeden. Zelfs wanneer de klant akkoord gaat, kan een cloudprovider bepaalde acties beperken.
Een goede aanpak gebruikt veilige verificatie. In plaats van productiegegevens te downloaden om exposure te bewijzen, kan de tester werken met testobjecten, canary-bestanden, beperkte proof-of-access en loggingcontrole. Bij IAM-bevindingen is het vaak voldoende om aan te tonen dat een rol een bepaald pad mogelijk maakt, zonder daadwerkelijk destructieve acties uit te voeren. Dat sluit beter aan bij professionele rapportage en verkleint het risico op verstoring.
Methodologie en rapportage in de praktijk
Cloudpenetratietesten volgt doorgaans bekende methodologische kaders zoals PTES en OWASP, maar de invulling verschilt per omgeving. De verkenningsfase omvat niet alleen domeinen en IP-adressen, maar ook cloudaccounts, subscriptions, projecten, tenants, identity providers, CI/CD-systemen en gekoppelde SaaS-diensten. Daarna volgt een analyse van rechten, configuraties, datastromen en mogelijke aanvalspaden.
Bij serverless en containers is de vraag vaak hoe code, secrets en runtime-rechten samenkomen. Een kwetsbare functie met een overprivileged role kan bijvoorbeeld toegang geven tot opslag of queues. In Kubernetes draait het niet alleen om clusterconfiguratie, maar ook om workload identities, admission controls, image provenance, secretsbeheer en netwerkbeleid. Bij CI/CD ligt de impact vaak in secrets, deploymentrechten en de mogelijkheid om code naar productie te brengen.
De rapportage moet technisch genoeg zijn voor engineers en duidelijk genoeg voor risicobeslissers. Een sterke bevinding beschrijft de context, het aanvalspad, het bewijs, de zakelijke impact, de beperkingen van de test en een haalbare remediatie. ISO/IEC 27001, de Cloud Security Alliance Cloud Controls Matrix en OWASP-richtlijnen kunnen helpen om bevindingen aan controles en verbetermaatregelen te koppelen zonder het rapport te overladen.
Waar de kansen liggen
In België en de EU is cloudpenetratietesten relevant in sectoren waar cloudadoptie samenvalt met hoge eisen rond privacy, continuïteit en governance. Financiële instellingen, zorgorganisaties, publieke diensten, technologiebedrijven, telecom, energie, logistiek en industriële omgevingen hebben allemaal nood aan cloudsecuritykennis. De precieze opdracht verschilt per sector, maar de rode draad is dezelfde: aantonen waar misconfiguraties en aanvalspaden tot echte bedrijfsrisico’s leiden.
Freelancers en consultants kunnen kansen vinden bij organisaties die periodieke assessments, migratiecontroles of pre-release tests nodig hebben. Interne securityteams hebben dan weer baat bij professionals die cloudengineering begrijpen en niet alleen rapporten afleveren. De sterkste profielen kunnen schakelen tussen offensieve analyse, praktische remediatie en overleg met platformteams.
Een carrière opbouwen die standhoudt
De meest duurzame route naar cloudpenetratietesten combineert drie elementen: aantoonbare praktijk, juridische discipline en cloudspecifieke diepgang. Wie leert werken met tijdelijke testomgevingen, duidelijke scope-afspraken, identity-first aanvalspaden en veilige bewijsvoering, bouwt vaardigheden op die direct bruikbaar zijn in echte opdrachten.
Readynez kan daarbij één leeroptie zijn voor professionals die gestructureerde securitytraining willen combineren met certificeringsvoorbereiding via Unlimited Security Training. De belangrijkste stap blijft echter hetzelfde: bouw een portfolio dat laat zien hoe tests worden voorbereid, uitgevoerd, gelogd en verantwoord gerapporteerd binnen de grenzen van toestemming en cloudproviderbeleid.
