R O L E B A S E D A C C E S S C O N T R O L

Transcriptie

1 R O L E B A S E D A C C E S S C O N T R O L september 2010 S U R F N E T B V, R A D B O U D K W A R T I E R 273, P O S T B U S 19035, 3501 D A U T R E C H T T , F , WWW. S U R F NET. NL

2 I N H O U D 1. Inleiding Aanleiding Doelstelling Doelgroep Werkwijze en leeswijzer Wat kun je met RBAC bereiken? Afbakening van RBAC Doelen RBAC-begrippen Hoe werken rollen en autorisaties? Wat voor soort rollen zijn er? Hoe ver moet je gaan met rollen? Wat is beter om vooraf te regelen? Basisimplementatie identity management Betrokkenheid en inbreng van Informatiemanagement Eigenaarschap van IdM-systemen Functioneel beheer IdM Beleid informatiebeveiliging Risicoanalyse en classificatiemethoden Aanpak RBAC-traject Eigenaarschap en functioneel beheer Scope van RBAC Beheer van het rollenmodel Aanpak: hoe wordt het rollenmodel initieel geconstrueerd?

3 1. I N L E I D I N G 1.1 Aanleiding De aanleiding om een algemene notitie over Role Based Access Control (verder afgekort als RBAC) te schrijven is gelegen in de audits die de afgelopen jaren in de sector Hoger Onderwijs en Onderzoek zijn uitgevoerd naar de volwassenheid van identity management, informatiebeveiliging en security incident management. De reden dat deze audits zijn uitgevoerd, is om eventuele wet- en regelgeving vóór te zijn, door aan te kunnen tonen dat de sector op de juiste koers zit. Een van de conclusies van die audits was dat RBAC bij de meeste instellingen nog niet is ingevoerd. RBAC komt tegemoet aan de groeiende behoefte om aan te tonen dat aan wet- en regelgeving is voldaan (governance). De toegevoegde waarde van RBAC ten opzichte van identity management in het algemeen ligt in het verhogen van de transparantie. Aangetoond kan worden wie bepaalt welke gebruiker welke rollen krijgt (en dus tot welke systemen deze toegang heeft) en wie bepaalt wat deze gebruiker mag doen (welke bevoegdheden daarbij horen). Daarin speelt ook het beveiligingsaspect een grote rol: authenticatie en autorisatie op basis van rollen is veiliger dan op basis van identiteit. Dat komt enerzijds doordat het aantal autorisaties aanmerkelijk lager is door het werken met rollen (meerdere personen kunnen eenzelfde rol hebben) en dus de kans op fouten afneemt. Anderzijds levert het werken met rollen meer centralisatie op, waardoor de beheersbaarheid en dus ook veiligheid toenemen. Omdat naar verwachting ook in de sector Hoger Onderwijs en Onderzoek meer governance vereist zal gaan worden en beveiliging steeds belangrijker wordt, zeker gezien de behoefte aan federatieve samenwerking, heeft SURFnet opdracht gegeven om deze notitie over Role Based Access Control op te stellen. Naast deze aanleiding zijn er nog meer redenen om RBAC in te voeren. Hiervoor wordt verwezen naar paragraaf 2.2 Doelen. 1.2 Doelstelling Centraal in deze notitie staat de vraag wat RBAC is en wat er bij het inrichten van RBAC komt kijken. Er wordt dan ook maar kort aandacht besteed aan de vervolgvraag: hoe pak je een RBAC-implementatie aan (paragraaf 5.4 Aanpak ). 1.3 Doelgroep De doelgroep van deze notitie is de sector Hoger Onderwijs en Onderzoek, en daarbinnen informatiemanagers, functioneel beheerders van identity management, eigenaren van bron- en doelsystemen, decentrale beheerders, de security officer en de interne auditor. 3

4 1.4 Werkwijze en leeswijzer In deze notitie wordt geïnventariseerd wat er komt kijken bij het inrichten van RBAC. Nadat de te behalen doelen (H. 2) en de gehanteerde begrippen (H. 3) zijn besproken wordt de invoering van RBAC behandeld: Wat is beter om vooraf te regelen? (H. 4), en Aanpak RBAC-project (H. 5). Bij de totstandkoming van deze notitie is dankbaar gebruik gemaakt van de input van een leesgroep in de achterban van SURFnet. 4

5 2. W A T K U N J E M E T R B A C B E R E I K E N? 2.1 Afbakening van RBAC Role Based Access Control maakt onderdeel uit van Identity and Access Management (verder IAM genoemd). Identity management is het geheel van beleid, processen en techniek voor het beheer en gebruik van elektronische identiteitsgegevens en wordt gebruikt om alle vormen van authenticatie en autorisatie te faciliteren. In de Starterkit Identity Management (december 2009) is beschreven hoe een basisimplementatie van identity management het beste kan worden ingevoerd (vijf fasen model). Access management gaat over de wijze van toegang tot en de bijbehorende autorisaties (toegangsrechten) in applicaties. RBAC is een onderdeel van access management, waarmee de toegang tot applicaties op basis van rollen wordt geïmplementeerd. Andere mogelijkheden zijn om de autorisaties te koppelen aan zaken als plaats en tijd, de gebruikte authenticatievorm (wachtwoord, een token, biometrie, etc.), interne of federatieve wijze van inloggen of via single sign-on, in hoeverre het apparaat (PC, mobiel, tablet, etc.) waarmee een gebruiker toegang wil gecontroleerd kan worden, of een combinatie hiervan. De huidige situatie in de sector Hoger Onderwijs en Onderzoek laat zien dat het identity management goed is geregeld voor de belangrijkste applicaties. Access management daarentegen wordt veelal decentraal ingevuld, wat relatief veel handelingen vereist (figuur 1). Figuur 1: Decentrale invulling van access management zoals veelal aangetroffen binnen het HO&O RBAC is een onderdeel van access management. Het eigene van RBAC is dat het de relatie tussen de individuele identiteit en de autorisaties (rechten) van die identiteit loskoppelt. De verzameling van meerdere autorisaties wordt ondergebracht in zogenaamde rollen. De identiteit wordt vervolgens gekoppeld aan de rol waarmee deze de bijbehorende autorisaties krijgt. Door het werken met rollen kan het aantal te verrichten 5

