Verschil tussen RBAC, ABAC en PBAC

RBAC, ABAC en PBAC zijn drie verschillende Access Control methodes die je binnen het IAM vakgebied kunt beschouwen als elkaars opvolgers. RBAC, ABAC en PBAC zijn access control methodes om geautomatiseerd te bepalen welke medewerkers welke toegangsrechten moeten krijgen en iedere methode hanteert een andere aanpak. Geautomatiseerd identiteits- en toegangsbeheer aan de hand van zulke methodes is belangrijk want je wilt niet alle toegangsrechten in een organisatie individueel en handmatig beheren. Je zoekt een structurele aanpak en daarvoor zorg je met RBAC, ABAC en PBAC. Hieronder leggen we uit hoe die methodes werken, wat de onderlinge verschillen zijn en de voordelen per methode. Ook geven we concrete voorbeelden van de drie methodes en hoe ze binnen een moderne IAM omgeving als HelloID worden ingezet. Maar we beginnen even met de historie achter deze toegangsmethodes.

Ontstaan van RBAC, ABAC en PBAC

Om de verschillen tussen de methodes te begrijpen, is het nuttig om eerst te kijken naar hun oorsprong en ontwikkeling.

Het begin: IBAC

De meest basale manier om toegangsbeheer te organiseren is Identity-Based Access Control (IBAC). Hierbij registreer je voor iedere individuele gebruiker een lijst met toegangsrechten. De behoefte hierop ontstond al bij mainframecomputers waar meerdere gebruikers toegang hadden tot één centraal computersysteem en beheerders wilden voorkomen dat gebruikers elkaar zouden hinderen op dat systeem. Met een beperkt aantal gebruikers en hooguit enkele gedeelde faciliteiten voldoet zo’n eenvoudige lijst met identiteiten en toegangsrechten.

De overgang naar RBAC

Met steeds meer gebruikers in netwerken en ook meer verschillende toepassingen werd het te ingewikkeld om voor iedereen individueel de verschillende toegangsrechten te blijven beheren. Daarom werd rond 1992 Role-Based Access Control (RBAC) geïntroduceerd. Hierbij krijgen gebruikers toegang tot IT-faciliteiten op basis van hun rol binnen de organisatie. Dit maakte het beheer eenvoudiger want iedereen met een bepaalde rol krijgt automatisch dezelfde rechten. Je beheert dus niet meer de toegangsrechten per gebruiker maar per rol.

Het ontstaan van ABAC

RBAC werkt goed in organisaties waarin een duidelijke één-op-één relatie bestaat tussen rollen en rechten. Maar er waren ook organisaties die duidelijk meer flexibiliteit vroegen. Daarom werd eind jaren ’90 Attribute-Based Access Control (ABAC) ontwikkeld. Bij ABAC worden toegangsrechten toegewezen op basis van verschillende kenmerken (attributen). Dat kan ook nog steeds iemands rol zijn maar bijvoorbeeld ook iemands afdeling of deskundigheden. Vanuit die optiek is RBAC een subset van ABAC; ABAC is breder, flexibeler en krachtiger.

De evolutie naar PBAC

ABAC maakt je dus flexibeler maar tegelijkertijd wordt het al snel ingewikkeld om al die afhankelijkheden tussen de verschillende attributen en iemands rechten te structureren en beheren. Dit leidde tot de ontwikkeling van Policy-Based Access Control (PBAC). PBAC legt de nadruk op gebruiksgemak door het toegangsbeleid te definiëren in begrijpelijke, natuurlijke taal in plaats van complexe structuren of code. Hierdoor kunnen organisaties zelf eenvoudiger en sneller toegangsregels opstellen en wijzigen. Je verstrekt de toegangsrechten nog steeds op basis van attributen maar je gebruikt eenvoudige beleidsregels om ze te beheren. Ook kun je eenvoudiger procesregels en workflows toevoegen.[1]

Access control attributen

Attributen zijn kenmerken van gebruikers en hun gebruikerssessies en vaak maken we daarbij onderscheid tussen drie verschillende soorten attributen:

• Gebruikersattributen: Dit zijn attributen die betrekking hebben op de gebruiker zelf. Voorbeelden van user attributen zijn de naam van de gebruiker, afdeling, je reguliere werklocatie, specifieke competenties etc.
• Objectattributen: Deze attributen zijn eigenschappen of kenmerken van bijvoorbeeld applicaties, webservices of data waartoe de gebruiker toegang vraagt. Een voorbeeld van zo’n object of resource attribuut is het gevoeligheidsniveau (openbaar/vertrouwelijk/geheim) en helpt om te bepalen welke specifieke middelen een gebruiker mag benaderen
• Contextuele attributen: Deze categorie attributen betreft operationele, technische en soms situatie-specifieke context waarin de toegang plaatsvindt.Voorbeelden van contextual attributes zijn de datum en tijd van een toegangspoging, maar ook de toegangslocatie of -netwerk, de status van het systeem of het gebruikte device.[2]

