Themapatroon identity & access management

Onderdeel van: Thema's
Contact: Guus van den Berg; Guus.vandenberg@cip-overheid.nl
Status: Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging

Leeswijzer

Dit themapatroon beschrijft de algemene probleemstelling van Identity & Access Management (IAM). Onderliggende patronen geven de uitwerking van Identity Management (IdM), Access Management (AM) en Federatie van identity management.

Criteria

Integriteit, Vertrouwelijkheid, Controleerbaarheid

Context

Organisaties bezitten een groot aantal gegevens(verzamelingen), diensten en IT-middelen, die waarde vertegenwoordigen. Deze objecten spelen een rol in bedrijfsprocessen of ze zijn producten van bedrijfsprocessen. Een organisatie kent personen zoals medewerkers of klanten die gebruik moeten maken van deze objecten. Organisaties bieden diensten aan voor andere organisaties zoals business partners. Ook zijn er systemen en services die toegang moeten hebben tot de verschillende objecten. Personen, (partner)organisaties en actieve systemen zijn actoren en worden in deze context benoemd als subjecten. Afhankelijk van de situatie, opereren actieve systemen en services als object óf als subject. In de patronen van het thema IAM ligt de focus op het subject Persoon. In de overige patronen voor Logische toegang, zoals Portaal en Vertrouwd Toegangspad ligt de focus op het subject Systeem.

Aan personen en systemen wordt toegang verleend tot diensten en gegevens

Dit patroon beschrijft koppelvlakken als thema. In de onderliggende patronen worden de verschillende soorten van koppelvlakken besproken, inclusief de belangrijkste verkeersstromen.

Probleem

Aan het ontsluiten van gegevens en IT-functies zijn risico’s verbonden. Diverse wet- en regelgeving verplichten organisaties om aan te tonen dat men grip heeft op: “Welke medewerkers (of systemen) hebben toegang tot welke gegevens en welke IT-functies?”. De problemen zijn als volgt samengevat:

De identiteit van een subject is niet uniek. Van één bepaald subject zijn vaak meerdere identiteiten binnen een organisatie geregistreerd.
Registratieprocessen bevatten niet alle subjecten die behoren tot de organisatie.
Samenhang ontbreekt in registraties van identiteiten en hun toegangsrechten.
Kwaliteit van identiteitsgegevens is ontoereikend.
Need to know dilemma. Starre rollenmodellen werken contraproductief.
Definiëren van toegangsrechten is een moeizaam en langdurig proces.
Management heeft geen overzicht en inzicht in verstrekte toegangsrechten aan medewerkers.
Autorisatieproces onwerkbaar, hoge beheerlast en complexiteit door te hoge granulariteit.
Procedures en/of technieken ontbreken om vast te stellen tot welke gegevens subjecten zich toegang hebben verschaft en in hoeverre dit in strijd is met bedrijfsregels (beleid).
Inspanning voor handmatige uitvoering van wijzigingen wordt te groot.
Toegangsrechten worden niet ingetrokken wanneer medewerkers deze voor hun werk niet meer nodig hebben, of wanneer ze de organisatie verlaten.

Oplossing

De oplossing van de problemen rond toegangsbeheersing wordt gevonden in een architectuur waarin drie groepen beheerprocessen worden onderscheiden:

Beheer van identiteiten van subjecten (Identity Management, IdM);
Beheer van toe te wijzen gebruiksrechten op objecten (behorend bij functioneel applicatiebeheer);
Beheer van de toegangsrechten / regels voor toegang (Access Management, AM).

Onderstaande figuur schetst IAM beheerprocessen. In het AM patroon is uitgewerkt dat autorisaties op basis van verschillende kenmerken worden verleend. Deze figuur geeft inzicht in de verschillende processen die nodig zijn om subjecten op gecontroleerde wijze toegang te geven tot de middelen (objecten) die zij nodig hebben om hun taak uit te kunnen voeren. Links en bovenin de figuur staan de processen, die leiden tot te beheren gegevens per entiteit: Clearance, Pasbeheer en Certificaatbeheer zijn optioneel. Niet elke organisatie gebruikt dit. Midden in de figuur staan de autorisatiebeheerprocessen. Onder de stippellijn staat het (functioneel) beheer van objecten en beheer van de toe te wijzen gebruikersrechten op deze objecten. Rondom de entiteit ‘Actie’ wordt de Access Management functie ‘runtime’, d.w.z. realtime-processing uitgevoerd (door het informatiesysteem).

Beheerprocessen van IAM

De tabel geeft een toelichting op de entiteiten uit bovenstaande figuur op alfabetische volgorde.

