Service account governance in Entra ID en AD

Loop door de meeste Microsoft-tenants en je vindt twee heel verschillende werelden. Menselijke identiteiten krijgen onboarding-checklists, access reviews, MFA en offboarding-tickets. Service accounts worden één keer aangemaakt, krijgen "voor de zekerheid" veel meer rechten dan nodig, en worden vervolgens jarenlang met rust gelaten. Service account governance is de praktijk om dat gat te dichten: dezelfde discipline toepassen op non-human identities die je al toepast op mensen. Het klinkt vanzelfsprekend zodra je het hardop zegt. In de praktijk doet bijna niemand het consequent.

Dat gat is geen kleine omissie. Service accounts, app registrations, managed identities en automation accounts hebben vaak permanente, hoog-geprivilegieerde toegang zonder MFA, zonder owner die regelmatig checkt, en met een wachtwoord of secret dat één keer is ingesteld en nooit meer geroteerd. Het is precies het type account waar een aanvaller naar zoekt, en precies het type account dat de meeste identity governance-programma's stilzwijgend overslaan. Dit artikel behandelt waarom service accounts anders behandeld worden, hoe ze governen er in de praktijk uitziet, en hoe je ze onderbrengt in hetzelfde toegangsmodel dat je voor mensen gebruikt.

Waarom service accounts tussen wal en schip vallen

Non-human identities worden niet verwaarloosd omdat niemand erom geeft. Ze worden verwaarloosd omdat de normale governance-machinerie gebouwd is met mensen in gedachten.

Ze lopen niet via HR

Elk menselijk account is gekoppeld aan een levenscyclusgebeurtenis: aangenomen, gepromoveerd, overgeplaatst, uit dienst. Die levenscyclus triggert access reviews, offboarding en akkoord van de manager. Een service account heeft geen HR-record. Niemands vertrek triggert een review van de service accounts die diegene heeft aangemaakt. Ze blijven gewoon draaien, stilletjes, lang nadat het project of de persoon weg is.

Ownership is bewust vaag

Een menselijk account heeft een duidelijke owner: de gebruiker zelf. Een service account wordt aangemaakt door één engineer, gebruikt door een applicatie of script dat een ander team onderhoudt, en uiteindelijk kan niemand met zekerheid zeggen wie er verantwoordelijk voor is. Als ownership onduidelijk is, heeft een reviewcyclus niets om aan te hangen, en blijft het account standaard met rust.

Ze aanraken is eng, dus niemand doet het

Een menselijk account uitschakelen dat toch nog nodig blijkt, is een ongemak. Een service account uitschakelen dat een nachtelijke batchjob of een integratie draait die niemand heeft gedocumenteerd, kan een systeem platleggen. Die asymmetrie duwt IT-teams richting niets doen, en zo stapelen geprivilegieerde accounts zich tien jaar lang op zonder ooit gereviewd te worden.

Ze zijn vaak overgeprovisioneerd vanaf dag één

Onder tijdsdruk is het gebruikelijk om een service account Global Administrator of een brede Contributor-rol te geven "zodat het werkt," met de mentale notitie om dat later te versmallen. Dat later komt zelden. Het resultaat is een populatie accounts met veel meer permanente rechten dan de taak daadwerkelijk vereist.

Hoe goede service account governance eruitziet

Non-human identities governen betekent niet dat je ze exact als mensen behandelt. Het betekent dat je dezelfde onderliggende principes toepast, aangepast aan hoe machines daadwerkelijk werken.

Elk account heeft een genoemde, verantwoordelijke owner

Geen team, geen gedeelde mailbox, een persoon. De owner is degene die wordt aangesproken als het account in een review naar voren komt, en die verantwoordelijk is als het geroteerd, versmald of uitgefaseerd moet worden.

Doel en scope moeten gedocumenteerd zijn, niet aangenomen

Wat doet dit account, waar maakt het verbinding mee, en wat heeft het daadwerkelijk nodig? Eén regel omschrijving bij aanmaak bespaart later uren speurwerk, wanneer iemand een onbekend account met domain admin-rechten vindt en moet uitzoeken of het veilig is om aan te raken.

Credentials hebben een rotatie- en verloopbeleid nodig

Certificaten en secrets voor app registrations en service principals horen een vervaldatum en een rotatieproces te hebben, net zoals wachtwoordbeleid voor mensen geldt. Een account met een secret dat nooit verloopt is een permanent risico dat alleen maar groter wordt met de tijd.

Toegang moet beperkt zijn tot wat de taak vereist

Dezelfde least-privilege gedachte die geldt voor de groepslidmaatschappen van een nieuwe medewerker, geldt hier ook. Een service account dat alleen een mailbox hoeft te lezen, hoort geen schrijfrechten te hebben op elke SharePoint-site in de tenant.

Reviews moeten volgens een schema gebeuren

Service accounts horen in dezelfde terugkerende access review-cadans als menselijke accounts, niet in een apart proces dat elk kwartaal weer wordt uitgesteld. Als niemand kan bevestigen dat een account nog nodig is, is dat op zich al een bevinding om op te acteren.

Een inventaris opbouwen: je kunt niet governen wat je niet ziet

De eerste echte stap in service account governance is bijna altijd discovery, omdat de meeste organisaties geen betrouwbare lijst hebben van wat er bestaat.

Waar non-human identities zich verstoppen

• On-prem AD service accounts, vaak jaren geleden aangemaakt voor een specifieke applicatie en nooit centraal gedocumenteerd.
• Entra ID app registrations en enterprise apps, sommige met client secrets of certificaten waarvan niemand zich herinnert dat ze zijn uitgegeven.
• Managed identities, die van nature een lager risico vormen maar toch onderdeel moeten zijn van het volledige overzicht.
• Automation- en runbook-accounts, gebruikt voor geplande scripts en integraties, vaak overgeprivilegieerd "voor de zekerheid."
• Gedeelde of generieke accounts die zich voordoen als service account, aangemaakt zodat iemand kan inloggen zonder de eigen identiteit te gebruiken, wat accountability verder vertroebelt.

