Top 7 IAM-problemen in organisaties met meer dan 500 medewerkers

• Product en technologie

Identity & Access Management wordt bij grotere organisaties al snel erg ingewikkeld. Waar je in een kleinere setting kunt volstaan met technische beveiligingsmaatregelen en een spreekwoordelijke spreadsheet om de bijbehorende instellingen te beheren, lukt dat niet meer met honderden gebruikers die ook nog eens gebruikmaken van een veelheid aan applicaties en enorme hoeveelheden data. Dan wordt rechtenbeheer al snel een organisatorische puzzel, die je alleen kunt leggen met de juiste IAM-ondersteuning. We verzamelden een aantal veelvoorkomende IAM-uitdagingen bij organisaties met meer dan 500 medewerkers, inclusief oplossingen om met die uitdagingen om te gaan.

Geen automatisch lifecycle management

Als je bij deze schaalgrootte het toegangsbeheer handmatig uitvoert, vraagt dat om problemen. Het is niet alleen arbeidsintensief, maar ook erg complex en daarmee foutgevoelig. Je hebt te maken met meerdere afdelingen, teams en functieprofielen, en iedere medewerker heeft eigen taken en verantwoordelijkheden. Bovendien is er veel dynamiek, want regelmatig worden nieuwe medewerkers aangenomen, collega’s stromen door en er zijn mensen die de organisatie weer verlaten. Zo doorloopt iedereen een eigen ‘identity lifecycle’, waarbij iemand steeds andere accounts en permissies nodig heeft.

Automatisch identity lifecycle management is dan onontbeerlijk. Binnen HelloID gebruiken we hiervoor Role Based Access Control (RBAC)[1]. Uitgangspunt daarbij zijn contract- en andere medewerkersgegevens die formeel zijn vastgelegd in bijvoorbeeld het HR-systeem of andere bronsystemen. Aan de hand van iemands functie, afdeling of andere zogeheten ‘gebruikersattributen’ bepaalt het platform met business rules automatisch welke accounts en rechten nodig zijn. Bij veranderingen worden automatisch de benodigde rechten aangepast, zodat iedereen op ieder moment beschikt over de juiste instellingen.

Tijdrovende onboarding

Ieders identity lifecycle begint met de onboarding, het moment waarop hij of zij in dienst komt. Op die dag moet iemand worden voorzien van de juiste IT-hulpmiddelen en instellingen. Hier gaat het nog te vaak fout. Als mensen relatief lang moeten wachten op iets simpels als een Office- en mailaccount, duurt het niet alleen langer voordat iemand productief wordt, het is vooral een teleurstellend begin.

Mensen met zo’n mindere ‘onboarding experience’ blijken relatief snel weer op zoek te gaan naar een andere baan. Zonde, want de zoektocht naar goed personeel kost vaak maanden en duizenden euro’s. Een gestroomlijnde onboarding is dus om meerdere redenen belangrijk. Steeds meer organisaties organiseren zelfs een zogeheten preboarding. Klanten configureren daarbij het IAM-platform zodanig dat nieuwe medewerkers al voorafgaand aan de begindatum accounts krijgen, nog wel met beperkte toegangsrechten. Ze kunnen dan alvast online kennismaken met de nieuwe collega’s, werkzaamheden, bedrijfssoftware en het HR-portaal. Zo ‘breek je digitaal het ijs’, al ruim vóór de startdag.

Medewerkers met te veel rechten

Als je binnen grotere organisaties het rechtenbeheer niet goed organiseert, verzamelen mensen al snel te veel rechten. Dat begint soms al bij de onboarding, waarbij de nieuwe collega een copy-paste krijgt van de accountinstellingen van een ervaren collega, met (te) ruime rechten. En krijgen ze tussentijds een andere rol, dan ontvangen ze vaak wel nieuwe rechten, maar eerder ontvangen rechten die niet meer nodig zijn, worden niet ingetrokken. Men gaat zo onbedoeld rechten opstapelen, de zogeheten ‘privilege creep’. Het gevolg hiervan is dat hackers via een binnengedrongen account veel méér schade kunnen veroorzaken.

Je kunt dit voorkomen door het rechtenbeheer zoveel mogelijk te automatiseren met het genoemde RBAC-mechanisme. Op die manier voldoe je automatisch aan het zogeheten Principle of Least Privilege. Dat houdt in dat iedere gebruiker op ieder moment alleen de rechten heeft die echt noodzakelijk zijn voor de voorgeschreven taken en verantwoordelijkheden. Bij tussentijdse veranderingen, een andere functie bijvoorbeeld, worden niet alleen nieuwe rechten verstrekt, maar ook achterhaalde rechten weer ingetrokken.

Onvolledige offboarding

De risico’s zijn nog groter als de offboarding van vertrekkende medewerkers niet goed is geregeld. In dat geval is een medewerker inmiddels vertrokken, maar zijn diens accounts en instellingen nog actief. Een kwaadwillende gebruiker – wellicht de ex-medewerker zelf – heeft dan eenvoudig via die account nog toegang tot functies en gegevens. Het is een van de meest voorkomende oorzaken van datalekken. En het gaat niet alleen om bijvoorbeeld documenten. Het is ook niet de bedoeling dat iemand nog toegang krijgt tot online vergaderingen en chatgroepen.

Ook dit kun je voorkomen door de identity lifecycle te automatiseren, met extra aandacht voor het moment dat medewerkers uitstromen. Juist die uitstroomfase is namelijk complex, bijvoorbeeld omdat de betreffende accounts stapsgewijs moeten worden geblokkeerd en verwijderd. Gevoelige gegevens moeten uiteraard direct worden geblokkeerd, maar sommige andere faciliteiten wil je nog tijdelijk toegankelijk houden voor ex-medewerkers. Denk aan het HR-portaal, waar iemand nog enige tijd de laatste salarisstroken en jaaropgaven moet kunnen ophalen. Ook zal er een proces moeten zijn om gegevens adequaat te archiveren voor eventuele latere naslag, audits en onderzoeken. Zonder dat de oud-collega, of een nieuwe medewerker met dezelfde naam, er nog bij kan.

