De wat- en wie-vraag van RBAC beantwoorden met CMDB

Bij de inrichting van RBAC komen al snel twee vragen naar voren: welke applicaties zijn er allemaal beschikbaar in een organisatie? En wie is daar precies verantwoordelijk voor? Een configuration management database (CMDB) vormt een handige administratief hulpmiddel om de antwoorden op die vragen vast te leggen.

In een eerder blog gaf ik al tips voor RBAC: een methodiek om toegang te relateren aan de rollen in je organisatie. Met RBAC bundel je de autorisaties van een medewerker op basis van bijvoorbeeld afdeling, functie of activiteit. Daarmee krijgt hij rechten tot bepaalde systemen, applicaties en databases die hij nodig heeft voor de uitvoering van zijn werk.

De wat- en wie-vraag van RBAC

Bij het opstellen en onderhouden van een RBAC-model neem je de actuele autorisaties als uitgangspunt. Welke rechten heeft een medewerker op dit moment? Die rechten en systemen worden opgenomen in het RBAC-model en daarna volgt de verificatie. Bijvoorbeeld: iemand werkt op de inkoopafdeling en heeft toegang tot het betaalsysteem, klopt dat? Er kunnen redenen zijn waarom dat mogelijk niet klopt, zoals historische vervuiling of een foutje van een collega.

We gaan daarom in gesprek met de betreffende lijnmanager van de medewerker en tonen hem een helder en begrijpelijk overzicht van de huidige autorisaties. Dan kan het voorkomen dat ook de lijnmanager niet weet wat een bepaald programma of systeem precies doet, wat je met bepaalde rechten kunt of waarom iemand daar autorisatie toe heeft. Dus voordat je de waarom-vraag van RBAC kan invullen, moet je eerst de wat- en wie-vraag beantwoorden: over welk systeem of applicatie hebben we het? Wie kan mij daar meer over systeem vertellen?

CMDB: wie is er verantwoordelijk voor dat systeem?

Dan begint de zoektocht naar documentatie over dat systeem. Is er iemand die het systeem beheert? Is die persoon ook de eigenaar? Zo niet, aan wie legt de beheerder verantwoording af? De lijnmanager weet vaak de antwoorden daarop niet.

Dit soort informatie is niet alleen nodig voor autorisatiebeheer, maar ondersteunt bijvoorbeeld ook bij inkoop en licentiebeheer, en hoort daarom goed te zijn vastgelegd in het bedrijf. De werkwijze die wij veel tegenkomen heet CMDB. Alhoewel een CMDB voor een kleine organisatie in een Excelsheet past, neemt dit voor grotere bedrijven al snel de vorm aan van een relationele database waarin je hardware en software als objecten kunt administreren. Het is een soort digitale kaartenbak waarin bijvoorbeeld Office 365 als softwarekaart is opgenomen. Hierop staat wie er verantwoordelijk is, wanneer de software is gekocht en wie het dagelijks beheer doet. Je ziet ook op welke pc’s de software allemaal staat, en klik je op een pc, dan ga je naar specifieke hardwarekaart van die pc waarop staat welke andere software er allemaal op is geïnstalleerd.

Voor de inrichting van RBAC is CMDB een ideale tool dat antwoord geeft op de wat- en wie-vraag. Zodat je vervolgens met de lijnmanager in gesprek kan gaan over de waarom-vraag.

Praktijk en systeem matchen

We weten nu op basis van de CMDB welke applicaties en systemen er zijn, wie welk systeem beheert en wie de eigenaren zijn. Daarmee kunnen we naar de vervolgstap: welke autorisaties horen er bij de applicatie, en voor wie binnen de organisatie zijn die autorisaties bedoeld? Niet alleen de lijnmanager heeft een mening over de toegang die zijn medewerker zou moeten hebben, maar ook de eigenaren van applicaties hebben daar als het goed is een mening over. Zoals bij een betalingssysteem bijvoorbeeld, waarvan de afdeling financiën of betalingen de eigenaar is. De afdeling inkoop mag misschien wel betaalopdrachten aanmaken, maar de afdeling financiën behoudt de eindcontrole met het goedkeuren van betalingsopdrachten. De afdeling financiën, als eigenaar, en de lijnmanager van de afdeling inkoop, zullen met elkaar in overleg moeten gaan over de verdeling van verantwoordelijkheden in het inkoopproces. Zij bepalen samen de autorisaties die aan specifieke rollen en medewerkers worden toegekend om dat proces goed te kunnen uitvoeren. Dat maakt van de invulling van RBAC tot een soort onderhandeling tussen lijnmanagers, als ‘eigenaren’ van de (functionele) rollen, en applicatie-eigenaren, met de verantwoordelijkheid voor applicaties en bijbehorende rechten en autorisaties. Dat klinkt overigens een stuk formeler dan het in de praktijk gaat: met de juiste begeleiding vanuit een projectorganisatie zijn dergelijke ‘onderhandelingen’ doorgaans niet meer dan een kort informeel overleg over 1 of 2 A4-tjes en een kop koffie.

De toepassing van CMDB verschilt per organisatie. Stel, een bedrijf maakt gebruik van SQL server en installeert dat op twintig verschillende systemen voor twintig verschillende databases. De softwarekaart zegt SQL Server 2012, maar zijn alle twintig databases op dezelfde manier ingericht? Mag iemand die toegang heeft tot één database ook direct toegang tot de negentien anderen? Of zijn ze verschillend ingericht, met verschillende data die afhankelijk per rol beschikbaar moet zijn? In dat geval is het wellicht slimmer om elke ‘instantie’ van de database als apart object, met z’n eigen unieke eigenschappen op te nemen in de CMDB.

De uitdaging is om praktijk en administratie eenduidig op elkaar te laten aansluiten. CMDB kan enorm goed helpen om RBAC te laten werken. Omgekeerd zien we dat RBAC een goed vehikel kan zijn om CMDB op orde te krijgen.

CMDB en RBAC werken ook samen voor risicobeheer en ITIL

Bij grote bedrijven is het gebruikelijk om RBAC gefaseerd in te voeren. Maar waar begin je eerst? CMDB kan ook hier helpen, omdat het ook is in te zetten voor het waarderen van risico per systeem en applicatie. Zo kun je bijvoorbeeld betalingssystemen een hoge waardering geven die direct in de eerste fase moeten worden opgepakt. Daarnaast kan CMDB ook worden ingezet om allerlei werkprocessen rondom de autorisatie van rechten en rollen goed aan te laten sluiten bij ITIL-processen. Meer daarover in een volgend blog. Kun je niet zo lang wachten? Stuur mij dan een bericht en ik spreek je graag bij in een persoonlijk gesprek.

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