Hoe een User Provisioning-oplossing je organisatie helpt

Hoe een User Provisioning-oplossing je organisatie helpt

Door: Arnout van der Vorst

In de vorige blog ‘Waarom heb je een IAM-oplossing nodig?‘ hebben we verschillende uitdagingen geschetst waar organisaties zonder Identity & Access Management (IAM) mee worstelen. We hebben de redenen onderverdeeld in de categorieën: efficiëntie en kostenreductie, compliance eisen aan wet- en regelgeving, en bescherming tegen datalekken. In deze blog zullen we opnieuw op deze drijfveren inzoomen, maar dan vanuit het perspectief hoe een IAM-oplossing deze problemen voorkomt en verhelpt. We trappen af met het onderdeel User Provisioning. Wil je dus weten hoe een (cloud gebaseerde) User Provisioning-oplossing jouw organisatie helpt? Lees dan zeker verder!

Hoe helpt een IAM-oplossing?

Eerder hebben we dus drie drijfveren beschreven om een IAM-strategie te formuleren en een IAM-oplossing te implementeren. Binnen die categorieën hebben we een aantal voorbeelden gegeven van uitdagingen die zich bij handmatig gebruikers-, autorisatie- en toegangsbeheer kunnen voordoen. In het geval van de drijfveer ‘efficiëntie en kostenreductie’ omvat dit handmatig mutatiebeheer, een verminderde gebruikerservaring en productiviteit, veel helpdesk tickets, en hoge softwarelicentiekosten. IAM-uitdagingen binnen de tweede business driver ‘Compliance aan eisen wet- en regelgeving’ zijn accumulatie van rechten en conflicterende permissies, en het werken met copy user in plaats van least privilege. Voor de laatste driver ‘Bescherming tegen datalekken’ hebben we menselijke fouten als uitdaging geïdentificeerd.

Zoals ook in de vorige blog beschreven is Identity & Access Management een verzamelbegrip voor verschillende technologieën die van doen hebben met gebruikers-, autorisatie- en toegangsbeheer. In het vervolg van deze blog zullen we dieper in gaan op het wat en hoe van deze IAM-technologieën. Voor het overzicht verdelen we deze onder in ‘User Provisioning’, ‘Service Automation’, en ‘Access Management’. Categorieën die niet geheel ontoevallig overeenkomen met de modules zoals wij deze in onze cloud IAM-oplossing HelloID hanteren.

User Provisioning

User Provisioning heeft betrekking op het automatiseren van de levenscyclus van een identiteit, de zogenaamde identity life cycle. Aan de hand van gedefinieerde bedrijfsregels en een rollenmodel worden bron- en doelsystemen met elkaar gekoppeld zodat circa 80% van de handmatige gebruikers- en autorisatiebeheer handelingen volledig automatisch kunnen worden afgehandeld. De meest bekende stappen in de levenscyclus van een gebruiker zijn de in-, door- en uitstroom (IDU). Maar ook een eventuele herinstroom valt hieronder. Door de IDU-processen te automatiseren verhelpt deze IAM-functionaliteit een groot deel van de geïdentificeerde problemen wat betreft foutgevoeligheid, kostbaarheid qua tijd en geld, en tijdigheid.

Koppelingen

Een Identity & Access Management oplossing koppelt bron- en doelsystemen zodat het beheer van gebruikers- en autorisaties zonder tussenkomst van menselijke handelingen wordt geautomatiseerd. Vaak zijn er maar een of meerdere systemen die geschikt zijn als bronsysteem. In het geval van doelsystemen is het raadzaam om allereerst te kijken naar die applicaties die door veel gebruikers wordt gebruikt en waarvoor veel wijzigingen moeten worden uitgevoerd.

Om de gewenste voordelen qua efficiëntie en kostenbesparing te halen moeten de kosten voor het koppelen immers in verhouding staan met de tijdswinst die je behaald. Een applicatie die door een of enkele personen wordt gebruikt is daarom over het algemeen niet interessant om te koppelen. De uitzondering op deze regel is natuurlijk wanneer de applicatie zeer gevoelige gegevens bevat. In dit geval wil je manuele fouten uitsluiten en kan een koppeling om deze reden wel degelijk interessant zijn. Hoewel er ook dan nog wellicht overwogen kan worden om deze niet binnen het provisioning, maar binnen het service automation proces onder te brengen.