Entiteit	Toelichting
Actie	Een handeling die een subject met een middel (object) kan uitvoeren, waarop een autorisatie of toegangsregel van toepassing kan worden verklaard
Afdeling	Een organisatorische eenheid als onderdeel van de afdelingshiërarchie van een organisatie
Arbeidsplaats	Een unieke positie binnen en afdeling waarop een persoon kan worden geplaatst c.q. te werk gesteld
Autorisatie	Een aan een class/ rol/ claim/ clearance verleend recht tot het uitvoeren van een actie op een IT-middel
Bedrijfspas	Het persoonsgebonden identiteitsbewijs van personen die een werkrelatie hebben met de organisatie, voorzien van Public Key certificaten
Certificaat	Een persoonsgebonden of Server gebonden Public Key – certificaat, dat voor personen geïnstalleerd is op de bedrijfspas of een andere tokenvorm als drager, eventueel gekoppeld aan het IT account fungeert dit als authenticatiemiddel. Voor IT-componenten wordt het certificaat geïnstalleerd in een Hardware Security Module (HSM) of als z.g. ‘software certificaat’ in de systeemprogrammatuur.
Criterium	Een eigenschap die iets of iemand kan bezitten en relevant is voor het definiëren van toegangsregels
IT-Account	Een persoonsgebonden account waarmee een persoon inlogt op de IT-client of het IT-portaal
IT-Middel (object)	Een applicatie, fysiek object, service of gegevens, waar de natuurlijke persoon (of IT-component) toegang toe moet hebben om zijn actie uit te kunnen voeren. Middelenbeheer wordt buiten de scope van IAM uitgevoerd, voor zowel IT-componenten als voor gegevens.
Persoon (subject)	Een natuurlijke persoon die een formele en geregistreerde werkrelatie heeft met de organisatie
Class / Role Assertion / Clearance	Abstractie, die wordt gehanteerd om samenhangende sets van autorisaties te bundelen en die inzicht verschaft “uit hoofde waarvan” personen, waaraan de class / role / assertion / clearance is toegekend, de desbetreffende autorisatie hebben ontvangen. Clearance level Vertrouwensniveau, dat een persoon is toegekend en gelijk is aan het maximale classificatieniveau van het te behandelen gegeven of bedrijfsproces: b.v.: Confidentieel, Geheim of Zeer geheim. Het wordt toegekend als resultaat van een veiligheidsonderzoek (AIVD/ MIVD en VOG van gemeente).
IT-component (subject)	Een IT-component is een geregistreerd applicatieproces of onderdeel van de IT- infrastructuur, dat toegang kan worden verleend tot de entiteit IT-Middel.
Toegangsregel	Beschrijft criteria waaronder bepaalde acties op een middel mogen worden uitgevoerd
Toekenning	Koppeling van een rol aan een persoon. Deze koppeling kan gelijk zijn aan de plaatsing van de persoon voor arbeidsplaats gerelateerde rollen, maar hieronder vallen ook de toekenningen van niet-arbeidsplaats gebonden rollen aan personen.
Werkrelatie	Een plaatsing c.q. tewerkstelling van een persoon op een arbeidsplaats binnen de organisatie.

De entiteit Persoon kent drie beheerprocessen. Onder de noemer Instromen vallen de deelprocessen Intake, aanleveren van een wettelijk identificatie document, in het kader van de Wet ter voorkoming van Witwassen en Financieren van Terrorisme (WWFT) en uitgifte van een Personeelsnummer, als de persoon die nog niet had. De werkrelatie van een persoon op een arbeidsplaats bij de organisatie wordt beheerd middels het proces Plaatsen. De entiteit IT-Component, is een IT-Middel (m.u.v. gegevens), in de gedaante van een subject. Het proces “Naam wijzigen” is van toepassing als een persoon gaat trouwen of scheiden en is een trigger voor het uitreiken van een nieuwe bedrijfspas met nieuwe certificaten en het wijzigen van de eigenschappen van het IT-account.

Identity Management (IdM), definitie: Het geheel aan beleid, verantwoordelijkheden, processen en hulpmiddelen dat organisaties in staat stelt om de identificatie en authenticatie van subjecten te faciliteren, te beheren en te controleren.

Onderstaande afbeelding schetst een eenvoudige IAM architectuur, die zowel de toegang tot oudere (legacy) systemen ondersteunt als de toegang tot moderne systemen.

