RBAC: sleutelrol, beheer en evolutie

Veel organisaties zijn bezig met RBAC in meer of mindere vorm; verkenning, project, implementatie, vulling of beheer. We zien dat dit gestuurd wordt door normen als NEN7510, waarin voornamelijk staat beschreven dat je moet kunnen aantonen waarom iemand een autorisatie nodig heeft en hoe deze tot stand is gekomen. Inmiddels weten we dat RBAC niet een heilige graal is, maar dat veel implementaties stuk lopen door de te grote scope en complexiteit. We combineren RBAC liever met claim-based autorisaties op basis van workflow, waarbij de aanvragen voor extra autorisaties uit de organisatie komen en daar ook worden goedgekeurd en verwerkt.

Bij de implementatie van RBAC gaat het vaak om de vraag: hoe ver moet je gaan? Een goede start is om te beginnen bij de structuur van de organisatie en deze te verdelen in lagen. Als we een grote gemeente in Nederland (+- 7500 medewerkers) analyseren komen we tot de volgende verdeling:
  1. 25 diensten
  2. 100 afdelingen
  3. 250 teams
  4. 500 functies
Bovenstaande gegevens gelden als we per organisatielaag een dekking van 80% willen realiseren. Er zijn immers veel meer dan 500 functies, maar deze zijn niet interessant voor RBAC, we zijn alleen op zoek naar de top 80%.
Op basis van bovenstaande gegevens kunnen we de RBAC matrix wat betreft rollen vullen voor deze 4 organisatielagen, elk item in de organisatielaag is dan een rol. Je kunt je afvragen of het nut heeft om de functie-laag te vullen, want dan heb je het meteen over 500 rollen. Vervolgens gaan we van bovenaf, dus startend bij dienst, invullen welke autorisaties bij elke rol horen. Op deze manier vult het systeem zich dus steeds verder aan.
Wat we echter hierbij missen is een unieke combinatie van een medewerker. We hebben bijvoorbeeld gedefinieerd wat elke medewerker mag bij dienst X en wat alle medewerkers met functie Y mogen, maar we missen op deze manier een medewerker met de combinatie van dienst X en functie Y. Dit noemen we de sleutelrol. Een sleutelrol is dus een virtuele rol die altijd een combinatie is van organisatierollen. Bij de start van een RBAC systeem zijn deze rollen niet gedefinieerd, maar door links te leggen tussen organisatielagen komen deze rollen tot stand. Op deze manier is het mogelijk om licht te beginnen en het RBAC model steeds verder te laten evolueren.
Advertisements
Dit bericht werd geplaatst in Role Based Access Control en getagged met . Maak dit favoriet permalink.

Een reactie op RBAC: sleutelrol, beheer en evolutie

  1. Anonymous zegt:

    Hi Arnout,Complimenten voor je sterk inhoudelijke blogs en http://www.tools4ever.com is ook al zo helder. Dat schept vertrouwen in een degelijke uitvoering! Als systeembeheerder herken ik hoeveel werk het aanmaken van een account kan kosten en de soms gebrekkige informatie die vanuit HR komt. Het klinkt aantrekkelijk om het accountbeheer dichter bij HR en de gebruikers/helpdesk/manager zelf te leggen. Wel vind ik het nogal een stap om een relatief kleine en innovatieve toepassing als UMRA in het hart van het ICT-systeem te plaatsen, gekoppeld aan alle andere systemen. Gaat dat wel goed en blijven die andere systemen probleemloos draaien?Mijn organisatie is denk ik te klein voor UMRA, met 80 medewerkers, 1 HR- en 1 ICT-medewerker en alle applicaties aan de AD gekoppeld. Maar voor grotere organisaties lijkt het me erg interessant.Willem.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s