Microsoft AZ-500: Sleutelbeheer, cryptografie en certificaten — 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

Sleutelbeheer op Azure draait om Azure Key Vault en Azure Managed HSM. Deze services bieden veilige opslag van cryptografisch materiaal, consistente API’s en auditeerbare operaties die de basis vormen voor encryptie at rest, in transit en op de applicatielaag. Het operationele doel is om het beheer van sleutels te scheiden van de applicatie-runtime, de ‘blast radius’ (impactradius) te minimaliseren met gerichte autorisatie en netwerkconfiguratie, en herstelbaarheid en rotatie af te dwingen om het risico van langlevende geheimen te verminderen.

Azure Key Vault en Managed HSM Architectuur en Autorisatie

Azure Key Vault-architectuur

• Samenstelling van de service: multi-tenant front-ends, regionale partities voor het datavlak, isolatie per tenant en door Azure AD ondersteunde authenticatie. Sleutels zijn ofwel software-beveiligd (Standard-laag) of HSM-beveiligd (Premium-laag). Geheimen en certificaten zijn altijd software-beveiligd.
• Lagen: Standard (softwaresleutels) voor algemeen gebruik en kostenefficiëntie; Premium (door HSM ondersteunde sleutels) wanneer FIPS 140-2 Level 2/3-equivalente bescherming of een toegewezen HSM-grens voor sleutelmateriaal vereist is. Kies Premium voor wettelijke vereisten of bij het gebruik van sleutels met “RSA-HSM” of “EC-HSM”.
• Voorlopig verwijderen en beveiliging tegen opschonen: Voorlopig verwijderen (soft delete) staat altijd aan met een configureerbare bewaarperiode (7–90 dagen, meestal 90). Beveiliging tegen opschonen (purge protection), indien ingeschakeld, voorkomt permanente verwijdering van de vault of objecten totdat de bewaarperiode is verstreken, zelfs door gebruikers met hoge privileges. Operationele redenering: schakel beveiliging tegen opschonen in op elke vault die door de klant beheerde sleutels (CMK) ondersteunt. Zonder dit zou een onbedoelde of kwaadwillige opschoning afhankelijke data (bijv. opslag of databases die met die sleutel zijn versleuteld) onherstelbaar kunnen maken.
• Herstel: Verwijderde vault-objecten kunnen worden opgevraagd en hersteld; herstel op vault-niveau wordt ondersteund. Back-ups produceren versleutelde blobs die kunnen worden hersteld naar compatibele vaults in dezelfde Azure-regio en -cloud. Redenering: exporteer periodiek back-ups van sleutels en beveilig deze afzonderlijk; test herstelsessies om de RTO te valideren.

Autorisatiemodel

• Machtigingsmodellen: Vault-toegangsbeleid (verouderd) versus Azure RBAC (aanbevolen).
  • Toegangsbeleid: gedefinieerd per vault; kent granulaire machtigingen toe voor sleutels, geheimen en certificaten. Het beste wanneer u zeer strikte, objecttype-specifieke runtimerechten nodig heeft voor een kleine set principals.
  • Azure RBAC: stel het ‘Permission model’ van de vault in op ‘Azure role-based access control’ om RBAC-datavlak-rollen te gebruiken. Voordelen: scope op abonnements-, resourcegroep- of vault-niveau; PIM-geschikte toewijzingen; gecentraliseerd beheer en auditing. Aanbevolen voor nieuwe implementaties en voor administratieve handelingen.
• Ingebouwde vault-rollen (voorbeelden): Key Vault Administrator (volledig beheer), Key Vault Crypto Officer (sleutelbeheer maar geen toegangsbeleid), Key Vault Secrets Officer, Key Vault Certificates Officer, Key Vault Reader. Operationele richtlijnen:
  • Gebruik RBAC (bijv. Key Vault Administrator) bij het delegeren van de configuratie van toegangsmodellen en netwerk-ACL’s.
  • Gebruik een toegangsbeleid of een datavlak-RBAC-rol zoals Key Vault Certificates Officer voor het met minimale rechten invoegen/verwijderen van certificaten in een enkele vault.
