Microsoft AZ-500: Identiteits- en toegangsbeheer — Studiegids

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Onderdeel van de Microsoft Azure Security Engineer Associate AZ-500 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Identiteits- en toegangsbeheer (IAM) in Microsoft Azure is gecentreerd rond Microsoft Entra ID (voorheen Azure AD). Dit bepaalt wie toegang heeft tot welke resources, onder welke voorwaarden en met welke privileges. Een effectieve IAM-architectuur minimaliseert permanente privileges, dwingt voorwaardelijke en risicogebaseerde toegang af, en implementeert moderne authenticatie voor zowel mensen als workloads, terwijl het hybride en externe samenwerkingsscenario’s ondersteunt.

Microsoft Entra Identiteitsconstructies en Scopes

Tenants, gebruikers en groepen
- Een tenant vertegenwoordigt de identiteitsgrens en vertrouwensbasis van uw organisatie. Gebruikers kunnen ‘member’- of ‘guest’-accounts (B2B) zijn. Gebruik beveiligingsgroepen voor autorisatie en Microsoft 365-groepen voor samenwerkingsfuncties; geef de voorkeur aan dynamische groepen om handmatig lidmaatschapsbeheer te verminderen.
Administrative Units (AU’s)
- Met AU’s kunt u directory-rollen delegeren over een subset van gebruikers/apparaten (bv. een regionale helpdesk kan alleen gebruikers in Europa beheren). Dit ondersteunt het ’least privilege’-principe voor directory-taken.
Directory-rollen en de scope van roltoewijzingen
- Directory-rollen (bv. Global Administrator, User Administrator) zijn van toepassing op Microsoft Entra-resources. Beperk de scope van directory-rollen waar mogelijk tot een AU om de ‘blast radius’ te verkleinen. De rol Global Administrator is vereist om Privileged Identity Management (PIM) initieel te configureren.
Scopes van op rollen gebaseerd toegangsbeheer in Azure (Azure RBAC)
- Azure RBAC regelt de toegang tot Azure-resources. Wijs rollen toe op het niveau van een management group, subscription, resource group of resource. Overerving stroomt naar beneden; kies altijd de kleinst mogelijke scope om overmatige privileges te verminderen.
Operationele redenering
- Houd directory-rollen (Entra) gescheiden van Azure RBAC (resource-autorisatie). Gebruik AU’s en strikte RBAC-scopes om het administratieve bereik te beperken, de mogelijkheden voor ’lateral movement’ te verkleinen en toegangsbeoordelingen te vereenvoudigen.

Toegangscontrole met Azure RBAC en ‘Least Privilege’

Ingebouwde rollen en ’least privilege’
- Geef de voorkeur aan de meest specifieke ingebouwde rol die geschikt is voor de taak. Voorbeeld: geef alleen-lezen toegang voor het pullen van container-images met AcrPull en upload/push-toegang met AcrPush, in plaats van de brede rol Contributor. Voor Key Vault, verleen administratieve controle via RBAC alleen aan vault-beheerders, terwijl u voor specifieke objectoperaties zoals certificaatbeheer gedetailleerde toegangsbeleidsregels gebruikt.
Overerving van roltoewijzingen
- Wijs toe op de laagst mogelijke scope. Toewijzingen op het niveau van een management group of subscription worden overgeërfd; vermijd brede, overgeërfde rechten tenzij dit een bewuste keuze is. Wanneer u consistente RBAC over meerdere subscriptions nodig heeft, pas dan consistente roltoewijzingen toe via Azure Blueprints (of moderne IaC-alternatieven) in plaats van handmatige PIM-toewijzingen.
Deny-toewijzingen
- Deny-toewijzingen blokkeren expliciet acties, ongeacht ‘allow’-toewijzingen, en worden doorgaans aangemaakt door Azure-services zoals Azure Policy of Blueprints. Gebruik ze om niet-onderhandelbare ‘guardrails’ af te dwingen (bv. het voorkomen van openbare netwerkregels op gevoelige resources).
Aangepaste rollen
- Wanneer ingebouwde rollen te breed zijn, definieer dan aangepaste rollen met alleen de vereiste acties. Valideer door middel van ’least-privilege’-testen en toegangsbeoordelingen.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

