Microsoft AZ-204: Azure Authenticatie, Autorisatie en Beveiliging — Studiegids

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

Overzicht

Authenticatie en autorisatie in Azure zijn gebaseerd op het Microsoft Identity Platform, dat tokens uitgeeft aan identiteiten (gebruikers, apps, workloads) en de toegang tot API’s en resources afdwingt. Applicaties integreren via OAuth 2.0 en OpenID Connect, verkrijgen tokens met MSAL en vragen permissies aan die zijn gedeclareerd in Azure AD-appregistraties. Workloads die op Azure draaien, kunnen credentials volledig elimineren door managed identities te gebruiken en vertrouwen op Azure RBAC om services zoals Key Vault, Storage en Microsoft Graph te bereiken. Secrets management is gecentreerd rond Azure Key Vault, met een duidelijke scheiding tussen data-plane-toegang tot de kluis en management-plane-beheer, en met sterke herstelgaranties door soft delete en purge protection. Voor storage bieden Shared Access Signatures (SAS) een gescoped, in de tijd beperkte delegatie aan clients zonder de account keys bloot te stellen.

Microsoft Identity Platform, OAuth 2.0, MSAL en App Registrations

Het Microsoft Identity Platform ondersteunt meerdere OAuth 2.0 flows die geoptimaliseerd zijn voor verschillende applicatietypes:

• Authorization code flow: De standaard voor web-apps, SPA’s en native apps. Public clients moeten PKCE gebruiken om de authorization code te beschermen. Apps leiden gebruikers om naar het authorize-eindpunt, ontvangen een authorization code op de redirect-URI en wisselen deze vervolgens in bij het token-eindpunt voor een access token (en optioneel een refresh token). Voor SPA’s vervangt authorization code + PKCE de verouderde implicit flow en beperkt het het lekken van tokens.
• Client credentials flow: Gebruikt door daemons en server-to-server services zonder gebruiker. De applicatie vraagt tokens aan met een client assertion (certificaat) of een client secret. Alleen application permissions (app roles) zijn hier beschikbaar, en de meeste vereisen admin consent. Deze flow gebruikt de /.default-scope om de set van statisch geconfigureerde application permissions aan te vragen.
• Device code flow: Ontworpen voor apparaten of omgevingen zonder een ingebouwde browser. De app verkrijgt een user code en verificatie-URL van het identity platform, de gebruiker authenticeert op een apart apparaat en de app pollt het token-eindpunt. Delegated permissions zijn van toepassing omdat een gebruiker inlogt.
• Implicit grant flow: Historisch gebruikt door SPA’s om tokens rechtstreeks van het authorize-eindpunt te ontvangen. Het wordt nu afgeraden ten gunste van authorization code met PKCE. Indien gebruikt, is een redirect-URI nog steeds vereist tijdens de appregistratie.

MSAL (Microsoft Authentication Library) biedt consistente token-acquisitie over verschillende talen en platformen heen. Public client-applicaties (desktop, mobiel, SPA) gebruiken

undefined

en

undefined

om tokens te verkrijgen en te cachen; native apps gebruiken ook

undefined

voor de device code flow en

undefined

voor het inwisselen van de authorization code in confidential client-contexten. Confidential clients (web-apps/API’s/daemons) verkrijgen tokens met

undefined

bij gebruik van client credentials en

undefined

voor OBO-scenario’s waarbij een API downstream API’s aanroept met de gedelegeerde context van een gebruiker.

Token caching is een integraal onderdeel van MSAL: het slaat access en refresh tokens op, geïndexeerd op account, client en scope, waardoor

undefined

onnodige interactieve prompts kan vermijden. Web-apps en API’s die in meerdere instanties draaien, moeten de token cache persisteren en beschermen met een gedeelde, versleutelde opslag (bv. een distributed cache met correcte encryptie at rest en in transit). Cache-serialisatie-hooks in MSAL maken veilige persistentie mogelijk. Scopes identificeren de permissies die een app aanvraagt. Vraag voor delegated permissions de minimale, resource-specifieke scopes aan (bv.

undefined

). Vraag voor client credentials de resource-gebaseerde

undefined

aan, wat overeenkomt met de application permissions die statisch aan de app zijn toegekend (bv.

undefined

). Gebruik incremental consent om scopes progressief aan te vragen en frictie te verminderen.

