Microsoft Graph-machtigingen onder de knie krijgen: de valkuil van least privilege vermijden

By Mirko Peters · 2026-08-28

Automatically translated with AI from the original post. Read the English original

Cover: How Microsoft Graph Connects Microsoft 365 Data and Context

Wanneer je applicaties bouwt, automatiseringsscripts schrijft of externe tools integreert in je Microsoft 365-omgeving, wordt Microsoft Graph al snel het centrale zenuwstelsel. Het verbindt Teams, SharePoint, Exchange en Azure Active Directory met elkaar en geeft je één overzicht over de gegevens van je organisatie. Maar met grote kracht komt grote architecturale verantwoordelijkheid. Teams vallen er maar al te vaak in de gemakstrap: ze kennen brede machtigingen toe om een app snel aan de praat te krijgen. Deze kortere weg kan je hele tenant blootstellen aan catastrofale beveiligingsrisico's. Vandaag bespreken we hoe je veilig omgaat met Microsoft Graph-machtigingen en hoe je de balans vindt tussen de functionaliteit van je app en absoluut least privilege.

De verborgen kracht en het risico van Microsoft Graph-machtigingen

Microsoft Graph fungeert als het overkoepelende operationele platform voor je cloudomgeving. Het vervangt een versnipperd doolhof van legacy-API's door één gestroomlijnd REST-eindpunt. Dat maakt ontwikkelen een stuk eenvoudiger, maar het concentreert ook het risico. Elke applicatie-identiteit of service principal die je aanmaakt, heeft specifieke sleutels nodig om toegang te krijgen tot de gegevens waarmee hij werkt. Als je die sleutels verkeerd beheert, is je hele beveiligingsperimeter in gevaar.

Het kernprobleem is dat gemak op beheergebied vaak belangrijker wordt gevonden dan beveiligingsbest practices. Ontwikkelaars willen tijdens een sprint niet vastlopen op permissiefouten, dus vragen ze scopes met brede toegang aan, zoals Sites.ReadWrite.All of Directory.ReadWrite.All. Dat voorkomt wel directe blokkades, maar het geeft een applicatie in feite de sleutels van het koninkrijk. Wordt die ene app gecompromitteerd, dan krijgt een aanvaller de mogelijkheid om enorme delen van de bedrijfsgegevens te lezen of te wijzigen. Begrijpen hoe delicaat de balans is tussen innovatie mogelijk maken en strikte beveiligingsgrenzen handhaven, is de eerste stap naar echte cloudvolwassenheid.

Het verschil tussen gedelegeerde toegang en app-only toegang

Om je Microsoft 365-tenant te beveiligen, moet je eerst de twee belangrijkste autorisatiemodellen van Microsoft Graph beheersen: gedelegeerde toegang en app-only (applicatie)toegang.

Gedelegeerde toegang is bedoeld voor apps die namens een aangemelde gebruiker draaien. In dit model kan de applicatie alleen toegang krijgen tot wat de geauthenticeerde gebruiker zelf mag zien. Als een gebruiker een bepaalde SharePoint-site niet kan bekijken, dan kan een app met gedelegeerde machtigingen die site namens die gebruiker ook niet bekijken. Dit model werkt met permissiescopes en vereist dat zowel de gebruiker als de applicatie autorisatie hebben gekregen.

App-only toegang werkt daarentegen los van een gebruiker. De applicatie draait als achtergrond-daemon, geplande script of geautomatiseerde service. Omdat er geen aangemelde gebruiker is die de gegevens beperkt, vertrouwt app-only toegang op applicatiemachtigingen (app-rollen). Deze rollen hebben vaak enorme bevoegdheden over de hele tenant. Voor app-only scenario's zijn strikt beheer, regelmatige controles van het gebruik van service principals en een consequente toepassing van het least privilege-principe nodig.

De least privilege-valkuil: veelvoorkomende fouten met machtigingen

Het least privilege-principe bepaalt dat een applicatie alleen de minimale machtigingen mag hebben die nodig zijn voor de specifieke taak. Helaas schenden veel organisaties deze regel dagelijks door veelvoorkomende architectuurfouten.

