903 Scriptie Hendriks en Pots-Zukik - vurore.nl · 2 Definitie en voorbeelden voor...

Scriptie Vrije

Universiteit Amsterdam Postgraduate IT Audit Opleiding Team 903 Danka Pots-Zukik & Marco Hendriks Definitief

ROLE

BASED

ACCESS

CONTROL Wat is Role Based Access Control en is het te implementeren in het huidige IT landschap van bedrijven?

Scriptie Role Based Access Control

Vrije Universiteit Amsterdam | Inhoudsopgave 2

VOORWOORD

Beste lezer,

U staat op het punt te beginnen met het lezen van onze scriptie die we hebben geschreven ter

afsluiting van de Postgraduate IT Audit Opleiding van de Vrije Universiteit te Amsterdam. Het

onderzoek en schrijven van deze scriptie is het resultaat van een leerzaam en interessant traject.

We willen hier de gelegenheid nemen om een aantal mensen bedanken die ons de

mogelijkheden hebben gegeven onderzoek te doen en het schrijven van de scriptie hebben

ondersteund.

Kees van Hoof, onze scriptiecoördinator van de VU, die veel van zijn tijd beschikbaar aan ons

heeft gesteld en ons altijd heeft voorzien van opbouwende kritieken.

Danny de Corte, onze bedrijfscoördinator, die met raad en daad ons heeft bijgestaan.

De geïnterviewden, die ons in staat hebben gesteld het onderzoek te doen en die in alle openheid

ons te woord hebben gestaan.

Onze partners en kinderen, voor het begrip, de ondersteuning en de hulp tijdens het hele traject.

Veel leesplezier.

Danka Pots-Zukik en Marco Hendriks.

Maarssen en Haarlem, mei 2009

NB. Ondanks dat we in de scriptie logische toegangsbeveiliging uitleggen gaan we ervan uit dat

de lezer basiskennis heeft van logische toegangsbeveiliging, IT in het algemeen en BIV/AO.



0 INHOUDSOPGAVE

0 Inhoudsopgave .......................................................................................................................................................... 3

1 Inleiding ....................................................................................................................................................................... 5

2 Probleemstelling ....................................................................................................................................................... 5

3 Samenvatting .............................................................................................................................................................. 6

4 Logische Toegangsbeveiliging ............................................................................................................................ 8

4.1 Logische Toegangsbeveiliging ................................................................................................................... 8

4.2 LTB-terminologie ............................................................................................................................................ 9

4.3 LTB beleid ....................................................................................................................................................... 10

4.4 LTB model ....................................................................................................................................................... 10

5 Belangrijkste modellen van logische toegangsbeveiliging ................................................................... 11

5.1 Mandatory Access Control (MAC) ......................................................................................................... 11

5.2 Discretionary access control (DAC) ..................................................................................................... 12

5.3 Role Based Access Control (RBAC) ....................................................................................................... 13

6 Role Based Access Control – De modellen .................................................................................................. 17

6.1 Core RBAC (RBAC0) .................................................................................................................................... 17

6.2 Hiërarchisch RBAC (RBAC1) ................................................................................................................... 17

6.3 RBAC met functiescheiding (RBAC2) .................................................................................................. 18

6.4 Hiërarchisch RBAC met functiescheiding (RBAC3) ....................................................................... 21

6.5 Kritische Succes Factoren voor RBAC implementatie .................................................................. 22

7 Conclusie theorie ................................................................................................................................................... 23

8 Role Based Access Control in de praktijk .................................................................................................... 24

8.1 Inleiding ........................................................................................................................................................... 24

8.2 De Bedrijven .................................................................................................................................................. 24

8.2.1 Bedrijf A ................................................................................................................................................. 24

8.2.2 Bedrijf B ................................................................................................................................................. 26

8.2.3 Bedrijf C .................................................................................................................................................. 27

8.2.4 Bedrijf D ................................................................................................................................................. 28



8.2.5 Bedrijf E .................................................................................................................................................. 29

8.2.6 Bedrijf F .................................................................................................................................................. 30

8.2.7 Bedrijf G ................................................................................................................................................. 31

8.2.8 Bedrijf H ................................................................................................................................................. 32

9 Conclusie praktijk .................................................................................................................................................. 33

10 Eindconclusie ..................................................................................................................................................... 34

11 Hoe nu verder? .................................................................................................................................................. 36

11.1 Onze visie ........................................................................................................................................................ 36

11.2 Variaties op RBAC ........................................................................................................................................ 36

11.2.1 Audit Based Access Control ........................................................................................................... 36

11.2.2 Context Based Access Control ....................................................................................................... 37

11.2.3 Claims Based Access Control ......................................................................................................... 37

12 Bijlage A: Literatuurlijst ................................................................................................................................. 39

13 Bijlage B: Interviewverzoek ......................................................................................................................... 40

14 Bijlage C: Gebruikte terminologie .............................................................................................................. 41

14.1 RBAC Administratie .................................................................................................................................... 41

14.2 Identity and access management systemen ..................................................................................... 41

14.3 Automatic provisioning ............................................................................................................................. 41

14.4 Role enginering ............................................................................................................................................. 42

14.5 Datamining ..................................................................................................................................................... 42


Vrije Universiteit Amsterdam | Inleiding 5

1 INLEIDING

De afsluitende opdracht van de Postgraduate IT Audit Opleiding van de Vrije Universiteit is het

voltooien van een afstudeeropdracht. Dit om als student blijk te geven over een voldoende

wetenschappelijk niveau te beschikken om te kunnen afstuderen. Deze afstudeeropdracht heeft

geresulteerd in de afstudeerscriptie die voor u ligt. Deze afstudeerscriptie bestaat uit een

literatuuronderzoek en praktijkonderzoek (interviews met ervaringsdeskundigen). In de

conclusie van deze afstudeerscriptie formuleren we het antwoord op de onderzoeksvraag aan de

hand van de resultaten van ons onderzoek.

2 PROBLEEMSTELLING

Het doel van ons onderzoek is om vast te stellen in welke mate implementatie van RBAC

succesvol dan wel onsuccesvol is geweest. Daarnaast willen wij de grondslagen onderzoeken op

basis waarvan bedrijven al dan niet hebben gekozen voor RBAC. En als laatste willen we

redenen achterhalen waarom een implementatie van RBAC wel of niet gelukt is.

Met ons onderzoek willen wij nagaan welke factoren bijdragen aan, dan wel in de weg staan van,

een succesvolle implementatie en beheer van RBAC. De beantwoording van de probleemstelling

kan mogelijk relevant zijn voor bedrijven die RBAC willen implementeren en kan bedrijven die

RBAC reeds hebben geïmplementeerd helpen in het verbeteren van hun beheer.

Grote bedrijven, zoals banken, hebben veelal een keur aan IT platforms, systemen en applicaties

die beheerd moeten worden. De laatste jaren, o.a. door de Sarbanes-Oxley Act, is er een focus

gekomen op de logische toegangsbeveiliging van deze platforms, systemen en applicaties. Vooral

het juist autoriseren van medewerkers voor applicaties vergt een grote inspanning van de

beheerafdelingen die zich bezig houden met logische toegangsbeveiliging. Eén van de manieren

waarop men het beheer van de logische toegang tot systemen wil vereenvoudigen is RBAC.

RBAC is begin jaren negentig bedacht als antwoord op Mandatory Access Control (MAC) en

Discretionary Access Control (DAC). Het idee erachter is om de user accounts van medewerkers

te koppelen aan rollen en via deze rollen toegang te geven tot platforms, systemen en

applicaties. Voor detail uitleg van RBAC zie paragraaf 6 en voor MAC en DAC zie paragraaf 5.

In het begin van de jaren negentig zag het IT landschap er heel anders uit dan nu. Had een

medewerker in die tijd misschien toegang nodig tot één à twee platforms, systemen of

applicaties, tegenwoordig hebben medewerkers tal van autorisaties nodig op tal van platforms,

systemen en applicaties, elk met zijn eigen technische beperkingen en eigenschappen. Ons

onderzoek wil zich richten op de vraag of de initiële gedachte van RBAC in het huidige IT

landschap nog toepasbaar is.

De onderzoekvraag is:

• Is Role Based Access Control nog toepasbaar in het huidige IT landschap?


Vrije Universiteit Amsterdam | Samenvatting 6

Bovenstaande onderzoeksvraag willen we gedetailleerd beantwoorden d.m.v. de onderstaande

deelvragen:

• Hoe is Role Based Access Control origineel bedoeld of opgezet?

• Op welke manier(en) wordt Role Based Access Control geïmplementeerd?

• Welke overwegingen worden gemaakt ten aanzien van de vraag om Role Based Access

Control te implementeren?

3 SAMENVATTING

RBAC is origineel bedoeld als een model voor logische toegangsbeveiliging (LTB) dat

commerciële bedrijven en overheidsinstellingen zou kunnen ondersteunen, doordat toegang tot

applicaties en informatie op centrale efficiënte manier beheerd kan worden. En daarbij zou

RBAC de restricties van MAC (m.b.t. moeilijke informatieverspreiding) en de tekortkomingen

van DAC (m.b.t. onoverzichtelijk en moeilijk toegangsbeheer) kunnen opvangen.

De belangrijkste kenmerken van het RBAC model zijn:

• RBAC heeft als doel om gebruikers op een centrale efficiënte manier, namelijk via rollen,

te voorzien van de juiste permissies, op basis van need-to-know en/of need-to-have.

• Bij het RBAC model is technisch gezien de organisatie de eigenaar van de gegevens en

deze bepaalt wie toegang krijgt. Dit in tegenstelling tot DAC waar het individuele

gebruiker technisch gezien eigenaar van gegevens is en ook individueel de toegang tot

die gegevens bepaalt.

• Met RBAC worden de gebruikersrechten centraal geadministreerd.

In de theorie worden vier RBAC modellen beschreven. Deze worden gedetailleerd beschreven in

paragraaf 6. Dit zijn:

• RBAC0: Core RBAC;

• RBAC1: Hiërarchisch RBAC;

• RBAC2: RBAC met functiescheiding;

• RBAC3: Hiërarchisch RBAC met functiescheiding.

Ons onderzoek langs acht bedrijven heeft geresulteerd in een inzicht op de manieren hoe Role

Based Access Control (RBAC) in de praktijk is opgezet en wordt gebruikt. Het blijkt dat de

implementatie van RBAC niet gemakkelijk is. Ook blijkt dat van de in theorie beschreven vier

modellen eigenlijk van maar twee modellen gebruik wordt gemaakt. Deze modellen zijn in de

basis ook het eenvoudigste.

Op de onderzoeksvragen kunnen dan de volgende antwoorden formuleren:



Vrije Universiteit Amsterdam | Samenvatting 7

Het onderzoek toont aan dat een volledige implementatie lastig is. We hebben nergens een

eenduidig en centraal beheerd Role Based Access Control systeem aangetroffen.


Role Based Access Control is bedoeld om het beheren van autorisaties te vereenvoudigen. In

