Microsoft AZ-500: Beveiliging van data, opslag en databases — 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

De beveiliging van data, storage en databases in Azure is gericht op het minimaliseren van vertrouwen, het isoleren van datavlakken, het overal toepassen van encryptie en het operationaliseren van ’least privilege’ met auditeerbare toegangspaden. Dit gedeelte legt uit hoe u Azure Storage, Azure SQL en Azure Cosmos DB kunt ‘hardenen’ (beveiligen), de juiste identiteits- en sleutelstrategie kunt kiezen en data-exfiltratie kunt voorkomen. Elke beschreven maatregel wordt vergezeld door de operationele redenering erachter, zodat u de configuratie in productie kunt rechtvaardigen en onderhouden.

Beveiligen van Azure Storage Accounts en datatoegang

Autorisatie en delen van storage-accounts

• Azure RBAC for Azure Storage: Geef de voorkeur aan op Azure AD gebaseerde autorisatie (Blob en Queue) via ingebouwde rollen zoals Storage Blob Data Reader/Contributor. Redenering: op tokens gebaseerde, in tijd beperkte toegang via Conditional Access, gelogd in Entra ID; vermijdt permanente accountsleutels en ondersteunt just-in-time toewijzing.
• Gedeelde sleutels (Shared keys): De primaire/secundaire sleutels van het account verlenen volledige rechten op het datavlak. Schakel het gebruik van sleutels in code uit en roteer ze regelmatig. Redenering: gedeelde sleutels zijn ‘bearer secrets’ zonder gebruikersbinding of CA; een compromittering betekent totale blootstelling van data.
• SAS-typen:
  • Service SAS: Verleent toegang met een beperkte scope tot specifieke resources (blob, file, queue, table) met permissies, IP-, protocol- en tijdslimieten. Redenering: nauwkeurig ’least privilege’ voor applicaties die geen AD-tokens kunnen gebruiken.
  • Account SAS: Breder aanvalsoppervlak (bijv. over services heen); gebruik spaarzaam. Redenering: vergroot de ‘blast radius’ als deze uitlekt.
  • User delegation SAS: Uitgegeven met behulp van Azure AD en een ‘user delegation key’ voor Blob. Redenering: koppelt aan Azure AD-identiteit en CA; superieure auditeerbaarheid en intrekking.
• Opgeslagen toegangsbeleid (Stored access policies): Definieer herbruikbare beperkingen (verloopdatum, permissies) voor SAS op containers/shares; het intrekken of bijwerken van het beleid maakt de SAS die eronder is uitgegeven ongeldig. Redenering: centrale intrekking zonder de noodzaak om tokens die in clients zijn ingebed opnieuw te genereren.

Voorbeeld: genereer een user delegation SAS voor een blob met Azure AD

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

Beveiliging per servicetype

• Blob/Queue/Table: Gebruik Azure AD RBAC waar ondersteund (Blob, Queue). Stel AllowBlobPublicAccess in op ‘false’, vereis HTTPS, en schakel versioning en soft delete in. Redenering: verwijdert anonieme blootstellingspaden en maakt herstelbaarheid mogelijk.
• Azure Files: Gebruik Azure AD Kerberos voor SMB met Entra ID (of AD DS-integratie) en dwing ’least-privilege’ permissies af op share- en bestandsniveau. Vereis SMB-encryptie. Redenering: aan identiteit gebonden toegang met transportbeveiliging over SMB; geen gedeelde sleutels in de gebruikersruimte.
• Table service: Gebruik SAS met strikte IP-/tijdbeperkingen en vermijd account-SAS. Redenering: de granulariteit op serviceniveau is minder rijk; beperk de scope agressief.

Netwerkisolatie voor alle storage-services

• Storage-firewallregels: Beperk de toegang tot geselecteerde openbare IP-bereiken, alleen wanneer Private Link niet haalbaar is. Redenering: verkleint het aanvalsoppervlak, maar verkeer loopt nog steeds via het openbare internet.
• Private endpoints: Geef de voorkeur aan Private Link for Blob, Queue, Table en Files. Map private DNS-zones naar resourcespecifieke namen. Stel openbare netwerktoegang in op ‘Disabled’. Redenering: verkeer blijft op de Azure-backbone; de identiteit van de resource wordt gevalideerd via private DNS; beperkt exfiltratie naar gelijkende services.
• Service endpoints en beleid: Als Private Link geen optie is, schakel dan service endpoints in en pas ‘service endpoint policies’ toe om uitgaand verkeer (egress) te beperken tot specifieke storage-accounts. Redenering: beperkt het verkeer, zelfs via de egress van het virtuele netwerk; beperkt het risico van het verzenden van data naar accounts die eigendom zijn van aanvallers.