6 handelingen op het gebied van access management sterk verminderen. Daar staat tegenover dat er handelingen bijkomen voor het inrichten en beheren van RBAC zelf. Per saldo zal het totaal aantal handelingen afnemen (figuur 2). Figuur 2: Identity and Access Management Onderstaande figuren 3 en 4 tonen een fictief voorbeeld waarbij de eerste figuur de relaties weergeeft tussen individuele identiteiten en applicaties zonder dat gebruik wordt gemaakt van RBAC. De tweede figuur illustreert het aantal relaties tussen identiteiten en applicaties met gebruik van RBAC. In beide figuren hebben de identiteiten exact even veel rechten tot de applicaties. De figuren illustreren een duidelijk voordeel van RBAC. In paragraaf 3.1 wordt uiteengezet dat het niet alleen om applicaties gaat, maar ook om objecten. Figuur 3: Autorisaties voor invoering RBAC 6

7 Figuur 4: Autorisaties na invoering RBAC 2.2 Doelen Met de invoering van RBAC kunnen de volgende doelen worden bereikt. Het belang van elk van deze doelen kan per organisatie verschillend gewogen worden. Verbeteren van transparantie en governance Door de identity- en access management processen compleet in te richten, inclusief RBAC, wordt er vanuit het oogpunt van de onderwijs- en andere bedrijfsprocessen voor gezorgd dat medewerkers en studenten alleen tot die informatie en systemen toegang hebben die nodig zijn voor hun werk of studie (op dit moment gebeurt dat vaak vanuit de kennis van de mogelijkheden van de IT applicaties en is er een beperkte afstemming tussen onderwijs- en bedrijfsprocessen en IT). Hiermee kan worden aangetoond dat een instelling serieus werkt aan het in control en compliant zijn ten aanzien van geldende wet- en regelgeving, zoals de Wet Bescherming Persoonsgegevens, en interne regels. Hierbij wordt het faciliteren van structurele controle op de rechtmatigheid van uitgegeven autorisaties eenvoudig mogelijk. Handhaven en verbeteren van het niveau van informatiebeveiliging Doordat autorisaties worden geclusterd en gekoppeld aan een rol, is altijd duidelijk wat een rol mag of kan. Doordat identiteiten worden gekoppeld aan rollen, is daarmee altijd inzichtelijk wie toegang heeft tot welke informatie. Door centraal vast te stellen wie rollen kan aanmaken of beheren, is het geheel van informatiebeveiliging beter in beeld. Verbeteren van de beheersbaarheid Standaardisatie is binnen het informatiebeleid een belangrijk concept. Door identity and access management zowel technisch als functioneel (procesmatig) verder te standaardiseren, kunnen de procedures binnen de organisatieonderdelen voor het aanvragen en toekennen van autorisaties worden gestandaardiseerd, verminderd en/of worden ingericht als deze nog niet bestaan. Kostenbeheersing RBAC maakt het mogelijk om eenvoudig te bepalen wie toegang moet hebben tot welk materiaal. Door dit middel in te zetten, bestaat de mogelijkheid kosten te besparen op 7

8 bijvoorbeeld softwarelicenties. Denk bijvoorbeeld aan het toekennen van fotobewerkingssoftware alleen aan die studenten die dit daadwerkelijk nodig hebben voor de studie. Hierdoor hoeft geen campusbrede licentie te worden afgesloten wat besparingen op kan leveren. Verbeteren van gebruiksgemak Als de beheersbaarheid van het aanvragen en toekennen van autorisaties verbetert, worden gebruikers sneller voorzien van de juiste rechten, hetgeen een kortere doorlooptijd met zich meebrengt. Door voorgedefinieerde rollen kunnen ook bepaalde autorisaties standaard worden doorgevoerd op basis van de positie of aanstelling van een medewerker in de organisatie. Dat heeft als voordeel dat niet alle serviceaanvragen met losse autorisatieverzoeken door betreffende leidinggevende expliciet moeten worden goedgekeurd. Medewerkers zullen dus door vergrote inzichtelijkheid en standaardisatie sneller over de juiste autorisaties beschikken en daarmee sneller toegang krijgen tot informatie. Daardoor is minder ondersteuning nodig vanuit de beheerorganisatie. Daarnaast bestaat nog een andere vorm van gebruiksgemak. Door gebruik te maken van rollen, kan een docent op het juiste moment het juiste materiaal beschikbaar stellen aan studenten. Dit voorkomt een data-overkill en zorgt er voor dat de student op het juiste moment over precies voldoende informatie beschikt om optimaal te kunnen studeren. Verbeteren van functiescheiding Door het centraal, maar in overeenstemming met beleid van de verschillende organisatieonderdelen, coördineren van rollen kan de benodigde functiescheiding beter worden gerealiseerd en inzichtelijk worden gemaakt. Tijdens de rollendefinitie, en achteraf bij audits, kunnen interne auditors een advies geven over autorisaties die niet in één functie verenigd mogen worden, en daarmee ook over rollen die niet zonder meer aan dezelfde persoon mogen worden toegekend. Op basis van deze adviezen kunnen functiescheidingsregels opgenomen worden waardoor ongewenste koppelingen geblokkeerd worden of een waarschuwing genereren. Als de autorisaties eenmaal zijn vastgesteld voor de specifieke rollen (clustering) kan een centraal autorisatiebeleid worden gevoerd. Vervolgens kunnen de (uitvoerende) verantwoordelijkheden met betrekking tot het autoriseren van medewerkers decentraal belegd worden. Verbeteren van controleerbaarheid Identity and access management kan monitoring en audit -mogelijkheden bieden voor de interne, externe en ad-hocverzoeken voor rapportages. Dit heeft als gevolg dat autorisaties en (realtime) informatie hierover beter en sneller ter beschikking komt. Uiteindelijk biedt dit IAM-proces de mogelijkheid om aantoonbaar in control te zijn ten aanzien van wie waartoe toegang heeft. Een groot voordeel van het RBAC-model is dat als een audit uitgevoerd moet worden, het aantal relaties dat aan de audit onderhevig is vele malen kleiner is dan bij rechtstreekse relaties van gebruikers aan applicaties of aan functionele autorisaties. 8

