Role Based Access Control (RBAC)

Role Based Access Control (RBAC) is een methode voor het inrichten van autorisatiebeheer binnen je organisatie. Je kent hierbij autorisaties niet toe op individuele basis, maar juist op basis van RBAC-rollen. Deze rollen zijn opgebouwd uit afdeling, functie, locatie en kostenplaats van een medewerker binnen je organisatie. Op deze pagina van onze kennisbank lees je alles over RBAC, RBAC-rollen en het toekennen van rechten op basis van deze rollen.

Binnen Identity & Access Management (IAM) kan RBAC een belangrijke rol spelen. Doordat je rechten op basis van RBAC-rollen toekent kan je de rechten die bepaalde groepen gebruikers krijgen in één keer definiëren. Dit scheelt veel tijd, voorkomt dat je individuele gebruikers autorisaties hoeft toe te kennen en gaat menselijke fouten in dit proces tegen. De verschillende RBAC-rollen leg je over het algemeen vast in een zogeheten RBAC-tabel.

RBAC-model

Handig aan RBAC is het gebruik van RBAC-rollen. Deze stellen je in staat om voor een bepaalde groep gebruikers in één keer alle benodigde rechten te definiëren. Als voorbeeld nemen we een medewerker die actief is binnen het financiële team van je organisatie. Voor het uitvoeren van zijn werk moet deze medewerker toegang hebben tot onder meer het CRM-, ERP- en ordersysteem, evenals diverse andere databronnen. Met behulp van RBAC leg je vast dat iedere medewerker die voor jouw financiële afdeling actief is automatisch de hiervoor benodigde rechten krijgt toegewezen.

De werkwijze scheelt je veel tijd. Zo hoef je geen rechten toe te kennen aan individuele gebruikers en weet je zeker dat alle gebruikers over de rechten beschikken die zij nodig hebben voor het uitvoeren van hun werk. Dat geldt echter ook andersom. Vertrekt een financieel medewerker naar een ander bedrijf of krijgt de medewerker binnen je organisatie een andere rol? Dan past RBAC de autorisaties van de gebruikers automatisch aan op zijn of haar nieuwe functie.

In een IAM-oplossing als HelloID leg je deze autorisaties vast in business rules. Prettig, want eenmaal geconfigureerd verloopt het RBAC-proces hierdoor geheel geautomatiseerd. De IAM-oplossing kent op basis van je business rules de juiste rechten toe afhankelijk van de rol die een specifieke gebruiker toegewezen krijgt. Wil je weten hoe dit precies werkt? Bekijk dan onze RBAC pagina. 

De voor- en nadelen van RBAC

RBAC biedt veel voordelen, maar brengt ook enkele aandachtspunten met zich mee.

Voordelen

• Toegangsrechten vereenvoudigen: Zo kan je met behulp van RBAC het beheer van toegangsrechten aanzienlijk vereenvoudigen. Je kent rechten toe op basis van rollen in plaats van individuele gebruikers. Dit scheelt niet alleen tijd, maar dringt ook de kans op menselijke fouten terug.
• Compliance met wet- en regelgeving: Met behulp van RBAC regel je je autorisaties op een gestructureerde, gestandaardiseerde en inzichtelijke wijze in. Belangrijk, onder meer met het oog op compliance met wet- en regelgeving zoals de Algemene verordening gegevensbescherming (AVG). Zo kan je met behulp van RBAC eenvoudig aantonen dat gevoelige gegevens alleen voor bevoegde medewerkers inzichtelijk zijn.

Nadelen

• Complexiteit: De implementatie van RBAC kan relatief complex zijn. Onder meer doordat je alle rollen die binnen je organisatie aanwezig zijn en de bijbehorende verantwoordelijkheden moet definiëren voordat je met RBAC aan de slag kan. Dit proces kan je vereenvoudigen met behulp van role mining, een techniek waarmee je de bestaande autorisaties van medewerkers analyseert en zo tot rollen komt.
• Rollenexplosie: Je kan te maken krijgen met een ‘rollenexplosie’. Het aantal rollen binnen je organisaties neemt in dit geval op explosieve wijze toe. Je loopt hierdoor het risico het beheer vooral te verschuiven van individuele gebruikers naar een wildgroei aan rollen. De beheerlast verschuift hierdoor, maar wordt niet zo zeer minder. Wij adviseren daarom altijd het gebruik van service automation voor het toekennen van onder meer tijdelijke rechten aan gebruikers.

RBAC vs ABAC

Een methode die veel op RBAC lijkt is Attributed Based Access Control (ABAC). Het belangrijkste verschil tussen de tweede methoden is hoe autorisaties worden toegekend. Bij RBAC ken je autorisaties toe op basis van rollen. Deze rollen zijn gebaseerd op afdeling, locatie, functieniveau en werkgerelateerde taken.

Bij ABAC ken je autorisaties juist toe op basis van gebruikerskenmerken, objectkenmerken en soorten uitgevoerde acties. Zo kan je rechten toekennen op basis van gebruiker, waarbij je specifiek kijkt naar de functietitel, gemiddelde taken of het functieniveau voor het vaststellen van het soort werk dat een gebruiker uitvoert. Denk echter ook aan kenmerken van objecten die gebruikers proberen te benaderen. Het kan daarbij onder meer gaan om het soort bestand, de persoon die een bestand heeft gemaakt of de gevoeligheid van een bestand. Ook het moment waarop een gebruiker een bestand probeert te benaderen, zoals de datum en/of het tijdstip, kan bij ABAC bepalend zijn in het toekennen van rechten.

