Het verborgen gevaar van shadow accounts in Microsoft 365-automatisering

By Mirko Peters · 2026-08-26

Welkom terug bij weer een diepgaande duik in de architectuur, beveiliging en beheerpraktijk van het Microsoft 365-ecosysteem. Als je cloudinfrastructuur beheert, …

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

Welkom terug bij weer een diepgaande duik in de architectuur, beveiliging en beheerpraktijk van het Microsoft 365-ecosysteem. Als je cloudinfrastructuur beheert, workflows bouwt of verantwoordelijk bent voor enterprise-IT, moeten we het hebben over een tikkende tijdbom die op zichtbare plaats verstopt zit. In onze recente aflevering, Service Principal Security: Stop Using Personal Accounts, hebben we een praktijk blootgelegd die zo gebruikelijk is dat vrijwel elke organisatie eraan schuldig is: geautomatiseerde processen die cruciaal zijn voor de bedrijfsvoering rechtstreeks koppelen aan persoonlijke gebruikersaccounts. Het begint als een onschuldige kortere weg. Een engineer moet snel een Power Automate-flow opzetten, een Logic App koppelen, gegevens via een API synchroniseren of een Power BI-gegevensvernieuwing instellen. Om tijd te besparen, authenticeert hij de verbinding met zijn eigen beheerdersaccount. Het werkt meteen, het project gaat zonder haperen live en iedereen gaat door. Maar wat gebeurt er als die engineer van team wisselt, zijn wachtwoord reset, een nieuw Conditional Access-beleid wordt ingesteld of hij het bedrijf verlaat? De automatisering breekt, productie valt stil en de organisatie ontdekt dat er kernprocessen draaien op geleende identiteit. Dit blogbericht werkt die gedachten verder uit en laat zien waarom shadow accounts de veerkracht van je infrastructuur ondermijnen en hoe je je aanpak kunt moderniseren voordat platformwijzigingen je dwingen om te handelen.

Als we over cloudarchitectuur praten, hebben we het vaak over redundantie, failoverclusters en disaster recovery. Toch wordt identiteitsveerkracht door veel organisaties volledig over het hoofd gezien. Wanneer een organisatie workflows bouwt bovenop menselijke inloggegevens, ontstaat een kwetsbaar web van afhankelijkheden dat onvermijdelijk leidt tot onverwachte storingen. Laten we de kern van deze problematiek eens uitpakken en bekijken hoe je overstapt naar een echt enterprise-waardig identiteitsmodel.

De digitale werkomgeving evolueert sneller dan ooit, en het standaardiseren van de manier waarop niet-menselijke workloads zich authenticeren, is niet langer een optionele best practice. Het is een verplichte stap om in moderne cloudomgevingen te kunnen overleven.

De shadow account-val in Microsoft 365-automatisering

De meeste identiteitsproblemen in enterprise-automatisering beginnen bij het streven naar snelheid. Wanneer ontwikkelaars of beheerders snelle integraties bouwen binnen Microsoft 365, voelt het gebruik van een bestaand gebruikersaccount heel soepel aan. De machtigingen zijn al ingericht, de authenticatieprompts zijn vertrouwd en de uitrol kost minuten in plaats van uren. Toch creëert dit gemak het shadow account-model. Persoonlijke accounts fungeren als verborgen infrastructuuridentiteiten en brengen menselijke kwetsbaarheden in geautomatiseerde systemen.

Kijk eens naar het moderne beveiligingslandschap. Organisaties voeren strikte Multi-Factor Authentication (MFA)-beleidsregels in, risicogebaseerde aanmeldblokkades en regelmatige wachtwoordwisselingen om menselijke gebruikers te beschermen. Deze beveiligingsmaatregelen zijn voor medewerkers volkomen noodzakelijk, maar voor headless automatisering zijn ze catastrofaal. Wanneer een script of een cloudflow op een persoonlijk account vertrouwt, stopt elke routinematige beveiligingsinterventie, zoals een MFA-prompt, een verplichte wachtwoordreset of een verdachte aanmeldcontrole, de automatisering direct. De workflow faalt niet door een bug in de code; hij faalt omdat een mens zijn wachtwoord moest wijzigen.

