RBAC: Role Based Access Control: wat moeten we er mee?

In de wereld van IDM en IAM (Identity & Access Management) zien we steeds meer de term RBAC naar voren komen en de wens van klanten om alle autorisaties in het netwerk op een gestructureerde manier te beheren en uit te delen. Wat je vaak tegenkomt bij het toekennen van autorisaties is een kopieslag van een collega, ook wel “voorbeeldgebruiker” genoemd. Meestal zie je dan ook dat er niet veel aandacht wordt besteed aan het ontnemen van autorisaties, 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.

We zien echter in deze mentaliteit wel een verandering, deels ingegeven door normeringen (NEN 7510 en NEN 7511) en IT auditors, maar ook door de volwassenheid van de organisatie zelf die bijvoorbeeld inzichtelijk willen hebben waar de licentiekosten voor Microsoft Visio en Project nu vandaan komen en of mogelijk externen hier zwaar op drukken.

Dus: hoe gaan we op een verantwoorde manier om met autorisaties? De eerste stap is om naar de organisatie zelf te kijken en te proberen om een rolmodel van bijvoorbeeld de combinatie van afdeling + functie te maken. Als je naar het HRM systeem kijkt is hier prima uit te halen welke top 50 combinaties van afdeling + functie aan actieve dienstverbanden gekoppeld is. Dit is dan meteen de eerste aanzet tot een organisatie rol-model. Deze rollen kunnen vervolgens vertaald worden op applicatierollen of systeemrollen, welke op hun beurt weer detailautorisaties bevatten. Op zich is een dergelijk schema niet al te ingewikkeld voor te stellen, echter merk je al snel dat het om veel rollen gaat met een zeer grote waaier naar de autorisaties. De echte complexiteit zit hem dan in het beheer van de vertaling van organisatierol naar applicatie/systeemrol, en verder naar autorisatie. Hoe maak je deze vertalingen inzichtelijk, hoe sla je ze op, wie mag deze beheren en wie mag ze eventueel namens wie beheren.

Een voorbeeld:

Stel we nemen een ziekenhuis met een afdeling Chirurgie waarin de functie Verpleger voorkomt. De functie Verpleger is niet uniek en komt ook binnen andere afdelingen voor, dus alleen de functie als rol is niet voldoende. De organisatierol voor een dergelijke medewerker wordt dan:

“Chirurgie-Verpleger”

Stel dat deze rol toegang moet hebben tot de applicaties EZIS, Mirador, UltraGenda, Zamicom, Word, Excel en PowerPoint, dan krijg je dus een vertaling van “Chirurgie-Verpleger” naar applicatierollen voor elke applicatie, bijvoorbeeld:

“Chirurgie-Verpleger” – “EZIS-DossiersRaadplegen”

“Chirurgie-Verpleger” – “EZIS-DossiersWijzigen”

“Chirurgie-Verpleger” – “UltraGenda-AfspraakInboeken”

De applicatierollen bevatten vervolgens weer de detailautorisaties binnen bijvoorbeeld EZIS en UltraGenda zodat de rol uitgevoerd kan worden. Als alle rollen en autorisaties uitgewerkt worden krijg je snel te maken met zeer veel data, en hoe ga je dit netjes beheren?

Mijn mening is dat je moet streven naar zoveel mogelijk gebruik maken van bestaande systemen en bronnen, bijvoorbeeld een HRM systeem. Je kunt uit een dergelijk systeem prima de relatie tussen leidinggevenden, afdelingen en medewerkers halen. Dit is een goed uitgangspunt om het beheer van de vertalingen tussen rollen te beleggen, je kunt dan namelijk een leidinggevende alle vertalingen van rollen binnen zijn/haar afdeling laten beheren met de mogelijkheid tot delegatie naar iemand anders. Op deze manier kan een leidinggevende exact bepalen en beheren wat er binnen zijn/haar afdeling of kostenplaats gebeurt.

Meer weten over de visie van Tools4ever op RBAC en over de oplossingen die we bieden? Neem dan vrijblijvend contact met ons op.

Role Based Access Control – RBAC

• rbac
• iam
• idm
• access management
• nen 7510
• nen 7511