Waarom je 'svc-'-accounts een tikkende tijdbom zijn

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

Welkom terug bij de podcast en bij onze doorlopende verdieping in enterprise-securityarchitectuur. Als jouw organisatie lijkt op de meeste, dan laat een snelle blik in je Active Directory of Microsoft Entra ID-directory een wirwar aan accounts zien die beginnen met "svc-", "app-" of "admin-bot". Deze accounts houden de boel draaiende, zorgen dat de data blijft stromen en dat de automatiseringen blijven lopen. Maar ze vormen ook het grootste blinde vlek in je moderne securitypositie. In deze blogpost gaan we verder op ons laatste gesprek en leggen we uit waarom traditionele serviceaccounts je Zero Trust-architectuur volledig ondermijnen en waarom migreren naar Microsoft Entra Workload Identities de enige weg vooruit is.

Voor een volledige audiobespreking van dit onderwerp kun je onze bijbehorende podcastaflevering beluisteren: Replace Service Accounts with Entra Workload Identities. Laten we nu duiken in de mechanismen van niet-menselijk risico en hoe je dat voorgoed elimineert.

Samengevat

Serviceaccounts met statische secrets en brede rechten vormen je grootste identiteitslek. Workload Identities (in Microsoft Entra ID) geven elke niet-menselijke actor een beheerde identiteit met least privilege, levenscyclus, CA-beleid, rotatie en volledige audittrails, zonder dat je je automatiseringen hoeft te breken.

Waarom serviceaccounts falen (en Zero Trust ondermijnen)

Het traditionele serviceaccountmodel is gebouwd voor een tijdperk van netwerkperimeters die niet meer bestaan. Toen vertrouwen werd bepaald door de vraag of een apparaat op het bedrijfsnetwerk zat, voelde een statisch wachtwoord in een configuratiebestand acceptabel aan. Vandaag is dat ontwerpprincipe een risico.

Statische secrets & geen MFA -> makkelijk te stelen, lastig veilig te roteren
Standaard te veel rechten -> "zorg dat het werkt"-machtigingen worden permanent
Geen levenscyclus -> verweesde of vergeten accounts overleven migraties en reorganisaties
Beperkte auditbaarheid -> "wie gebruikte dit en waarom?" = gokwerk en screenshots
Uitzonderingscultuur -> CA/MFA-uitzonderingen voor bots vergroten stilletjes je aanvalsoppervlak

Managed Identities: een goede stap, maar wel gebonden aan Azure

Wanneer organisaties beseffen dat statische serviceaccounts gevaarlijk zijn, is hun eerste instinct vaak een uitstap naar Azure Managed Identities. Managed Identities zijn een enorme vooruitgang omdat ze secrets volledig elimineren voor Azure-gehoste resources, maar ze hebben duidelijke grenzen.

