Geautomatiseerd toegangsbeheer in Entra ID onderhouden na go-live

De meeste artikelen over toegangsbeheer automatiseren gaan over de start: schrijf je membership rules, koppel afdeling aan een set groepen, zet het aan. Dat is het leuke deel en het is goed te doen. Wat er daarna gebeurt, is waar het bij de meeste organisaties stilletjes misgaat. Een automatisch model is geen ding dat je één keer inricht en dan vergeet. Attributen veranderen, er komen nieuwe groepen bij, mensen vragen uitzonderingen aan, en na een jaar weet niemand meer precies waarom een bepaalde regel bestaat. Dit artikel gaat niet over hoe je begint, maar over hoe je het jaren correct houdt.

TL;DR

• Een attribuutgestuurd access-model is levend: attributen, groepen en rollen veranderen constant.
• De grootste risico's na go-live zijn attribuutkwaliteit die verslechtert, regels die stapelen, en uitzonderingen die permanent worden.
• Behandel je regelset als code: één plek waar hij staat, één plek waar je hem wijzigt, en een spoor van waarom.
• Maak van elke uitzondering een tijdelijke, niet een stille permanente afwijking.
• Een periodieke review van de regels zelf, niet alleen van de toegang, houdt het model uitlegbaar.

Waarom een automatisch model toch scheefgroeit

Attribuutgestuurd toegangsbeheer, of ABAC, koppelt groeps- en rollidmaatschap aan attributen zoals afdeling, functie en locatie, in Entra ID en on-prem Active Directory. Zolang de attributen kloppen en de regels helder zijn, doet het model precies wat het moet doen: het houdt toegang afgestemd op wie iemand is en wat iemand doet. Het probleem is dat geen van die twee vanzelf stabiel blijft.

Attribuutkwaliteit verslechtert stilletjes

Op de dag dat je aanzet, zijn de attributen meestal netjes: je hebt ze net gecontroleerd. Daarna beginnen ze te verlopen. Iemand verhuist naar een ander kantoor maar het locatieveld wordt niet bijgewerkt. Een functietitel wordt met de hand ingevoerd als "Sr. Controller" terwijl je regel op "Controller" matcht. Een reorganisatie hernoemt een afdeling en de helft van je regels matcht niks meer. Het model is niet stuk, maar het voedt zich met vervuilde data en geeft dus verkeerde uitkomsten. En omdat het automatisch draait, valt dat pas op als iemand ergens niet bij kan of juist ergens wél bij kan.

Regels stapelen sneller dan je opruimt

Elke nieuwe behoefte leidt tot een nieuwe regel. Een nieuw team, een nieuwe applicatie, een uitzondering voor één afdeling. Toevoegen is makkelijk en gebeurt onder druk. Opruimen gebeurt bijna nooit, want een regel weghalen voelt riskant: straks breekt er iets. Zo groeit de regelset gestaag, tot niemand meer het geheel overziet en twee regels elkaar tegenspreken zonder dat iemand het merkt.

Uitzonderingen worden permanent

Iemand heeft tijdelijk toegang nodig buiten het model om. Je maakt een handmatige uitzondering, met de bedoeling die later terug te draaien. "Later" komt nooit. De uitzondering blijft staan, valt buiten de regels, en is precies het soort staande toegang dat je met automatisering wilde voorkomen. Eén uitzondering is geen probleem. Vijftig ongedocumenteerde uitzonderingen ondermijnen het hele model.

Behandel je regelset als code

De belangrijkste gewoonte om een automatisch model gezond te houden, is je regels behandelen zoals je code behandelt. Dat betekent drie dingen.

• Eén bron. De regelset staat op één plek en dat is de waarheid. Niet deels in Entra ID, deels in een script, deels in iemands hoofd. Als je moet raden waar een regel vandaan komt, ben je het overzicht al kwijt.
• Wijzigen op één manier. Regels wijzig je via één vast proces, niet door hier en daar met de hand in de portal te klikken. Elke wijziging is een bewuste actie, geen bijvangst.
• Een spoor van waarom. Bij elke regel hoort een korte reden: waarom bestaat deze, sinds wanneer, en wie heeft hem aangevraagd. Zonder dat spoor durft niemand ooit iets weg te halen, en dan blijft alles staan.

Dit hoeft geen zwaar systeem te zijn. Het punt is dat je op elk moment kunt uitleggen waarom iemand ergens bij kan. Als het antwoord "dat weet niemand meer" is, is dat het echte probleem, niet de toegang zelf.