M.u.v. ‘standalone’ objecten wordt voor vrijwel alle systemen een bepaalde vorm van IdM gebruikt. De HRM database met alle relevante persoonsgegevens wordt bij voorkeur als “authentieke bron” gebruikt voor het vullen van de Identiteiten en Policy Repository via koppelvlak (1). Deze repository vormt de kern van IAM, want in deze database worden alle toegangsgegevens opgeslagen van personen en systemen. De repository wordt in XACML termen het Policy Information Point (PIP) genoemd. Via koppelvlak (2) worden de IdM gegevens doorgegeven aan de Authenticatie service. Dit geautomatiseerd doorgeven wordt provisioning genoemd.

Eenvoudige IAM architectuur

Access Management (AM), definitie: Het geheel aan beleid, verantwoordelijkheden, processen en hulpmiddelen dat organisaties in staat stelt om de toegang tot en het gebruik van objecten (systemen en informatie) te faciliteren, te beheren en te controleren.

Uitgangspunt bij het verlenen van toegang zijn de z.g. Policy ‘s oftewel beleidsregels die vertaald zijn in autorisaties. De Authentication Service verzorgt via koppelvlak (3) de authenticatie van de personen die werken op de Client. Voor legacy systemen wordt na het authenticatie proces via koppelvlak (4) toegang verleend tot het IT-middel en daarmee de gegevens. De autorisatie wordt bij oudere systemen meestal binnen het IT-middel zelf gekoppeld aan het IT-account van het subject. Ook toegangsregels zijn specifiek voor het IT-middel gedefinieerd en geconfigureerd. De eigenaar vult de repository van zijn object met toegangsrechten van geautoriseerde personen. Wanneer authenticatie wordt verzorgd via Kerberos, dan wijkt het architectuurplaatje iets af van bovenstaande figuur; zie hiervoor het patroon SSO. De client haalt een ticket op van de Ticket Granting Ticket server, die acteert als Policy Enforcement Point (PEP). Deze ticket wordt aangeboden aan het IT-middel, waarmee toegang wordt verleend tot gegevens. Gebruik makend van XACML, geeft het PDP op basis van toegangsregels via (8) toegang tot het IT- middel na authenticatie van de persoon en het besluit over de toegangsrechten vanuit de Policy Administration het Policy Decision Point: via koppelvlak (5) en (6). In overleg met eigenaren worden toegangsrechten gekoppeld aan rollen en centraal opgeslagen in een repository.

Onderstaande figuur schetst een IAM architectuur inclusief IAM-federatie functionaliteit. In de hierna volgende patronen wordt deze architectuur telkens in onderdelen toegelicht. De koppelvlaknummers zijn daarbij steeds dezelfde en hebben in alle volgende IAM-architectuurplaten dezelfde betekenis. In het externe domein is alleen een “Vertrouwde partij” afgebeeld. De interactie met klanten en eigen medewerkers op externe clients is van een andere orde en is uitgewerkt in het patroon “Portaal en toegangsserver” en in het patroon “Koppelvlak semi-vertrouwde derden”.

IAM architectuur op basis van XACML

Deze IAM architectuur maakt het mogelijk dat applicaties wederzijds met vertrouwde partners kunnen worden gedeeld. Dat betekent dat eigen medewerkers applicaties van een vertrouwde partij kunnen gebruiken maar dat medewerkers van de vertrouwde partij op hun beurt ook de applicaties van de partnerorganisatie kunnen benaderen. De genummerde pijltjes in deze afbeelding geven weer welke interfaces ingericht moeten worden om flexibel informatie te kunnen delen in een federatief samenwerkingsverband. In de patronen Identity Management, Access Management en Federatie van Identity Management wordt de architectuur verder uitgewerkt.

Afwegingen

Het beheer over de IAM administraties kan op verschillende plaatsen in de organisatie worden belegd, bijvoorbeeld bij “Enterprise userbeheer”. De identiteit van personen die op de personeelslijst staan, worden beheerd door Human Resource Management (HRM). Doelgroepen zoals klanten, externe relaties worden in een andere repository beheerd zoals: Customer Relations Management (CRM). Vanuit deze repositories wordt het PIP gevoed. Afgewogen moet worden hoe met uitzendkrachten, contractors en medewerkers op projectbasis wordt omgegaan in de repositories. Deze personen moeten op een bij hun taak passende manier op naam worden geautoriseerd. Registratie van IT-componenten in de gedaante van subject en object wordt ondergebracht in de CMDB, als onderdeel van IT-service management.

Heeft een organisatie gekozen voor de invoering van IAM, dan is een stapsgewijze invoering belangrijk:

Start bij afdelingen of applicaties waar de grootste voordelen te behalen zijn en ga van daaruit verder uitbreiden.
Koppel invoering IAM aan nieuwbouw- of vernieuwingstrajecten, zodat desinvesteringen voor wijzigingen in bestaande architecturen zo veel mogelijk worden vermeden.
Bij legacy-applicaties moet een afweging plaatsvinden op basis van een business case. Daarbij worden de kosten verbonden aan de traditionele ‘embedded’ IAM van de applicatie vergeleken met de kosten voor het aanpassen van de applicatie. De overwegingen daarbij zijn het kwantitatieve deel (jaarlijks terugkerende kosten van een product) en het kwalitatieve deel (imago, wet- en regelgeving etc.).

Implicaties

Veel systemen en applicaties worden geleverd met een ingebouwde autorisatiestructuur. Het aanpassen van deze systemen en applicaties om een meer centraal toegangsbeheer mogelijk te maken, kost veel geld en inspanning.
De koppeling van systemen aan een IAM systeem leidt tot meer afhankelijkheden binnen de technische architectuur (nieuwe interfaces) en informatiearchitectuur (autorisatiemodellen zijn gekoppeld aan modellen van de applicaties). Aanvankelijk leidt dit tot een verhoging van de complexiteit, maar een juiste aanpak van IAM maakt deze complexiteit beheersbaar.
Belangrijker nog dan de aanpassingen aan de informatie- en systeemarchitectuur zijn de afspraken over verantwoordelijkheden over de verschillende deelgebieden. Wie is verantwoordelijk voor autorisaties?

NB. Er zijn ook alternatieven. Zo heeft de gemeente Zaanstad er voor gekozen dat IAM wel de rechten muteert in het ICT-accountbeheer systeem (MS Active Directory), maar dat IAM niet de specifieke rechten binnen een applicatie muteert. Dat laatste wordt geregeld door IAM een ticket te laten sturen via het Facilitair Managementsysteem (Topdesk) naar de functioneel beheerder. Op het ticket staat precies welke toegangsrechten de functioneel beheerder moet toekennen binnen een applicatie. Hierdoor hoefde de ingebouwde autorisatiestructuur van de applicatie niet te worden aangepast.

Gerelateerde patronen

Identity management (IdM): gaat dieper in op het beheer van identiteiten
Access Management (AM): gaat dieper in op de toekenning van toegang tot objecten
Single Sign-On (SSO): gaat in op gemeenschappelijk gebruik van authenticatiemiddelen en - diensten binnen een organisatie
Federatie van Identity Management: gaat in op het gebruik van identiteitsgegevens en mogelijk ook authenticatiediensten van andere organisaties, binnen een vertrouwenskader (federatie).

Standaarden en links

RBAC
OAuth: Open Authorization is een open standard voor autorisatie.
LDAP (Lightweight Directory Access Protocol)

Omdat organisaties en partners elkaar niet kunnen voorschrijven welke producten en leveranciers moeten worden gebruikt en met welke partijen ze mogen samenwerken, wordt de toegepaste Federatieve Authenticatie bij voorkeur volledig gebaseerd op z.g. Open Standaarden. De belangrijkste standaarden die in dit verband moeten worden geadopteerd zijn:

SAML: Security Assertion Markup Language. De OASIS standaard voor uitwisseling van authenticatie en autorisatiegegevens tussen verschillende zones.
XACML: eXtensible Access Control Markup Language. Een access control policy taal, die geïmplementeerd is in XML en een procesmodel. Dit model beschrijft hoe met policies om moet worden gegaan en geeft structuur aan Access management met onderstaande begrippen:

XACML-functie	Toelichting
PIP: Policy Information Point	Bevat alle identiteitsinformatie voor toegang tot IT-systemen zowel persoonsgebonden als functioneel. Vanuit verschillende directories vindt provisioning plaats naar het PIP, dat vervolgens relevante account- en persoonsinformatie real-time kan doorgeven aan authenticatieservices, zoals Kerberos.
PAP: Policy Administration Point	Administreert beleidsregels zoals wachtwoord policy, de authenticatiemethode voor toegang tot specifieke objecten (resources), een kenmerk die een subject (gebruiker) moet hebben voor autorisatie tot een object etc.
PDP: Policy Decision Point	Neemt real-time besluiten op basis van resource-, identiteit- en policy- informatie. De PDP maakt daarbij gebruik van de Identity Repository (PIP) en de Policy Repository.
PEP: Policy Enforcement Point	Dwingt real-time in de infrastructuur af dat de juiste policy wordt nageleefd. Dat kan betekenen dat voor een bepaalde URL de gebruiker zich moet authenticeren door middel van één of twee factor authenticatie (Wachtwoord of Token met PIN etc.)