Cloud-pentest voor AWS, Azure en GCP.

Meestal niet, maar elke provider heeft regels. AWS staat tests van een lijst diensten toe zonder voorafgaande goedkeuring, Microsoft vraagt sinds 2017 geen goedkeuring meer voor Azure maar publiceert wel rules of engagement, en Google hoeft niet vooraf te horen dat je test. AWS en Microsoft verbieden allebei denial-of-servicetests, en wij doen ze ook niet.

Een auditrol met alleen leesrechten in elk account, elke subscription of elk project in scope, en testidentiteiten voor de startpunten die we afspreken, zoals een developergebruiker of een workloadrol. Je inloggegevens als beheerder van productie hebben we nooit nodig, en je trekt onze toegang zelf in als de opdracht klaar is.

Nee. Een configuratiereview of CSPM-tool somt instellingen op die een benchmark niet halen. Een pentest begint bij posities die een aanvaller kan innemen en laat zien welke van die instellingen samen een pad vormen naar je data of een beheerdersrol. De review is goede input; het pad is de bevinding.

Ja, als onderdeel van het account. We testen clusterrollen, serviceaccounttokens, workloads met verhoogde rechten en de routes van een container naar de node of het cloudaccount, en bij serverless waardoor elke functie aangeroepen kan worden en waar haar rol bij kan. Beheerde control planes testen we alleen voor zover de provider dat toestaat.

Omdat cloudomgevingen meer van elkaar verschillen dan applicaties. Twee bedrijven met hetzelfde product kunnen één account draaien of veertig, een paar rollen of duizenden gefedereerde identiteiten. Het scopinggesprek telt de accounts, identiteiten en workloads die ertoe doen, en de offerte volgt daaruit in plaats van uit een bandbreedte.