Rol-gebaseerde toegangscontrole (RBAC)

Role-Based Access Control (RBAC) verleent systeemtoegang op basis van rol in plaats van per individuele gebruiker. In plaats van rechten per persoon uit te delen, definieer je een rol één keer, koppel je de bijbehorende toegang en wijs je mensen aan die rol toe. Deze pagina legt uit hoe RBAC werkt, waar het past in Microsoft Entra ID en on-prem Active Directory, waar het model ophoudt, en hoe ServiceChanger rol- en groepslidmaatschappen synchroon houdt vanuit één attribuut.

Wat Role-Based Access Control (RBAC) is

RBAC koppelt toegang aan rollen, niet aan personen. Een rol bundelt de rechten die bij een functie horen, en gebruikers erven die rechten doordat ze lid zijn van de rol. Het model bestaat uit vier onderdelen: gebruikers, rollen, rechten en de toewijzingen die ze verbinden. Wanneer iemand van functie wisselt, verplaats je die persoon tussen rollen in plaats van tientallen losse rechten aan te passen. Dat houdt toegang voorspelbaar, beter te auditen en eenvoudiger te beheren op schaal.

Waarom teams RBAC gebruiken

RBAC vermindert ongeautoriseerde toegang doordat mensen alleen de rechten hebben die hun rol meebrengt, wat aansluit bij het principe van de minste rechten. Het beperkt beheerwerk, omdat toegang per rol wordt toegekend en ingetrokken in plaats van per gebruiker. En het maakt audits eenvoudig: in plaats van elk account te bekijken, beoordeel je een korte lijst met rollen en wie daarin zit. De twee gewoonten die een RBAC-opzet gezond houden zijn rollen benoemen naar echte functies en het lidmaatschap van rollen volgens een vast schema herzien zodat het niet afdrijft.

RBAC in Microsoft Entra ID en Active Directory

In een Microsoft-omgeving vertalen rollen zich naar groepen: Entra ID-groepen en -rollen in de cloud, beveiligings- en distributiegroepen in on-prem Active Directory. Het lastige is niet het definiëren van een rol, maar het lidmaatschap correct houden terwijl mensen in dienst komen, doorstromen en vertrekken. ServiceChanger doet dat met een attribuutmodel. Eén attribuut op de gebruiker, zoals afdeling, functietitel of locatie, koppelt aan een vaste set groepen en rollen. Je zet het attribuut en de hele set volgt. Wijzig je het, dan wisselt de set mee en worden verouderde lidmaatschappen automatisch verwijderd.

Een uitgewerkt voorbeeld

Stel dat het afdelingsattribuut van een gebruiker op "Finance" staat. ServiceChanger koppelt die waarde aan een set: de Finance Entra ID-groep, de SharePoint Finance-sitegroep en een on-prem beveiligingsgroep voor de boekhoudkundige fileshare. Het zetten van het attribuut voegt de gebruiker in één keer aan alle drie toe. Wanneer die persoon naar Sales overstapt, wijzig je één attribuut. ServiceChanger plaatst ze in de Sales-set en verwijdert de drie Finance-lidmaatschappen, zodat er geen resttoegang achterblijft. Eén waarde erin, een vaste set lidmaatschappen eruit, automatisch actueel gehouden.

Waar RBAC ophoudt en ABAC begint

RBAC bepaalt toegang op basis van rollidmaatschap en niets meer. Zodra toegang moet afhangen van actuele context, de locatie van de gebruiker, het tijdstip, de gevoeligheid van het record, is het geen RBAC meer. Die beslissingen horen bij Attribute-Based Access Control (ABAC) of Policy-Based Access Control (PBAC), die attributen op het moment van het verzoek beoordelen. Het is goed om de grens helder te houden: "dynamische" of "contextbewuste" toegang is geen geavanceerde RBAC-functie, maar een ander model. In de praktijk draaien veel organisaties beide, met rollen als de stabiele ruggengraat van toegang en attribuutregels voor de voorwaardelijke delen. ServiceChanger werkt op de lidmaatschapslaag en stuurt de groepen en rollen aan waaruit die modellen lezen.

RBAC over cloud- en hybride directories

Cloudplatforms hebben elk hun eigen rolmodel, AWS IAM, Azure-rollen, GCP IAM, en de praktische uitdaging is rollidmaatschap consistent houden wanneer identiteit op meerdere plekken leeft. Een hybride Microsoft-omgeving is het gangbare geval: identiteiten staan in on-prem Active Directory en synchroniseren naar Entra ID. ServiceChanger past één model toe over die splitsing, zodat hetzelfde attribuut lidmaatschappen in beide directories aanstuurt zonder dat je elke kant met de hand scriptt. Licentiegebruik wordt hierbij bijgehouden zodat je kunt zien welke toegewezen rollen overeenkomen met verbruikte seats, al rapporteert ServiceChanger dat gebruik alleen en wijst het de licenties niet zelf toe.

Conclusie

RBAC blijft een praktische standaard omdat het toegang voorspelbaar en auditbaar maakt: definieer rollen op functie, wijs mensen toe en herzie het lidmaatschap volgens een schema. De grens is dat het niet kan redeneren over actuele context, en daar nemen ABAC en PBAC het over. In een Microsoft-omgeving is het terugkerende probleem het lidmaatschap van groepen en rollen door de tijd heen correct houden, en dat is precies wat ServiceChanger automatiseert: één attribuutwaarde koppelen aan een set lidmaatschappen over Entra ID en on-prem Active Directory, en opruimen wat niet meer van toepassing is.

Veelgestelde vragen over Role-Based Access Control (RBAC)