Azure AD-appregistraties definiëren de applicatie-identiteit, credentials, redirect-URI’s en permissies. Delegated permissions vereisen een ingelogde gebruiker en kunnen vaak door gebruikers zelf worden goedgekeurd voor hun eigen data; application permissions worden aan de app zelf verleend en vereisen bijna altijd dat een admin toestemming geeft (consent), omdat ze tenant-breed of zeer breed van toepassing zijn. Apps die API’s exposen, declareren scopes (voor delegated permissions) en app roles (voor application permissions) onder “Expose an API”. Configureer single-tenant- of multi-tenant-toegang afhankelijk van de trust boundaries, en gebruik certificaten in plaats van client secrets voor sterkere credentials en eenvoudigere rotatie.

Microsoft Graph gebruikt dezelfde token-uitgifte. Authenticeer met MSAL gericht op de Graph-resource en vraag least-privilege scopes aan. Veelvoorkomende eindpunten zijn:

undefined

voor het gebruikersprofiel met delegated tokens (bv.

undefined

)

undefined

en

undefined

voor directory-objecten (vereist de juiste delegated of application permissions zoals

undefined

of

undefined

)

undefined

of

undefined

voor SharePoint/OneDrive-operaties Vraag bij het gebruik van client credentials de

undefined

-scope aan en zorg ervoor dat er admin consent is voor de vereiste application permissions. Kies de juiste authority (tenant-specifiek versus common/organizations) om te bepalen waar gebruikers kunnen inloggen en waar tokens kunnen worden uitgegeven (‘gemint’).

Beheerde Identiteiten en Veilige Toegang tot Azure Resources, plus Key Vault-verwijzingen

Beheerde identiteiten voor Azure-resources elimineren geheimen doordat Azure de service principal-referenties kan beheren. Door het systeem toegewezen beheerde identiteiten zijn 1:1 gekoppeld aan een resource (App Service, Function App, VM, VMSS, Logic App, etc.) en delen diens levenscyclus; wanneer de resource wordt verwijderd, wordt de identiteit ook verwijderd. Door de gebruiker toegewezen beheerde identiteiten worden aangemaakt als zelfstandige Azure-resources die aan meerdere compute-resources gekoppeld kunnen worden en onafhankelijk van de levenscyclus van een specifieke workload bestaan. Dit model ondersteunt het hergebruik van identiteiten en de scheiding van taken.

Om met een beheerde identiteit toegang te krijgen tot Azure-resources, kent u de juiste Azure RBAC-rol toe op de correcte scope:

• Voor het Azure Storage-datavlak met Azure AD, wijs rollen toe zoals Storage Blob Data Reader/Contributor op het niveau van een storage account, container, of RG/abonnement.
• Voor Key Vault (RBAC-datavlakmodel), wijs rollen toe zoals Key Vault Secrets User of Key Vault Crypto Officer.
• Voor Microsoft Graph via applicatiemachtigingen kunnen beheerde identiteiten downstream API’s alleen aanroepen nadat een app-registratie is gekoppeld. Gebruik workload identity federation of configureer de enterprise app-machtigingen en beheerderstoestemming indien nodig.

Gebruik tijdens runtime de Instance Metadata Service (IMDS) op VM’s of het door App Service beheerde eindpunt om tokens te verkrijgen; SDK’s zoals Azure Identity’s DefaultAzureCredential zullen automatisch het eindpunt voor beheerde identiteiten gebruiken wanneer dit beschikbaar is. Dit elimineert de noodzaak om geheimen op te slaan en ondersteunt rotatie door het platform.

Key Vault-verwijzingen in App Service en Azure Functions maken het mogelijk om geheimen veilig op te halen in applicatie-instellingen zonder codewijzigingen. Gebruik in de waarde van een app-instelling de verwijzingssyntaxis @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version}). Het platform lost de verwijzing op met behulp van de beheerde identiteit van de app bij het opstarten en vernieuwt deze periodiek. Zorg ervoor dat de beheerde identiteit de ‘Get’-machtiging voor geheimen heeft via Key Vault-toegangsbeleid of de rol Key Vault Secrets User bij gebruik van het RBAC-datavlakmodel. Key Vault-verwijzingen zijn ideaal voor configuratiewaarden die nooit in platte tekst in de app-configuratieopslag mogen worden bewaard en verwijderen de logica voor het omgaan met geheimen uit de applicatiecode.

Azure Key Vault: Geheimen, Sleutels, Certificaten en Toegangsbeheer

Azure Key Vault slaat drie soorten objecten op:

• Geheimen: Ondoorzichtige tekenreeksen zoals wachtwoorden, connection strings of API-sleutels. Versiebeheer is van toepassing; clients voeren doorgaans Get- en Set-operaties uit.
• Sleutels: Cryptografische sleutels (RSA, EC) die worden gebruikt voor sign/verify-, encrypt/decrypt- en wrap/unwrap-operaties. Het sleutelmateriaal wordt beschermd door de door HSM ondersteunde service; clients roepen crypto-operaties aan via de service in plaats van het private sleutelmateriaal te exporteren.
• Certificaten: X.509-objecten met levenscyclusbeheer, optioneel geïntegreerd met partner-CA’s. Certificaten worden gematerialiseerd als een certificaat plus een corresponderend geheim (PFX) en, optioneel, een beheerde sleutel.

Voorlopig verwijderen (soft delete) is standaard ingeschakeld, waardoor verwijderde objecten gedurende een bewaarperiode behouden blijven. Schakel beveiliging tegen opschonen (purge protection) in om onomkeerbare verwijdering binnen de bewaarperiode te voorkomen en om herstelgaranties af te dwingen (vaak een bewaarvereiste van 90 dagen). Combineer voorlopig verwijderen en beveiliging tegen opschonen om te voldoen aan strikte herstelbeleidsregels. Beveilig daarnaast de netwerktoegang tot de vault met private endpoints en schakel openbare netwerktoegang uit waar mogelijk.

Toegangsbeheer kan gebruikmaken van het verouderde vault-toegangsbeleid of Azure RBAC voor het datavlak. Toegangsbeleid wordt per vault geconfigureerd en kent expliciet machtigingen (Get, List, Set, Sign, Wrap) toe aan principals; ze worden niet overgeërfd en kunnen op grote schaal operationeel zwaar worden. Het RBAC-datavlakmodel gebruikt Azure-rollen (bijv. Key Vault Administrator, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Crypto Officer) en ondersteunt scoping op abonnements-, resourcegroep- of vault-niveau, met auditing geïntegreerd in Azure RBAC. Kies één model; als RBAC is ingeschakeld voor het datavlak, wordt het toegangsbeleid genegeerd. Operaties op het beheervlak (het aanmaken/bijwerken van de vault) gebruiken altijd Azure RBAC.

Integreer Key Vault met applicaties met behulp van Azure SDK’s (bijv. SecretClient, KeyClient, CertificateClient) en DefaultAzureCredential. Geef de voorkeur aan beheerde identiteiten voor authenticatie, vermijd het insluiten van referenties en implementeer beleid voor nieuwe pogingen (retry) en beperking (throttling) bij het aanroepen van de Vault API’s.

Azure Storage SAS en Opgeslagen Toegangsbeleid

Shared Access Signatures (SAS) delegeren fijnmazige, in de tijd beperkte toegang tot Azure Storage zonder accountsleutels bloot te geven:

• User Delegation SAS (alleen Blob): Ondersteund door Azure AD. De applicatie verkrijgt een user delegation key van de Blob-service met behulp van Azure AD-credentials en maakt vervolgens SAS-tokens voor clients. Dit is de veiligste aanpak voor gebruikersgerichte scenario’s, omdat het gebruik van accountsleutels wordt vermeden en het aansluit bij op rollen gebaseerde autorisatie.
• Service SAS: Gekoppeld aan een specifieke resource (blob, container, queue message, table entity, file). Ondertekend met een accountsleutel. Ondersteunt permissies zoals lezen, schrijven, toevoegen, aanmaken, verwijderen, weergeven, onveranderlijkheid instellen en tags, afhankelijk van de service.
• Account SAS: Breedste scope over meerdere services (Blob, Queue, Table, File) en resourcetypes. Gebruik spaarzaam vanwege de grote impactradius (blast radius).

SAS-tokens bevatten beperkingen zoals een vervaltijd (se), starttijd (st), permissies (sp), IP-bereiken (sip), toegestane protocollen (spr), ondertekende resource (sr) en, wanneer gekoppeld aan een opgeslagen toegangsbeleid, een ondertekende identifier (si). Volg het principe van minimale rechten (least privilege) door alleen de noodzakelijke permissies te verlenen, vervaltijden kort te houden en HTTPS af te dwingen (spr=https). Geef waar mogelijk de voorkeur aan een User Delegation SAS; gebruik anders een Service SAS met een opgeslagen toegangsbeleid voor intrekking.

Opgeslagen toegangsbeleid (stored access policies) bevindt zich op containers, file shares, queues of tables en definieert een herbruikbare set van beperkingen (permissies, start, vervaltijd). Verwijs bij het aanmaken van een SAS naar het beleid via de identifier. Dit maakt centrale intrekking of het aanscherpen van de scope mogelijk zonder alle SAS-tokens opnieuw te hoeven uitgeven; het bijwerken of verwijderen van het beleid heeft onmiddellijk effect op alle SAS-tokens die eraan gekoppeld zijn. Roteer accountsleutels regelmatig als Service of Account SAS wordt gebruikt, en monitor het gebruik via diagnostische instellingen en Azure Monitor-logs.