9 3. R B A C - B E G R I P P E N 3.1 Hoe werken rollen en autorisaties? Identity and access management is in feite de verbindende schakel tussen de organisatie en haar IT. Het verbindt organisatiekenmerken, zoals het organogram, functies en taken aan IT-toepassingen, zoals , ELO en intranet (figuur 5). Binnen het IT-domein wordt onderscheid gemaakt naar de harde IT, met technische autorisaties en de zachte IT met functionele autorisaties die vanuit de business gedefinieerd worden. Figuur 5: De koppeling tussen organisatie en IT wordt gevormd door IAM Zoals eerder beschreven wordt met RBAC niet langer een rechtstreekse relatie gelegd tussen een identiteit en autorisaties. Dit gaat middels een relatie van een identiteit aan een rol en van een rol aan autorisaties van een object. Een object is iets waartoe een gebruiker toegang kan krijgen, bijvoorbeeld een applicatie, een deel van een applicatie, een database, een document, een map, een client of een andere elektronische entiteit. Bij een document bijvoorbeeld kun je rechten hebben om dit te bewerken of te lezen. Dat noemen we een autorisatie. Autorisaties bestaan op twee niveaus; technisch en functioneel. Technische autorisaties zijn het laagste niveau van autorisatie (acces control) waarbij bepaald wordt of het recht ten aanzien van een attribuut aan of uit staat (bijvoorbeeld: recht om veld titel te bewerken staat aan; het recht om veld Rechten toekennen aan gebruikers staat uit). Een bundeling van deze rechten vormen de zogenaamde functionele autorisaties. De functionele autorisatie is dus een verzameling van aan/uit - en ja/nee -voorwaarden die samen een, voor mensen begrijpelijke, set van rechten vormen. Een voorbeeld: Een persoon krijgt het recht leesrechten op een document. Het recht leesrechten is de functionele autorisatie. Deze leesrechten zijn opgebouwd uit meerdere technische autorisaties zoals bijvoorbeeld: is allowed to edit title field = no en Can write in meta data fields = 0. Een rol is een, door de organisatie bepaalde, samenstelling van rechten en bevoegdheden. Bijvoorbeeld de rol docent bedrijfskunde. De rol docent bedrijfskunde moet toegang hebben tot zowel het lesmateriaal van bedrijfskunde als het medewerkers deel van het intranet. Om die reden zal de rol docent bedrijfskunde aan een verzameling van functionele autorisaties gekoppeld moeten worden waaronder de functionele autorisatie docenten toegang intranet en toegang lesmateriaal bedrijfskunde maar ook die van toegang docenten. 9

10 Hoe je identiteiten (uit de organisatie) kunt koppelen aan applicaties (objecten, in de IT) is in figuur 6 weergegeven. Er is een hoofdindeling in vier blokken te zien (het 3 e blok bestaat uit 2 delen). Het model wordt op een volgende pagina in een voorbeeld uitgewerkt. De vier blokken: 1. Elektronische identiteit (kortweg identiteit genoemd): een aantal kenmerken, herleidbaar tot een natuurlijke persoon in de organisatie / instelling. Elke organisatie bepaalt zelf uit welke kenmerken een identiteit bestaat. 2. Rol: een aan een functie, plaats in de organisatie of taak gerelateerde omschrijving van werkzaamheden / activiteiten. Voorbeelden van rollen zijn: medewerker, student, of meer specifiek secretaresse, lid van de faculteitsraad, etc. 3.a Functionele autorisaties: de rechten die een persoon heeft binnen een object (zie 4). Vaak is het mogelijk om een aantal technische autorisaties (zie 3.b) te aggregeren, waarmee meer functionele rechten kunnen worden bepaald, die dan bestaan uit een groep van technische instellingen. Dit kan binnen een object of over objecten heen. Denk aan een aggregatie die leidt tot de autorisatie de beheerder van het intranet van een organisatieonderdeel. 3.b Technische autorisaties: Dit betreft de individuele rechten die in een applicatie kunnen worden aangebracht (de vertaling van permissies naar harde techniek). Denk aan leesrechten en schrijfrechten voor een map of een webpagina, etc. Als bij een taak uitsluitend leesrechten horen, dan wordt ergens in de techniek de schrijfrechten op uit gezet. 4. Object: vaak een applicatie of onderdeel van een applicatie en/of de content van een applicatie (document, veld in een database, e.d.). Figuur 6: Het vierblokkenmodel Bij de figuur moeten een aantal kanttekeningen worden geplaatst: 1. Om de voordelen van RBAC optimaal te benutten moeten drie hoofdvragen altijd beantwoord kunnen worden: - Wie bepaalt welke gebruiker welke rol(len) krijgt? - Wie bepaalt wat een rol mag d.w.z. welke functionele autorisaties gekoppeld worden aan een rol? 10

11 - En wie bepaalt welke functionele autorisaties er zijn en wat ze kunnen? Het kunnen beantwoorden van deze vragen is een voorwaarde voor governance; je kunt daarmee aantonen hoe de beheerverantwoordelijkheden ten aanzien van RBAC liggen. De rollen worden gedefinieerd vanuit de business. De functionele autorisaties worden in samenspraak tussen business en de IT gedefinieerd en wel in termen waar de business iets mee kan. De technische autorisaties worden door de IT gedefinieerd (de vertaling van functionele autorisaties naar techniek). Wanneer er iets in de IT verandert, dan heeft dat meestal weinig invloed op de vastgestelde rollen. Wel kan een nieuwe versie van een applicatie met nieuwe mogelijkheden leiden tot een nieuwe meer efficiënte werkwijze. Een nieuwe werkwijze kan vragen om verfijning van autorisaties, etc. 2. Er moet bepaald worden wat onder elk van de 4 hieronder benoemde beheerstaken (gebruikers, rollen, autorisaties en applicaties) verstaan moet worden en wie daarvoor verantwoordelijk is. - Gebruikersbeheer: het beheer van identiteiten (persoonlijke kenmerken), die gekoppeld worden aan één of meerdere rollen. Gebruikersbeheer vindt plaats in de bronsystemen. Voor identiteiten van medewerkers doet HRM dit meestal, voor identiteiten van studenten veelal Studiezaken, voor derden is dit vaak decentraal belegd. - Rollenbeheer: het bewaken dat door de organisatie heen dezelfde omschrijving (met bijbehorende autorisaties) wordt gehanteerd van een eenmaal vastgestelde rol (ook als het beheer daarvan decentraal belegd is). Een instelling doet er verstandig aan om de functie van rollenbeheerder te introduceren om in control te kunnen blijven (zie ook paragraaf 5.4) - Autorisatiebeheer: dit is voor 90% applicatiebeheer; dit is het beheren van technische en functionele autorisaties. Het koppelt de autorisaties aan objecten. Hier valt ook het beheer van individuele koppelingen tussen identiteiten en functionele autorisaties onder (dus zonder tussenkomst van een rol, denk aan een financieel directeur die een medewerker expliciet autorisatie geeft om betalingen te verrichten). - Objectbeheer: applicatiebeheer door IT. Van belang is dat de diverse beheerders in het oog houden dat er door de jaren heen bij de uitvoering van RBAC geen wildgroei ontstaat, met name bij de decentrale toekenning van rollen. Het gevaar dat het IT-domein eenzijdig functionele autorisaties definieert, zonder inbreng vanuit de business, kan afgedekt worden door de rollenbeheerder expliciet de taak te geven hier coördinerend op te treden. Daarnaast verzorgt de rollenbeheerder het life cycle management voor rollen. 3. De overgangen (koppelvlakken) tussen de 4 segmenten (en hun beheerders) zal beschreven moeten worden, en ook hier: wie is daarvoor verantwoordelijk? In dat kader wordt hier uitgelegd hoe de gepresenteerde pijlen moeten worden geïnterpreteerd: - Van identiteiten naar rollen: In het bronsysteem wordt vastgelegd bij welke hoofdrol een identiteit hoort. Vervolgens wordt in de RBAC-module de relatie vastgelegd tussen de identiteit en de overige rollen. Dit wordt gedaan door 11