Bronsysteem

De basis voor een geautomatiseerd gebruikersbeheer proces start bij een centraal kernregistratiesysteem dat als bronsysteem dient voor de overige systemen en applicaties. Dit kernregistratiesysteem noemen we ook wel de single source of truth. In de meeste organisaties is het HR-systeem een goede single source of truth. De organisatie heeft er namelijk belang bij om het HR-systeem goed op orde te houden. Op basis van deze gegevens betaalt de organisatie ook de salarissen uit. Staat iemand niet in het HR-systeem dan ontvangt deze persoon geen salaris. Staat iemand er nog in terwijl deze al wel uit dienst is dan zou die ex-medewerker nog steeds salaris ontvangen. In beide gevallen is er dus voldoende motivatie om tijd en energie in een goede registratie te steken.

Bronsystemen

Naast de integriteit van de gegevens die dit mee brengt bevat het HR-systeem ook veel relevante informatie die je nodig hebt om gebruikers en autorisaties op een goede en correcte wijze te kunnen beheren. Dit zijn bijvoorbeeld de voor- en achternaam, maar ook de voorkeursnaam. Deze gegevens heb je nodig voor het kunnen genereren van een gebruikersnaam en e-mailadres. Nog veel interessanter zijn echter de contractgegevens. Op basis van de in- en uitdienstdatum weet je wanneer je een gebruikersaccount moet aanmaken en wanneer deze moet worden dichtgezet. De functie en afdeling van de persoon vertellen op hun beurt wat over de werkzaamheden en daarmee de rechten die hij of zij nodig heeft. Hoewel deze gegevens natuurlijk sowieso ook veelal gewenst zijn om vanuit een smoelenboek of contactenlijst in te kunnen zien. Tot slot staat ook de manager van de persoon vaak in het HR-systeem geregistreerd. Deze is weer erg interessant voor service automation, waar we in de volgende blog op in zullen haken.

Meerdere bronsystemen

Laat je overigens niet misleiden door het woord ‘single’, want er zijn wel degelijk situaties waarin je meerdere bronsystemen tegelijkertijd wilt toepassen. Denk aan een zorgorganisatie die naast het HR-systeem ook een planningspakket als bronsysteem aanhoudt. Daarin wordt bijvoorbeeld vastgelegd welke zorgmedewerkers wanneer welke cliënten behandelen. Of een educatieve instelling die studenten in een studenteninformatiesysteem (SIS) bijhoudt. Belangrijk om te onthouden: Identity & Access Management limiteert zich niet enkel tot medewerkers, maar omhelst alle gebruikers die toegang nodig hebben tot je ICT-omgeving.

Doelsystemen

Op basis van het bronsysteem weet je dus wie je gebruikers zijn en wat ze in de organisatie doen, maar met deze wetenschap zijn je gebruikers nog niet geholpen. Aan de andere kant hebben we immers de verschillende doelsystemen waar je gebruikers een account of bepaalde rechten in nodig hebben. Dit kan een (Azure) Active Directory of Google Workspace zijn. Het NTFS bestandsysteem of SharePoint in de cloud. Maar ook bedrijfsspecifieke applicaties zoals een Customer Relationship Management (CRM) systeem,  applicatie voor Elektronisch Patiëntendossier (EPD) of een Elektronische Leeromgeving (ELO).

Doelsystemen

Een doelsysteem kan tegelijkertijd ook de rol van bronsysteem vervullen. Zo beschikt een HRM-applicatie bijvoorbeeld vaak over Employee Self-Service voor bijvoorbeeld het wijzigen van je adresgegevens of een verlofaanvraag. Om hierop te kunnen inloggen heb je een gebruikersaccount nodig die niet noodzakelijkerwijs gekoppeld is aan de HR-registratie. Het beheren van deze accounts kan door het als doelsysteem aan een User Provisioning systeem te koppelen.

Daarnaast kunnen doelsystemen afhankelijkheden van elkaar hebben. Denk bijvoorbeeld aan het e-mailadres van een gebruiker. In het geval van handmatig gebruikersbeheer ‘verzint’ een IT servicedesk medewerker deze vaak. Voordat deze echt aan een gebruiker wordt toegekend moet de beschikbaarheid echter wel gecontroleerd worden. Bij geautomatiseerde User Provisioning zal de IAM-oplossing deze genereren en in bijvoorbeeld een (Azure) Active Directory controleren en registreren, maar vervolgens is deze in nog veel meer applicaties benodigd. Denk bijvoorbeeld aan de hierboven genoemde HR self-service applicatie.