Bovendien wordt offboarding een administratieve nachtmerrie. Wanneer een medewerker de organisatie verlaat, wordt zijn account uiteindelijk uitgeschakeld of verwijderd. Als dat account stiekem kritieke SharePoint-integraties, geautomatiseerde rapportageprocessen of workflows voor klantnotificaties aandreef, dan vallen die systemen uit. IT-teams ontdekken deze kapotte afhankelijkheden vaak pas nadat de bedrijfsvoering al is verstoord. Menselijke accounts als infrastructuuridentiteiten behandelen is een architecturaal anti-patroon dat een onacceptabel operationeel risico introduceert.

Identiteitsrot en de verborgen kosten van menselijke afhankelijkheden

Identiteitsrot is een stille killer in enterprise-IT. Het ontstaat wanneer de aannames achter een authenticatiemechanisme geleidelijk aan verslechteren, tot het systeem onverwacht faalt. Wanneer workflows afhankelijk zijn van menselijke accounts, uit identiteitsrot zich op verschillende destructieve manieren. Rollen veranderen, afdelingen worden samengevoegd en machtigingen lopen uit de pas. Een account dat ooit de juiste toegang had tot een bepaalde site of database, kan ineens andere rechten hebben door een compliance-audit of een functiewisseling.

Wanneer een geautomatiseerde workflow afhankelijk is van die specifieke gebruikerscontext, breekt elke aanpassing van de toegangsrechten van die gebruiker de automatiseringsketen. Dit creëert een cultuur van angst, waarin IT-beheerders er niet aan willen beginnen om gebruikersaccounts aan te passen, beveiligingsprofielen bij te werken of oud-medewerkers netjes uit te schakelen, omdat ze vermoeden dat er iets onzichtbaars kapotgaat. Serviceaccounts die als onbeveiligde spookgebruikers functioneren, zijn een ander symptoom van deze rot. Organisaties maken vaak generieke gebruikersaccounts aan, zoals scriptrunner@company.com, geven ze permanente wachtwoorden, omzeilen MFA en gebruiken ze in tientallen scripts. Deze spookaccounts hebben zelden goede auditing, ontbreken moderne beveiligingsmaatregelen en vormen enorme compliance-overtredingen die bij een audit vroeg of laat aan het licht komen.

Door te leunen op menselijke afhankelijkheden, offeren organisaties zichtbaarheid, controleerbaarheid en beheersbaarheid op. Moderne cloudarchitectuur vraagt dat elke workload op eigen architecturale merites staat, volledig onafhankelijk van de mensen die hem oorspronkelijk hebben gebouwd of uitgerold.

Waarom Microsoft de overstap van op gebruikers gebaseerde workflows afdwingt

Als de operationele risico's van shadow accounts nog niet genoeg waren om organisaties te overtuigen van verandering, dan doet de platformroadmap dat zeker wel. Microsoft sluit actief de deur op verouderde authenticatiepatronen en op gebruikers gebaseerde automatisering. Op weg naar het identiteitsmodel van 2026 komt er een einde aan de tijd van automatisering zonder service principal. Verouderde SharePoint 2013-workflows worden uitgefaseerd, Azure AD Graph wordt volledig afgeschaft en app-only moderne authenticatie wordt een harde eis binnen het hele ecosysteem.

De boodschap van Microsoft op platformniveau is ondubbelzinnig: automatisering moet een eigen identiteit hebben. Jarenlang stelde het oude architectuurmodel een fundamenteel verkeerde vraag: "Welke persoon voert deze automatisering uit?" Moderne cloudgovernance vervangt die vraag door een veel veiligere: "Welke specifieke workload is geautoriseerd om deze actie uit te voeren?" Deze verschuiving verandert alles aan de manier waarop we cloudoplossingen ontwerpen, uitrollen en beheren.

