- Gebruik Microsoft Entra ID, voorheen Azure AD, als basis voor gebruikers, groepen, toepassingen en workload identities.
- Ontwerp Conditional Access met MFA, risicosignalen, apparaatstatus en noodtoegang voordat beleid wordt afgedwongen.
- Beperk Azure RBAC en PIM tot de kleinste bruikbare scope, met tijdgebonden toegang voor beheerdersrollen.
- Controleer aanmeldingen, auditgebeurtenissen, provisioning en access reviews zodat IAM ook na de implementatie betrouwbaar blijft.
Identiteit en toegang binnen AZ-500 is het domein waarin Azure-resources, Microsoft Entra ID-objecten en applicaties veilig beschikbaar worden gemaakt zonder beheerders onnodig veel permanente rechten te geven. Voor het examen betekent dit dat kandidaten Conditional Access, MFA, RBAC, PIM, Identity Protection, app-toegang en workload identities moeten begrijpen; in productie betekent het vooral dat dezelfde onderdelen samenhangend moeten worden ontworpen.
Microsoft gebruikt sinds de hernoeming de naam Microsoft Entra ID voor wat veel teams nog Azure Active Directory of Azure AD noemen. Die naamswijziging is meer dan cosmetisch bij studie en documentatie: oude termen komen nog voor in scripts, portalpaden en artikelen, terwijl nieuwe examen- en productdocumentatie vooral Entra ID gebruikt. In dit artikel wordt Entra ID gebruikt, met Azure AD alleen waar het nodig is om bestaande productnamen of documentatie te herkennen.
Laatst herzien: 29 juli 2026. De inhoud is afgestemd op publieke Microsoft Learn-documentatie voor AZ-500 en Microsoft Entra ID-functies. Examendetails kunnen wijzigen; de officiële pagina voor Microsoft Certified: Azure Security Engineer Associate blijft het vertrekpunt voor actuele skills measured, examenstatus en Microsofts eigen oefenmateriaal.
Waarom IAM zwaar weegt in AZ-500
Identiteit is in Azure meestal het eerste controlepunt vóór netwerk-, compute- of databeveiliging effect krijgt. Een storage account kan versleuteld zijn, een virtueel netwerk kan afgeschermd zijn en Defender-signalen kunnen correct binnenkomen, maar een te brede Owner-toewijzing of zwak app-secret kan alsnog leiden tot ongewenste wijziging van resources.
Daarom behandelt AZ-500 IAM niet als losstaand onderwerp. Identiteit raakt aan governance, logging, incidentrespons, automatisering en applicatie-integratie. Een security engineer moet kunnen uitleggen waarom een gebruiker toegang krijgt, via welk beleid die toegang wordt toegestaan, welke rol de gebruiker precies heeft en hoe die beslissing achteraf wordt gecontroleerd.
Er is ook een nuttig onderscheid met SC-300. AZ-500 is de certificering voor de Azure Security Engineer Associate en behandelt Azure-beveiliging breed, inclusief IAM, netwerkbeveiliging, workloadbescherming, data en monitoring. SC-300, de Identity and Access Administrator Associate, gaat dieper in op Entra ID identity lifecycle, authenticatie, Conditional Access en applicatietoegang. Wie vooral identity-adminwerk doet, kan SC-300 inhoudelijk dichter bij de dagelijkse rol vinden; wie Azure-omgevingen end-to-end moet beveiligen, heeft met AZ-500 de bredere context nodig.
Entra ID, licenties en functies die vaak door elkaar lopen
Een veelgemaakte studiefout is dat alle Entra ID-functies als één pakket worden gezien. In werkelijkheid verschilt de beschikbaarheid per tenant, licentie en configuratie. Conditional Access is afhankelijk van Entra ID Premium-functionaliteit, terwijl functies zoals Identity Protection en Privileged Identity Management doorgaans met Entra ID P2 worden geassocieerd. MFA kan bovendien op verschillende manieren bestaan: als legacy per-user MFA, via Security Defaults of als onderdeel van Conditional Access-beleid.
Voor AZ-500 is vooral belangrijk dat kandidaten het ontwerp kunnen verklaren. Legacy per-user MFA is beperkt en moeilijk centraal te sturen. Conditional Access geeft veel meer context, zoals gebruiker, groep, applicatie, locatie, apparaatcompliance, aanmeldingsrisico en gebruikersrisico. Security Defaults kan geschikt zijn voor eenvoudige tenants, maar biedt niet dezelfde verfijning als uitgewerkt CA-beleid.
Identity Protection verdient extra precisie. Het is geen versleutelingsfunctie. De service gebruikt Microsoft-risicosignalen en machine learning om risicovolle gebruikers en aanmeldingen te detecteren, waarna beleid bijvoorbeeld MFA kan vereisen, wachtwoordwijziging kan afdwingen of toegang kan blokkeren. De connector- en documentatiepagina voor Azure AD Identity Protection gebruikt nog de oudere naamgeving, maar de concepten horen bij Microsoft Entra ID.
Conditional Access veilig uitrollen
Conditional Access is krachtig omdat het toegang niet alleen baseert op een wachtwoord, maar op context. Een beheerder kan andere eisen stellen aan een Global Administrator die buiten een vertrouwde locatie inlogt dan aan een standaardgebruiker op een compliant beheerd toestel. Die flexibiliteit maakt CA ook risicovol: één slecht getest beleid kan beheerders, helpdesk of break-glass-accounts buitensluiten.
Een betrouwbaar CA-ontwerp begint daarom met noodtoegang. Break-glass-accounts horen cloud-only te zijn, sterk beveiligd te worden, uitgesloten te zijn van blokkende CA-regels en continu bewaakt te worden. Die uitsluiting is geen zwakte wanneer zij goed wordt gedocumenteerd en gealarmeerd; zij voorkomt dat een tenant onbeheerbaar wordt tijdens een storing, federatieprobleem of foutieve beleidswijziging.
In de praktijk wordt nieuw beleid eerst in Report-only geplaatst. Daarna worden sign-in logs bekeken om te zien welke gebruikers, applicaties en locaties geraakt zouden worden. Named locations helpen daarbij om bekende bedrijfsnetwerken of landenbeleid consistent te behandelen, maar ze mogen niet worden gebruikt als enige beveiligingscontrole. Een aanvaller kan via een vertrouwde locatie of geïnfecteerd apparaat alsnog toegang proberen te krijgen.
Een volwassen CA-beleid combineert signalen. MFA voor beheerders is een basismaatregel, maar device compliance, app sensitivity, sign-in risk en gebruikersgroep maken het verschil tussen een generieke regel en beleid dat aansluit op bedrijfsrisico. Voor AZ-500 is het belangrijk om te begrijpen wat het beleid doet, welke grant controls worden toegepast en hoe uitsluitingen worden verantwoord.
Voorbeeld — Conditional Access-policy als ontwerpschets
Onderstaande JSON is geen kant-en-klare Microsoft Graph-aanroep, maar een compacte ontwerpschets die helpt om CA-logica te bespreken voordat een beleid in de tenant wordt aangemaakt. Gebruik bij implementatie de Microsoft Graph-documentatie en test nieuwe regels eerst in Report-only.
{
"displayName": "Require MFA for privileged roles outside trusted locations",
"state": "enabledForReportingButNotEnforced",
"conditions": {
"users": {
"includeRoles": [
"Global Administrator",
"Privileged Role Administrator"
],
"excludeGroups": [
"ca-exclude-break-glass-accounts"
]
},
"locations": {
"includeLocations": ["All"],
"excludeLocations": ["trusted-corporate-locations"]
}
},
"grantControls": {
"operator": "AND",
"builtInControls": ["mfa"]
}
}
De leerwaarde zit in de structuur: een hoge-risicogroep wordt geraakt, break-glass blijft uitgesloten, vertrouwde locaties worden apart behandeld en het beleid staat nog niet afdwingend aan. Wie dit patroon begrijpt, kan in de portal of via Microsoft Graph veiliger redeneren over echte CA-configuraties.
RBAC en PIM: toegang beperken zonder beheer te blokkeren
Azure RBAC bepaalt wat een identiteit mag doen op een bepaalde scope. Die scope kan een management group, subscription, resource group of individuele resource zijn. De fout die in omgevingen vaak terugkomt, is dat Owner of Contributor op subscriptionniveau wordt toegekend omdat dit snel werkt. Het resultaat is een omgeving waarin wijzigingen technisch mogelijk zijn, maar governance moeilijk controleerbaar wordt.
Een betere aanpak is beginnen bij de kleinste scope die het werk mogelijk maakt. Een applicatieteam dat één resource group beheert, heeft zelden Contributor nodig op de volledige subscription. Een platformteam kan bredere rechten nodig hebben, maar zelfs dan hoort het onderscheid tussen lezen, wijzigen, roltoewijzingen beheren en beleid aanpassen expliciet te zijn.
PIM voegt daar tijdelijkheid en controle aan toe. In plaats van permanente Global Administrator- of Owner-rechten kunnen gebruikers eligible worden gemaakt en hun rol alleen activeren wanneer zij die nodig hebben. Activatie kan worden gekoppeld aan MFA, justification, ticketinformatie, goedkeuring en een beperkte duur. Voor rollen met hoge impact is dat vaak een betere balans tussen beheerbaarheid en risico.
Access reviews sluiten de cirkel. Rollen die ooit logisch waren voor een project, leverancier of migratie blijven anders vaak maanden of jaren bestaan. Periodieke beoordeling van groepen, gastgebruikers en privileged roles maakt IAM minder afhankelijk van handmatige opruimacties op het einde van een project.
Voorbeeld — RBAC-toewijzing op resource group-scope
Deze Azure CLI-opdracht toont hoe een groep Contributor kan krijgen op één resource group in plaats van op de hele subscription. In productie hoort de groepsnaam, scope en rol eerst te worden gevalideerd tegen het changeproces en het least-privilege-ontwerp.
az role assignment create \
--assignee "azure-secops-rg-contributors" \
--role "Contributor" \
--scope "/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/rg-secops-prod-weu"
De opdracht illustreert het belangrijkste examen- en praktijkpunt: RBAC is altijd een combinatie van identiteit, rol en scope. Als één van die drie te breed is gekozen, wordt het toegangsmodel zwakker dan nodig.
Workload identities en applicatietoegang
AZ-500-kandidaten richten zich vaak eerst op menselijke gebruikers, maar in moderne Azure-omgevingen hebben pipelines, functions, containers en integraties minstens even vaak toegang nodig. Voor die workloads bestaan verschillende identiteitsvormen, waaronder managed identities, service principals en app-registrations. Het onderscheid is belangrijk omdat secrets, certificaten en federatie elk andere risico’s opleveren.
Managed identities zijn meestal de voorkeursoptie voor workloads die binnen Azure draaien, omdat Azure de levenscyclus van de identiteit beheert en er geen client secret in code of pipelinevariabelen nodig is. Voor CI/CD buiten Azure, zoals GitHub Actions of Azure DevOps-scenario’s, is workload identity federation vaak veiliger dan langdurige client secrets. Daarbij vertrouwt Entra ID een externe tokenuitgever onder gecontroleerde voorwaarden, zodat de pipeline tijdelijke tokens kan verkrijgen.
App-registraties blijven relevant voor SaaS-integraties en API-toegang, maar Graph-permissies vragen strikte discipline. Application permissions geven een workload vaak brede tenantrechten en werken zonder ingelogde gebruiker. Delegated permissions volgen de context van een gebruiker. In beide gevallen hoort toestemming beperkt te blijven tot de kleinste Graph-scope die de toepassing nodig heeft, met admin consent alleen wanneer het ontwerp dat rechtvaardigt.
Gastgebruikers verdienen aparte aandacht. B2B-toegang is handig voor leveranciers, auditors en projectteams, maar standaardrechten in de tenant moeten worden beperkt. Terms of Use, MFA via Conditional Access en access reviews voor projectgroepen voorkomen dat externe accounts langer toegang houden dan nodig is. Dit is geen los compliance-detail; het bepaalt hoe veilig samenwerking over tenantgrenzen heen blijft.
Monitoring, governance en examenvoorbereiding
Een IAM-ontwerp is pas verdedigbaar wanneer gebeurtenissen zichtbaar zijn. Entra sign-in logs laten zien wie probeerde aan te melden, met welke applicatie, vanaf welke locatie en met welk resultaat. Audit logs tonen wijzigingen aan gebruikers, groepen, rollen en beleid. Provisioning logs helpen bij lifecycle-processen, bijvoorbeeld wanneer gebruikers automatisch naar SaaS-applicaties worden gesynchroniseerd.
Identity Protection-rapporten geven context rond risicovolle gebruikers en aanmeldingen. In een productieomgeving hoort dit niet alleen in de portal bekeken te worden; koppeling met een SIEM, zoals Microsoft Sentinel, maakt detectie en respons consistenter. Waarschuw in het bijzonder op privilege-escalatie, wijzigingen aan Conditional Access, nieuwe credentials op app-registrations, activatie van hoge PIM-rollen en aanmeldingen van break-glass-accounts.
Voor het examen helpt het om elke functie te koppelen aan een operationele vraag. Conditional Access beantwoordt onder welke voorwaarden toegang wordt toegestaan. RBAC beantwoordt wat iemand binnen Azure mag doen. PIM beantwoordt wanneer hoge rechten mogen worden gebruikt. Identity Protection beantwoordt hoe de tenant reageert op risicosignalen. Monitoring beantwoordt hoe afwijkingen later worden gevonden en onderzocht.
Wie gestructureerd wil oefenen, kan een labtenant gebruiken en per thema één scenario bouwen: een CA-policy in Report-only, een PIM-eligible rol, een RBAC-toewijzing op resource group-niveau, een app-registratie met beperkte Graph-toegang en een access review voor gastgebruikers. Readynez behandelt AZ-500 in diezelfde praktijkgerichte context via de AZ-500-cursus, maar de leerwaarde zit vooral in het zelf kunnen uitleggen waarom elke instelling veilig is gekozen.
Veelgemaakte fouten bij AZ-500-IAM
De meeste problemen ontstaan niet doordat een functie ontbreekt, maar doordat zij te snel of te breed wordt toegepast. Per-user MFA blijft bijvoorbeeld bestaan naast Conditional Access, waardoor uitzonderingen en gebruikerservaring moeilijk voorspelbaar worden. Een nieuw CA-beleid wordt soms meteen ingeschakeld zonder Report-only-test, waardoor legitieme beheerders of serviceaccounts worden geraakt.
Bij RBAC is de klassieke fout een brede Owner-toewijzing op subscriptionniveau. Bij PIM is de fout dat rollen wel eligible worden gemaakt, maar dat activatievoorwaarden, goedkeuring en reviews zwak blijven. Bij app-registraties is het patroon vergelijkbaar: een langdurig client secret en brede Graph-permissies lossen het korte-termijnprobleem op, maar vergroten de impact van credentiallekken.
De praktische correctie is steeds dezelfde: begin met least privilege, test op beperkte groepen, documenteer uitzonderingen en monitor de controle zelf. Een CA-uitsluiting zonder alert is riskant. Een break-glass-account zonder periodieke test is onzeker. Een access review zonder eigenaar wordt administratief werk zonder beveiligingswaarde.
Referenties voor verder studeren
Gebruik voor examenplanning de officiële Microsoft Learn-pagina voor Azure Security Engineer Associate en controleer daar de actuele vaardigheden, eventuele wijzigingen en oefenmogelijkheden. Voor Identity Protection, Conditional Access, PIM, RBAC, workload identities en access reviews is Microsoft Learn ook de primaire bron, maar let op dat sommige pagina’s nog oudere Azure AD-termen bevatten.
Aanvullend kan de startpagina van Readynez helpen om trainingsopties te vinden wanneer zelfstudie onvoldoende structuur biedt. Voor organisaties die meerdere Azure- en Microsoft-securityrollen willen plannen, kan Readynez365 relevant zijn als abonnementsroute voor terugkerende training.
FAQ
Hoe helpt Microsoft Entra ID Protection bij risicovolle aanmeldingen?
Microsoft Entra ID Protection gebruikt risicosignalen en machine learning om verdachte gebruikers- en aanmeldingsrisico’s te detecteren. Voorbeelden zijn atypische aanmeldingspatronen, signalen rond gelekte credentials of aanmeldingen die afwijken van normaal gedrag.
De reactie wordt bepaald door beleid. Een tenant kan bijvoorbeeld MFA vereisen, een wachtwoordwijziging afdwingen of toegang blokkeren. Voor AZ-500 is het belangrijk om Identity Protection niet te zien als versleuteling, maar als detectie- en responslaag binnen identity security.
Voor beheerde tenants is Conditional Access doorgaans de betere route dan legacy per-user MFA, omdat beleid dan kan worden gebaseerd op gebruiker, groep, applicatie, risico, locatie en apparaatstatus. Security Defaults kan geschikt zijn voor eenvoudige omgevingen, maar is minder verfijnd.
Een veilige uitrol begint met beheerders en risicovolle scenario’s, gebruikt Report-only voor nieuwe CA-regels en houdt break-glass-accounts buiten blokkende policies. Daarna kan MFA gefaseerd worden uitgebreid naar gebruikersgroepen en gevoelige applicaties.
Hoe wordt RBAC effectief toegepast volgens least privilege?
Effectieve RBAC begint met de juiste scope. Een rol op resource group-niveau is vaak veiliger dan dezelfde rol op subscriptionniveau, zolang het team daarmee zijn werk kan doen. Built-in roles zijn meestal voldoende; custom roles zijn nuttig wanneer ingebouwde rollen te breed zijn.
Roltoewijzingen moeten regelmatig worden beoordeeld, vooral voor Owner, User Access Administrator en Contributor. Waar mogelijk worden hoge rechten gecombineerd met PIM, zodat toegang tijdelijk wordt geactiveerd en achteraf traceerbaar blijft.
Wanneer gebruik je managed identities in plaats van app secrets?
Managed identities zijn geschikt voor Azure-workloads die toegang nodig hebben tot Azure-resources zonder dat er een secret in code, configuratie of pipelinevariabelen staat. Azure beheert de identiteit, waardoor credentialrotatie en secretopslag minder foutgevoelig worden.
Voor workloads buiten Azure kan workload identity federation een betere optie zijn dan langdurige client secrets. Als app-registraties toch secrets of certificaten gebruiken, moeten scopes beperkt zijn, credentials worden geroteerd en wijzigingen worden gemonitord.
Welke logs zijn belangrijk voor IAM-governance in Azure?
Sign-in logs, audit logs en provisioning logs vormen de basis voor Entra ID-governance. Sign-in logs tonen aanmeldingspogingen en CA-resultaten, audit logs tonen configuratiewijzigingen en provisioning logs helpen bij lifecycle-onderzoek tussen Entra ID en applicaties.
Daarnaast zijn Identity Protection-rapporten, PIM-activatielogs en alerts op wijzigingen aan app-registraties belangrijk. In productie worden deze signalen bij voorkeur doorgestuurd naar een SIEM zodat riskante aanmeldingen en privilege-escalaties sneller onderzocht kunnen worden.
