Studie Role Based Access Control

Platform Informatiebeveiliging

Studie Role Based Access Control Versie 1.0 November 2005

PI RBAC versie 1.0 doc

Inhoudsopgave Managementsamenvatting 1. Inleiding

3

5

2. Autorisatiebeheer en RBAC 2.1 Introductie 6 2.2 Positionering 7 2.3 RBAC-model 9 3. Normen 11 3.1 Beleid en organisatie 11 3.2 Implementatie/uitvoering 3.3 Beheersing 14

6

13

Bijlage: Relatie naar de Code voor Informatiebeveiliging

16

Literatuur 17

PI-Studie RBAC versie 1.0

2 van 17

Managementsamenvatting Waarom hebben we in deze studie een normenkader voor Role Based Access Control (RBAC) opgesteld? Dit hebben we gedaan omdat organisaties al langer worstelen met deze vorm van beheer. Er is een duidelijke behoefte in de markt ontstaan door onder andere het steeds meer volwassen worden van de IT. Tevens is er een zeer sterke invloed van wet en regelgeving die vereist dat organisaties inzicht hebben en geven in de autorisaties binnen hun systemen. De laatste jaren is de complexiteit en diversiteit van systemen toegenomen wat meestal leidt tot onoverzichtelijkheid van de autorisaties. Ook het verdwijnen van grenzen binnen en buiten de organisatie en doordat organisaties steeds meer klantgericht gaan werken leiden tot een toename van het aantal autorisaties. Dit alles noodzaakt organisaties om op zoek te gaan naar manieren om al deze autorisaties op een beheersbare wijze onder controle te krijgen. RBAC is een van de methoden die wereldwijd steeds meer populariteit geniet. Deze studie voorziet in een aantal behoeften. In de eerste plaats hebben organisaties die RBAC willen gaan implementeren behoefte aan ondersteuning op het gebied van richtlijnen. Dit stelt hun in staat RBAC op een zodanige manier te implementeren en te beheren rekening houdend met de richtlijnen uit dit normenkader. Daarbij voorziet het normenkader in een bepaalde standaard die volgens de deelnemers aan deze studie noodzakelijk is voor een goede RBACimplementatie. In de tweede plaats worden ICT-auditors steeds meer geconfronteerd met RBAC. RBAC is voor deze groep een relatief nieuw aandachtsgebied. Vanuit die ontwikkelingen hebben zij behoefte aan een normenkader op het gebied van “beleid en organisatie”, “implementatie en uitvoering” en “beheersing”. Bij het opstellen van dit normenkader zijn wij niet uitgebreid op alle aspecten van Role Based Access Control ingegaan. Hierover is voldoende recente literatuur voorhanden. Verwijzingen naar de literatuur zijn opgenomen in de bijlage. De studie is als volgt opgebouwd: In hoofdstuk één wordt het doel van het Platform Informatiebeveiliging (PI) beschreven, de werkwijze en degenen die aan deze PI-studie hebben meegewerkt. Het tweede hoofdstuk geeft een beknopte introductie van RBAC. Er wordt aandacht besteed aan autorisatiebeheer op basis van RBAC, de positionering van RBAC, zowel procesmatig als technisch, en er wordt een conceptueel RBAC-model met beheerfuncties besproken. Dit model is gebaseerd op de ANSI INCITS standaard 359-2004. In het derde hoofdstuk zijn de richtlijnen uitgewerkt op het gebied van beleid en organisatie, implementatie/uitvoering en beheersing. Binnen deze studie zijn we alleen uitgegaan van gebruikersautorisaties binnen de geautomatiseerde gegevensverwerking. Andere aandachtsgebieden zoals fysieke toegangsbeveiliging, toegangsbeveiliging van services en eventuele provisioning van mobiele telefoons, laptops en andere zaken hebben we niet in deze studie meegenomen.


3 van 17