Een van de gevaarlijkste valkuilen is het gebruik van brede wildcard- of tenantbrede machtigingen uit gemak. Als een applicatie alleen het profiel van de huidige gebruiker hoeft te lezen, maar je kent toch User.Read.All toe, dan creëer je onnodige blootstelling. Een andere veelgemaakte fout is resultaten filteren op applicatieniveau nadat er een complete dataset is opgehaald, in plaats van OData-queryfilters aan de serverkant te gebruiken. Als je app alle sitecollecties ophaalt om ze lokaal te filteren, dan heeft de data die de app nooit had mogen zien de netwerkgrens al gepasseerd en is die in de applicatielaag beland.

Daarnaast kan het op termijn tot autorisatiegaten leiden als je vertrouwt op wijzigbare identifiers zoals weergavenamen of e-mailadressen in plaats van onveranderlijke GUID's. Als je groepsuitbreiding negeert of ervan uitgaat dat machtigingen direct in je hele tenant worden gesynchroniseerd, kan dat ook stilletjes tot te veel blootstelling leiden. Opgeslagen machtigingen kunnen verouderen. Dat betekent dat een account of applicatie toegang kan behouden lang nadat de zakelijke reden ervoor is verdwenen.

Je tenant beveiligen zonder applicatiefunctionaliteit te breken

Beveiligingsmaatregelen die applicaties volledig onbruikbaar maken, worden vroeg of laat omzeild door gefrustreerde ontwikkelaars. Het verharden van je Microsoft Graph-machtigingen vraagt daarom om een strategische aanpak: je beschermt de data zonder de legitieme zakelijke processen te vertragen.

Begin met het controleren van je bestaande Azure AD-app-registraties en serviceprincipals. Breng per aangepaste applicatie in kaart welke machtigingen zijn toegekend en vergelijk die met het daadwerkelijke gebruik in de logs. Heeft een app al maanden applicatiemachtigingen die hij niet gebruikt, trek ze dan meteen in. Gebruik hulpmiddelen zoals de auditlogs van Microsoft Entra en de functies voor identiteitsbescherming om aanmeldgedrag te monitoren en afwijkend API-gebruik te signaleren.

Een andere cruciale praktijk is het toepassen van granulaire scopes. Vraag in plaats van brede toegang tot alle mailboxen of alle sites liever resourcespecifieke toestemmingsopties aan, waar die beschikbaar zijn. Moderne integraties met Microsoft Teams en SharePoint laten je bijvoorbeeld machtigingen verlenen voor specifieke teams of sites in plaats van voor de hele tenant. Zo beperk je het risico: als één app wordt gecompromitteerd, blijft de schade beperkt tot één samenwerkingsomgeving in plaats van de hele onderneming.

Praktische strategieën voor het beheren van Microsoft 365-beveiliging

Van een reactieve naar een proactieve beveiligingsaanpak heb je herhaalbare processen en geautomatiseerd governance nodig. Dit zijn praktische strategieën die je vandaag nog kunt inzetten om Microsoft Graph-machtigingen écht onder de knie te krijgen:

Hanteer een strikt beoordelingsproces voor alle nieuwe Azure AD-app-registraties, voordat ze in productieomgevingen terechtkomen.
Implementeer geautomatiseerd beheer van de identiteitslevenscyclus, zodat de toegang van apps en serviceprincipals automatisch wordt ingetrokken zodra projecten eindigen of eigenaren de organisatie verlaten.
Gebruik Microsoft Graph API-query's om de machtigingen in je tenant periodiek en geautomatiseerd te controleren.
Leer je ontwikkelteams over de beveiligingsrisico's van te ruime scopes en over alternatieven, zoals resourcespecifieke toestemming.
Voeg beveiligingsscans en validatie van machtigingen toe aan je CI/CD-pipelines, zodat te ruime app-rollen worden opgespoord vóór de uitrol.

Door machtigingen als code te behandelen en strikte validatienormen toe te passen, zorg je ervoor dat je cloudapplicaties veilig, compliant en performant blijven.

Het beheersen van Microsoft Graph-machtigingen is een fundamentele voorwaarde voor elke veilige en schaalbare Microsoft 365-architectuur. Door de kernlogica van gedelegeerde versus app-only toegang te begrijpen, de veelvoorkomende valkuilen van least privilege te vermijden en proactief governance toe te passen, bescherm je de gevoelige data van je organisatie en benut je tegelijk volledig de automatiseringsmogelijkheden van de cloud. Wil je zien hoe deze concepten in de praktijk samenkomen? Luister dan zeker ook naar onze bijbehorende aflevering: How Microsoft Graph Connects Microsoft 365 Data and Context.