Artikel

Het monster dat RBAC heet

In de wereld van identiteits- en toegangsbeheer komt de term RBAC (Role Based Access Control) steeds vaker voor. Steeds meer organisaties hebben namelijk – deels ingegeven door normeringen – de wens om alle autorisaties in het netwerk op een gestructureerde wijze te beheren en uit te delen. Maar hoe pas je RBAC op een goede manier toe binnen de organisatie?

Valkuilen

Er bestaan een tweetal valkuilen bij organisatie wat betreft het toekennen en ontnemen van autorisaties. Regelmatig wordt bij het toekennen van autorisaties een kopie gemaakt van een collega, ook wel ‘voorbeeldgebruiker’ genoemd. Het risico daarvan is dat de nieuwe medewerker zo onterecht toegang kan krijgen tot bepaalde applicaties en systemen. Daarnaast wordt er te weinig aandacht besteed aan het ontnemen van autorisaties wanneer een kopie wordt gemaakt van een andere medewerker. Het is immers van groter belang dat de medewerker zijn/haar werk kan doen en in eerste instantie niet wat er mogelijk teveel gedaan kan worden. Ingegeven door normeringen en IT-auditors, maar ook gedreven door onnodige licentiekosten voor onder andere Microsoft Visio, Projects en Adobe CS, zien organisaties het belang van op een verantwoorde manier met autorisaties om te gaan. 

Verkeerde aanpak

RBAC is een methode om het autorisatiebeheer binnen een organisatie in te richten. Volgens deze methode worden autorisaties niet op individuele basis toegekend, maar op basis van RBAC-rollen en die rollen zijn weer opgebouwd uit afdeling, functie, locatie en kostenplaats van een medewerker in een organisatie. Hoewel organisaties het belang van RBAC inzien, zijn zij bang voor de implementatie ervan. Onterecht is er een beeld ontstaan dat RBAC heel veel werk op gaat leveren - met name op het gebied van beheer - en dat implementatietrajecten lang en complex zijn.  RBAC wordt gezien als een monster en dat is het resultaat van een verkeerde aanpak van de implementatie.

Verantwoordelijken voor RBAC implementaties hebben de illusie gehad dat 100 procent van de medewerkers in een RBAC-rol te vatten is. Er zijn vaak net zoveel functies als medewerkers binnen een organisatie. Daardoor ontstaat er een eindeloze opsomming van rollen ten opzichte van resources en dat betekent een langdurig proces om alle medewerkers een RBAC-rol toe te kennen. Daarnaast is het de vraag of alles en iedereen wel in RBAC moet. Is RBAC eigenlijk niet alleen nodig voor die gebruikersgroepen voor wie de autorisaties vanuit het oogpunt van risicomanagement, regelgeving of efficiency zorgvuldig moeten worden ingericht? Hoe dan ook: RBAC kan sneller en minder complex. 

RBAC als lego

Het is aan te raden om bij RBAC een bottum-up en gestapelde benadering te hanteren, waarbij eerst een fundament wordt gelegd wat later verder uitgewerkt kan worden. Immers toegang tot bepaalde standaardapplicaties, zoals Microsoft Office en Outlook, geldt voor het grootste deel van de medewerkers. Voor een grote groep medewerkers kunnen autorisaties op organisatieniveau (inloggen, tekstverwerken, e-mail) en afdelingsniveau (toegang tot afdelings-share en –applicaties) meteen worden toegekend. Het is dan van belang om de top vijftig combinaties van afdeling en functie van actieve dienstverbanden te bepalen.

HRM-systeem als basis

Voor het bepalen van de combinaties is het HRM-systeem een prima bron. Dit is een eerste aanzet tot een rollenmodel op organisatieniveau. Een voorbeeld: Een ziekenhuis in Leersum heeft een afdeling Chirurgie waarin de functie Verpleger voorkomt. Op basis van functie, afdeling en locatie uit het HRM-systeem kan de organisatierol worden gecreëerd. Dit is respectievelijk ‘Verpleger’, ‘Verpleger in Leersum’ en ‘Verpleger Chirurgie’. Wanneer ‘Verpleger’ en ‘Chirurgie’ zijn gedefinieerd dan is een verpleger in afdeling chirurgie automatisch ‘Verpleger’ + ‘Chirurgie’ en krijgt hij automatisch de stapeling van de rollen (zie afbeelding bovenaan artikel).

Op deze manier kan zeer eenvoudig ruim 80 procent van de RBAC-tabel worden gevuld. Een groot voordeel hiervan is dat nieuwe medewerkers de eerste dagen alvast aan het werk kunnen en dat er tijd wordt gecreëerd voor het toekennen van specifieke rechten op applicatie- en systeemniveau.  

