Role Based Access Control

Effectief managen van autorisaties is een van de grootste obstakels bij het succesvol inzetten van internet (intranet) technieken op het bedrijfsnetwerk. Toepassen van RBAC levert de extra controle die nodig is. Leon Kuunders legt uit hoe RBAC werkt.

Access Control Lists (ACL's) worden door beheerders bijgehouden per server, met aparte lijsten per gebruikt protocol (bijvoorbeeld FTP en HTTP).

In dit artikel (van de hand van Leon Kuunders) wordt nader ingegaan op RBAC, wat deze methode is, welke problemen er mee kunnen worden opgelost en hoe deze methode ingezet kan worden.

Introductie

In een omgeving waar met geclassificeerde informatie wordt gewerkt (informatie die geheim is en alleen op een need-to-know basis beschikbaar wordt gesteld) voldoet een rechten structuur waarbij permissies via een ACL aan enkele objecten zijn gekoppeld prima. Echter, voor organisaties waar de eigenaar van de informatie niet de eindgebruiker is maar de organisatie, wordt het effectief managen van zo'n ACL onmogelijk.

Een ander nadeel van het rechtstreeks koppelen van ACL's aan objecten is de hoeveelheid mutaties die moeten worden doorgevoerd als een gebruiker van functie verandert, vertrekt, of als er nieuwe medewerkers worden aangenomen. Het risico dat de verkeerde permissies worden toegekend is groot en de controle daarop zeer moeilijk. Voor accountability geen goed nieuws.

De oplossing voor dit probleem heet RBAC: Role Based Access Control. Met deze techniek worden permissies gekoppeld aan rollen en rollen aan gebruikers. Het beheren van zo'n systeem bestaat dus uit het beheren van de rollen (en functies) van gebruikers en het beheren van permissies van rollen.

Role Based Access Control

RBAC is een toegangscontrole mechanisme waarmee:

Complexe permissies worden beschreven

Administratieve fouten tot een minumum worden beperkt

Administratieve lasten worden verlaagd

Een voorbeeld, ontleend aan de Role Based Access Control Workshop 1998.

De drie musketiers (Athos, Porthos en Aramis) hebben toegang tot het paleis, lopen in een mooi uniform en dragen een aantal wapens bij zich. Per musketier worden er dus drie relaties gelegd: één naar de poortwachters van het paleis, één naar de klerenmaker voor het uniform en één naar de wapenopslagplaats zodat de wapens worden uitgereikt (zie figuur e1).

figuur e1

In totaal komt daarbij het aantal relaties op 3 x 3 = 9. Als de vierde musketier geselecteerd is (D'Artagnan), dan moeten ook voor hem weer drie relaties worden aangemaakt. Het total aantal te beheren relaties (ofwel permissies) komt daarmee op 3 x 4 = 12.

Als er wordt gekeken naar de rol (of functie) die deze vier personen vervullen, dan blijkt dat allen de rol van Musketier hebben. Aan deze rol zitten voor alle vier dezelfde permissies gekoppeld: ze mogen in het paleis en de wapenopslagplaats en ze hebben een uniform.

Door de de rol "Musketier" te introduceren en deze te koppelen aan de taken "Paleis", "Uniform" en "Wapens", kunnen het aantal permissies dat moet worden bijgehouden worden gereduceerd van 12 (4 x 3) naar 7 ((4 x 1) + (1 x 3)) (zie figuur e2).

figuur e2

Administratieve lasten

Gewoonlijk is er een directe relatie tussen de beheerkosten en het aantal permissies dat uitgedeeld moet worden per gebruiker. In de meeste organisaties zal het gebruiken van een RBAC dan ook de beheerlasten omlaag laten gaan: het aantal te beheren permissies is lager.

Betrouwbaarheid

Doordat permissies niet meer worden uitgedeeld op persoonsniveau maar zijn gekoppeld aan rollen / functies en de taken die daarbij horen, is het beheren van de permissies eenvoudiger. Doordat minder handelingen hoeven te worden verricht voor het wijzigen ervan is de kans op fouten ook kleiner. Dit heeft een betrouwbaardere autorisatiestructuur tot gevolg.

Uitgangspunten:

1. Een RBAC systeem moet het mogelijk maken rollen, gebruikers en permissies op te slaan in een database.
2. Een gebruiker moet aan meerdere rollen kunnen worden gekoppeld.
3. Het systeem moet het principe van "Separation of Duty" (dit is het principe dat bepaalde taken door minimaal twee personen moeten worden uitgevoerd ter voorkoming van fraude) ondersteunen.
4. Het systeem moet gebaseerd zijn op bestaande technologiën.
5. Het systeem moet overerfbaarheid (inheratance) ondersteunen. /li>
6. Als een gebruiker aan meerdere rollen is gekoppeld en de permissies bij deze rollen conflicteren met elkaar, dan gaat de laagste permissie boven de hoogste (bijvoorbeeld geen toegang gaat voor wel toegang).
7. Het systeem moet alle wijzigingen op en toekennen van rollen vastleggen in een log bestand.
8. Het systeem moet gegroepeerd een overzicht van alle permissies gekoppeld aan een gebruiker kunnen laten zien.
9. Het systeem moet een overzicht van alle gebruikers met een bepaalde permissie (gekoppeld aan een rol) kunnen laten zien.
10. Het systeem moet een beheerders interface hebben voor toevoegen/wijzigen/verwijderen van rollen, permissies en gebruikers en voor het toekennen van permissies aan rollen en rollen aan gebruikers.
11. Een rol moet in staat zijn aan één of meerdere "groepen" op de te beheren systemen te koppelen.
12. ”Gebruikersobjecten” zijn mensen, applicaties, apparaten of functies.

Aanbevelingen:

1. Met rollen worden systeem rechten bedoeld waarop twee criteria van toepassing zijn:
   1. Systemen die functioneel gezien bij elkaar horen zijn in één groep geplaatst..
   2. Permissies die geschikt zijn voor bepaalde gebruikersgroepen zijn samengevoegd.
2. Het modelleren van een RBAC-model kan op drie verschillende manieren:
   1. “Bottom Up” - door de rollen vast te stellen aan de hand van reeds aanwezige groepen en permissies op de te beheren systemen.
   2. “Top Down” - door de rollen vast te stellen aan de hand van een analyse van business processen en andere eisen.
   3. “Hybrid” - door de rollen middels een combinatie van Top Down en Bottom Up methodes vast te stellen.
3. De Top Down benadering is het moeilijkste te implementeren omdat het waarschijnlijk resulteert in een groot aantal wijzigingen op reeds aanwezige groepen en permissies.
4. De Bottom UP benadering is eenvoudiger te implementeren omdat het van het reeds aanwezige groepen en permissies model uitgaat.
5. Meestal is de meest succesvolle aanpak voor modellering de Hybride benadering.
6. Het doel van modelleren is een maximale flexibiliteit te bereiken met een minimum aan administratieve lasten.
7. Het delegeren van beheer op gebruikers, rollen en permissies moet worden meegenomen in het modellerings proces. Een sterk gedecentraliseerd model (met veel gedelegeerde verantwoordelijkheden) kan het beste met de Top Down benadering worden vastgesteld.
8. Vastleggen van rollen met een Top Down benadering zorgt voor het samenvoegen van business processen in organisatie parameters.
9. Een Top Down benadering is alleen succesvol als alle business units zich conformeren aan het systeem.
10. Een Rol wordt normaliter gekoppeld aan een groep op het te beheren systeem.
11. De succesvolle implementatie van een RBAC systeem is afhankelijk van een goede analyse van te verdelen permissies.
12. Een Rol heeft geen zin als er geen permissies mee worden verdeeld.
13. Zorg voor jaarlijkse controle van het model.
14. De beste manier om het model te controleren is met behulp van "what ... if" scenario's en het doorlopen van cases.

Berekening:

Een RBAC systeem levert dus met minder kosten een betrouwbaardere ICT op. De berekening waarmee kan worden bepaald of het inzetten van RBAC een voordeel oplevert staat in figuur e3.
figuur e3

Uiteraard moet ook een RBAC systeem worden beheerd. En dit beheren gebeurt met de DREAM methodiek:

The processes at the foundation of a Role-Based Access Control system – Discovery, Rationalization, Engineering, Administration and Maintenance of the roles we use – are critical in realizing the DREAM of a successful RBAC implementation. Without them, RBAC is no more manageable than a traditional identity-based access control system.