Naar inhoud
lightbulb Welkom op de nieuwe kennisbank | We hebben de docs volledig vernieuwd met meer dan 160 features. Bekijk wat nieuw isarrow_forward

Pentest voorbereiding voor Google Workspace-omgevingen

Een pentest test je beveiliging door een aanval te simuleren. Voor Google Workspace richt je je op je eigen configuratie, accounts, koppelingen en de menselijke laag, niet op de infrastructuur van Google. Deze gids legt uit wat je wel en niet mag testen, hoe je de scope bepaalt en hoe je je voorbereidt.

Pentest voorbereiding voor Google Workspace-omgevingen begint met een belangrijk onderscheid: je test niet de infrastructuur van Google. Die wordt door Google zelf voortdurend getest en valt buiten jouw scope. Een pentest van je Workspace-omgeving richt zich op wat jij beheert: je configuratie, je accounts, je koppelingen en je menselijke beveiligingslaag. Dat is precies waar de meeste echte zwakheden zitten.

Wat je wel en niet pentest

Dit onderscheid voorkomt verspilde moeite en problemen. De volgende tabel zet het tegenover elkaar.

Wel in scope Niet in scope
Je configuratie en beleid De servers en datacenters van Google
Zwakke of ontbrekende 2FA De onderliggende Workspace-dienst zelf
Te ruime delingsinstellingen Gedeelde infrastructuur van andere klanten
Overgeprivilegieerde accounts Denial-of-service tegen het platform
Riskante OAuth-koppelingen Pogingen tot data-toegang buiten je eigen organisatie
De menselijke laag via phishing
warning

Blijf binnen je eigen omgeving

Voer geen aanvallen uit op de infrastructuur van Google of op gedeelde diensten die andere klanten raken. Dat is niet alleen zinloos omdat Google het zelf afdekt, maar ook in strijd met het Acceptable Use Policy en de gebruiksvoorwaarden. Denial-of-service-tests zijn expliciet verboden. Houd je test strikt bij je eigen configuratie, accounts en gedrag, binnen je eigen project en organisatie.

De regels van Google

Voor je eigen Workspace- en Cloud-resources hoef je Google vooraf geen toestemming te vragen en is er geen formele meldprocedure, anders dan bij sommige andere clouds. Dat betekent niet dat alles mag. Je test alleen binnen je eigen project en organisatie, je raakt geen andere klanten en je houdt je aan het Acceptable Use Policy en de Terms of Service. Bij twijfel raadpleeg je het actuele beleid van Google over beveiligingstesten voordat je begint.

info

Workspace en Cloud hangen samen

Houd er rekening mee dat Google Workspace en Google Cloud aan elkaar raken. Een service-account met domain-wide delegation kan elke Workspace-gebruiker impersoneren, en een Workspace-superbeheerder kan terugpivoten naar Cloud. Neem beide oppervlakken mee in je scope-bepaling als ze beide in gebruik zijn.

Scope en toestemming vooraf

Een pentest zonder duidelijke afspraken loopt mis. Voordat er iets gebeurt, leg je vast wat getest wordt, wanneer, door wie en wat de grenzen zijn.

Pentest voorbereiden

  1. Bepaal de scope: welke onderdelen van je Workspace-omgeving wel en niet.
  2. Leg schriftelijke toestemming vast van de verantwoordelijke binnen je organisatie.
  3. Stem af of je eigen team of een externe partij de test uitvoert.
  4. Bepaal of het een black-box-, grey-box- of white-box-test wordt.
  5. Spreek een tijdvenster af en een noodstopprocedure.
  6. Zorg dat detectie aan staat, zodat je ook test of je de aanval opmerkt.
info

Detectie meetesten

Een pentest test niet alleen of er een gat is, maar ook of je het merkt. Laat je detectie en monitoring aan staan tijdens de test. Als de pentester ongezien een account overneemt of data exporteert, weet je dat je monitoring tekortschiet. Dat inzicht is vaak waardevoller dan de gevonden kwetsbaarheid zelf.

Veelvoorkomende bevindingen

Pentests van Workspace-omgevingen leveren vaak vergelijkbare zwakheden op. Door ze vooraf te kennen, kun je ze deels al dichten.

  • Zwakke 2FA: accounts zonder 2FA of met de zwakkere sms-variant in plaats van passkeys of een authenticator.
  • Ruim delen: bestanden die openbaar of te breed gedeeld staan, soms via oude links.
  • Te veel admins: overbodige superbeheerders met meer rechten dan nodig.
  • Riskante OAuth: externe apps met brede toegang tot mail, Drive of contacten.
  • Phishing-vatbaarheid: de menselijke laag die op een nagebootste login klikt.

De menselijke laag

Een groot deel van de waarde van een pentest zit in de menselijke laag, vaak via een gecontroleerde phishing-actie. Zie phishing-simulaties voor hoe je dit ethisch aanpakt. De pentest combineert dit met technische verkenning van zwakke configuraties.

Na de test

De pentest levert een rapport met bevindingen en risico-inschattingen. De echte waarde zit in wat je ermee doet. Prioriteer de bevindingen, koppel ze aan je verbeterproces en plan een hertest om te bevestigen dat de gaten gedicht zijn.

lightbulb

Een rapport is het begin, niet het einde

Een pentest zonder opvolging is weggegooid geld. Maak van elke serieuze bevinding een concrete actie met eigenaar en deadline. Plan een hertest van de gedichte gaten, zodat je zeker weet dat het probleem echt verholpen is en niet alleen op papier.

Mag ik Google Workspace zomaar pentesten?

Je eigen configuratie, accounts en gedrag wel, mits met interne toestemming. De onderliggende infrastructuur van Google mag je niet aanvallen. Voor je eigen resources vraagt Google vooraf geen toestemming, maar je blijft wel binnen je eigen project en organisatie en houdt je aan het Acceptable Use Policy.

Wat is het verschil tussen black-box en white-box?

Bij black-box weet de tester vooraf niets, zoals een echte aanvaller. Bij white-box krijgt de tester volledige informatie en toegang. Grey-box zit ertussenin. De keuze hangt af van je doel.

Moet ik mijn team op de hoogte stellen?

Het beveiligingsteam dat detecteert wil je soms juist niet inlichten, om te testen of ze de aanval opmerken. De verantwoordelijke leiding moet altijd toestemming geven en op de hoogte zijn.

Moet ik Google vooraf waarschuwen?

Nee. Anders dan bij sommige andere clouds is er voor je eigen Workspace- en Cloud-resources geen meld- of goedkeuringsplicht. Je moet je wel aan de gebruiksvoorwaarden houden en mag geen denial-of-service of tests uitvoeren die andere klanten raken.

Hoe vaak moet ik pentesten?

Jaarlijks is gangbaar, plus na grote wijzigingen in je omgeving. Compliance-kaders zoals ISO 27001 verwachten periodieke beveiligingstesten.

Wat doe ik met de bevindingen?

Prioriteer ze op risico, wijs een eigenaar en deadline toe en plan een hertest. Het rapport is pas waardevol als de gaten ook echt gedicht en geverifieerd zijn.

Met een heldere scope, vastgelegde toestemming, actieve detectie en serieuze opvolging maak je van een pentest een waardevolle test van je echte beveiliging. Onthoud dat je je eigen configuratie en gedrag test, niet het platform van Google. Daar zitten de zwakheden die jij kunt en moet oplossen.