# Pentest voorbereiding voor Google Workspace-omgevingen 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. [[TOC]] ## 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 | | :::warn title="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 title="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. :::howto title="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 title="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 [[workspace-phishing-simulatie|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 [[workspace-incident-response|verbeterproces]] en plan een hertest om te bevestigen dat de gaten gedicht zijn. :::tip title="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. ::: :::faq ### 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.