Wie zich niet aanpast aan deze verschuiving, vecht tegen de natuurlijke richting van het platform. Organisaties die blijven vasthouden aan op gebruikers gebaseerde automatisering, lopen het risico op plotselinge, cascaderende storingen zodra Microsoft verouderde API's uitfaseert en strikte moderne authenticatiestandaarden afdwingt. De overstap naar workload-identiteiten is dus niet alleen een beveiligingsupgrade; het is een afstemming op de toekomstige richting van enterprise-software.

Identiteit behandelen als infrastructuur met service principals

Om shadow accounts uit te bannen, moeten organisaties een nieuwe mindset aannemen: identiteit is infrastructuur. Net zoals we virtuele machines, opslagaccounts en netwerkcomponenten behandelen als afzonderlijke infrastructuurelementen, moeten we application- en workload-identiteiten met exact dezelfde zorgvuldigheid behandelen. Dat brengt ons bij service principals.

Een service principal functioneert als een niet-interactieve runtime-identiteit die een workload of applicatie vertegenwoordigt in plaats van een menselijke medewerker. Door het Decoupling Principle toe te passen in enterprise-beveiliging, zorgen organisaties ervoor dat applicaties onafhankelijke identiteitsgrenzen hebben. Als een medewerker het bedrijf verlaat, zijn wachtwoord reset of zijn MFA-apparaat bijwerkt, blijft de service principal volledig ongewijzigd, omdat de levenscyclus volledig los staat van menselijke activiteit.

Identiteit behandelen als deployment-artefact betekent dat wanneer je een Logic App, een Function App of een enterprise-integratie uitrolt, de bijbehorende service principal wordt aangemaakt, van machtigingen wordt voorzien en als code wordt beheerd. Deze infrastructuurgerichte aanpak verbetert de veerkracht aanzienlijk, zorgt voor schone auditsporen en elimineert de kwetsbare menselijke afhankelijkheden die stille storingen veroorzaken.

Managed identities en de kracht van zero-secret authenticatie

Hoewel service principals het probleem van menselijke afhankelijkheid oplossen, brachten ze historisch gezien een nieuwe uitdaging met zich mee: het beheren van geheimen. Clientgeheimen, certificaten of wachtwoorden opslaan in configuratiebestanden, omgevingsvariabelen of key vaults maakte organisaties nog steeds kwetsbaar voor secret sprawl en lekkage van referenties. Gelukkig is de cloudarchitectuur voorbij statische referenties gegaan door de introductie van beheerde identiteiten (Managed Identities).

Managed Identities vormen het toppunt van cloudnative identiteitsarchitectuur, omdat Azure de volledige levenscyclus van de referenties automatisch beheert. Het platform regelt het genereren, roteren, opslaan, verlopen en afdwingen van vertrouwen achter de schermen. Ontwikkelaars en beheerders hoeven de onderliggende referenties nooit te verwerken, te bekijken of te roteren.

Zo bereik je zero-secret-authenticatie. Door statische clientgeheimen en wachtwoorden volledig te elimineren, verwijderen organisaties een van de meest voorkomende aanvalsvectoren die kwaadwillenden misbruiken. Wanneer de identiteit rechtstreeks gekoppeld is aan de levenscyclus van de resource via Azure, wordt vertrouwen op platformniveau native vastgesteld. Workloads authenticeren zich veilig met kortlevende tokens die door het platform worden uitgegeven, wat het risico op datalekken en de operationele last aanzienlijk verkleint.

Statische geheimen elimineren met federated credentials

Hoewel Managed Identities ideaal zijn voor workloads die native binnen Azure draaien, vertrouwen veel enterprise-automatiseringspijplijnen op externe CI/CD-systemen, multicloudomgevingen of ontwikkelaarstools zoals GitHub Actions. In deze scenario's grijpen traditionele workflows vaak naar het genereren van langlevende clientgeheimen die worden opgeslagen in externe repositories, en dat levert enorme beveiligingsrisico's op.