12 (de)centrale beheerders van de RBAC-module op basis van vooraf vastgestelde criteria. Hiermee wordt bepaald welke identiteiten onderdeel zijn van welke rol. - Van identiteiten rechtstreeks naar functionele autorisaties: wanneer het niet mogelijk is om via een rol tot functionele autorisatie te komen, kan een identiteit rechtstreeks aan een functionele autorisatie worden gekoppeld. - Van rollen naar (functionele) autorisaties: Rollen worden gekoppeld aan één of meerdere functionele autorisaties. Daarmee wordt de relatie gelegd tussen wat een rol kan en mag ten aanzien van objecten. - Van objecten naar technische autorisaties: de individuele koppeling tussen technische autorisaties en objecten wordt in samenspraak tussen de business en de IT verzorgd (tweezijdige pijl): welke clustering van (technische) autorisaties is handig voor IT en functioneel vanuit de business? Het gewenste resultaat is dat hierover afstemming en overeenstemming ontstaat. In de praktijk kan het vierblokkenmodel er voor medewerkers als volgt uitzien (figuur 7): 12

13 Figuur 7: Het vierblokkenmodel ingevuld voor medewerkers 3.2 Wat voor soort rollen zijn er? Rollen kunnen worden vastgelegd in een model. Zo n model is vaak hiërarchisch. De rollen op het hoogste niveau worden dan hoofdrol genoemd, de overige rollen vaak subrollen. Binnen het hoger onderwijs wordt bijvoorbeeld veel gewerkt met de hoofdrollen medewerker, student, en derde. De hoofdrollen zijn een natuurlijke indeling van de populatie van een organisatie op hoofdlijnen. Voor elke hoofdrol is er altijd life cycle management bepaald. Voor subrollen geldt dat het life cycle management er niet per se voor bepaald is. Als dat niet gebeurt, erft de subrol de life cycle managementregels van een hoofdrol. Daarnaast onderscheiden 13

14 hoofdrollen zich doordat deze zijn ondergebracht in een bronsysteem dat vaak alleen voor die hoofdrol wordt gebruikt (HRM-systeem, studentinformatiesysteem en derdenregistratiesysteem). Omdat niet iedereen binnen een hoofdrol dezelfde rechten nodig heeft, is het noodzakelijk om naast hoofdrollen subrollen te differentiëren. Voorbeeld: niet iedere medewerker heeft toegang tot de financiële administratie en niet iedereen die daar wel toegang tot heeft, heeft dezelfde rechten. Om dit enigszins werkbaar te maken worden de volgende subrollen onderscheiden: Organisatierollen: geven bevoegdheden op grond van de plek binnen de organisatie, waar iemand werkt of studeert: een medewerker aan de faculteit X heeft het recht op toegang tot het besloten intranetdeel van faculteit X. Een student aan faculteit Y krijgt altijd toegang tot de elektronische leeromgeving van faculteit Y. Functierollen: bevoegdheden die iemand op basis van zijn functie krijgt. Bijvoorbeeld: alle lijnmanagers krijgen toegang tot de documenten die door medewerkers van zijn of haar afdeling worden gemaakt en bewerkt. Taakgerichte rollen; op grond van een specifieke taak die een persoon heeft kan er speciale toegang verleend worden. Bijvoorbeeld: iemand is lid van de Faculteitsraad en moet uit dien hoofde toegang hebben tot relevante documenten. Ad-hocrollen (groepen); tijdelijke groepering, die gebruikers zelf aanbrengen, voor bijvoorbeeld studieprojecten. Projectleden krijgen dan toegang tot een projectruimte die één van hen heeft aangemaakt. Het aspect wie mag de rol uitdelen is hier vrijgegeven. Deze indeling lijkt vooral logisch voor medewerkers. Maar ook voor studenten en derden kan toegang op basis van bijvoorbeeld vakgroepen beschouwd worden als onderdeel van functierollen. En zo zijn er ook voorbeelden te bedenken waarbij voor hen soms ook proces- of taakgerichte rollen ingevoerd kunnen worden (lid van de studentenraad). Naast bovengenoemde soorten rollen bestaan er ook plaats- en tijdgebonden rollen. Het is bijvoorbeeld wenselijk dat een beheerder die vanuit huis een stand-bydienst draait om storingen in het instellingsnetwerk te verhelpen, toegang heeft tot de noodzakelijke bestanden. Echter, als hij geen dienst heeft, is het niet wenselijk om hem vanaf zijn thuiswerkplek die toegang te verlenen. De attributen plaats en tijd zitten beide in het gegeven voorbeeld. Merk op dat er dus een koppeling kan bestaan tussen rollen en andere aspecten van access management, zoals genoemd in paragraaf Hoe ver moet je gaan met rollen? Hiërarchisch of stapelen van rollen? Er wordt onderscheid gemaakt tussen hiërarchische rollenmodellen en niet-hiërarchische rollenmodellen. Bij hiërarchische rollenmodellen worden onder een hoofdrol steeds gedetailleerdere rollen opgenomen, zodat er een boomstructuur ontstaat waarbij overerving van autorisaties plaatsvindt. Bij niet-hiërarchische rollenmodellen gebeurt dat niet en worden, onder elke hoofdrol, subrollen los (of: gestapeld) weergegeven. Beide systemen hebben voor- en nadelen. 14