tegenstelling tot MAC en DAC, waar autorisaties direct aan een gebruiker worden gekoppeld,

maakt RBAC gebruik van rollen waaraan gebruikers worden gekoppeld.


We zien vooral dat RBAC0 en RBAC2 wordt gebruikt.



Ons onderzoek heeft aangetoond dat de belangrijkste overweging om een RBAC model te

implementeren de onbeheersbaarheid van de bestaande LTB situatie binnen de bedrijven was.

Dit is onder andere gekomen door de decentrale LTB administratie. Daarnaast kwam ook naar

voren dat alternatieven voor RBAC niet zijn onderzocht door de bedrijven. Dit bespreken we

uitgebreid in de praktijk paragraaf 8.


Vrije Universiteit Amsterdam | Logische Toegangsbeveiliging 8

4 LOGISCHE TOEGANGSBEVEILIGING

Computersystemen en applicaties ondersteunen bedrijfsprocessen en eindgebruikers. Sinds de

jaren 70 werden de bedrijven steeds meer afhankelijk van hun IT systemen. Het werd steeds

belangrijker om zorg te dragen dat de vertrouwelijkheid, integriteit en beschikbaarheid, in het

kort de goede werking, van de IT systemen en de bedrijfsgegevens gewaarborgd waren. Eén van

de maatregelen om de goede werking van IT systemen te waarborgen is het opzetten van een

goed logisch toegangsbeveiliging (LTB) proces. Een goede inrichting van de logische

toegangsbeveiliging zal ervoor zorgen dat de gebruikers slechts toegang krijgen tot de computer

systemen en informatie die zij voor vervulling van hun functie nodig hebben.

In deze paragraaf geven we een toelichting op het begrip logische toegangsbeveiliging.

4.1 LOGISCHE TOEGANGSBEVEILIGING

LTB is het geheel van organisatorische, procedurele en technische maatregelen om de toegang

tot de objecten van de informatievoorziening te beheersen, zodanig dat deze overeenkomen met

het daartoe gedefinieerde beleid1.

De organisatorische beheersingsmaatregelen zijn gericht op de organisatiestructuur zoals

arbeidsverdeling en functiescheiding. Bij LTB kan men hierbij denken aan hoe de

gebruikersrechten binnen een organisatie belegd zijn. De procedurele maatregelen betreffen de

procedures voor de realisatie van een adequate en verantwoorde functie-uitoefening binnen de

organisatie. In verband met de LTB zijn de procedures voor toekennen, controleren en afnemen

van gebruikersrechten in de computersystemen belangrijk. De technische

beheersingsmaatregelen bevinden zich in de IT componenten en hebben te maken met software,

zowel applicatie als systeem software. Voorbeelden hiervan zijn security databases die het LTB

beleid technisch afdwingen2 en de logische scheidingen tussen verschillende omgevingen (bijv.

OTAP)3. Het LTB beleid wordt besproken in paragraaf 4.3.

Role Based Access Control (RBAC) is één van de modellen voor de inrichting van de logische

toegangsbeveiliging tot computersystemen en de informatie die zij herbergen. Het RBAC model

staat centraal in deze scriptie en daarom wordt hij uitgebreid beschreven in paragraaf 5.3.

1 Definitie voor LTB van `RBAC onder Controle` van R. Tellegen.

2 Definitie en voorbeelden voor organisatorische, procedurele, en technische maatregelen van `Inleiding EDP-auditing` van Jan van

Praat en Hans Suerink.

3 OTAP staat voor Ontwikkel, Test, Acceptatie en Productie. OTAP geeft het pad aan dat wordt doorlopen tijdens software

ontwikkeling.



4.2 LTB-TERMINOLOGIE

Omdat de terminologie van LTB in deze scriptie gebruikt is, worden in deze paragraaf de termen

m.b.t. LTB uitgelegd.

LTB-terminologie kent de volgende semantische elementen: gebruikers, transactie, objecten,

subjecten, bewerking en permissies. Met deze elementen worden LTB modellen beschreven.

Deze elementen4 zullen hierna gedefinieerd worden.

Gebruiker Iedereen die inlogt in het computersysteem is een gebruiker. Elke

gebruiker heeft een gebruikersaccount die gekoppeld is aan een

natuurlijke persoon. In deze scriptie concentreren we op de

gebruikersorganisatie, daardoor zijn de generieke accounts niet

in beschouwing genomen;

Transactie Een logische interactieve verbinding (bijv. inloggen) tussen de

gebruiker en het computersysteem;

Object Objecten zijn de resources die via het computersysteem

toegankelijk zijn, zoals databases, bestanden, TCP/UDP poorten,

applicaties, geheugensegmenten, printers enz. De toegang tot de

objecten worden beveiligd d.m.v. logische toegangsbeveiliging;

Subject De entiteiten die acties in het computersysteem kunnen uitvoeren

worden subjecten genoemd. In de praktijk is een subject meestal

een proces;

Bewerking

Bewerking is een proces dat wordt aangeroepen door een

gebruiker en betrekking heeft op een object. Voorbeelden hiervan

zijn: uitvoeren van een programma, lezen van een bestand,

toevoegen van een record in de database;

Permissies Permissies (of rechten) bepalen welke bewerkingen subjecten op

objecten kunnen uitvoeren. Een voorbeeld is het recht om

databaserecords te muteren.

4 Definitie voor LTB elementen van ‘RBAC onder Controle’ van R. Tellegen.



4.3 LTB BELEID

De doelstellingen met betrekking tot de LTB van een bedrijf worden in een LTB beleid

opgenomen.

De samenstelling van het LTB beleid is een afgeleide van:

• De aard van de organisatie en haar doelstellingen5;

• Wet- en regelgeving6;

• Risicotolerantie;

• Het IT landschap van het bedrijf.

Dit is de reden dat LTB beleid sterk kan verschillen tussen organisaties.

4.4 LTB MODEL

In het LTB model wordt het LTB beleid vertaald naar regels die door de toegangsbeheer

mechanismen van de onderliggende systemen ondersteund worden. De drie meest op brede schaal erkende LTB modellen zijn Discretionary Access Control (DAC), Mandatory Access Control (MAC) en Role Based Access Control (RBAC). In de volgende paragraaf worden de hiervoor genoemde LTB modellen uitgebreid beschreven.

5 Bij voorbeeld het LTB beleid van een Ministerie van Defensie zal sterk verschillen van het LTB beleid van een bank.

6 Voorbeelden van dergelijke weten regelgevingen zijn: privacywetgeving en Wet computercriminaliteit. Voor de financiële wereld

zijn de bepalingen van De Nederlandsche Bank ook van belang.


Vrije Universiteit Amsterdam | Belangrijkste modellen van logische

toegangsbeveiliging

11

5 BELANGRIJKSTE MODELLEN VAN LOGISCHE

TOEGANGSBEVEILIGING

In deze paragraaf en paragraaf 6 worden de eerste deelvraag, gesteld in paragraaf 2, beantwoord

aan de hand van de resultaten van ons onderzoek. Deze deelvraag is:


Voorafgaand aan de ontwikkeling, en de NIST formalisering7, van RBAC in het begin van de jaren

90, werden MAC en DAC beschouwd als de enige formele modellen voor LTB. Het Amerikaanse

Department of Defence (DoD) publiceerde in 1983 het boek ‘Trusted Computer System

Evaluation Criteria’ (TCSEC)8 als resultaat van een uitgebreid onderzoek naar LTB. In de TCSEC

zijn twee LTB modellen gedefinieerd, te weten Mandatory Access Control (MAC) en

Discretionary Access Control (DAC).

In deze paragraaf geven we een theoretische beschrijving van MAC, DAC en RBAC. Verder geven

we de verschillen tussen deze modellen aan.

5.1 MANDATORY ACCESS CONTROL (MAC)

De definitie van TCSEC voor MAC is:

“A means of restricting access to objects based on the sensitivity (as represented by a label) of the

information contained in the objects and the formal authorization (i.e., clearance) of subjects to

access information of such sensitivity.”

De hoofddoelstelling van MAC is beschermen van de vertrouwelijkheid van informatie

opgeslagen in computersystemen. MAC zorgt er primair voor dat informatie met een hoog

vertrouwelijkheidniveau niet wordt vrijgegeven aan een gebruiker met een laag

vertrouwelijkheidniveau. Dit is een zeer strikte manier van logische toegangsbeveiliging en

weinig flexibel.

Bij het MAC model is de organisatie technisch gezien eigenaar van de gegevens. De organisatie

bepaalt wie toegang tot de gegevens krijgt. Dit in tegenstelling tot DAC waar het individuele

gebruiker technisch gezien eigenaar van gegevens is en ook individueel de toegang tot die

gegevens bepaalt. MAC maakt gebruik van een hiërarchisch model. Met MAC wordt LTB centraal

geadministreerd.

Het Amerikaanse DoD gebruikte MAC als LTB model. Het MAC model werd beschouwd als een

passend LTB model voor de militaire organisaties, vanwege het strikt hiërarchische karakter van

dergelijke organisaties. Commerciële bedrijven en overheidsinstellingen gebruikten dit model

niet, omdat het strikte toegangsbeveiliging mechanisme minder geschikt is voor commerciële 7 Role based access control is in 1992 geformaliseerd door David Ferraiolo and Rick Kuhn.

8 Trusted Computer System Evaluation Criteria (TCSEC), ook ‘Orange Book’ genoemd, DoD 1983.



toegangsbeveiliging

12

bedrijven en overheidsinstellingen. Dit omdat bij commerciële bedrijven en

overheidsinstellingen informatie vaak moet worden gedeeld en verspreidt over de diverse

organisatielagen heen. Dit wordt door de controle op vertrouwelijkheidniveau binnen MAC niet

toegestaan. Daarom werd bij commerciële bedrijven en overheidsinstellingen vaker het DAC

model als LTB model gebruikt.

5.2 DISCRETIONARY ACCESS CONTROL (DAC)

De hoofddoelstelling van DAC is om het verspreiden en delen van informatie eenvoudiger te

maken. Dit in tegenstelling tot MAC, waarin het rigide toegangsbeveiliging mechanisme de

informatieverspreiding moeilijk maakt.

De definitie van TCSEC voor DAC is:

“A means of restricting access to objects based on the identity of subjects and/or groups to which

they belong. The controls are discretionary in the sense that a subject with a certain access

permission is capable of passing that permission (perhaps indirectly) on to any other subject

(unless restrained by mandatory access control)”.

Terwijl MAC werd beschouwd als een passend LTB model voor militaire organisaties, werd DAC

meer geschikt bevonden voor commerciële bedrijven en overheidsinstellingen. Dit omdat de

eisen ten aanzien van het delen en verspreiden van informatie minder strikt waren.

Bij het DAC model is de individuele gebruiker technisch gezien eigenaar van de gegevens. De

individuele gebruiker bepaalt wie toegang tot de gegevens krijgt. De administratie van de

rechten van gebruikers gebeurt decentraal. Dit in tegenstelling tot MAC waar de organisatie