• Ontwerp van de scope: Geef de voorkeur aan het toewijzen van RBAC op de scope van de vault om overprivilegiëring te vermijden. Gebruik de resourcegroep-scope alleen wanneer meerdere vaults identieke operateurteams delen; vermijd toewijzingen op abonnementsniveau voor runtime-toegang.

Managed HSM

• Architectuur en beveiligingsdomeinen: Managed HSM is een single-tenant, FIPS 140-2 Level 3 gevalideerd HSM-cluster per klant. Een beveiligingsdomein beschermt de overdraagbaarheid van het sleutelmateriaal van het cluster; voor back-up/herstel tussen clusters is een quorum van privésleutels van het beveiligingsdomein vereist. Redenering: genereer en deponeer domeinsleutels bij verschillende beheerders; test een herstel naar een DR HSM.
• Rollenmodel: Geïntegreerd met Azure RBAC. Rollen omvatten Managed HSM Administrator, Crypto Officer, Crypto User en Reader. Scheiding van taken: beheerders beheren het cluster; crypto officers beheren sleutels; crypto users gebruiken sleutels voor operaties.
• Hoge beschikbaarheid: Regionaal redundant met meerdere HSM-partities en een door een SLA ondersteunde service; zoneredundantie is beschikbaar in ondersteunde regio’s. Voor disaster recovery tussen regio’s, vertrouw op back-ups + beveiligingsdomein.
• Gebruiksscenario’s: Betalingsverwerking, ondertekening van code, key wrapping voor envelope-encryptie en gereguleerde workloads die Level 3 HSM-grenzen vereisen.

Objecten en levenscyclus: sleutels, geheimen, certificaten en rotatie

Sleutels, geheimen, certificaten

• Sleutels: Voor cryptografische operaties (ondertekenen, verifiëren, wrappen/unwrappen, versleutelen/ontsleutelen). Kies sleuteltype/-grootte op basis van de sterkte van het algoritme en prestaties (bijv. RSA 3072/4096 voor compliance, of ECC P-256/P-384 voor prestaties).
• Geheimen: Willekeurige bytes/strings zoals wachtwoorden, connection strings en API-tokens. Niet gebruikt voor cryptografische operaties.
• Certificaten: X.509 met privésleutels. Opgeslagen als zowel een certificaatobject als een corresponderend geheim (PFX/PEM). Nuttig voor TLS/MTLS en de levenscyclus van code signing.

Levenscyclusoperaties en rotatie

• Versiebeheer: Elke ‘set’- of ‘import’-actie genereert een onveranderlijke (immutable) versie. Applicaties moeten verwijzen naar geheimen met versie voor deterministisch gedrag, of naar versie-loze URI’s om automatisch de nieuwste versie op te halen, afhankelijk van de behoeften van het change management.
• Rotatiestrategieën:
  • Sleutels: Geef de voorkeur aan versie-loze sleutel-URI’s voor Azure-services die dit ondersteunen (bijv. Storage, SQL TDE, door AKV beheerde geheimen). Roteer door een nieuwe versie toe te voegen; services maken automatisch opnieuw verbinding (rebind) indien ondersteund. Als een service een vastgepinde versie vereist, automatiseer dan een herconfiguratiestap. Dwing rotatie af met AKV-rotatiebeleid en alarmering.
  • Geheimen: Roteer via Azure Automation, Functions of Logic Apps, getriggerd door Event Grid-notificaties, of gebruik provider-native rotatie (bijv. het roteren van SAS of databasewachtwoorden). Vermijd statische geheimen met een lange levensduur door ze waar mogelijk te vervangen door managed identities.
  • Certificaten: Definieer certificaatbeleid met ’lifetime actions’ om automatisch te vernieuwen vóór de vervaldatum; gebruik geïntegreerde ‘issuers’ voor een handsfree vernieuwing.

Certificaatbeheer