RBAC en ABAC in de praktijk

Een concreet voorbeeld is een zorginstelling, waarbij je artsen toegang wilt geven tot patiëntgegevens. Maak je gebruik van RBAC? Dan kan je op basis van de functie arts toegang geven tot alle patiëntgegevens. Of bijvoorbeeld afhankelijk van een locatie toegang verstrekken tot alle patiëntgegevens gekoppeld aan die specifieke locatie. Je bepaalt je hierbij dan ook in belangrijke mate op statische gegevens.

Maak je gebruik ABAC? Dan kan je meerdere attributen gebruiken, die dynamisch kunnen zijn. Dit betekent bijvoorbeeld dat je artsen toegang kunt gegeven tot patiëntgegevens van patiënten waarmee zij volgens het planningssysteem een directe arts-patiëntrelatie hebben. ABAC maakt het dan ook mogelijk autorisaties nauwkeuriger af te stemmen op de daadwerkelijke behoefte van gebruikers en biedt in dat opzicht meer flexibiliteit dan RBAC.

Role engineering: top-down of bottom-up

Wil je aan de slag met RBAC? Dan begin je met het vaststellen van de rollen die binnen je organisaties aanwezig zijn. Je kunt hierbij kiezen voor twee werkwijzen: top-down en bottom-up. Bij top-down begin je dit proces met de functies binnen je organisatie, terwijl je bij bottom-up juist begint met gebruikersdata. Beide werkwijzen kennen hun eigen voordelen. We zetten de verschillen uiteen.

Top-down

Bij top-down role engineering zoom je in op de bestaande gebruikers en functies die zij vervullen. Je brengt hierbij hun acties nauwkeurig in kaart, en identificeert zo welke applicaties zij veel gebruiken en welke juist niet. Voor het uitvoeren van deze analyse zijn verschillende mogelijkheden. Zo kan je een werknemer een dag lang monitoren en vastleggen van welke applicaties zij gebruik maken. Je kunt er echter ook voor kiezen managers van specifieke afdelingen te interviewen en hen in kaart laten brengen welke applicaties hun teamleden nodig hebben. Denk echter ook aan het betrekken van systemowners, die precies uiteen kunnen zetten welke functies nooit gebruik zouden moeten maken van een specifieke applicatie.

Ongeacht het soort top-down analyse dat je kiest, breng je hiermee in beeld welke applicaties een medewerker in de praktijk gebruikt of zou moeten gebruiken. Dit geeft je bijvoorbeeld de mogelijkheid autorisaties die onnodig zijn toegekend in te trekken. Onder meer belangrijk indien je een least privilege-beleid hanteert.

Bottom-up

Naast een top-down benadering kan je ook kiezen voor een bottom-up analyse. Je kijkt hierbij niet zo zeer naar de functies van gebruikers, maar zoekt naar relaties tussen toegekende rechten en specifieke functies. Blijkt bijvoorbeeld dat alle medewerkers van de financiële afdeling toegang hebben tot het CRM- en ordersysteem? Dan kan dit patroon erop duiden dat deze functie altijd toegang nodig heeft tot deze systemen.

Allerlei tools zijn beschikbaar die je helpen bij het maken van een bottom-up analyse. Een belangrijk aandachtspunt hierbij is de kwaliteit van je data: hoe schoner je data, hoe nauwkeuriger een bottom-up analyse is. Andersom geldt echter ook dat vervuiling in je data gerelateerd tot autorisaties kan leiden tot foutieve conclusies en de kwaliteit van je bottom-up analyse kan aantasten.

Role mining

Een andere interessante optie is role mining, een methode die het beste van top-down en bottom-up role engineering combineert. Het proces bestaat uit verschillende stappen:

• Het inventariseren van bestaande rollen.
• Het in kaart brengen van bestaande rechten(groepen).
• Het ontwerpen van je RBAC-concept.
• Het evalueren van het concept met stakeholders zoals afdelingsmanagers.
• Het opstellen van je eerste baseline versie van het rollenmodel op basis van de resultaten uit bovenstaande stappen.

Role based access control met HelloID

HelloID is een IAM-oplossing die je in belangrijke mate helpt met RBAC. HelloID fungeert als bemiddelaar tussen je bronsysteem zoals een HR-systeem en doelsystemen als Active Directory (AD), Azure AD of Google Workspace.

Zowel voor RBAC als ABAC biedt HelloID uitgebreide ondersteuning. Zo biedt de IAM-oplossing je het beste van twee werelden. Het role mining-proces bestaat bij HelloID uit de volgende stappen:

• Het inventarissen van de rollen.
• Het in kaart brengen van bestaande rechten(groepen).
• Het ontwerpen van een RBAC-concept.
• Een evaluatie van het concept met stakeholders, waaronder afdelingsmanagers.

Deze stappen leiden tot een eerste baseline-versie van het rollenmodel, dat je operationeel kunt toepassen. Dit model kan je vervolgens uitbouwen, regelmatig vernieuwen en actualiseren en aanpassen aan de hand van nieuwe inzichten.

Prettig is dat HelloID je stap voor stap door het role mining-proces heen leidt. Zo kan jij probleemloos en zonder zorgen met RBAC aan de slag en zo de digitale veiligheid van je organisatie naar een hoger niveau tillen. Benieuwd hoe HelloID je bij dit proces kan helpen? Lees dan onze blogpost over het gebruik van slimme role mining, waarin we dieper ingaan op deze methode. Wil je de mogelijkheden zelf in de praktijk ervaren? Boek dan nu een demo!

HelloID Software HelloID Whitepaper