Operationele instellingen om te standaardiseren

• Dwing alleen HTTPS af, met een minimum van TLS 1.2.
• Schakel toegang met gedeelde sleutels uit voor Blob en Queue als u AD gebruikt (afhankelijk van feature-ondersteuning).
• Onveranderlijkheidsbeleid (Immutability policies) op kritieke containers/shares voor wettelijke retentie en weerbaarheid tegen ransomware.

Encryptie en sleutelbeheer

Lagen van encryptie-at-rest

• Door de service beheerde sleutels (SMK): Standaard server-side encryptie beheerd door Azure. Redenering: geen operationele overhead; geschikt voor veel workloads.
• Door de klant beheerde sleutels (CMK): Sleutels in Key Vault of Managed HSM voor Storage, SQL en Cosmos DB. Redenering: geëxternaliseerde vertrouwensgrens, klantcontrole over rotatie/intrekking en bewijs voor compliance.
• Infrastructuur-encryptie (dubbele encryptie): Extra laag die afzonderlijke sleutels gebruikt. Redenering: ‘defense-in-depth’ voor het geval de encryptie van opslagmedia wordt omzeild of een cryptografische grens wordt gecompromitteerd.

Sleutelrotatie en -operaties

• SMK’s roteren automatisch; geen actie vereist.
• CMK’s roteren door een nieuwe sleutelversie te maken, wrap/unwrap-permissies te verlenen en de resource naar de nieuwste versie te laten verwijzen (of een versieloze sleutelreferentie waar ondersteund). Redenering: niet-verstorende rotatie met een auditeerbare wijziging.
• Bescherm sleutels met Key Vault soft delete en purge protection; beheer de admin-toegang via RBAC en de datavlak-toegang via toegangsbeleid of RBAC (gebruik RBAC voor Managed HSM). Redenering: voorkomt destructief sleutelverlies en dwingt ’least privilege’ af.

Voorbeeld: stel CMK in voor een storage-account

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

Encryptie-scopes

• Gebruik per-container encryptie-scopes in Storage wanneer verschillende datasets afzonderlijke sleutels vereisen. Redenering: segmenteer de ‘blast radius’ en maak gedifferentieerde sleutellevenscycli mogelijk.

Databaseplatformbeveiliging: Azure SQL en Azure Cosmos DB

Authenticatie en toegang tot Azure SQL

• Microsoft Entra-authenticatie: Maak een Azure AD-beheerder op serverniveau; gebruik ‘contained database users’ (CREATE USER FROM EXTERNAL PROVIDER). Reden: vermijdt SQL-logins/wachtwoorden en maakt Conditional Access en PIM mogelijk.
• Contained users: Identiteit bevindt zich in de database, niet in de master. Reden: vereenvoudigt geo-restore en failover zonder dat logins opnieuw moeten worden geprovisioneerd.
• Firewallregels: Vermijd brede IP-regels voor clients; geef de voorkeur aan Private Link met openbare netwerktoegang uitgeschakeld. Als IP-regels vereist zijn, beperk deze dan tot exacte adressen en automatiseer de beoordeling. Reden: verkleint het aanvalsoppervlak en vermindert de vindbaarheid via openbare eindpunten.
• Private endpoints: Routeer al het data-plane-verkeer via een VNet met private DNS. Reden: elimineert blootstelling en vereenvoudigt de preventie van data-exfiltratie.
• Authenticatiepatronen: Gebruik Active Directory Integrated (voor apparaten die lid zijn van een domein) of interactieve/device code om tokens te verkrijgen; serviceworkloads moeten managed identities gebruiken. Reden: verwijdert wachtwoorden en maakt het beheer van tokenlevensduur/beleid mogelijk.

Functies voor gegevensbescherming

• Transparent Data Encryption (TDE): Standaard ingeschakeld; versleutelt data/logs/back-ups. Reden: beschermt ‘at-rest’ media zonder applicatiewijzigingen. Gebruik TDE met CMK voor externe controle.
• Always Encrypted: Client-side encryptie voor gevoelige kolommen met sleutels in Key Vault. Reden: voorkomt dat SQL-operators of de engine de platte tekst kunnen zien; gebruik voor PII/PCI-velden.
• Dynamic Data Masking (DDM): Obfusceert queryresultaten voor niet-geprivilegieerde gebruikers. Reden: vermindert de blootstelling van data bij toevallige inzage, maar is geen beveiligingsgrens; combineer met RBAC.
• Auditing: Stuur naar Log Analytics, Event Hubs of Storage. Reden: creëert een onveranderlijk spoor voor onderzoeken en compliance.