Attribuutkwaliteit bewaken

Omdat het hele model op attributen leunt, is attribuuthygiëne geen eenmalige opschoning maar een doorlopende taak. Een paar praktische controles:

1. Meet dekking. Hoeveel gebruikers hebben afdeling, functie en locatie gevuld? Een percentage dat daalt is een vroeg waarschuwingssignaal.
2. Zoek naar varianten. "Amsterdam", "AMS" en "Kantoor Amsterdam" horen hetzelfde te zijn. Vrije-tekstvelden lopen langzaam vol met varianten die je regels breken.
3. Controleer de bron. Als attributen uit een HR-systeem komen, ligt de kwaliteit daar. Slechte data bij de bron wordt niet beter door hem te automatiseren; hij wordt sneller verspreid.
4. Signaleer wezen. Gebruikers die aan geen enkele regel voldoen, of groepen die door geen enkele regel meer worden gevuld, zijn kandidaten voor onderzoek.

Dit is precies waarom een model dat attributen alleen leest en niet blind terugschrijft, veiliger is. Als de bron rommelig is, wil je dat zien en corrigeren, niet dat een tool de rommel automatisch als waarheid vastlegt.

Uitzonderingen tijdelijk houden

Uitzonderingen zijn onvermijdelijk. Het model dekt nooit honderd procent, en dat hoeft ook niet. De kunst is om uitzonderingen tijdelijk te houden in plaats van stil permanent.

• Geef elke uitzondering een einddatum. Toegang buiten het model om krijgt standaard een vervaldatum. Wil iemand hem verlengen, dan is dat een bewuste keuze, geen vergeten actie.
• Documenteer de reden. Eén regel: waarom deze uitzondering, wie heeft hem aangevraagd, wie keurde hem goed. Zonder dat is het over drie maanden onbekende staande toegang.
• Review ze apart. Uitzonderingen zijn per definitie het deel dat niet door de regels wordt gedekt, dus ze verdienen extra aandacht bij een review. Als een uitzondering vaak terugkomt, is dat een signaal dat je regelset hem eigenlijk zou moeten dekken.

Review de regels, niet alleen de toegang

De meeste organisaties doen periodiek een access review: klopt de toegang die mensen hebben nog? Dat is nuttig, maar bij een automatisch model is er een tweede review die minstens zo belangrijk is: klopt de regelset zelf nog?

Loop een of twee keer per jaar de regels langs en stel per regel drie vragen. Bestaat de reden nog waarom deze regel is gemaakt? Matcht hij nog daadwerkelijk gebruikers en groepen, of is hij dood geworden na een reorganisatie? Overlapt hij met een andere regel of spreekt hij die tegen? Deze review vangt precies het soort scheefgroei dat een gewone access review mist, omdat een access review naar de uitkomst kijkt en niet naar de logica erachter.

Een werkbaar onderhoudsritme

Je hoeft hier geen fulltime beheer op te zetten. Een licht, vast ritme is genoeg:

1. Continu: attribuutkwaliteit signaleren, zodat je vervuiling ziet voordat hij toegang beïnvloedt.
2. Per wijziging: elke nieuwe regel of uitzondering krijgt een reden en, bij uitzonderingen, een einddatum.
3. Elk kwartaal: een korte check op nieuwe uitzonderingen en op groepen die geen regel meer hebben.
4. Halfjaarlijks: een review van de regelset zelf, niet alleen van de toegang.
5. Bij elke reorganisatie: een gerichte check, want een afdeling die hernoemt of verdwijnt raakt vrijwel altijd meerdere regels tegelijk.

Een platform als ServiceChanger neemt het uitvoerende deel hiervan over: het draait de regels op Entra ID en on-prem Active Directory, herberekent toegang als attributen wijzigen, en legt elke toevoeging en intrekking vast zodat je bij een review een spoor hebt. Maar het onderhoud van de regels, de keuze wat een regel zou moeten zijn en wanneer een uitzondering weg mag, blijft mensenwerk. De tool voert de logica uit die jij hebt bepaald; hij bepaalt de logica niet voor je.

Tot slot

Toegangsbeheer automatiseren is geen project met een einddatum, het is een systeem dat je onderhoudt. Het goede nieuws is dat het onderhoud licht is als je het bij de start goed inricht: één plek voor je regels, een reden bij elke regel, en een einddatum bij elke uitzondering. De organisaties waar het na twee jaar nog klopt, zijn niet de organisaties met de slimste regels. Het zijn de organisaties die konden uitleggen waarom elke regel er stond.