Hoe kunnen Azure RBAC-rechten onderdeel worden van een aanvalspad?

Azure RBAC (rolgebaseerde toegangscontrole) is de ruggengraat van toegangsbeheer in Microsoft Azure. Goed ingericht biedt het een krachtige manier om te bepalen wie wat mag doen binnen je cloudomgeving. Maar wanneer RBAC-rechten te ruim zijn toegewezen, slecht zijn gedocumenteerd of niet regelmatig worden gecontroleerd, worden ze iets heel anders: een aanvalspad.

In dit artikel leer je stap voor stap hoe je Azure RBAC-rechten analyseert vanuit het perspectief van een aanvaller. Je brengt de RBAC-structuur in kaart, identificeert gevaarlijke escalatiepaden, simuleert een aanvalspad en herstelt de gevonden risico’s structureel. Het doel is niet alleen inzicht, maar concrete actie.

Vereiste kennis en toegang voor deze analyse

Voordat je begint, is het belangrijk om te weten wat je nodig hebt. Deze analyse vereist zowel technische kennis als de juiste toegangsrechten binnen je Azure-omgeving. Zonder de juiste basis loop je het risico om een incompleet beeld te krijgen van de werkelijke risico’s.

Zorg dat je beschikt over het volgende:

• Azure-toegang: Minimaal de rol van Security Reader of Reader op abonnementsniveau, bij voorkeur Global Reader in Microsoft Entra ID (voorheen Azure AD)
• Tooling: Azure CLI of Azure PowerShell, toegang tot de Azure Portal, en optioneel tools zoals AzureHound of BloodHound voor het visualiseren van aanvalspaden
• Basiskennis van RBAC-concepten: Begrip van rollen (built-in en custom), bereiken (management group, subscription, resource group, resource) en principals (gebruikers, groepen, service principals, managed identities)
• Toestemming: Voer deze analyse alleen uit op omgevingen waarvoor je expliciete autorisatie hebt. Zonder toestemming is dit ongeoorloofde toegang

Met deze basis op orde kun je de analyse uitvoeren op een gestructureerde en verantwoorde manier. Heb je niet alle toegang zelf, dan is het verstandig om samen te werken met een Azure-beheerder of een externe specialist die een pentest uitvoert op jouw cloudomgeving.

Breng de RBAC-structuur van je Azure-omgeving in kaart

De eerste stap is inzicht krijgen in wie welke rechten heeft, op welk niveau. Dit klinkt eenvoudig, maar in de praktijk zijn Azure-omgevingen vaak gegroeid zonder centraal overzicht. Rechten zijn toegewezen op meerdere niveaus, via verschillende groepen, en soms direct aan individuele accounts.

Voer de volgende stappen uit om een volledig beeld te krijgen:

1. Exporteer alle role assignments op abonnementsniveau via Azure CLI: az role assignment list –all –output json
2. Filter de output op hoge bevoorrechte rollen zoals Owner, Contributor en User Access Administrator
3. Breng ook de Microsoft Entra ID-rollen in kaart, zoals Global Administrator en Privileged Role Administrator, via het Entra-portaal of via PowerShell
4. Inventariseer service principals en managed identities met toegewezen rollen, want dit zijn vaak vergeten maar krachtige identiteiten
5. Visualiseer de structuur per bereik: welke principals hebben toegang op management group-niveau, en welke rechten erven zij daardoor automatisch op onderliggende abonnementen en resource groups?

Na deze stap heb je een gestructureerde lijst van alle RBAC-toewijzingen in je omgeving. Controleer of de lijst volledig is door het totale aantal role assignments in de Portal te vergelijken met je export. Ontbrekende toewijzingen wijzen op een onvolledige analyse of op rechten die via groepen zijn toegewezen en apart moeten worden uitgevraagd.

Identificeer gevaarlijke rechten en escalatiepaden

Niet elke RBAC-toewijzing is even gevaarlijk. De uitdaging is om te onderscheiden welke rechten, ook als ze op zichzelf onschuldig lijken, kunnen worden misbruikt voor privilege escalation. Dit is precies waar aanvallers naar zoeken: combinaties van rechten die samen meer opleveren dan elk afzonderlijk.

Richt je analyse op de volgende categorieën:

• Directe hoge rechten: Owner en User Access Administrator op abonnementsniveau geven volledige controle. Elke toewijzing hier moet worden gerechtvaardigd.
• Gevaarlijke Entra ID-permissies: Accounts met de mogelijkheid om rollen toe te wijzen, wachtwoorden te resetten of applicaties te registreren kunnen hun eigen rechten uitbreiden
• Managed identities met brede rechten: Een managed identity die is gekoppeld aan een virtual machine en Contributor-rechten heeft op een abonnement, is een potentieel escalatiepad als de VM wordt gecompromitteerd
• Custom rollen met gevaarlijke acties: Controleer custom rollen op acties zoals Microsoft.Authorization/roleAssignments/write, waarmee een principal zichzelf of anderen hogere rechten kan geven

Een concrete escalatieroute die regelmatig voorkomt in Azure-omgevingen is de combinatie van een SSRF-kwetsbaarheid in een applicatie, een managed identity met brede rechten, en vervolgens toegang tot een Key Vault met gevoelige geheimen of certificaten. Los van elkaar lijken dit kleine bevindingen. Samen vormen ze een aanvalspad naar volledige controle over cloudresources. Dit is precies waarom red-teamonderzoek verdergaat dan losse kwetsbaarhedenlijsten.

Simuleer een aanvalspad stap voor stap

Met de gevaarlijke rechten in kaart is de volgende stap het daadwerkelijk doorlopen van een aanvalspad in een gecontroleerde omgeving. Het doel is te bewijzen dat een combinatie van zwaktes exploiteerbaar is, niet alleen theoretisch gevaarlijk. Dit geeft prioriteit aan je herstelacties.

Kies een startpunt

Selecteer een realistisch beginpunt voor de simulatie. Dit kan een account zijn met beperkte rechten (zoals een standaardgebruiker of een service principal met een specifieke rol), een gecompromitteerde applicatie-identiteit, of een managed identity die bereikbaar is via een kwetsbare resource.

Doorloop de escalatieketen

Voer de volgende stappen uit om het aanvalspad te simuleren:

1. Bepaal vanuit het startpunt welke Azure-resources bereikbaar zijn en welke acties zijn toegestaan
2. Identificeer of het account rechten heeft om role assignments te maken of te wijzigen. Controleer dit met: az role assignment list –assignee <object-id>
3. Controleer of via de huidige identiteit toegang is tot een Key Vault, storage account of andere gevoelige resource
4. Probeer vanuit de huidige rechten een hogere rol toe te wijzen aan een testaccount (in een testomgeving) om te bewijzen dat escalatie mogelijk is
5. Documenteer elke stap met screenshots, commando-output en een beschrijving van de gebruikte rechten

Na deze simulatie weet je of het aanvalspad werkelijk exploiteerbaar is en hoeveel stappen een aanvaller nodig heeft om volledige controle te krijgen. Een aanvalspad met drie of minder stappen van beperkte toegang naar Owner-rechten is een kritiek risico dat onmiddellijk aandacht vereist.

Valideer en documenteer de gevonden risico’s

Een gevonden aanvalspad heeft alleen waarde als het goed is gedocumenteerd en gevalideerd. Zonder duidelijke documentatie is het moeilijk om prioriteiten te stellen en zijn de bevindingen lastig over te dragen aan beheerders of management.

Structureer je documentatie per gevonden aanvalspad op de volgende manier:

1. Beschrijf het startpunt: Welke identiteit of toegang is het beginpunt van het pad?
2. Beschrijf de stappen: Welke rechten, misconfiguraties of zwaktes worden opeenvolgend benut?
3. Beschrijf het eindpunt: Wat kan een aanvaller bereiken als het pad volledig wordt doorlopen?
4. Classificeer de ernst: Gebruik een risicoschaal op basis van impact (wat kan worden bereikt?) en kans (hoe realistisch is het startpunt?)
5. Voeg bewijs toe: Commando-output, screenshots of logregels die het pad aantoonbaar maken

