Identity & Access Management (IAM)

Wat identity and access management (IAM) inhoudt

Identity and access management (IAM) is het geheel van beleid en tools dat bepaalt bij wie een account hoort en wat dat account mag bereiken. In de meeste organisaties beslaat dit een identity provider, een gebruikersdirectory, authenticatie en de toegangsrechten die aan elke rol hangen. Het vakgebied is breed en geen enkele tool doet alles. Weten welk deel je oplost is de eerste stap in elk IAM-project.

Waar ServiceChanger in identity and access management past

ServiceChanger authenticeert geen gebruikers. Het doet geen single sign-on of multi-factor authenticatie. Standaard reageert het op de attributen die al in je directory staan en leest het out of the box geen HR-systeem uit. Het zit na je identity provider. Zodra een account in Microsoft Entra ID of on-prem Active Directory bestaat, zet ServiceChanger één attribuutwaarde (afdeling, functie of locatie) om in de juiste set groep- en rollidmaatschappen, en houdt die set automatisch kloppend. Als "afdeling = Finance" negen specifieke groepen moet betekenen, zorgt ServiceChanger dat die negen lidmaatschappen er altijd zijn en niets extra. Wil je je HR-systeem koppelen voor onboarding en offboarding, dan bouwen we dat als maatwerk met automation accounts en runbooks in Azure. Het is één laag toegangsautomatisering, geen complete IAM- of IGA-suite.

Eén attribuut bepaalt een set groepen en rollen

Het kernidee is simpel. Je koppelt één attribuut aan een hele set lidmaatschappen. "Functie = veldtechnicus" kan vanuit één waarde een VPN-groep, een remote-access-rol, drie gedeelde mailboxen en de juiste software-uitrolgroepen toekennen. Verhuist iemand van Sales naar Finance, dan vervallen de Sales-lidmaatschappen en wordt de Finance-set toegevoegd, omdat de koppeling doorlopend wordt geëvalueerd en niet eenmalig bij onboarding. Voorbeelden die we in de praktijk zien: afdeling = Finance naar negen groepen, locatie = Rotterdam naar een printergroep plus een site-distributielijst, en functie = manager die een goedkeuringsrol toevoegt bovenop de basisset voor de afdeling.

Entra ID en on-prem Active Directory in één model

De meeste organisaties zijn nog hybride: sommige groepen staan in Microsoft Entra ID, andere bestaan alleen in on-prem Active Directory. ServiceChanger schrijft naar beide vanuit hetzelfde model. Het kan Entra ID dynamic groups aansturen, samenwerken met Entra Connect voor de gesynchroniseerde objecten, en een PowerShell-runbook op een hybrid worker draaien voor de on-prem groepen die de cloud niet bereikt. Zo kan één koppeling "afdeling = Finance" tegelijk een cloud-securitygroep en een on-prem AD-groep vullen, zonder tweede tool en zonder handmatige export. Deze hybride dekking vanuit één model is precies het deel dat generieke IAM-tooling overslaat.

Doorlopende handhaving, geen eenmalige sync

Access drift is het sluipende probleem in elke directory: mensen houden lidmaatschappen die ze niet meer nodig hebben, en handmatige opschoning loopt altijd achter. ServiceChanger past het attribuutmodel volgens een schema opnieuw toe, dus een lidmaatschap dat er niet hoort wordt verwijderd en een ontbrekend lidmaatschap wordt teruggezet. Er is geen shadow mode en geen alleen-voorbeeld-run; het attribuutmodel is de bron van waarheid en wordt bij elke ronde gehandhaafd. Zo blijft het gat tussen "wat het attribuut zegt" en "wat de directory verleent" bijna nul tussen toegangsreviews door.

Waar authenticatie en levenscyclus thuishoren

