Het IT-landschap blijft veranderen, net als de wet en regelgeving omtrent de Governance over dit landschap. Het implementeren van access controls om te bepalen wie welke rechten(autorisaties) mag hebben op welke systemen kent al vele vormen. De invloed van de huidige wet en regelgeving die onder andere in Nederland wordt opgelegd door de DNB heeft de laatste jaren tot een toenemend aantal Role Based Access Control(RBAC)- implementaties geleid. Niet omdat de DNB dit voorschrijft maar omdat RBAC een middel is om het doel genaamd Compliance te bereiken.
Over deze blogger
Anton is sinds vier jaar Lead Architect Identity Access Governance bij Grabowsky. Daar is hij verantwoordelijk voor de verschillende IAM /IAG-projecten en als trainer in Europa voor de opleidingen van de leading vendor op het gebied van IGA (Identity Governance and Administration). Hiervoor deed hij vier jaar ervaring op als Technisch Consultant bij TNT Pakketservice. Anton studeerde Technische informatica aan de TU Delft.
RBAC biedt namelijk de voordelen om je organisatie te vangen in rollen, zowel de medewerkers als het IT- landschap. Groepen mensen gebaseerd op bijvoorbeeld functies, verantwoordelijkheden, projecten en de daarbij horende autorisaties op de verschillende systemen, kunnen worden gevat in een rol. Dit creëert een extra abstractie laag voor zowel de business als IT. Waarbij de business verantwoordelijk is voor het definiëren van de verschillende rollen binnen de organisatie en IT verantwoordelijk is voor het tot rollen bundelen van functionaliteiten van de specifieke applicaties. Dit leidt tot een vraag en aanbodspel tussen business en IT om te komen tot een geheel rollenmodel waarbij de verschillende actoren verantwoordelijk blijven voor hun eigen domein.
Het klinkt simpel
Dit spel klinkt simpel, maar hoe vang je een organisatie in RBAC? Een vertaling van al bestaande complexe autorisatiematrices leidt al snel tot een even complex rollenmodel. Waarbij autorisatiematrices een vanuit de historie opgebouwde weerspiegeling is van de gewenste situatie, maar vaak niet het evenbeeld is van de werkelijkheid. Een RBAC-project is een uitdaging gezien de veranderende omgeving en verouderde standaarden en dit vraagt om een flexibele aanpak.
Gebruik ik een voetbalmetafoor dan zie ik een rollenbeheerteam als de verdedigers, het RBAC-project team (de specialisten) als de middenvelders en de business en IT-verantwoordelijken voor het definiëren van de rollen als de aanvallers. De tegenstander is de organisatie en het IT-landschap. De verdediging moet in staat zijn om de aanvallen van de veranderde organisatie te pareren, het middenveld controleert de dosering van de changes, bepaalt daarmee de snelheid van het spel en voorziet de voorhoede van kansen om te scoren. Begin dus makkelijk, zorg dat je het spel doorhebt, geef de spitsen een schot voor open doel. Wanneer er gescoord wordt, zal het publiek toenemen en zullen de moeilijkere tegenstanders zich melden. Het team is een geoliede machine geworden die inmiddels zijn mannetje kan staan en wanneer de middenvelders gewisseld worden, zullen de successen niet uitblijven.
Als de voetbalwedstrijd wordt gespeeld met deze opstelling, dan kan het geschetste team weliswaar de wedstrijd winnen, maar zal het ook de competitie winnen? Een wedstrijd is eindig maar de in stand houding van RBAC moet blijvend zijn. Het zou toch veel beter zijn als de organisatie en het IT-landschap meespelen?
Het RBAC projectteam heeft de rol van coach. Ze geven tips en trucks aan de business en IT-verantwoordelijken om de bal te passen naar het middenveld (het midden management). Het middenmanagement wordt ook gecoacht om de bal door te spelen naar de aanvallers: de medewerkers in de organisatie en onder hen ook het rollenbeheerteam. Als RBAC functioneert kan de coach naar huis. Als RBAC niet goed functioneert moet er een nieuwe coach worden gevonden.