Voorbeelden RBAC vs ABAC vs PBAC

Laten we de theorie eens concreet maken. Hieronder vind je een aantal voorbeelden hoe je RBAC, ABAC en PBAC in de praktijk kunt toepassen.

Voorbeeld RBAC (Role-Based Access Control)

RBAC verleent toegang op basis van de rol(len) die een gebruiker binnen een organisatie heeft. Gebruikers worden toegewezen aan specifieke rollen, en elke rol heeft vooraf gedefinieerde rechten en permissies. Bijvoorbeeld:

• Definitie en opzet: In RBAC worden rollen zoals “Financieel Manager”, “HR Medewerker”, “IT Beheerder” en “Verpleegkundige” gecreëerd. Gebruikers zoals Jan, Sara, Mike en Lisa worden aan deze rollen toegewezen en krijgen de bijbehorende toegangsrechten.
• Voorbeeld:
  

  Jan is een Financieel Manager en mag financiële rapporten bewerken en personeelsdossiers inzien.

  Sara is een HR Medewerker en mag personeelsdossiers inzien, maar niet bewerken.

  Mike is een IT Beheerder en heeft toegang tot IT-systemen, maar geen toegang tot financiële rapporten of personeelsdossiers.

  Lisa is een Verpleegkundige en mag patiëntendossiers inzien en vitale gegevens bijwerken.

• Voordelen: Dit model is eenvoudig te begrijpen en te implementeren, vooral in organisaties met een stabiele structuur. Het biedt duidelijkheid over wie welke toegang heeft.
• Nadelen: RBAC is minder flexibel bij veranderende of complexe toegangsbehoeften. Als er wijzigingen nodig zijn, moeten rollen worden aangepast of nieuwe rollen worden gecreëerd, wat kan leiden tot een overvloed aan rollen en ingewikkeld beheer.[3]

Voorbeeld ABAC (Attribute-Based Access Control)

ABAC verleent toegang op basis van verschillende attributen of eigenschappen van gebruikers, bronnen, acties en de omgeving. Deze attributen worden geëvalueerd om te bepalen of toegang moet worden verleend. Bijvoorbeeld:

• Definitie en opzet: Attributen kunnen betrekking hebben op de functie, afdeling en werkzame locatie van de gebruiker (user attributen), type bestand en gevoeligheid van informatie (resource attributen), tijdstip en locatie van toegang (contextuele attributen). Bedrijfsregels worden opgesteld die deze attributen combineren om toegangsbeslissingen te nemen.
• Voorbeeld:
  

  Jan mag vertrouwelijke financiële rapporten bewerken als hij in de afdeling Financiën werkt, de functie Manager heeft en het binnen kantooruren is.

  HR Medewerkers zoals Sara mogen personeelsdossiers inzien, maar niet bewerken, ongeacht het tijdstip.

  Lisa, een Verpleegkundige, mag het dossier van een patiënt inzien als zij de behandelende zorgverlener is, het binnen haar diensturen is en zij toegang aanvraagt vanuit het ziekenhuisnetwerk.

• Voordelen: ABAC biedt een hoge mate van flexibiliteit en fijnmazige controle. Toegang kan dynamisch worden aangepast op basis van actuele attributen, waardoor het geschikt is voor organisaties met complexe en veranderende toegangsbehoeften.
• Nadelen: Het systeem is complexer om te implementeren en te beheren. Het vereist een uitgebreid beheer van attributen en het zorgvuldig opstellen van regels, vaak met behulp van programmeercode zoals XACML, wat meer tijd en technische expertise vraagt.

Voorbeeld PBAC (Policy-Based Access Control)

PBAC bepaalt toegang op basis van centraal beheerde beleidsregels die attributen en logica combineren. Deze policies worden in begrijpelijke, natuurlijke taal geschreven, wat het beheer eenvoudiger en toegankelijker maakt. Bijvoorbeeld:

• Definitie en opzet: Beleidsregels worden opgesteld die duidelijk specificeren wie toegang heeft tot wat, onder welke omstandigheden. Deze regels combineren attributen met specifieke voorwaarden en worden centraal beheerd.
• Voorbeeld:
  

  Policy 1: Financiële managers mogen vertrouwelijke financiële rapporten bewerken tijdens kantooruren.

  Policy 2: HR-medewerkers mogen personeelsdossiers inzien, maar niet bewerken.

  Policy 3: Behandelende zorgverleners mogen medische dossiers van hun toegewezen patiënten inzien en bijwerken tijdens hun diensturen.

  Policy 4: Alle toegang tot patiëntendossiers moet plaatsvinden binnen het ziekenhuisnetwerk.

  Deze policies worden in natuurlijke taal geschreven en centraal beheerd, waardoor ze eenvoudiger te begrijpen en aan te passen zijn.