15 De keuze voor een hiërarchisch rollenmodel wordt vaak gemaakt door organisaties die een sterk hiërarchische organisatiestructuur hebben, zoals bijvoorbeeld academische ziekenhuizen. Hierbij wordt de organisatiestructuur vertaald naar een rollenmodel. In de figuur is te zien dat de KNO-arts altijd onderdeel uitmaakt van de bovenliggende groep Artsen en dat de groep Artsen onderdeel uitmaakt van de groep Medisch personeel die weer onderdeel is van de groep Medewerkers. Deze groepen zijn 1 op 1 te vertalen in rollen waaraan de verschillende autorisaties worden gekoppeld (figuur 8). Figuur 8: Hiërarchisch rollenmodel Bij minder hiërarchisch werkende instellingen kan het praktisch zijn om te werken met gestapelde rollen. Naast het toekennen van een hoofdrol wordt de identiteit gekoppeld aan één of meerdere subrollen die niet hiërarchisch georganiseerd zijn (figuur 9). Op deze manier zijn ook rollen toe te kennen die niet in een hiërarchisch model passen. Figuur 9: Gestapeld rollenmodel In de praktijk blijkt dat een groot aantal instellingen en organisaties kiezen voor een gecombineerde inrichting van zowel hierarchische als gestapelde rollen. Hiebij worden de eerste paar lagen in het model hiërarchisch ingericht, waarna overige rollen worden gestapeld. Functiescheiding Het feit dat een of meerdere rollen aan personen toegekend kunnen worden, wil niet altijd zeggen dat die rollen ook toegekend mogen worden. Vanwege interne of externe regelgeving kan het zijn dat bepaalde functies niet verenigd mogen worden in één 15

16 persoon. We spreken dan over Functiescheiding (ook wel Segregation of Duties). Een lijnmanager of proceseigenaar zou hier bij de toekenning van de rollen rekening mee moeten houden. De praktijk leert echter dat niet altijd alle benodigde gegevens beschikbaar zijn om de juiste afweging te maken, bijvoorbeeld door het gebrek aan informatie over alle systeemautorisaties die aan (basis)rollen gekoppeld zijn. Bij geautomatiseerde toewijzing moet hier goed naar gekeken worden. De meeste IAMsystemen hebben mogelijkheden om bij de koppeling van de rollen aan de autorisatie(groepen) controles in te bouwen binnen de daarvoor vast te stellen zogenaamde businessrules. Koppelingen die strijdig zijn met de functiescheidingsregels worden dan niet gemaakt en/of worden gerapporteerd aan het management, dat daarover een expliciet besluit moet nemen. Uiteindelijk is het vangnet voor het bepalen van de juiste functiescheiding een audit of controle. Soorten toegang We onderscheiden twee soorten toegang, namelijk toegang tot een applicatie en toegang binnen een applicatie, waarmee bedoeld wordt dat toegang binnen een verfijning is van toegang tot een applicatie. Niet iedereen heeft bijvoorbeeld dezelfde rechten binnen het financiële systeem. Per applicatie kan een matrix worden gemaakt, waarin aangegeven wordt voor welk soort toegang je welk type rollen mag gebruiken. Een voorbeeld daarvan is de toegang tot intranet. Figuur 10: Verschillende rollen voor toegang tot intranet Iedere medewerker (hoofdrol) heeft toegang tot het openbare deel van intranet. Voor de directie (organisatierol) bestaat een aparte module, waar overige medewerkers geen toegang toe hebben. De directeur HRM (functierol) heeft een apart deel op intranet binnen het directiedeel, waar de personeelsdossiers worden bijgehouden en beheerd. Een specifieke medewerker van de afdeling HRM heeft toegang tot dat stuk van de personeelsdossiers waar individuele CV s worden opgeslagen (taakgerichte rol). Deze taakgerichte rol verschaft alleen toegang tot specifiek de cv s en niet automatisch tot de personeelsdossiers en directiepagina s. Ook voor ad hoc zaken zoals een tijdelijke projectgroep kan toegang geregeld worden. 16

17 Medewerkers die tijdelijk een taak van een collega overnemen (met andere rollen en bevoegdheden) zullen tijdelijk voorzien moeten worden van die nieuwe bevoegdheden. Dat geldt ook voor externe krachten die tijdelijk aan een intern project werken of studenten die eenmalig in een projectgroep samenwerken. Het koppelen van een vervaldatum aan de nieuwe bevoegdheden moet er voor zorgen dat deze niet eeuwigdurend worden. 17

18 4. W A T I S B E T E R O M V O O R A F T E REGELEN? RBAC op zichzelf kan ingericht worden zonder dat andere delen van IAM zijn ingericht. Om RBAC succesvol in te richten is het aan te raden om de volgende onderdelen op orde te hebben voordat gestart wordt met de implementatie. Daarbij is het raadzaam om bij de invoering gefaseerd te werk te gaan. 4.1 Basisimplementatie identity management Idealiter is de basisimplementatie van identity management op orde. Gegevensbeheer van identiteiten voor medewerkers, studenten en derden is belegd en ingericht in bronsystemen. Er is een identity managementsysteem aanwezig dat de doelsystemen voorziet van de juiste identiteitsgegevens. Daarmee is bewust of onbewust binnen de meeste instellingen een basisimplementatie van hoofdrollen aanwezig. De hoofdrollen worden onderscheiden in bronsystemen en het identity management is voor deze rollen ingericht. Met behulp van deze hoofdrollen is toegang tot applicaties geregeld. Voorbeeld: alle medewerkers krijgen toegang tot het algemene deel van de intranetsite, elke student heeft toegang tot de elektronische leeromgeving, etc. Wanneer een persoon zowel medewerker als student is, zijn er twee opties: 1. hij krijgt twee identiteiten toebedeeld met bijbehorende rollen en autorisaties. Daarmee gaat de persoon binnen de instelling door het leven als twee compleet gescheiden identiteiten. Daarmee krijgt hij bijvoorbeeld één adres als medewerker en één als student. Er zal voor gewaakt moeten worden dat er geen mogelijkheid is om in de rol medewerker de eigen studieresultaten aan te passen; dat betekent dat sommige subrollen moeten worden uitgesloten (functiescheiding). 2. in het identity managementsysteem worden de gegevens uit de verschillende bronsystemen geaggregeerd tot één identiteit. Deze identiteit wordt gekoppeld aan de benodigde rollen. Ook hier zullen beperkingen in bepaalde autorisaties moeten worden ingeregeld. Ongeacht welke oplossing gekozen is, zal de keuze invloed hebben op de inrichting van RBAC. 4.2 Betrokkenheid en inbreng van Informatiemanagement Informatiemanagement houdt zich bezig met de wijze waarop organisaties nu en in de toekomst op een effectieve en efficiënte wijze in hun informatiebehoefte kunnen voorzien. Bij de meeste onderwijsinstellingen is de afdeling Informatiemanagement, die centraal in de organisatie is gepositioneerd, hiervoor verantwoordelijk. Deze afdeling is in elk geval verantwoordelijk voor de hoofdlijnen (beleid) van het informatiemanagement; de uitvoering ervan vindt soms decentraal plaats. Bij de afdeling Informatiemanagement valt ook (het beheer van) de hoofdstructuur van het identity-managementsysteem. Die hoofdstructuur (c.q. informatiearchitectuur) zal geschikt gemaakt moeten worden voor de implementatie van RBAC: beschrijving van de rollen, vaststellen beheermodel, classificatie van data. Het beste kan dat samen met 18