Operationele redenering
- RBAC-scoping en aangepaste rollen verminderen overmatige rechten en het audit-oppervlak. Deny-toewijzingen coderen ‘harde’ compliance-beperkingen die niet kunnen worden omzeild door per ongeluk te brede ‘allow’-toekenningen, wat de weerbaarheid van de ‘posture’ verbetert.

Geprivilegieerde Toegang, Conditional Access en Identity Protection

Privileged Identity Management (PIM)
- Eligible vs. active: ’eligible’-toewijzingen verlenen geen permanente permissies; gebruikers moeten JIT-activering uitvoeren om ‘active’ te worden. Dwing goedkeuring, een rechtvaardiging en MFA af bij activering; stel beperkte duur in en vereis ticketreferenties voor traceerbaarheid. Begin met het inventariseren van geprivilegieerde rollen om de huidige blootstelling te begrijpen. Gebruik periodieke toegangsbeoordelingen, idealiter met resource- of groepseigenaren als beoordelaars, om de voortdurende noodzaak te valideren.
Conditional Access (CA)
- Toewijzingen zijn gericht op gebruikers/groepen, workload-identiteiten, cloud-apps en acties. Voorwaarden omvatten aanmeldingsrisico, apparaatplatform/-status, locaties, client-apps en filters voor apparaten en apps. Toegangscontroles (‘grant controls’) kunnen MFA, conforme of ‘hybrid Azure AD–joined’ apparaten, app-beschermingsbeleid of gebruiksvoorwaarden vereisen. Sessiecontroles beperken de aanmeldingsfrequentie, persistente sessies en door de app afgedwongen beperkingen (bv. alleen-webtoegang voor SharePoint). Gebruik de ‘report-only’-modus om de impact van beleid veilig te valideren voordat het wordt afgedwongen. Houd uitsluitingen bij voor ‘break-glass’-accounts en gefaseerde uitrol om buitensluiting te voorkomen.
Identity Protection
- Gebruikersrisico (‘user risk’) weerspiegelt de waarschijnlijkheid dat een account gecompromitteerd is; aanmeldingsrisico (‘sign-in risk’) weerspiegelt de waarschijnlijkheid dat een specifieke sessie riskant is. Configureer beleid om veilige herstelacties te vereisen:
  - Gebruikers met gelekte referenties: behandel als Hoog gebruikersrisico; dwing een wachtwoordreset af en blokkeer totdat het probleem is verholpen.
  - Aanmeldingen vanaf IP’s met verdachte activiteit: behandel ten minste als Gemiddeld aanmeldingsrisico; vraag om MFA of blokkeer voor gevoelige apps.
- Integreer met CA om het vertrouwen in realtime aan te passen. Volg de risicogeschiedenis en herstelacties om de effectiviteit te meten.
Operationele redenering
- PIM elimineert permanente privileges en dwingt sterke, auditeerbare activering af. CA en Identity Protection passen ‘zero trust’ toe—elke toegangspoging wordt geverifieerd op basis van gebruiker, apparaat, sessie en risico—wat succesvolle diefstal van referenties en ’token replay’-aanvallen vermindert.

Hybride en Workload-identiteiten