Valideer ook of de gevonden rechten daadwerkelijk in gebruik zijn. Een account met Owner-rechten dat al twee jaar niet is ingelogd, is een ander risicoprofiel dan een actief serviceaccount met dezelfde rechten. Azure Monitor en de aanmeldingslogboeken in Entra ID helpen je om activiteit te beoordelen. Meer achtergrond over hoe aanvalspaden worden geanalyseerd in bredere beveiligingsonderzoeken vind je via ons cyberresearch-overzicht.

Herstel gevaarlijke RBAC-toewijzingen structureel

Met de bevindingen gedocumenteerd is het tijd voor herstel. Het verwijderen van één gevaarlijke toewijzing is een begin, maar structureel herstel vereist dat je de onderliggende oorzaken aanpakt. Anders groeit de RBAC-structuur opnieuw toe naar een onveilige situatie.

Pak het herstel in de volgende volgorde aan:

1. Verwijder ongebruikte en onnodige role assignments direct: Begin met accounts die geen actieve gebruikers meer hebben, verlopen service principals en testaccounts met hoge rechten
2. Vervang brede rollen door specifieke rollen: Gebruik het principe van least privilege. Een applicatie die alleen leesrechten nodig heeft op een storage account, krijgt de rol Storage Blob Data Reader, niet Contributor
3. Beperk Owner en User Access Administrator tot een minimum: Gebruik Privileged Identity Management (PIM) om hoge rechten tijdelijk en op aanvraag beschikbaar te stellen in plaats van permanent toe te wijzen
4. Stel alerts in voor wijzigingen in role assignments: Configureer Azure Monitor of Microsoft Sentinel om te signaleren wanneer nieuwe hoge rechten worden toegewezen
5. Documenteer een RBAC-beleid: Leg vast wie rechten mag toewijzen, op welk niveau, en hoe dit wordt gereviewd. Zonder beleid groeien problemen vanzelf terug

Controleer na het herstel opnieuw of de eerder gesimuleerde aanvalspaden nog steeds exploiteerbaar zijn. Als de stappen in het aanvalspad zijn verbroken, is het risico effectief gemitigeerd. Herhaal de inventarisatie uit stap twee om te bevestigen dat er geen nieuwe gevaarlijke combinaties zijn ontstaan door de wijzigingen.

Hoe Q-Cyber helpt met Azure RBAC-beveiliging

Een RBAC-analyse handmatig uitvoeren geeft waardevolle inzichten, maar heeft beperkingen. Het vergt tijd, specifieke toolkennis en het vermogen om losse bevindingen te verbinden tot realistische aanvalspaden. Precies daar voegen wij waarde toe.

Bij Q-Cyber analyseren we Azure RBAC-rechten niet als een checklist, maar als een aanvaller die zoekt naar de snelste route naar volledige controle. Wat we concreet doen:

• We voeren een handmatige pentest uit op je Azure-omgeving, inclusief analyse van RBAC-structuren, managed identities en privilege-escalatiepaden
• We correleren losse bevindingen tot werkelijke aanvalspaden, zodat je weet welke combinaties van zwaktes het grootste risico vormen
• We leveren een helder rapport met concrete herstelprioriteiten, niet alleen een lijst met technische bevindingen
• Via Continuous-Q® blijven we na de initiële pentest je omgeving volgen, zodat nieuwe rechten en configuratiewijzigingen niet onopgemerkt blijven
• We adviseren onafhankelijk, zonder afhankelijkheid van softwarepartijen of toeleveranciers

Wil je weten hoe jouw Azure RBAC-structuur eruitziet vanuit het perspectief van een aanvaller? Neem contact op en we bespreken wat een gerichte analyse voor jouw omgeving kan opleveren.

Gerelateerde artikelen

• Cybersecurity governance: wat is het en hoe begin je?
• Wat is applicatiebeveiliging en waarom is het belangrijk?
• Informatiebeveiliging in de zorg: speciale eisen
• Hoe lang duurt een gemiddelde pentest?
• Wat houdt penetratietesten precies in?
• Wat is het verschil tussen pentesten en vulnerability scanning?
• Hoe meet je de effectiviteit van pentesten?
• Wat zijn de gevolgen van een mislukte pentest?
• Hoe weet ik of mijn website is gehackt?