4.7 Identiteits- en toegangsbeheer

Overzicht en motivatie

Elk verzoek dat je systemen raakt draagt een impliciete bewering: ik mag dit doen. Identiteits- en toegangsbeheer (IAM) is de discipline van beslissen of die bewering waar is. Het beantwoordt twee aparte vragen die mensen voortdurend door elkaar halen. Authenticatie bewijst wie je bent. Autorisatie bepaalt wat je mag doen zodra je dat hebt bewezen. Houd die twee ideeën gescheiden in je hoofd en de helft van de verwarring op dit gebied verdwijnt.

Voor grote teams is identiteit stilletjes de belangrijkste beheersmaatregel geworden die je bezit. Hoofdstuk 4.3 maakt het punt dat identiteit de nieuwe perimeter is, en hoofdstuk 4.1 bouwt zero trust erop: wanneer je ophoudt het netwerk te vertrouwen, is het enige wat overblijft om te vertrouwen een geverifieerde identiteit en een expliciet beleid. Die verschuiving betekent dat een zwakke wachtwoordherstelstroom of een vergeten serviceaccount niet langer een kleine bug is. Het is de voordeur. De meeste echte inbreuken zijn geen slimme exploits van geheugenveiligheidsgebreken. Het zijn gestolen inloggegevens, te brede rechten en accounts die maanden geleden uitgezet hadden moeten worden.

De inzet stijgt in omgevingen van onderneming en overheid. Een wereldwijde onderneming jongleert met tientallen overlappende directory’s, duizenden joiners en leavers per maand en partners die beperkte toegang nodig hebben tot een deel van je systemen. Een overheidsinstantie legt er smartcardinloggegevens bovenop, voorgeschreven niveaus van identiteitszekerheid en auditors die schriftelijk zullen vragen wie precies op een bepaalde dag een gegeven record kon aanraken. Dit hoofdstuk is uitgesproken over hoe je een identiteitslaag bouwt die die vragen goed beantwoordt zonder je mensen tot stilstand te malen.

Kernprincipes

Authenticatie en autorisatie zijn verschillende problemen. Identiteit bewijzen en rechten verlenen vragen aparte ontwerpen en aparte reviews.
Eén identiteit, veel systemen. Consolideer naar één bron van waarheid per identiteitspopulatie. Wildgroei van directory’s is een beveiligingsbug.
Standaard minste privilege. Begin bij nul toegang en voeg bewust toe, voor mensen en machines.
Elke inloggegeven is tijdelijk. Geef de voorkeur aan kortlevende, automatisch uitgegeven inloggegevens boven langlevende geheimen.
Deprovisioneren is net zo belangrijk als provisioneren. Toegang die haar behoefte overleeft is puur risico.
Phishingbestendig verslaat memoriseerbaar. Beweeg authenticatie richting passkeys en op hardware gebaseerde factoren.
Machines zijn ook identiteiten. Werklasten, pipelines en services hebben beheerde identiteit nodig, geen gedeelde statische sleutels.
Toegang is een levenscyclus, geen gebeurtenis. Verleen, beoordeel en trek in volgens schema, en bewijs dat je het deed.

Aanbevelingen

Scheid authenticatie van autorisatie en centraliseer beide

Authenticeer via één identiteitsprovider (IdP), een systeem dat identiteit verifieert en tokens uitgeeft die andere systemen vertrouwen. Laat dan elke applicatie haar eigen autorisatiebeslissingen nemen uit de identiteit en attributen die dat token draagt. Deze splitsing laat je authenticatie eenmaal versterken, voor iedereen, terwijl fijnmazige rechtenlogica dicht bij de data blijft die ze beschermt. Neem single sign-on (SSO) aan, waarbij één authenticatie toegang geeft tot veel applicaties, zodat je mensen één sterke login hebben in plaats van veertig zwakke. Federatie breidt hetzelfde vertrouwen uit over organisatiegrenzen, zodat de identiteiten van een partner je systemen kunnen benaderen zonder dat jij hun wachtwoorden beheert.

Gebruik de moderne protocollen waarvoor elk werkelijk bedoeld is