Voorbeeld: server-level auditing inschakelen naar Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• Vulnerability Assessment (VA): Maakt basislijnen en scant schema/configuratie; exporteer naar storage; integreer met DevSecOps-gates. Reden: continue hygiëne en detectie van afwijkingen (‘drift’) met duidelijke herstelrichtlijnen.
• Threat Detection: Detecteert SQL-injectie, afwijkende logins, login vanaf een onbekende locatie, misbruik van privileges. Reden: beheerde detectie met lage operationele overhead; een aanvulling op netwerkcontroles.
• Reactie op alerts: Routeer naar Logic Apps, e-mail, SIEM. Maak playbooks voor triage, het opschorten van gebruikers, het intrekken van tokens en het aanscherpen van de firewall. Reden: een gecodificeerde reactie verkort de ‘mean time to contain’.

Beveiliging van Azure Cosmos DB

• Sleutels en tokens: Primaire/secundaire sleutels hebben hoge privileges; roteer ze regelmatig. Geef de voorkeur aan Azure AD RBAC voor data-plane-operaties met rollen zoals Cosmos DB Built-in Data Contributor/Reader. Reden: identiteitsgebonden toegang met CA en audit.
• Netwerkcontroles: IP-firewall ‘allow list’ voor noodgevallen; Private Endpoints als het standaardpad; schakel openbare toegang uit indien mogelijk. Reden: gegarandeerde padcontrole en validatie van eindpunten.
• Encryptie: Standaard ‘at rest’ versleuteld; schakel CMK in voor extra controle. Reden: voldoet aan externe crypto-eisen en scheiding van taken (‘separation of duties’).
• Diagnostische logs en metrics: Schakel DataPlaneRequests, ControlPlaneRequests en API-specifieke categorieën in (bijv. MongoRequests). Reden: end-to-end observeerbaarheid voor toegangspatronen, throttling en afwijkende verzoeken.

Monitoring, Classificatie en Exfiltratiebeheer

Geheimen en connection strings ondersteund door Key Vault

• Gebruik managed identities om geheimen/sleutels op te halen tijdens runtime; sla geheimen nooit op in code of instellingen. Reden: elimineert de wildgroei van credentials en de noodzaak voor het rouleren van geheimen in applicaties.
• App Service/Functions Key Vault-referentie

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• Geef waar mogelijk de voorkeur aan Azure AD-toegangstokens voor SQL boven op geheimen gebaseerde connection strings. Reden: sterker beleid en betere intrekkingsmogelijkheden.

Informatiebeveiliging en dataklassificatie

• Microsoft Purview Information Protection sensitivity labels: Pas labels toe met encryptie en gebruiksrechten voor documenten en e-mails; integreer met auto-labeling. Reden: persistente beveiliging die de grenzen van de opslag overschrijdt.
• SQL Information Protection (Azure SQL): Gebruik ingebouwde data discovery en classificatie, beveel labels aan voor kolommen en exporteer naar Purview. Reden: centraal beheer en consistent beleid over het gehele datalandschap.

Controles voor data-exfiltratie en veilige toegangspatronen

• Private Link eerst: Voor Storage, SQL en Cosmos DB. Schakel publieke endpoints uit. Reden: voorkomt toegang vanaf het publieke internet en dwingt af dat verkeer afkomstig is uit goedgekeurde VNets.
• Egress filtering: Gebruik Azure Firewall met FQDN-tags en DNAT-regels die alleen de vereiste Azure-endpoints toestaan; voeg service endpoint policies toe waar Private Link onpraktisch is. Reden: een allow-list voor uitgaand verkeer blokkeert datalekken naar door aanvallers beheerde endpoints.
• Resource instance rules: Sta in de Storage-firewall alleen specifieke, vertrouwde resource-instanties (bijv. een Synapse-workspace) toe. Reden: koppelt toegang aan bekende producers/consumers, niet alleen aan netwerken.
• SAS hardening: Gebruik waar mogelijk user delegation SAS, beperk tot HTTPS, beperk IP-adressen, gebruik minimale permissies en de kortst mogelijke levensduur; koppel aan stored access policies voor intrekking. Reden: vermindert misbruik van tokens en vereenvoudigt ongeldigmaking in noodgevallen.
• AKS en service endpoints: Als je afhankelijk bent van service endpoints, gebruik dan Azure CNI zodat pods VNet-IP’s krijgen en de endpoint-toegang overerven. Reden: overbrugt containerverkeer naar VNet-native controles; anders zijn de endpoints niet van toepassing op NAT-verkeer van pods.
• Logging en analytics: Schakel diagnostische logs van Storage, SQL en Cosmos DB in naar Log Analytics; maak alerts aan voor afwijkend datavolume, pieken in de uitgifte van SAS en frequente 403-fouten. Reden: vroege detectie van exfiltratiepogingen.