technisch gezien de eigenaar van de gegevens is en de toegang tot die gegevens bepaalt. Verder

gebeurt het administreren van de gebruikersrechten bij MAC centraal.

Bij een beperkt aantal platforms, informatiesystemen en gebruikers is het decentraal beheren

van gebruikersrechten in principe geen probleem. Wanneer het echter om een grote hoeveelheid

platforms, informatiesystemen en gebruikers gaat, dan leidt decentraal beheer van

gebruikersrechten al snel tot een onoverzichtelijke ‘spaghetti’ van toegang en rechten9. Hierdoor

wordt de logische toegangsbeveiliging onbeheersbaar (zie Figuur 1).

9 Voorbeeld: bij een financiële instelling werken meer dan 25000 medewerkers, die gebruik maken van een grote diversiteit aan

platforms, informatiesystemen en applicaties, zie paragraaf 8.2.



toegangsbeveiliging

13

Figuur 1 Decentraal toegangsbeheer bij DAC – ‘spaghetti’ van toegangen en permissies (rechten) die onoverzichtelijk en moeilijk beheerbaar zijn.

Met DAC hebben de commerciële bedrijven en overheidsinstellingen dus een LTB model dat het

verspreiden en delen van informatie makkelijker maakt. Maar naast het delen van informatie is

de vertrouwelijkheid en integriteit van die informatie ook voor commerciële bedrijven en

overheidsinstellingen van groot belang. Bij DAC is de vrijheid van individuele gebruikers om

rechten toe te kennen aan andere gebruikers tegenstrijdig met het beheersen van de

vertrouwelijkheid en integriteit van informatie. En omdat MAC een te rigide LTB model was, is

Role Based Access Control (RBAC) ontstaan. Hierover meer in de volgende paragraaf.

5.3 ROLE BASED ACCESS CONTROL (RBAC)

Het concept van RBAC is ontstaan met het eerste commerciële gebruik van de multi-user en

multi-applicatie on-line systemen die in de jaren 70 van start zijn gegaan. Het onderzoek van

David Ferraiolo en Richard Kuhn10, van begin jaren 90, toonde (voor het eerst) aan dat de

overtuiging dat DAC geschikt is voor commerciële bedrijven en overheidsinstellingen ongegrond

en ongepast was. Toen is RBAC als een formele LTB oplossing voor de business applicaties van

de commerciële bedrijven ontstaan en door het National Institute of Standards and Technology

(NIST) erkend11.

10 David Ferraiolo and D. Richard Kuhn (National Institute of Standards and Technology), Role-Based Access Controls (ABSTRACT),

15th National Computer Security Conference (1992), Baltimore MD.

11 Het Ferraiolo-Kuhn model is in 2000 geïntegreerd met het framework van Sandhu. Dit geïntegreerde RBAC model is gepubliceerd

als NIST RBAC model (Sandhu, Ferraiolo, and Kuhn, 2000). In 2004 werd dit model geadopteerd als ANSI/INCITS standaard.



toegangsbeveiliging

14

De definitie van Samarati en di Vimercati12 van RBAC is:

“Control access depending on the roles that users have within the system and on rules stating what

accesses are allowed to users in given roles.”

RBAC is ontstaan als LTB model om de voordelen van MAC en DAC te benutten en de

tekortkomingen van beide LTB modellen op te vangen. Met RBAC wilde men de

gebruikersrechten centraal beheren, waardoor de integriteit en vertrouwelijkheid beter kon

worden gewaarborgd, en tevens flexibel zijn door de invoering van autorisatierollen. Via deze

autorisatierollen worden gebruikers voorzien van de juiste rechten op basis van need-to-know

of need-to-have13.

De theoretische kenmerken van RBAC model zijn:

• RBAC is geschikt voor gebruik als een LTB model voor de commerciële bedrijven en

overheidsinstellingen. Zodoende wordt in het RBAC model het LTB beleid van

commerciële bedrijven en overheidsinstellingen vertaald naar regels die door de

toegangsbeheer mechanismen van de onderliggende systemen ondersteund worden.

• RBAC heeft als doel om gebruikers op een centrale efficiënte manier, namelijk via rollen,

te voorzien van de juiste permissies, op basis van need-to-know of need-to-have.

• Bij het RBAC model is technisch gezien de organisatie de eigenaar van de gegevens en

deze bepaalt wie toegang krijgt.

• Met RBAC wordt LTB centraal geadministreerd.

Hiermee worden de volgende tekortkomingen van MAC en DAC opgevangen, te weten:

1. Het te strikte toegangsbeveiliging mechanisme van MAC (dat minder geschikt is voor

commerciële bedrijven en overheidsinstellingen);

2. Onoverzichtelijk beheer van gebruikersrechten in het geval van DAC.

Bij het RBAC is, net als bij MAC, de organisatie technisch gezien de eigenaar van de gegevens. De

organisatie bepaalt wie toegang tot de gegevens krijgt. Dit in tegenstelling tot DAC waar het

individuele gebruiker technisch gezien eigenaar van gegevens is en ook individueel de toegang

tot die gegevens bepaalt. Met RBAC worden de gebruikersrechten centraal geadministreerd.

12 Pierangela Samarati and Sabrina de Capitani di Vimercati, Access Control: Policies, Models and Mechanisms, Lecture Notes in

Computer Science, Volume 2171 (2001).

13 Dit is het least-privilege beveiligingsprincipe. De implementatie van dit principe is een belangrijke beveiligingsmaatregel voor de

waarborging van de integriteit van de gegevens in informatiesystemen.



toegangsbeveiliging

15

Figuur 2 De tekortkoming van het DAC model m.b.t. onoverzichtelijk en moeilijk beheerbaar toegangsbeheer kan opgelost worden met het RBAC LTB model.

Het RBAC model bestaat uit een dynamisch en een statisch deel (zie Figuur 3). Het dynamische

deel bestaat uit het toekennen, wijzigen en intrekken van rollen aan gebruikers. Het statische

gedeelte bestaat uit het toekennen van autorisaties aan rollen (zie Figuur 3). RBAC gaat ervan uit

dat de autorisaties van rollen niet of nauwelijks wijzigen, maar dat het verloop bij gebruikers, en

dus de mutatiegraad, veel hoger is.

Figuur 3 De permissies van een Rol binnen een systeem blijven vrij statisch in tegenstelling tot het verlenen en het intrekken van lidmaatschappen aan de reeks gespecificeerde genoemde rollen binnen het systeem.



toegangsbeveiliging

16

De literatuur14 beschrijft enkele voordelen die het RBAC model kan opleveren ten opzichte van

andere modellen voor logische toegangsbeveiliging:

• Efficiënter, simpeler en goedkoper logisch toegangsbeheer;

• Makkelijker beheer van gebruikersrechten door invoering van rollen. Aan de nieuwe

medewerkers worden bestaande rollen toegewezen. Bij functieverandering wordt het

gebruikerslidmaatschap van de ene rol verwijderd en de gebruiker wordt lid van een

andere rol. Als de medewerker het bedrijf verlaat dan worden de lidmaatschappen van

alle rollen geschrapt;

• Makkelijker wijzigen van rechten van een bepaalde rol. Bij wijziging van rechten voor

een groep gebruikers die dezelfde rol hebben, hoeft alleen de autorisatie van de rol te

worden aangepast. Dit in tegenstelling tot MAC en DAC waarbij de autorisaties direct

worden gekoppeld aan een gebruiker. Bij wijziging van rechten voor een groep

gebruikers zal dan de autorisatie voor elke gebruiker afzonderlijk moeten worden

aangepast;

• Mogelijkheden voor geheel of gedeeltelijk outsourcing van toegangsbeheer;

• Met de implementatie van RBAC kunnen de beveiligingsprincipes als ‘least privilege’ en

functiescheiding worden bekrachtigd.

14 Michael P. Gallaher, Ph.D., Alan C. O’Connor, B.A., Brian Kropp, Ph.D., The Economic Impact of Role-Based Access Control, NIST,

March 2002; en Healthcare Role-Based Access Control Task Force Charter, Developed For: The Healthcare RBAC Task Force,

Developed by: Science Applications International Corporation 22 July 2003


Vrije Universiteit Amsterdam | Role Based Access Control – De modellen 17

6 ROLE BASED ACCESS CONTROL – DE MODELLEN

In deze paragraaf beschrijven we de diverse RBAC modellen die in de literatuur zijn beschreven.

Aan het einde van de paragraaf geven we de Kritische Succes Factoren voor een succesvolle

RBAC implementatie gedefinieerd uit de theorie. En als laatste geven we onze conclusie als

resultaat van het theoretisch onderzoek naar RBAC. In de literatuur zijn vier RBAC modellen

beschreven. Hier volgt de beschrijving van die vier RBAC modellen.

6.1 CORE RBAC (RBAC0)

Het eerste model van RBAC is Core RBAC (wordt ook RBAC0, Flat RBAC of Basis RBAC

genoemd). RBAC0 bevat de basis aspecten van het RBAC model. RBAC0 houdt in dat gebruikers

aan rollen gekoppeld worden en dat aan de rollen autorisaties worden toegekend. In Figuur 4

geeft RBAC0 weer.

Figuur 4 Afbeelding van RBAC0

RBAC0 bevat dezelfde elementen als het klassieke LTB model (zie paragraaf 4) met de

toevoeging van het element ‘rol’. Het element ‘rol’ is hierbij de logische representatie van het

takenpakket van de gebruiker die volgens het principe need-to-know en/of need-to-have voor

de gebruiker beschikbaar moet zijn.

6.2 HIËRARCHISCH RBAC (RBAC1)

Met RBAC1 wordt het principe van overerving van autorisaties ingevoerd. Overerving van

autorisaties is dat een hiërarchisch hogere rol automatisch de autorisaties van een hiërarchisch

lagere rol krijgt zonder dat aan de hiërarchisch hogere rol de autorisaties direct worden

toegewezen. Dit omdat verschillende rollen deels dezelfde autorisatie kunnen hebben. In veel

organisaties moet bepaalde informatie en applicaties voor alle medewerkers benodigd zijn. Deze



basisset aan autorisatie kan dan worden vastgelegd in een basisrol. En de autorisatie van deze

basisrol zal worden overgeërfd naar alle bovenliggende rollen. Met RBAC1 wordt dus

voorkomen dat een basisset van autorisaties voor elke rol gedefinieerd moet worden.

Het komt ook voor dat naar mate een gebruiker een hogere positie in de organisatie bekleedt

zijn autorisaties toenemen. In dit geval kan ook gebruik worden gemaakt van hiërarchische

rolstructuren en overerving van autorisaties. Bijvoorbeeld een senior medewerker krijgt, naast

specifieke autorisaties gedefinieerd in de senior rol, ook automatisch via overerving de

autorisaties gedefinieerd in de junior rol.

Hiërarchische rolstructuren kunnen worden gevormd op basis van een formele positie

(senioriteit), specialisme, regionale structuren, enz. Verder kennen hiërarchische rolstructuren

verschillende logische structuren zoals een boomstructuur (‘tree’)