• Import/generatie: Importeer bestaande PFX/PEM (met privésleutel) of genereer een CSR en laat Key Vault de uitgifte voltooien met een geconfigureerde CA.
• Automatische vernieuwing en issuers: Configureer issuers zoals DigiCert, GlobalSign of een enterprise Microsoft CA via Key Vault. Schakel automatische vernieuwing in met notificatie- en vernieuwingsdrempels.
• Applicatie-integratie:
  • App Service en Functions: gebruik Key Vault-referenties met een managed identity; het platform synchroniseert geroteerde geheimen automatisch.
  • Application Gateway/WAF: verwijs naar de secret-ID van het certificaat in Key Vault; de Gateway pikt nieuwe versies automatisch op.
  • AKS: mount certificaten via de Secrets Store CSI-driver en de Azure Key Vault-provider.

Voorbeeld van RBAC-toewijzing voor certificaatoperaties met minimale rechten (least privilege):

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Netwerkbeveiliging en service-integratie

Key Vault-netwerken

• Firewallregels: Stel in op ‘Selected networks’ om te beperken tot goedgekeurde bronnen. Reden: voorkomt verkeer afkomstig van het internet, zelfs met geldige tokens.
• Virtual network service endpoints: Sta verkeer toe vanaf specifieke subnets zonder privé-IP’s. Eenvoudig in te schakelen en vermindert de blootstelling (exposure). Gebruik wanneer snelle isolatie nodig is en er geen DNS-wijzigingen vereist zijn.
• Private endpoints: Wijs een privé-IP toe aan de vault in uw VNet voor volledig private connectiviteit. Blokkeer openbare netwerktoegang. Reden: de sterkste controle op data-exfiltratie, vereist in omgevingen met een hoge vertrouwensgraad (high-trust) en wanneer uitgaand internetverkeer beperkt is.
• Vertrouwde services: Met ‘Allow trusted Microsoft services’ kunnen specifieke Azure-services de vault bereiken ondanks netwerkbeperkingen. Vereist voor scenario’s zoals het scannen van Storage-encryptiesleutels tijdens rotatie. Schakel dit beperkt in en documenteer de afhankelijkheden.

Customer-managed keys (CMK) en sleutel-URI’s

• Ondersteunde services: Azure Storage, SQL Database (TDE), Synapse, Databricks, encryptie van AKS-geheimen ‘at rest’, App Configuration, Event Hubs, Service Bus en Managed Disks via een Disk Encryption Set.
• Sleutel-URI-strategie:
  • Versie-loze URI’s: Geef de voorkeur wanneer de service automatische ‘rebind’ bij nieuwe sleutelversies ondersteunt; maakt naadloze rotatie mogelijk zonder service-updates.
  • URI’s met versie: Vereist door sommige services; automatiseer een update van de serviceconfiguratie die gekoppeld is aan rotatie-events.
• Rotatiepatronen:
  • Gefaseerde rotatie: Maak een nieuwe sleutelversie aan; valideer dat de service er toegang toe heeft; monitor op fouten; schakel vervolgens optioneel oudere versies uit na een veilige periode.
  • Event-driven: Gebruik Event Grid bij ‘key-new-version’-events om validatie- of herconfiguratieworkflows voor services te triggeren.

Integratie van envelope encryption

• Azure-services gebruiken lokaal een data encryption key (DEK) (bijv. AES-256) en een Key Encryption Key (KEK) in Key Vault/HSM om de DEK te ‘wrappen’. Zorg operationeel voor de beschikbaarheid van de KEK en netwerktoegang, omdat verlies of geblokkeerde toegang serviceoperaties kan stilleggen.

Voorbeeld: een DEK wrappen met een AKV-sleutel

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Cryptografie, opties voor data-at-rest en goede praktijken voor secrets

Kernconcepten van cryptografie

• Symmetrische encryptie: Eén sleutel gebruikt voor versleutelen/ontsleutelen (bijv. AES-GCM/CTR). Snel; ideaal voor grote hoeveelheden data.
• Asymmetrische encryptie: Publieke/private sleutelparen (RSA/ECC) gebruikt voor sleuteluitwisseling en handtekeningen. Trager; ideaal voor het vestigen van vertrouwen en het ‘wrappen’ van DEK’s.
• Hashing: Eenrichtings-digest (bijv. SHA-256). Voor integriteit; geen encryptie.
• Ondertekening: Private sleutel produceert handtekening; publieke sleutel verifieert. Onweerlegbaarheid en integriteit.
• Envelope-encryptie: Combineer asymmetrische KEK met symmetrische DEK voor prestaties en isolatie van sleutelbeheer.