19 proceseigenaren en gebruikers bepaald worden. De afdeling Informatiemanagement zal de coördinatie hiervan op zich nemen. 4.3 Eigenaarschap van identity-managementsystemen Er moeten in de organisatie afspraken gemaakt zijn wie eigenaar is van bronsystemen, van het identity management systeem en van de bedrijfsprocessen die daarvan afhankelijk zijn. Hoewel de afdeling Informatiemanagement coördinerend optreedt met betrekking tot het beleid en de hoofdstructuur van de informatievoorziening, is het heel goed mogelijk dat het eigenaarschap elders ligt. Systemen die bedrijfsprocessen ondersteunen kunnen het eigendom zijn van de eigenaar van die bedrijfsprocessen of ze kunnen vallen onder bijvoorbeeld een CIO. Hoe dan ook, het eigendom (en het beheer) moet belegd zijn, anders is onvoldoende duidelijk wie waar voor verantwoordelijk is. 4.4 Functioneel beheer identity management Functioneel beheer van identity management is een min of meer logisch uitvloeisel van informatiemanagement en maakt onderdeel uit van de basisimplementatie. Aangegeven moet worden aan welke eisen applicaties in de informatiearchitectuur moeten voldoen. Dit moet ook gecontroleerd worden. Denk hierbij aan: het (laten) opstellen van functionele specificaties, het (laten) uitvoeren van het beheer, zorgen voor dekking van de kosten, bewaking van de werking van de architectuur, e.d. 4.5 Beleid informatiebeveiliging Naast informatiemanagement is ook beleid met betrekking tot informatiebeveiliging een noodzakelijke voorwaarde voor het succesvol implementeren van RBAC. Het informatiebeveiligingsbeleid is het middel waarmee vastgesteld kan worden welke assets door de toepassing van RBAC beschermd moeten worden. 4.6 Risicoanalyse en classificatiemethoden Belangrijk onderdeel van het informatiebeveiligingsbeleid vormen de risicoanalyse en de daarop gebaseerde classificatiemethodiek. Bij een risicoanalyse worden bedreigingen voor de informatievoorziening benoemd en in kaart gebracht. Per bedreiging wordt de kans van optreden bepaald en wordt vervolgens berekend wat als gevolg de schade is die zou kunnen optreden als een bedreiging zich daadwerkelijk voordoet. Op grond van dit beeld wordt het niveau van maatregelen vastgesteld. Met het classificeren van gegevens wordt bereikt dat per object (gegeven, gegevensgroep, gegevenssoort) wordt aangegeven hoe belangrijk het gegeven is voor de bedrijfsvoering. In relatie tot RBAC zijn met name integriteit en vertrouwelijkheid erg belangrijk. Daardoor komen classificaties als vertrouwelijk, cruciaal of geheim veelvuldig voor. 19

20 De classificatie kan worden gebruikt om de verscheidenheid (diepgang) in rollen te bepalen die voor een systeem worden gebruikt. Het is evident dat een systeem dat alleen niet-vertrouwelijke data bevat voor wat betreft het lezen van de data een geringe verscheidenheid in rollen nodig heeft. Omgekeerd is het vaak zo dat een systeem dat wel vertrouwelijke data bevat meer rollen nodig heeft. Maar dat laatste is natuurlijk geen wet van Meden en Perzen. Er kan sprake zijn van informatie die alle medewerkers van een organisatie mogen zien, maar die buiten de organisatie niet mag worden ingezien. In dat geval kan toch worden volstaan met een gering aantal rollen. Het is noodzakelijk dat iedere instelling een beeld heeft van de waarde van informatie en in de bedrijfsvoering daarmee rekening houdt. Het hebben van een classificatiesysteem is een noodzakelijke voorwaarde voor een veilig RBAC-systeem. Het toekennen van meta data aan objecten is een andere manier van classificeren, die gebruikt kan worden voor het ontsluiten van rechten aan rollen. Denk bijvoorbeeld aan het classificeren van een reader, waarbij in de meta data is opgenomen lesmateriaal voor derdejaars studenten. Door de rol derdejaars studenten te koppelen aan het recht lesmateriaal voor derdejaars studenten krijgt iedereen die toegang heeft tot die rol automatisch toegang tot het lesmateriaal. Met behulp van classificatie kan dus bepaald worden hoe ver je wilt gaan met het koppelen van een rol aan een object. 20

21 5. A A N P A K R B A C - T R A J E C T 5.1 Eigenaarschap en functioneel beheer Zoals in hoofdstuk 4 is aangegeven, zijn onder andere eigenaarschap en functioneel beheer noodzakelijke voorwaarden voor identity management. Voor de implementatie van RBAC zal aanvullend invulling gegeven moeten worden aan beide aspecten. Wie is de eigenaar van rollen? Wie is verantwoordelijk voor rollenbeheer? Wie is verantwoordelijk voor een goede toepassing van functiescheiding? Deze zaken moeten worden vastgelegd, gecommuniceerd met betrokkenen en nageleefd. 5.2 Scope van RBAC Eerst de concernsystemen Vaak is het vanuit een centrale verantwoordelijkheid alleen haalbaar om RBAC in te voeren voor de concernsystemen, die meestal door de centrale IT-dienst worden geleverd. Het gaat hierbij om de (ondersteunende) bedrijfsprocessen, zoals onderwijs, onderzoek, financiën, HRM, e.d. Met de focus op concernsystemen is het mogelijk grotendeels aan de te behalen doelen te voldoen (zie hiervoor paragraaf 2.2). De overige systemen zijn vaak decentraal en worden door de decentrale eigenaren beheerd en bekostigd. Zodra RBAC centraal is ingeregeld, kunnen ook deze systemen worden meegenomen. Dit sluit aan bij de lopende ontwikkeling dat veel instellingen op een meer centrale wijze gaan voorzien in hun IT-services. Diversiteit van rollen Binnen elke hoofdrol hebben we onderscheid gemaakt tussen functierollen (bevoegdheden op basis van iemands functie), organisatierollen (bevoegdheden op basis van iemands positie binnen de organisatie), taakgerichte rollen (bevoegdheden op grond van iemands specifieke taken) en ad-hocrollen (tijdelijke samenwerkingsverbanden). Vaak zijn functierollen en organisatierollen een gegeven. Daarvan zullen er ook niet al te veel zijn binnen een organisatie. Anders is dat met taakgerichte rollen, want daarmee kunnen speciale situaties en uitzonderingen in het systeem geïmplementeerd worden en het aantal daarvan kan groot zijn. Naar verwachting zal daarover ook de meeste discussie ontstaan. Op zich is dat niet erg; deze categorie leent zich uitstekend voor decentrale verfijning indien nodig. 5.3 Beheer van het rollenmodel Er zullen maatregelen genomen moeten worden om het onderhoud, het beheer en de beheersbaarheid van rollen zo eenvoudig mogelijk te houden. Daarvoor is het aanstellen van een rollenbeheerder aan te raden. De rollenbeheerder is verantwoordelijk voor een zo uniform mogelijk gebruik van rollen en voorkomt wildgroei van rollen. 21

