Waarom Entra ID entitlement management faalt (en hoe je het oplost)

By Mirko Peters · 2026-10-28

Ontdek waarom entitlement management in Entra ID faalt door een wildgroei aan pakketten, en hoe een op rollen gebaseerd pakketontwerp en catalogusgrenzen dat oplossen.

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

Entitlement management van Microsoft Entra ID belooft een gestroomlijnde manier om toegang te verlenen via op rollen gebaseerde pakketten, maar organisaties raken vaak verstrikt in honderden overbodige of onbeheerde pakketten. Door de focus te verleggen van silo's per applicatie naar een op rollen gebaseerd toegangsontwerp, catalogusgrenzen en strikte levenscyclusbeheersing, kunnen beheerders een wildgroei aan pakketten voorkomen en duurzame cloudbeveiligingsmodellen bouwen.

Belangrijkste punten

• Entitlement management faalt vaak wanneer pakketten per applicatie worden gemaakt in plaats van per functie of projectrol.
• Ongecontroleerd aanmaken van pakketten leidt tot "sedimentlagen" van overbodige bundels die eindgebruikers niet goed kunnen navigeren.
• Catalogusgrenzen zijn essentiële zakelijke beveiligingsmuren die voorkomen dat machtigingen tussen afdelingen geleidelijk worden uitgebreid.
• Resources samen bundelen maakt het intrekken van toegang eenvoudig, omdat alles gezamenlijk vervalt.
• Regelmatig de pakketlijst zelf controleren is net zo belangrijk als het controleren van de toegang van individuele gebruikers.

De valkuil van de applicatiesilo in pakketontwerp

Wanneer organisaties entitlement management van Entra ID voor het eerst gebruiken, is de standaardneiging om de structuur van oude IT-ticketsystemen na te bootsen. Een beheerder krijgt een verzoek voor Salesforce en maakt dus een Salesforce-pakket. Een week later vraagt iemand om SAP, en komt er een SAP-pakket. Al snel heb je tientallen applicatiespecifieke pakketten, en moeten eindgebruikers hun dagelijkse machtigingen handmatig samenstellen.

Deze aanpak creëert precies de versnippering die entitlement management juist moest wegnemen. Niemand wordt aangenomen om alleen Salesforce te gebruiken; mensen worden aangenomen als regionaal accountmanager, financieel analist of projectmedewerker. Wanneer je per applicatie in plaats van per rol pakketten maakt, dwing je managers om meerdere losse aanvragen zonder context goed te keuren. Door je ontwerp te baseren op op rollen gebaseerde pakketten, wordt alles wat een identiteit nodig heeft voor een specifieke functie in één samenhangende eenheid aangevraagd, goedgekeurd en uiteindelijk ook weer ingetrokken.

Op rollen gebaseerde pakketten versus applicatiepakketten

Een applicatiepakket geeft slechts één aanmelding, waardoor de gebruiker kwetsbaar is omdat basale samenwerkingstools ontbreken, zoals SharePoint-sites, beveiligingsgroepen en Microsoft Teams-kanalen. Een op rollen gebaseerd pakket bundelt al deze onderliggende resources met gerichte machtigingen, zoals lidmaatschap van een team, bijdragerechten op een repository en leestoegang tot een rapportageportal. Dit vermindert de beslissingsdruk op goedkeurders aanzienlijk: zij kunnen één logisch pakket beoordelen in plaats van zich door vijf afzonderlijke machtigingsverzoeken te worstelen.

Catalogusgrenzen en eigenaarschapscontroles

Entitlement management is afhankelijk van catalogi om resources en pakketten te ordenen, maar een catalogus is meer dan alleen een map: het is een beveiligingsgrens. Zonder strikt eigenaarschap van catalogi gaan afdelingen over de grenzen heen, halen ze resources uit engineering in marketingpakketten of maken ze administratieve bundels zonder goed toezicht.