Opties voor hybride identiteit
- Wachtwoord-hashsynchronisatie (PHS): synchroniseert wachtwoord-hashes naar Entra ID. Eenvoudig en veerkrachtig; dwingt on-premises aanmeldingsbeleid niet af op het moment van authenticatie.
- Pass-through authenticatie (PTA): valideert wachtwoorden tegen on-prem DC’s via lichtgewicht connectors; dwingt on-prem wachtwoordbeleid en accountbeperkingen in realtime af, zonder AD FS.
- Federatie (bijv. AD FS): verplaatst authenticatie naar een on-prem STS. Alleen gebruiken wanneer vereist voor complexe claims of legacy-scenario’s; het introduceert meer servers en operationele overhead.
- Naadloze eenmalige aanmelding (Seamless SSO): meldt gebruikers aan op apparaten die lid zijn van het domein binnen het bedrijfsnetwerk met minimale prompts.
- Operationele keuze: om on-prem wachtwoordbeleid en accountbeperkingen af te dwingen en tegelijkertijd het aantal servers te minimaliseren, implementeer PTA en Seamless SSO en schakel ook PHS in voor veerkracht/failover van scenario’s die niet afhankelijk zijn van PTA. Federatie alleen verhoogt de complexiteit en voldoet niet aan het doel om “servers te minimaliseren”.
App-authenticatie naar Azure SQL vanaf hybride Windows-apparaten
- Gebruik Active Directory geïntegreerde authenticatie om prompts te minimaliseren en waar mogelijk gebruik te maken van Kerberos/SSO.
Beheerde identiteiten en service-principals
- Beheerde identiteiten (door het systeem toegewezen of door de gebruiker toegewezen) zijn de eerste keuze voor workloads die in Azure worden gehost, omdat ze secrets elimineren en referenties automatisch rouleren. Wijs RBAC met de minste privileges toe aan de identiteit op het resource-niveau.
- Service-principals ondersteunen app-registraties; gebruik certificaatreferenties in plaats van client secrets en stel de kortst mogelijke levensduur in.
Workload identity federation
- Gebruik OIDC-federatie om externe workload-identiteiten (bijv. GitHub Actions, Kubernetes) tokens te laten verkrijgen voor Entra-apps zonder secrets op te slaan. Definieer de issuer-, subject- en audience-claims nauwkeurig om te beperken wie tokens kan uitwisselen.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

Toegang van AKS tot ACR
- Geef de beheerde identiteit van het AKS-cluster de rol AcrPull op de doel-registry via de attach-acr-flow, die de juiste scoping automatiseert en verkeerde toewijzingen voorkomt.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

Operationele redenering
- PTA+PHS+Seamless SSO dwingt realtime on-prem controles af met behoud van cloud-veerkracht. Beheerde identiteiten en federatie verwijderen statische secrets uit pipelines en de runtime, waardoor veelvoorkomende routes voor diefstal van referenties worden afgesloten.

Externe Samenwerking, Authenticatiemethoden en App-toegang

Externe identiteiten en B2B-samenwerking
- Gebruik B2B-gastaccounts met instellingen voor cross-tenant toegang, gebruiksvoorwaarden en CA gericht op gasten. Beperk wie kan uitnodigen en geef de voorkeur aan just-in-time toegang via entitlement management.
Entitlement management en toegangspakketten
- Bundel groepen, apps en SharePoint-sites in toegangspakketten met beleidsregels die definiëren wie kan aanvragen (inclusief externe gebruikers), goedkeuringsstromen, toewijzingsduren en toegangsbeoordelingen. Gebruik voor de selectie van beoordelaars Groepseigenaren om de bedrijfsverantwoordelijkheid bij de resourcebeheerders te houden.
Authenticatiemethoden en wachtwoordloos
- Standaardiseer op sterke methoden: FIDO2-beveiligingssleutels, Windows Hello for Business en Microsoft Authenticator telefoonaanmelding. Gebruik de gecombineerde registratie van beveiligingsinformatie (SSPR + MFA) en dwing het MFA-registratiebeleid af voor alle gebruikers. Activeer SSPR met on-prem writeback indien nodig; vereis veilige methoden en beperk waar mogelijk tot door het bedrijf beheerde factoren. Schakel verouderde/basis authenticatieprotocollen uit en blokkeer zwakke, alleen-sms MFA waar het risico dit rechtvaardigt.
Microsoft Entra application proxy
- Publiceer on-premises webapps zonder inkomende firewall-openingen. Gebruik connectorgroepen voor HA, pre-authenticatie met Entra ID, en pas CA, apparaatnaleving en Identity Protection toe als lagen voor zero trust op verouderde apps.
Beveiliging van applicatieregistratie
- Vereis workflows voor beheerdersgoedkeuring; beperk wie apps kan aanmaken; classificeer machtigingen; geef de voorkeur aan applicatiemachtigingen alleen wanneer geen gebruikerscontext vereist is en scope API’s tot het minimum. Schakel ‘implicit grant’ uit waar mogelijk, vereis toewijzing voor enterprise-apps en geef de voorkeur aan certificaten boven secrets met geautomatiseerde rotatie.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

