Microsoft AZ-500: Daten-, Speicher- und Datenbanksicherheit — Lernleitfaden

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

Teil des Microsoft Azure Security Engineer Associate AZ-500 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Die Sicherheit von Azure-Daten, -Speichern und -Datenbanken konzentriert sich auf die Minimierung von Vertrauen, die Isolierung von Datenebenen, die durchgängige Verschlüsselung und die Operationalisierung des Prinzips der geringsten Rechte (Least Privilege) mit auditierbaren Zugriffspfaden. Dieser Abschnitt erklärt, wie Sie Azure Storage, Azure SQL und Azure Cosmos DB härten, die richtige Identitäts- und Schlüsselstrategie auswählen und Datenexfiltration verhindern. Jede beschriebene Kontrollmaßnahme wird von der betrieblichen Begründung begleitet, damit Sie die Konfiguration im Produktivbetrieb rechtfertigen und aufrechterhalten können.

Absicherung von Azure Storage Accounts und Datenzugriff

Autorisierung und Freigabe von Speicherkonten

• Azure RBAC für Azure Storage: Bevorzugen Sie die auf Azure AD basierende Autorisierung (Blob und Queue) über integrierte Rollen wie Storage Blob Data Reader/Contributor. Begründung: Token-basierter, zeitlich begrenzter Zugriff über Conditional Access, protokolliert in Entra ID; vermeidet dauerhafte Kontoschlüssel und unterstützt die Just-in-Time-Zuweisung.
• Gemeinsam genutzte Schlüssel (Shared Keys): Die primären/sekundären Schlüssel des Kontos gewähren volle Rechte auf der Datenebene. Deaktivieren Sie die Verwendung von Schlüsseln im Code und rotieren Sie diese häufig. Begründung: Gemeinsam genutzte Schlüssel sind Bearer-Secrets ohne Benutzerbindung oder Conditional Access (CA); eine Kompromittierung bedeutet die vollständige Offenlegung der Daten.
• SAS-Typen:
  • Service SAS: Gewährt bereichsbezogenen Zugriff auf bestimmte Ressourcen (Blob, File, Queue, Table) mit Berechtigungen, IP-, Protokoll- und Zeitlimits. Begründung: Präzises Prinzip der geringsten Rechte für Anwendungen, die keine AD-Token verwenden können.
  • Account SAS: Breitere Angriffsfläche (z. B. dienstübergreifend); sparsam verwenden. Begründung: Erweitert den Explosionsradius (Blast Radius) bei einem Leak.
  • User Delegation SAS: Wird unter Verwendung von Azure AD und einem Benutzerdelegierungsschlüssel für Blob ausgestellt. Begründung: Bindet an die Azure AD-Identität und Conditional Access (CA); überlegene Auditierbarkeit und Widerrufbarkeit.
• Gespeicherte Zugriffsrichtlinien (Stored Access Policies): Definieren wiederverwendbare Einschränkungen (Ablauf, Berechtigungen) für SAS auf Containern/Freigaben; das Widerrufen oder Aktualisieren der Richtlinie macht die darunter ausgestellten SAS ungültig. Begründung: Zentraler Widerruf, ohne in Clients eingebettete Token neu generieren zu müssen.

Beispiel: Generieren einer User Delegation SAS für einen Blob mit 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

Dienstsicherheit nach Typ

• Blob/Queue/Table: Verwenden Sie Azure AD RBAC, wo unterstützt (Blob, Queue). Setzen Sie AllowBlobPublicAccess auf false, erzwingen Sie HTTPS, aktivieren Sie Versionierung und Soft Delete (vorläufiges Löschen). Begründung: Entfernt anonyme Zugriffspfade und ermöglicht die Wiederherstellbarkeit.
• Azure Files: Verwenden Sie Azure AD Kerberos für SMB mit Entra ID (oder AD DS-Integration) und erzwingen Sie Freigabe-/Dateiberechtigungen nach dem Prinzip der geringsten Rechte. Erzwingen Sie SMB-Verschlüsselung. Begründung: Identitätsgebundener Zugriff mit Transportsicherheit über SMB; keine gemeinsam genutzten Schlüssel im Benutzerbereich.
• Table Service: Verwenden Sie SAS mit strengen IP-/Zeiteinschränkungen und vermeiden Sie Account SAS. Begründung: Die Granularität auf Dienstebene ist nicht so fein; legen Sie den Geltungsbereich aggressiv fest.

Netzwerkisolation für alle Speicherdienste