Geen controle op individuele toegangsrechten

Je provisiont rechten dus zoveel mogelijk ABAC-gebaseerd, maar sommige rechten kun je alleen individueel regelen. Binnen een stafafdeling heb je bijvoorbeeld veel medewerkers met de functie ‘adviseur’. Ze krijgen allemaal de standaard kantoorapplicaties, maar de verdere IT-benodigdheden hangen af van de projecten waar ze mee bezig zijn. Ook de accounts en rechten voor allerlei nevenwerkzaamheden zoals BHV-taken, kun je vaak niet afleiden uit iemands functie of afdeling.

Als je zulke accounts en rechten handmatig aanmaakt, en rechtstreeks beheert binnen de betreffende systemen, verlies je al snel de grip op deze instellingen en wordt het een warboel. De manager die de rechten heeft aangevraagd, kijkt er daarna niet meer naar om, en de gebruiker vindt het uiteraard wel prima. Zo bouw je al snel een enorme set onbeheerde rechten op binnen een veelheid aan systemen.

Je kunt dit gelukkig voorkomen door binnen HelloID deze rechten te beheren via de Service Automation module. Hiermee kun je beheerschermen samenstellen voor specifieke beheeracties en er is een self-service portaal. Op die manier behandel je deze individuele verzoeken vanaf één centrale plek en houd je het overzicht. We kunnen rechten hier ook tijdelijk verstrekken, waarna ze automatisch weer worden ingetrokken. En als onderdeel van de Governance module bieden we een Recertification functie, waarmee je periodiek kunt evalueren of rechten nog nodig zijn.

Gebrekkig inzicht en beperkte auditmogelijkheden

Bij grote organisaties wil je niet alleen ondersteuning hebben bij het ‘hier en nu’ van je account- en rechtenbeheer. Professionele organisaties moeten ook een volledige status en historie kunnen overleggen over het gebruik en het beheer van alle IT-middelen. Je moet bijvoorbeeld een volledige audittrail beschikbaar hebben voor het onderzoeken van cyberincidenten. En je hebt deze gegevens ook nodig bij audits en het aantonen van je compliance met informatiebeveiligingsnormen en -wetgeving.

Hiervoor is het belangrijk dat je een centraal IAM-platform hebt, waarin deze gegevens op één plek eenvoudig toegankelijk zijn. Het gaat daarbij niet alleen om real-time aanmeldingen tot systemen. Ook moet per account en toegangsrecht worden gedocumenteerd op grond van welke beleidsregel ze zijn verstrekt. En bij individuele gebruikersverzoeken moet je kunnen terugvinden wie zo’n verzoek heeft ingediend, welke manager het heeft goedgekeurd, en hoe het verzoek verder is afgehandeld. Zonder IAM is de vraag sowieso óf deze gegevens beschikbaar zijn, en zijn ze meestal decentraal in verschillende systemen terechtgekomen.

Geen periodieke IAM-evaluatie

Als je de toegangsrechten initieel goed hebt ingericht, kan het beheer ervan gaandeweg toch ‘uit sync’ raken met de werkelijkheid. Bijvoorbeeld omdat je nieuwe systemen introduceert, processen wijzigt, nieuwe functies creëert of afdelingen toevoegt. Het zijn stuk voor stuk zaken die invloed kunnen hebben op de verdeling van IT-rechten. Als dat niet goed wordt verwerkt in het rechtenbeheer, ontstaat er vervuiling. Bovendien ontdek je gaandeweg altijd optimalisatie- en verbeterpunten.

De enige manier waarop een organisatie hiermee kan omgaan, is een professionele ‘Plan-Do-Check-Act’ cyclus op te zetten als onderdeel van je IAM-processen. Veel informatiebeveiligingsnormen (zoals ISO 27001, de BIO en NEN 7510) schrijven dit ook voor. Belangrijk is dat je IAM-omgeving hiervoor governance hulpmiddelen biedt, zoals Reconciliation, Recertification en Role mining. Hiermee kun je het rechtenbeheer periodiek analyseren, verbeterpunten herkennen en deze eenvoudig doorvoeren.

Hoe kunnen we samen je IAM-issues oppakken?

Bij grotere organisaties ligt het zwaartepunt van de IAM-problematiek dus niet zozeer bij de technische toegangsbeveiliging. De echte uitdaging is het organiseren van de enorme aantallen accounts en toegangsrechten. Hoe zorg je dat iedereen op ieder moment beschikt over juist díe rechten die nodig zijn voor de aangewezen taken.

Handmatig wordt dat al snel onbeheersbaar. Met geautomatiseerde provisioning, aangevuld met goed geautomatiseerde serviceprocessen en self-service, kun je het rechtenbeheer wél goed organiseren. Met goede logging en rapportages kun je ook op ieder moment de compliance aantonen, en krachtige governance tools helpen het rechtenbeheer regelmatig te verifiëren, optimaliseren en verbeteren.

Meer weten over hoe HelloID dit voor je kan verzorgen? Hier maak je kennis met alle beschikbare IAM-modules en kun je ook een Demo aanvragen.

Bekijk helloID

[1] Omdat we binnen HelloID niet alleen iemands functie en afdeling kunnen gebruiken, maar feitelijk alle beschikbare gebruikersattributen, hanteren we ook wel de term ABAC (Attribute Based Access Control)