Beheer

Security
grenscontrole

Rollen of attributen?

RBAC en ABAC allebei verre van ideaal

© CC BY-SA 2.0 - Flickr.com MPD01605
20 maart 2020

RBAC en ABAC allebei verre van ideaal

Het op efficiënte, transparante en veilige wijze inrichten en beheren van autorisaties is al decennialang een groot struikelblok voor veel organisaties. In de loop der tijd zijn verschillende methoden ontwikkeld voor autorisatiebeheer, waarvan de bekendste RBAC en ABAC zijn. Maar deze methodes hebben volgens Rob van der Staaij stuk voor stuk hun onvolkomenheden.

Bij role-based access control (RBAC) worden autorisaties gebundeld in rollen, zodat de toegang tot informatiesystemen via het lidmaatschap van een of meer rollen kan worden gefaciliteerd in plaats van op individuele basis. Een RBAC-rol kan worden gedefinieerd als een verzameling autorisaties die wordt vastgesteld aan de hand van bedrijfsprocessen en de hieraan gerelateerde taken, organisatiestructuur en regelgeving. Indien goed opgezet, zou RBAC autorisaties meer transparant en beheersbaar moeten maken.

In de praktijk blijkt de invoering van RBAC uitermate moeizaam en tijdrovend. Zo is er geen consensus over hoe RBAC-rollen moeten worden samengesteld. Voorzichtigheid is geboden bij role mining. Hierbij worden patronen van autorisaties binnen applicaties in kaart gebracht, op basis waarvan rollen worden samengesteld. Afgezien van het feit dat role mining zich beperkt tot één applicatie of applicatiesuite, introduceert deze methode het risico dat ook onterechte autorisaties worden meegenomen. Beter is het om top-down te werk te gaan, waarbij eerst wordt bekeken welke taken ter ondersteuning van de bedrijfsvoering worden uitgevoerd.

Rollen niet koppelen aan functies

Sommigen menen dat RBAC-rollen moeten worden gekoppeld aan functies. Functies en RBAC-rollen verschillen echter wezenlijk. Functies zijn gerelateerd aan competenties, opleidingsniveau, hiërarchische positie en uiteindelijk aan salaris, terwijl RBAC-rollen gerelateerd zijn aan taken en de hiervoor benodigde autorisaties. Functies zijn zelden eenduidig over de autorisaties die iemand nodig heeft. Een bestuursvoorzitter kan dezelfde autorisaties hebben als zijn of haar secretarieel medewerker. We zien niet voor niets dat leidinggevenden vaak liever autorisaties aan een nieuwe medewerker toekennen door deze af te kijken van iemand die dezelfde applicaties gebruikt dan op basis van functie. Een ander verschil is dat iemand doorgaans maar één functie heeft, maar gemakkelijk meer dan één RBAC-rol kan hebben. Iemand kan bijvoorbeeld tegelijkertijd de algemene rol Medewerker Organisatie X en de meer specifieke rol Auditor hebben. Ook heeft iedereen met een vast dienstverband een functie, maar niet iedereen hoeft een RBAC-rol te hebben. RBAC is alleen nodig voor die gebruikersgroepen voor wie de autorisaties vanwege risicomanagement, regelgeving of efficiency op adequate wijze moeten worden ingericht en beheerd. Anders dan functies zijn rollen flexibel. Ze kunnen gemakkelijk worden toegekend en weer ingetrokken, ook tijdens iemands dienstverband. Overigens moet ieder RBAC-model van tijd tot tijd worden aangepast, want de aspecten waar RBAC-rollen op zijn gebaseerd – organisatiestructuur, bedrijfsprocessen, regelgeving – zijn aan verandering onderhevig.

Valkuil

Wie RBAC volledig wil doorvoeren binnen de organisatie, stuit op een van de grootste valkuilen van deze methode. De ervaring leert dat het volledig doorvoeren door het dynamische karakter van organisaties zo goed als onmogelijk is. Los daarvan blijkt het aantal rollen dat nodig is binnen het RBAC-model vaak een vraagstuk. Het antwoord is dat er geen ideaal aantal bestaat. Wel moet het aantal RBAC-rollen werkbaar en overzichtelijk blijven. Een andere uitdaging is dat de RBAC-rollen moeten worden vertaald naar toegangsrechten binnen de applicaties. Dit gebeurt doorgaans met behulp van applicatiegroepen en applicatierollen. Overigens worden applicatierollen door sommige softwareleveranciers RBAC-rollen genoemd, wat oneigenlijk is. RBAC-rollen bevinden zich op het niveau van de business en vormen een abstracte laag tussen de eindgebruikers en het applicatielandschap. Een laatste obstakel dat nog genoemd moet worden, is dat de in de markt beschikbare tooling voor het modelleren en beheren van RBAC-rollen zonder uitzondering tekortkomingen kent. Bijna altijd zijn (soms zelfs zeer) aanzienlijke aanpassingen nodig om de technologie te laten aansluiten op de behoeften van de organisatie. Het lukt leveranciers al jarenlang niet om hun producten te voorzien van de brede functionaliteit en flexibiliteit die in de praktijk nodig zijn.

ABAC net zo complex

Vanwege de ontoereikendheden van RBAC hebben veel organisaties hun blik verlegd naar attribute-based access control (ABAC). ABAC is het verlenen van toegang op basis van het evalueren van attributen ofwel kenmerken. De attributen kunnen worden geassocieerd met alle entiteiten in de ABAC-omgeving, zoals subject (bijvoorbeeld eindgebruiker), object (bijvoorbeeld document), de context (bijvoorbeeld het tijdstip waarop, het type apparaat waarmee of de locatie waarvandaan de toegang nodig is) en ten slotte de autorisaties zelf. De attributen worden als input gebruikt voor regels die worden geraadpleegd op het moment dat een subject om toegang vraagt, en resulteren in het wel of niet toestaan van die toegang.

Op het eerste gezicht voorziet ABAC in meer flexibiliteit dan RBAC. Een groot voordeel is dat de context kan worden meegenomen in het bepalen van toegang, iets wat met RBAC niet goed mogelijk is. Ook kunnen autorisaties op veel gedetailleerdere wijze worden vastgesteld (fine-grained). Als voorbeeld is het mogelijk om de toegang tot een document alleen op een bepaald tijdstip toe te staan en te beperken tot gebruikers met een minimumervaringsniveau. Ten slotte kunnen autorisaties met behulp van ABAC op centrale wijze worden ingericht, buiten de applicaties om (externalization). Applicaties moeten hiervoor dan wel zijn aangepast.

ABAC is door sommigen omarmd als de opvolger van RBAC, maar blijkt inmiddels in complexiteit bepaald niet onder te doen voor RBAC. Om te beginnen is er geen eenduidig begrip van wat ABAC eigenlijk precies behelst. Oorspronkelijk is ABAC gebaseerd op XACML (eXtensible Access Control Markup Language), een verouderde standaard die voorziet in een referentiearchitectuur, een structuur voor het vaststellen van regels alsmede protocollen voor het afhandelen van toegangsaanvragen. Alleen volgens deze standaard is het mogelijk om ABAC in al zijn facetten te implementeren, bijvoorbeeld door autorisaties buiten applicaties om in te richten. Overigens kan ABAC worden gecombineerd met RBAC.

Aan de haal

Vanwege de hypevorming rondom ABAC zijn consultants en andere partijen met het begrip aan de haal gegaan en noemen iedere vorm van autorisatiebeheer ABAC, zodra er op enigerlei wijze attributen in het spel zijn. Het is bijvoorbeeld heel gebruikelijk om bepaalde attributen, bijvoorbeeld de afdeling waarbinnen men werkt, uit een bronsysteem te betrekken als basis voor autorisaties in doelapplicaties, maar dit is geen ABAC. Een ander veel aangehaald voorbeeld is dat waarbij een zogeheten attribute provider voorziet in een bepaald attribuut, bijvoorbeeld leeftijd, zodra een service provider hierom vraagt, bijvoorbeeld wanneer iemand een bepaalde dienst wil afnemen waarvoor een minimumleeftijd geldt. Ook dit is geen ABAC.

Nadelen van ABAC in zijn pure vorm zijn de complexe architectuur, het feit dat applicaties compatibel moeten zijn en de stugge XACML-standaard die op het lastige XML (eXtensible Markup Language) is gebaseerd, al is dit laatste te ondervangen door de XML-specificaties te migreren naar bijvoorbeeld JSON (JavaScript Object Notation). Verder is de in de markt beschikbare technologie voor ABAC zeer schaars.

OAuth en UMA

Hoop gloort er in de vorm van nieuwe standaarden. OAuth en het hiervan afgeleide UMA (User-Managed Access) zijn veelbelovend, vooral omdat ze eenvoudig van structuur zijn. Er is nog weinig ervaring met UMA, maar het aantal OAuth-implementaties groeit flink en de ervaringen zijn tot nu toe overwegend positief. Daarbij moet worden aangetekend dat OAuth vooral relevant is voor webomgevingen en mobiele omgevingen.

Autorisatiebeheer kent grote uitdagingen. Geen van de beschikbare methoden is de haarlemmerolie voor dit complexe vraagstuk. Er moet altijd rekening worden gehouden met maatwerk en vooral met langdurige implementatietrajecten. Ook is het goed om te bedenken dat autorisatiebeheer altijd een gedegen fundament vereist in de vorm van identity governance.

Het advies kan alleen maar zijn om een pragmatische aanpak te hanteren en per situatie te bekijken hoe autorisaties op de meest effectieve en transparante wijze kunnen worden ingericht. Behalve kennis en expertise zijn goede communicatie en een gedeeld begrip bij alle stakeholders belangrijke voorwaarden.

 

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (maartnummer, 2020). Wil je alle artikelen uit dit nummer lezen, klik dan hier voor de inhoudsopgave.

Lees meer over
Lees meer over Beheer OP AG Intelligence
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.