• Voordelen: PBAC combineert de flexibiliteit van ABAC met eenvoudiger beheer. Doordat policies in natuurlijke taal zijn geschreven, kunnen ze sneller worden opgesteld en aangepast, zelfs door mensen zonder diepgaande technische kennis. Het centrale beheer van policies maakt het makkelijker om consistentie te behouden en snel in te spelen op veranderingen.
• Nadelen: Het vereist een goed opgezet en beheerd beleidssysteem. Als er te veel policies zijn of als ze niet goed worden beheerd, kan het systeem complex en moeilijk te overzien worden.

RBAC vs ABAC

Wat is het verschil tussen RBAC en ABAC?

Het belangrijkste verschil tussen RBAC en ABAC is de manier waarop elke methode toegang verleent. Met RBAC kun je toegang verlenen door een rol rechtstreeks aan een gebruiker toe te kennen. Met ABAC kun je de toegang dynamisch bepalen op basis van gebruikerskenmerken, objectkenmerken en contextuele kenmerken.

ABAC vs PBAC

Wat is het verschil tussen ABAC en PBAC?

Het verschil tussen ABAC vs PBAC zit in hoe je het rechtenmodel kunt configureren. Met ABAC configureer je de rolattributen via speciale markup talen zoals XACML. Met PBAC stel je deze in in de vorm van eenvoudige beleidsregels en met natuurlijke taal. PBAC is dus niet per se krachtiger dan ABAC, maar wel veel eenvoudiger om te gebruiken.

Samengevat

Kort samengevat zijn dit dus de verschillen

• RBAC is geschikt voor eenvoudige, stabiele omgevingen maar mist flexibiliteit.
• ABAC biedt grote flexibiliteit en fijnmazige controle, maar is complexer in beheer.
• PBAC combineert de flexibiliteit van ABAC met eenvoudiger beheer door gebruik van centraal gedefinieerde policies in een begrijpelijke taal.

Belangrijk is dat de verschillen tussen ABAC en PBAC niet liggen in het gebruik van de attributen. Ook bij PBAC gebruik je een of meerdere attributen, maar je beschikt over een meer gebruiksvriendelijke aanpak om je toegangsrechten te beheren.[4] Dat illustreren we hieronder aan de hand van het HelloID platform.

RBAC, ABAC en PBAC binnen je IAM platform

Veel IAM platformen ondersteunen RBAC maar we zagen al dat je daarmee beperkingen hebt. Daarom hebben we voor HelloID een geavanceerder mechanisme ingebouwd waarmee we een combinatie van RBAC, ABAC en PBAC bieden. Je kunt daarbij alle beschikbare informatie over gebruikers, hun context en hun verzoeken gebruiken. Om dat wel werkbaar en toegankelijk te houden gebruiken we binnen HelloID de user attributen anders dan de context en resource attributen:

• De waardes van user attributen zijn relatief statisch. Iemands functie, afdeling etc. veranderen niet dagelijks en daarom kun je ze perfect binnen de HelloID Provisioning Module gebruiken om automatisch te bepalen welke accounts en toegangsrechten medewerkers nodig hebben. Een of twee keer per dag ververst het systeem de accounts en toegangsrechten van de gebruikers en zet de wijzigingen door naar de betrokken doelsystemen zoals de Active Directory, TOPdesk en bedrijfsapplicaties.
• Context attributen en resource attributen gaan niet over gebruikers maar over individuele gebruikerssessies en deze waardes veranderen per sessie. We kunnen ze dus niet gebruiken voor de provisioning van gebruikersaccounts en rechten. In plaats daarvan gebruiken we die context- en resource-afhankelijkheden om de toegangsrechten verder te verfijnen. Je kunt bijvoorbeeld in een toegangsrecht een conditie opnemen dat de toegang alleen geldt tijdens kantoortijden. Zo maken we de toegang waar gewenst context- en resource-afhankelijk.

Kortom, het geautomatiseerd verstrekken van gebruikersaccounts en hun rechten naar doelsystemen doen we aan de hand van user attributen. Het verfijnen van specifieke toegangsrechten kunnen we doen aan de hand van context attributen en resource attributen. Zo ondersteunen we volledige ABAC en PBAC. We leggen het hieronder verder uit.

Provisioning aan de hand van user attributen

