Jordy HerberCloudaanvallen gaan steeds minder over servers en steeds meer over rechten. Een service principal met Directory.ReadWrite.All, een managed identity met Contributor op een subscription, een pipeline met secrets of een app registration zonder eigenaar kan gevaarlijker zijn dan een kwetsbare VM.
Ik zie dit vaak bij klanten: human identities worden redelijk goed beheerd, maar workload identities zijn historisch gegroeid. Niemand weet precies waarom een app bepaalde permissions heeft. Secrets verlopen niet. Owners zijn vertrokken. En de app draait nog steeds in productie.
Deze blog zet workload identity abuse praktisch neer voor Microsoft-omgevingen. We kijken naar Entra ID, Azure RBAC, Microsoft Graph permissions, Defender for Cloud CSPM/CIEM, Sentinel en een PowerShell-inventarisatie die je direct kunt gebruiken.
| Praktijkopmerking: Ik zie dit vaak bij klanten: de tooling staat deels aan, maar de koppeling tussen identity, cloud, data en SOC-proces ontbreekt. Juist daar vallen moderne aanvallen doorheen. |
Waarom dit onderwerp nu speelt
Het MDDR 2025 benoemt cloud threat trends en laat een stijging zien in disruptive cloud campaigns en credential/data-exfiltrationpogingen. De rode draad is duidelijk: cloud is API-first en identity-first. Als de identiteit te veel mag, is de workload te krachtig.
Workload identities zijn non-human accounts: app registrations, service principals, managed identities, automation accounts en federated identities vanuit CI/CD. Ze gebruiken geen MFA, draaien vaak 24/7 en hebben meestal geen mens die dagelijks inlogt. Daardoor valt misbruik minder snel op.
Mijn advies is om workload identities te behandelen als privileged accounts. Niet als technisch detail van developers. Dit klinkt klein, maar heeft impact op je SOC proces: incidenten rond app permissions moeten dezelfde urgentie krijgen als admin role changes.
Wat je moet weten: API permissions zijn adminrechten
In Microsoft Graph kunnen application permissions tenantbreed werken. Permissions zoals Files.Read.All, Sites.FullControl.All, Mail.ReadWrite, Directory.ReadWrite.All en RoleManagement.ReadWrite.Directory zijn geen kleine vinkjes. Ze bepalen of een workload data kan lezen, mailboxen kan benaderen of directoryobjecten kan aanpassen.
Een gestolen client secret is vaak genoeg. Geen MFA. Geen interactieve sign-in. Geen gebruiker die een verdachte prompt ziet. Bij federated credentials, bijvoorbeeld vanuit GitHub of andere CI/CD-platformen, kan een te brede trust relationship hetzelfde effect hebben.
De klassieke vraag ‘welke gebruikers zijn admin?’ moet dus worden uitgebreid naar ‘welke apps kunnen als admin handelen?’
Architectuur: CSPM, CIEM en Sentinel
Defender for Cloud CSPM geeft zicht op posture, attack paths en cloudrisico’s. CIEM helpt bij permissions management: wie of wat heeft te veel rechten, welke rechten worden niet gebruikt, en waar ontstaat privilege escalation? Dit is licentie- en configuratieafhankelijk en moet bewust worden ingeschakeld.
Sentinel blijft nodig voor detectie op wijzigingen. Denk aan nieuwe service principal credentials, nieuwe owners, nieuwe app role assignments en plotselinge Graph API-activiteit. Zeker in grotere tenants wil je die events niet handmatig doorzoeken.
In de praktijk begint dit met inventarisatie. Exporteer app permissions, wijs eigenaars toe, classificeer apps op data-impact en verwijder ongebruikte secrets. Daarna pas ga je finetunen.
Praktijkvoorbeeld: service principal met te veel rechten
Een integratie is ooit gebouwd om rapportages uit SharePoint en Entra ID te halen. Tijdens implementatie kreeg de app voor het gemak Files.Read.All, Sites.FullControl.All en Directory.ReadWrite.All. De ontwikkelaar is vertrokken, de secret verloopt pas over twee jaar en niemand weet precies waarom die rechten nodig zijn.
Een aanvaller die de secret vindt in een pipeline, logbestand of oud script heeft geen gebruiker nodig. Er is geen MFA-prompt en geen servicedeskactie. De app kan direct Graph API aanroepen binnen de toegekende permissions. Afhankelijk van de rechten kan dit leiden tot datatoegang, directorywijzigingen of persistence.
De eerste stap is inventarisatie. Welke apps hebben application permissions? Welke hebben owners? Welke credentials zijn oud? Welke apps hebben geen sign-in activiteit maar wel hoge rechten? Welke apps zijn multi-tenant? Welke apps hebben redirect URLs die niet meer bestaan?
Daarna komt classificatie. Niet elke app met permissions is fout. Sommige integraties zijn bedrijfskritisch. Maar elke high-risk app moet een eigenaar, doel, dataclassificatie, credential policy en reviewdatum hebben. Zonder die metadata kun je security niet sturen.
Sentinel-detecties helpen vooral bij verandering. Nieuwe credential, nieuwe owner, nieuwe permission of nieuwe app role assignment is vaak belangrijker dan de bestaande toestand. CIEM en CSPM helpen bij posture; Sentinel helpt bij drift.
Niveau 400: managed identities, federated credentials en attack paths
Managed identities zijn veiliger dan secrets omdat je geen statisch geheim hoeft te beheren, maar ze zijn niet automatisch least privilege. Een managed identity met Contributor op een resource group kan nog steeds veel schade doen. Controleer Azure RBAC en resource scope.
Federated credentials voor CI/CD zijn krachtig, maar de trust moet smal zijn. Beperk issuer, subject en audience. Een te brede branch- of repo-scope kan betekenen dat een ongewenste pipeline tokenrechten krijgt. Dit is een cloud security- én DevOps-governancepunt.
AzureActivity toont RBAC-wijzigingen, maar Entra AuditLogs tonen app- en service principal wijzigingen. Je hebt beide nodig. Voor Graph permissions kijk je naar app role assignments. Voor Azure control plane kijk je naar role assignments. Combineer die werelden in je onderzoek.
Defender for Cloud attack path analysis kan helpen om te zien hoe een identiteit via rechten bij kritieke resources komt. Dat is nuttiger dan losse aanbevelingen. Een over-permissive identity bij een publieke storage account heeft meer prioriteit dan dezelfde identity zonder dataroute.
Gebruik naming conventions, maar vertrouw er niet blind op. Een app met ‘test’ in de naam kan productierechten hebben. Een app met ‘prod’ kan ongebruikt zijn. Baseer beslissingen op permissions, usage, owners en data-impact.
Response bij gecompromitteerde workload identity is anders dan bij een gebruiker. Je roteert secrets/certificaten, verwijdert federated credentials waar nodig, trekt app permissions in, controleert logs op Graph/API calls en valideert downstream data access. Alleen de app uitschakelen kan productie breken; werk daarom met eigenaar en impactanalyse.
Implementatieplan in drie sprints
Sprint 1 is inventarisatie. Exporteer app registrations, service principals, managed identities, owners, credentials en permissions. Label apps als productie, test, onbekend of uit te faseren. Alles zonder owner krijgt een remediationticket. Zonder eigenaar kun je geen risico accepteren.
Sprint 2 is privilege reductie. Begin met de hoogste Graph application permissions en Azure RBAC Owner/Contributor-rechten. Vraag per app waarom de permission nodig is, welke data geraakt wordt en welke alternatieve least-privilege permission mogelijk is. Verwijder niet blind rechten uit productie, maar plan gecontroleerde changes met rollback.
Sprint 3 is drift detectie. Maak Sentinel-regels voor nieuwe credentials, owner changes, app role assignments en RBAC-wijzigingen. Zet CIEM-aanbevelingen om naar backlog-items met prioriteit op basis van attack path en data-impact. Zo voorkom je dat posture management een lijst wordt waar niemand meer naar kijkt.
Praktische keuzes voor productie
Voor productie moet je workload identity governance koppelen aan change management. Nieuwe application permissions horen niet via losse adminacties te ontstaan. Gebruik een aanvraagproces waarin doel, scope, data-impact, eigenaar, omgeving en einddatum worden vastgelegd. Dat klinkt bureaucratisch, maar voorkomt dat tijdelijke rechten permanent worden.
Maak onderscheid tussen break-glass, productie-integraties en experimentele apps. Break-glass moet streng bewaakt worden, productie-integraties moeten stabiel maar reviewed zijn, en experimentele apps horen korte levensduur en beperkte rechten te hebben. Eén generieke policy voor alle apps werkt zelden.
Gebruik logging voor bewijs. Als een team zegt dat een app Sites.FullControl.All nodig heeft, vraag dan welke sites daadwerkelijk worden benaderd. Combineer sign-in activiteit, Graph audit en businesscontext. Least privilege wordt veel makkelijker wanneer je werkelijk gebruik kunt aantonen.
Extra SOC-tuning voor workload identities
Voor workload identities is ‘geen interactief gedrag’ normaal. Je moet dus niet zoeken naar menselijke signalen, maar naar verandering en afwijkend gebruik. Nieuwe credentials, nieuw IP-patroon, nieuwe resource scope of plotselinge Graph-activiteit zijn goede startpunten.
Maak een lijst van businesskritische apps met verwachte API’s en resources. Als een app die normaal alleen rapportages uit één site haalt ineens mailboxdata benadert, wil je dat zien. Dat vraagt om baselining per app, niet alleen algemene tenantregels.
Technisch voorbeeld
De voorbeelden hieronder zijn bedoeld als startpunt. Test altijd met je eigen logging, tijdzones, naming conventions en false-positive patroon. Maak van een hunt-query pas een analytics rule als je eigenaar, severity, response en uitzonderingen hebt vastgelegd.
KQL
// Sentinel: service principal credential toegevoegd of high privilege app role toegekend
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in (“Add service principal credentials”, “Add app role assignment to service principal”, “Add owner to application”, “Add owner to service principal”)
| extend Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))
| extend Target = tostring(TargetResources[0].displayName)
| extend Props = tostring(TargetResources[0].modifiedProperties)
| extend RiskyPermission = Props has_any (“Directory.ReadWrite.All”,”Application.ReadWrite.All”,”RoleManagement.ReadWrite.Directory”,”Sites.FullControl.All”,”Mail.ReadWrite”,”Files.Read.All”)
| project TimeGenerated, OperationName, Actor, Target, RiskyPermission, Props, Result
| order by TimeGenerated desc
PowerShell
# Microsoft Graph PowerShell: app registrations met potentieel risicovolle application permissions
Connect-MgGraph -Scopes “Application.Read.All”,”Directory.Read.All”,”AppRoleAssignment.Read.All”
$spns = Get-MgServicePrincipal -All
$results = foreach ($spn in $spns) {
$assignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $spn.Id -All -ErrorAction SilentlyContinue
foreach ($a in $assignments) {
[pscustomobject]@{
AppDisplayName = $spn.DisplayName
AppId = $spn.AppId
Resource = $a.ResourceDisplayName
AppRoleId = $a.AppRoleId
CreatedDate = $spn.CreatedDateTime
Owners = ($spn | Select-Object -ExpandProperty Owners -ErrorAction SilentlyContinue)
}
}
}
$results | Export-Csv “.\workload-identity-permissions.csv” -NoTypeInformation
Mapping: workload identity risico naar controle
| Risico | Signaal | Controle |
| Geen eigenaar | Application zonder owner | Owner verplicht + lifecycle review |
| Te brede Graph permissions | High-privilege app role assignments | Admin consent + least privilege |
| Secrets verlopen niet | Long-lived credentials | Certificate/secret rotation policy |
| Pipeline trust te breed | Federated credential zonder scope | OIDC subject/audience beperken |
| RBAC privilege drift | Contributor/Owner op subscription | CIEM + PIM voor Azure resources |
Veelgemaakte fouten
- Alleen human admins reviewen.
- Application permissions behandelen als developerkeuze zonder security review.
- Secrets roteren zonder te controleren waar ze gebruikt worden.
- Geen app-owner of business-owner vastleggen.
- CIEM aanzetten maar aanbevelingen niet koppelen aan changeproces.
Advies vanuit de praktijk
Mijn advies is om dit onderwerp niet als los project te behandelen. Koppel het aan je SOC-proces, je identity governance, je cloud governance en waar relevant je Purview data security-aanpak. De techniek is belangrijk, maar ownership bepaalt of het blijft werken.
Begin klein en meetbaar. Kies één high-value scenario, bouw één goede detectie, test één responsepad en leg vast wie eigenaar is. Daarna schaal je uit. Dat werkt beter dan tien half afgemaakte policies die niemand durft aan te zetten.
Conclusie
Cloud Attacks & Workload Identity Abuse: non-human identities zijn je nieuwe adminaccounts is geen onderwerp voor alleen awareness of alleen tooling. De kern is dat moderne aanvallen misbruik maken van normale processen: aanmelden, toestemming geven, data openen, scripts uitvoeren, cloudrechten gebruiken en incidenten te laat correleren. Microsoft Security helpt hier sterk bij, maar alleen als je de signalen over identity, endpoint, cloud en data samenbrengt. Maak logging betrouwbaar, maak detections herhaalbaar, automatiseer de eerste response waar de zekerheid hoog genoeg is en gebruik Purview-context om data-impact te begrijpen.
Volg ITCowboys voor de volgende technische deep dive. In de komende blogs pak ik meer Microsoft Security, XDR, Sentinel, Identity en Purview onderwerpen op vanuit de praktijk.
Bronnenlijst
De hyperlinks hieronder zijn gebruikt voor broncontrole en release-status.