• Speicher-Firewallregeln: Beschränken Sie den Zugriff auf ausgewählte öffentliche IP-Bereiche nur dann, wenn Private Link nicht realisierbar ist. Begründung: Reduziert die Angriffsfläche, aber der Datenverkehr läuft immer noch über das öffentliche Internet.
• Private Endpunkte: Bevorzugen Sie Private Link für Blob, Queue, Table und Files. Ordnen Sie private DNS-Zonen ressourcenspezifischen Namen zu. Setzen Sie den öffentlichen Netzwerkzugriff auf Disabled (Deaktiviert). Begründung: Der Datenverkehr verbleibt im Azure-Backbone; die Ressourcenidentität wird über privates DNS validiert; mindert die Exfiltration zu ähnlich aussehenden Diensten.
• Dienstendpunkte und -richtlinien: Wenn Private Link keine Option ist, aktivieren Sie Dienstendpunkte und wenden Sie Dienstendpunktrichtlinien an, um den ausgehenden Datenverkehr (Egress) auf bestimmte Speicherkonten zu beschränken. Begründung: Schränkt den Datenverkehr auch bei Egress aus dem virtuellen Netzwerk ein; begrenzt das Risiko, Daten an Konten im Besitz von Angreifern zu senden.

Zu standardisierende Betriebseinstellungen

• Nur HTTPS erzwingen, mindestens TLS 1.2.
• Zugriff über gemeinsam genutzte Schlüssel für Blob und Queue deaktivieren, wenn AD verwendet wird (abhängig von der Feature-Unterstützung).
• Unveränderlichkeitsrichtlinien (Immutability Policies) für kritische Container/Freigaben zur Einhaltung gesetzlicher Aufbewahrungsfristen und zur Resilienz gegen Ransomware.

Verschlüsselung und Schlüsselverwaltung

Ebenen der Verschlüsselung ruhender Daten (Encryption at Rest)

• Von Diensten verwaltete Schlüssel (Service-Managed Keys, SMK): Standardmäßige serverseitige Verschlüsselung, die von Azure verwaltet wird. Begründung: Kein betrieblicher Aufwand; für viele Workloads geeignet.
• Vom Kunden verwaltete Schlüssel (Customer-Managed Keys, CMK): Schlüssel in Key Vault oder Managed HSM für Storage, SQL und Cosmos DB. Begründung: Externalisierte Vertrauensgrenze, kundenseitige Kontrolle über Rotation/Widerruf und Compliance-Nachweise.
• Infrastrukturverschlüsselung (doppelte Verschlüsselung): Zusätzliche Schicht, die separate Schlüssel verwendet. Begründung: Tiefenverteidigung (Defense-in-Depth), falls die Verschlüsselung der Speichermedien umgangen oder eine Kryptogrenze kompromittiert wird.

Schlüsselrotation und -operationen

• SMK rotieren automatisch; keine Aktion erforderlich.
• CMK werden rotiert, indem eine neue Schlüsselversion erstellt, Wrap-/Unwrap-Berechtigungen erteilt und die Ressource auf die neueste Version (oder eine versionslose Schlüsselreferenz, falls unterstützt) umgestellt wird. Begründung: Unterbrechungsfreie Rotation mit auditierbarer Änderung.
• Schützen Sie Schlüssel mit Key Vault Soft Delete (vorläufiges Löschen) und Purge Protection (Löschschutz); steuern Sie den Admin-Zugriff über RBAC und den Zugriff auf die Datenebene über Zugriffsrichtlinien oder RBAC (für Managed HSM, verwenden Sie RBAC). Begründung: Verhindert den destruktiven Verlust von Schlüsseln und setzt das Prinzip der geringsten Rechte durch.

Beispiel: CMK für ein Speicherkonto festlegen

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

Verschlüsselungsbereiche (Encryption Scopes)

• Verwenden Sie Verschlüsselungsbereiche pro Container im Storage, wenn unterschiedliche Datensätze separate Schlüssel erfordern. Begründung: Segmentiert den Explosionsradius (Blast Radius) und ermöglicht differenzierte Lebenszyklen für Schlüssel.

Sicherheit von Datenbankplattformen: Azure SQL und Azure Cosmos DB

Azure SQL-Authentifizierung und -Zugriff