Drie standaarden doen het meeste werk, en elk heeft een taak. OpenID Connect (OIDC) is een identiteitslaag gebouwd op OAuth 2.0. Gebruik haar om wie is deze gebruiker te beantwoorden voor web- en mobiel aanmelden. OAuth 2.0 is een autorisatieraamwerk voor gedelegeerde toegang. Gebruik het om een applicatie een API te laten aanroepen namens een gebruiker zonder ooit zijn wachtwoord te zien (hoofdstuk 2.3). Security Assertion Markup Language (SAML) is de oudere op XML gebaseerde federatiestandaard. Ze blijft het werkpaard voor SSO van ondernemingen naar gevestigde bedrijfsapplicaties. Een gangbare fout is naar OAuth grijpen om direct te authenticeren. OAuth verleent toegang tot resources. OIDC zit erbovenop om identiteit vast te stellen. Kies OIDC voor nieuw gebruikersgericht aanmelden, houd SAML waar je ondernemingscatalogus het eist en verzin geen eigen tokenformaat.

Maak authenticatie phishingbestendig

Wachtwoorden alleen zijn op schaal onverdedigbaar. Eis multifactorauthenticatie (MFA), die iets wat je weet, iets wat je hebt en iets wat je bent combineert, voor elk menselijk account zonder uitzondering. Duw dan voorbij de zwakke factoren: eenmalige codes via sms zijn phishbaar en SIM-swapbaar. De sterke bestemming zijn passkeys en de onderliggende WebAuthn-standaard (een browser-API voor authenticatie met publieke sleutels), die een login binden aan een in hardware bewaarde privésleutel en aan de oorsprong van de echte site, zodat een nepsite niets kan oogsten wat het stelen waard is. Passkeys zijn ook wachtwoordloos, waar je gebruikers je dankbaar voor zullen zijn. Behandel accountherstel en wachtwoordherstel als onderdeel van het authenticatieoppervlak, want een aanvaller die je MFA niet kan verslaan zal in plaats daarvan de herstelstroom aanvallen.

Beheer de joiner-mover-leaver-levenscyclus en deprovisioneer snel

Identiteit is een levenscyclus. Een joiner heeft op dag één de juiste toegang nodig. Een mover die van rol verandert heeft nieuwe toegang nodig en, cruciaal, de oude toegang moet worden verwijderd, anders verzamelen ze langzaam de sleutels van het hele gebouw. Een leaver moet alle toegang snel verliezen, idealiter binnen minuten na de laatste dag, over elk systeem. Stuur dit aan vanuit een gezaghebbende bron, meestal het personeelssysteem, zodat een statuswijziging daar downstream automatisch provisioneert en deprovisioneert. Automatiseer het. Handmatige offboardingchecklists missen altijd iets, en het account dat ze missen is degene dat in het incidentrapport verschijnt.

Kies een autorisatiemodel en druk het uit als policy as code

Verleen rechten via rolgebaseerde toegangscontrole (RBAC), waarbij je rechten toewijst aan functierollen en mensen aan rollen, omdat het eenvoudig is om over te redeneren en makkelijk te auditen. Grijp naar attribuutgebaseerde toegangscontrole (ABAC) waar je contextbewuste beslissingen nodig hebt op basis van attributen als afdeling, dataclassificatie, locatie of tijdstip. De meeste volwassen organisaties draaien een hybride: RBAC voor de grove verleningen, ABAC voor de fijne voorwaarden. Welke je ook kiest, druk autorisatie uit als policy as code: regels geschreven in een versiebeheerde, testbare, beoordeelbare vorm in plaats van in een console geklikt. Policy as code maakt toegangsbeslissingen controleerbaar, vergelijkbaar en consistent over omgevingen, en laat je een rechtenwijziging testen voordat ze wordt opgeleverd.

Dwing minste privilege af met just-in-time-toegang en PAM

Pas het principe van minste privilege toe: elke identiteit krijgt de minimale toegang die ze nodig heeft en niets meer. Permanent privilege is de vijand, want een permanent verleend recht is een recht beschikbaar voor elke aanvaller die op dat account landt, op elk moment. Geef de voorkeur aan just-in-time (JIT)-toegang, waarbij een persoon verhoogde rechten aanvraagt voor een begrensd venster, ze na goedkeuring krijgt en ze automatisch verliest wanneer het venster sluit. Neem voor je gevaarlijkste accounts privileged access management (PAM) aan: een systeem dat administratieve inloggegevens in een kluis bewaart, bevoorrechte sessies bemiddelt en opneemt en verhoging op aanvraag uitgeeft. Het doel is nul permanente adminrechten, zodat zelfs een volledig gecompromitteerde laptop niets duurzaams oplevert.