Hier komen federated credentials en OpenID Connect (OIDC) in beeld. Gefedereerde identiteit stelt externe workloads in staat een tijdelijke, op vertrouwen gebaseerde relatie op te bouwen met Microsoft Entra ID, zonder dat er opgeslagen referenties nodig zijn. In plaats van een permanent wachtwoord te gebruiken, vraagt de externe pijplijn rechtstreeks bij de eigen provider een token op, presenteert dat cryptografisch ondertekende token aan Entra ID en ontvangt daarvoor een kortlevend toegangstoken terug.

Dit model met kortstondige identiteiten zorgt ervoor dat er nergens op schijf of in configuratie-instellingen een herbruikbare referentie bestaat. Als een externe repository wordt gecompromitteerd, vinden aanvallers geen statische geheimen om te oogsten. Federated credentials overbruggen de kloof tussen multicloudactiviteiten en enterprise-beveiliging, en bewijzen dat snelle automatisering en robuuste bescherming prima samen kunnen gaan.

Permission creep aanpakken in moderne cloudarchitectuur

Zodra organisaties succesvol overstappen naar service principals, Managed Identities en federated credentials, ontstaat een nieuw architectuurrisico: permission creep. Een veerkrachtige, goed werkende identiteit met te veel machtigingen wordt een gevaarlijk wapen als ze wordt gecompromitteerd. Al te vaak kennen engineers te brede Graph API-scopes toe, zoals `Application.ReadWrite.All` of `Directory.ReadWrite.All`, gewoon om deploymentwrijving weg te nemen en tijdens de initiële setup geen permissiefouten te hoeven oplossen.

Het resultaat is een landschap vol overbevoegde service principals die ongemerkt door de tenant opereren. Aanvallers scannen actief op machine-identiteiten, omdat het compromitteren van een slecht beveiligde service principal met hoge rechten persistente, heimelijke toegang tot de hele omgeving geeft. Machinetokens bewegen vaak sneller en wekken minder argwaan dan menselijke aanmeldingen, waardoor ze aantrekkelijke doelwitten zijn voor lateral movement en data-exfiltratie.

Om deze crisis te beperken, is strikte naleving van het principe van least privilege vereist. Service principals mogen alleen de specifieke, granulaire applicatiemachtigingen krijgen die nodig zijn om hun taken uit te voeren. Ze moeten regelmatig worden gecontroleerd, gemonitord op afwijkend gedrag en met precies dezelfde voorzichtigheid worden behandeld als root-toegang tot fysieke productie-infrastructuur. Door een goede workload-identiteitsarchitectuur te combineren met gedisciplineerd machtigingenbeheer, kunnen organisaties automatisering bouwen die zowel zeer veerkrachtig als uitzonderlijk veilig is.

Conclusie

Het tijdperk waarin enterprise-automatisering wordt opgebouwd op persoonlijke gebruikersaccounts loopt officieel ten einde. Zoals we in dit artikel hebben laten zien, levert het koppelen van kritieke Microsoft 365-workflows aan menselijke credentials wankele infrastructuur op, ernstige beveiligingslekken en de onvermijdelijke ellende van identity rot. Tussen Microsofts agressieve uitfasering van verouderde authenticatiemethoden en de altijd aanwezige dreiging van storingen veroorzaakt door uitgediende medewerkers, is de huidige situatie simpelweg niet langer houdbaar. Door te kiezen voor service principals, managed identities voor authenticatie zonder geheimen, federated credentials en een strikt beheer van machtigingen, maken organisaties hun automatiseringspijplijnen veilig, veerkrachtig en klaar voor enterprise-gebruik.

Wil je dieper ingaan op deze concepten en praktijkvoorbeelden horen over het beveiligen van je automatiseringsomgevingen? Luister dan zeker naar onze speciale aflevering over Service Principal Security: Stop Using Personal Accounts. Die zit vol praktische inzichten waarmee je je huidige architectuur kunt doorlichten, schaduwaccounts kunt elimineren en je Microsoft 365-tenant kunt voorbereiden op de naderende identiteitscrisis.