Als voorbeeld leggen de logische boomstructuur hieronder uit (zie Figuur 5). De senior rollen

zijn in het bovenste deel van de boom geplaatst. De junior rollen zitten in het onderste deel van

de boom. Alle medewerkers van de afdeling boekhouding hebben de autorisaties van de rol

‘Boekhouding’ (R0). De hoger geplaatste rol ‘Debiteuren’ (R1) heeft daarmee naast de

autorisaties voor de rol R1 ook de autorisaties voor de rol R0. De rol R1 erft hiermee de

autorisaties van de rol R0. En op dezelfde manier erven de rollen R2 en R3 weer de autorisaties

van de rol R1. En de rol R4 weer de autorisatie van de rol R3. Enzovoort.

Figuur 5 Voorbeeld van rol hiërarchieën in een boom structuur

6.3 RBAC MET FUNCTIESCHEIDING (RBAC2)

RBAC2 ondersteunt de statische en dynamische functiescheiding. Met RBAC2 kan een

organisatie voorkomen dat conflicterende rollen aan één gebruiker worden toegewezen. Dit is



statische functiescheiding (SFS). Volgens de theorie kan RBAC2 ook dynamische

functiescheiding (DFS) ondersteunen. Hierover later meer.

Conflicterende (onverenigbare) rollen zijn rollen die via de controletechnische functiescheiding

gescheiden zouden moeten zijn. Volgens Starreveld kan men controletechnisch de volgende

functies onderscheiden: beschikken, uitvoeren, bewaren, registreren en controleren. In Figuur 6

zijn conflicterende rollen aangegeven met de gestreepte pijlen.

Figuur 6 RBAC2 met SFS in een boom structuur

In RBAC2 met SFS kan dus worden voorkomen dat één gebruiker de rollen ‘Invoer-medewerker

debiteuren’ en de rol ‘hoofd facturering’ krijgt.

Ter ondersteuning van het LTB beleid m.b.t. functiescheiding kunnen rolmatrices worden

gemaakt. In deze matrices wordt aangegeven welke rollen op basis van functiescheiding

conflicterend zijn. Deze rolmatrices worden gebruikt bij de RBAC administratie van gebruikers

accounts. In Figuur 7 is de rolmatrix van ons voorbeeld met de boekhouding afdeling afgebeeld.

Figuur 7 SFS rolmatrix



Bij DFS worden de rollen die door een gebruiker geactiveerd kunnen worden beperkt op

transactie-niveau. Dit betekent dat aan een gebruiker conflicterende rollen kunnen worden

toegewezen. Daarmee zou functiescheiding kunnen worden doorbroken. Dit wordt echter

afgeschermd omdat tijdens een transactie wordt vastgehouden welke rol de gebruiker heeft

geactiveerd. Als het gevolg daarvan kan de gebruiker tijdens dezelfde transactie de

conflicterende rol niet meer gebruiken. Hierdoor blijft de functiescheiding dus op transactie-

niveau intact.



6.4 HIËRARCHISCH RBAC MET FUNCTIESCHEIDING (RBAC3)

RBAC3 combineert de hiërarchische rolstructuren van RBAC1 met de functiescheiding (SFS en

DFS) van RBAC2.

In RBAC3 met SFS wordt voorkomen dat conflicterende rollen via directe toewijzing van een rol

en/of overerving vanuit de hiërarchie aan één en dezelfde gebruiker worden toegewezen.

Figuur 8 Hiërarchieën en SFS in een boom structuur

In ons voorbeeld van de afdeling boekhouding (zie Figuur 8) zien we dat de rol ‘invoer-

medewerker debiteuren’ (R2) conflicteert met de rol ‘invoer-medewerker facturering’ (R3). In

RBAC3 erft nu de rol ‘hoofd debiteurenadministratie’ (R4) naast de autorisaties ook de

beperkingen van rol R2 met rol R3, doordat R2 en R3 conflicterende rollen zijn. Hetzelfde geldt

ook voor de rol ‘hoofd facturering’ (R5) die naast de autorisatie van rol R3 ook de beperkingen

van de rol R3 met rol R2 erft.

Bij DFS worden de rollen die door een gebruiker geactiveerd kunnen worden beperkt op

transactie-niveau. Dit betekent dat aan een gebruiker conflicterende rollen kunnen worden

toegewezen. In ons voorbeeld van afdeling boekhouding (zie Figuur 8) betekent dit dat aan een

gebruiker zowel de rol ‘hoofd debiteurenadministratie’ (R4) als ‘hoofd facturering’ (R5) kan

worden toegewezen. Daardoor heeft de gebruiker via overerving ook de autorisaties van de

conflicterende rollen R2 en R3. Maar op transactie-niveau wordt vastgehouden welke rol de

gebruiker heeft geactiveerd. Als het gevolg daarvan kan de gebruiker tijdens dezelfde transactie

de conflicterende rol niet meer gebruiken. Hierdoor blijft de functiescheiding dus op transactie-

niveau intact.



6.5 KRITISCHE SUCCES FACTOREN VOOR RBAC IMPLEMENTATIE

In de theorie zijn een paar Kritische Succes Factoren voor een succesvolle implementatie

gedefinieerd. Deze theorie komt deels voor uit praktische implementaties15:

• Zorgvuldige implementatie van het Identity and Access Management systeem (IAM

systeem)16. Zie paragraaf 14.2 voor detail uitleg;

• Het Role Engineering17 proces voor het informatiesysteem zou in coöperatie met de

business en IT professionals uitgevoerd worden;

• Er moet gekozen worden voor het juiste IAM systeem. Het gebruik van een IAM systeem

om RBAC te managen is een belangrijke factor voor het succes van RBAC.

15 Role-Based Access Control (RBAC) Role Engineering Process, Developed For: The Healthcare RBAC Task Force, Developed by:

Science Applications International Corporation (SAIC), 11 May 2004

16 Identity and Access Management systemen (IAM systemen) zijn in de kern een software pakketten waarin de administratie van

gebruikers accounts plaatsvindt. Tevens worden in dergelijke pakketten (RBAC) rollen bijgehouden.

17 Het proces van het definiëren van rollen, permissies, beperkingen (o.a. functiescheidingen en het principe van least privilege) en

rollenhiërarchie in de informatiesystemen wordt Role Engineering genoemd.


Vrije Universiteit Amsterdam | Conclusie theorie 23

7 CONCLUSIE THEORIE

In deze paragraaf geven we antwoord op de deelvraag gesteld in paragraaf 5 en trekken we

daarbij conclusies op basis van de onderzoeksresultaten.

Deelvraag: Hoe is Role Based Access Control origineel bedoeld of opgezet?

In theorie wordt RBAC weergegeven als een model dat het beheer LTB zeer kan

versimplificeren. RBAC is vooral een antwoord op de MAC en DAC modellen die niet

beantwoordden aan gestelde eisen van commerciële bedrijven en overheidsinstellingen. De

theoretische uitleg van de diverse RBAC modellen in de literatuur is op zich helder en logisch.

Maar daar houdt de theorie dan ook op. Wat er ontbreekt, is een beschrijving hoe je RBAC nu zou

moeten implementeren in de praktijk. Daar worden eigenlijk geen handvatten voor gegeven. In

de literatuur worden wel RBAC implementatie trajecten beschreven, maar er is geen goede best-

practice aanwezig welke stappen men zou moeten nemen om RBAC succesvol te implementeren.


Vrije Universiteit Amsterdam | Role Based Access Control in de praktijk 24

8 ROLE BASED ACCESS CONTROL IN DE PRAKTIJK

8.1 INLEIDING

In het vorige paragrafen hebben we de diverse theoretische modellen voor het opzetten van

logische toegangsbeveiliging uiteengezet, met daarbij de focus op RBAC. In de komende

paragrafen staan de resultaten van ons onderzoek naar de implementatie van RBAC bij een

aantal bedrijven. Voor ons onderzoek hebben we diverse personen geïnterviewd die binnen hun

bedrijf verantwoordelijk zijn of zijn geweest voor de invoering van RBAC of het

informatiebeveiliging beleid van dat bedrijf in totaliteit. Vooraf aan alle interviews is er een

interviewverzoek inclusief vragenlijst (zie paragraaf 13) opgestuurd zodat de geïnterviewde

persoon zich kon inlezen en voorbereiden op het doel van ons interview.

Onder de bedrijven bevinden zich detailhandel, overheidsinstellingen en financiële instellingen,

waaronder banken, bank-verzekeraars en verzekeraars. En voor al deze bedrijven hebben we,

met het oog op vergelijking, de situatie in Nederland bekeken. In het totaal zijn er acht bedrijven

bezocht.

De bedrijven zijn geanonimiseerd en zullen worden aangeduid volgens de bedrijfstypologieën

zoals beschouwd in deel 2B van Bestuurlijk Informatievoorziening van Prof. R.W. Starreveld e.a..

We beschrijven per bedrijf de reden van invoering van RBAC, de schaalgrootte waarop RBAC is

geïmplementeerd, wat men tot het IT Landschap rekent en van welk RBAC model, zoals

beschreven in de theoretische paragrafen, men gebruik maakt. We wilden verder weten of er

nog alternatieve methoden van logische toegangsbeveiliging dan RBAC zijn overwogen om te

implementeren. Daarnaast geven we de door de geïnterviewden genoemde kritische

succesfactoren om RBAC in te voeren en de belangrijkste mijlpalen gedurende de implementatie

weer.

Een IT landschap is onder te verdelen in hardware, systeemsoftware, eindgebruikerapplicaties

en netwerkcomponenten.

8.2 DE BEDRIJVEN

In de volgende paragrafen worden de laatste twee deelvragen, gesteld in paragraaf 2,

beantwoord aan de hand van de resultaten van ons onderzoek. Deze twee deelvragen zijn:




8.2.1 BEDRIJF A

Dit bedrijf is een overheidsinstelling. Het bedrijf is tot stand gekomen na een fusie van diverse

overheidsinstellingen. Er werken meer dan 15.000 medewerkers. De IT is geoutsourced, behalve

het beheer van de eindgebruikers applicaties. Tot het IT Landschap worden alleen de

eindgebruikers applicaties gerekend. RBAC0 is er geïmplementeerd en er wordt gebruik



gemaakt van een IAM systeem. RBAC is geïmplementeerd op basis van afdelingsfuncties.

Vervolgens worden die functies vertaald naar benodigde rollen in het IAM systeem. Dit IAM

systeem maakt geen gebruik van ‘automatic provisioning’18, maar de benodigde autorisaties

worden handmatig in de doelsystemen aangebracht.

Er is in 2002 een LTB beleid opgesteld, dat in 2003 geaccordeerd is. Hierin werd de intentie

vastgelegd om RBAC te implementeren. De reden om RBAC te implementeren was dat de

logische toegangsbeveiliging begin 2002 totaal onbeheersbaar was geworden. Er is aangegeven

dat er niet is gekeken naar eventuele alternatieve LTB modellen.