Elke catalogus moet een benoemde eigenaar hebben die echt bevoegd is, geen gedeelde mailbox of opgeheven distributielijst. Cataloguseigenaren bepalen welke resources geïmporteerd mogen worden en wie pakketten binnen die grens mag opstellen. Heeft een catalogus geen toegewijde eigenaar, dan worden de pakketten erin verweesde objecten die onbepaald actief blijven, omdat niemand verantwoordelijk is om ze uit te faseren.

Voorkomen dat er na verloop van tijd wildgroei aan pakketten ontstaat

In het eerste jaar van een uitrol van entitlement management zien de systemen er brandschoon uit. Na drie jaar hebben teams honderden varianten opgebouwd: pakketten voor specifieke ad-hocvergaderingen, seizoensprojecten die allang zijn afgerond, of kleine aanpassingen aan bestaande groepslidmaatschappen. Aanvragers verdrinken in de keuzes en kiezen uiteindelijk het grootste beschikbare pakket, gewoon om zeker te zijn dat ze hun werk kunnen doen.

Om dat tegen te gaan, behandel je je pakketinventaris als een levende architectuur. Voordat een beheerder een verzoek voor een nieuw pakket goedkeurt, moet hij controleren of een bestaand pakket de behoefte al dekt. Daarnaast dwing je harde verloopdatums af voor projectgebonden pakketten, zodat tijdelijke toegang ook echt tijdelijk blijft.

Een duurzame governancestrategie opbouwen

Om access-pakketten te ontwerpen die meegroeien, moet je governance zien als een doorlopende gedragsworkflow en niet als een eenmalige configuratietaak. Combineer je op rollen gebaseerde pakketten met duidelijke naamgevingsconventies die duidelijk aangeven welk bedrijfsgebied en welk niveau ze dekken, zoals finance-analyst-standard of engineering-platform-elevated. Combineer deze namen met heldere beschrijvingen zonder jargon, geschreven specifiek voor nieuwe medewerkers en niet voor IT-beheerders.

Uiteindelijk slaagt entitlement management wanneer het rekening houdt met hoe mensen nu eenmaal handelen. Door het aantal beslissingen te beperken, veilige standaardinstellingen af te dwingen en toegang rechtstreeks te koppelen aan organisatorische rollen, voorkom je dat entitlement-wildgroei ontstaat voordat het begint.

Voor een bredere verkenning van toegangsreviews, identity governance-modellen en geautomatiseerde levenscyclusworkflows: Luister de volledige aflevering van de M365 FM Podcast en duik dieper in het beveiligen van je Microsoft-clouدomgeving.

Veelgestelde vragen

Waarom moeten access-pakketten per rol worden opgebouwd en niet per applicatie?

Pakketten per rol sluiten aan op de werkelijke bedrijfsbehoefte, waardoor gebruikers één compleet pakket aan resources kunnen aanvragen dat nodig is voor hun functie. Pakketten per applicatie dwingen gebruikers om meerdere afzonderlijke aanvragen in te dienen, wat de beheerlast en het risico op verweesde machtigingen vergroot.

Wat is het doel van een catalogus in entitlement management van Entra ID?

Catalogi fungeren als administratieve en beveiligingsgrenzen die gerelateerde resources en access-pakketten bevatten. Ze maken het mogelijk om eigenaarschap van specifieke bedrijfsgebieden te delegeren, zodat resourcebeheerders alleen middelen kunnen bundelen die relevant zijn voor hun afdeling.

Hoe voorkom je wildgroei aan pakketten in grote omgevingen?

Je voorkomt wildgroei aan pakketten door strikte naamgevingsconventies vast te leggen, voor elke catalogus een menselijke eigenaar te verplichten, bestaande pakketten regelmatig te controleren en automatische verloopdatums af te dwingen voor projectspecifieke pakketten.

Wat gebeurt er wanneer een access-pakket verloopt?

Zodra een toewijzing van een access-pakket de ingestelde einddatum bereikt, trekt Entra ID automatisch alle bijbehorende resourcetoegang in over de gebundelde groepen, teams en applicaties, zonder dat een manager handmatig moet ingrijpen.