Omdat ServiceChanger lidmaatschappen afhandelt, blijft de rest van IAM bij de tools die daarvoor gemaakt zijn. Single sign-on en multi-factor authenticatie blijven in je identity provider; die verifiëren wie er inlogt. Standaard gaat ServiceChanger ervan uit dat het account al bestaat en de attributen al gezet zijn, en zorgt dan dat de toegang die uit die attributen volgt klopt. Wil je je HR-systeem koppelen zodat onboarding en offboarding die attributen sturen, dan bouwen we dat als maatwerk met automation accounts en runbooks in Azure. De twee lagen passen op elkaar: de identity provider bepaalt of je mag inloggen, ServiceChanger bepaalt in welke groepen je belandt.

Wat de licentiemodule wel en niet doet

De licentiemodule volgt het gebruik. Het laat zien welke licenties zijn toegekend en hoe ze zich verhouden tot je groep- en rolmodel, zodat je over-toekenning ziet voordat een toegangsreview dat doet. Het provisioneert geen licenties en wint ze niet terug. Een licentie verwijderen of terugkopen blijft een bewuste actie in je eigen beheertooling. De module geeft je het inzicht om te beslissen; het voert de wijziging niet voor je uit.

IAM, naleving en toegangsreviews

Toegangsreviews stellen één vraag: heeft elk lidmaatschap nog een reden. Als lidmaatschappen uit attributen volgen, is die reden de attribuutwaarde zelf, wat reviews korter en auditbewijs schoner maakt. ServiceChanger vervangt je audit- of rapportagetools niet, maar attribuutgedreven lidmaatschappen geven die tools een consistent, uitlegbaar antwoord voor normen zoals GDPR, HIPAA en SOC 2: deze groep bestaat omdat dit attribuut deze waarde heeft.

Waar IAM naartoe beweegt

Het bredere IAM-veld beweegt richting zero-trust-modellen, waarbij toegang nooit wordt aangenomen en op het moment van gebruik wordt gecontroleerd, en richting wachtwoordloos inloggen met passkeys en FIDO2. Die verschuivingen spelen in de authenticatielaag. Wat eronder constant blijft, is de behoefte aan correct groep- en rollidmaatschap, want een zero-trust-beslissing is zo goed als de toegangsdata die het leest. Dat lidmaatschap accuraat en attribuutgedreven houden is het deel dat ServiceChanger afhandelt, ongeacht de inlogmethode erbovenop.

IAM components: de bouwstenen van een IAM-systeem

Een IAM-systeem is geen enkel product. Het is een stapel componenten die elk een ander deel van het probleem oplossen, en de meeste organisaties zetten ze samen uit een paar tools. De componenten kennen helpt je zien waar een gat zit en welke tool het vult.

• Identity provider:de dienst die de gezaghebbende registratie van wie een gebruiker is vasthoudt en bij inloggen het token uitgeeft dat dat bewijst. In een Microsoft-omgeving is dit Microsoft Entra ID. Die beantwoordt "is dit echt diegene".
• Directory:de opslag van gebruiker- en groepobjecten met hun attributen: afdeling, functie, locatie, manager. Microsoft Entra ID en on-prem Active Directory zijn de twee directories die de meeste bedrijven draaien, vaak naast elkaar. Dit is de data die ServiceChanger leest om lidmaatschappen te bepalen.
• Authenticatie:de controle bij inloggen, inclusief single sign-on, multi-factor authenticatie en wachtwoordloze methoden. Die bevestigt dat de persoon achter het scherm bij de identiteit hoort. Deze laag blijft in je identity provider.
• Autorisatie:de beslissing over wat een geauthenticeerd account mag bereiken, uitgedrukt als groep- en rollidmaatschappen. Dit is de laag die ServiceChanger automatiseert vanuit directory-attributen.
• Provisioning:accounts en hun toegang aanmaken, bijwerken en verwijderen over een user lifecycle. Accountaanmaak en HR-gestuurde joiner-mover-leaver-stromen horen hier; ServiceChanger houdt lidmaatschappen kloppend zodra een account bestaat, en HR-gestuurde provisioning is maatwerk met automation accounts en runbooks in Azure.
• Governance:de toezichtslaag: access reviews, certificeringen, segregation-of-duty-checks en auditbewijs. Attribuutgedreven lidmaatschappen geven deze laag een schoner antwoord, maar een volledige IGA-suite bezit het certificeringsproces zelf.

IAM vs IGA vs PAM: welke lost welk probleem op

Drie termen lopen in bijna elk IAM-project door elkaar, en de verkeerde categorie kopen kost geld en tijd. Dit is wat elk oplost en wanneer je het echt nodig hebt.

Waar ServiceChanger past: de lidmaatschaps- en autorisatielaag van IAM, voor Microsoft Entra ID en on-prem Active Directory. Geen IGA-suite, geen PAM-vault. Is je probleem "de verkeerde mensen zitten in de verkeerde groepen en het loopt scheef", dan is dat het ServiceChanger-probleem. Is je probleem "we kunnen onze reviews niet aantonen" of "onze adminaccounts zijn onbeheerd", dan is dat IGA of PAM.

IAM implementation: een realistisch stappenplan

Een attribuutgedreven IAM-implementatie is geen big-bang-project. Het werkt het best als een reeks, afdeling voor afdeling, zodat een dataprobleem op één plek niet de hele uitrol stillegt. Dit is de volgorde die we aanhouden, met een realistische tijdsindicatie per stap voor een middelgrote organisatie.

1. Inventariseer de attributen (1 tot 2 weken):zet op een rij welke directory-attributen je echt gevuld hebt (afdeling, functie, locatie, manager) en hoe consistent de waarden zijn. Dit is het eerlijke startpunt, en meestal rommeliger dan mensen verwachten.
2. Verbeter de datakwaliteit (2 tot 4 weken):schoon de attribuutwaarden op zodat "Finance", "finance" en "FIN" één waarde worden. De koppeling is zo goed als de data eronder, dus deze stap betaalt zich in elke latere stap terug.
3. Ontwerp de mapping (1 tot 2 weken):bepaal welke attribuutwaarde welke set groepen en rollen moet verlenen. Group mining helpt hier: het kijkt naar bestaande lidmaatschappen en stelt voor welke groepen al met welke attributen samenhangen.
4. Pilot op één afdeling (2 tot 3 weken):draai het model op één goed begrepen afdeling. Houd het klein genoeg om elk resultaat met de hand te controleren en de mappingfouten te vangen voordat ze opschalen.
5. Rol uit per afdeling (4 tot 8 weken):breid afdeling voor afdeling uit, niet alles tegelijk. Elke afdeling heeft eigen randgevallen, en een gefaseerde uitrol houdt de impact klein.
6. Regel de uitzonderingen (doorlopend, vroeg beginnen):sommige mensen hebben echt toegang nodig die hun attribuut niet verleent. Leg elke uitzondering vast met een eigenaar en een reden, zodat die zichtbaar blijft en geen stille drift wordt.
7. Ga naar beheer in steady-state (doorlopend):zodra het model doorlopend wordt toegepast, verschuift het dagelijkse werk van toegang verlenen naar de mapping en de attribuutdata onderhouden. Zet hier het self-service portaal in zodat mensen toegang aanvragen en een manager of eigenaar goedkeurt.

IAM op Microsoft Entra ID en on-prem AD in de praktijk

De meeste vragen die we krijgen zijn Microsoft-specifiek, want daar wordt het groepmodel lastig. Een paar dingen die het waard zijn om te weten voordat je aanneemt dat dynamic groups het dekken.