1. Inleiding Het Platform Informatiebeveiliging (PI) heeft als doel “het bevorderen van de beveiliging van alle belangen betreffende gegevensverwerking, -opslag en -transport, alles in de ruimste zin van het woord”. Binnen deze doelstelling wordt het ontwikkelen van aanvaardbare richtlijnen voor de praktische inrichting van informatiebeveiliging als essentieel onderwerp gezien. Door het gezamenlijk opstellen van dergelijke richtlijnen kan worden gebruik gemaakt van praktijkervaringen, zodat een doeltreffende richtlijn ontstaat die ook uitvoerbaar is. De PI-richtlijnen worden in werkgroepverband ontwikkeld onder auspiciën van de Commissie Werkgroepsturing, waarin zowel leden van het PI-bestuur als van het Genootschap van Informatie Beveiligers (GVIB) zijn vertegenwoordigd. Deze Commissie ziet er onder meer op de kwaliteit van de werkgroepresultaten. De deelnemers van de werkgroepen zijn primair afkomstig uit de organisaties die aangesloten zijn bij PI en GVIB, maar niet uitsluitend. Het betreft beveiligingsfunctionarissen en (ICT-)auditors van uiteenlopende bedrijven en instellingen, die zich kenmerken door de hoge eisen die zij in hun advies- en controlewerkzaamheden aan organisaties moeten stellen in verband met de sterke automatiseringsgraad en de belangen die met de geautomatiseerde informatievoorziening zijn gemoeid. Door deze achtergrond vormen de deelnemers een representatieve afspiegeling van de aanwezige beveiligingsexpertise in Nederland en bieden zij een draagvlak om gezag te verlenen aan de ontwikkelde richtlijnen, hetgeen bevorderlijk is voor de acceptatie door het algemene en het ICT-management. De beveiligingsmaatregelen die in de PI-richtlijnen worden beschreven, vormen een onderdeel van de bredere context van het gehele samenstel van beveiligingsmaatregelen om de kwaliteit van de geautomatiseerde informatievoorziening te waarborgen. Beveiligingsmaatregelen binnen deze bredere context zijn bijvoorbeeld beschreven in de publicatie 'Code voor Informatiebeveiliging, een Standaard voor Beleid en Implementatie’. Deze code is een internationale ‘best practice’ (ISO/IEC 17799: 2000). Deze code richt zich in het bijzonder op het tactische niveau binnen organisaties en bestrijkt het gehele terrein van informatiebeveiliging. Door het abstractieniveau geeft de Code echter onvoldoende concrete handvatten voor het implementeren van beveiligingsmaatregelen bij ICT-systemen. Hetzelfde geldt nog sterker voor het besluit Voorschrift Informatiebeveiliging Rijksdienst (VIR), dat voor de rijksoverheid van toepassing is. De PI-richtlijnen kunnen dan ook worden beschouwd als een verdere praktische uitwerking van de Code en de baselinebeveiliging van het besluit VIR en zijn vooral (doch niet uitsluitend) gericht op het operationele niveau binnen organisaties. De beveiligingsrichtlijnen die in PI-verband zijn en worden ontwikkeld, betreffen de maatregelen en voorzieningen die moeten worden getroffen ter waarborging van de kwaliteitsaspecten integriteit, vertrouwelijkheid en beschikbaarheid van de gegevens die met een ICT-systeem worden opgeslagen, verwerkt en/of getransporteerd. Dat wil niet zeggen dat andere kwaliteitsaspecten, zoals efficiëntie (bedieningsgemak, performance, kostenbeheersing), uit het oog worden verloren. Juist door de inbreng vanuit de praktijk wordt gestreefd naar een optimaal evenwicht tussen beveiligingsniveau en praktische realiseerbaarheid. De richtlijnen vormen de neerslag van de gezamenlijke kennis, inzichten en praktische ervaringen van de werkgroepen PI-leden. De PI-beveiligingsrichtlijnen zijn primair bedoeld voor functionarissen die zijn belast met het implementeren van beveiligingsmaatregelen in organisatie, techniek en processen. Daarnaast zijn de richtlijnen van betekenis voor de volgende doelgroepen: - Beveiligingsfunctionarissen, die verantwoordelijk zijn voor het doen treffen van beveiligingsmaatregelen en het houden van toezicht daarop. De richtlijnen geven hieraan ondersteuning.


4 van 17

-

Het management dat (eind)verantwoordelijk is voor de keuze van de beveiligingsmaatregelen binnen zijn competentiegebied en dat de richtlijnen kan gebruiken als een objectief handvat.

-

(ICT-)auditors. De richtlijnen kunnen worden gehanteerd als toetsingsnorm bij audits.

Aan deze PI-studie hebben de volgende personen en organisaties hun medewerking verleend: - B.Bokhorst RE RA, Belastingdienst/Centrum voor Proces en Productontwikkeling -

Drs. L.J.C. van Riel RE, Audit Dienst Defensie

-

ing. P.M. Hoogendoorn RE, Achmea Pensioenen

-

ing. P.Mienes RE, KPMG IRM

-

Drs. P.H.Kalverda, PGGM

-

A.J.M.Mulder RE, PricewaterhouseCoopers