Operationele redenering
- Toegangspakketten en app proxy bieden beheerde, auditeerbare externe toegang. Sterke, wachtwoordloze methoden verhogen de phishing-weerstand. Strikte controles op app-registratie voorkomen te brede toestemming en verminderen de kans op app-imitatie.

Praktijkscenario

Adobe Inc. moet een externe leverancier tijdelijke administratieve toegang verlenen tot een subset van Azure-resources en een interne verouderde webapp publiceren voor de leverancier, met handhaving van sterke authenticatie en ‘zero standing privilege’.

Scope en modelleer toegang

Maak een resourcegroep rg-vendor-ops en verplaats alleen de benodigde resources ernaartoe. Wijs de minimale Azure RBAC-rollen toe (bijv. Contributor op rg-vendor-ops; Reader op een diagnostische resourcegroep).
Rationale: Een enge scope voorkomt laterale beweging. Rolovererving is beperkt tot rg-vendor-ops, wat de ‘blast radius’ beperkt.

Beheer identiteit en activering met PIM

Maak leveranciersbeheerders ’eligible’ (in aanmerking komend), niet permanent, voor de vereiste rollen; vereis goedkeuring, ticket-ID, MFA bij activering en beperk activering tot 4 uur. Begin met het uitvoeren van PIM’s ‘Discover privileged roles’ om een baseline van bestaande toewijzingen te maken.
Rationale: Toewijzingen als ’eligible’ verwijderen ‘standing privilege’. Goedkeuring en MFA dwingen JIT-toegang af, afgestemd op supportvensters, en bieden een auditeerbare controle.

Handhaaf Conditional Access- en risicobeleid

Maak een CA-beleid gericht op de leveranciersgroep en de Azure-portal en ARM API’s, dat MFA, een compliant/hybrid-joined apparaat vereist en toegang vanaf risicovolle locaties blokkeert. Activeer eerst ‘report-only’; handhaaf daarna. Configureer Identity Protection: blokkeer Hoog gebruikersrisico (gelekte credentials) totdat het wachtwoord is gereset; vereis MFA voor Gemiddeld aanmeldingsrisico (verdacht IP).
Rationale: CA koppelt toegang in realtime aan apparaatvertrouwen en risico. ‘Report-only’ voorkomt storingen tijdens de uitrol. Risicobeleid herstelt automatisch gecompromitteerde sessies en accounts.

Publiceer de verouderde app met Microsoft Entra application proxy

Implementeer twee connectors in afzonderlijke, aan de leverancier blootgestelde subnetten voor HA. Configureer pre-authenticatie met Entra ID, vereis toewijzing aan de enterprise-app en pas hetzelfde CA-beleid toe. Gebruik toegangspakketten om leveranciersgebruikers tijdgebonden toegang te verlenen tot zowel de enterprise-app als de RG-rollen; stel Groepseigenaren in als beoordelaars.
Rationale: App proxy elimineert inkomende blootstelling en centraliseert authenticatie. Entitlement management standaardiseert onboarding/offboarding en zorgt voor periodieke beoordelingen door resource-eigenaren.

Beveilig workload- en app-credentials

Vervang alle client secrets door certificaat-credentials voor service principals; gebruik voor CI/CD workload identity federation in plaats van secrets op te slaan. Voor AKS-workloads die images nodig hebben, koppel de ACR aan het cluster om AcrPull toe te kennen aan de managed identity.
Rationale: Het verwijderen van statische secrets dicht een veelvoorkomend aanvalsvector; federatie en managed identities bieden least-privilege, automatisch geroteerde toegang.

Bescherm ‘break-glass’ en monitor

Sluit twee break-glass-accounts uit van CA, maar bescherm ze met lange, willekeurige wachtwoorden die offline zijn opgeslagen. Activeer driemaandelijkse toegangsbeoordelingen en exporteer PIM- en CA-logs naar een Log Analytics-werkruimte met waarschuwingen voor afwijkende activeringen.
Rationale: ‘Break-glass’ voorkomt tenant-lockout terwijl het operationeel veilig is. Continue monitoring detecteert misbruik snel, wat de naleving en paraatheid voor incidentrespons handhaaft.

Alle domeinen · Netwerkbeveiligingsarchitectuur →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →