Scriptie ROLE BASED ACCESS CONTROL. Vrije Universiteit Amsterdam. Postgraduate IT Audit Opleiding. Team 903. Danka Pots-Zukik & Marco Hendriks

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

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.

Vrije Universiteit Amsterdam | Inhoudsopgave

2


Scriptie

INHOUDSOPGAVE

0 0

Inhoudsopgave ..........................................................................................................................................................3

1

Inleiding .......................................................................................................................................................................5

2

Probleemstelling .......................................................................................................................................................5

3

Samenvatting..............................................................................................................................................................6

4

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

5

6

4.1

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

4.2

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

4.3

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

4.4

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

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

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 Vrije Universiteit Amsterdam | Inhoudsopgave

3


Scriptie

9

8.2.5

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

8.2.6

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

8.2.7

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

8.2.8

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

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 | Inhoudsopgave

4

Scriptie


INLEIDING

1

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.

PROBLEEMSTELLING

2

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 | Inleiding

5


Scriptie

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?

SAMENVATTING

3

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: •

Is Role Based Access Control nog toepasbaar in het huidige IT landschap? Vrije Universiteit Amsterdam | Samenvatting

6

Scriptie


Het onderzoek toont aan dat een volledige implementatie lastig is. We hebben nergens een eenduidig en centraal beheerd Role Based Access Control systeem aangetroffen. •

Hoe is Role Based Access Control origineel bedoeld of opgezet?

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. •

Op welke manier(en) wordt Role Based Access Control geïmplementeerd? We zien vooral dat RBAC0 en RBAC2 wordt gebruikt. •

Welke overwegingen worden gemaakt ten aanzien van de vraag om Role Based Access Control te implementeren?

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 | Samenvatting

7


Scriptie

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.

Definitie en voorbeelden voor organisatorische, procedurele, en technische maatregelen van `Inleiding EDP-auditing` van Jan van Praat en Hans Suerink.

2

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

Vrije Universiteit Amsterdam | Logische Toegangsbeveiliging

8


Scriptie

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.


9


Scriptie

LTB BELEID

4.3

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.

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.

6


10


Scriptie

BELANGRIJKSTE MODELLEN VAN LOGISCHE

5

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: •

Hoe is Role Based Access Control origineel bedoeld of opgezet?

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.

Vrije Universiteit Amsterdam | Belangrijkste modellen van logische toegangsbeveiliging

11


Scriptie

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.


12


Scriptie

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.


13


Scriptie

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.


14

Scriptie


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.


15

Scriptie


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


16


Scriptie

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 Vrije Universiteit Amsterdam | Role Based Access Control – De modellen

17


Scriptie

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

Vrije Universiteit Amsterdam | Role Based Access Control – De modellen

18


Scriptie

statische functiescheiding (SFS). Volgens de theorie functiescheiding (DFS) ondersteunen. Hierover later meer.

kan

RBAC2

ook

dynamische

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


19

Scriptie


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 transactieniveau intact.


20


Scriptie

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 ‘invoermedewerker 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 transactieniveau intact.


21

Scriptie


KRITISCHE SUCCES FACTOREN VOOR RBAC IMPLEMENTATIE

6.5

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.

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.

17


22

Scriptie

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 bestpractice aanwezig welke stappen men zou moeten nemen om RBAC succesvol te implementeren.

Vrije Universiteit Amsterdam | Conclusie theorie

23


Scriptie

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.

DE BEDRIJVEN

8.2

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: •

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?

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 Vrije Universiteit Amsterdam | Role Based Access Control in de praktijk

24


Scriptie

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.

Vrije Universiteit Amsterdam | Role Based Access Control in de praktijk

25


Scriptie

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. Kritische Succes Factoren om RBAC 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.


26


Scriptie

Belangrijkste mijlpalen gedurende de implementatie: 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. Kritische Succes Factoren om RBAC te implementeren: 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.


27


Scriptie

Belangrijkste mijlpalen gedurende de implementatie: 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.


28


Scriptie

Kritische Succes Factoren om RBAC te implementeren: 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. Belangrijkste mijlpalen gedurende de implementatie: 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. Kritische Succes Factoren om RBAC te implementeren: 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; Vrije Universiteit Amsterdam | Role Based Access Control in de praktijk

29


Scriptie

4. Doe een goed vooronderzoek. Belangrijkste mijlpalen gedurende de implementatie: 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. Kritische Succes Factoren om RBAC te implementeren: 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. Belangrijkste mijlpalen gedurende de implementatie: Voor de branches zijn de mijlpalen gehaald. Voor de hoofdkantoren is RBAC nog niet ingericht. En verder zijn de rapportage mogelijkheden beperkt. Vrije Universiteit Amsterdam | Role Based Access Control in de praktijk

30


Scriptie

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. Kritische Succes Factoren om RBAC te implementeren: 1. Het verkrijgen van support van de businessafdelingen; 2. Centrale aansturing van het RBAC project; 3. Het aanstellen van contactpersonen per businessafdeling. Belangrijkste mijlpalen gedurende de implementatie: 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.


31


Scriptie

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. Kritische Succes Factoren om RBAC te implementeren: 1. Het verkrijgen van support van het business management; 2. Het opzetten van een centraal kenniscentrum. Belangrijkste mijlpalen gedurende de implementatie: 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.


32


Scriptie

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 Control te implementeren? 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 | Conclusie praktijk

33

Scriptie


EINDCONCLUSIE

10

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: •

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

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

34

Scriptie


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 | Eindconclusie

35


Scriptie

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. Vrije Universiteit Amsterdam | Hoe nu verder?

36


Scriptie

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

11.2.2 CONTEXT BASED ACCESS C ONTROL 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. Commentaar schrijvers: 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. Commentaar schrijvers: 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.

Vrije Universiteit Amsterdam | Hoe nu verder?

37

Scriptie


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 | Hoe nu verder?

38


Scriptie

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 A: Literatuurlijst

39


Scriptie

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 B: Interviewverzoek

40


Scriptie

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

41


Scriptie

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 (SOLLsituatie).

Vrije Universiteit Amsterdam | Bijlage C: Gebruikte terminologie

42

Scriptie ROLE BASED ACCESS CONTROL. Vrije Universiteit Amsterdam. Postgraduate IT Audit Opleiding. Team 903. Danka Pots-Zukik & Marco Hendriks

Recommend Documents