Dank voor hun constructieve bijdragen in de reviewfase van de PI-studie is verschuldigd aan: - R.Kuiper en J.Wessels, Logica CMG - H.A.M. Luiijf MSc, TNO Defence, Security and Safety - KPN Audit - Ir. A.Hofman, Capgemini - drs. P.J.M. Goeyenbier RE RA, EDP Audit Pool - Vaktechnische Commissie van de NOREA Mededeling Norea: “NOREA, de beroepsorganisatie van IT-auditors, beoogt met het in 2002 gepubliceerde Studierapport 3 (getiteld: Raamwerk voor ontwikkeling van normenstelsels en standaarden) een extra impuls te geven aan de ontwikkeling van normen en standaarden die bij IT-audits worden gebruikt. Het Platform Informatiebeveiliging en NOREA hebben gezamenlijk vastgesteld dat de PI-studies en PI-standaarden, hoewel vaak niet voldoend aan de formatvereisten van Studierapport 3, in deze context zeker ook voor IT-auditors waardevolle handreikingen kunnen bevatten. In concreto is door NOREA geconstateerd dat de voorliggende PI-studie Role Based Access Control als handreiking kan dienen bij het uitvoeren van IT-audits. Wij bevelen deze publicatie dan ook van harte aan aan onze leden"


5 van 17

2. Autorisatiebeheer en RBAC 2.1 Introductie In de literatuurlijst worden verschillende bronnen aangehaald die een goed overzicht geven van Role Based Access Control (RBAC). Onderstaand wordt een beknopte introductie gegeven. Autorisatiebeheer Autorisatiebeheer heeft als doel om gebruikers op een efficiënte manier te voorzien van de juiste autorisaties, op basis van need-to-know of need-to-access. In de praktijk blijkt dit vaak geen eenvoudige zaak, onder andere omdat een gebruikersaccount of user-id op veel plekken gedefinieerd moet worden en daar gekoppeld moet worden aan autorisatiegroepen. De onderstaande figuur geeft weer hoe gebruikers aan autorisatiegroepen zijn gekoppeld, die op hun beurt bepaalde toegang geven tot objecten (mappen, bestanden, tabellen, transacties, commando’s, beheerfaciliteiten, etc.).

Figuur 1: algemeen autorisatiepatroon Aan deze traditionele manier van autorisatiebeheer kleven een aantal nadelen, zoals: • door verschillende beheerders moeten in een groot aantal ‘autorisatieregistraties’ handelingen worden uitgevoerd om de autorisaties aan te brengen of te verwijderen; dit is niet efficiënt en verlengt veelal de doorlooptijd van een aanvraag; • vaak is niet bekend welke autorisaties precies nodig zijn voor een gebruiker; • er bestaat geen compleet overzicht van alle autorisaties van een medewerker; • als een medewerker een andere functie krijgt, worden de oude autorisaties niet altijd verwijderd. Een oplossing voor deze problemen kan worden gevonden in een overkoepelend autorisatiemanagementsysteem op basis van RBAC (Role Based Access Control). Autorisatiebeheer op basis van RBAC Bij het inrichten van autorisatiebeheer op basis van RBAC verandert er op de platforms en in de applicaties (de doelsystemen) in principe niets: de bovenstaande begrippen gebruiker, autorisatiegroep en object komen dan ook terug in de figuur op de volgende pagina. Kenmerkend voor het RBAC-concept en de bijbehorende tooling zijn vier aspecten: • het RBAC-tool is een overkoepelend systeem over alle platformen en applicaties heen; • in het RBAC-tool is vastgelegd welke (business) rol(len) een gebruiker heeft; de gebruiker wordt niet meer rechtstreeks, maar nu via rollen, gerelateerd aan autorisatiegroepen (binnen het RBAC-tool ‘permissies’ genoemd); • de doelomgeving wordt aangestuurd (‘provisioning’) vanuit het RBAC-tool, d.w.z. dat gebruikersaccounts/user-id’s automatisch worden gecreëerd (of verwijderd) als dat nodig is, en dat deze automatisch worden gekoppeld aan (of losgekoppeld van) autorisatiegroepen; • omdat in het RBAC-tool vastligt welke autorisaties een gebruiker zou moeten hebben (SOLL-situatie), en in de doelsystemen de werkelijke autorisaties bekend zijn (IST-situatie) kan eenvoudig een verschillenlijst worden geproduceerd van afwijkingen tussen de gewenste en de werkelijke situatie.


6 van 17

Figuur 2: RBAC-autorisatiebeheer

2.2 Positionering Procesmatig perspectief In de onderstaande figuur zijn de belangrijkste deelprocessen weergegeven van het proces Autorisatiebeheer, zoals het in deze studie wordt belicht. Gebruikersgegevens worden Geregistreerd in bronregistratie

Gebruiker -In dienst -Uit dienst -Wijziging functie

Gebruikersbeheer Gebruikersgegevens roltoekenning

Rol Hiërarchie

