Een cloud pentest scope opstellen

Een pentest op een on-premise omgeving is al lastig te scoppen. In de cloud komt er een laag bij: de cloud provider heeft zijn eigen verantwoordelijkheden, en die overschrijden is zowel contractueel als juridisch een probleem. Dit artikel helpt je een scope op te stellen die realistisch, uitvoerbaar en zinvol is.

Het shared responsibility model bepaalt je speelruimte

AWS, Azure en GCP werken allemaal met een gedeeld verantwoordelijkheidsmodel. De provider beheert de fysieke infrastructuur, de hypervisor en de onderliggende netwerkhardware. Jij bent verantwoordelijk voor alles wat daarboven zit: je workloads, je identiteitsbeheer, je configuraties.

Wat dit betekent voor je scope: je test nooit de infrastructuur van de provider zelf. Je test wat jij hebt gebouwd en geconfigureerd op die infrastructuur.

Elke provider heeft hier beleid over:

• AWS heeft in 2019 de eis voor voorafgaande melding laten vervallen voor de meeste diensten. Je mag testen zonder toestemming te vragen, zolang je je aan hun Customer Support Policy for Penetration Testing houdt. Denial-of-service aanvallen en aanvallen op andere AWS-klanten zijn expliciet verboden.
• Azure werkt met de Penetration Testing Rules of Engagement. Je meldt van tevoren via een formulier, maar toestemming is grotendeels automatisch voor standaard testactiviteiten.
• GCP heeft een Cloud Platform Acceptable Use Policy die vergelijkbare grenzen stelt. Grootschalige of destructieve tests vragen om expliciete goedkeuring.

Houd deze documenten bij de hand voordat je ook maar een tool opstart.

Wat hoort wel in de scope

Een goede cloud pentest richt zich op de aanvalspaden die een echte aanvaller zou bewandelen. Dat zijn:

Identity-perimeter. IAM-rollen, service accounts en federated identities zijn in de cloud vaak de zwakste schakel. Kijk naar overpermissioned roles, privilege escalation via AssumeRole (AWS) of managed identities (Azure), en tokens die onbedoeld zijn blootgesteld.

Exposed services. Publiek bereikbare storage buckets, open security groups, onbeveiligde API gateways en verkeerd geconfigureerde load balancers. Automatische tooling vindt dit snel; de pentest voegt waarde door te laten zien wat een aanvaller er daadwerkelijk mee kan.

IaC-review. Terraform, Bicep of CloudFormation templates bevatten vaak configuraties die je in productie nooit zou willen. Een IaC-review als onderdeel van de pentest geeft inzicht in structurele problemen, niet alleen in eenmalige misconfiguraties.

Secret scanning. Hardcoded credentials in code, environment variables, Kubernetes secrets en parameter stores worden regelmatig over het hoofd gezien. Tools als Trufflehog of git-secrets helpen, maar een pentest kijkt ook naar toegangspaden naar die secrets.

Post-exploitation paths. Wat kan een aanvaller doen nadat hij een initieel voetje in de deur heeft? Lateral movement tussen accounts, data exfiltration via storage services, persistentie via backdoor-rollen. Dit deel onderscheidt een goede pentest van een vulnerability scan.

Wat niet bij de pentest hoort

Een architectuuraudit is geen pentest. Vragen als “hadden we dit anders moeten ontwerpen?” of “is dit de juiste service voor deze workload?” horen thuis in een aparte sessie met een architect, niet in het pentest-rapport.

Hetzelfde geldt voor compliance-checks. Of je aan NIS2, ISO 27001 of SOC2 voldoet, bepaalt een auditor, geen pentester. De overlap bestaat, maar de methodieken zijn anders.

Zet dit expliciet in je scope-document om later discussie te voorkomen.

CSPM-tools als pre-pentest hygiëne

Cloud Security Posture Management tools (Prisma Cloud, Wiz, Microsoft Defender for Cloud, AWS Security Hub) geven een breed overzicht van misconfiguraties. Gebruik ze voordat de pentest begint.

Waarom? Een pentester die een uur besteedt aan het vinden van publieke S3 buckets die een CSPM-tool in vijf minuten rapporteert, is duur. Los de low-hanging fruit op met CSPM, zodat de pentester zich kan richten op complexere aanvalspaden.

Dat gezegd: een CSPM-tool vervangt de pentest niet. Het ziet geen logische aanvalspaden, geen gecombineerde kwetsbaarheden en geen business context.

Een scope-document dat werkt

Een bruikbaar scope-document bevat minimaal:

• De te testen accounts, subscriptions of projecten (met ID’s)
• De testwindow (begin- en eindtijd, tijdzone)
• Contactpersonen aan beide kanten
• Wat out of scope is, inclusief productiedatabases als je alleen staging test
• De regels van de provider (AWS/Azure/GCP) als bijlage
• De afspraken over dataverwerking tijdens de test

Wil je meer weten over cloud security trainingen, dan vind je ze via cloud pentest trainingen.

Scope vs. realiteit

Een te brede scope leidt tot oppervlakkige bevindingen. Een te smalle scope mist de relevante aanvalspaden. De juiste balans: begin bij de kroonjuwelen van je omgeving (productie-identiteiten, kritische datastores, externe interfaces) en werk van buiten naar binnen.

Bespreek de scope altijd met de pentester voordat het contract getekend wordt. Een goede pentester stelt vragen terug en past de scope aan op basis van wat hij ziet in de verkenningsfase.