Gratis demo Contact
RBAC best practices voor effectief toegangsbeheer

RBAC best practices voor effectief toegangsbeheer

Door: Arnout van der Vorst 6 oktober 2025

Moderne IAM-oplossingen zoals HelloID gebruiken zogeheten Role Based Access Control (RBAC) om de uitgifte en het beheer van accounts en rechten te organiseren. Bij grotere organisaties is het namelijk ondoenlijk om dat per medewerker bij te houden. In plaats daarvan bepaal je per rol welke rechten nodig zijn om de bijbehorende taken in te kunnen vullen. Iedereen met diezelfde rol krijgt identieke rechten. Je vereenvoudigt zo je rechtenbeheer, kunt de uitgifte van rechten automatiseren en voorkomt dat individuele gebruikers onjuiste rechten krijgen. In deze blog geven we wat concrete RBAC best practices . Maar eerst vatten we nog even kort het RBAC concept samen.

Wat doet RBAC?

De essentie van RBAC

RBAC vereist een set eenduidige gebruikersgegevens (ook wel attributen genoemd) die bijvoorbeeld in HR-systemen worden bijgehouden. Voorbeelden van zulke attributen zijn de functie van de medewerker, de afdeling waar hij of zij werkt, de werklocatie en iemands diploma’s. Door het systeem met deze brongegevens te koppelen aan het IAM-platform, kun je daarin al die gegevens gebruiken om iemands rechten te bepalen. Dus iedereen die ‘verpleegkundige’ is op de ‘kinderafdeling’ krijgt dezelfde rechten. Omdat je meerdere gebruikersattributen kunt gebruiken en de term ‘rol’ dus eigenlijk te beperkt is, wordt ook wel gesproken over Attribute Based Access Control (ABAC).

Voor de implementatie hiervan gebruikt HelloID zogeheten business rules die je eenvoudig kunt opstellen, uitbreiden en combineren. Hiermee kun je ook eenvoudig rechten uitdelen op meerdere niveaus. Rechten op mail, office en intranet zijn vaak generiek binnen de hele organisatie. Ook zijn er vaak rechten die iedereen binnen een bepaalde afdeling of locatie ontvangen, ongeacht hun specifieke functie. Er is maar een deel van de rechten die echt zijn gekoppeld aan individuele functies.

Meerdere keren per dag draait je HelloID platform een ‘run’ waarin op basis van de brongegevens en de business rules wordt bepaald in welke systemen iemand een account moet hebben en met welke rechten. Vervolgens worden de wijzigingen ten opzichte van de vorige run doorgevoerd in de aangesloten doelsystemen. Doelsystemen variëren van de Active Directory en de kantoorapplicaties tot allerlei organisatie specifieke bedrijfssystemen.

Dit is de essentie, maar hoe gebruiken klanten RBAC in de praktijk? We verzamelden binnen onze HelloID klantcases een aantal specifieke voorbeelden hoe RBAC is toegepast. We beginnen daarbij met de basics en werken van daaruit naar meer specifieke RBAC best practices.

Basis implementatie RBAC

RBAC basis implementatie

Met HelloID kun je heel basaal starten en dan in vervolgprojecten je rechtenbeheer steeds verder uitbreiden en verfijnen. Bij de eerste uitrol beperk je je dan tot het aansluiten van een bronsysteem (meestal het HR-systeem) en een of twee doelsystemen met slechts enkele rollen. Zo vertelde een middelgrote gemeente:

“Dankzij de koppeling met het HR-systeem komen alle personeelswijzigingen automatisch binnen in HelloID, dat ervoor zorgt dat de juiste accounts en toegangsrechten worden verstrekt. Dat beperkt zich niet tot de onboarding van nieuwe medewerkers. Ook functiewijzigingen worden automatisch verwerkt en als iemand de organisatie verlaat, zorgt HelloID dat de betreffende account en toegangsrechten vanzelf worden geblokkeerd. Role Based Access Control is basaal geïmplementeerd met een afgebakende set rollen. Dit kan desgewenst later worden verfijnd naar meer specifieke rollen en bijbehorende toegangsrechten.”

Ook bij zo’n basale uitrol is de winst vaak al aanzienlijk. Zelfs al beperkt de automatisering zich tot de uitgifte van accounts en rechten in bijvoorbeeld de Active Directory, toch geeft dit de IT-afdeling al veel meer grip op het rechtenbeheer en wordt er bespaard op handmatige werkzaamheden.