Rollenbeheer

Rollenmodel (gewenste Situatie)

Bronregistratie (bijv. HR) Management

Automatische datafeed

Rollenbeheer op Basis van RBAC

(HR) management (ont)koppelt rollen aan gebruiker

RBAC tool

Monitoring Auditing

Provisioning Gebruikers Profielen en Autorisaties worden doorgegeven aan de platforms

Monitoring & Auditing data Totaaloverzichten Uitzonderingen Soll-ist vergelijking

z/OS

Active Directory

Unix

Figuur 3: RBAC-autorisatiebeheer deelprocessen PI-Studie RBAC versie 1.0

7 van 17

De vier deelprocessen zijn: Gebruikersbeheer • alle activiteiten gericht op - registratie en onderhouden van gebruikersgegevens in het RBAC-tool op basis van gegevens uit de bronadministratie; - toekennen en ontnemen van autorisaties door toekennen/verwijderen van voorgedefinieerde rollen; Rollenbeheer • alle activiteiten gericht op het opstellen en onderhouden van roldefinities, het zogenaamde tactische autorisatiebeheer; Provisioning • activiteiten gericht op het aanmaken en beheren van gebruikersaccounts en –autorisaties op de doelplatformen; Monitoring & Auditing • activiteiten gericht op het signaleren van afwijkingen tussen SOLL en IST m.b.t. gebruikeraccounts en –autorisaties, alsmede het voorzien in adequate auditing functionaliteiten. Technisch perspectief In het kader van platformoverstijgend autorisatiebeheer worden in het RBAC-tool naast rollen en permissies ook gebruikersgegevens vastgelegd; de overige aspecten van identificatie en authenticatie vallen buiten de scope van deze studie. De onderstaande figuur belicht deze afbakening vanuit een technisch perspectief.

Authenticatie Login

Authenticatie data

Autorisatie

AUTORISATIEBEHEER

HRM Beheer

Provisioning & Monitoring & Auditing

AC

RBAC tool

z/OS AC

Unix

AC

Active Directory

Gebruikers gegevens

Autorisatie data

AC: Access Control mechanisme

Figuur 4: Technisch perspectief Autorisatiebeheer


8 van 17