Geef machines en werklasten echte identiteit

Mensen zijn maar de helft van je identiteiten. Services, pipelines, containers en functies authenticeren zich allemaal bij iets, en te vaak doen ze het met een langlevend geheim geplakt in een configuratiebestand. Vervang statische sleutels door beheerde werklastidentiteit: kortlevende inloggegevens automatisch uitgegeven aan een werklast op basis van waar ze draait en wat ze is. Gebruik mutual TLS (mTLS), waarbij beide kanten van een verbinding certificaten presenteren, voor authenticatie tussen services. Bewaar resterende geheimen in een toegewijde geheimenbeheerder met rotatie, nooit in broncode of images (hoofdstuk 4.2). Kortlevende, automatisch geroteerde werklastinloggegevens nemen de meest voorkomende oorzaak van lekken van cloudinloggegevens weg.

Maak identiteit het controlevlak en beoordeel toegang continu

In een zero-trustarchitectuur (hoofdstuk 4.1) is identiteit waar beleid wordt bepaald en afgedwongen, dus investeer daar dienovereenkomstig. Sluit dan de lus met toegangsreviews, ook hercertificering genoemd: volgens schema bevestigt de eigenaar van elk systeem dat elke persoon en machine met toegang die nog nodig heeft, en trekt in wat ze niet kunnen rechtvaardigen. Voed elke authenticatie- en autorisatiegebeurtenis in een auditspoor dat wie wat wanneer benaderde en onder welk beleid beantwoordt (hoofdstuk 4.6). Toegangsreviews zijn hoe je privilegewildgroei bestrijdt, de langzame opeenhoping van rechten waarvan geen enkele verlening ooit onredelijk leek maar die samen een account veel te krachtig maken.

Afwegingen: voor- en nadelen

Beslissing	Voordelen	Nadelen
Gecentraliseerde IdP met SSO	Eén sterke login, consistent beleid, makkelijke audit	Single point of failure. Een storing sluit iedereen buiten
RBAC	Eenvoudig, controleerbaar, vertrouwd	Rolexplosie. Grof voor contextgevoelige behoeften
ABAC	Fijnmazig, contextbewust, schaalt met attributen	Moeilijker te ontwerpen, testen en over te redeneren
Passkeys / WebAuthn	Phishingbestendig, wachtwoordloos, sterk	Herstel- en apparaatverliesstromen vragen zorgvuldig ontwerp
Just-in-time-toegang	Bijna nul permanent privilege	Wrijving. Vraagt snelle, betrouwbare goedkeuringspaden
Federatie met partners	Geen extern wachtwoordbeheer. Afgebakend vertrouwen	Vertrouwen hangt af van de eigen hygiëne van de partner
Langlevende servicesleutels	Triviaal makkelijk op te zetten	Lekgevoelig. De belangrijkste oorzaak van inbreuken op inloggegevens

De centrale spanning is beveiliging tegenover wrijving. Elke maatregel die het aanvalsoppervlak verkleint (MFA op alles, JIT-verhoging, kortlevende inloggegevens) voegt ook een stap toe aan iemands dag, en mensen routeren rond maatregelen die te veel pijn doen. Los het op door het veilige pad het makkelijke pad te maken: SSO zodat sterke authenticatie één tik is, passkeys zodat er geen wachtwoord is om te typen en geautomatiseerde provisioning zodat de juiste toegang gewoon verschijnt. Besteed je wrijvingsbudget waar de schadezone het grootst is, aan bevoorrechte en productietoegang, en houd alledaagse toegang bijna wrijvingsloos.

Vragen om met je team te bespreken