• Microsoft Entra-Authentifizierung: Erstellen Sie einen Azure AD-Administrator auf Serverebene; verwenden Sie eigenständige Datenbankbenutzer (CREATE USER FROM EXTERNAL PROVIDER). Begründung: Vermeidet SQL-Logins/Passwörter und ermöglicht Conditional Access und PIM.
• Eigenständige Benutzer: Die Identität befindet sich in der Datenbank, nicht in der Master-Datenbank. Begründung: Vereinfacht die geografische Wiederherstellung und das Failover, ohne dass Logins neu bereitgestellt werden müssen.
• Firewall-Regeln: Vermeiden Sie weitreichende Client-IP-Regeln; bevorzugen Sie Private Link bei deaktiviertem öffentlichen Netzwerkzugriff. Wenn IP-Regeln erforderlich sind, beschränken Sie diese auf exakte Adressen und automatisieren Sie die Überprüfung. Begründung: Verringert die Angriffsfläche und reduziert die Auffindbarkeit über öffentliche Endpunkte.
• Private Endpunkte: Leiten Sie den gesamten Datenverkehr der Datenebene über ein VNet mit privatem DNS. Begründung: Beseitigt die öffentliche Exposition und vereinfacht die Verhinderung von Datenexfiltration.
• Authentifizierungsmuster: Verwenden Sie Active Directory Integrated (für in die Domäne eingebundene Geräte) oder interaktiven/Gerätecode, um Token zu erhalten; Service-Workloads sollten verwaltete Identitäten (Managed Identities) verwenden. Begründung: Entfernt Passwörter und ermöglicht die Verwaltung von Token-Lebensdauern/Richtlinien.

Datenschutzfunktionen

• Transparent Data Encryption (TDE): Standardmäßig aktiviert; verschlüsselt Daten/Protokolle/Backups. Begründung: Schützt ruhende Daten (at-rest) auf Speichermedien ohne Anwendungsänderungen. Verwenden Sie TDE mit CMK für externalisierte Kontrolle.
• Always Encrypted: Clientseitige Verschlüsselung für sensible Spalten mit Schlüsseln in Key Vault. Begründung: Verhindert, dass SQL-Operatoren oder die Engine Klartext sehen; für PII/PCI-Felder verwenden.
• Dynamic Data Masking (DDM): Verschleiert Abfrageergebnisse für nicht privilegierte Benutzer. Begründung: Reduziert die zufällige Offenlegung von Daten, ist aber keine Sicherheitsgrenze; mit RBAC kombinieren.
• Überwachung (Auditing): An Log Analytics, Event Hubs oder Storage senden. Begründung: Erstellt einen unveränderlichen Prüfpfad für Untersuchungen und Compliance.

Beispiel: Aktivieren der Überwachung auf Serverebene für 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

• Schwachstellenbewertung (Vulnerability Assessment, VA): Erstellt Baselines und scannt Schema/Konfiguration; Export in Storage; Integration in DevSecOps-Gates. Begründung: Kontinuierliche Hygiene und Drift-Erkennung mit klaren Anleitungen zur Behebung.
• Bedrohungserkennung (Threat Detection): Erkennt SQL-Injection, anomale Anmeldungen, Anmeldung von unbekanntem Standort, missbräuchliche Berechtigungen. Begründung: Verwaltete Erkennung mit geringem Betriebsaufwand; ergänzt Netzwerkkontrollen.
• Reaktion auf Warnungen (Alert Response): Weiterleitung an Logic Apps, E-Mail, SIEM. Erstellen Sie Playbooks für die Triage, Benutzersperrung, Token-Widerruf und Verschärfung der Firewall-Regeln. Begründung: Kodifizierte Reaktion reduziert die durchschnittliche Zeit bis zur Eindämmung (Mean Time to Contain).

Sicherheit von Azure Cosmos DB

• Schlüssel und Token: Primäre/sekundäre Schlüssel sind hochprivilegiert; rotieren Sie sie regelmäßig. Bevorzugen Sie Azure AD RBAC für Operationen auf der Datenebene mit Rollen wie Cosmos DB Built-in Data Contributor/Reader. Begründung: Identitätsgebundener Zugriff mit CA und Überwachung.
• Netzwerksteuerungen: IP-Firewall-Positivliste für Notfälle; Private Endpoints als Standardpfad; öffentlichen Zugriff nach Möglichkeit deaktivieren. Begründung: Garantierte Pfadkontrolle und Endpunktvalidierung.
• Verschlüsselung: Standardmäßig im Ruhezustand (at rest) verschlüsselt; aktivieren Sie CMK für zusätzliche Kontrolle. Begründung: Erfüllt externe Krypto-Anforderungen und die Trennung von Aufgaben (Separation of Duties).
• Diagnoseprotokolle und Metriken: Aktivieren Sie DataPlaneRequests, ControlPlaneRequests und API-spezifische Kategorien (z. B. MongoRequests). Begründung: End-to-End-Beobachtbarkeit für Zugriffsmuster, Drosselung (Throttling) und anomale Anfragen.