✅ Secretloze toegang voor Azure-native resources (Functions, VM's, Logic Apps)
❌ Hiaten bij hybride/externe doelen, zwakke eigenaarschapsregistratie, beperkte governance-overzichten
❌ CA- en entitlementdekking is niet uniform over niet-Azure-oppervlakken

Workload Identities: wat je er echt voor terugkrijgt

Hier komen Microsoft Entra Workload Identities in beeld. In plaats van niet-menselijke actoren als tweederangs burgers te behandelen of je vast te zetten aan beperkingen die alleen binnen Azure gelden, verheffen Workload Identities applicaties, scripts en geautomatiseerde services tot volwaardige securityprincipals.

Volwaardige niet-menselijke identiteiten (apps, scripts, connectors, RPA, integraties)
Beperkte machtigingen (Graph-/resourcerollen, app-only authenticatie) met least privilege
Levenscyclus (eigenaar, reviewfrequentie, buitengebruikstellingsproces) gekoppeld aan het bedrijfsproces
Conditional Access voor workloads (risico- en contextbewuste poorten, sessiebeheer waar ondersteund)
Credential-hygiëne (kortlevende secrets, certificaten, sleutelrotatiebeleid)
Geïntegreerd zicht (aanmeldingen, tokens, resourcetoegang, wijzigingshistorie) -> klaar voor audits

Vergelijkingsmatrix (in een oogopslag)

Mogelijkheid	Serviceaccount	Managed Identity	Workload Identity
Secrets	Statische wachtwoorden	Secretloos (Azure)	Secretloos/kortlevend + rotatie
Bereik	Breed / gebruikersachtig	Azure-gericht	Elke workload (apps/scripts/connectors)
CA / risico	Zelden toegepast	Beperkt	Beleidsgestuurd waar ondersteund
Levenscyclus	Ad hoc	Basis	Eigenaar + reviews + buitengebruikstelling
Audit	Schaars	Azure-logs	Gecentraliseerd spoor van aanmeldingen en entitlements

Architectuurpatronen (veelvoorkomende toepassingen)

Het implementeren van workload-identiteiten vraagt om een correcte koppeling aan je architectuurpatronen. Hieronder zie je hoe ze van toepassing zijn op de meest voorkomende enterprise-workloads:

Power Platform-connectors / cloudflows -> Ken per integratie een workload-identiteit toe; verleen alleen de noodzakelijke Graph- en Dataverse-scopes.
Line-of-business-apps (web-API's, daemons) -> App-registratie + certificaat; gebruik app-rollen en app-only Graph; dwing waar van toepassing Voorwaardelijke toegang af.
Automatiseringsscripts (Azure Automation, GitHub Actions, DevOps) -> Gebruik federated credentials (OIDC), zonder opgeslagen geheimen.
Cross-tenant- / B2B-taken -> Een eigen workload-identiteit per tenantgrens; isoleer rechten en logging.

Migratiehandboek (90 dagen, zonder gedoe)

Honderden verouderde serviceaccounts aanpakken kan overweldigend aanvoelen. Daarom heb je een gestructureerd migratiehandboek nodig dat 90 dagen beslaat en zich richt op het verminderen van risico's.

Fase 1 — Ontdekken & triëren (weken 0–3)

Inventariseer niet-menselijke aanmeldingen en objecten: svc-*, app-*, gedeelde postvakken, app-registraties, geheimen die binnen 90 dagen verlopen.
Koppel elk object aan een eigenaar, een zakelijk doel, doelen, machtigingen en een afhankelijkheid van noodaccounts.
Risicoranglijst: statische wachtwoorden, globale rollen, geen eigenaar, geen recente rotatie.

Fase 2 — Converteer eerst de hoogrisico-objecten (weken 4–8)

Richt per integratie een workload-identiteit in (hergebruik niet).
Vervang wachtwoordauthenticatie door certificaten of federated credentials; stel rotatie in.
Ga over op app-only-machtigingen; verwijder gedelegeerde gebruikersmachtigingen waar ze niet nodig zijn.
Pas Voorwaardelijke toegang-beleid toe op aanmeldingen van workloads (waar ondersteund).
Implementeer toegangsreviews (per kwartaal) + eigenaarschap in CMDB/ITSM.

Fase 3 — Buiten gebruik stellen & beheersen (weken 9–12)

Schakel oude serviceaccounts uit; monitor 14 dagen; verwijder ze daarna.
Dwing aanmaakstandaarden af: naamgeving, eigenaar, gegevensclassificatie, reviewfrequentie.
Voeg waarschuwingen toe: afwijkende aanmeldingen, inactieve identiteiten van >30/60/90 dagen, verlopende geheimen.
Verwerk identiteitscontroles in CI/CD (policy-as-code).

Voorwaardelijke toegang en machtigingen (praktische vangrails)

Een van de krachtigste functies van moderne identiteitsplatformen is de mogelijkheid om vangrails specifiek af te stemmen op niet-menselijke actoren. Door menselijke en workload-beleidsregels te scheiden, voorkom je dat bots onmogelijke-reisalarmen veroorzaken, terwijl kwaadaardig verkeer nog steeds wordt geblokkeerd.

Afzonderlijk beleid voor menselijke versus workload-identiteiten; blokkeer interactieve aanmelding voor workloads.
Benoemde locaties / netwerkbeperkingen voor app-only-toegang waar mogelijk.
Tijdsgebonden toekenningen (PIM voor app-rollen waar beschikbaar; geplande toegangsreviews).
Scopes: geef de voorkeur aan app-rollen / resourcespecifieke rollen boven rechten op directoryniveau.

Logging en audit (wat je aan de auditor laat zien)

Wanneer compliance-officers en auditors aanklopppen, accepteren ze geen spreadsheets of mondelinge garanties meer over wie toegang heeft tot backend-scripts. Je moet governance direct kunnen aantonen met gecentraliseerde logging.

Eigenaar van de app/workload, doel, gevoeligheid van gegevens
Aanmeldingslogs (aanmeldingen van service-principals), tokendoelgroep, IP-adres, clientapp
Roltoewijzingen (wie heeft goedgekeurd, wanneer gecertificeerd)
Geschiedenis van referenties (type, laatste rotatie, vervaldatum)
Levenscyclus: aangemaakt/gewijzigd/uitgeschakeld/verwijderd met de wijzigende actor

KPI-dashboard (bewijs de verbetering)

Om het blijvende draagvlak van het management te behouden, volg en rapporteer je op kerncijfers die de vermindering van je niet-menselijke risico's in de tijd laten zien.

% niet-menselijke identiteiten met eigenaar + reviewfrequentie (doel ≥ 95%)
Verweesde serviceaccounts (doel -> 0)
Geheimen ouder dan 90 dagen (doel -> 0; geef de voorkeur aan certificaat/federated)
Omvang van app-only-rollen (aantal “Directory.ReadWrite.All” -> dalende trend)
Auditbevindingen voor niet-menselijke toegang (kwartaal op kwartaal ↓)

Antipatronen die je moet elimineren

Terwijl je je omgeving opschoont, zorg je dat teams niet terugvallen in oude gewoonten. Breng deze antipatronen meteen tot staan:

Eén generiek serviceaccount hergebruiken voor veel systemen
Wachtwoorden insluiten in scripts, web.config of Key Vault zonder rotatiebeleid
Algemeen beheerder / Eigenaar toekennen ‘voor de zekerheid’, zodat taken blijven draaien
‘Tijdelijke’ uitzonderingen op Conditional Access die nooit verlopen

Snelle winst (deze week)

Je hoeft niet te wachten op de start van een groot project om je beveiligingshouding te verbeteren. Dit zijn vier snelle winstpunten die je deze week kunt uitvoeren:

Geef elke niet-menselijke identiteit de tags Owner, System, Data Class.
Zet één risicovolle taak om naar federated credentials (GitHub OIDC -> Entra).
Vervang een gedeeld serviceaccount in Power Automate door een workload identity.
Maak een rapport van service principals met verlopende of verlopen geheimen en plan waarschuwingen in.

Veelgestelde vragen (snelle antwoorden)

Breken workload identities oudere on-premises taken?
Nee, overbrug met app-only authenticatie, certificaten of brokerservices en faseer wachtwoorden geleidelijk uit.

Kan ik Conditional Access afdwingen op aanmeldingen van niet-menselijke identiteiten?
Ja, voor ondersteunde scenario's (aanmeldingen van service principals). Gebruik waar van toepassing netwerk-, locatie- en apparaatsignalen en blokkeer interactieve aanmeldingen.

Hoe voorkom ik wildgroei?
Eén workload identity per integratie (niet per team). Dwing naamgeving, eigenaar en beoordelingen af bij het aanmaken en automatiseer het opruimen van inactieve identiteiten.

En Power Platform?
Gebruik Service Principals / Workload Identities voor connectors en Dataverse en stop met het gebruik van gedeelde gebruikersaccounts.

Conclusie

Met wachtwoordrotatie alleen los je het risico van serviceaccounts niet op. Entra Workload Identities brengen toegang van niet-menselijke identiteiten onder hetzelfde Zero Trust-, levenscyclus- en auditmodel dat je al voor personen eist, zonder storingen of heldendaden. Begin met je riskantste ‘svc-’-accounts, zet ze om naar beheerde workload identities en maak uitzonderingen weer echt uitzonderingen.

Als je dit artikel waardevol vond, bekijk dan zeker de volledige discussie in onze podcastaflevering, Replace Service Accounts with Entra Workload Identities. Abonneer je op de show voor meer diepgaande verhalen over enterprise-beveiligingsstrategieën voor Microsoft 365 en Azure!