Identity Life Cycle

Wanneer we het hebben over identity life cycle management behelst dit het principe dat op het moment dat er voor een gebruiker iets veranderd binnen een bronsysteem, dit leidt tot wijzigingen in een of meerdere doelsystemen. We kunnen grofweg de volgende identity life cycle events onderscheiden:

Identity Life Cycle

Oftewel als iemand in het bronsysteem wordt geregistreerd heeft deze een account nodig. Wanneer de indienst-/instroomdatum is bereikt wordt het account geactiveerd. Als er een mutatie plaatsvindt zoals een naamswijziging (bij trouwen of scheiden) of een functiewijziging (bij een promotie) leidt dit tot andere accountgegevens en rechten. Als iemand uit dienst gaat dan ontneemt het systeem zijn rechten, schakelt zijn account uit en verwijdert deze ook uiteindelijk.

Normaliter leidt dit tot veel handmatig werk voor zowel HR- als IT-afdelingen. HR moet immers notificeren wanneer er een mutatie optreedt door HR. En de servicedesk en applicatiebeheerders verrichten handelingen om de wijzigingen in de verschillende systemen te verwerken. Wanneer een van beiden verzaakt of mutaties verzamelt en gebundeld verwerkt dan heeft dit gevolgen voor de tijdigheid, productiviteit én informatiebeveiliging.

Een User Provisioning-oplossing kan deze wijzigingen volledig automatiseren. Het IAM-systeem leest het bronsysteem periodiek uit en vergelijkt de gemaakte snapshots met elkaar. Door het uitvoeren van een gap analyse detecteert deze vervolgens automatisch alle mutaties. De HR-medewerker hoeft de mutaties alleen nog maar binnen het HR-systeem te verwerken. Hier verandert dus niets aan. Ze hoeven echter niet meer handmatig de IT-afdeling hiervan op de hoogte te stellen. Op basis van vastgelegde procedures en attribuut mappings kan het systeem vervolgens deze wijzigingen ook automatisch doorvoeren in de gekoppelde doelsystemen. Dit neemt dus werkdruk weg bij de IT servicedesk en functioneel applicatiebeheer. In zijn totaliteit zorgt het geautomatiseerde proces dat de wijzigingen in vervolg tijdig en foutloos worden doorgevoerd.

Rollenmodel

Je vraagt je wellicht af hoe de IAM-oplossing weet welke personen binnen je organisatie in welke applicaties een gebruikersaccount nodig hebben en welke bijbehorende rechten. Dit leg je vast in het rollenmodel van de IAM-oplossing. Het rollenmodel is in feite het brein van je Identity & Access Management systeem. Andere veelgebruikte termen zijn een autorisatiematrix, Role Based Access Control (RBAC) of Attribute Based Access Control (ABAC). Of zoals we het zelf samenvatten: business rules. Een business rule bestaat uit condities en permissies. Op basis van de conditie bepaalt het rollenmodel wanneer de business rule of rol voor iemand van toepassing is. De toegangsrechten bepalen wat iemand in dat geval krijgt. Of andersom: wat hij of zij verliest wanneer de persoon niet meer aan de gestelde condities voldoet.

Condities

Condities bepalen welke personen binnen het bereik van een business rule vallen. Je selecteert hiermee dus een subgroep van gebruikers die de aan de regel gekoppelde permissies zullen ontvangen. Het uitgangspunt is dat iedere gebruiker binnen de organisatie een duidelijke ‘rol’ krijgt, gerelateerd aan zijn of haar werkzaamheden. Welke werkzaamheden iemand vervult kan je afleiden uit iemands functie, team, afdeling, dienst en/of locatie. Binnen een autorisatiematrix start je met de condities voor de bovenste laag van de organisatie. Zo is het vaak zo dat (bijna) iedereen binnen de organisatie toegangsrechten nodig heeft als een (Azure) AD account, toegang tot het internet en intranet, en Microsoft Office. Ga je een laag dieper, naar bijvoorbeeld afdelingen dan is bijvoorbeeld toegang tot de netwerkmap van de afdeling benodigd. Pas wanneer het echt nodig is kom je bij individuele functies of combinaties van kenmerken als functie en afdeling uit. In de praktijk kan je een groot deel van de handmatige taken echter al op de hogere niveau’s afhandelen.