22 Figuur 11: Rollenbeheer en de positie van de rollenbeheerder 1. Proceseigenaar vraagt nieuwe rol aan en krijgt reactie rollenbeheerder (wel/niet akkoord) 2. Verwerking aanvraag in server voor rollenbeheer (RBAC-module IAM-systeem) 3. Gebruik nieuwe rol door proceseigenaar Aanvragen voor nieuwe rollen worden door de rollenbeheerder behandeld en de definitie zal door alle organisatieonderdelen gebruikt worden. Het is niet verplicht om een nieuwe rol te gebruiken, maar als je het doet, dan volgens het door de rollenbeheerder bepaalde algemeen gebruik. Het wijzigen van rollen loopt via de rollenbeheerder, die dit afstemt met de proceseigenaren en andere belanghebbenden. De rollenbeheerder kan adviseren om rollen automatisch toe te kennen aan identiteiten. Zo ja, dan wordt het in de provisioning meegenomen. De rollenbeheerder bepaalt samen met de proceseigenaar (eigenaar van bedrijfsprocessen, zoals HRM, financiën, onderzoek of IT) hoe de autorisaties bij deze rol eruitzien. De rollenbeheerder ziet er ook op toe dat lokaal gebruikte rollen aan van te voren omschreven vereisten voldoen, bijvoorbeeld door gemeenschappelijk geformuleerde standaarden te hanteren. Het handmatig toekennen van rollen aan identiteiten via een procedure of via een applicatie gebeurt door de proceseigenaren van werkprocessen. 5.4 Aanpak: hoe wordt het rollenmodel initieel geconstrueerd? Top-down of bottom-up? Bij het ontwikkelen van rollen kan men zich afvragen welke methode gebruikt moet worden: top-down (vanuit de business) of bottom-up (vanuit IT)? Binnen de IT kan men in de diverse systemen (bottom-up) vaststellen welke autorisaties zijn uitgedeeld om deze vervolgens te bundelen tot functionele autorisaties. Vervolgens 22