• Dynamic groups en hun grenzen:Entra ID dynamic groups kennen al lidmaatschap toe vanuit een attribuutregel, en voor simpele gevallen zijn ze prima. Ze schieten tekort als één attribuut veel groepen tegelijk moet aansturen, als je ook on-prem AD-groepen nodig hebt, of als de regel logica vraagt die een membership-expressie niet aankan. Dat is het gat dat een attribuutmodel vult.
• Hybride met Entra Connect:in een hybride opzet synchroniseert Entra Connect on-prem objecten omhoog naar de cloud, maar een cloud-only dynamic group kan niet terugschrijven naar een on-prem AD-groep. ServiceChanger stuurt de cloudkant direct aan en draait een PowerShell-runbook op een hybrid worker voor de on-prem kant, en laat je bestaande Entra Connect de syncrichting doen die het al doet.
• Waar Conditional Access aanhaakt (alleen context):Conditional Access in Entra ID stuurt zijn policies vaak op groeplidmaatschap: "leden van deze groep moeten MFA doen". Correct, attribuutgedreven lidmaatschap zorgt dat die policies de juiste mensen raken. ServiceChanger configureert geen Conditional Access; het houdt de groepen die die policies lezen accuraat.
• Waar Intune aanhaakt (alleen context):Intune wijst deviceconfiguraties en app-uitrollen aan groepen toe. Zijn die groepen attribuutgedreven, dan belandt een nieuwe medewerker op een afdeling automatisch in de juiste uitrolgroep. ServiceChanger beheert het groeplidmaatschap dat Intune target, niet de Intune-policies zelf.

IAM-eisen vanuit NIS2 en ISO 27001

Toegangsbeheer is waar veel auditwerk landt, want NIS2 en ISO 27001 vragen allebei dat je aantoont, niet alleen beweert, dat toegang beheerst is. Attribuutgedreven lidmaatschappen maken drie veelvoorkomende eisen een stuk makkelijker te halen.

• Aantoonbare least privilege:beide kaders willen toegang beperkt tot wat een rol nodig heeft. Als een lidmaatschap bestaat omdat "afdeling = Finance", is de rechtvaardiging de attribuutwaarde zelf, wat least privilege van een bewering in iets verandert waar je naar kunt wijzen.
• Een audittrail:auditors willen zien wie welke toegang had en waarom. Attribuutgedreven lidmaatschappen geven een consistente, uitlegbare reden voor elke groep, dus het bewijs is de mapping plus de attribuutwaarde in plaats van een stapel losse beslissingen.
• Periodieke toegangsreviews:beide normen verwachten dat toegang volgens een schema wordt beoordeeld. Reviews gaan sneller als elk lidmaatschap terug te voeren is op een attribuut, want de beoordelaar checkt de mapping één keer in plaats van elke afzonderlijke toekenning. ServiceChanger draait het certificeringsproces niet zelf; het maakt de data die dat proces beoordeelt schoon en consistent.

Veelgemaakte fouten in toegangsbeheer

De meeste toegangsproblemen zijn niet technisch, het zijn procesproblemen die zich over jaren opstapelen. Dit zijn de zes die we het vaakst zien, en elk ervan is precies wat attribuutgedreven lidmaatschappen willen voorkomen.

• Rechten kopiëren van een collega:de snelste manier om toegang te geven is klonen wat je buurman heeft, en het is ook hoe rechten zich verspreiden zonder reden erbij. Twee jaar later weet niemand meer waarom de helft van de groeplidmaatschappen bestaat.
• Alles in één project willen doen:teams proberen elke afdeling, uitzondering en randgeval te modelleren voordat ze live gaan, en het project loopt vast. Eén schone afdeling in productie wint van een perfect model dat nooit uitkomt.
• De attributen niet eerst opschonen:mappen boven op vervuilde data betekent dat "Finance", "finance" en "FIN" elk een eigen set groepen krijgen. De mapping lijkt kapot terwijl de data het probleem is.
• Geen eigenaar per groep:een groep zonder eigenaar is een groep die niemand beoordeelt. Als een toegangsreview vraagt "waarom bestaat dit", heeft een groep zonder eigenaar geen antwoord en blijft jaren hangen.
• Uitzonderingen niet vastleggen:de ene persoon die "eenmalig" extra toegang nodig heeft, wordt permanente stille drift als de reden nooit wordt opgeschreven. Elke uitzondering heeft een eigenaar en een reden op papier nodig.
• Offboarding vergeten:toegang die volgens schema wordt gegeven maar alleen met de hand wordt weggehaald, loopt altijd achter. Als lidmaatschappen doorlopend attributen volgen, valt bij een vertrekker de toegang mee weg met de attributen, in plaats van maanden actief te blijven.

FAQ's over identity and access management (IAM)