praktijkvoorbeeld zorg RBAC

Grootste businesscase met autorisatiemanagement

De grootste voordelen realiseer je echter als je het volledige autorisatiebeheer van complexe bedrijfsapplicaties gaat automatiseren. Een kenmerkend voorbeeld zijn Elektronische Patiënt Dossiers (EPD’s) binnen ziekenhuizen en andere zorginstellingen. Zo maakte een middelgrote zorgorganisatie een grote verbeterslag door het autorisatiebeheer van hun Nedap Ons zorgsysteem te automatiseren. Tot die tijd verstrekten ze alleen de accounts automatisch, de rechten werden handmatig ingesteld:

“Per gebruiker moet je instellen wat iemands rol is (of rollen), hun weekkaart- en deskundigheidsprofiel en vooral iemands bereik in het systeem. Het gaat er namelijk niet alleen om welke handelingen je mag uitvoeren, maar ook welke cliëntgegevens je moet kunnen inzien en bewerken. Iets dat nog complexer wordt omdat veel mensen vaak meerdere aanstellingen of rollen hebben. Op vergelijkbare wijze moet je ook fijnmazig kunnen instellen welke medewerker-gegevens toegankelijk zijn voor welke manager.

Met behulp van iemands afdeling, jobtitle en deskundigheid bepaalt HelloID aan de hand van eenvoudig te configureren business rules volautomatisch welke autorisaties moeten worden toegewezen. Op deze manier heeft dus iedere nieuwe medewerker automatisch op ieder moment de juiste Ons autorisaties. Bij indiensttreding, maar ook bij tussentijdse wijzigingen. Iedere wijziging in de HR-gegevens wordt bij de eerstvolgende ‘refresh’ doorgevoerd binnen HelloID en vertaald naar doelsystemen zoals Nedap Ons. En als iemand onze organisatie verlaat, worden automatisch alle gevoelige gegevens direct geblokkeerd. Overall heeft de automatisering inclusief het Nedap Ons autorisatiebeheer ons een besparing van zo’n 15 tot 20 uur per week opgeleverd en ook de kwaliteit is écht verbeterd.”

Met behulp van business rules wordt een uitgebreide vertaalslag gemaakt van gebruikersattributen uit het bronsysteem naar de autorisaties die worden ingesteld binnen de applicaties. Dit zijn geen eenvoudige permissies. Het zijn vaak uitgebreide ‘tweedimensionale combinaties’ van rechten:

  • Het betreft enerzijds functionaliteit die iemand met een bepaalde functie mag gebruiken. Een verpleegkundige mag bijvoorbeeld geen medicatie voorschrijven maar een arts wel.

  • Daarnaast de toegang tot (patiënt)gegevens. In het kader van de AVG moeten zorgmedewerkers zoveel mogelijk alleen toegang krijgen tot de patiënten binnen de eigen afdeling waarmee men een zorg- of behandelrelatie heeft. En dan hangt het ook van de functie af of iemand medische gegevens alleen mag inzien of ze mag wijzigen.

Je ziet dus dat deze autorisaties direct van belang zijn voor de compliance met informatie-beveiligingsnormen zoals de NEN 7510. Tools4ever biedt in de meeste gevallen een standaard connector voor het betreffende systeem. Het gebruik van die connector kan exact worden geconfigureerd ten behoeve van jouw specifieke RBAC-invulling.

RBAC met flexkrachten

Extra bronsystemen voor bijvoorbeeld flexkrachten

In de eerdere RBAC best practices ging het nog om eigen medewerkers. Veel organisaties werken echter met inhuurkrachten om de roosters compleet te maken. En ze gebruiken daarvoor tegenwoordig vaak online brokerplatforms waarin het hele inhuurproces is geautomatiseerd, vanaf het zoeken tot het inplannen van inhuurkrachten.

Daarmee ben je er nog niet. Je wilt deze inhuurkrachten volwaardig laten meedraaien en daar horen eigen accounts en toegangsrechten bij. Tegelijk willen veel organisaties die tijdelijke krachten niet opnemen in het HR-systeem. Een oplossing is dan om zo’n online bemiddelingsplatform direct aan je IAM te koppelen als extra bronsysteem. In onderstaand voorbeeld is dat gebeurd bij een zorginstelling die het Elanza bemiddelingsplatform gebruikt:

“We willen inhuurkrachten tijdens een dienst ook toegang geven tot bijvoorbeeld het zorgsysteem, maar wel met exact de juiste rechten. Voorheen organiseerden we dit provisorisch. Een aantal inhuurkrachten die veel diensten draaiden hadden we opgenomen in ons personeelssysteem maar voor anderen was simpelweg geen account beschikbaar. Dan moet je als inhuurkracht een interne collega om hulp vragen waarbij je het risico natuurlijk loopt dat mensen ‘even’ elkaars account gebruiken. Iets dat je uiteraard niet wilt in het kader van je NEN 7510 compliance. De oplossing was de HelloID – Elanza connector. Daarmee functioneert Elanza als een extra bronsysteem voor HelloID. We kunnen nu inhuurkrachten op een vergelijkbare manier als vaste collega’s voorzien van accounts en toegangsrechten.”

Ten behoeve van je RBAC gebruik je dus normaliter de attributen van je HR-systeem om de juiste rechten te verstrekken. Nu is ook het Elanza-platform aangesloten en worden daar de gegevens van een flexwerker en diens roostergegevens doorgegeven aan HelloID om aan de hand van business rules de juiste gegevens te verstrekken. Overigens kan zo’n inhuurkracht voor iedere dienst andere rechten nodig hebben. En dat je buiten de diensten automatisch de toegang wilt blokkeren. Dat is als volgt opgelost:

“De accounts worden natuurlijk niet steeds afgebroken, maar ze zijn buiten de diensten automatisch gedeactiveerd. Dus iemand wordt ingehuurd voor een specifieke dienst op een bepaald tijdstip, voor een specifieke functie en afdeling. Aan de hand van die gegevens zorgt HelloID dat de accounts worden geactiveerd en voorzien van de bijpassende rechten in bijvoorbeeld Nedap ONS. Na de dienst worden de accounts weer gedeactiveerd en de rechten ingetrokken. Bij een volgende dienst worden andere rechten weer ingesteld etc. etc. Een inhuurkracht kan dus bij iedere dienst direct aan de slag, maar tussentijds kan hij of zij niet bij onze systemen komen.”

automatiseren met RBAC

Regie van handmatige processen

We denken bij RBAC allereerst aan het geautomatiseerde beheer van digitale rechten. Toch kun je dit mechanisme ook gebruiken voor de regie van allerlei handmatige werkzaamheden. We geven hier twee voorbeelden.

Uitgifte van fysieke middelen

Afhankelijk van iemands rol binnen een organisatie kan een medewerker bijvoorbeeld ook een laptop, smartphone, toegangspas en bedrijfskleding nodig hebben. De uitgifte hiervan - en ook het intrekken als spullen niet meer nodig zijn - is een ingewikkeld logistiek proces dat vaak wordt beheerd vanuit een IT Service Management systeem zoals TOPdesk. Hierbij kan je IAM-platform voor de regie zorgen. Een zorginstelling vertelde hierover:

“Ook gaan we nog uitgebreider aan de slag met onze TOPdesk koppeling. Straks kan HelloID TOPdesk automatisch instructies geven om aan nieuwe medewerkers – afhankelijk van hun rol – tijdig laptops, smartphones en toegangspasjes te verstrekken. En die ook weer tijdig in te trekken als iemand weggaat of ze niet meer nodig heeft.”

Ook een veiligheidsregio organiseert zo de uitgifte van apparaten en kleding voor bijvoorbeeld brandweermedewerkers. De fysieke uitgifte verloopt naar aanleiding van service tickets die worden verstuurd naar het service management systeem. Je wilt die tickets automatisch verstrekken aan de hand van actuele gebruikersgegevens en gebeurtenissen. Wanneer komt iemand in dienst, of wanneer verlaat een gebruiker de organisatie? Je IAM-platform heeft dat overzicht en beschikt over alle gegevens om de benodigde tickets tijdig ‘in te schieten’.

Eerst je provisioning regisseren, van daaruit automatiseren

Sowieso is het fijn dat je met HelloID je account en rechtenbeheer stapsgewijs kunt automatiseren. Er zijn bijvoorbeeld organisaties waarin het nieuwe IAM-platform eerst primair wordt ingezet voor de regie van hun provisioning proces. Men begint met automatische notificaties vanuit het IAM-platform naar functioneel beheerders. Die notificaties bevatten het verzoek accounts aan te maken en rechten te wijzigen in de betreffende systemen. Pas in een vervolgstap gaat men echt automatiseren. Een zorginstelling vertelde:

“Dit is het groeipad dat we zochten. In eerste instantie gebruiken we HelloID dus vooral om het hele proces beter te regisseren en te bewaken. Vervolgens kunnen we steeds meer doelsystemen aan HelloID gaan koppelen. Dan zijn ook de notificaties niet langer nodig en wordt het beheer van accounts en toegangsrechten volledig geautomatiseerd. Zo plannen we momenteel de uitrol van de nieuwe koppeling tussen HelloID en het Chipsoft HiX Elektronisch Patiëntendossier (EPD). Dus eerst realiseerden we de ‘orchestratie’ van ons accountbeheer en van daaruit groeien we nu door naar volledige automatisering.”

Fysiek toegangsbeheer met je IAM

Met behulp van RBAC kun je ook het fysieke toegangsbeheer beter organiseren. Nu worden toegangspasjes vaak nog apart beheerd door ‘Facilitair Management’ of een vergelijkbare afdeling, met een eigen standalone systeem. En dat is eigenlijk vreemd want het beheer is vergelijkbaar is met je digitale toegangsbeheer. Ook bij gebouwen en ruimtes zal de toegang vaak afhankelijk zijn van iemands functie, afdeling en andere kenmerken.

Om die reden nam een van de veiligheidsregio’s in Nederland hun deurbeleid mee bij het automatiseren van hun account- en toegangsbeheer:

“Uiteraard werken de medewerkers vanuit verschillende locaties, variërend van kantoorlocaties tot brandweerkazernes. Iedere medewerker krijgt een eigen pasje met daarop een geregistreerd profiel dat bepaalt tot welke locaties iemand wel of geen toegang heeft. En ook die toegang beheren we tegenwoordig via HelloID. We gebruikten hiervoor al een beheersysteem, Paxton. Tools4ever heeft op basis van de Paxton API een HelloID koppeling ontwikkeld en daarmee hebben we de toekenning van toegangsprofielen opgenomen binnen HelloID. Dat betekent dat nu iedereen aan de hand van iemands functie, afdeling en contractgegevens kan worden gekoppeld aan het juiste Paxton profiel. Zo houden we het digitale toegangsbeheer en het fysieke toegangsbeheer synchroon.”

Het oorspronkelijke pasjesbeheersysteem blijft dus in gebruik omdat de fysieke pasjes moeten worden geconfigureerd en geactiveerd. Maar IAM heeft de regie over wie welk toegangsprofiel mag ontvangen.

preboarding met RBAC

Tijdelijke rollen voor je preboarding

Veel organisaties zorgen via hun geautomatiseerde provisioning dat nieuwe medewerkers op de dag van onboarding toegang krijgen tot hun systemen. Meestal worden al voor de indiensttreding iemands digitale identiteit en accounts aangemaakt, maar ze worden via business rules daadwerkelijk geactiveerd bij de indiensttreding. Een klant besloot echter nieuwe medewerkers al eerder toegang te geven:

 “Voorheen kregen nieuwe medewerkers pas bij hun onboarding toegang tot de IT-systemen. Echt een spookbeeld want dan is alles nieuw terwijl jij die eerste dag gewoon lekker aan de slag wilt. Dat hebben we nu opgelost en een nieuwe collega krijgt al een maand toegang tot intranet en de systemen. Zo kun je in alle rust kennis maken met de software, collega’s mailen, online trainingen volgen, roostergegevens inkijken en zelfs al roosterverzoeken indienen.

Tot de dag van de onboarding beperken we de rechten nog wel want je mag natuurlijk nog geen cliëntgegevens inzien. Op de dag van de onboarding past HelloID automatisch de instellingen aan en heb je vanaf dan de volledige rechten. Dit is echt een enorme verbetering, het is voor mensen echt veel prettiger om op die manier te kunnen beginnen en het is een win-win want ze zijn ook direct een stuk productiever.”

Dit toont ook het belang van business rules waarin je de contractdatum en andere data gebruiken kan voor je account- en rechtenbeheer. Door die gegevens rechtstreeks te ontvangen van bijvoorbeeld je HR-systeem, kun je alle wijzigingen exact op het juiste moment doorvoeren. Soms precies op het moment van wijziging, maar desgewenst soms ook al enkele weken daarvoor. Ook gebruiken organisaties hiervoor soms tijdelijke rollen met aangepaste rechten, waarna ze op de dag van onboarding worden overgezet naar hun daadwerkelijke functie.