23 worden deze gekoppeld aan rollen. Voordeel van deze methode is dat men relatief snel een aantal rollen kan vaststellen op basis van bestaande autorisaties. Nadeel van deze methode is dat dergelijke autorisaties vaak in het verleden ongestructureerd zijn ontwikkeld en niet getoetst zijn aan een centraal vastgesteld model of aan de behoefte van de organisatie. Daardoor dreigen er enorme aantallen rollen te ontstaan, die feitelijk nauwelijks van elkaar verschillen. Bovendien kunnen er autorisaties zijn gerealiseerd die feitelijk niet toegestaan zijn (functiescheiding), maar die door het uitblijven van incidenten (nog) niet tot problemen hebben geleid. Er ontbreekt dan echter een mechanisme of een procedure om deze rollen terug te brengen tot een set rollen die afdoende zijn om op een verantwoorde manier hetzelfde bedrijfsproces of meerdere bedrijfsprocessen te ondersteunen. Hiervoor kan een proces van eliminatie worden ingericht, waarbij de rollenbeheerder kijkt of a) de rol past binnen de afgesproken structuur en b) of de permissies wel kloppen. Het ontwikkelen van rollen vanuit de bedrijfsprocessen en dus vanuit de business (topdown) heeft om die reden de voorkeur. Maar ook hier kleven nadelen aan. De bedrijfsprocessen zijn lang niet altijd goed gedocumenteerd en onderhouden en procesaanpassingen zijn vaak doorgevoerd op basis van organisatorische of technische omstandigheden, terwijl feitelijk gekozen had kunnen worden voor aanpassingen in de organisatie of de techniek. Een strikte businessinsteek kan dan leiden tot lange, moeizame definitieprocessen en daarmee (te) lange doorlooptijden tot de eerste resultaten. Een combinatie van top-down en bottom-up lijkt hier de beste weg. Op die manier kunnen business en IT van elkaar leren en elkaars referentiekader overnemen. Voor complexe processen kan in eerste instantie gekozen worden voor grofmazige rollen, gekoppeld aan individueel maatwerk, waarbij pas later een verdere diepgang wordt aangebracht (eventueel in combinatie met organisatorische en technische ontwikkelingen). Hoe gaan we praktisch te werk? In deze paragraaf beschrijven we kort de methode en aanpak om te komen tot de opzet van RBAC. 1. Scope en ambities vastleggen In deze projectstap wordt onderzocht waaraan de organisatie behoefte heeft (creëren draagvlak), waarna wordt vastgelegd wat allemaal onder het project valt (alleen concernsystemen of ook decentrale systemen, faseringen (eerst medewerkers, dan pas studenten, worden bepaalde locaties uitgezonderd, e.d.) en welke ambities (doelen) men nastreeft (is governance het hoofddoel of gaat het meer om het verbeteren van het gebruiksgemak en de beheersbaarheid). Bij de bepaling van de scope wordt -kwalitatiefook gekeken naar de kwetsbaarheid van informatie (BIV-classificatie); in stap 5 gebeurt dit meer kwantitatief en op een lager abstractieniveau. Het project wordt belegd bij een formele opdrachtgever, bijvoorbeeld de CIO of iemand van informatiemanagement. 2. Terugkoppeling scope en ambities Met deze stap wordt mandaat voor het uitvoeren van het RBAC-project verkregen door de scope en ambities met het bestuur of de informatiemanager van de instelling te bespreken. Hiermee worden tevens eventuele misverstanden over de reikwijdte van het project weggenomen (verwachtingsmanagement). De hoofdlijnen van de inhoud van het 23

24 project en de beschikbaarheid van financiering en menskracht zijn vastgesteld. De projectgroep kan worden ingericht. 3. Beschrijving rollen Rollen, voor zover al bekend, worden beschreven. Rollen kunnen bijvoorbeeld tot stand komen omdat de instellingen een (complete) set procesbeschrijvingen heeft, waarin functies genoemd zijn (bijvoorbeeld het inkoopproces). Het digitaal oogsten van bestaande rollen is een andere manier om te komen tot rollen, maar het risico bestaat dat vergelijkbare zaken op sterk verschillende manieren beschreven zijn, waardoor zowel van overzicht als van vereenvoudiging geen sprake is (zie ook top-down of bottom-up ). De voorkeurswijze van het vaststellen van rollen verloopt op hoofdlijnen langs beschreven businessprocessen, maar wel in afstemming met IT. Onderdeel van deze fase is een eerste ruwe bepaling en beschrijving van: Rollenbeleid: - scope van het rollenbeleid: instellingsbrede definities versus specifieke applicaties, domeinen of een combinatie van beide? - het bepalen van het rollengebruik: onder welke omstandigheden en voorwaarden kunnen de rollen gebruikt worden? Rollendefinitie: - rollenontwikkeling en beheer: top-down ontwikkelen of bottom-up, of een combinatie van beide? - rollenmodel (hiërarchisch of gestapeld): bepaal welk rollenmodel in welke situatie gewenst is; - koppelen van rollen aan autorisaties (permissies): hoe zouden rollen gedefinieerd en geaggregeerd moeten worden? - functionele diepgang van rollen: zouden rollendefinities allesomvattend moeten zijn en de meeste (of bijna alle) functies moeten omvatten, of zouden rollendefinities gericht moeten zijn op uitsluitend de kritieke functies van een applicatie? - rollenrelaties: zouden rolobjecten georganiseerd moeten worden in een gestapeld of in een hiërarchisch model of een hybride oplossing? 24

25 4. Vaststellen beheermodel Hoe wenst de instelling de rollen te beheren: deels centraal, deels decentraal of alleen centraal? En welke bevoegdheden voor het toekennen van decentrale rollen worden dan waar precies belegd? Onderdeel van deze fase is een eerste ruwe bepaling en beschrijving van: Rollenmanagement: - toewijzing van rollen: zouden gebruikers rollen automatisch toegewezen moeten krijgen of zou dit op basis van een aanvraag moeten gebeuren? - rapportage & audit van rollen: hoe kan de business de kwaliteit van het autorisatieproces monitoren en aantonen dat men voldoende in control is? 5. Classificatie van objecten Voor de mate van verfijning in rollen maakt het uit hoe gevoelig de gegevens zijn waarmee gewerkt wordt. Vaststellen van het gewenste beveiligingsniveau door middel van een BIV-classificatie (beschikbaarheid, integriteit, vertrouwelijkheid) is gewenst. Uitkomst van deze stap kan zijn dat systemen die bepaalde vertrouwelijke informatie bevatten (bijvoorbeeld patiëntinformatie) meer rollen nodig hebben (bijvoorbeeld voor verschillende medische disciplines/vakgroepen, wel/niet inzien, wel/niet wijzigen, e.d.), dan andere systemen. Daarnaast is het wenselijk na te gaan in hoeverre individuele objecten geclassificeerd moeten worden om eenvoudige ontsluiting op basis van rollen mogelijk te maken. 6. Workshop met businessdeelnemers Hier wordt een eerste opzet gemaakt voor een rollenmodel, vanuit de business geredeneerd. De ruwe beschrijvingen van rollenbeleid, rollendefinitie en rollenmanagement worden aangepast en uitgewerkt. Deelnemers in deze workshop zijn leden van het College van Bestuur en de directie IT. 7. Workshop proceseigenaren Het voorlopige rollenmodel wordt in een workshop met proceseigenaren doorgenomen en zo nodig bijgesteld. De discussie dient heel concreet te zijn en betrekking te hebben op de werkprocessen. Deelnemers in deze workshop zijn de proceseigenaren van het primaire proces en de ondersteunende processen, zoals onderwijsmanagers, vakgroephoofden, hoofd HRM, etc. 8. Analyse workshopresultaat en zo nodig bijstellen rollenmodel Op basis van de workshops wordt het definitieve rollenmodel bepaald en teruggekoppeld aan de opdrachtgever. 9. Inrichting organisatie De organisatie wordt (geleidelijk) zodanig ingericht dat met rollen gewerkt kan worden; geen big bang scenario s, maar een geleidelijke introductie. Faseren is nuttig: doe de eerste implementatie op (centraal) beheerniveau. Ook daar zie je verschillende rollen 25

26 met hun verschillende autorisaties. En als de beheerders gewend zijn aan RBAC, dan heb je een groep mensen die de rest van de implementatie goed kan begeleiden. Kies daarna voor een basisimplementatie voor één doelgroep, bijvoorbeeld medewerkers, en faseer daarbinnen naar applicatie. Daarna de andere doelgroepen (studenten en derden) per applicatie. Scholing van decentrale beheerders en workshops om het rollengebaseerd werken goed tussen de oren te krijgen verhogen de slagingskans. 10. Evaluatie aanpak en eventueel bijstelling Na de eerste implementatie volgt een evaluatie van de gevolgde aanpak en zo nodig een bijstelling voordat het rollenmodel in de hele organisatie wordt uitgerold. Bij de evaluatie worden betrokken de proceseigenaren van het primaire proces en de ondersteunende processen, zoals onderwijsmanagers, vakgroephoofden, hoofd HRM, etc. 11. Rapportage en invoering in de gehele instelling Na het uitvoeren van de initiële stappen wordt de rest van de organisatie aangepakt en ingericht om met rollen te werken. Communicatie met de diverse organisatieonderdelen is een belangrijke voorwaarde voor het welslagen van de implementatie in de gehele instelling. 12. Audit Het is belangrijk om vast te stellen in welke mate de geformuleerde ambities na afronding van het project gerealiseerd zijn. Hiervoor kan een externe partij een audit uitvoeren, zoals die in het verleden ook al in de sector heeft plaatsgevonden voor de volwassenheid van instellingen op de gebieden identity management, informatiebeveiliging en security incident management. 26

27 Erkenning Bij de totstandkoming van de notitie is dankbaar gebruik gemaakt van de inbreng van een leesgroep uit de SURFnet achterban. In de leesgroep hebben de onderstaande personen geparticipeerd. Peter Oost Els Velraeds Beer Franken Peter Peters Jacques Schuurman Jan Michielsen Erasmus Universiteit Fontys Hogescholen AMC TU Twente SURFnet SURFnet Literatuur Voor wie verder wil volgen hier nog enkele leessuggesties. PvIB PvIB PvIB SURFnet SURFnet Expertbrief Security Architectuur Expertbrief Single Sign On Expertbrief Access Management (deel 1: Visie) Starterkit Identity Management 27