RBAC Avoiding the Horror and getting past the Hype

Sprekers
Mark van Reijn
Technology Specialist ISM
Novell, Inc.

Gert-Jan de Jong
IT security consultant
Atos Origin

Samenvatting
RBAC kan een grote waarde hebben voor organisaties die een realistische en praktische houding hebben bij de implementatie ervan. De nieuwe Identity Manager Roles Based Provisioning Module integreert het RBAC model met Novell Identity Manager en ondersteunt de toegangsbeheer processen van de organisatie. Deze sessie geeft een visie op RBAC en praktijk ervaringen.

Strekking van de presentatie
Korte inleiding RBAC theorie
Het concept is meer dan 30 jaar oud en heeft zijn achtergrond in het groeperen van systeemtoegangen en functiescheiding. In 1992 is het RBAC model voor het eerst als voorstel ingediend bij NIST om opgenomen te worden als standaard. In 2001 is de huidige standaard geaccepteerd. Het hoofddoel van standaardisatie was het hebben van een referentiemodel en standaard terminologie voor toegangsbeheer.

De basis van RBAC bestaat uit relaties tussen: identiteiten <-> rollen <-> bevoegdheden op objecten. Waarbij een object bepaalde informatie of functionaliteit kan representeren. Hiërarchische RBAC maakt diverse rol <-> rol relaties mogelijk. Een ander belangrijk aspect is de mogelijkheid tot functie scheiding, waarbij 2 soorten te onderscheiden zijn:
- statische functiescheiding
Een identiteit mag niet de bevoegdheden A én B beide toegewezen hebben gekregen.

- dynamische functiescheiding
Een identiteit mag wel de bevoegdheden A en B toegewezen hebben gekregen, maar voor een bepaald soort transactie niet beide gebruiken.

Een aantal veel voorkomende redenen voor het gebruik van RBAC zijn:
- versimpelen van toegangsbeheer

- mogelijkheden voor delegatie van toegangsbeheer

- communicatie tussen business en techniek
De business moet kunnen begrijpen wat toegang op systemen precies inhoudt. Dit kan door bevoegdheden in functionele termen te definiëren en te koppelen aan technische systeemtoegangen.

- rapporteren
Rapportages zijn begrijpelijk voor de business, vanwege de definitie van bevoegdheden in functionele termen.

Novell's referentie model
Novell gebruikt een standaard indeling voor het definiëren en beheren van rollen, bevoegdheden en systeemtoegangen. Dit model ondersteunt de praktische benadering die Novell nastreeft. Het model bestaat uit de volgende onderdelen:
- Business Roles
Rollen in business termen, bijvoorbeeld: administratief medewerker

- IT Roles
Rollen die aansluiten bij de technische architectuur, bijvoorbeeld: financiële applicatie.

- Permission Roles (bevoegdheden)
Specifieke bevoegdheden, bijvoorbeeld: betalingen kunnen doen.

- Entitlements (systeemtoegangen)
Technische benodigdheden, bijvoorbeeld: toegangsrechten op een bepaald bestand, gekoppeld aan een account op het systeem.

RBAC met de Novell's Roles Based Provisioning Module
Het RBAC model is sterk geïntegreerd met identity en access management producten. Deze producten kunnen rollen synchroniseren en bepaalde acties nemen op basis van rollen. In de Designer, Novell's applicatie voor configuratie en ontwikkeling van IAM producten, kunnen de definities van systeemtoegangen (Novell: entitlements) en bevoegdheden (Novell: permission roles) worden gedefinieerd. Een initiële inrichting voor het gehele rollenmodel, inclusief Business Roles is ook te definiëren.

Het toegangsbeheer proces in de organisatie wordt ondersteund door een webapplicatie, de User Application. In deze applicatie zijn mogelijkheden opgenomen voor het toewijzen en intrekken van rollen, het beheren van rollen en het definiëren van functiescheidingsregels. Workflow functionaliteit maakt het mogelijk menselijke interactie op te nemen in het proces, zoals het goedkeuren van aanvragen. Het toewijzen van rollen kan op verschillende manieren, handmatig en automatisch op basis van bepaalde criteria. De mogelijkheden zijn:
- toewijzing van rollen aan (dynamische) groepen
Een identiteit kan automatisch in een groep zijn ingedeeld op basis van een bepaald attribuut of gegeven van de identiteit, denk aan een functienaam of projectgroep. Indien rollen zijn toegewezen aan deze groep, krijgt de identiteit automatisch de rol toegewezen.

- toewijzing van rollen aan containers
Containers volgen vaak een structuur van de organisatie, bijvoorbeeld afdelingen of fysieke locaties. Indien een rol aan een container is toegewezen krijgt iedere identiteit op die locatie of afdeling automatisch de rol toegewezen.

- toewijzing van rollen aan identiteiten
Directe toewijzing aan identiteiten zijn bijvoorbeeld rollen die op aanvraag worden uitgedeeld. Hierdoor worden uitzonderingen op de automatische toewijzingen mogelijk.

Praktijk ervaringen
Vanuit praktijkervaring met toegangsbeheer processen is het volgende driehoek model ontstaan: Roles <-> Rules <-> Approvals

100% Roles
Rollen met bevoegdheden definiëren voor iedere systeemtoegang, geen uitzonderingen.
100% Rules
Als je voldoet aan bepaald criterium, krijg je direct een bepaalde systeemtoegang.
100% Approvals
Alle systeemtoegangen worden uitgedeeld op aanvraag en rechtstreeks toegewezen aan de identiteit.

De ideale situatie ligt in het middelste gebied:
- Maak niet overal rollen voor, houd ze proces gericht.

- Gebruik Rules in het algemeen voor het automatisch toewijzen van rollen, alleen in uitzonderlijke gevallen voor het automatisch toewijzen van systeemtoegangen.

- Alles wat dan niet gedekt is, gaat op aanvraag. Trends in aanvragen kunnen een aanwijzing zijn, dat aanpassing van het rollenmodel benodigd is. Zoals met zoveel zaken is 80/20 regel een acceptabele balans, waarbij 80% van de bevoegdheden automatisch wordt toegewezen en 20% op aanvraag.

Probeer rollen te definiëren in termen van het proces, zodat bij reorganisaties de rollen niet te veel hoeven te wijzigen. Maak een procedure voor uitzonderingen, alles in rollen definiëren is moeilijk te onderhouden. RBAC gaat uit van principle of least privilege, een zeer fijnmazige definitie van rollen, waarbij een identiteit allen toegang heeft tot het noodzakelijke. In praktijk blijkt dat onderscheid nodig is tussen kritische bevoegdheden en niet-kritische bevoegdheden, waarbij de niet-kritische bevoegdheden wat ruimer mogen zijn. De identiteit heeft dan ook toegang tot zaken die niet direct noodzakelijk zijn, maar dit is in het geval van niet-kritische bevoegdheden niet erg. Als laatste dient een organisatie te beseffen dat het beheer van rollen een continu proces is, geen statische inrichting!

Analyse
Het referentiemodel van Novell ziet er logisch uit, maar wat betekent het nu voor het toegangsbeheer proces. Het ziet er nu uit alsof de IT afdeling alle definities maakt en de business alleen maar business roles hoeft te definiëren. In praktijk werkt dit niet, omdat er dan te weinig communicatie tussen business en IT plaatsvindt. De definities van toegang die door IT ter beschikking worden gesteld moeten voldoen aan de behoefte van de business. Morgen zal er nog een sessie plaatsvinden waar het proces besproken zal worden, hopelijk wordt het een en ander dan duidelijker.
Daarnaast lijkt er een vervaging van terminologie te ontstaan. Het NIST model hanteert een duidelijk onderscheid tussen: Role, Permission (bevoegdheid) en Privilege (systeemtoegang). In het Novell referentiemodel wordt Permission als de laagste hiërarchische rol gezien en Privilege zit in een entitlement. Een entitlement is in feite een Rule, waarbij een Privilege wordt toegewezen op basis van een bepaald criterium. Nu wordt entitlement dus ook gebruikt als definitie van Privilege, maar dan zonder criterium voor automatische toewijzing. Volgt u het nog?
Als laatste wil ik ingaan op de fijnmazigheid van het definiëren van rollen en bevoegdheden. Kritisch en niet-kritisch is natuurlijk te simpel gesteld, maar de sprekers zullen bedoelen dat er gekeken moet worden naar het risico behorend bij de betreffende informatie of functionaliteit. Indien het risico hoog is, moeten rollen het principle of least privilege volgen, waarbij nauwkeurige functiescheiding mogelijk wordt. Bij lager risico kunnen definities ruimer worden genomen, wat het beheer en gebruikersgemak ten goede komt. De ondergrens is dus het risico dat de organisatie acceptabel vindt.