Condities

Ga je het voor elke medewerker exact inrichten dan zal je zien dat elke medewerker op zijn eigen manier uniek is. Met als gevolg dat je evenveel rollen als medewerkers krijgt. En dat is nu precies wat we niet willen. Dit betekent namelijk het verplaatsen van het handmatige gebruikers- en autorisatiebeheer naar het handmatig beheer van het rollenmodel. En dat brengt gegarandeerd dezelfde problemen met zich mee op het gebied van foutgevoeligheid, tijdigheid, productiviteit, kosten etc. die met een goed ingerichte IAM-oplossing juist verholpen worden. De stelregel is dat je met User Provisioning circa 80 procent van je gebruikers- en autorisatiebeheer kan automatiseren. De overige 20 procent handelt een IAM-oplossing af met service automation technologie.

Toegangsrechten

Nadat je een rol hebt geïdentificeerd ken je toegangsrechten tot specifieke applicaties en data toe om zo’n rol effectief in te vullen. Hiermee zorg je er voor dat iedereen met eenzelfde rol automatisch diezelfde rechten krijgt.

Toegangsrechten

Er zijn vijf type permissies die je aan een rol kunt koppelen:

  • Account
  • Account access
  • Group membership
  • Permission
  • Sub-permission

Bij het toewijzen van een account wordt er een nieuw user account voor de gebruiker aangemaakt in een nog geblokkeerde status. Wanneer account access wordt verleend wordt het account ingeschakeld. Een group membership verwijst naar het koppelen van de gebruiker aan een groep in een doelsysteem. Permissions zijn custom rechten in doelsystemen waar optioneel subpermissions aan gekoppeld kunnen worden.

Binnen een IAM-oplossing is het belangrijk dat dit gesloten processen zijn. Oftewel er moet altijd een tegenhanger zijn van het verkrijgen van een toegangsrecht. Wijzigt iemands rol? Dan wil je namelijk dat ook automatisch de bijbehorende toegangsrechten worden aangepast, en dat er dus niet enkel wordt bijgeplust. Juist dit is binnen een handmatig gebruikers- en autorisatiebeheerproces enorm lastig om per gebruiker bij te houden. Voor een IAM-oplossing als HelloID is dit veel eenvoudiger. Zo is het tegenovergestelde van het verkrijgen van een permission: het ontnemen hiervan. Van account access: het uitschakelen van een account. En van het aanmaken van een account: het verwijderen ervan. Door deze werking weet je zeker dat je geen spookaccounts in je netwerk krijgt die niet meer manueel, maar ook niet meer geautomatiseerd worden beheerd.

In onze volgende blog lees je hoe een Service Automation oplossing je organisatie helpt. Wil je meer weten over onze User Provisioning module binnen HelloID?

Lees alles over HelloID

Arnout van der Vorst

Geschreven door:
Arnout van der Vorst

Maak kennis met Arnout van der Vorst, de inspirerende Identity Management Architect bij Tools4ever sinds het jaar 2000. Na zijn studie Hogere Informatica aan de Hogeschool van Utrecht is hij begonnen als Supportmedewerker bij Tools4ever. Daarna heeft Arnout zich opgewerkt tot een sleutelfiguur in het bedrijf.  Zijn bijdragen strekken zich uit van klantondersteuning tot strategische pre-sales activiteiten, en hij deelt zijn kennis via webinars en artikelen.

Anderen bekeken ook

Waarom heb je een IAM-oplossing nodig?

Waarom heb je een IAM-oplossing nodig?

29 augustus 2022

Slimme role mining: de booster voor Role Based Access Control

Slimme role mining: de booster voor Role Based Access Control

30 juni 2022

De transitie naar de cloud en IDaaS

De transitie naar de cloud en IDaaS

31 mei 2022

Hoe HelloID IT-managers helpt om efficiënter en sneller te werken

Hoe HelloID IT-managers helpt om efficiënter en sneller te werken

10 maart 2020