2.3 RBAC-model In de tools voor autorisatiebeheersing wordt het RBAC-model op verschillende manieren geïmplementeerd. Ten behoeve van dit leveranciers-onafhankelijke normenkader wordt het onderstaande conceptuele model gehanteerd. Het model en het normenkader zijn van toepassing op de praktische implementatie van de huidige gangbare RBAC-vormen zoals deze in de ANSI INCITS standaard 359-2004 (zie http://csrc.nist.gov/rbac/) zijn gedefinieerd, met name: RBAC-01 Basis RBAC; de eerste vorm is de algemene standaard waarbij gebruikers aan rollen gekoppeld worden en aan de rollen permissies worden toegekend; 2) RBAC-02Hiërarchische RBAC; de tweede vorm van het RBAC-model introduceert rolhiërarchieën, waarbij rollen (en de er aan gekoppelde permissies) door andere rollen worden geërfd; 3) RBAC-03 Statische functiescheiding in combinatie met hiërarchische RBAC; het kenmerkende aspect van de derde vorm is dat in het model beperkende voorwaarden worden opgenomen over de koppeling van gebruikers aan rollen. Deze onverenigbaarheid van permissies en/of rollen wordt verondersteld apart te zijn vastgelegd in het RBAC-tool; 4) RBAC-04 Dynamische functiescheiding in combinatie met hiërarchische RBAC; van de vierde vorm – dynamic separation of duty relations – bestaat momenteel nog onvoldoende een beeld van praktische implementaties, vooral daar waar het een applicatieoverstijgende implementatie van deze RBAC-vorm betreft. Wel komt deze vorm van functiescheiding voor in applicaties (zoals workflow management systemen) als rules of geprogrammeerde controles. De vorm is vooralsnog niet te implementeren in generieke RBAC-tools. Het dynamische aspect van functiescheiding blijft in dit normenkader daarom buiten beschouwing. 1)

In figuur 5 is globaal aangegeven welke beheerfuncties rond het model minimaal zijn te onderkennen: - Gebruikersbeheer –het beheer van gebruikersgegevens, gebruikersprofielen en de koppeling met rollen, veelal onder verantwoordelijkheid van het lijnmanagement; HRM levert in de regel de stamgegevens van medewerkers; - Rollenbeheer – het beheer van rollen, en de koppeling tussen rollen en permissies; - Technisch autorisatiebeheer – het beheer van autorisatiegroepen/applicatierollen in de doelsystemen, en de bijbehorende permissies in het model; - Operationeel autorisatiebeheer – het operationele beheer van gebruikersprofielen en de koppelingen met autorisatiegroepen/applicatierollen; idealiter is deze beheertaak geautomatiseerd door middel van provisioning.


9 van 17

Gebruikers beheer

Rollen beheer

Technisch autorisatiebeheer

HRM

Gebruiker

Rol

Provisioning

Permissie

Autorisatiebeheertool (SOLL)

Provisioning

Doelomgeving(en) (IST) Gebruikers profiel

n:m relaties

Autorisatiegroep/ applicatierol

Object

Operationeel autorisatiebeheer

Figuur 5. Conceptueel RBAC-model met beheerfuncties Omschrijving van de gehanteerde begrippen in figuur 5: Term HRM

gebruiker

gebruikersprofiel autorisatiegroep / applicatierol permissie object rol SOLL IST provisioning

Omschrijving bronregistratie van personeelszaken (human resource management) die alle medewerkers bevat die enige vorm van toegang gaan krijgen op de ICT-middelen, waarbij deze registratie in samenhang wordt beschouwd met de registratie van externen (medewerkers, partners) gebruikers in het autorisatiebeheer tool kunnen zijn o.a. vaste medewerkers, inhuur, derde partijen, niet persoonsgebonden gebruikersdefinities; via provisioning leidt de definitie tot een gebruikersprofiel in één of meer doelsystemen definitie van de gebruiker in het doelsysteem (bv. account, user-id) (groepering van) toegangsrecht(en) op object(en) in één doelsysteem, nodig om een rol of (deel)taak te kunnen vervullen, bijv. Unix- of Windows groep of rollen (soms wel profielen genoemd) in een applicatie afbeelding in het autorisatiebeheer tool van één concrete autorisatiegroep / applicatierol in het doelsysteem datgene waarop toegangsrechten worden verkregen, bijv. gegevens(bestand), directory, applicatie, scherm, commando, share geheel van activiteiten, die als een logische eenheid van werk aan een medewerker kan worden toegewezen term uit de accountancy, hier gebruikt om aan te geven welke permissies een rol volgens het model zou moeten hebben term uit de accountancy, hier gebruikt om aan te geven welke autorisaties werkelijk aanwezig zijn in de doelsystemen (half-)automatische koppeling tussen het autorisatiebeheer tool en de doelomgeving(en), die er voor zorgt dat in de doelsystemen gebruikersprofielen worden gecreëerd/verwijderd, en koppelingen met autorisatiegroepen/ applicatierollen worden aangebracht/verwijderd


10 van 17

3. Normen De verantwoordelijkheid voor het (doen) implementeren van beheermaatregelen berust bij de organisatie. Indien normen expliciet gelden voor de ICT-organisatie zijn deze als zodanig aangeduid. De hier uitgewerkte normen betreffen het autorisatiebeheer volgens RBAC inclusief de algemene normen voor het autorisatiebeheer.

3.1 Beleid en organisatie 3.1.1. De organisatie heeft beleid geformuleerd voor het proces Autorisatiebeheer waarbij minimaal invulling gegeven is aan: a) het doel (of de doelen) en de uitgangspunten; b) welke omgevingen en doelsystemen binnen de scope vallen: b.1 ontwikkeling, test, acceptatie, productie; b.2 welke typen permissies in welke doelsystemen; b.3 welke typen speciale privileges in welke doelsystemen; b.4 welke typen gebruikersprofielen (vast dienstverband, inhuur, derde partijen, applicatiebeheer user-id’s, niet persoonsgebonden user-id’s). c) het eigenaarschap van Autorisatiebeheer; d) de vereiste communicatie en overlegstructuren voor het goed en effectief kunnen functioneren van het proces; e) de globale organisatorische inrichting ten aanzien van verantwoordelijkheden; f) de inrichting volgens de Role Based Access Control methode (RBAC); g) hoe om te gaan met uitzonderingen en afwijkingen van de autorisatiemodellen; h) de wijze van controle op de inrichting en uitvoering van de activiteiten. 3.1.2. De organisatie heeft de verantwoordelijkheden binnen het proces voor Autorisatiebeheer vastgelegd en ingevuld, waarbij sprake is van een adequate controletechnische functiescheiding. Hierbij zijn minimaal de volgende verantwoordelijkheden ingevuld: a) eigenaarschap van het proces Autorisatiebeheer, verantwoordelijk voor het realiseren van de doelstellingen van het proces en het onderhoud van het gehanteerde RBAC-(meta-)model; b) gebruikersbeheer, verantwoordelijk voor het beheer van de gebruikersprofielen en de koppeling van gebruikers aan rollen; c) security functie, verantwoordelijk voor het goedkeuren en toezicht op de interne autorisaties van het autorisatiebeheer tool (ICT-organisatie); d) rollenbeheer, verantwoordelijk voor het beheer van de, binnen Autorisatiebeheer, onderkende functies en rollen en de koppeling tussen functies, rollen en permissies; e) eigenaarschap van objecten, verantwoordelijk voor de toegang tot het object (applicaties en bedrijfsgegevens); f) functioneel beheer van applicaties, verantwoordelijk voor aansturen van de technisch autorisatiebeheerder betreffende het oprichten van autorisatiegroepen / applicatierollen en de koppeling daarvan met de objecten in de doelomgeving, en het vastleggen van de gerelateerde permissies in het RBAC-tool; g) de aanvrager, verantwoordelijk voor een juiste en tijdige aanvraag van wijzigingen in de implementatie van het RBAC-model; i) de controlefunctie, verantwoordelijk voor de periodieke toetsing op de beheersbaarheid van het geïmplementeerde RBAC-model en controle op de effectiviteit ervan. Een combinatie van onderstaande verantwoordelijkheden wordt niet bij één persoon belegd: - security functie; - gebruikersbeheer; - rollenbeheer; - technisch autorisatiebeheer; - de controlerende functie.