Bedrijf A beschikte in 2002 over meer dan 800 applicaties die de bedrijfsprocessen

ondersteunden. Dit grote aantal applicaties was het resultaat van de eerder genoemde fusie. De

verschillende fusiepartners hadden voor diverse bedrijfsprocessen hun eigen applicaties. Na de

fusie bleef dit in stand, wat resulteerde dat een bepaald bedrijfsproces werd ondersteund door

verschillende applicaties. Als eerste heeft men ervoor gekozen om het aantal applicaties te

verminderen. Huidig aantal applicaties is 400 en men wil nog verder reduceren richting 200

applicaties. Daarna heeft men ongebruikte gebruikeraccounts verwijderd. Als laatste heeft men

de autorisaties toegekend aan de gebruikersaccounts geschoond.

In 2005 heeft het bedrijf gekozen voor een IAM systeem. Er is een project opgezet om RBAC en

het IAM systeem te implementeren, zonder implementatie van ‘automatic provisioning’. Per

businessafdeling heeft men contactpersonen geïdentificeerd die het projectteam ondersteunen

met het uitrollen en opstellen van de rollen. Begin 2007 had het project klaar moeten zijn.

Kritische Succes Factoren om RBAC te implementeren:

1. Vooraf opschonen gebruikersaccounts (ongebruikte gebruikersaccounts verwijderen,

personaliseren van gebruikersaccounts);

2. Vooraf opschonen autorisaties toegekend aan gebruikersaccounts, parallel aan het

traject om business rollen te definiëren;

3. Het gebruik van contactpersonen bij de businessafdelingen;

4. Implementeren van automatic provisioning. Dit is tot op heden nog niet gelukt.

Belangrijkste mijlpalen gedurende de implementatie:

De implementatie van het IAM systeem zou afgerond zijn begin 2007. Deze mijlpaal is

verschoven naar eind 2009. De reden hiervoor aangegeven is dat het implementatie tempo te

hoog lag voor de organisatie.

Conclusie Bedrijf A:

RBAC en het IAM systeem zijn na vier jaar nog niet volledig ingevoerd, ondanks het opschonen

van de applicaties en autorisaties.

18 ‘Automatic provisioning’ is het automatisch toewijzen van vooraf gedefinieerde en benodigde rechten aan gebruikers.



Verder heeft men een vorm van RBAC ingevoerd op basis van afdelingsfuncties en niet op basis

van rollen. Dit is niet volgens de theorie van RBAC en zou volgens ons één van de redenen

kunnen zijn van de moeizame implementatie.

8.2.2 BEDRIJF B

Dit bedrijf is een overheidsinstelling. Er werken meer dan 30.000 medewerkers. De IT wordt

binnen de instelling beheerd. Het bedrijf rekent alle IT componenten tot het IT Landschap.

RBAC2 is er geïmplementeerd, maar er wordt nog niet gebruik gemaakt van een IAM systeem.

Bij Bedrijf B is men in 1998 begonnen met het implementeren van RBAC op het mainframe. De

reden hiervoor was dat de logische toegangsbeveiliging decentraal werd beheerd en

onbeheersbaar was geworden. Het project dat hiervoor werd ingericht had de focus om vanuit

de organisatiestructuur autorisatierollen op te zetten. Later wilde men dit uitbreiden naar

andere platforms dan het mainframe. Het project werd uitgebreid. Daar werd duidelijk dat over

de platforms heen het autorisatieproces zeer divers was, per platform het technisch autorisatie

mechanisme verschilt en dat er veel vervuiling was in de autorisatiestructuren van de platforms.

Er is toen besloten om eerst het autorisatieproces te stroomlijnen. Er werd een centrale LTB

desk opgericht. Hier werden centraal autorisatieverzoeken verzameld, verspreidt en

geregistreerd. En er werd een applicatie gebouwd waar men autorisaties van gebruikers

administreerde. Daarnaast werd de vervuiling in de autorisatiestructuren aangepakt en

ongebruikte gebruikersaccounts opgeruimd.

Nu kon men d.m.v. datamining19 beginnen met het opzetten van autorisatierollen op basis van

businessfunctie. Dit is gefaseerd per platform aangepakt. Men heeft er voor gekozen om op de

platforms functioneel applicatieve autorisatiegroepen te implementeren. Het bundelen van de

platformautorisaties in businessrollen gebeurt buiten de platforms. Hiervoor is een eigen

software pakket ontwikkeld waarin men alle gebruikers registreert en beheert. De controle op

conflicterende rollen en autorisatie gebeurt niet centraal d.m.v. het software pakket, maar

decentraal bij de beheerders van de applicaties waar de gebruikers toegang toe willen hebben.

Later heeft men een IAM systeem aangeschaft en men is bezig dit systeem te implementeren.


1. De organisatie moet de implementatie van het IAM systeem, inclusief automatic

provisioning, accepteren. Door invoering van zo’n systeem neemt het ‘handmatig’

aanbrengen van autorisaties af, wat leidt tot verlies van banen. RBAC verdient zich pas

terug na implementatie van automatic provisioning;

2. Voldoende budget om een IAM systeem aan te schaffen en te implementeren;

3. Het implementeren van centrale autorisatieprocessen;

4. Het aanbrengen van uniformiteit in autorisaties.

19 Datamining is het op een geautomatiseerde manier patronen en relaties ontdekken in grote hoeveelheden gegevens.




Na 3 jaar zou op 90% van de platforms de autorisaties via automatic provisioning moeten

worden aangebracht. En na 3 jaar zou de investering terugverdient zijn. Deze mijlpaal is niet

gehaald vanwege de complexiteit en diversiteit van het IT landschap.

Conclusie Bedrijf B:

Bedrijf B had al een centraal systeem om autorisaties in vast te leggen. De logische

toegangsbeveiliging was dus al, zeker procedureel, op orde. De hoofdreden om een IAM systeem

te implementeren was kostenbesparing (op personeel). Het lijkt erop dat RBAC prima werkt

zonder geautomatiseerd systeem en dat het invoeren van een IAM systeem om kosten te

besparen leidt tot toenamen van de complexiteit.

Ook hier heeft, net als bij bedrijf A, men RBAC geïmplementeerd op basis van afdelingsfuncties

i.p.v. rollen.

8.2.3 BEDRIJF C

Dit bedrijf is een overheidsinstelling verdeeld over meerdere deels autonome regio’s. Er werken

meer dan 50.000 medewerkers. De IT wordt binnen de instelling beheerd. De instelling rekent

alle IT componenten tot het IT Landschap. Er is hier geprobeerd RBAC te implementeren, met

behulp van een IAM systeem, maar dat is tot op heden niet gelukt.

In het jaar 2003 is bij Bedrijf C een autorisatie project opgezet. Veel applicaties hadden interne

autorisatiestructuren, waardoor de totale autorisatie per medewerker ondoorzichtig was. Dit

wilde men oplossen met het invoeren van RBAC. Daarvoor had men ook een IAM systeem

aangeschaft. Omdat het bedrijf zowel regionaal als landelijk beheerde IT-systemen heeft, en men

naar meer uniformiteit toe wilde over de regio’s heen, is er voor gekozen nieuwe landelijke uit te

rollen applicaties aan te sluiten op het IAM systeem en RBAC. Uiteindelijk hebben bezwaren van

de projectmanagers van de nieuw uit te rollen applicaties op het aansluiten van de beveiliging

van hun applicatie op het IAM systeem aan de basis gelegen van het niet kunnen uitrollen van

RBAC. Dit heeft kunnen gebeuren doordat het autorisatie project niet voldoende door het

management ondersteund werd.


1. Volledigheid van de personeelsgegevens;

2. Acceptatie van IT projectmanagers. Er werd aangegeven dat IT projectmanagers geen

gebruik wilden maken van de functionaliteiten van het centrale IAM systeem. Men wilde

liever gebruik blijven maken van decentrale LTB per applicatie. Er was geen vertrouwen

in het centrale IAM systeem, omdat men vond dat het IAM systeem de benodigde

vertrouwelijkheid niet kon waarborgen;

3. Voldoende draagvlak bij het management.




Uiteindelijk is RBAC niet uitgerold binnen dit Bedrijf en is het IAM systeem in onbruik geraakt.

Dit is veroorzaakt door onvoldoende management back-up en daardoor onvoldoende acceptatie

van projectmanagers.

Conclusie Bedrijf C:

De versnippering van de IT en onvoldoende draagvlak bij het management worden genoemd als

belangrijk punten voor het falen van de implementatie. Onze additionele opmerking is dat het

aanschaffen van een applicatie als oplossing van het LTB probleem geen goede zet is. Het is

belangrijk eerst een goede structuur voor de logische toegangsbeveiliging neer te zetten en dan

pas verder denken over geautomatiseerde systemen die het werk zouden kunnen overnemen.

8.2.4 BEDRIJF D

Dit bedrijf is een overheidsinstelling met een branche netwerk. Er werken meer dan 4.000

medewerkers. De IT wordt binnen de instelling beheerd. Het bedrijf rekent alle IT componenten

tot het IT Landschap. Dit IT Landschap bestaat echter uit één platform cq. producent. Dit

platform kan centraal geadministreerd worden met techniek die beschikbaar is binnen het

platform.

Bij Bedrijf D heeft men in 2003 gekozen voor een RBAC oplossing plus implementatie van een

IAM systeem. RBAC0 is er deels geimplementeerd. De RBAC0 implementatie voorziet echter

alleen in rollen voor de branchemedewerkers. Reden hiervoor is dat de functies, rollen en

benodigde autorisaties van de branchemedewerkers over het algemeen niet veel veranderen en

ook niet complex zijn. In dit geval gaat het om toegang tot het intranet van het bedrijf en het

personeelssysteem. Ondanks dat er van één platform gebruik wordt gemaakt, en dit platform

centraal beheer van LTB toestaat, heeft men toch gekozen voor een extern IAM systeem. Reden

die men aangaf was vooral het unieke verkoopargument van de mogelijkheid tot het vergelijken

van de verleende autorisaties met de benodigde autorisaties (IST en SOLL). De reden voor de

invoering van RBAC was de vervuiling in autorisaties.

Er is gekozen voor een gefaseerde aanpak om RBAC en het IAM systeem te implementeren,

namelijk:

1. Een IAM systeem implementeren, gekoppeld aan het Human Resource systeem;

2. Het koppelen van de applicaties en legacy systemen;

3. Het implementeren van single sign-on.

Fase 1 was ten tijde van het onderzoek afgerond. Fase 2 en 3 moeten nog worden gedaan. Op dit

moment gebruikt met het IAM systeem alleen om vergelijkingen te doen tussen de SOLL en de

IST situatie. Er wordt geen gebruik gemaakt van automatic provisioning en het aanbrengen van

autorisatie gebeurt rechtstreeks in de doelsystemen en niet via het IAM systeem.




1. De business moet actief meedenken met een RBAC implementatie;

2. Het aanbrengen van uniformiteit in functie autorisatie. Bedrijf D bestaat uit

verschillende regio’s en autorisatie voor op het oog dezelfde functies verschillen toch in