Überwachungs-, Klassifizierungs- und Exfiltrationskontrollen

Durch Key Vault gesicherte Geheimnisse und Verbindungszeichenfolgen

• Verwenden Sie verwaltete Identitäten, um Geheimnisse/Schlüssel zur Laufzeit abzurufen; speichern Sie niemals Geheimnisse im Code oder in den Einstellungen. Begründung: eliminiert die unkontrollierte Verbreitung von Anmeldeinformationen und die Notwendigkeit der Geheimnisrotation in Apps.
• Key Vault-Referenz für App Service/Functions

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

• Bevorzugen Sie nach Möglichkeit Azure AD-Zugriffstoken für SQL gegenüber geheimnisbasierten Verbindungszeichenfolgen. Begründung: stärkere Richtlinien und Widerrufsmöglichkeiten.

Informationsschutz und Datenklassifizierung

• Microsoft Purview Information Protection-Vertraulichkeitsbezeichnungen: Wenden Sie Bezeichnungen mit Verschlüsselung und Nutzungsrechten für Dokumente und E-Mails an; integrieren Sie diese mit der automatischen Bezeichnung. Begründung: dauerhafter Schutz über Speichergrenzen hinaus.
• SQL Information Protection (Azure SQL): Nutzen Sie die integrierte Datenerkennung und -klassifizierung, empfehlen Sie Bezeichnungen für Spalten und exportieren Sie diese nach Purview. Begründung: zentrale Governance und konsistente Richtlinien über die gesamte Datenlandschaft hinweg.

Kontrollen zur Datenexfiltration und sichere Zugriffsmuster

• Private Link zuerst: Für Storage, SQL und Cosmos DB. Deaktivieren Sie öffentliche Endpunkte. Begründung: verhindert den Zugriff aus dem öffentlichen Internet und erzwingt, dass der Datenverkehr aus genehmigten VNets stammt.
• Egress-Filterung: Verwenden Sie Azure Firewall mit FQDN-Tags und DNAT-Regeln, die nur erforderliche Azure-Endpunkte zulassen; fügen Sie Dienstendpunktrichtlinien hinzu, wo Private Link unpraktisch ist. Begründung: Positivlisten (Allow-Listing) für ausgehenden Verkehr blockieren Datenlecks zu von Angreifern kontrollierten Endpunkten.
• Ressourceninstanzregeln: Erlauben Sie für die Storage-Firewall nur bestimmten vertrauenswürdigen Ressourceninstanzen (z. B. einem Synapse-Workspace) den Zugriff. Begründung: bindet den Zugriff an bekannte Produzenten/Konsumenten, nicht nur an Netzwerke.
• SAS-Härtung: Verwenden Sie nach Möglichkeit User Delegation SAS, beschränken Sie sie auf HTTPS, schränken Sie IPs ein, verwenden Sie minimale Berechtigungen und kürzeste Lebensdauern; binden Sie sie an gespeicherte Zugriffsrichtlinien für den Widerruf. Begründung: reduziert den Missbrauch von Token und vereinfacht die Notfall-Invalidierung.
• AKS und Dienstendpunkte: Wenn Sie sich auf Dienstendpunkte verlassen, verwenden Sie Azure CNI, damit Pods VNet-IPs erhalten und den Endpunktzugriff erben. Begründung: überbrückt den Container-Verkehr zu VNet-nativen Kontrollen; andernfalls gelten Endpunkte nicht für NAT-übersetzten Pod-Verkehr.
• Protokollierung und Analyse: Aktivieren Sie Diagnoseprotokolle für Storage, SQL und Cosmos DB in Log Analytics; erstellen Sie Warnungen für anomales Datenvolumen, sprunghafte SAS-Ausstellung und häufige 403-Fehler. Begründung: Früherkennung von Exfiltrationsversuchen.

Praktisches Problemszenario

Spotify muss die Datenexfiltration aus Entwickler-Subnetzen und AKS-Workloads zu nicht autorisierten Storage- und SQL-Endpunkten verhindern und gleichzeitig CI/CD-Pipelines die Durchführung von Integrationstests ermöglichen.

1. Deaktivieren Sie den öffentlichen Netzwerkzugriff und erstellen Sie Private Endpoints für alle Produktions-Storage-Konten und Azure SQL-Server. Begründung: Erzwingt, dass alle Datenflüsse auf der Datenebene über Private Link laufen, was den öffentlichen Ein- und Ausgang eliminiert und eine strikte Herkunftsdurchsetzung über VNets und privates DNS ermöglicht.

