Slimme RBAC: voorkom rollenexplosie

Bij moderne IAM oplossingen lijkt het zogeheten Role Based Access Model (RBAC) vaak de heilige graal. Bij een organisatie van enige omvang is het namelijk ondoenlijk om per medewerker bij te houden welke toegangsrechten nodig zijn. We zoeken daarom een slimme manier om grip te houden op dat rechtenbeheer.

RBAC lost dit op door rechten groepsgewijs toe te kennen aan groepen medewerkers die dezelfde rol hebben en dus dezelfde rechten nodig hebben. Een financieel medewerker krijgt bijvoorbeeld standaard toegang tot de boekhoudsoftware terwijl een IT-collega juist toegang nodig heeft tot specifieke IT-systemen. Zo kun je voor iedere medewerker aan de hand van diens rol automatisch de juiste rechten verstrekken. En krijgt iemand na verloop van tijd een andere rol? Dan zorgt het IAM platform automatisch dat ook de rechten worden bijgewerkt.

Omdat iemands functie of rol altijd nauwkeurig worden geregistreerd in het HR systeem, fungeert dat als een betrouwbaar bronsysteem aan de hand waarvan je de uitgifte van toegangsrechten eenvoudig kunt automatiseren. Zo voorkomen we ook de ongewenste opstapeling van toegangsrechten en worden de accounts van vertrekkend personeel tijdig geblokkeerd. RBAC helpt je daarmee om compliant te blijven met privacy- en informatiebeveiligingsnormen.

Is Role Based Access Control dus de silver bullet voor je rechtenbeheer? Deels, want er is wel een belangrijk aandachtspunt. Als je RBAC te rigide probeert door te voeren, maken we ons rechtenbeheer alsnog nodeloos ingewikkeld; zelfs als we rollen slim structureren met bijvoorbeeld een rollen hiërarchie en subrollen. Er is een slimme en pragmatische RBAC aanpak nodig en die schetsen we in deze blog. Zodat we wél de voordelen van RBAC benutten maar geen last hebben van de beperkingen.

Eigen visie op RBAC

Binnen onze eigen HelloID oplossing maken we ook gebruik van RBAC maar we zorgen wel voor een slimme, wendbare uitvoering. Iedereen heeft namelijk een eigen unieke rol in een organisatie en dat is meestal maar deels vastgelegd in iemands officiële rol. Je moet dus ook rechten kunnen verstrekken op basis van andere attributen. En ook individuele uitzonderingen mogen geen problemen opleveren.

Voorkom rollenexplosie

Vaak wordt RBAC erg strikt gedefinieerd; iedere medewerker heeft een rol en aan iedere rol is een volledige set van toegangsrechten toegekend. Dus weet je iemands officiële rol (of meerdere rollen) in de organisatie, dan weet je ook welke rechten nodig zijn.

In de praktijk vind je zulke ‘sleutelrollen’ eigenlijk alleen rondom de primaire bedrijfsprocessen, de spreekwoordelijke werkvloer. Denk bijvoorbeeld aan het zorgpersoneel in zorginstellingen. Dat zijn medewerkers met een duidelijk afgebakende taakomschrijving die allemaal dezelfde systemen en gegevens gebruiken. In dat geval kun je met RBAC eenvoudig de accounts en gebruikersrechten voor al die medewerkers uitgeven en beheren. En omdat dat ook nog eens een relatief grote groep is, is het rendement van RBAC groot.

Bij veel andere rollen is dat echter een stuk lastiger. Een projectmanager bijvoorbeeld heeft uiteraard wat office apps nodig maar welke faciliteiten hij of zij verder nodig heeft, kan variëren per project. En je hebt junior, medior en senior ontwikkelaars die grotendeels dezelfde systemen gebruiken maar waarbij de meer ervaren collega’s soms net wat meer rechten krijgen. Wil je zulke medewerkers toch allemaal gaan beheren aan de hand van verschillende rollen? Dan dreigt al snel een rollenexplosie, zelfs als je alle rollen goed structureert met bijvoorbeeld een rollen hiërarchie met subrollen. In de praktijk vervang je het oorspronkelijke probleem (complex beheer van rechten) door een ander probleem (beheer van een complexe rollen hiërarchie).

Sowieso kun je twisten over de praktische nut van bijvoorbeeld subrollen.

Zo zegt Arnout onze Identity Mangement Architect: “Ik heb nog nooit iemand ontmoet die dit echt gebruikt. Het voegt niets toe en maakt het alleen maar moeilijker. Hoewel strikte regels het voorschrijven, is het in de realiteit overbodig.”

Van RBAC naar ABAC en slim stapelen

Binnen Tools4ever hanteren we daarom bewust een ‘bredere blik’ op RBAC. Dat begint met de definitie van de term ‘rol’. Binnen HelloID onderkennen we niet alleen afgebakende rollen en functies. We willen ook toegangsrechten koppelen aan bijvoorbeeld iemands afdeling, divisie, werklocatie, competenties of combinaties hiervan. We hanteren dan ook feitelijk niet een puur RBAC maar een zogeheten ABAC model (Attribute Based Access Control).

Daarmee kunnen we onze toegangsrechten veel meer generiek en flexibeler beheren. Zo krijgen medewerkers in veel organisaties – ongeacht hun rol – op de dag van onboarding een mailaccount, office applicaties en internet. Het is dus nodeloos ingewikkeld om deze rechten per rol te gaan beheren. En vervolgens is het ook logisch dat je iedereen die werkzaam is bij de HR afdeling toegang wilt geven tot de HR SharePoint site; de specifieke rol van de medewerker doet er daarbij niet toe. We gaan dus op een slimme manier rechten stapelen. Veel rechten verstrek je dus organisatie-breed of op het niveau van afdelingen, teams of locaties; alleen als rechten echt functie-specifiek zijn, zul je die verstrekken aan de hand van individuele rollen. Feitelijk werken we zo aan een beheersbare rechtenpiramide die je zo eenvoudig mogelijk houdt omdat je rechten zo hoog mogelijk in de organisatie vastlegt en alleen sleutelrollen gebruikt waar dat handig is.

En beheer de ‘excepties’

Bovendien is het ongewenst om ieder toegangsrecht te beheren aan de hand van rollen of andere attributen. Hou ruimte voor individuele verzoeken. In het voorbeeld van een projectmanager varieert de rechtenbehoefte per project en is een deel van de faciliteiten ook alleen maar nodig tijdens het project. Iets soortgelijk geldt voor een IT-ontwikkelaar die een bepaald applicatie nodig heeft voor een ontwikkelopdracht. En ook al heeft een van de business analisten een Adobe licentie nodig, het is zonde om alle analisten standaard zo’n dure licentie te geven.

Accepteer dus dat je een deel van de rechten als maatwerk op aanvraag verstrekt. Het is dan wel belangrijk dat we de bijgaande beheerprocessen goed organiseren. Zo moeten bij de aanvraag automatisch de juiste managers en resource owners zo’n verzoek beoordelen en goedkeuren. Zodat je grip houdt op je rechtenuitgifte, je licentiekosten en compliant blijft.

Realisatie van die RBAC visie?

We ontwikkelden voor HelloID dus een gemengde oplossing waarbij rechten niet alleen aan individuele gebruikersrollen kunnen worden toegewezen, maar ook aan meer algemene attributen zoals iemands afdeling, locatie of competenties. Binnen onze Provisioning Module ondersteunen we dat aan de hand van zogeheten business rules. Vervolgens gebruiken we Service Automation om op een beheersbare en controleerbare manier ook alle individuele rechtenaanvragen af te handelen.

Provisioning: Business rules

We automatiseren de uitgifte en het beheer van toegangsrechten met behulp van business rules. Zo’n business rule is feitelijk een soort beleidsregel die bestaat uit een of meerdere condities en de bijbehorende rechten (permissies). Condities bepalen wanneer en voor welke gebruikers die permissies gelden. Een voorbeeld van een business rule zoals we die in een zorginstelling kunnen configureren:

Als een medewerker de functie ‘Helpende Niveau 4’ heeft (de conditie), krijgt deze standaard een EntraID account + een account met de bijbehorende rol in het Elektronisch Cliënten Dossier (de bijbehorende permissies).

Voor de beheerder is dat denken in beleidsregels een enorm voordeel; je hoeft je niet te verdiepen in de achterliggende technische structuur met rollen, attributen en rechten. Je kunt eenvoudig regels toevoegen die kunnen gelden voor alle gebruikers, specifieke afdelingen, rollen of andere attributen. Het maakt ook niet uit dat er overlap zit tussen verschillende business rules. Dus jij kunt focussen op de beleidsregels en HelloID vertaalt die regels naar een consistente, samenhangende rechtenpiramide. Waarbij role mining functionaliteit helpt om de regels slimmer en eenvoudiger te maken. En ook om je rollenmodel actueel te houden want organisaties wijzigen natuurlijk voortdurend en rolmining helpt om mismatches te herkennen.

Je kunt in deze business rules ook nog aanvullende beleidsregels opnemen. Bijvoorbeeld een regel dat een account voor een nieuwe medewerker één dag voor de on-boarding wordt geactiveerd. Of de eis dat gebruikers pas toegang krijgen tot applicaties nadat ze de terms & conditions hebben geaccepteerd.

Service Automation

Zoals genoemd, moet je de uitzonderingen in je rechtenmodel gewoon handmatig kunnen invullen; de projectshare voor de projectmanager, de adobe licentie voor de businessanalist etc. Onze vuistregel is dat we met business rules ongeveer 80 procent van alle accounts en toegangsrechten kunnen automatiseren.

De overige 20 procent is maatwerk en handel je af met onze Service Automation Module. Dat betekent dat in die individuele gevallen de medewerker – of diens manager – zelf via het self-service portal een aanvraag kan indienen voor een specifieke applicatie of toegangsrecht. Vervolgens wordt de aanvraag verwerkt via geautomatiseerde workflows. Er wordt bijvoorbeeld automatisch gecheckt of de aanvrager voldoet aan de criteria en ook wordt automatisch de relevante resource owners en managers online om goedkeuring gevraagd. Is de aanvraag akkoord dan worden de toegangsrechten automatisch verstrekt. Alle aanvragen worden geregistreerd zodat achteraf alle handelingen traceerbaar zijn voor audits. En ook kan bijvoorbeeld een tijdelijke goedkeuring worden geconfigureerd zodat aanvragen niet onbeperkt geldig blijven.

De voordelen van deze aanpak

Deze aanpak levert behoorlijk wat voordelen op:

• Business rules voorkomen een explosie van rollen en houden ons rechtenbeheer zo eenvoudig mogelijk.
• Business rules werken intuïtief en je kunt je rechtenmodel ook eenvoudig aanpassen.
• Naast de uitgifte of het intrekken van toegangsrechten kun je ook allerlei andere beleidsregels opnemen.
• De volledige aanpak is auditeerbaar, inclusief de afhandeling van individuele rechtenverzoeken.

Meer weten over hoe wij RBAC en Service Automation  gebruiken om eenvoudig jouw rechtenmodel samen te stellen? Check het in onze webinar.