Praktijkscenario

Adobe is bezig met de uitrol van een multi-tenant mediaportaal op Azure. Klanten loggen in met hun eigen Microsoft Entra ID-tenants, uploaden grote mediabestanden rechtstreeks naar Blob storage en volgen de verwerkingsstatus. De oplossing moet het opslaan van secrets vermijden, permissies centraliseren en de herstelbaarheid van secrets garanderen voor ten minste 90 dagen.

1. Registreer applicaties in Microsoft Entra ID:

   • Maak een SPA voor de portal-UI en een confidential client voor de backend-API. Stel API-scopes bloot voor gedelegeerde toegang en definieer app-rollen voor achtergrondtaken. Configureer de SPA om authorization code + PKCE te gebruiken met exacte redirect-URI’s. Dit zorgt ervoor dat elke client de juiste OAuth-flow volgt en dwingt grenzen af voor toestemming volgens het principe van minimale rechten.

2. Implementeer MSAL in de SPA en backend:

   • De SPA verkrijgt tokens voor de backend-API met behulp van AcquireTokenInteractive/AcquireTokenSilent met incrementele toestemming. De backend gebruikt AcquireTokenOnBehalfOf om Microsoft Graph aan te roepen en het basisprofiel van de ingelogde gebruiker te lezen. Dit behoudt de gebruikerscontext end-to-end en minimaliseert prompts door middel van token caching.

3. Activeer door het systeem toegewezen managed identities op App Service (API) en Azure Functions (media processors):

   • Wijs de rol Storage Blob Data Contributor toe op de mediacontainer en Key Vault Secrets User op de kluis. Managed identities elimineren de wildgroei van secrets en staan het platform toe om credentials automatisch te roteren, terwijl veilige toegang tot Storage en Key Vault via Azure RBAC mogelijk wordt gemaakt.

4. Configureer Azure Key Vault met een RBAC-datavlak, soft delete en purge protection:

   • Sla ondertekeningscertificaten voor backend-assertion, API-sleutels van derden en eventuele verbindings-secrets op die niet door AAD kunnen worden vervangen. Dwing purge protection en soft delete af om herstelbaarheid voor 90 dagen te garanderen. RBAC vereenvoudigt audits en schaalt beter over omgevingen heen in vergelijking met toegangsbeleid per kluis.

5. Gebruik Key Vault-referenties voor configuratie:

   • Verwijs naar secrets in de app-instellingen van App Service en Functions met @Microsoft.KeyVault(SecretUri=…). Het platform lost de waarden op en vernieuwt ze met de managed identity, waardoor codewijzigingen overbodig worden en wordt voorkomen dat secrets in platte tekst in de configuratie worden opgeslagen.

6. Delegeer directe uploads vanuit de browser met SAS:

   • De backend geeft User Delegation SAS-tokens uit voor kortstondige, write-only toegang tot een specifiek blob-pad, beperkt door IP en HTTPS. Maak voor operationele batchtools een Service SAS die is gekoppeld aan een opgeslagen toegangsbeleid op de container, zodat tokens centraal kunnen worden ingetrokken door het beleid bij te werken of te verwijderen. Dit maakt client-uploads met hoge doorvoersnelheid mogelijk zonder accountsleutels bloot te geven en ondersteunt intrekking in noodgevallen.

7. Integreer Microsoft Graph minimaal:

   • Vraag https://graph.microsoft.com/User.Read aan in de SPA voor profielweergave en gebruik https://graph.microsoft.com/.default in de backend indien applicatiepermissies vereist zijn (met voorafgaande toestemming van een beheerder). Het gebruik van /.default zorgt ervoor dat de backend centraal verleende applicatiepermissies respecteert en vermijdt het aanvragen van te veel scopes tijdens runtime.

Dit ontwerp gebruikt authorization code + PKCE om de SPA te beveiligen, OBO om de gebruikerscontext downstream te behouden, managed identities en RBAC om secrets te elimineren, Key Vault met sterke herstelgaranties, Key Vault-referenties voor configuratiehygiëne, Graph met scopes volgens het principe van minimale rechten, en SAS met opgeslagen toegangsbeleid voor veilige, intrekbare client-uploads.

← Azure Containeroplossingen · Alle domeinen · Azure API Management →

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

Blader door Microsoft →