de praktijk.


De implementatie van het IAM systeem (fase 1) zou 3 maanden in beslag nemen. Dit is een

meervoud hiervan geworden.

Conclusie Bedrijf D:

Bij bedrijf D is men begonnen met de aanschaf van een IAM systeem. Tijdens ons interview gaf

men aan dat men primair gebruik maakt van een platform waarin een centrale logische

toegangsbeveiliging administratie beschikbaar is. Onze opinie is dat men de verkeerde

uitgangspunten heeft gekozen voor de aanschaf van het IAM systeem. Het besluit tot aanschaf

van een IAM systeem is vooral genomen op basis van randfunctionaliteiten zoals SOLL-IST

rapportages. En dus niet het primaire doel van een IAM systeem om gebruikers te administreren

en hun autorisaties te kunnen beheren (zie ook paragraaf 14.2)

Verder kunnen we concluderen dat de invoering van RBAC alleen is gelukt voor de statische

omgeving van de branchemedewerkers.

8.2.5 BEDRIJF E

Dit bedrijf is een handelsbedrijf met een branchenetwerk. Er werken meer dan 40.000

medewerkers in Nederland. De IT wordt binnen de instelling beheerd. Het bedrijf rekent alle IT

componenten tot het IT Landschap. RBAC2 is er geïmplementeerd voor de branches en er wordt

gebruik gemaakt van een IAM systeem.

Eind 2006 heeft Bedrijf E een RBAC project opgezet. Reden hiervoor was dat men vanuit de

business een nieuw business model wilde opzetten, inclusief nieuw HR proces en ontsluiting van

de IT. Na onderzoek bleek een RBAC project, met een single sign-on en automatic provisioning

hier prima bij te passen. Vanuit de business zijn de rollen opgezet, die vervolgens zijn vertaalt

naar platform autorisatie. Het systeem is zo gebouwd dat men meerdere rollen kan toewijzen

per persoon. Daarbij worden conflicten tussen rollen, bijvoorbeeld het doorbreken van

functiescheiding, aangegeven. Voor de branches van Bedrijf E heeft men ook ‘automatic

provisioning’ kunnen doorvoeren. Voor de hoofdkantoren is dit niet gelukt.


1. Het verantwoordelijk maken van de businessafdelingen voor het bepalen van de

autorisaties van de rollen;

2. Goede communicatie vanuit het RBAC project richting beheerders en gebruikers;

3. Bewustwording dat sommige legacy applicaties moeilijk onder RBAC te brengen zijn;



4. Doe een goed vooronderzoek.


Voor de branches zijn de mijlpalen gehaald. RBAC en ‘automatic provisioning’ is

geïmplementeerd. Dit is vooral te danken aan het feit dat de autorisaties van de rollen in de

branches statisch zijn. Voor de hoofdkantoren zijn de mijlpalen niet gehaald. Dit komt

hoofdzakelijk omdat in tegenstelling tot de branches er veel reorganisaties en

functieaanpassingen zijn.

Conclusie Bedrijf E:

De belangrijkste conclusie die we hier kunnen trekken is dat RBAC in een statische autorisatie

omgeving makkelijker is te implementeren. In een omgeving met veel reorganisaties en

autorisatiewijzigingen is het veel moeilijker of misschien wel onmogelijk.

8.2.6 BEDRIJF F

Dit bedrijf is een financiële instelling met een branchenetwerk. Er werken meer dan 50.000

medewerkers in Nederland. De infrastructurele IT is geoutsourced. Het bedrijf rekent alle IT

componenten tot het IT Landschap. RBAC0 is er geïmplementeerd en er wordt gebruik gemaakt

van een IAM systeem.

Rond het millennium is men bij Bedrijf F begonnen met RBAC0 op het mainframe. Eerst heeft

men de technisch beheerrollen, zoals operations en service desk, aangepakt. Reden hiervoor was

dat hier de meeste vervuiling in zat. Om de benodigde autorisatie voor branchemedewerkers te

administreren werd er gebruik gemaakt een in eigen beheer ontwikkeld software pakket.

Hiermee werd mogelijkheid geboden om de rol autorisaties centraal te beheren en het

toevoegen van branchemedewerkers aan die rollen decentraal binnen de branche organisatie.

Zelfs werd er door het pakket gewaarborgd dat conflicterende rollen niet aan dezelfde persoon

werden uitgegeven. Dit is dus een RBAC2 implementatie.

Vervolgens wilde men deze best-practice uitrollen over meerdere platforms en is er een IAM

systeem aangeschaft.


1. Support van het management;

2. Het implementatie van een goed IAM systeem;

3. Het beheer van de rollen goed beleggen;

4. Het implementeren van goede rapportage mogelijkheden m.b.t. de controle op de

autorisaties.


Voor de branches zijn de mijlpalen gehaald. Voor de hoofdkantoren is RBAC nog niet ingericht.

En verder zijn de rapportage mogelijkheden beperkt.



Conclusie Bedrijf F:

De belangrijkste conclusie die we hier kunnen trekken is dezelfde als bij bedrijf E. RBAC is in een

statische autorisatie omgeving makkelijk is te implementeren. In een omgeving met veel

reorganisaties en autorisatiewijzigingen is het veel moeilijker. Verder heeft men een eigen

pakket ontwikkeld dat de RBAC2 administratie voor de branches ondersteunt. Dat lijkt goed te

werken in tegenstelling tot de aangekochte IAM systemen die we bij andere bedrijven zien.

8.2.7 BEDRIJF G

Dit bedrijf is een financiële instelling met een branchenetwerk. Er werken meer dan 25.000

medewerkers in Nederland. De IT is wordt deels binnen de instelling en deels buiten de

instelling beheerd. Het bedrijf rekent alle IT componenten tot het IT Landschap. RBAC0 is er

geïmplementeerd en er wordt gebruik gemaakt van een IAM systeem.

Bedrijf G had, in ieder geval op een enkel platform, al een vorm van RBAC0 geïmplementeerd.

Niet op basis van rollen, maar op basis van groepen die de organisatie weerspiegelden.

In 2006 is men bij Bedrijf G begonnen met het implementeren van RBAC samen met een IAM

systeem. De reden hiervan was de autorisaties vervuild waren en dat externe toezichthouders

een verbetering van de logisch toegangsbeveiliging eisten. Via datamining heeft men de

autorisatie van medewerkers vergeleken met de benodigde autorisaties. Vervolgens heeft men

deze geschoond. Per businessafdeling is het projectteam aan de slag gegaan. Er worden

presentaties gegeven en er wordt gewerkt met contactpersonen op de afdelingen. Omdat RBAC

per businessafdeling wordt uitgerold zijn de autorisaties gebaseerd op personeelsfunctie i.p.v.

op rollen.

Het IAM systeem zou moeten voorzien in ‘automatic provisioning’. Dit is tot op heden nog niet

geïmplementeerd. Het aanbrengen van autorisatie gebeurt grotendeels nog handmatig op de

platforms.


1. Het verkrijgen van support van de businessafdelingen;

2. Centrale aansturing van het RBAC project;

3. Het aanstellen van contactpersonen per businessafdeling.


De mijlpaal is om alle autorisaties van medewerkers halverwege 2009 via RBAC te kunnen

uitgeven en administreren. Tot op heden is de uitrol nog niet compleet.

Conclusie Bedrijf G:

Bedrijf G geeft aan al ver te zijn met de implementatie van RBAC. Het IAM systeem wordt alleen

gebruikt als aanvraag en registratiesysteem. De grote voordelen als ‘automatic provisioning’

worden niet behaald.



RBAC is gebaseerd op afdelingsfuncties en niet op rollen. Dit is niet volgens de theorie van RBAC

en zou volgens ons één van de redenen kunnen zijn van de moeizame implementatie.

8.2.8 BEDRIJF H

Dit bedrijf is een financiële instelling. Er werken meer dan 20.000 medewerkers in Nederland.

De IT wordt binnen de instelling beheerd. Het bedrijf rekent alle IT componenten tot het IT

Landschap. RBAC0 is er geïmplementeerd voor één divisie en er daar wordt ook gebruik

gemaakt van een IAM systeem.

Bij bedrijf H heeft men voor één van de divisies RBAC uitgerold. Dit moet in de toekomst ook

over de andere divisies worden uitgerold. Reden om deze divisie uit te kiezen was dat externe

eisen tot een business case hebben geleidt. Deze business case gaf aan dat er een eenduidig LTB

beleid moest zijn en dat autorisaties moesten worden geschoond. Daarnaast was het vanuit

beheersoogpunt van belang om het aantal applicaties terug te brengen. Allereerst is men de

functie van de medewerkers en de daarbij behorende autorisaties gaan inventariseren. Elke

afdeling kreeg daarmee zijn eigen functiebeheer team die de rollen voor die afdeling beheert.

Deze rollen, plus de autorisaties, worden beheerd in een centrale database, die tevens aan het

HR systeem is gekoppeld. Deze centrale database maakt geen gebruik van ‘automatic

provisioning’. Autorisaties worden decentraal op de verschillende platforms door de beheerders

aangebracht.


1. Het verkrijgen van support van het business management;

2. Het opzetten van een centraal kenniscentrum.


1. In 2009 wil men op bedrijfsniveau een identiteits manegement project, inclusief

aangekocht systeem uitgerold, hebben;

2. In 2010/2011 wil men RBAC 3 hebben ingevoerd d.m.v. datamining.

Conclusie Bedrijf H:

Bedrijf H heeft RBAC zeer minimaal ingevoerd. De belangrijkste mijlpalen liggen in de toekomst.


Vrije Universiteit Amsterdam | Conclusie praktijk 33

9 CONCLUSIE PRAKTIJK

In deze paragraaf geven we antwoord op de deelvragen gesteld in paragraaf 8.2 en trekken we

daarbij conclusies op basis van de onderzoeksresultaten.

Deelvraag: Op welke manier(en) wordt Role Based Access Control geïmplementeerd?

Ons onderzoek toont aan dat wanneer er al sprake is van een RBAC implementatie dit RBAC0 zal

zijn. Drie keer zijn we RBAC2 tegengekomen, waarvan twee keer in een statische omgeving. En

voor die twee keer werd een in eigen beheer ontwikkeld pakket gebruikt om de autorisaties te

administreren. RBAC 1 en RBAC3 zijn we niet tegengekomen tijdens ons onderzoek. De reden

dat we de hiërarchische component van RBAC niet tegenkomen is volgens ons het feit dat RBAC

vaak wordt uitgerold op basis van personeelsfuncties i.p.v. rollen.

Verder kunnen we concluderen dat bedrijven die eerst zorgen voor een goede

autorisatiestructuur en een goed LTB beleid minder moeite hebben met de implementatie van

RBAC. Daarbij dient wel opgemerkt te worden dat ook deze bedrijven RBAC nog niet volledig

hebben geïmplementeerd.

Over de IAM systemen kunnen we het volgende zeggen. Bij geen enkel bedrijf hebben we een