Role mining methode voor RBAC

Role mining als RBAC-tool

Veel organisaties beginnen dus met een afgebakend startscenario met bijvoorbeeld één bron-systeem en de Active Directory als doelapplicatie. Van daaruit groeien ze verder. De vraag is daarbij hoe je een initieel RBAC-model of rollenmodel ontwikkelt, een eerste set business rules die je daarna stapsgewijs kunt verfijnen en uitbreiden.

Meestal is het namelijk ingewikkeld om de bestaande organisatie en processen te vertalen naar zo’n eerste opzet. Daarom ontwikkelden we een role mining aanpak waarbij we een soort reversed engineering gebruiken. Uitgangspunt daarbij is dat je ook bij het eerdere handmatige beheer al zo goed mogelijk hebt geprobeerd de gebruikers te voorzien van de juiste accounts en rechten. Door die bestaande gegevens op een slimme manier opnieuw te gebruiken, bouw je een eerste rollenmodel.

Dat werkt als volgt. Zodra je HelloID hebt gekoppeld aan een paar systemen, kun je de daarin bestaande instellingen uploaden. Deze kun je analyseren en verbanden leggen tussen enerzijds de attributen van gebruikers in het bronsysteem en anderzijds de bestaande gebruikersaccounts en toegangsrechten in doelsystemen.

Zo krijg je inzicht in welke faciliteiten normaliter zijn gekoppeld aan teams, afdelingen of functies. En met dat inzicht kunnen een IT-beheerder en een HR-medewerker samen met een Tools4ever consultant al in één sessie een eerste rollenmodel vormgeven. Een klant vertelde wat dit opleverde:

“We hadden geen vooraf uitgedachte rollen- en rechtenstructuur en maakten ons dus zorgen over hoe we dat moesten aanpakken. Met zo’n role mining sessie combineer je echter de gegevens uit AFAS en al bestaande instellingen in Active Directory. Daaruit kun je een eerste rollenmodel destilleren. Je ziet bijvoorbeeld snel welke groepen gebruikers soortgelijke rechten nodig hebben, en zo een eerste rechtenstructuur vormgeven met een hanteerbare set business rules. Hiermee hebben we al zo’n 70% van alle rechten geautomatiseerd en kunnen we dit gaandeweg verder uitbouwen.”

Tegelijkertijd is dat eerste rollenmodel natuurlijk niet definitief. Je kunt het verder uitbreiden met nieuwe applicaties en de rechtenstructuur verfijnen. En ook veranderen organisaties. Afdelingen worden samengevoegd of juist gesplitst, en nieuwe functies worden gecreëerd. Een rollenmodel is dus een levend geheel dat je regelmatig opnieuw wilt beoordelen en zo nodig aanpassen.

Daarom bouwen we Role Mining functionaliteit nu in binnen de HelloID governance module. Met behulp van patroonherkenning biedt HelloID regulier aanbevelingen voor het optimaliseren van je autorisatiemodel. Hiermee beschik je niet alleen over een role mining tool om een eerste rollenmodel op te stellen. Je kunt dit model vervolgens ook gaandeweg steeds verder verbeteren en optimaliseren.

Meer weten over het gebruik van RBAC binnen HelloID?

In deze blog hebben we verschillende voorbeelden genoemd van hoe bestaande HelloID klanten RBAC en onze business rules inzetten om hun rechtenbeheer zo goed mogelijk in te richten voor de eigen organisatie en wensen. Wil je meer weten over RBAC binnen HelloID, kun je ons webinar terugkijken.

Bekijk het RBAC webinar met live demo

Arnout van der Vorst

Geschreven door:
Arnout van der Vorst

Maak kennis met Arnout van der Vorst, de inspirerende Identity Management Architect bij Tools4ever sinds het jaar 2000. Na zijn studie Hogere Informatica aan de Hogeschool van Utrecht is hij begonnen als Supportmedewerker bij Tools4ever. Daarna heeft Arnout zich opgewerkt tot een sleutelfiguur in het bedrijf. Zijn bijdragen strekken zich uit van klantondersteuning tot strategische pre-sales activiteiten, en hij deelt zijn kennis via webinars en artikelen.