Azure Disk Encryption en opslagencryptie

• Standaardencryptie van Managed Disks: Server-side encryption (SSE) met door het platform beheerde sleutels (PMK). Minimale operationele overhead.
• CMK met Disk Encryption Set (DES): Gebruik een DES die verwijst naar een Key Vault- of Managed HSM-sleutel voor schijven, snapshots en images. Reden: gecentraliseerd beheer van de levenscyclus van sleutels en intrekking; voldoet aan compliance-eisen voor klantbeheer.
• ADE (Azure Disk Encryption): In-guest BitLocker (Windows) of dm-crypt (Linux). Gebruik wanneer je encryptie op OS-niveau nodig hebt, ‘key protectors’ op schijfniveau die aan een domein zijn gekoppeld, of wanneer bestaande compliance-mandaten dit vereisen. Operationele afweging: hogere complexiteit, beheer van extensies en mogelijke impact op de provisioning van VM’s.
• Dubbele encryptie:
  • Schijven: Combineer SSE met PMK op de infrastructuurlaag plus CMK via DES om twee onafhankelijke encryptielagen te realiseren.
  • Storage-accounts: Gebruik ’encryption scopes’ met afzonderlijke CMK’s per container/workload; combineer met infrastructuur-encryptie waar beschikbaar voor twee lagen.
• Encryption scopes (Azure Storage): Definieer scopes per container of per blob met verschillende CMK’s om het risico van tenants/workloads te isoleren en gerichte rotatie mogelijk te maken zonder brede impact.

Goede praktijken voor secrets en operationele procedures

• Managed identities: Gebruik door het systeem of door de gebruiker toegewezen ‘managed identities’ voor Azure-resources om tokens voor Key Vault en services te verkrijgen, waardoor ingebedde credentials worden geëlimineerd. Configureer RBAC of toegangsbeleid zo beperkt mogelijk.
• Scannen van secrets: Schakel Microsoft Defender for DevOps, GitHub Advanced Security secret scanning en repository-beveiligingen in. Integreer met pull requests om bekende patronen van credentials te blokkeren.
• Pipelines en IaC: Gebruik Key Vault-taakintegraties in Azure Pipelines en op OIDC-gebaseerde ‘federated credentials’ in GitHub Actions om persisterende secrets te vermijden. Print geen secrets in logs; maskeer outputs. Roteer gelekt materiaal onmiddellijk.
• Applicatieontwerp: Geef waar veilig de voorkeur aan versieloze verwijzingen; cache minimaal en handel 401/403-fouten af door tokens opnieuw te verkrijgen en secrets opnieuw op te halen om rotatie-gebeurtenissen te ondersteunen.

Diepgaande analyse van certificaatbeheer

• Uitgifte op basis van beleid: Definieer het onderwerp, SANs, sleutelgebruik, EKU’s, sleuteltype/-grootte en instellingen voor sleutelhergebruik in een Key Vault-certificaatbeleid. Reden: een consistente TLS-houding over alle omgevingen heen.
• Integratie van de uitgever: Configureer een CA-profiel in Key Vault. Voor een private PKI, integreer met Microsoft ADCS via een aangepaste uitgever of gebruik de Certificate Connector van Azure Key Vault. Publieke CA’s maken geautomatiseerde verlenging mogelijk zonder private sleutels buiten AKV bloot te stellen.
• Automatische verlengingsoperaties: Gebruik levenscyclusacties (bv. verlengen 60 dagen voor vervaldatum; notificeren na 90 dagen). Stem operationeel gezien de verlengingsvensters af op change freezes en zorg ervoor dat afhankelijke services automatisch synchroniseren.
• Applicatiegebruik: Haal op als een secret (PFX/PEM) of koppel via een verwijzing in platformservices. Geef de voorkeur aan platform-native koppelingen (App Service, Application Gateway) voor een zero-downtime rollover bij nieuwe versies. Voor Kubernetes, mount via CSI om rolling restarts te activeren bij rotatie.