aangekocht systeem gezien dat volledig functioneert. Ons onderzoek toont aan dat handmatige

administratie of in eigen beheer ontwikkelde pakketten beter lijken te werken dan aangekochte

IAM systemen. Belangrijkste oorzaak hiervoor is volgens ons dat de verkeerde redenen worden

gebruikt om een IAM systeem aan te schaffen. Deze redenen variëren sterk. Het ene bedrijf wil

de onbeheersbaar geworden logische toegangsbeveiliging verbeteren door aanschaf van een

IAM systeem. Het andere bedrijf besluit tot aanschaf van een IAM systeem op basis van

randfunctionaliteiten zoals rapportages.

Deelvraag: Welke overwegingen worden gemaakt ten aanzien van de vraag om Role Based Access


Ons onderzoek heeft aangetoond dat de reden om voor RBAC te kiezen vaak simpel is. De

toegangsbeveiliging werd meestal decentraal geadministreerd en was onbeheersbaar geworden.

De oorzaak hiervan is het groeien van het IT Landschap van één platform naar meerdere

platforms en het fuseren van bedrijven. Daarnaast gaf men vaak aan dat kostenbesparing ook

een reden tot invoering was. Die kostenbesparing zou vooral moeten komen door het invoeren

van een IAM systeem met ‘automatic provisioning’. Helaas is gebleken dat het merendeel van de

RBAC implementaties dat niet hebben kunnen volbrengen.

Verder heeft ons onderzoek aangetoond dat men eigenlijk niet heeft gekeken naar alternatieven

voor RBAC, of dat er geen alternatieven waren. Men geeft aan dat RBAC wordt gezien als DE

oplossing voor de toegangsbeveiliging problematiek in hun bedrijf.


Vrije Universiteit Amsterdam | Eindconclusie 34

10 EINDCONCLUSIE

In deze paragraaf geven we antwoord op de onderzoeksvraag gesteld zijn in paragraaf 2 en

trekken we daarbij conclusies op basis van de onderzoeksresultaten.

De hoofdonderzoeksvraag is:


Ons onderzoek toont aan dat er tussen de theorie en de praktijk een gat zit. In de conclusie van

de theorie, paragraaf 7, hebben we geconcludeerd dat de RBAC theorie een goede best-practice

voor implementatie van RBAC mist. Dit blijkt ook uit ons praktijkonderzoek. We zien dat er

diverse pogingen gedaan worden om RBAC te implementeren, maar geen van die pogingen is

echt succesvol. De enige plekken waar wij een implementatie van RBAC hebben gevonden is op

statische bedrijfsomgevingen. En volgens de theorie zou RBAC juist geschikt zijn om

geïmplementeerd te worden in dynamische bedrijfsomgevingen met reorganisaties en verloop

van personeel. Volgens ons komt dit omdat de implementaties die wij gezien hebben niet

volgens de theorie van rollen zijn ingevoerd, maar op basis van afdelingsfuncties. Ons onderzoek

toont aan dat veel bedrijven kiezen voor het opzetten van rollen op het niveau van afdelingen.

Hierdoor wordt vaak gekeken naar reeds bestaande afdelingsfuncties om rollen te definiëren.

Dit is af te leiden uit het feit dat een aantal bedrijven datamining heeft gebruikt om rollen te

definiëren. D.m.v. datamining maakte men van de reeds aanwezige autorisaties RBAC rollen.

RBAC is echter volgens de theorie gebaseerd op afdelingsoverstijgende rollen die onafhankelijk

zijn van een bedrijfsafdeling. Daardoor hoeven de autorisaties van de rollen niet gewijzigd te

worden bij een reorganisatie. De bedrijven die wij hebben onderzocht maken gebruik van rollen

op basis van afdelingsfunctie, waardoor bij een reorganisatie de autorisatie van de rollen wel

moeten wijzigen. Het lijkt erop dat door de grootte van de door onderzochte bedrijven het

centraal opzetten van rollen niet uitvoerbaar is. Onze conclusie is dan ook dat de RBAC theorie

te veel uitgaat van afdelingsoverstijgende bedrijfsrollen en dat dit in de praktijk niet werkt.

Daarmee moeten we concluderen dat RBAC volgens de door ons onderzochte theorie niet

toepasbaar is in de praktijk, zoals bij de door ons onderzochte bedrijven.

Daarnaast zien we dat in de praktijk de bedrijven van veel verschillende platforms gebruik

maken. In de theorie is daarvoor als één van de kritische succesfactoren aangegeven dat voor

een succesvolle RBAC implementatie het gebruik van een IAM systeem onontbeerlijk is. Ook

tijdens onze interviews werd dat diverse keren aangegeven. Tijdens ons onderzoek zijn we bij

geen enkel bedrijf een volledig en goed werkend IAM systeem tegengekomen. Het lijkt er dus op

dat dit één van de oorzaken is dat RBAC niet goed geïmplementeerd kan worden. En daarmee

kunnen we concluderen dat de grote verscheidenheid aan platforms een goede RBAC

implementatie in de weg staat.

Onze eindconclusie is RBAC niet goed te implementeren is in het huidige IT landschap, omdat er

geen goede handvatten voor een succesvolle implementatie beschikbaar zijn.

Naar aanleiding van het onderzoek kunnen we echter wel een positieve kanttekening plaatsen

bij de door ons onderzochte RBAC implementaties. Er is veelal aangegeven dat de reden om


Vrije Universiteit Amsterdam | Eindconclusie 35

RBAC te implementeren de vervuiling in de autorisatiestructuren was. De meeste

geïnterviewden geven aan dat die vervuiling wel is aangepakt en dat de autorisatiestructuren

zijn opgeschoond. Positief punt is dus dat door het starten van een RBAC traject de

autorisatiestructuren meer aandacht krijgen dan daarvoor.


Vrije Universiteit Amsterdam | Hoe nu verder? 36

11 HOE NU VERDER?

Naast een droge conclusie van het constateerde bij het onderzoek, willen we deze scriptie van

meerwaarde laten zijn op toekomstige implementaties van Role Based Access Control binnen

bedrijven. Daarom willen we hier kort onze visie neerzetten van hoe wij van mening zijn op Role

Based Access Control te implementeren. Daarnaast willen we in paragraaf 11.2 kort een aantal

toekomstvisies m.b.t logische toegangsbeveiliging naast elkaar zetten met daarop een kort

commentaar van de schrijvers.

11.1 ONZE VISIE

Naast de in de conclusie genoemde kritische succesfactoren, die allemaal valide zijn, willen we

hier onze visie hoe RBAC te implementeren in een omgeving met meerdere platforms.

Belangrijk is dat rollen niet dubbel geadministreerd worden. Als er dus wordt gekozen voor een

IAM systeem is het van belang in dat systeem de rollen te beheren. Op de doelsystemen (de

achterliggende platforms) moet de rechtenstructuur zo statisch mogelijk worden gehouden. Op

de doelsystemen zou men autorisatie moeten bezien vanuit de applicaties en de rechten

administreren via functionele applicatiegroepen. De functionele applicatiegroepen

vertegenwoordigen de applicatie specifieke functies. De koppeling tussen de rollen en de

functionele applicatiegroepen moet gebeuren in het IAM systeem. Op deze manier hoeft men bij

reorganisaties alleen de rollen plus de koppelingen naar dat doelsystemen te wijzigen en blijven

de doelsystemen buiten schot. Een wijziging op een doelsysteem wordt alleen doorgevoerd als

er een applicatie bijkomt of verdwijnt of dat een applicatie een extra applicatiefunctie krijgt.

Op deze manier worden de organisatorische kant en de applicatieve kant gescheiden door het

IAM systeem.

11.2 VARIATIES OP RBAC

11.2.1 AUDIT BASED ACCESS CONTROL

Audit Based Access Control (ABAC) visie is ontstaan vanuit de zorg. Daar is er grote noodzaak

om snel toegang te krijgen tot gegevens. Het idee van ABAC is dat de gebruiker in principe alle

rechten heeft en dat achteraf via auditing en logging de toegang kan worden verantwoord. De

administratie van de rechten gebeurt decentraal en gebruikers mogen rechten aan elkaar

uitdelen. De restricties op de toegang van gegevens wordt procedureel in beleid opgesteld. In

essentie lijkt ABAC door zijn decentrale rechtenstructuur erg op DAC.

Commentaar schrijvers:

In de visie voor ABAC wordt gerefereerd naar het feit dat bij financiële en overheidsinstellingen de

financiële waarde van gegevens groter is dan bijvoorbeeld in de zorg en dat daarom ABAC wellicht

geen optie is voor dit soort instellingen. Er wordt dan echter voorbij gegaan aan andere criteria die

gegevens met zich meedragen, namelijk vertrouwelijkheid en integriteit. Ook al hebben gegevens

geen grote financiële waarde kan het in de openbaarheid brengen van bijvoorbeeld medische

gegevens grote, ook financiële, consequenties hebben.



Persoonlijk denken wij, als toekomstige RE’s, dat ABAC niet een toekomst vaste methodiek zal

blijken te zijn.

11.2.2 CONTEXT BASED ACCESS CONTROL

Context Based Access Control (CBAC) kan worden gezien als een aanvulling op RBAC. Bij RBAC

worden gebruikers gekoppeld aan rollen die autorisatie geven tot bepaalde gegevens of

programmatuur. Een gebruiker heeft te allen tijde en op alle plaatsten rechten tot deze

autorisatie. Bij CBAC wordt er een extra onderscheidt gemaakt op welke manier deze data of

programmatuur wordt genaderd. Er kan bijvoorbeeld onderscheidt gemaakt worden tussen het

verkrijgen van toegang vanaf een werkplek binnen de bedrijfsmuren of toegang vanaf een laptop

buiten de bedrijfsmuren.

CBAC legt wel een extra claim op de organisatie omdat naast de ‘normale’ RBAC autorisatie ook

extra gegevens moeten worden bijgehouden.


CBAC is theoretisch een goede aanvulling op RBAC. Maar omdat het een aanvulling is verdiend het

niet de aanbeveling om CBAC te implementeren. Ons onderzoek wees uit dat het implementeren

van RBAC al lastig genoeg is, zonder de extra activiteiten die benodigd zijn om CBAC te

implementeren.

11.2.3 CLAIMS BASED ACCESS CONTROL

Claims Based Access Control (ClBAC) is bedoeld om gebruikers toegang via webportalen te

regelen. ClBAC lijkt in essentie op CBAC. Ook ClBAC maakt van de context waarin toegang wordt

verleend, maar gaat veel verder. De bedoeling van ClBAC is dat de ‘claim’, de digitale identiteit

van een gebruiker, via een webportaal de toegang tot de doelsystemen regelt. Op de

doelsystemen zelf zal de gebruiker geen autorisatie meer hebben, maar zal via het webportaal

d.m.v. een interface die een systeemuser gebruikt toegang krijgen. Daarmee vervalt de directe

traceerbaarheid van een natuurlijk persoon tot een datamutatie en zullen er compenserende