Bij die provisioning zit het grote verschil tussen RBAC en ABAC dus in de beschikbare user attributen. Pure RBAC werkt alleen met rollen terwijl je bij ABAC beschikt over veel meer attributen zoals de afdeling, divisie, werklocatie en competenties die je bovendien kunt combineren. En daarmee heb je de mogelijkheden je rechtenbeheer veel slimmer en eenvoudiger te organiseren. Zo kun je bijvoorbeeld een slimme ‘rechtenpiramide’ bouwen:

• Sommige rechten heeft iedere medewerker nodig. In veel organisaties krijgt bijvoorbeeld iedereen een mailaccount en een Microsoft 365 licentie. Dus die verstrek je met ABAC automatisch organisatie-breed aan alle gebruikers. Je hoeft dus niet zoals bij RBAC deze rechten aan alle aanwezige rollen te koppelen.
• Andere rechten kun je verstrekken aan de hand van een afdeling of team. Een voorbeeld is een SharePoint afdelingsshare. Die verstrek je aan de hand van de afdeling waar mensen werkzaam zijn. Ook hier doen de individuele rollen er niet toe.
• Vaak hou je dan slechts een beperkt aantal rechten over die je echt specifiek aan iemands rol moet koppelen. Zoals een zorgmedewerker die specifieke rechten in het zorgsysteem moet krijgen. Alleen die rechten verstrekken we dus aan de hand van individuele rollen.

Dit illustreert de kracht van ABAC. Met attributen als rollen, afdelingen, teams, locaties of competenties kun je heel eenvoudig andersoortige en grotere groepen binnen je organisatie selecteren aan wie je in een keer dezelfde rechten kunt toekennen. Met RBAC lukt dat niet of wordt het enorm ingewikkeld.

Van ABAC naar PBAC met business rules

Maar hoe kun je zo’n attribuut gebaseerd model ook eenvoudig instellen en beheren? Je wilt niet een scripting tool of een andere ingewikkelde methode gebruiken om je ABAC instellingen te beheren. Hiervoor gebruiken we binnen HelloID business rules. In een business rule (ook wel beleidsregel genoemd) kun je eenvoudig beschrijven bij welke specifieke gebruikerscondities welke bijbehorende rechten of permissies moeten worden toegekend. In een zorginstelling zou zo’n business rule er bijvoorbeeld als volgt kunnen uitzien:

Als een medewerker de functie ‘Helpende Niveau 4’ heeft en werkt op afdeling Zorg A (de conditie) à krijgt deze standaard een Entra ID account + een account in het Elektronisch Cliënten Dossier met rechten voor cliënten op Zorg A (de bijbehorende permissies).

Zoals we al eerder aangaven kunnen we die permissies verfijnen aan de hand van contextattributen en resourceattributen. In een zorgsysteem kun je bijvoorbeeld instellen welke cliëntgroepen toegankelijk zijn, of men gegevens alleen mag inzien of ze ook bewerken, en vanaf welk netwerk. Per applicatie zijn er andere configuratiemogelijkheden en er is dan ook een uitgebreide HelloID connector catalogus om de verschillende doelsystemen aan te sluiten en automatisch te voorzien van de juiste rechten.

Met die business rules realiseren we een PBAC (Policy-Based Access Control) model en dat heeft een enorm voordeel. Het denken in beleidsregels is eenvoudig en de beheerder hoeft zich niet te verdiepen in de achterliggende structuur tussen attributen en rechten. Je voegt eenvoudig regels toe die naar behoefte kunnen gelden voor alle gebruikers, specifieke afdelingen, rollen of andere user attributen. Ook kun je eenvoudig allerlei condities toevoegen aan de permissies. Eventuele overlap tussen business rules is daarbij geen probleem, het systeem vertaalt alle ingevoerde regels naar een consistente, samenhangende rechtenstructuur. Extra voordeel is dat je via business rules ook aanvullende beleidsregels en workflows kunt toevoegen. Bijvoorbeeld een regel dat accounts voor nieuwe medewerkers een week vóór de on-boarding moeten worden geactiveerd. Of dat sommige applicatierechten pas actief mogen worden als gebruikers de gebruikersvoorwaarden online hebben geaccepteerd.

Meer weten over RBAC, ABAC en PBAC

Meer weten over hoe je het bovenstaande praktisch kunt toepassen voor je identity en access management? In ons webinar geven we een uitgebreide uitleg over de opbouw van je rechtenstructuur aan de hand van rollen en andere attributen. Ook zie je hoe je role mining kunt gebruiken om je bestaande rechtenstructuur te analyseren en deze verder te optimaliseren.

Bekijk het hier

Bronnen:

[1] https://www.jstor.org/stable/10.2307/26486786

[2] https://dl.acm.org/doi/abs/10.1145/3007204

[3] https://link.springer.com/chapter/10.1007/978-3-030-04834-1_2

[4] https://ieeexplore.ieee.org/abstract/document/4470448