Role explosion: waarom RBAC vastloopt na 200 medewerkers

Ergens tussen de 200 en 300 medewerkers lopen de meeste IT-teams tegen dezelfde muur op: het aantal rollen in het toegangsmodel groeit sneller dan het aantal mensen. Wat begon als een overzichtelijke lijst van tien functiegebonden rollen is stilletjes uitgegroeid tot negentig, en niemand kan meer met zekerheid zeggen wat de helft ervan precies geeft. Dit is role explosion access control in zijn meest voorkomende vorm, en het is een van de meest voorspelbare problemen in identity management.

Het frustrerende is dat er geen enkele dag iets misging. Elke nieuwe rol werd om een redelijke reden toegevoegd: een nieuw kantoor, een hybride functietitel, een klant die net iets andere rechten nodig had. De schade is cumulatief, niet het gevolg van één slechte beslissing.

Dit artikel legt uit waarom statische RBAC (role-based access control) tot op zekere hoogte prima schaalt en daarna volledig vastloopt, en wat attribute-based denken anders doet om diezelfde valkuil te vermijden.

Waarom RBAC prima werkt bij 50 mensen en faalt bij 250

Role-based access control kent rechten toe aan een rol, en gebruikers krijgen rechten door aan die rol te worden toegewezen. Op kleine schaal is dat elegant. Een bedrijf met 50 medewerkers heeft misschien acht of tien rollen nodig: sales, finance, engineering, support, management. Iedereen past ergens. Eén persoon kan het hele model in zijn hoofd houden.

De problemen beginnen zodra de organisatie diverser wordt. Groei brengt met zich mee:

• Meerdere kantoren of landen, elk met net iets andere toegangsbehoeften.
• Hybride functies die niet netjes op één afdeling passen (een "sales engineer", een "finance ops"-medewerker).
• Klant- of projectspecifieke toegang die niet in een bestaande rol past.
• Reorganisaties waarbij oude rollen technisch nog toegewezen staan aan mensen die intussen zijn doorgestroomd.

Elk van deze punten is op zich beheersbaar. Samen zijn ze dat niet. Niemand start met het doel negentig rollen te bouwen. Ze stapelen zich op, één uitzondering per keer, en tegen de tijd dat iemand het opmerkt voelt opruimen risicovoller dan het gewoon laten zoals het is.

Het mechanisme achter role explosion

Combinatorische groei

De wiskundige oorzaak is combinatorisch. Als toegang werkelijk afhangt van afdeling, locatie en senioriteit, heeft een strikt rolgebaseerd model in principe een aparte rol nodig voor elke combinatie die in de praktijk voorkomt. Vijf afdelingen keer vier locaties keer drie senioriteitsniveaus is in het slechtste geval al zestig rollen, nog voordat je project- of klantspecifieke variatie meerekent. RBAC gaat ervan uit dat een rol een stabiel, benoembaar ding is, maar echte organisaties hebben toegangseisen die eigenlijk combinaties van attributen zijn. Die combinaties modelleren als platte, benoemde rollen is precies waar de vermenigvuldiging ontstaat.

Niemand is eigenaar van het opruimen

Een rol aanmaken is een gunst van vijf minuten voor iemand die vastzit. Een rol opheffen vereist dat je weet wie er allemaal aan toegewezen is, waarom ze die rol kregen, en dat verwijderen niets breekt. Dat is echt werk met echt risico, en het heeft zelden een eigenaar. Dus rollen stapelen zich op en worden bijna nooit verwijderd. Een rol-audit bij de meeste mid-market bedrijven boven de 200 medewerkers levert rollen op met één lid, rollen zonder leden, en rollen die niemand meer kan verklaren.

Rolnamen verliezen hun betekenis

Bij een jong bedrijf heeft "Sales Manager NL" een duidelijke, actuele betekenis. Drie jaar en twee reorganisaties later bevat diezelfde rol misschien mensen uit een afdeling die niet meer onder die naam bestaat, plus wat legacy-uitzonderingen die nooit zijn opgeruimd. De naam overleeft; de betekenis niet. Auditors en reviewers keuren rollen uiteindelijk goed op basis van het label, niet de inhoud, omdat het verifiëren van de inhoud te veel tijd kost.

Wat role explosion in de praktijk kost

De kosten komen op drie plekken naar boven, en geen van alle is hypothetisch.

1. Access reviews duren langer en betekenen minder. Een kwartaalreview met negentig rollen en onduidelijk eigenaarschap wordt een afvinkoefening. Reviewers kunnen niet zinvol beoordelen wat ze niet begrijpen, dus keuren ze standaard goed. Dit is precies het patroon dat auditors signaleren onder kaders als ISO 27001 en NIS2, waar de kwaliteit van reviews telt, niet alleen de frequentie.
2. Onboarding en offboarding worden trager en risicovoller. Nieuwe IT-beheerders kunnen niet inschatten welke van de negentig rollen een nieuwe medewerker echt nodig heeft, dus kopiëren ze de toegang van een collega (met het risico van te veel rechten) of escaleren ze elk verzoek. Offboarding lijdt op dezelfde manier: een vertrekkende medewerker uit "zijn rollen" halen is onbetrouwbaar als niemand meer zeker weet welke rollen daadwerkelijk iets deden.
3. Standing access hoopt zich stilletjes op. Elke ongebruikte of half begrepen rol is een set staande rechten die niemand actief beheert. Dit is precies het patroon van access-sprawl dat telkens terugkomt in post-mortems na een incident: niet één overduidelijk foute toewijzing, maar honderden kleine, vergeten toewijzingen.