maatregelen moeten worden genomen. Er wordt o.a. verwezen naar ABAC met zijn audittrails.

Een ‘claim’ geeft informatie over de digitale identiteit van de gebruiker. Zo kunnen bijvoorbeeld

een junior en een senior medewerker dezelfde rol krijgen toebedeeld, maar mag alleen de senior

medewerker bijvoorbeeld transacties fiatteren.

Daarnaast zouden de ‘claims’ centraal kunnen worden beheerd door een zgn. ‘identity provider’.

Een soort internet provider, maar dan voor digitale identiteit. Zo zouden ‘claims’ van gebruikers

door meerdere bedrijven kunnen worden gebruikt.


ClBAC is vergaande visie op hoe logisch toegangsbeheer zou kunnen worden ingericht. Het is zeer

afhankelijk van het feit dat toegang tot gegevens via een webportaal wordt gegeven. Daarnaast is

er nog geen ‘identity provider’. Dit wordt door de schrijver ook al aangegeven in zijn verhandeling

over ClBAC.



Wij vinden het een interessant idee, maar zien in de nabije toekomst ClBAC niet op grote schaal

worden geïmplementeerd, omdat er teveel afhankelijkheden zijn.


Vrije Universiteit Amsterdam | Bijlage A: Literatuurlijst 39

12 BIJLAGE A: LITERATUURLIJST

Hieronder de lijst van literatuur die we hebben gebruikt voor ons onderzoek.

1. Jan van Praat en Hans Suerink, Inleiding EDP-auditing, 5e druk 1e oplage, november 2004 2. Deel 2B van Bestuurlijk Informatievoorziening van Prof. R.W. Starreveld e.a. 3. David Ferraiolo and D. Richard Kuhn (National Institute of Standards and Technology),

Role-Based Access Controls (ABSTRACT), 15th National Computer Security Conference (1992), Baltimore MD

4. Ravi S. Sandhu, Edward J. Coynek, Hal L. Feinsteink and Charles E. Youmank, Role-Based

Access Control Models, IEEE Computer, February 1996 5. Ravi Sandhu, David Ferraiolo and D. Richard Kuhn, The NIST Model for Role-Based Access

Control: Towards A Unified Standard (abstract),2000 6. Andreas Schaad, Jonathan Moffett, Jeremy Jacob, The Role-Based Access Control System of

a European Bank: A Case Study and Discussion (Abstract), SACMAT 2001: 6th ACM Symposium on Access Control Models and Technologies

7. Francis M. Kugblenu and Memon Asim, Separation of Duty in Role Based Access Control

System: A Case Study (Master Thesis in Computer Science), January 2007 8. AN INTRODUCTION TO ROLE-BASED ACCESS CONTROL, NIST/ITL Bulletin, December,

1995 9. Michael P. Gallaher, Ph.D.Alan C. O’Connor, B.A.Brian Kropp, Ph.D., The Economic Impact

of Role-Based Access Control, NIST, March 2002 (Benefits of RBAC) 10. Role-Based Access Control (RBAC) Role Engineering Process, Developed For: The

Healthcare RBAC Task Force, Developed by: Science Applications International Corporation (SAIC), 11 May 2004

11. Gustaf Neumann and Mark Strembeck, A Scenario driven Role Engineering Process for

Functional RBAC Roles (Abstract) 12. Jean-Pierre Vincent, RBAC Next Generations, INFORMATIEBEVEILIGING DECEMBER

2007 13. Studie Role Based Access Control, Platform Informatiebeveiliging, November 2005 14. Erik Steinmann, Jan Vogels, Bram Vonk, Security (Access Control) 15. Rob Kroneman en John Rudolph, Role Based Acces Control: Een proces benadering, Juli

2008 16. drs.ing. Jan-Roel Löwenthal CISSP, Combineer rol-, attribuut- en auditgebaseerd

autoriseren: Iedereen mag alles, INFORMATIEBEVEILIGING JULI 2007 17. Hans Scholten, Context Based Access Control-An approach for implementing RBAC and

beyond 18. Pierangela Samarati and Sabrina de Capitani di Vimercati, Access Control: Policies,

Models and Mechanisms, Lecture Notes in Computer Science, Volume 2171 (2001) 19. R. Tellegen, RBAC onder controle (referaat IT Auditing) 2006


Vrije Universiteit Amsterdam | Bijlage B: Interviewverzoek 40

13 BIJLAGE B: INTERVIEWVERZOEK

Interviewverzoek ten behoeve van een onderzoek naar

Role Based Access Control

Afstudeerscriptie van Danka Pots-Zukik (email: [email protected]; tel.: 06-22079548) en Marco Hendriks (email: [email protected]; tel.: 06-48474253), Studenten aan de Vrije Universiteit, Postdoctorale IT Audit Opleiding. Inleiding en context Voor onze afstudeerscriptie van de postdoctorale IT-Audit opleiding aan de Vrije Universiteit Amsterdam onderzoeken wij de toepasbaarheid van Role Based Access (RBAC). Hierbij is de hoofdvraag: Is Role Based Access toepasbaar in het huidige IT landschap?

Graag willen wij de onderstaande vragen/stellingen met u te bespreken. Het interview zal ongeveer één uur in beslag nemen. Uiteraard zal de manier van terugkoppeling, weergave van meningen en naamsvermelding ook in het gesprek aan de orde komen. Vanuit de literatuur belooft RBAC een aantal attractieve voordelen ten opzichte van andere methoden voor logische toegangsbeveiliging:

• Als meerdere gebruikers dezelfde toegangsrechten nodig hebben, dan kunnen die rechten afgebakend worden en gebruikt worden voor meerdere ontvangers. Dit biedt efficiëntie in het beheer en kan leiden tot kostenvermindering.

• In het geval dat meerdere gebruikers andere toegangsrechten nodig hebben, dan kan de rol definitie veranderd worden en daarna toegepast worden op meerdere gebruikers.

• Men kan snel en betrouwbaar bepaalde rechten intrekken en nieuwe verstrekken door de rol classificatie van de gebruiker te veranderen.

Ons onderzoek richt zich op de haalbaarheid van de voordelen van RBAC. Om een goed beeld te krijgen van alle problematiek, en uitdagingen die de hoofdvraag beïnvloeden, zouden wij u dan ook willen vragen met ons van gedachten te wisselen over de volgende vragen en stellingen:

Discussievragen:

1. Hoe ziet het IT landschap van uw bedrijf eruit? 2. Wat is uw, of het bedrijf zijn, definitie van IT-landschap? 3. Hoe is de Logical Access Control in uw bedrijf ingericht? 4. Wat zijn de redenen geweest om RBAC wel of niet in te voeren? 5. Wat waren de andere mogelijke opties voor het inrichten van de Logical Access Control

behalve RBAC? 6. Is er een business case over het implementeren van RBAC gemaakt? Zo ja, wat zijn de

uitkomsten? 7. Op welke manier is RBAC geïmplementeerd? 8. Wat is in de scope van de RBAC? Is RBAC ingericht op alle platforms en op welke manier? 9. Is er onderzocht of implementatie van RBAC de gewenste resultaten heeft gegeven en

wat de uitkomst daarvan was? • Zijn de mijlpalen gehaald? • Wat voor problemen cq. uitdagingen zijn er opgedoken? • Zijn de initiële doelstellingen gehaald?

10. Wat zijn jullie plannen voor de toekomst m.b.t. de Logical Access Control?


Vrije Universiteit Amsterdam | Bijlage C: Gebruikte terminologie 41

14 BIJLAGE C: GEBRUIKTE TERMINOLOGIE

14.1 RBAC ADMINISTRATIE

Om RBAC goed te kunnen implementeren moet er een eenduidige administratie zijn. Het huidige

IT Landschap bestaat meestal uit verschillende platforms, OS instanties en variaties, hardware

en interfaces. Het administreren van de toegangsrechten kan dan ook op verschillende manieren

plaatsvinden:

1. Per hardware of OS instantie, bijvoorbeeld per LPAR op een mainframe;

2. Per platform, bijvoorbeeld centraal voor unix via ldap en dan apart centraal voor

windows via de windows ldap, active directory;

Centraal via een centraal autorisatie rol beheer systeem, ook wel IAM systeem genoemd. Zie

paragraaf 14.2. Met de implementatie van een IAM systeem kan de geadministreerde autorisatie

automatisch worden doorgezet naar de doelsystemen. Dit heet ‘automatic provisioning’.

Hierover meer in paragraaf 14.3.

14.2 IDENTITY AND ACCESS MANAGEMENT SYSTEMEN

Identity and access management systemen (IAM systemen) zijn in de kern een software pakket

waarin de administratie van gebruikers accounts plaatsvindt. Tevens worden in een dergelijk

pakket rollen bijgehouden. Deze rollen bestaan uit autorisaties die benodigd zijn per platform.

Vaak is een IAM rol gekoppeld aan een bepaalde bedrijfsfunctie. Eigenlijk kan een IAM systeem

gezien worden als een soort ‘broker’ tussen het HR systeem met de daarin vastgelegde functies

en de IT doelsystemen met de benodigde autorisaties. Op deze manier wordt er van de native

security systemen van de IT platforms gebruik gemaakt. Als dit op een juiste manier gebruikt

wordt dan hoeven er bij wijzigingen in de HR structuur geen structurele wijzigingen worden

aangebracht in de native security systemen van de IT doelsystemen. De koppelingen naar de IT

doelsystemen binnen de IAM systemen hoeven dan slechts te worden gewijzigd op basis van de

organisatorische functiewijzigingen.

14.3 AUTOMATIC PROVISIONING

‘Automatic provisioning’ is het automatisch toewijzen van rechten aan gebruikers. Het IAM

systeem wordt aan de ene kant gekoppeld aan het HR systeem en aan de andere kant aan de

doelsystemen. Wanneer een medewerker in het HR systeem wordt aangebracht, gemuteerd qua

functie of rol of verwijderd wordt, dan zal via het IAM systeem deze wijzigingen automatisch

worden doorgevoerd op de doelsystemen. In theorie hoeft er geen menselijke interventie meer

nodig te zijn. In de praktijk zullen we zien dat de implementatie ervan niet gemakkelijk is.


Vrije Universiteit Amsterdam | Bijlage C: Gebruikte terminologie 42

14.4 ROLE ENGINERING

Role enginering is het proces van het definiëren van rollen, permissies, beperkingen (o.a.

functiescheidingen en het principe van least privilege) en rollenhiërarchie in de

informatiesystemen.

14.5 DATAMINING

Datamining is het op een geautomatiseerde manier patronen en relaties ontdekken in grote

hoeveelheden gegevens. In het geval van RBAC wordt het gebruikt om reeds bestaande

autorisaties in de systemen te bekijken (IST-situatie) en van daaruit rollen te definiëren (SOLL-

situatie).

903 Scriptie Hendriks en Pots-Zukik - vurore.nl · 2 Definitie en voorbeelden voor...

Documents

Transcript of 903 Scriptie Hendriks en Pots-Zukik - vurore.nl · 2 Definitie en voorbeelden voor...