Hoe snel kun je vandaag werkelijk alle toegang intrekken voor iemand die vertrekt, en hoe weet je dat het werkte? De snelheid van deprovisioneren is een directe maat voor je identiteitsvolwassenheid, omdat een leaver wiens toegang blijft hangen een onbewaakt account met echte rechten is. In een grote organisatie met tientallen losse systemen is het eerlijke antwoord vaak “we zijn niet zeker”, en het gat zijn meestal de applicaties die nooit aan de centrale identiteitsprovider zijn gekoppeld. Neem een echt recent vertrek mee en traceer elk systeem dat ze konden raken, tijdstempels controlerend voor wanneer elke toegang werkelijk eindigde. Besluit een doel, zoals volledige intrekking binnen een uur na de statuswijziging in het personeelssysteem, en instrumenteer het zodat je het kunt bewijzen in plaats van hopen. Als enig systeem leunt op iemand die een handmatige stap onthoudt, is dat het account dat een toekomstige inbreuk zal gebruiken.
Waar heb je nog permanente bevoorrechte toegang en langlevende statische inloggegevens, en wat zou het kosten om ze te elimineren? Permanente adminrechten en permanente servicesleutels zijn de twee bezittingen die aanvallers het meest willen, omdat ze duurzaam en krachtig zijn. Maak een inventaris van elke mens met altijd aan productie- of administratieve toegang en elke service die zich met een statische sleutel authenticeert, en vraag eerlijk welke daarvan naar just-in-time-verhoging of kortlevende werklastidentiteit kunnen. De concurrerende overweging is operationele angst: teams houden permanente toegang omdat noodmomenten er veiliger mee voelen, dus je moet noodverhoging snel en betrouwbaar maken voordat je de permanente rechten wegneemt. Neem de lijst mee naar de discussie en rangschik posten naar schadezone, met productie- en administratieve toegang eerst. De eindtoestand om naar te streven is nul permanente adminrechten en geen statische sleutel die één deploy overleeft.
Heb je één gezaghebbende identiteit per persoon en per werklast, of meerdere, en wat kost de wildgroei je? Wildgroei van directory’s, waar dezelfde mens bestaat als vijf accounts over vijf systemen met afdrijvende attributen, is waar deprovisioneringsgaten en wezen-toegang worden geboren. Consolideren naar één bron van waarheid per identiteitspopulatie is een van de investeringen met de hoogste hefboom die een groot team kan doen, omdat elke downstreammaatregel afhangt van weten dat twee records dezelfde persoon zijn. Neem een inventaris mee van je identiteitsstores en breng in kaart welke gezaghebbend zijn tegenover welke gemakskopieën zijn die niemand beheert. De afweging is dat consolidatie een grote, onglamoureuze migratie is die met functiewerk om aandacht strijdt. Besluit of de doorlopende kosten van wildgroei, in auditpijn en inbreukrisico, rechtvaardigen die migratie nu te financieren in plaats van na het volgende incident.
Zijn je sterkste authenticatiefactoren werkelijk phishingbestendig, en wat belet je wachtwoorden voorgoed uit te faseren? De factor die een aanvaller niet kan phishen is degene die diefstal van inloggegevens als je dominante inbreukpad beëindigt, en passkeys gebonden aan WebAuthn zijn de enige breed inzetbare optie die die lat haalt. In een grote organisatie is het eerlijke beeld meestal gemengd: passkeys voor sommigen, eenmalige codes via sms voor anderen en een lange staart legacyapplicaties die nog een wachtwoord alleen accepteren. De concurrerende overweging is echt, omdat passkeys het moeilijke probleem naar herstel en apparaatverlies verschuiven, en een onhandige herstelstroom het nieuwe zachte doelwit wordt waar een aanvaller simpelweg naartoe pivoteert. Neem de dekkingsgetallen mee per factortype, de lijst applicaties die nog op een wachtwoord terugvallen en een ontworpen accountherstelpad dat je zou vertrouwen tegen een vastberaden social-engineeringpoging. Koppel het doel in omgevingen van onderneming en overheid aan elk voorgeschreven zekerheidsniveau, aangezien een systeem met hoge zekerheid dat nog een phishbare factor toestaat zowel een compliance- als een beveiligingsgat heeft.
Hoe bepaal je welke toegang elke identiteit krijgt, en kun je die beslissing vergelijken, testen en bewijzen voordat ze wordt opgeleverd? De kloof tussen “iemand klikte rechten in een console” en “een beoordeeld, versiebeheerd beleid” is het verschil tussen een toegangsmodel dat je kunt auditen en een waarvoor je alleen je excuses kunt aanbieden. Voor een groot team is de druk elke applicatie haar eigen maatwerkregels te laten laten groeien, wat stilletjes rolexplosie aan de RBAC-kant en niet te testen voorwaarden aan de ABAC-kant produceert, tot niemand kan zeggen wat een gegeven verlening werkelijk toestaat. De concurrerende overweging is leveringssnelheid, omdat autorisatie uitdrukken als policy as code een reviewstap toevoegt die een consoleklik niet heeft, en teams onder deadline de wrijving verwensen tot de eerste gefaalde audit of te brede verlening hun zaak maakt. Neem een echte rechtenwijziging mee en traceer hoe ze zou worden voorgesteld, getest, beoordeeld en teruggedraaid, plus een telling van hoeveel rollen je hebt en hoeveel niemand kan uitleggen. In omgevingen van onderneming en overheid zal een auditor vragen precies te tonen wie op een gegeven dag een record kon benaderen en onder welke regel, en alleen een vergelijkbaar, testbaar beleid beantwoordt dat zonder haast.
Wanneer trok een toegangsreview voor het laatst iets echts in, en wie is verantwoordelijk wanneer privilegewildgroei ongecontroleerd blijft? Toegangsreviews zijn de maatregel die de langzame opeenhoping van rechten bestrijdt waarvan geen enkele verlening ooit onredelijk leek, en een review die nooit iets intrekt is reviewtheater dat papierwerk produceert in plaats van veiligheid. In een grote organisatie is de faalwijze de rubberen stempel: systeemeigenaren hercertificeren honderden posten in één zitting en keuren ze allemaal goed omdat het werkelijk evalueren van elke vervelend is en de prikkel om toegang te laten stromen sterker is dan de prikkel om te snijden. De concurrerende overweging is dat zinvolle reviews eigenaartijd kosten en af en toe iemands werkstroom breken wanneer toegang die ze stilletjes gebruikten verdwijnt, dus je moet de review gericht en op risico gedreven maken in plaats van een ongedifferentieerde lijst. Neem het intrekkingspercentage van je laatste cyclus mee, het gemiddeld aantal rechten per persoon en bewijs van wie de hercertificering van elk systeem bezit. Noem in omgevingen van onderneming en overheid de verantwoordelijke functionaris voor elke review en het ritme waaraan ze worden gehouden, want privilegewildgroei die niemand verantwoordelijk is te vangen is precies de toestand die auditors en aanvallers allebei uitbuiten.