Attribute-based access als uitweg

Attribute-based access control (ABAC) probeert niet elke combinatie vooraf te benoemen. In plaats van een rol voor "Sales Manager NL Senior" schrijf je een regel: toegang volgt direct uit afdeling, locatie en functietitel, de attributen van de gebruiker in Entra ID of Active Directory. De regel evalueert de combinatie op het moment van toewijzing, in plaats van dat iemand vooraf een rol moet hebben gebouwd voor precies die combinatie.

Waarom dit de vermenigvuldiging stopt

Het aantal regels dat je nodig hebt groeit niet combinatorisch mee met het aantal attribuutcombinaties dat bestaat. Een handvol regels op basis van afdeling, locatie, functietitel en dienstverband kan hetzelfde terrein afdekken als negentig statische rollen vroeger deden, omdat de rule engine het combineren doet, niet een mens die een rollencatalogus onderhoudt. Er komt een nieuw kantoor bij en de bestaande locatieregels zijn er meteen op van toepassing.

Waarom dit rollen eerlijk houdt

Omdat toegang wordt afgeleid van actuele attributen in plaats van een statische toewijzing, corrigeert het zichzelf zodra de onderliggende gegevens veranderen. Iemand wisselt van afdeling in HR of in Entra ID, en de toegang wordt automatisch herberekend in plaats van dat diegene rechten blijft houden uit een rol die hij feitelijk verlaten heeft. Die ene eigenschap lost het grootste deel op van het "verweesde rollidmaatschap"-probleem dat access reviews zo vervelend maakt.

Een praktische manier om een bestaande wirwar te ontrafelen

Je hoeft je toegangsmodel niet vanaf nul opnieuw op te bouwen om vooruitgang te boeken. Een gefaseerde aanpak werkt beter dan een big-bang-migratie:

• Analyseer eerst je bestaande groepen en rollen. Kijk wie er daadwerkelijk in elke rol zit en welke attributen ze gemeen hebben. Vaak valt het grootste deel van een rommelige rollencatalogus netjes op twee of drie attributen te herleiden zodra je er zo naar kijkt.
• Begin met de rollen met de meeste leden. De rollen omzetten die het grootste deel van je mensen dekken, haalt meteen het meeste onderhoud weg, ook als een aantal randgevallen als statische, handmatig beheerde groepen blijft bestaan.
• Houd echte uitzonderingen als uitzondering. Niet alles hoort regelgedreven te zijn. Directietoegang, eenmalige contractorafspraken en werkelijk unieke gevallen horen in kleine, duidelijk gelabelde statische groepen, niet geforceerd in een attribuutregel die er niet echt op van toepassing is.
• Review wat overblijft op een vaste cadans. Zodra het grootste deel van de toegang regelgedreven is, krimpt de access review tot het beoordelen van echte uitzonderingen, iets wat mensen daadwerkelijk goed kunnen doen.

De group mining van ServiceChanger kijkt naar je bestaande Entra ID- en on-prem AD-groepen en stelt de attribuutpatronen voor die er al in verscholen zitten, zodat deze eerste stap geen handmatige audit van elke rol vereist.

RBAC versus ABAC op schaal: een snelle vergelijking

Statische RBAC	Attribute-based (ABAC)
Rollen nodig voor 5 afdelingen x 4 locaties	20+ benoemde rollen	Een handvol regels
Nieuw kantoor opent	Nieuwe rollen voor dat kantoor	Bestaande locatieregels gelden automatisch
Medewerker wisselt van afdeling	Handmatige rolwijziging	Toegang wordt herberekend uit het bijgewerkte attribuut
Inspanning access review	Groeit mee met aantal rollen	Gericht op regels en echte uitzonderingen
Faalmodus	Rollen die niemand begrijpt	Regel heeft een echte randgeval-groep nodig

FAQ

Bij welke bedrijfsgrootte begint role explosion meestal? De meeste mid-market IT-teams merken het ergens tussen de 200 en 300 medewerkers, zodra de organisatie genoeg afdelingen, locaties en functievariaties heeft dat een platte rollencatalogus dit niet meer overzichtelijk kan dekken.

Moeten we RBAC helemaal loslaten om dit op te lossen? Nee. Attribute-based access control vervangt het idee van rollen niet, het verandert hoe toegang wordt afgeleid. Je houdt rolconcepten aan voor rapportage terwijl de onderliggende rechten uit attributen worden berekend, en behoudt een klein aantal statische rollen voor echte uitzonderingen.

Is dit hetzelfde probleem als te veel Entra ID-groepen? Het hangt nauw samen. Role explosion uit zich vaak als group sprawl in Entra ID en on-prem AD, omdat elke statische rol meestal op minstens één groep wordt afgebeeld. Het rolmodel en de groepsstructuur opschonen gebeurt doorgaans in één beweging.

Hoe lang duurt het om een bestaande rollencatalogus te ontrafelen? Dat hangt af van hoe verward het is, maar beginnen met de rollen met de meeste leden en bestaande groepen doorlichten op attribuutpatronen laat doorgaans al binnen enkele weken merkbare reductie zien.

Als je rollencatalogus stilletjes voorbij het punt is gegroeid waar iemand hem nog kan uitleggen, is dat een signaal om vóór je volgende access review te handelen, niet erna. ServiceChanger past attribute-based regels toe over zowel Entra ID als on-prem Active Directory, zodat je je meest gebruikte rollen kunt omzetten naar regels zonder wat al werkt overhoop te halen. Lees meer over attribute-based access control of bekijk de gids over role-based access control voor de basis waarop dit artikel voortbouwt.