Praktijkscenario

Siemens AG moet IoT-telemetrie in Azure beveiligen, sterk sleutelbeheer afdwingen voor data-at-rest en de rotatie van certificaten en secrets automatiseren voor een wereldwijd gedistribueerde vloot.

1. Kluizen en HSM-grenzen vaststellen

• Creëer regionale Premium Key Vaults voor applicatie-secrets/certificaten en een Managed HSM voor KEK-operaties.
• Reden: Premium-kluizen maken HSM-ondersteunde sleutels mogelijk wanneer nodig; Managed HSM biedt Level 3-garantie en onafhankelijk sleutelbeheer voor wrapping-operaties.

2. Herstelbaarheid en vangrails afdwingen

• Schakel beveiliging tegen definitief verwijderen (purge protection) in op alle kluizen en Managed HSM; stel de retentie voor voorlopig verwijderen (soft-delete) in op 90 dagen. Pas Azure Policy toe om kluizen zonder purge protection te auditen/weigeren.
• Reden: Voorkomt catastrofaal dataverlies door definitieve verwijderingen; beleid zorgt ervoor dat er geen drift kan optreden.

3. Autorisatie centraliseren met RBAC

• Stel de kluizen in op het Azure RBAC-permissiemodel. Wijs Key Vault Administrator toe aan een klein platformteam via PIM; wijs Key Vault Secrets Officer toe aan app-teams op het kluisniveau; wijs Managed HSM Crypto Officer toe aan security engineers.
• Reden: RBAC + PIM leidt tot least privilege, tijdsgebonden escalatie en consistente auditing. Scheiding van taken voorkomt dat beheerders sleutels kunnen gebruiken.

4. Netwerk vergrendelen met private endpoints

• Creëer private endpoints in hub-VNets; schakel openbare netwerktoegang uit. Schakel “trusted services” alleen in voor Storage-accounts die CMK gebruiken.
• Reden: Private endpoints elimineren publieke blootstelling en blokkeren paden voor data-exfiltratie, terwijl noodzakelijke service-naar-kluis-stromen behouden blijven.

5. CMK en encryptiestrategie implementeren

• Voor Storage, definieer encryptiebereiken per workload met versieloze KEK-URI’s in de Premium-kluis; voor Managed Disks, gebruik Disk Encryption Sets met CMK uit de HSM. Schakel encryptie op infrastructuurniveau in voor dubbele encryptie.
• Reden: Sleutels per workload verkleinen de blast radius; versieloze URI’s maken naadloze rotatie mogelijk; dubbele encryptie voldoet aan strenge compliance-eisen.

6. Sleutel- en secret-rotatie automatiseren

• Configureer AKV-sleutelrotatiebeleid (bv. jaarlijkse vervaldatum, roteren na 9 maanden) en Event Grid-notificaties die validatie-jobs activeren. Gebruik managed identities in services; verwijder statische credentials.
• Reden: Voorspelbare, geautomatiseerde rotatie vermindert het risico van langlopende sleutels en secrets; managed identities vervangen kwetsbare gedeelde secrets.

7. Certificaten operationaliseren

• Gebruik Key Vault-certificaatbeleid met DigiCert-uitgeverintegratie; stel automatische verlenging in op 60 dagen voor de vervaldatum. Koppel certificaten via verwijzing in Application Gateway en App Service.
• Reden: Geautomatiseerde verlenging voorkomt storingen en vermijdt handmatige sleutelverwerking; platformkoppelingen pikken nieuwe versies op zonder herimplementaties.

8. Valideren en monitoren

• Schakel diagnostische logs van Key Vault en Managed HSM in naar Log Analytics; alarmeer bij ongeautoriseerde pogingen, firewall-weigeringen en gebeurtenissen voor bijna-verlopen certificaten. Voer driemaandelijkse hersteltests uit voor kluis- en HSM-back-ups met behulp van het security domain quorum.
• Reden: Continue monitoring detecteert misconfiguraties of aanvallen snel; hersteltests garanderen herstelbaarheid onder druk.

← Beveiliging van data · Alle domeinen · Beheer van beveiligingspostuur en governance →

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

Blader door Microsoft →