Sectorperspectief

Startup. Koop identiteit, bouw haar niet. Eén gehoste identiteitsprovider met SSO, passkeys verplicht en offboarding met één klik geeft een handvol engineers een houding van ondernemingskwaliteit voor een vergoeding per gebruiker. Leun op de ingebouwde werklastidentiteit van de provider zodat er geen enkele langlevende cloudsleutel in je pipeline is, en gebruik OIDC en OAuth 2.0 kant-en-klaar in plaats van tokenafhandeling te verzinnen die je niet kunt onderhouden.

Kleinbedrijf. Zonder identiteitsspecialist in dienst geef je de voorkeur aan de SSO en MFA die al gebundeld zijn in de tools die je betaalt, en zet je ze aan in plaats van een apart platform te zoeken. Behandel het joiner-mover-leaver-probleem als korte schriftelijke checklist gekoppeld aan wie het aannemen bezit, en geef de voorkeur aan passkeys omdat ze de helpdesklast voor wachtwoordherstel wegnemen die je niemand kunt besparen. Vermijd gedeelde logins, aangezien ze de goedkope gewoonte zijn die later toerekening en intrekking onmogelijk maakt.

Grote onderneming. Het werk is consolidatie en governance over veel directory’s en teams: één gezaghebbende identiteitsprovider aangestuurd door het personeelssysteem, geautomatiseerde joiner-mover-leaver-stromen, RBAC voor functies met ABAC voor context en privileged access management met sessieopname. Druk autorisatie uit als policy as code zodat wijzigingen vergelijkbaar en testbaar zijn, draai geplande toegangsreviews die werkelijk intrekken en standaardiseer de interface zodat applicaties zich op centrale identiteit koppelen in plaats van elk hun eigen login te laten groeien.