Een eenvoudige classificatie helpt prioriteren

Signaal	Wat het je vertelt
Geen recente sign-in of gebruiksactiviteit	Kandidaat voor uitschakelen of verwijderen
Geprivilegieerde rol (Global Admin, Domain Admin) zonder gedocumenteerde owner	Hoge prioriteit voor onderzoek
Secret of certificaat bijna of al verlopen	Rotatie of uitfasering nodig
Brede rechten maar een smal, bekend doel	Kandidaat om te versmallen
Gedeelde credentials gebruikt door meerdere personen	Vervangen door individuele accounts of managed identity

Zodra je een inventaris hebt, geeft rangschikken op privilegeniveau en op hoe verouderd een account oogt, een praktische volgorde om doorheen te werken, in plaats van te proberen alles tegelijk op te lossen.

Toegangsregels consequent toepassen, niet alleen op mensen

Het onderliggende idee achter goede access governance is dat toegang een gedefinieerde set regels moet volgen, niet iemands geheugen van wat ooit is toegekend en waarom. Dat principe blijft waar, ook als het account non-human is.

Attribuut-gebaseerde regels werken ook voor service accounts

Net zoals menselijke toegang gestuurd kan worden door attributen als afdeling, functie en locatie, kunnen service accounts gestuurd worden door attributen als omgeving (productie versus test), applicatie en functie. Een service account getagd bij een specifieke applicatie en omgeving kan tegen die classificatie worden versmald, gereviewd en geaudit, in plaats van te vertrouwen op iemands geheugen over waar het account voor was.

Groepslidmaatschap blijft belangrijk

On-prem AD- en Entra ID-groepen blijven het mechanisme waarmee het meeste privilege wordt toegekend, of het lid nu een persoon is of een service principal. De access-automatisering van ServiceChanger past dezelfde regel-gebaseerde groepstoewijzing toe op accounts op basis van hun attributen, wat betekent dat de groepslidmaatschappen van een service account consistent blijven met het gedocumenteerde doel, in plaats van langzaam te verwateren door ad hoc toegevoegde rechten.

Access reviews horen non-human identities standaard mee te nemen

Access reviews die zijn opgebouwd rond ServiceChanger dekken de groepen en rollen waar service accounts in participeren, zodat een verouderd, overgeprivilegieerd of eigenaarloos service account naar voren komt in dezelfde terugkerende review als een verouderd menselijk account, in plaats van in een blinde vlek te blijven leven.

Waar licentie- en asset-governance overlappen

Service accounts zijn niet alleen een toegangsrisico, ze duiken ook op manieren op in licentie- en apparaatvraagstukken die makkelijk over het hoofd worden gezien.

Service accounts en licentieverbruik

Sommige service- of systeemaccounts krijgen per ongeluk een Microsoft 365-licentie toegewezen die ze niet nodig hebben, hetzij doordat ze abusievelijk zijn toegevoegd aan een licentiegroep, hetzij door een achtergebleven toewijzing die niemand heeft opgeruimd. De licentiemodule van ServiceChanger toont licentiegebruik op basis van echte Entra ID-sign-in-activiteit en contractgegevens, wat het makkelijker maakt om een gelicentieerd account te herkennen dat duidelijk geen mens is die regelmatig inlogt, en het te markeren voor review.

Houd de scope eerlijk

Niets hiervan vervangt een security review van precies welke rechten een bepaald service account heeft. Governance-tooling geeft je zichtbaarheid en consequente regelhandhaving rond groepslidmaatschap en toegang, geen vervanging voor het correct afbakenen van de onderliggende permissies zelf.

FAQ

Wat is een service account in Entra ID of Active Directory? Een service account is een non-human identity die door een applicatie, script of geautomatiseerd proces wordt gebruikt om te authenticeren en toegang te krijgen tot resources, in plaats van gekoppeld te zijn aan een individuele gebruiker die inlogt.

Waarom zijn service accounts een groter beveiligingsrisico dan gebruikersaccounts? Ze hebben vaak permanente, hoog-geprivilegieerde toegang, gebruiken zelden MFA, en worden veel minder vaak gereviewd dan menselijke accounts, omdat geen HR-gebeurtenis een controle triggert. Die combinatie maakt ze een aantrekkelijk doelwit als credentials worden gecompromitteerd.

Moeten service accounts door dezelfde access reviews als medewerkers? Ja. Ze meenemen in dezelfde terugkerende reviewcadans, in plaats van een apart of ad hoc proces, is een van de effectiefste manieren om verouderde of overgeprivilegieerde accounts op te sporen voordat ze een probleem worden.

Kan attribute-based access control worden toegepast op service accounts? Ja. Attributen als omgeving, applicatie en functie kunnen groepslidmaatschap en toegang voor service accounts sturen, op dezelfde manier als afdeling, functie en locatie dat doen voor mensen.

Service accounts hebben geen aparte governance-filosofie nodig, ze hebben dezelfde regels nodig, consequent toegepast. Voor een breder overzicht van hoe je toegang schoon en auditeerbaar houdt binnen je Microsoft-omgeving, lees onze gids over access governance en compliance. Voor meer over de mechaniek van regel-gebaseerde toegang, bekijk onze artikelen over Entra ID en access control. Wil je zien hoe ServiceChanger consequente, attribuut-gebaseerde regels toepast op elk account in je tenant, mens of niet, neem contact op om het in actie te zien.