Een volgende stap is om deze organisatierollen te vertalen naar applicatierollen of systeemrollen, dus de laatste 20 procent van de RBAC-tabel. De basis ligt er en nu wordt er verder gestapeld. Het toekennen van de systeemrollen kan goed uitgevoerd worden door een manager. Hij is tenslotte verantwoordelijk voor de autorisaties van zijn medewerkers, niet de HR-afdeling. Via e-mail notificatie en/of een webformulier wordt via een workflow aan deze juiste manager gevraagd wat de specifieke rechten en applicaties voor de betreffende medewerker moeten zijn. Vervolgens kan RBAC-software vastleggen welke keuzes de manager maakt en deze informatie kan gebruikt worden om lege delen van de RBAC-tabel verder te definiëren om uiteindelijk te komen tot een gevulde RBAC-tabel. Het is dus mogelijk om een leidinggevende alle vertalingen van rollen binnen zijn/haar afdeling te laten beheren met de mogelijkheid tot delegatie naar iemand anders. Of dat een actie van een manager via een workflow resulteert in een notificatie naar een licentiemanager. Op deze manier kan een leidinggevende exact bepalen en beheren wat er binnen zijn/haar afdeling of kostenplaats gebeurt. 

Detailautorisaties

De systeem- en applicatierollen bevatten de detailautorisaties binnen de betreffende applicatie zodat de rol uitgevoerd kan worden. De verantwoordelijkheid voor het daadwerkelijk toegang verschaffen tot het netwerk ligt bij ICT en Functioneel/Technisch Applicatie Beheer. Het is ook mogelijk om dit gedeelte te automatiseren (provisioning) met identity management software. Het voordeel van een RBAC-implementatie via deze manier is de snelheid van de implementatie. 

Daarnaast is het mogelijk om gemakkelijk SoD (Segregation of Duty) te krijgen door bijvoorbeeld bepaalde autorisaties te weigeren bij verboden combinaties van functies en afdelingen. In geval van een reorganisatie is het niet nodig om de gehele RBAC-tabel opnieuw te maken. Slechts het eerste ‘Wie ben je’ gedeelte (zie afbeelding bovenaan artikel) dient aangepast te worden en dat kan eenvoudig in het HRM-systeem. Door het HRM-systeem als basis te nemen en keer op keer te raadplegen, beschikt de manager continu over de meest actuele informatie en een gevulde dashboard met de functie, afdeling, locatie en kostenpost van zijn medewerkers. Een directe koppeling met het HRM-systeem is dus noodzakelijk, omdat dat de bron is van alle informatie. 

RBAC staat op dit moment sterk in de belangstelling bij tal van organisaties, want met deze toegangsmethode kunnen autorisaties efficiënt, transparant en controleerbaar worden ingericht. Het implementeren van RBAC hoeft zeker niet complex te zijn. Het advies is om RBAC op een gestapelde manier te benaderen, waarbij autorisaties op organisatie- en afdelingsniveau automatisch verlopen (via het HRM-systeem) en waarbij gericht wordt op de top vijftig combinaties van functie en afdeling. Op die manier kan 80 procent van de RBAC-tabel zeer snel en eenvoudig worden gevuld. De autorisaties van de overige 20 procent op het gedetailleerde niveau geven organisaties veel hoofdbrekens. Om ook deze 20 procent pragmatisch binnen het RBAC model af te handelen is het advies om de toekenning van autorisaties te laten verlopen via de manager van de betrokken medewerker. Een manager kan de detailautorisaties van de medewerker bepalen en aanpassen.

Piramide

Deze methode is ook te vatten in een piramide. Van boven naar beneden van organisatie (top), via afdeling, locatie, functie naar individu (grondlaag). De piramide wordt ingevuld en op de toplaag (organisatie en locatie) zijn er alleen autorisaties die voor iedereen gelden. Dit gedeelte kan direct ingevuld worden.

Het advies is om in eerste instantie bij afdeling/functie op te houden met invullen. De laatste details zullen altijd ad-hoc via bijvoorbeeld workflow geregeld blijven. Vervolgens kunnen organisaties de piramide verder invullen en daarmee ook de RBAC-tabel.

Door gebruik te maken van het RBAC model verzamelt de organisatie door de tijd heen steeds meer informatie over keuzes en aanpassingen die gemaakt worden met betrekking tot het maken van autorisaties. Via een reviewslag van de security-officer kan deze informatie gebruikt worden om de RBAC tabel verder te verrijken en de 80 procent te laten groeien tot wellicht 100 procent.

Categorie:   
Auteur(s)
afbeelding van tseinen
Tjeerd Seinen
Tools4ever - Technisch Account Manager

Tjeerd Seinen als account manager werkzaam bij Tools4ever in Nederland. Hij beschikt over zowel een technische als commerciële achtergrond en hij is daardoor in staat om kansen in de markt om te zetten in functionaliteiten voor producten en consultancy diensten. Tjeerd heeft meer dan 20 jaar ervaring op het gebied van sales en softwareontwikkeling. Hij studeerde technische informatica aan de Hogeschool van Amsterdam. Daarnaast rondde hij de MBA-opleiding van het NIMBAS in Utrecht met succes af.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.