Overheid. Aanbestedingsregels, transparantie en publieke verantwoording sturen het ontwerp. Bind authenticatie aan hardware-inloggegevens zoals PIV- of CAC-smartcards, stel niveaus van identiteitszekerheid vast volgens NIST SP 800-63 zodat systemen met hoger risico factoren met hogere zekerheid eisen en houd onveranderlijke auditlogs bij die precies beantwoorden wie wat wanneer benaderde. Publiceer de afhandeling in gewone taal van burgergerichte identiteit, houd klant- en personeelsidentiteitsstacks gescheiden en zorg dat elke bevoorrechte actie op een gevoelig systeem wordt bemiddeld en vastgelegd voor de auditors die ernaar zullen vragen.

Voorbeelden

Startup. Een startup van twintig personen kan geen identiteitsteam bemannen, dus koopt ze er een. Elke werknemer meldt zich aan via één gehoste identiteitsprovider met SSO naar e-mail, codehosting, cloudconsole en de interne app, en passkeys zijn verplicht zodat er geen wachtwoorden zijn om te phishen. Offboarden is één klik: de persoon in de identiteitsprovider uitschakelen snijdt de toegang overal tegelijk af. Voor hun eigen product gebruiken ze OIDC voor gebruikersaanmelding en OAuth 2.0 om integraties hun API te laten aanroepen met beperkte tokens. Authenticatie van service naar cloud gebruikt de ingebouwde werklastidentiteit van de provider, zodat er nergens in hun pipeline een enkele langlevende cloudsleutel is. Dit kost een bescheiden vergoeding per gebruiker en koopt hen een identiteitshouding die sterker is dan veel ondernemingen draaien.

Grote onderneming. Een multinationale bank heeft een decennium vier directory’s en honderden applicaties opgehoopt, sommige gefedereerd via SAML, sommige met eigen lokale logins. Ze financiert een consolidatieprogramma: één gezaghebbende identiteitsprovider, aangestuurd door het personeelssysteem, met geautomatiseerde joiner-mover-leaver-stromen die bij aanname provisioneren en binnen minuten na beëindiging intrekken. RBAC dekt standaard functies terwijl ABAC regels voor dataresidentie en screening afdwingt voor grensoverschrijdende toegang. Beheerders hebben geen permanente productietoegang. Ze vragen just-in-time-verhoging aan via een privileged-access-managementsysteem dat elke sessie opneemt. Kwartaalmatige toegangsreviews dwingen systeemeigenaren te hercertificeren of in te trekken, en elke beslissing wordt uitgedrukt als policy as code zodat auditors precies kunnen vergelijken wat wanneer veranderde.

Overheid. Een federale instantie geeft smartcards voor persoonlijke identiteitsverificatie (PIV) uit, en het militaire equivalent, de common access card (CAC), aan haar personeel, zodat authenticatie is gebonden aan een hardware-inloggegeven in plaats van een wachtwoord. Haar identiteitsprogramma volgt de federale aanpak van identiteits-, inloggegevens- en toegangsbeheer (FICAM) en stelt niveaus van identiteitszekerheid vast volgens de richtlijn NIST SP 800-63 van het National Institute of Standards and Technology, zodat systemen met hoger risico inloggegevens met hogere zekerheid eisen. Burgergerichte diensten gebruiken een aparte klantidentiteitsstack op een lager zekerheidsniveau met sterke MFA. Toegangsreviews en onveranderlijke auditlogs voeden direct het continue autorisatiebewijs van de instantie (hoofdstuk 4.6), en elke bevoorrechte actie op een geclassificeerd systeem wordt bemiddeld en vastgelegd.

Zakelijke onderbouwing: motivatie, ROI en TCO

Het rendement op identiteitsinvestering komt uit je dominante inbreukvector uit de gevarenzone halen. Gestolen inloggegevens en accounts met te veel rechten drijven een groot deel van de echte incidenten, en elk draagt een zware staart: incidentrespons, boetes van toezichthouders, inbreukmelding en blijvende reputatieschade. Phishingbestendige MFA alleen elimineert het meest voorkomende binnendringpad, en geautomatiseerd deprovisioneren sluit het wezen-accountgat dat een routinevertrek in een blootstelling verandert. Dit behoren tot de goedkoopste risicovermindering beschikbaar per uitgegeven euro.

