Orphaned accounts: een groot offboardingrisico

Orphaned accounts en het offboardingrisico dat ze veroorzaken, staan zelden op een risicoregister totdat er iets misgaat. Een orphaned account is simpelweg een identiteit, een Entra ID-gebruiker, een on-prem AD-account, een service principal, die nog ingeschakeld is en nog toegang heeft, maar geen actieve eigenaar meer heeft die er legitiem werk mee doet. De persoon is vertrokken. Het contract is afgelopen. Het project is maanden geleden afgerond. Niemand heeft eraan gedacht de deur te sluiten.

Dit is geen zeldzame uitzondering. Het is een van de meest voorkomende bevindingen in access reviews en security-audits, en een geliefd doelwit voor wie een netwerk van buitenaf verkent, omdat een orphaned account vaak precies de toegang bevat die een vertrokken medewerker had, zonder dat er iemand op let zoals bij een actieve medewerker wel het geval zou zijn.

Dit artikel behandelt wat een account echt "orphaned" maakt in plaats van gewoon inactief, waarom het een reëel aanvalspad is, waar offboarding meestal misgaat, en hoe het automatiseren van de leaver-kant van de identiteitslevenscyclus dit gat definitief dicht.

Wat een account echt "orphaned" maakt

Niet elk inactief account is orphaned, en niet elk orphaned account oogt inactief. Dat onderscheid is belangrijk, want het bepaalt hoe je ze vindt.

Drie veelvoorkomende patronen

• Het schone leaver-gat. Het dienstverband van iemand eindigt, HR verwerkt de uitdiensttreding, maar het account wordt nooit uitgeschakeld omdat er geen geautomatiseerde trigger is die de HR-gebeurtenis koppelt aan het identiteitssysteem. Het account blijft volledig ingeschakeld staan, tot iemand het toevallig opmerkt.
• Het contractor- of projectaccount. Een leverancier, consultant of seizoenskracht krijgt een account voor een bepaalde periode. De opdracht eindigt, maar er is helemaal geen leaver-gebeurtenis in HR, omdat deze persoon nooit medewerker was, dus er wordt niets getriggerd om het account te sluiten.
• Het service- of gedeelde account zonder eigenaar. Een service-account is jaren geleden aangemaakt voor een integratie of een gedeelde mailbox. Degene die het instelde, is inmiddels vertrokken. Het account authenticeert nog steeds en houdt nog steeds welke toegang het oorspronkelijk kreeg, maar niemand in de organisatie kan vandaag vertellen waar het voor dient.

Al deze patronen delen hetzelfde onderliggende probleem: het bestaan van het account is niet langer gekoppeld aan een legitieme, actuele zakelijke behoefte, maar het technische account zelf weet dat niet en blijft gewoon doorwerken zoals voorheen.

Waarom orphaned accounts een belangrijk aanvalspad zijn

Een orphaned account is aantrekkelijk voor een aanvaller, of voor een kwaadwillende insider, om redenen die niet gelden voor het account van een actieve medewerker.

• Er let niemand op. Een ongebruikelijk aanmeldpatroon van een huidige medewerker kan opvallen omdat het afwijkt van diens normale werktijden. Bij een orphaned account is er geen legitieme gebruiker meer die kan opmerken dat er iets mis is.
• Het heeft vaak nog echte toegang. Groepslidmaatschappen worden zelden ingetrokken op het moment dat iemand vertrekt, tenzij iets dit automatisch doet, waardoor een orphaned account maandenlang toegang kan houden tot file shares, mailboxen en applicaties.
• Credentials worden niet vanzelf zwakker. Een wachtwoord dat twee jaar geleden is ingesteld, is vandaag nog precies zo geldig als toen, tenzij een beleid rotatie afdwingt of het account wordt uitgeschakeld.
• Het is een bekend patroon voor aanvallers. Credential stuffing en wraakzuchtige ex-medewerkers wijzen allebei richting accounts die ooit van iemand waren. Incident responders vinden geregeld dat het nog actieve account van een vertrokken medewerker het toegangspunt van een inbraak was.