Praktijkscenario

Spotify moet data-exfiltratie vanuit developer-subnets en AKS-workloads naar ongeautoriseerde Storage- en SQL-endpoints voorkomen, terwijl CI/CD-pipelines integratietests moeten kunnen uitvoeren.

1. Schakel publieke netwerktoegang uit en maak Private Endpoints aan voor alle productie-Storage-accounts en Azure SQL-servers. Reden: Dwingt alle data-plane-stromen over Private Link, waardoor publieke ingress/egress wordt geëlimineerd en een strikte handhaving van de herkomst via VNets en private DNS mogelijk wordt.

2. Configureer private DNS-zones met A-records die de FQDN’s van de storage- en databaseresources mappen naar de private endpoint-IP’s; koppel alle vereiste VNets. Reden: Voorkomt DNS-lekkage naar publieke endpoints en zorgt ervoor dat clients de FQDN’s naar de bedoelde private resources resolven.

3. Voeg in de Storage-firewalls resource instance rules toe alleen voor de identiteiten van het productie-AKS-cluster en de build agent scale set; stel de standaardactie in op ‘deny’. Reden: Zelfs binnen hetzelfde VNet kunnen alleen goedgekeurde resource-identiteiten toegang krijgen tot het account, wat laterale verplaatsing en exfiltratie vanuit niet-vertrouwde workloads tegengaat.

4. Dwing het gebruik van Azure CNI af op AKS en schakel service endpoints in met service endpoint policies om dev-namespaces alleen een specifiek non-prod storage-account te laten bereiken. Reden: Dev-pods verkrijgen VNet-IP’s zodat netwerkbeleid van toepassing is; endpoint policies beperken al het niet-private verkeer strikt tot de goedgekeurde accounts.

5. Vervang shared keys door Azure AD RBAC voor Blob en Queue in de applicatiecode; waar delen onvermijdelijk is voor tests, geef een user delegation SAS uit met stored access policies en een vervaltijd van 1 uur. Reden: Aan identiteit gebonden tokens zijn auditeerbaar en intrekbaar; een kortlevende SAS minimaliseert het risico als een token wordt blootgesteld in build-logs.

6. Schakel Defender for SQL in met threat detection en Vulnerability Assessment; stuur alerts en SQL-auditlogs naar een centrale Log Analytics-workspace met geautomatiseerde Logic Apps voor triage (gebruiker uitschakelen, sessies intrekken, tijdelijke firewall deny-regel toevoegen). Reden: Beheerde detecties versnellen de indamming van SQL-injectie en afwijkende toegang, terwijl playbooks de respons standaardiseren en versnellen.

7. Gebruik Key Vault voor CMK’s die TDE en Storage encryption scopes beveiligen; schakel soft delete en purge protection in; roteer sleutels per kwartaal en werk de resource-referenties bij naar de nieuwste sleutelversie. Reden: Geëxternaliseerd cryptografisch beheer met veilige rotatie voldoet aan compliance-eisen en vermindert het risico op operationele fouten.

8. Classificeer gevoelige kolommen in Azure SQL met SQL Information Protection en onboard naar Microsoft Purview; pas MIP sensitivity labels toe voor downstream exports. Reden: Persistente labeling reist mee met data-extracten, wat misbruik beperkt en DLP-tooling in staat stelt om controles af te dwingen over verschillende tools en apparaten heen.

9. Vergrendel uitgaand verkeer met Azure Firewall tot alleen de Azure-services die nodig zijn voor build/test, gebruikmakend van FQDN-tags voor Storage en SQL en door uitgaand HTTP(S) met wildcards te weigeren. Reden: Een positief beveiligingsmodel zorgt ervoor dat verkeer alleen goedgekeurde endpoints kan bereiken, wat voorkomt dat data naar domeinen van aanvallers wordt gestuurd.

Deze reeks stappen voorkomt publieke toegang, beperkt zowel wie als wat de data kan bereiken, koppelt toegang aan identiteiten in plaats van aan geheimen, en operationaliseert monitoring en snelle respons—dit alles met behoud van de ontwikkelsnelheid door middel van afgebakende, tijdgebonden uitzonderingen.

← Beveiliging van compute · Alle domeinen · Sleutelbeheer →

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

Blader door Microsoft →