Wat is domain-wide delegation
Domain-wide delegation (DWD) is een autorisatiemechanisme waarmee een service account zich kan voordoen als elke Workspace-gebruiker. Technisch gezien vraagt het service account OAuth-tokens aan met een sub-claim voor een willekeurige gebruiker in de organisatie. Er is geen toestemming van die gebruiker nodig: een beheerder autoriseert de toegang organisatiebreed.
Dit is bedoeld voor administratieve tools die gegevens van meerdere gebruikers verwerken, bijvoorbeeld:
- Een HR-tool die agenda's van alle medewerkers leest.
- Een compliance-tool die Gmail-berichten scant.
- Een script dat Drive-bestanden van alle gebruikers inventariseert.
DWD is een org-brede sleutel
DWD is een van de krachtigste en gevaarlijkste instellingen in Workspace. Een gecompromitteerd service account met DWD geeft toegang tot alle accounts in je organisatie, binnen de toegekende scopes. Gebruik het alleen als er geen alternatief is, zoals directe service-accounttoegang of OAuth-toestemming per gebruiker.
DWD inschakelen op het service account
Eerst schakel je delegatie in op het service account zelf, in de Google Cloud Console.
Service account voorbereiden in Google Cloud
- Ga naar console.cloud.google.com en kies (of maak) een apart, herkenbaar project voor dit account.
- Open IAM en beheer > Serviceaccounts.
- Maak een nieuw service account of selecteer een bestaand account.
- Open het tabblad Details en klik op Geavanceerde instellingen tonen.
- Noteer het Client ID (de OAuth 2-client-ID, een numerieke ID van circa 21 cijfers). Dit ID heb je straks nodig in de Admin Console.
Geen aparte aan-knop meer nodig
In de huidige console hoef je op het service account geen losse optie "Enable G Suite Domain-wide Delegation" meer aan te zetten. Een service account kan worden gedelegeerd zodra een beheerder het Client ID autoriseert in de Admin Console. Het is dus de autorisatie aan de Admin-kant die de toegang verleent, niet een vinkje aan de Cloud-kant.
DWD autoriseren in de Admin Console
De autorisatie doe je als super-admin in de Admin Console. De navigatie is verplaatst onder Toegang en gegevensbeheer.
Client ID en scopes autoriseren
- Ga naar admin.google.com en log in als super-admin.
- Navigeer naar Beveiliging > Toegang en gegevensbeheer > API-besturingselementen > Domeinbrede delegatie beheren.
- Klik op Nieuw toevoegen.
- Voer het Client ID van het service account in.
- Voeg de OAuth-scopes toe als kommagescheiden lijst (zie voorbeeld hieronder).
- Klik op Autoriseren.
Super-admin vereist
Alleen een super-admin kan in de lijst voor domeinbrede delegatie schrijven. Standaard- of editor-beheerdersrollen mogen dit niet. Geef dit recht dus niet onnodig breed weg.
Voorbeeldlijst met scopes voor een agenda-integratie (lezen):
https://www.googleapis.com/auth/calendar.readonly,
https://www.googleapis.com/auth/calendar.events.readonly
Code-voorbeeld voor delegatie
Onderstaand Python-fragment laadt een service-accountsleutel en wisselt die in voor credentials die namens een specifieke gebruiker handelen:
from google.oauth2 import service_account
SCOPES = ['https://www.googleapis.com/auth/calendar.readonly']
SERVICE_ACCOUNT_FILE = 'service-account.json'
credentials = service_account.Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE, scopes=SCOPES
)
delegated_credentials = credentials.with_subject('gebruiker@bedrijf.nl')
Vervang gebruiker@bedrijf.nl door het adres van de gebruiker namens wie je handelt. De scopes in SCOPES moeten een subset zijn van de scopes die je in de Admin Console hebt geautoriseerd, anders krijg je een unauthorized_client-fout.
Sleutels vermijden waar het kan
Statische service-accountsleutels zijn een geliefd doelwit. Google adviseert om sleutelaanmaak te beperken via een organisatiebeleid en waar mogelijk de signJwt-API of Workload Identity Federation te gebruiken in plaats van een JSON-sleutelbestand. Bewaar een sleutel die je toch gebruikt nooit in een repository of in platte tekst.
Minimale scopes als uitgangspunt
Voeg nooit meer scopes toe dan de applicatie strikt nodig heeft. Zoek in de API-documentatie de exacte scope op die de gewenste bewerking vereist, en geef voorrang aan readonly-varianten als je niet hoeft te schrijven. Voor de zekerheid alle scopes opsommen is een veiligheidsrisico: elke extra scope vergroot de schade bij een lek.
DWD-toegangen regelmatig reviewen
Controleer minstens ieder kwartaal welke service accounts DWD-toegang hebben en welke scopes daarbij horen. Verwijder accounts die niet meer in gebruik zijn en scopes die niet meer nodig zijn.
Via Cloud Audit Logs zie je welke scopes daadwerkelijk zijn aangesproken. Scopes die nooit terugkomen in de logs zijn kandidaten om te verwijderen. Met de Cloud Asset Inventory-API kun je bovendien achterhalen wie toegang heeft tot het service account zelf, bijvoorbeeld via de rol iam.serviceAccountTokenCreator.
DWD beveiligen
- Beperk het aantal service accounts met DWD tot het strikt noodzakelijke.
- Gebruik een apart service account per applicatie, nooit een gedeeld account.
- Plaats DWD-service accounts in een eigen, geïsoleerd Cloud-project.
- Roteer sleutels of vermijd sleutels door Workload Identity Federation te gebruiken.
- Monitor op ongebruikelijke patronen in Cloud Audit Logs, zoals impersonatie van veel verschillende gebruikers in korte tijd.
Kan ik DWD beperken tot bepaalde organisatie-eenheden?
DWD wordt georganiseerd rond het Client ID en de OAuth-scopes, niet rond organisatie-eenheden. De toegang geldt in de praktijk organisatiebreed. Wil je beperken namens welke gebruikers de app handelt, regel dat dan in de applicatiecode of door de scopes zo smal mogelijk te houden. Vertrouw niet op een OU-grens als beveiligingslaag voor DWD.
Wat is het verschil tussen DWD en OAuth-toestemming door een gebruiker?
Bij gewone OAuth geeft de gebruiker zelf toestemming en kan die toestemming weer intrekken. Bij DWD is geen gebruikersinteractie nodig: de beheerder autoriseert de toegang organisatiebreed. Daarom is DWD krachtiger maar ook riskanter.
Welke beheerdersrol heb ik nodig om DWD in te stellen?
Je hebt de super-admin-rol nodig. Standaard- en editor-beheerders kunnen de lijst voor domeinbrede delegatie niet bewerken.
Kan ik zien welke DWD-acties zijn uitgevoerd?
Ja, via Google Cloud Audit Logs. Zoek op het e-mailadres van het service account en op het type actie om te zien welke API-aanroepen namens welke gebruikers zijn gedaan.
Hoe verwijder ik DWD-toegang weer?
Ga naar Admin Console, dan Beveiliging, dan Toegang en gegevensbeheer, dan API-besturingselementen, dan Domeinbrede delegatie beheren, en verwijder de regel van het betreffende Client ID. De toegang stopt zodra de regel weg is.
Wat doe ik bij een vermoeden van misbruik?
Trek de autorisatie meteen in door het Client ID uit de lijst te verwijderen, roteer of verwijder de bijbehorende service-accountsleutels, en onderzoek de Cloud Audit Logs op verdachte impersonatie. Behandel een gelekte DWD-sleutel als een organisatiebrede inbreuk.