2. Konfigurieren Sie private DNS-Zonen mit A-Records, die die FQDNs der Speicher- und Datenbankressourcen auf die privaten Endpunkt-IPs abbilden; verknüpfen Sie alle erforderlichen VNets. Begründung: Verhindert DNS-Leakage zu öffentlichen Endpunkten und stellt sicher, dass Clients zu den beabsichtigten privaten Ressourcen auflösen.

3. Fügen Sie in Storage-Firewalls Ressourceninstanzregeln nur für die Identitäten des Produktions-AKS-Clusters und des Build-Agent-Scale-Sets hinzu; setzen Sie die Standardaktion auf „Verweigern“ (Deny). Begründung: Selbst innerhalb desselben VNets können nur genehmigte Ressourcenidentitäten auf das Konto zugreifen, was die laterale Bewegung und Exfiltration von nicht vertrauenswürdigen Workloads verhindert.

4. Erzwingen Sie Azure CNI auf AKS und aktivieren Sie Dienstendpunkte mit Dienstendpunktrichtlinien, um Dev-Namespaces den Zugriff nur auf ein dediziertes Nicht-Produktions-Speicherkonto zu gestatten. Begründung: Dev-Pods erhalten VNet-IPs, sodass Netzwerkrichtlinien angewendet werden können; Endpunktrichtlinien beschränken jeglichen nicht-privaten Verkehr strikt auf genehmigte Konten.

5. Ersetzen Sie Shared Keys durch Azure AD RBAC für Blob und Queue im Anwendungscode; wo die gemeinsame Nutzung für Tests unvermeidbar ist, stellen Sie User Delegation SAS mit gespeicherten Zugriffsrichtlinien und einer Ablaufzeit von 1 Stunde aus. Begründung: Identitätsgebundene Token sind prüfbar und widerrufbar; kurzlebige SAS minimieren das Risiko, falls ein Token in Build-Protokollen offengelegt wird.

6. Aktivieren Sie Defender for SQL mit Bedrohungserkennung und Schwachstellenanalyse (Vulnerability Assessment); leiten Sie Warnungen und SQL-Audit-Protokolle an einen zentralen Log Analytics-Workspace mit automatisierten Logic Apps zur Triage weiter (Benutzer deaktivieren, Sitzungen widerrufen, temporäre Firewall-Verweigerungsregel hinzufügen). Begründung: Verwaltete Erkennungen beschleunigen die Eindämmung von SQL-Injection und anomalem Zugriff, während Playbooks die Reaktion standardisieren und beschleunigen.

7. Verwenden Sie Key Vault für CMK zum Schutz von TDE und Storage-Verschlüsselungsbereichen (Encryption Scopes); aktivieren Sie Soft Delete und Purge Protection; rotieren Sie die Schlüssel vierteljährlich und aktualisieren Sie die Ressourcenreferenzen auf die neueste Schlüsselversion. Begründung: Externalisierte kryptografische Kontrolle mit sicherer Rotation erfüllt Compliance-Anforderungen und reduziert das Risiko von Bedienungsfehlern.

8. Klassifizieren Sie sensible Spalten in Azure SQL mit SQL Information Protection und binden Sie sie in Microsoft Purview ein; wenden Sie MIP-Vertraulichkeitsbezeichnungen für nachgelagerte Exporte an. Begründung: Persistente Bezeichnungen bleiben bei Datenextrakten erhalten, was den Missbrauch einschränkt und es DLP-Tools ermöglicht, Kontrollen über verschiedene Tools und Geräte hinweg durchzusetzen.

9. Sperren Sie den ausgehenden Verkehr (Egress) mit Azure Firewall auf nur die Azure-Dienste, die für Build/Test erforderlich sind, indem Sie FQDN-Tags für Storage und SQL verwenden und ausgehenden Wildcard-HTTP(S)-Verkehr verweigern. Begründung: Ein positives Sicherheitsmodell stellt sicher, dass der Verkehr nur genehmigte Endpunkte erreichen kann, und verhindert, dass Daten an von Angreifern kontrollierte Domänen gesendet werden.

Diese Abfolge verhindert den öffentlichen Zugriff, schränkt ein, wer und was auf Daten zugreifen kann, bindet den Zugriff an Identitäten anstatt an Geheimnisse und operationalisiert die Überwachung sowie eine schnelle Reaktion – all dies unter Beibehaltung der Entwicklergeschwindigkeit durch bereichsbezogene, zeitlich begrenzte Ausnahmen.

← Sicherheit für Compute · Alle Domänen · Schlüsselverwaltung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →