De match tussen RBAC en applicatiebeheer

In de ideale wereld zijn alle bevoegdheden binnen een applicatie een-op-een gekoppeld aan een Role-Based Access Control oplossing (RBAC). Een manager kent zijn nieuwe werknemer met behulp van RBAC dan automatisch de toegang en rechten toe die behoren bij zijn rol. Maar in de praktijk werkt dat vaak anders, omdat applicaties enorm verschillen in volwassenheid en abstractieniveau. In dit blog ga ik dieper in op de praktische koppeling van applicatiebeheer naar RBAC.

Applicaties zijn er groen en rijp en kennen elk hun eigen (business proces) logica en functionaliteit. Voor het toekennen van rechten hebben volwassen applicaties zogeheten applicatierollen. Als een applicatie qua logica en structuur goed doordacht in elkaar zit dan noemen we het een volwassen applicatie. Alle mogelijke functionaliteiten in een applicatie kunnen hiermee worden gedefinieerd als procesrollen die horen bij de bedrijfsprocessen zoals die in een applicatie zijn ingericht. Door applicatierollen te koppelen aan (Azure) active directory groepen of een andere (LDAP) directory, kun je vanuit je RBAC-model direct het toegangsbeheer geautomatiseerd aansturen. Deze automatisering zorgt voor efficiëntie en voorkomt menselijk falen.

Toegangsbeheer zonder applicatierollen

Bij minder volwassen applicaties zijn er geen applicatierollen en is er vaak geen koppeling met (Azure) Active Directory mogelijk. Rechten worden daardoor op het laagste detailniveau handmatig per persoon met vinkjes toegekend. Dat levert voor toegangsbeheer via RBAC een uitdaging op. Medewerkers in de organisatie die het rollenmodel moeten controleren, raken het overzicht kwijt wanneer je voor een (groot) aantal applicaties op dergelijke wijze autorisaties op het laagste detailniveau in het rollenmodel opneemt.

Wanneer in een bedrijfsapplicatie geen rollen kunnen worden gedefinieerd, kan het werken met sjabloongebruikers een oplossing zijn. In plaats van een applicatierol maak je een sjabloongebruiker aan. Een voorbeeld: stel dat ik in het betaalpakket geen rol ‘Invoerder Betaalopdrachten’ kan maken, dan kan ik als alternatief een gebruiker opvoeren met de naam ‘Invoerder Betaalopdrachten’ (daar waar een normale gebruiker bijvoorbeeld Jan de Vries heet). Je koppelt de individuele permissies die horen bij het invoeren van betalingen, aan de gebruiker ‘Invoerder Betaalopdrachten’. In het rollenmodel neem je vervolgens deze sjabloongebruiker op alsof het een applicatierol is.

Bij iedere nieuwe medewerker die betalingen moet gaan invoeren, volgt vanuit het RBAC model dat hij ‘Invoerder Betaalopdrachten’ moet krijgen in de betaalapplicatie. e De beheerder van de betaalapplicatie krijgt  een signaal dat hij een applicatierol ‘Invoerder Betalingen’ moet toekennen. Omdat zijn applicatie geen rollen kent, interpreteert de beheerder dit als: kopieer de rechten van de sjabloongebruiker ‘Invoerder Betalingen’ naar de nieuwe medewerker. Met deze werkwijze kan in principe elke applicatie, on-premise of in de cloud, worden opgenomen in RBAC.

Applicatierollen én extra rechten

Wat ik regelmatig tegenkom, is dat de functionaliteiten van een applicatie gedeeltelijk zijn vastgelegd in applicatierollen. Denk bijvoorbeeld aan een betalingsapplicatie: de rollen invoerder en goedkeurder zijn duidelijk gedefinieerd, maar in een ander menu wordt dit weer verder uitgesplitst per rekeningnummer. Dat onderscheid is dus niet direct gekoppeld aan de applicatierollen.

Aangenomen dat een organisatie dat onderscheid in bevoegdheden niet voor niets maakt, is het wenselijk deze ook in het RBAC model te laten terugkeren. Vervolgens is de vraag hoe je dat efficiënt doet. Het is prima denkbaar om met een hybride oplossing te werken: het ene deel van de applicatie-autorisaties, dat netjes in applicatie-rollen kan worden vastgelegd, kan bijvoorbeeld via Active Directory groepen worden gekoppeld aan het RBAC model, en automatisch worden bestuurd; het andere deel van de autorisaties van dezelfde applicatie wordt zonder Active Directory koppeling vastgelegd in het RBAC model, en kan via een ticket/werkorder mechanisme worden aangestuurd.. Een nieuwe medewerker aanmaken kan dan resulteren in een automatische toekenning van toegang en applicatierollen, via Active Directory, en daarnaast een verzoek (een ticket of werkorder) aan de applicatiebeheerder om extra autorisaties handmatig in te stellen.

Wat zijn je uitgangspunten?

Met RBAC beantwoord je de waarom-vraag: waarom heeft die persoon toegang tot dat systeem of die gegevens? De mate waarin RBAC het volledige beeld weergeeft qua differentiatie in autorisaties binnen een organisatie, is afhankelijk van kosten en security-eisen. Dat verschilt per organisatie. Zijn de risico’s klein, kunnen rechten niet (gemakkelijk) worden opgenomen in applicatie-rollen of levert automatiseren geen kostenbesparing op? Dan kan het acceptabel zijn dat het RBAC-model niet alle fijnmazigheid in systemen weergeeft. Periodieke rapportages door een applicatiebeheerder kunnen dan volstaan. Een Security Officer of rolmanager is bij uitstek de persoon om hierin de applicatiebeheerders te adviseren en samen met hen een passende keuze te maken.

Wilt u meer weten over het HR-systeem als bron voor Identity Management? Bekijk ons webinar direct en gratis terug!