Heel lang geleden schreef ik op mijn LinkedIn profiel: Role Based Access Control is EOL. En in mijn niet meer zo jeugdige overmoedigheid vertelde ik dat ook tijdens een intake bij een potentiële klant, die mij vroeg hoe ze zo handig mogelijk RBAC zouden kunnen invoeren. Dat is ook nooit een opdracht geworden. 

RBAC is EOL was enigszins een prematuur statement, moet ik toegeven, Role Based Access Control is nog lang niet End-Of-Life. Integendeel, in de praktijk zien we dat de term steeds bekender wordt en dat steeds meer organisaties beginnen met RBAC projecten. Na de financials en overheid zijn nu ook de overige branches zich bewust van de noodzaak om autorisatiebeheer aan te pakken. IAM projecten en RBAC oplossingen worden meer en meer omarmd en natuurlijk zijn de meeste grote informatiesystemen, zoals SAP, EBS, CODA, EXACT, ChipSoft, zelf ook al heel lang geRBAC’d. Voor menig onderneming is RBAC een goede introductiewijze om meer na te gaan denken over autorisaties. En daar kan ik klanten vanzelfsprekend ook mee helpen… ☺

Waarom RBAC?

RBAC is in theorie erg lastig, dit is een link naar de originele NIST publicatie.

Echter ook in de praktijk. Ik zal uitleggen waarom RBAC wel degelijk EOL zou moeten zijn.

Laat ik even beginnen met uitleggen waarom we RBAC gebruiken: beheergemak. Ja, werkelijk, dat is eigenlijk de enige reden. Het is een methode op op een makkelijke manier toegang tot een bestand, een record of een locatie te verlenen aan een persoon en om die toegang ook te beheersen: dus ook weten dat die persoon toegang heeft, kunnen verklaren waarom dat het geval is en of die toegang juist is.

Doordat we het concept van een ‘rol’ gebruiken, kunnen we de directe koppeling van ‘iemand’ aan een ‘autorisatie’ loskoppelen. Dat scheelt enorm veel beheer. Als twee medewerkers dezelfde taken moeten uitvoeren, dan hebben ze natuurlijk dezelfde rechten nodig. Als we ze nu dezelfde rol geven, dan hebben ze dus dezelfde rechten, als tenminste de autorisaties die voor uitvoering van die taken aan die rol nodig zijn, ook zijn gekoppeld. Als iemand anders ook dezelfde rol heeft, dan krijgt die persoon ook dezelfde rechten. Dat is dus echt veel makkelijker dan iedereen afzonderlijk dezelfde rechten te verschaffen, met het risico dat er fouten worden gemaakt, dat functiewisselingen niet of niet goed worden verwerkt en nog veel meer nare problemen.

Het enige waar die rechtstreekse autorisaties goed voor zijn, is het laten zien welke rechten iemand heeft. Dat zie je immers meteen. Niet dat we daardoor veel inzicht krijgen, want interpreteer al die toekenningen maar eens.

Met dat rollenbeheren zijn we er nog niet. Nee, er is namelijk niet sprake van één niveau rol, er zijn verschillende niveaus van rollen. We hebben natuurlijk de rollen in een organisatie. De debiteurenbeheerder, de accountmanmager, de architect. De rollen die feitelijk een verzameling van taken zijn die iemand uitvoert. Een debiteurenbeheerder gebruikt natuurlijk een financieel systeem (alleen het debiteurendeel natuurlijk…), Office365 (het stukje van zijn of haar afdeling wellicht?), het intranet, misschien ook wel een stukje CRM systeem. Daarbij moet een debiteurenbeheerder toegang hebben tot de verkoopadministratie, telebankieren, een grootboek. 

Taken!

Wie bepaalt nu welke taken onze medewerker met de rol debiteurenbeheer heeft? De lijnmanager. En misschien ook een proceseigenaar. Want de lijnmanager wil natuurlijk een optimale bezetting binnen de afdeling, maar de proceseigenaar heeft weer andere eisen, zoals kwalitatief hoogwaardig personeel en functiescheiding. Die beide managers kunnen weleens tegengestelde belangen hebben. Een lijnmanager wil zoveel mogelijk transacties uitvoeren met een volledige bezetting, maar de proceseigenaar wil een kwalitatief hoogwaardig proces.

Er is echter nog een speler van belang: de systeemeigenaar… De lijnmanager kan wel willen dat iemand verschillende taken kan uitvoeren, maar die verzameling taken moet wel in de informatiesystemen op diezelfde manier ondersteund kunnen worden. Wat nou als de in een informatiesysteem ontwikkeld rollenmodel strijdig is met de organisatierol… Komt niet voor? Natuurlijk wel, dat komt overal en elke dag voor.

Autorisaties

Last but not least: welke autorisaties zitten er feitelijk in een rol? Medewerkers in AGSAPAX-IAM-DEB-Linux-WS hebben onder meer toegang tot GRXACZP-LEDG02Q-FileTransfer-RW. Duidelijk? Wie weet of dat goed is? Is deze autorisatie expliciet of impliciet toegekend? Wie zit er in die groep? Is dat juist? Is die autorisatie nog juist en actueel? Is die autorisatie niet te ruim? Wat kosten die rechten wel niet? Wie heeft die rechten toegekend? Wie heeft de autorisatie aan de rol gekoppeld? Heeft iemand dat goedgekeurd? Wie het weet mag het zeggen, want ik kan op grond van deze constatering wel honderd vragen stellen.

 

Genoeg geklaaggezongen. Wat gaan we eraan doen?

Volgende keer gaan we een beetje af van rollen en over op attributen.