11 van 17

3.1.3. De organisatie hanteert richtlijnen voor de toepassing van de Role Based Access Control (RBAC) methode, waarbij minimaal invulling is gegeven aan: a) de organisatorische inrichting met een gedetailleerde invulling van taken, bevoegdheden en verantwoordelijkheden; b) de technische inrichting, inclusief het gebruik van geautomatiseerde hulpmiddelen; c) het toepassingsgebied, de fasering en prioritering van de implementatie; d) de betekenis van de RBAC-methode en –hulpmiddelen voor herinrichtingsprocessen en nieuw te ontwikkelen of aan te schaffen applicaties; e) de koppeling met het incident management proces 3.1.4. De organisatie hanteert voor de inrichting van het RBAC model richtlijnen voor het bepalen van de rollen, waarbij minimaal invulling is gegeven aan: a) de methode voor het bepalen van de rollen, waarbij meestal een keuze is gemaakt voor een combinatie van top-down en bottom-up; b) de toepassing van role engineering hulpmiddelen; c) de soorten rollen die worden gebruikt - functie/proces gerelateerd; - taak gerelateerd; - project gerelateerd; - organisatie gerelateerd; - geografisch gerelateerd; d) de rollenstructuur, waarbij minimaal aandacht besteed is aan: - het juiste gebruik van rollen; - de introductie van rolhiërarchiën; - het automatisch ‘erven’ van rollen; e) het na de initiële implementatie ontstaan van nieuwe rollen; f) het na de initiële implementatie wijzigen van de betekenis van rollen; g) de voorwaarden waaronder permissies rechtstreeks mogen worden gekoppeld aan gebruikers; h) de naamgevingconventie voor de verschillende te definiëren rollen; i) de onderhoudbaarheid en transparantie. 3.1.5. De organisatie hanteert voor de inrichting van het RBAC model richtlijnen voor het definiëren van autorisatiegroepen / applicatierollen (en daarmee voor de permissies), waarbij minimaal invulling is gegeven aan: a) de soorten groepen en profielen die worden gebruikt: b) de noodzaak van een eenduidige functionele omschrijving; c) de methode voor het bepalen van de permissies per rol, waarbij meestal een keuze is gemaakt uit een combinatie van top-down en bottom-up; d) de naamgevingconventie voor de te definiëren groepen en rollen; e) functiescheidingsregels op het niveau van permissies en/of rollen (Static Separation of Duty); f) de onderhoudbaarheid. 3.1.6. De organisatie hanteert voor de inrichting van het proces Autorisatiebeheer richtlijnen voor de SOLL/IST controle, waarbij minimaal invulling is gegeven aan: a) de uit te voeren controles; b) de periodiciteit van de uit te voeren controles; c) de op te leveren rapportages; d) te ondernemen acties bij gesignaleerde verschillen; e) de methode van aanpassing van IST aan SOLL situatie (handmatig of (half)automatisch).


12 van 17