De total cost of ownership is echt maar begrensd. Ze omvat licenties van de identiteitsprovider, een privileged-access-management- en geheimenplatform, de engineering om elke applicatie aan centrale identiteit te koppelen en de doorlopende inspanning van toegangsreviews. De grotere kost is organisatorisch: directory’s consolideren en SSO achteraf op legacyapplicaties aanbrengen is langzaam, onglamoureus werk dat met functies strijdt. Weeg het af tegen het alternatief. Gefragmenteerde identiteit besteedt voor altijd hetzelfde geld in de vorm van handmatig offboarden, audithasten en helpdeskwachtwoordherstel, plus de uiteindelijke kosten van de inbreuk die fragmentatie waarschijnlijk maakt. Formuleer identiteit voor het bestuur als het controlevlak voor zero trust: consolidatie en automatisering zijn een eenmalige investering die zowel inbreukrisico als de terugkerende kosten van audits, offboarden en toegangssupport verlaagt.

Antipatronen en valkuilen

Wezen-accounts. Toegang die de persoon of het doel overleeft, vooral onbewaakte serviceaccounts en vergeten externen.
Overal permanente admin. Altijd aan bevoorrechte toegang in plaats van just-in-time-verhoging, wat elk gecompromitteerd adminaccount duurzame macht geeft.
Langlevende statische sleutels. Servicecredentials geplakt in configuratie of CI die nooit verlopen en uiteindelijk lekken.
Wildgroei van directory’s. Dezelfde persoon als veel ongecontroleerde accounts, zodat geen wijziging ooit volledig doorwerkt.
Gedeelde accounts. Inloggegevens gebruikt door meerdere mensen, wat toerekening vernietigt en intrekking onmogelijk maakt.
Sms als je sterke factor. Phishbare, SIM-swapbare eenmalige codes behandelen als voldoende MFA.
Rolexplosie. Zoveel smalle RBAC-rollen dat het model niet meer te auditen is en niemand weet wat een rol verleent.
Deprovisioneren als handmatige checklist. Menselijke offboardingstappen die onvermijdelijk het ene account missen dat ertoe doet.
OAuth gebruikt voor authenticatie. Een toegangstoken behandelen als bewijs van identiteit in plaats van OIDC te gebruiken.
Reviewtheater. Toegangshercertificeringen afgestempeld zonder dat iemand werkelijk behoefte evalueert.

Volwassenheidsmodel

Niveau 1, Initiëren: Elke applicatie heeft haar eigen login. Wachtwoorden zonder consistente MFA. Provisioneren en offboarden zijn handmatig, reactief en traag. Wezen-accounts hopen zich op. Servicecredentials zijn langlevende statische sleutels. Geen toegangsreviews. Rechten worden verleend en nooit herzien.
Niveau 2, Ontwikkelen: SSO dekt grote applicaties via een centrale identiteitsprovider, maar de dekking is ongelijk over teams. MFA is vereist voor de meeste menselijke toegang. Basale RBAC bestaat. Joiner-mover-leaver is deels geautomatiseerd vanuit het personeelssysteem. Sommige bevoorrechte accounts staan in een kluis. Toegangsreviews gebeuren af en toe en inconsistent.
Niveau 3, Standaardiseren: Een geconsolideerde identiteitsprovider is gezaghebbend voor het personeel, met geautomatiseerd provisioneren en snel deprovisioneren organisatiebreed afgedwongen. Phishingbestendige MFA is standaard en gedocumenteerd. RBAC plus ABAC wordt uitgedrukt als policy as code. Privileged access management met sessieopname is aanwezig. Werklastidentiteit vervangt de meeste statische sleutels. Geplande toegangsreviews worden afgedwongen en geaudit tegen een schriftelijk beleid dat elk team volgt.
Niveau 4, Beheersen: Het identiteitsprogramma wordt gemeten aan de hand van uitgangswaarden en beheerst met data. Je volgt de deprovisioneringstijd van statuswijziging in het personeelssysteem tot volledige intrekking, MFA- en passkeydekking per populatie, het aantal accounts met permanent bevoorrechte toegang, het aantal langlevende statische sleutels nog in gebruik, aantallen wezen-accounts en intrekkingspercentages van toegangsreviews. Statistieken dragen doelen, zoals volledige intrekking binnen een uur en nul netto nieuwe permanente adminverleningen, en het overschrijden van een drempel triggert onderzoek in plaats van een schouderophaal. Autorisatiewijzigingen worden in de pipeline getest en elke go/no-go op een toegangsverlening wordt door bewijs gedreven, niet door gewoonte.
Niveau 5, Orkestreren: Identiteit is het continu verbeterde controlevlak voor zero trust, geïntegreerd met beveiliging, risico en joiner-mover-leaver-planning over de organisatie. Passkeys zijn de standaard en wachtwoorden worden uitgefaseerd. Nul permanent privilege wordt bereikt door just-in-time-verhoging, en alle werklasten gebruiken kortlevende, automatisch geroteerde inloggegevens en mTLS. Autorisatie is volledig policy as code. Toegangsreviews zijn continu en risicogedreven, deprovisioneren is bijna onmiddellijk en elke beslissing produceert automatisch auditbewijs. Het model past zich aan naarmate risicosignalen verschuiven en toegang dynamisch aanscherpt of versoepelt in plaats van volgens een vast ritme.

