Van RBAC naar ABAC deel 3

De derde blog in een serie over de migratie van Role Based Access Control naar Attribute Based Access Control is een feit. In deel 1 beschreef ik dat RBAC in mijn optiek end-of-life zou moeten zijn en in deel 2 beschreef ik dat migratie gefaseerd kan plaatsvinden, door eerst een vorm van Hybride ABAC toe te passen. Hybride in de zin dat we de federatieve ABAC techniek gebruiken om toegang te krijgen, maar dat het autorisatiemodel nog steeds RBAC is. We doen gewoon alsof een Rol het belangrijste attribuut is. Het doelsysteem begrijpt de rollen in de zin van RBAC, dus aan de applicatiekant eigenlijk niet veel te veranderen. Een inlogfaciliteit is eigenlijk overbodig, want bij federatie krijg je automatisch single sign-on; in de applicatie hoeven geen gebruikers beheerd te worden, dus ook geen wachtwoorden of wachtwoordherstelfunctie. Die gegevens krijgt de applicatie aangeleverd van de ‘Identity Provider’ (geduld, er zijn andere bronnen van attributen, maar we zijn bezig met de migratie, dus die alternatieven komen nog wel aanbod…).

In plaats van te moeten inloggen, krijgt een gebruiker gewoon toegang, zonder account. Dat is even wennen… een gebruiker heeft geen account in een doelsysteem, een gebruiker is geen ‘subject’ (een actor), maar een object (waarvan het systeem alleen maar gegevens vastlegt). Dat is niet alleen wennen voor de gebruikers, maar ook voor ontwikkelaars (he, ik heb geen user table…?) en auditors (he, ik heb geen transactielog per user). Nee, je hebt geen users meer… (komen we vast nog wel op terug, geen zorg…!)

Terug naar de rol. Zoals beschreven in de vorige blogs, is de rol eigenlijk een tegennatuurlijk concept. Een rol lijkt een eenvoudig principe vanuit de optiek van beheer, maar eigenlijk is het een beheergedrocht. Ik ken organisaties waar ‘roleigenaren’ en ‘rollenbeheer’-teams van vele FTE’s bezig zijn met allerhande operationele autorisatiebeheertaken, waarvan vrijwel niemand snapt wat er feitelijk gebeurt. In het merendeel van de gevallen accepteert een ‘Role Owner’ klakkeloos de door autorisatiebeheerders voorgestelde aanpassingen, zonder de implicaties te kunnen doorgronden. Dit geldt overigens ook voor auditors. Tip voor organisaties die een onvoldoende kregen voor hun autorisatiebeheer: vertel de auditor dat je RBAC hanteert en je bent meteen gevrijwaard voor het volgende controletijdvak…

Nogmaals terug naar de rol. Als we de rol even vergeten en de basisvraag omtrent autorisaties opnieuw bekijken, dan zien we dat een proceseigenaar niks geeft om rollen of om geautoriseerde personen. Een proceseigenaar zou kwaliteitseisen willen stellen, zoals:

• Vereist opleidingsniveau
• Vereiste certificering
• Verklaring omtrent Gedrag
• Vereiste ervaring
• Locatie en tijdstip van de dag
• Soort apparaat
• Fraude- en misbruikpreventie

Sommige van deze kenmerken gebruiken we natuurlijk ook in de traditionele ‘RBAC’ wereld. Iemand kan een rol krijgen als hij of zij over een bepaald opleidingsniveau en een VoG beschikt. Maar hoe weet iemand die de rol aan een medewerker toekent dat dan? Het moet ergens zijn vastgelegd. Er moet een registratie van deze kenmerken bestaan. Die bestaat in de meeste organisaties wel. Denk maar aan de P&O of HRM systemen. Daarin ligt vast dat iemand bij indiensttreding een VoG heeft overlegd. Daarin kunnen diploma’s en certificeringen vastgelegd worden. Maar daar hebben we dan wel een probleempunt te pakken. Er zijn diverse bronnen van kenmerken en attributen; de vraag is of we binnen de bestaande processen in organisaties die verschillende bronnen wel hanteren en of we ze op tijd hanteren. Ik durf de stelling met een gerust hart aan dat we dergelijke attributen niet goed beheren.

Als dat dan zo is, hoe zeker zijn we er dan van dat we wel de juiste capaciteiten inzetten om de vereiste kwaliteit te bereiken? Als een attribuut niet meer geldig is, hoe zeker zijn we er dan van dat de persoon die bepaalde autorisaties op grond van dat attribuut heeft gekregen, die autorisaties kwijtraakt als het attribuut is vervallen? Is het autorisatiemechanisme zo dynamisch dat ad-hoc wijzigingen automatisch worden doorgevoerd?

Nee. Nee en nog eens nee, bij traditionele beheerprocessen bestaat die zekerheid niet. En dat is logisch, de bestaande ondersteunende bedrijfsprocessen zijn niet ingericht op het beheer van attributen. P&O/HRM houdt zich bezig met personeelsgegevens, beoordelingen, salarisbetalingen, maar niet met een al dan niet voltooide opleiding. Pas als daar een hoger salaris bij hoort, dan zal die beoordeling een keer plaatsvinden. De proces trigger is dan bijvoorbeeld een verzoek van de medewerker, het is dus hooguit een passief proces, het is niet geschikt voor actuele autorisatieprocessen.

Als we dus aan de geobjectiveerde kwaliteitseisen van de proceseigenaar willen voldoen, dan moeten we die attributen dus ergens anders vandaan halen. Waarom niet vanuit het proces waar die attributen worden beheerd? Opleidingen en certificeringen kun je toch het beste bij het opleidingsinstituut ophalen? Als de proceseigenaar eist dat iemand een CISM certificaat heeft als die persoon een taak wil uitvoeren, dan zou je toch op dat moment bij ISACA moeten kijken of die persoon CISM is? Hoe dynamisch wil je het hebben?

Voor onze migratie van RBAC naar ABAC gaat dat nu te ver, maar het geeft wel richting aan de migratie. We gaan eerst die verdraaide rollen als attributen hanteren, maar vervolgens gaan we die rolinhoud maar eens decomponeren naar kleinere objecten, waarvoor we attributen en attribuutbeheerders kunnen vinden. Eerst binnen onze organisatie en later daarbuiten… Dus iemand heeft een rol debiteurenbeheerder, maar misschien is er ook wel een attribuut ‘datum in dienst’ op grond waarvan we de werkervaring kunnen afleiden. Ja, ik weet dat dat niet alles zegt, maar het is natuurlijk maar een voorbeeld. Het achterliggende idee is om via diverse iteraties de autorities om te zetten van ‘rollen’ naar attributen. En daarmee te komen van een statisch rollenmodel naar een dynamisch op attributen gebaseerd autorisatiemodel. Als we in staat blijken om de autorisatie om beheertaken voor debiteuren af te leiden uit kwantificeerbare attributen en niet meer vanuit de ‘rol’, dan zijn we een heel eind verder.

Maar klein vraagje… hoe weten we waar welk attribuut is te vinden, want, waar registreren we dat allemaal?

Volgende keer gaan we attributen ten behoeve van ABAC beheren in en RBAC omgeving. Ja, spannend

Door: André Koot, Lead IAM en Security consultant bij Nixu Benelux ism cqure.nl kennisplatform