3.2 Implementatie/uitvoering 3.2.1. De organisatie heeft de onderkende deelprocessen voor Autorisatiebeheer vastgelegd en ingevuld, waarbij minimaal de volgende deelprocessen zijn beschreven en ingevuld: a) het beheer van gebruikersgegevens; b) de ontwikkeling en het beheer van rollen, inclusief het (ont)koppelen van permissies aan rollen; c) het (ont)koppelen van gebruikers aan rollen; d) het beheer van permissies; e) de controle op de juistheid van de SOLL; f) de SOLL/IST controle. 3.2.2. De organisatie heeft voor elk onderkend deelproces vastgelegd wie verantwoordelijk is voor: a) de aansluiting op het Informatiebeveiligingsbeleid; b) het opstellen/wijzigen van de richtlijnen voor het deelproces; c) het opstellen/onderhouden van de voor het deelproces geldende procedures en instructies; d) de uitvoering van de operationele taken binnen het deelproces; e) de controle op en de rapportage over de werking van het deelproces. 3.2.3. De ICT-organisatie heeft de onderkende deelprocessen voor Autorisatiebeheer vastgelegd en ingevuld, waarbij minimaal de volgende deelprocessen zijn beschreven en ingevuld: a) het beheer van gebruikersprofielen; b) het (ont)koppelen van gebruikersprofielen aan autorisatiegroepen / applicatierollen; c) de ontwikkeling en het beheer van autorisatiegroepen / applicatierollen; d) de provisioning. 3.2.4. De ICT-organisatie heeft voor het proces Autorisatiebeheer een keuze gemaakt voor het gebruik van beheerhulpmiddelen, waarbij minimaal aandacht is besteed aan: a) het toepassingsgebied van het beheerhulpmiddel en aansluiting met relevante componenten binnen het toepassingsgebied; b) de ondersteuning van het RBAC-model met de gewenste hiërarchische niveaus; c) de waarborgen voor vertrouwelijkheid, integriteit, beschikbaarheid en controleerbaarheid van de gegevens in het autorisatiebeheertool; d) de rapportagemogelijkheden, waaronder: d.1 het inzichtelijk maken van alle relaties tussen gebruikers, (hiërarchie van) rollen en permissies; d.2 het inzichtelijk maken van de gedefinieerde onverenigbaarheid van permissies en/of rollen; d.3 managementinformatie waaruit de effectiviteit van het beheerproces blijkt, bv aantallen SOLL-IST verschillen per applicatie maar ook aantallen nieuwe, gewijzigde en verwijderde rollen, permissies en gebruikers per afdeling of vestiging. Ook aantallen permissies per rol en aantal rollen per gebruiker en trendanalyses kunnen hierbij van belang zijn. e) de schaalbaarheid; f) de ondersteuning van de vereiste controletechnische scheiding van rollen bij het autorisatiebeheer; g) de toekomstvastheid van en ondersteuning door de leverancier; h) de openheid van de oplossing (bijv. alle gegevens exporteerbaar); i) de automatische vergelijking van de SOLL- met de IST-situatie; j) de automatische aanpassing IST- aan de SOLL-situatie: j.1 bij verschillen; j.2 bij aanpassingen van het model; k) de aansluiting met andere beheermiddelen; l) de ondersteuning van role engineering; PI-Studie RBAC versie 1.0

13 van 17

m) automatische provisioning. 3.2.5. De organisatie hanteert procedures en instructies voor het beheer van gebruikersgegevens, waarbij minimaal invulling is gegeven aan: a) het aanmaken/onderhouden/verwijderen van gebruikersdefinities n.a.v. de in- en uitdiensttreding van gebruikers en wijziging van hun functie; b) de eventuele koppeling met het HRM-systeem. 3.2.6. De organisatie hanteert procedures en instructies voor de ontwikkeling en het beheer van rollen, waarbij minimaal invulling is gegeven aan: a) het aanmaken/onderhouden/verwijderen van rollen; b) het (ont)koppelen van de gedefinieerde rol(len) aan functie(s); c) het (ont)koppelen van de gedefinieerde rollen aan permissies. 3.2.7. De organisatie hanteert procedures en instructies voor de ontwikkeling en het beheer van autorisatiegroepen / applicatierollen (en daarmee voor de permissies), waarbij minimaal invulling is gegeven aan: a) het aanmaken/verwijderen van de groepen / rollen; b) het onderhouden van de groepen / rollen, waarbij specifieke aandacht is besteed aan (de gevolgen van) het wijzigen van de functionaliteit; c) het opstellen/onderhouden van de functiescheidingsmatrix. 3.2.8. De organisatie hanteert procedures en instructies voor het (ont)koppelen van gebruikers aan rollen, waarbij gebruik gemaakt wordt van de functiescheidingsregels. Hierbij dient tenminste te zijn gedacht aan: a) functie- of rolwijzigingen; b) in- en uitdiensttreding. 3.2.9. De ICT-organisatie hanteert procedures en instructies voor de provisioning, waarbij minimaal invulling is gegeven aan a) het aanmaken/onderhouden/verwijderen van gebruikersprofielen op de doelsystemen; b) het (ont)koppelen van autorisatiegroepen / applicatierollen aan/van objecten op de doelsystemen; c) het aanmaken/verwijderen van gebruikersgebonden resources zoals persoonlijke directories, discussiegroepen, mailboxen e.d.. 3.2.10. De organisatie hanteert procedures en instructies voor de periodieke controle op de juistheid van de RBAC-implementatie en voor periodieke SOLL/IST controles. Bij de controle op de juistheid van de RBAC-implementatie wordt tenminste aandacht gegeven aan: a) de overeenstemming tussen de medewerkergegevens in het HRM-systeem en de gebruikersdefinities in het RBAC-tool; b) gebruiker-rol relaties; c) rol-permissie relaties; d) permissie-object relaties. 3.2.11. De ICT-organisatie moet het beheer van het autorisatiebeheer tool hebben ondergebracht in de vigerende beheerprocessen. 3.2.12. De organisatie hanteert procedures en instructies voor uitzonderingen op het model.