Ideeën voor discussie

Wat zou er nodig zijn om nul permanente administratieve toegang te bereiken, en welk break-glasspad zou dat veilig maken?
Waar is ABAC haar complexiteit waard in jouw omgeving tegenover bij gewone RBAC blijven?
Hoe agressief moet je wachtwoorden uitfaseren ten gunste van passkeys, en welke herstelstroom vervangt ze?
Welke applicaties staan nog buiten je centrale identiteitsprovider, en wat houdt ze daar?
Hoe geef je partners en klanten beperkte toegang zonder hun beveiligingshygiëne te erven?
Welke enkele statistiek vangt je deprovisioneringssnelheid het best, en meet je die vandaag?

Belangrijkste inzichten

Authenticatie bewijst wie je bent. Autorisatie bepaalt wat je mag doen. Ontwerp en beoordeel ze afzonderlijk.
Consolideer naar één gezaghebbende identiteitsprovider met SSO. Wildgroei van directory’s is een beveiligingsdefect, geen gemak.
Automatiseer de joiner-mover-leaver-levenscyclus en maak deprovisioneren snel en aantoonbaar.
Gebruik OIDC voor gebruikersaanmelding, OAuth 2.0 voor gedelegeerde API-toegang en SAML waar de ondernemingscatalogus het nodig heeft. Gebruik OAuth niet als authenticatie.
Beweeg authenticatie naar phishingbestendige passkeys en WebAuthn. Eis overal MFA en behandel zwakke factoren als noodoplossing.
Dwing minste privilege af met just-in-time-toegang en privileged access management. Streef naar nul permanente adminrechten.
Geef machines echte identiteit met kortlevende werklastinloggegevens en mTLS. Elimineer langlevende statische sleutels.
Maak identiteit het controlevlak voor zero trust (hoofdstuk 4.1) en sluit de lus met continue toegangsreviews en auditbewijs (hoofdstuk 4.6).

Referenties en verder lezen

National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines (identity assurance, authentication, and federation levels)
National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
National Institute of Standards and Technology, SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
National Institute of Standards and Technology, SP 800-53: Security and Privacy Controls, Access Control (AC) and Identification and Authentication (IA) families
The OAuth 2.0 Authorisation Framework, IETF RFC 6749, and the OAuth 2.0 Security Best Current Practice
OpenID Connect Core 1.0 specification, OpenID Foundation
Security Assertion Markup Language (SAML) 2.0 specification, OASIS
Web Authentication (WebAuthn) Level 2, W3C Recommendation, and FIDO2 / FIDO Alliance passkey specifications
Federal Identity, Credential, and Access Management (FICAM) architecture and playbooks, U.S. General Services Administration
FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors
Open Policy Agent (OPA) documentation, Cloud Native Computing Foundation (policy-as-code for authorisation)