Combineer die factoren en je krijgt een account dat zowel makkelijk te compromitteren is als onwaarschijnlijk een alarm afgaat als dat gebeurt, een slechtere combinatie dan bijna elk ander toegangsrisico in een typische Microsoft-omgeving.

Waar het offboardingproces echt misgaat

De meeste IT-teams hebben al een offboarding-checklist. Het probleem is meestal niet dat de checklist fout is, maar dat de uitvoering ervan afhangt van iemand die eraan denkt hem uit te voeren, elke keer weer, voor elk type vertrekker.

Een paar patronen komen steeds terug:

1. HR- en IT-systemen praten niet met elkaar. HR markeert iemand als uit dienst. Er gebeurt niets in Entra ID of on-prem AD tenzij iemand een koppeling heeft gebouwd, waardoor het uitschakelen van het account een handmatig ticket wordt.
2. Niet-medewerkers hebben helemaal geen trigger. Contractors en tijdelijke krachten staan vaak niet eens in het HR-systeem, dus er is geen gebeurtenis om op te vangen, en hun accounts blijven afhankelijk van iemand die eraan denkt ze handmatig te verwijderen.
3. Groeps- en rollidmaatschap maakt geen deel uit van de uitschakelstap. Ook als een account wordt uitgeschakeld, blijven de groepslidmaatschappen soms onaangeroerd, wat een probleem wordt als het account per ongeluk weer wordt ingeschakeld.

Dit zijn geen exotische fouten. Het is wat er standaard gebeurt wanneer offboarding afhangt van iemand die een handmatige stap moet onthouden, vermenigvuldigd over tientallen of honderden vertrekkers per jaar.

Staande toegang: hoe orphaned accounts stilletjes rechten opstapelen

Orphaned accounts zijn zelden meteen gevaarlijk. Ze worden geleidelijk gevaarlijker, op dezelfde manier waarop staande toegang zich opstapelt bij elk account dat niet actief wordt beheerd.

Gedurende het dienstverband van een medewerker is het gebruikelijk om groepslidmaatschappen van oude projecten en rechten uit functiewijzigingen mee te slepen, die alleen ooit zijn toegevoegd en nooit weer verwijderd. Tegen de tijd dat iemand vertrekt, heeft het account vaak meer toegang dan de laatste rol daadwerkelijk vereiste, laag voor laag opgebouwd over jaren. Wordt dat account vervolgens orphaned in plaats van netjes uitgeschakeld, dan blijft die opgebouwde toegang gewoon staan, onbewaakt en ongebruikt door wie dan ook met een legitieme reden om er iets mee te doen. Precies daarom worden staande toegang en orphaned accounts meestal in één adem genoemd: een orphaned account is waar staande toegang verandert van auditbevinding in een echt, exploiteerbaar risico.

Hoe geautomatiseerde leaver-flows het gat dichten

De oplossing is geen betere checklist. Het is het wegnemen van de afhankelijkheid van iemand die moet onthouden die checklist uit te voeren.

Koppel de leaver-gebeurtenis direct aan het toegangssysteem

Wanneer een HR-systeem iemand als uit dienst markeert, of een attribuut zoals dienstverbandstatus verandert in Entra ID of on-prem AD, moet die verandering de trigger zijn, niet een ticket dat in een wachtrij blijft liggen. Een attribute-based access control (ABAC)-engine die groeps- en rollidmaatschap toekent op basis van attributen zoals afdeling, locatie en functietitel, kan diezelfde logica omgekeerd toepassen: zodra het statusattribuut verandert, wikkelt het lidmaatschap in elke regelgestuurde groep zich automatisch af, omdat de regel die de toegang gaf niet langer klopt.

Dit is de kernwaarde van het automatiseren van de toegangskant van joiner/mover/leaver: toegang volgt continu de actuele attributen van de persoon, niet alleen op het moment dat iemand eraan denkt te controleren.

Vang ook de accounts op die HR niet kent

Contractor- en projectaccounts hebben dezelfde discipline nodig, ook zonder HR-registratie erachter. Een harde vervaldatum instellen bij het aanmaken van het account, gekoppeld aan de einddatum van het contract, geeft je een automatisch vangnet, ook als er geen uitdiensttredingsgebeurtenis is die opruiming triggert.

Gebruik access reviews als vangnet, niet als eerste verdedigingslinie

Zelfs met automatisering op de leaver-trigger vangt een terugkerende access review wat de automatisering miste: het gedeelde service-account waarvan niemand meer het doel weet, of het account dat handmatig buiten het normale proces is aangemaakt. Group mining, het bekijken van bestaande lidmaatschapspatronen om accounts en groepen te vinden die bij geen enkele huidige regel passen, is een praktische manier om deze te vinden zonder elk account met de hand te controleren.

Bron van orphaned account	Typische detectiemethode	Beste oplossing
Vertrokken medewerker, geen HR-naar-IT-koppeling	Handmatige audit of access review	Geautomatiseerde statusattribuut-trigger
Contractor-/projectaccount	Zelden ontdekt vóór een audit	Harde vervaldatum bij aanmaak
Service- of gedeeld account zonder eigenaar	Access review, group mining	Duidelijk eigenaarschap toewijzen, periodiek reviewen
Verouderde toegang na functiewijziging	Access review	Attribuutgestuurde groepslidmaatschap in plaats van handmatige toekenning

FAQ

Wat is het verschil tussen een inactief account en een orphaned account? Een inactief account is simpelweg niet recent gebruikt, maar kan nog een legitieme, actuele eigenaar hebben. Een orphaned account heeft helemaal geen actieve, legitieme eigenaar meer, wat het juist een beveiligingsrisico maakt en niet slechts rommel in het systeem.

Waarom worden orphaned accounts gezien als een belangrijk aanvalspad? Ze combineren reële, vaak brede toegang met de afwezigheid van wie dan ook die ongebruikelijke activiteit opmerkt, omdat er geen legitieme actieve gebruiker meer is die een aanmelding zou herkennen die niet van hemzelf is.

Kan ServiceChanger het account van een vertrekker automatisch uitschakelen in Entra ID? De ABAC-engine van ServiceChanger wikkelt automatisch de groeps- en rollidmaatschap van een vertrekker af zodra het statusattribuut verandert, waarmee de staande toegang verdwijnt die een orphaned account anders zou behouden. De volledige automatisering van uitschakelen en intrekken loopt via je eigen Azure Automation-runbooks, die de engine vanuit diezelfde attribuutwijziging kan aansturen.

Hoe vaak moeten we access reviews uitvoeren om orphaned accounts op te sporen? Een kwartaalritme is voor de meeste mid-market omgevingen een redelijke basis, met een strakkere cyclus voor bevoorrechte accounts. Een review verkleint het risico alleen als de bevindingen ook echt worden opgevolgd, niet slechts worden gearchiveerd.

Orphaned accounts zijn geen teken dat je team slordig is, ze zijn het voorspelbare resultaat van een offboardingproces dat afhangt van iemand die een handmatige stap moet onthouden voor elk type vertrekker. Door het intrekken van toegang te koppelen aan dezelfde attribuutwijziging die al onboarding triggert, dicht je dat gat automatisch. Voor meer over het opbouwen van access governance die een audit doorstaat, zie ons overzicht access governance en security compliance, of lees meer over offboarding en security op de blog.

Volgende stap

Wil je dat de toegang van een vertrekker automatisch wordt afgewikkeld zodra de status verandert, zodat orphaned accounts zich niet langer op de achtergrond opstapelen? Plan een demo of lees de documentatie over toegangsautomatisering.