3.3 Beheersing 3.3.1. De organisatie hanteert procedures en instructies voor het periodiek beoordelen van en rapporteren over de uitvoering van het proces Autorisatiebeheer, waarbij minimaal beoordeeld wordt in hoeverre: PI-Studie RBAC versie 1.0

14 van 17

a) b) c) d)

de voorgeschreven richtlijnen worden nageleefd; per deelproces is/wordt gewerkt volgens de voorgeschreven procedures en instructies; de beheerhulpmiddelen adequaat worden toegepast; de controletechnische functiescheiding wordt gehanteerd.

3.3.2. De organisatie hanteert procedures en instructies voor het periodiek evalueren en het (eventueel) bijstellen c.q. aanpassen van het proces Autorisatiebeheer en de daarmee beoogde doelstellingen. Deze evaluatie wordt gebaseerd op: a) de informatie en rapportages verkregen uit punt 3.3.1. hiervoor; b) cijferbeoordeling en trendanalyse uit de managementrapportage c) eventuele aanvullende onderzoeken om tot een nadere beoordeling van het proces en doelstellingen van Autorisatiebeheer.


15 van 17

Bijlage

Relatie met de Code voor Informatiebeveiliging, deel 2 4.7 Toegangsbeveiliging 4.7.1 Zakelijke eisen ten aanzien van toegangsbeveiliging 4.7.1.1 Beleid ten aanzien van toegangsbeveiliging De zakelijke eisen voor toegangsbeveiliging moeten gedefinieerd en gedocumenteerd zijn en de toegang moet worden beperkt tot hetgeen bepaald is in het beleidsdocument voor toegangsbeveiliging. 4.7.2 Management van toegangsrechten / autorisatiebeheer 4.7.2.4 Controle van toegangsrechten Middels een formeel proces moeten periodiek de toegangsrechten van gebruikers worden herzien. 4.7.4 Toegangsbeveiliging voor netwerken 4.7.4.1 Beleid ten aanzien van het gebruik van netwerkdiensten Gebruikers mogen alleen directe toegang krijgen tot die diensten waarvoor zij specifiek geautoriseerd zijn. 4.7.6 Toegangsbeveiliging voor toepassingen 4.7.6.1 Beperking van toegang tot informatie Toegang tot functies van informatie- en toepassingssystemen moet worden beperkt overeenkomstig het toegangsbeleid van de organisatie zoals bepaald in 4.7.1.1.


16 van 17

Literatuur Boek: -

Role-Based Access Control – Ferraiolo, Kuhn en Chandramouli, Artech House 2003

Artikelen: -

De (on)beheersbaarheid van toegangsbeveiliging – Mienes en Bokhorst, Compact 2003/1 PDF te downloaden vanaf: www.kpmg.nl/irm > Informatiebeveiliging > publicaties en whitepapers > De (on)beheersbaarheid van toegangsbeveiliging

-

Rolgebaseerd autoriseren: effectief sturen op ICT-gebruik – Heiden, Stultjens en Hermans, Compact 2004/2

-

Rolgebaseerd autoriseren onder architectuur – Hofman, Informatiebeveiliging 2005/1

-

Rolbeheer, een nieuwe tak van sport – Hofman en Löwenthal, IT-beheer 2005/5

-

De (harde) praktijk van role engineering – Mienes, Compact 2005/3

Website: -

http://csrc.nist.gov/rbac/ Website van het National Institute of Standards and Technology

-

http://www.gvib.nl/afy_info_ID_1321.htm Website Genootschap voor informatie beveiligers, Handreiking Identiteiten- en Autorisatiebeheer


17 van 17

Studie Role Based Access Control

Recommend Documents