RBAC vs ABAC

De keuze tussen toegangscontrolemodellen bepaalt hoe je rechten toekent, wijzigt en intrekt voor elke gebruiker. De twee meest gebruikte modellen zijn Role-Based Access Control (RBAC) en Attribute-Based Access Control (ABAC). RBAC bundelt rechten in rollen. ABAC leidt toegang af uit attributen zoals afdeling, functietitel of locatie. Het zijn geen tegenpolen: in de praktijk gebruiken de sterkste opzetten attributen om te bepalen welke rollen een gebruiker krijgt. Het loont dus om te weten hoe elk model werkt en waar de grens tussen beide ligt.

Wat is Role-Based Access Control (RBAC)?

Role-Based Access Control (RBAC) kent rechten toe via vooraf gedefinieerde rollen. Je definieert rollen zoals administrator, finance manager of service desk agent, koppelt aan elke rol een vaste set rechten en wijst gebruikers vervolgens aan rollen toe. Een gebruiker erft alles wat de rol verleent en niets meer.

RBAC is overzichtelijk en eenvoudig te auditen, omdat toegang netjes terug te voeren is op een benoemde rol. Het nadeel komt naar voren bij schaal. Als verantwoordelijkheden niet precies in een rol passen, maken teams steeds meer smalle rollen om de uitzonderingen af te dekken, en die wildgroei aan rollen wordt lastig te onderhouden.

Wat is Attribute-Based Access Control (ABAC)?

Attribute-Based Access Control (ABAC) leidt toegang af uit attributen op de gebruiker, zoals afdeling, functietitel of locatie. In plaats van handmatig een rol toe te wijzen, schrijf je de regel één keer: een bepaalde attribuutwaarde verwijst naar een vaste set groepen, rollen of resources. Zet je het attribuut, dan krijgt de gebruiker die hele set. Wijzig je het attribuut, dan wordt de set omgewisseld en wordt verwijderd wat niet meer van toepassing is.

Bijvoorbeeld: de waarde afdeling = Finance kan verwijzen naar de Finance SharePoint-site, de GL-applicatiegroep, de finance distributielijst en een on-prem AD-beveiligingsgroep. Eén attribuutwaarde stuurt een consistente set toegang aan. Zo blijft toegang afgestemd op hoe de organisatie mensen daadwerkelijk omschrijft, in plaats van op een aparte lijst met rol-toewijzingen die je los moet bijhouden.

RBAC vs ABAC: een vergelijking naast elkaar

Beide toegangscontrolemodellen verlenen uiteindelijk dezelfde soort rechten. Het verschil zit in wat bepaalt wie ze krijgt.

• Wat toegang stuurt:RBAC kent toegang toe via een rol die iemand krijgt. ABAC leidt toegang af uit attribuutwaarden die al op de gebruiker staan, zoals afdeling of functietitel.
• Omgaan met verandering:Bij RBAC betekent een overstap of promotie het handmatig opnieuw toewijzen van rollen. Bij ABAC werk je één attribuut bij en volgt de bijbehorende set groepen en rollen automatisch.
• Uitzonderingen:RBAC krijgt al snel extra rollen om uitzonderingen af te dekken. ABAC legt uitzonderingen vast als regels op attributen, dus je past een regel aan in plaats van weer een rol aan te maken.
• Auditen:RBAC is eenvoudig te auditen omdat toegang terug te voeren is op een benoemde rol. ABAC kost meer moeite om te auditen, omdat je toegang moet herleiden via de regels en de attribuutwaarden die ze hebben geactiveerd.

De echte kosten van ABAC

ABAC is flexibel, maar die flexibiliteit heeft een prijs die het waard is te benoemen voordat je ervoor kiest.

• Complexiteit van regels:Elk attribuut dat toegang stuurt, is weer een invoer die je schoon en consistent moet houden. Foutieve of ontbrekende attribuutdata leidt tot verkeerde toegang, dus het model is zo goed als de data die het voedt.
• Lastiger te auditen:Omdat toegang wordt afgeleid en niet toegewezen, betekent de vraag wie waarbij kan dat je de regels moet doorlopen. Dat is meer werk dan een lijst met rollidmaatschappen lezen.
• Ontwerp vooraf:Met RBAC kun je klein beginnen met een handvol rollen. ABAC vraagt je eerst de koppeling van attribuut naar toegang te doordenken, wat in het begin meer werk is maar zich uitbetaalt naarmate de organisatie groeit.

RBAC en ABAC samen

Je hoeft niet één model te kiezen en met de zwakke kanten ervan te leven. Het praktische patroon is om attributen te laten bepalen welke rollen een gebruiker krijgt: ABAC die RBAC aanstuurt. Je houdt rollen als de eenheid die mensen begrijpen en auditen, en je gebruikt attribuutwaarden om die rollen automatisch toe te kennen en in te trekken.

In deze opzet verwijst één attribuutwaarde, zoals een afdeling of functietitel, naar een vaste set groepen en rollen. Het attribuut bepaalt het lidmaatschap; de rol draagt nog steeds de rechten. Je krijgt de helderheid van benoemde rollen samen met de onderhoudsarme, zelfcorrigerende toewijzing die attributen bieden. Dit is het model waar ServiceChanger omheen is gebouwd.

Welk toegangscontrolemodel past bij jouw organisatie?

Draait je organisatie op stabiele, goed gedefinieerde rollen en hecht je vooral aan eenvoudig auditen, dan kan kale RBAC voldoende zijn. Wisselen mensen vaak van afdeling, locatie of functietitel, dan wordt dat handmatig beheren de bottleneck en betaalt op attributen gebaseerde toewijzing zich uit. Voor de meeste groeiende organisaties is het antwoord niet RBAC of ABAC maar beide: rollen voor helderheid, attributen om die rollen correct toegewezen te houden naarmate mensen veranderen.

Hoe ServiceChanger toegangsbeheer vereenvoudigt

ServiceChanger automatiseert groeps- en rollidmaatschappen in Microsoft Entra ID en on-prem Active Directory, aangestuurd door een attribuutmodel. Je koppelt één attribuutwaarde aan de set groepen en rollen die ze hoort te verlenen, en ServiceChanger houdt de lidmaatschappen synchroon. Stel of wijzig het attribuut en de juiste toegang volgt, waarbij wat niet meer van toepassing is wordt verwijderd. Geen scripting per wijziging, en geen aparte lijst met toewijzingen die je handmatig moet bijhouden.

• Attribuut stuurt lidmaatschap:Een waarde voor afdeling, functietitel of locatie verwijst naar een vaste set Entra ID- en on-prem AD-groepen en -rollen.
• Synchroon gehouden:Wijzig het attribuut en de lidmaatschappen volgen, inclusief het verwijderen van toegang die niet meer van toepassing is, zonder voor elke wijziging een script te schrijven.
• Cloud en on-prem:Entra ID dynamische groepen en Entra Connect verzorgen de cloudkant; een PowerShell-runbook op een hybrid worker past hetzelfde model toe op on-prem Active Directory.

Een concreet geval. Je zet afdeling = Finance op een gebruiker, en ServiceChanger verleent automatisch de Finance SharePoint-site, de GL-applicatiegroep, de finance distributielijst en de bijbehorende on-prem AD-beveiligingsgroep. Verplaats je die gebruiker naar een andere afdeling, dan wordt de Finance-toegang verwijderd en vervangen. Onder de motorkap gebruikt het Entra ID dynamische groepen, Entra Connect en een PowerShell-runbook op een hybrid worker om on-prem AD te bereiken, zodat hetzelfde model zowel cloud- als on-prem-identiteiten dekt.