Microsoft AZ-500: Sicherheit für Compute, Container und Endpunkte — 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

Dieser Abschnitt bietet eine Betriebsreferenz für die Absicherung von Azure Compute, Containern und Endpunkten über IaaS und PaaS hinweg. Er konzentriert sich darauf, wie Schutzmaßnahmen konfiguriert werden, warum sie wichtig sind und wie sie mit Azure-nativen Kontrollen konsistent durchgesetzt werden können.

Compute- und Endpunktsicherheit

Die Plattformsicherheitsfunktionen und Verschlüsselungsoptionen für Azure VMs sind fundamental.

• Secure Boot, vTPM und Trusted Launch: Trusted Launch härtet Gen2-VMs, indem es UEFI Secure Boot und ein virtuelles TPM (vTPM) aktiviert. Secure Boot verhindert unsignierte Bootloader/Rootkits. Das vTPM bietet einen manipulationssicheren Speicher für Schlüssel (z. B. für BitLocker) und unterstützt Measured Boot, sodass die Plattform die Integrität der OS-Boot-Kette bestätigen (attestieren) kann. Im Betrieb sollten Sie Trusted Launch bei der Bereitstellung aktivieren und per Richtlinie erzwingen, um sicherzustellen, dass alle neuen VMs hardwarebasierte Integritätsprüfungen erhalten, ohne dass Administratoren statische BIOS/UEFI-Einstellungen verwalten müssen.

• Confidential VMs: Verwenden Sie auf AMD SEV-SNP oder Intel TDX basierende Confidential-VM-Serien (z. B. DCasv5/DCadsv5), um den VM-Arbeitsspeicher zu verschlüsseln und eine Attestierung zu ermöglichen. Dies schützt Workloads vor einem bösartigen Host/Hypervisor und vor Seitenkanalangriffen. Im Betrieb wählen Sie Confidential-SKUs für Szenarien mit hochsensiblen Daten in der Nutzung (Data-in-Use), integrieren die Attestierung in Ihre Deployment-Pipeline und bevorzugen flüchtige Betriebssystemdatenträger (Ephemeral OS Disks), wenn Sie schnelle Neubereitstellungen ohne Datenpersistenz benötigen.

• Optionen für die Datenträgerverschlüsselung:

  • Azure Disk Encryption (ADE): BitLocker (Windows) oder DM-Crypt (Linux) innerhalb des Gastbetriebssystems, Schlüssel in Key Vault (BEK/KEK). Nützlich, wenn Sie gastbasierte Krypto-Domänen, Compliance-Prüfungen innerhalb des Betriebssystems oder vTPM-gebundenes BitLocker nutzen müssen. Erfordert einen Agenten und Lifecycle-Operationen für den Zustand der Erweiterung.
  • Serverseitige Verschlüsselung (SSE) mit vom Kunden verwalteten Schlüsseln (CMK): Verschlüsselung auf Speicherebene für verwaltete Datenträger unter Verwendung von Schlüsseln in Key Vault oder Managed HSM. Keine Gast-Agenten, vollständige Plattformabdeckung (Datenträger, Snapshots, Images), minimaler Betriebsaufwand. Empfohlener Standard für die meisten Anwendungsfälle; kombinieren Sie dies mit Trusted Launch oder Confidential VMs für eine stärkere tiefengestaffelte Verteidigung (Defense-in-Depth).

• Microsoft Defender for Servers:

  • Plan 1: Microsoft Defender for Endpoint (MDE) für EDR/Endpunktschutz auf Servern. Wählen Sie diesen Plan, wenn Sie bereits ausgereifte Tools für Schwachstellen- und Konfigurationsmanagement haben und hauptsächlich EDR benötigen.
  • Plan 2: Fügt agentenbasierte/agentenlose Schwachstellenbewertung, Just-in-Time (JIT) VM-Zugriff, adaptive Anwendungssteuerung, adaptive Netzwerkhärtung und Dateiintegritätsüberwachung (FIM) hinzu. Wählen Sie diesen Plan, wenn Sie eine plattformgesteuerte Reduzierung der Angriffsfläche und eine aktive Governance wünschen, ohne mehrere Tools miteinander verbinden zu müssen.
  • Endpunktschutz: Stellen Sie MDE über VM-Erweiterungen oder Arc für Nicht-Azure-Server bereit, um Telemetrie, Manipulationsschutz und Reaktions-Playbooks über hybride Umgebungen hinweg zu standardisieren.
  • Schwachstellenbewertung: Nutzen Sie das Signal von MDE Threat & Vulnerability Management oder den integrierten Scanner (z. B. Qualys), um CVEs zu inventarisieren, nach Ausnutzbarkeit zu priorisieren und das Patching zu orchestrieren. Im Betrieb sollten Sie zuerst eine Baseline für kritische, dem Internet zugewandte Server erstellen und die Behebung an Wartungsfenster koppeln.
  • Dateiintegritätsüberwachung: Verfolgen Sie Änderungen an sensiblen Dateien/Registrierungsschlüsseln, um verdächtige Manipulationen zu erkennen und Compliance-Anforderungen zu erfüllen. Konfigurieren Sie bereichsbezogene Überwachungspfade, um Störgeräusche (Noise) zu vermeiden, und leiten Sie Warnungen an Ihr SIEM weiter.

• Reduzierung der Angriffsfläche mit Defender for Cloud:

  • Just-in-Time VM-Zugriff: Schließt eingehenden RDP/SSH-Zugriff. Administratoren fordern zeitlich begrenzten Zugriff an; Defender öffnet die NSG- oder Azure Firewall-Regel und protokolliert die Aktivität. Das Ergebnis ist eine drastisch reduzierte Angriffsfläche mit auditierbaren Ausnahmen.
  • Adaptive Anwendungssteuerung: Lernt normale Prozesse und erstellt Positivlisten (Allowlists) (AppLocker unter Windows, Audit-Regeln für Linux). Dies blockiert nicht genehmigte Binärdateien und Skripte – besonders wirksam gegen dateilose Angriffe oder LOLBin-Angriffe.
  • Adaptive Netzwerkhärtung: Nutzt Datenverkehrsanalysen und Threat Intelligence, um eine Verschärfung von NSG-Regeln vorzuschlagen. Etablieren Sie einen Rhythmus aus Überprüfung und Anwendung, um die Angriffsfläche iterativ zu verkleinern und gleichzeitig Ausfälle zu vermeiden.
  • Gastkonfiguration (Guest Configuration): Azure Policy für die Überwachung/Korrektur innerhalb des Gastbetriebssystems (Windows und Linux) über einen Agenten oder Azure Arc. Verwenden Sie dies, um Betriebssystem-Baselines, Kennwortrichtlinien und CIS-konforme Einstellungen durchzusetzen, wenn Sie einen nachweisbaren Konfigurationszustand benötigen und nicht nur den Sicherheitsstatus der Plattform.

PaaS-Compute: App Service und Functions

Secure-by-Default-Muster reduzieren die Angriffsfläche von PaaS.

• Azure App Service:

  • Authentifizierung/Autorisierung: Aktivieren Sie die App Service-Authentifizierung, um die Authentifizierung an Microsoft Entra ID oder andere Anbieter auszulagern. Verwenden Sie Easy Auth für standardmäßige OIDC/OAuth2-Flows und erzwingen Sie dann die Anmeldung auf allen Routen, um unauthentifizierten Zugriff zu unterbinden.
  • Zugriffsbeschränkungen: Erlauben oder verweigern Sie Datenverkehr nach IP/CIDR, Service-Tags oder Datenverkehr aus virtuellen Netzwerken über private Endpunkte. Pflegen Sie separate Regeln für den scm-Endpunkt und den App-Endpunkt, um Ihre Deployment-Ebene unabhängig zu schützen.
  • Private Endpunkte: Stellen Sie die App über eine private IP in Ihrem VNet bereit und deaktivieren Sie optional den öffentlichen Zugriff. Verwenden Sie private DNS-Zonen und beschränken Sie ausgehende Abhängigkeiten mit VNet-Integration und einer zentralen Egress-Firewall.
  • Verwaltete Identitäten: Bevorzugen Sie system- oder benutzerseitig zugewiesene Identitäten für den Zugriff auf Key Vault, Storage und andere Dienste. Dies eliminiert eingebettete Geheimnisse und ermöglicht eine zentralisierte Rollenzuweisung und Schlüsselrotation.

• Azure Functions:

  • Schlüsselverwaltung: Functions verwenden Funktionsschlüssel, Hostschlüssel und den Hauptschlüssel. Rotieren Sie Schlüssel regelmäßig und speichern Sie extern genutzte Schlüssel in Key Vault oder ersetzen Sie Schlüssel durch geeignete OAuth-Flows, falls möglich.
  • Netzwerkintegration: Verwenden Sie private Endpunkte für den eingehenden Zugriff auf die Function-App und regionale VNet-Integration für ausgehende Kontrollen. Beschränken Sie das von Functions genutzte Storage-Konto nur auf ausgewählte Netzwerke und fügen Sie den privaten Endpunkt der Function zu den erlaubten Netzwerken hinzu.
  • Identitäten: Verwenden Sie verwaltete Identitäten für die Service-zu-Service-Authentifizierung anstelle von Schlüsseln oder Verbindungszeichenfolgen. Setzen Sie das Prinzip der geringsten Rechte (Least Privilege) mit eng gefassten RBAC-Zuweisungen um.
  • Deployment-Kontrollen: Erzwingen Sie nur FTPS, deaktivieren Sie die Standardauthentifizierung für die scm-Site, beschränken Sie scm-IPs und verwenden Sie „Run From Package“, um unveränderliche Deployments sicherzustellen. Integrieren Sie CI/CD mit Workload Identity Federation, um langlebige Geheimnisse zu eliminieren.

Kubernetes- und Container-Sicherheit

Härten Sie Cluster und Lieferketten (Supply Chains) durchgängig.

• AKS-Identität und -Autorisierung:

  • Microsoft Entra-Integration: Aktivieren Sie verwaltetes AAD für AKS, um kubectl mit Entra-Token und -Gruppen zu authentifizieren. Dies zentralisiert den Benutzerlebenszyklus und MFA/Conditional Access.
  • Kubernetes RBAC: Weisen Sie Entra-Benutzer/-Gruppen Kubernetes-Rollen und -Rollenbindungen zu, um das Prinzip der geringsten Rechte auf Namespace-Ebene umzusetzen.
  • Azure RBAC für Kubernetes: Verwenden Sie integrierte Rollen (z. B. Azure Kubernetes Service RBAC Viewer/Admin), wenn Azure RBAC Kubernetes-API-Aktionen direkt autorisieren soll. Dies vereinheitlicht die Autorisierung und Überwachung mit der Azure-Steuerungsebene.

• AKS-Netzwerk und Datenschutz:

  • Netzwerkrichtlinien: Erzwingen Sie Pod-zu-Pod- und Pod-zu-Service-Datenverkehr mit Azure NPM oder Calico. Standardmäßig verweigern und erforderlichen Egress explizit erlauben; Policy-as-Code verhindert laterale Bewegungen.
  • Private Cluster: Machen Sie den API-Server privat und nur über private Endpunkte zugänglich. Kombinieren Sie dies mit Azure Bastion/Private Link und einer Firewall-Egress-Strategie (NAT Gateway + UDRs), um die Verwaltungsebene vom Internet fernzuhalten.

• Sicherheit für Container Registry (ACR):

  • RBAC: Weisen Sie AcrPull Workloads zu, die nur Images pullen müssen, und AcrPush an Build-Pipelines; vermeiden Sie die überprivilegierte Rolle „Owner“. AcrPull und AcrPush entsprechen dem Prinzip der geringsten Rechte.
  • Inhaltsvertrauen und Signierung: Signieren Sie Images mit cosign und erzwingen Sie die Überprüfung mit Admission Control (Gatekeeper + Ratify), bevor Pods starten. Dies schützt vor manipulierten Images.
  • Image-Scanning: Aktivieren Sie Microsoft Defender for Cloud, um ACR bei Push/Import und nach einem Zeitplan zu scannen. Blockieren Sie die Bereitstellung von Images mit kritischen, ungepatchten CVEs mithilfe von Admission Policies.
  • Quarantäne-Muster: Leiten Sie neue Images an ein Quarantäne-Repo oder -Tag weiter, führen Sie Scans und Richtlinienprüfungen durch und stufen Sie sie dann nach der Genehmigung durch erneutes Taggen hoch.
  • Privater Zugriff: Deaktivieren Sie den öffentlichen Netzwerkzugriff und verwenden Sie private Endpunkte sowie Firewall-Regeln für die Registry. Verbinden Sie AKS mit ACR über eine Rollenzuweisung auf Ressourcenebene anstelle einer Verzeichnisrolle.

Kurzes Beispiel, um ACR mit der verwalteten Identität des Clusters an AKS anzubinden:

az aks update -g rg-aks -n myAKS --attach-acr myAcrName

• Microsoft Defender for Containers: Stellt einen Datenebenen-Sensor in AKS bereit, überwacht Kubernetes-Audit-Logs und Laufzeitsignale und korreliert diese mit den Ergebnissen von Image-Scans. Es erkennt verdächtige exec-Befehle in Pods, Krypto-Mining, exponierte Dashboards und riskante Operationen auf der Steuerungsebene. Aktivieren Sie die automatische Bereitstellung und verbinden Sie Warnungen zur Triage mit Ihrem SIEM/SOAR.

Governance, Richtlinien und Durchsetzung

Konsistente Kontrolle erfordert Richtlinien bei der Bereitstellung und zur Laufzeit.

• Azure Policy für Compute und Datenträger:
  • Erstellung von VMs ohne Trusted Launch oder ohne SSE mit CMK verweigern.
  • VM-Erweiterungen für Endpunktschutz mithilfe von DeployIfNotExists erzwingen, um erforderliche Agents automatisch zu installieren.
  • Konformität der Gastkonfiguration prüfen; Abweichungen (Drift) nach einem Zeitplan beheben.

Kurzer Richtlinien-Ausschnitt, um eine erforderliche VM-Erweiterung bereitzustellen, falls sie fehlt:

"policyRule": {
  "if": { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "name": "MDE.Windows"
    }
  }
}

• Kubernetes Admission Controls:
  • Das Azure Policy Add-on für AKS verwendet Gatekeeper (OPA), um Pod-Spezifikationen bei der Zulassung (Admission) zu bewerten. Erzwingen Sie Regeln wie „Nur von ACR pullen“, „Keine privilegierten Container“ und „Imagesignaturen erfordern“.
  • Pflegen Sie separate Initiativen für Baseline (unverzichtbar) und verstärkt (sensible Namespaces), um eine schrittweise Härtung zu ermöglichen.

Kurze Gatekeeper-Constraint zur Einschränkung von Registries:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-acr-only
spec:
  parameters:
    repos:
    - myacr.azurecr.io/

• Operative Kadenz:
  • Erkennen: Nutzen Sie Empfehlungen von Defender for Cloud und Workload-Warnungen als Signale für Abweichungen (Drift) und Bedrohungen.
  • Entscheiden: Triage nach Geschäftsauswirkungen und Ausnutzbarkeit durchführen; Verantwortliche über Tags zuweisen.
  • Durchsetzen: Wandeln Sie erfolgreiche Pilotprojekte in Deny-Richtlinien/Admission-Constraints um; messen Sie blockierte Versuche, um Schatten-IT zu erkennen.

Praktisches Problemszenario

Adobe Inc. migriert einen Microservice für Zahlungsabwicklungen zu Azure. Die Sicherheitsanforderungen schreiben vor: keine öffentliche Erreichbarkeit, nur signierte Images und zeitlich begrenzter Admin-Zugriff auf Legacy-VMs während der Umstellung (Cutover).

1. Die AKS-Steuerungsebene privat machen und den Egress-Verkehr sperren.

• Begründung: Ein privater AKS-API-Server entfernt die Verwaltungsebene aus dem Internet. Ein NAT Gateway plus Azure Firewall mit expliziten ausgehenden Regeln stellt sicher, dass Workloads nur genehmigte Endpunkte erreichen (ACR, Key Vault, Microsoft-Paket-Repos).

2. Signierte Images erzwingen und Registries einschränken.

• Begründung: Konfigurieren Sie Gatekeeper mit Constraints, die nur Images von myacr.azurecr.io zulassen und von Ratify validierte cosign-Signaturen erfordern. Dies verhindert die Ausführung manipulierter oder nicht vertrauenswürdiger Images und schließt ein großes Risiko in der Lieferkette (Supply Chain).

3. ACR mit privaten Endpunkten und Rollen nach dem Prinzip der geringsten Rechte absichern.

• Begründung: Deaktivieren Sie den öffentlichen Netzwerkzugriff und stellen Sie ACR über einen privaten Endpunkt im AKS-VNet bereit. Weisen Sie der verwalteten Identität von AKS nur die Rolle AcrPull zu; weisen Sie der Build-Pipeline AcrPush zu. Dies folgt dem Prinzip der geringsten Rechte und eliminiert die Abhängigkeit vom Internet.

4. Defender for Containers und das Scannen von ACR-Images aktivieren.

• Begründung: Kontinuierliches Scannen von Images beim Push-Vorgang und die Bedrohungserkennung zur Laufzeit bieten einen mehrschichtigen Schutz. Warnungen fassen Fehlkonfigurationen, bekannte Schwachstellen und verdächtige Verhaltensweisen für eine schnelle Reaktion zusammen.

5. App Service-basierte Admin-Tools mit Authentifizierung und privatem Zugriff schützen.

• Begründung: Nutzen Sie die App Service-Authentifizierung mit Microsoft Entra ID, um MFA und bedingten Zugriff (Conditional Access) zu erzwingen. Erstellen Sie einen privaten Endpunkt für die Admin-App und schränken Sie den scm-Zugriff separat ein. Verwaltete Identitäten eliminieren die Notwendigkeit von Secrets für den Zugriff auf Key Vault.

6. Just-in-Time (JIT) VM-Zugriff für Legacy-Hosts während der Umstellung nutzen.

• Begründung: JIT schließt RDP/SSH standardmäßig und öffnet die Ports nur auf genehmigte Anfragen für eine begrenzte Dauer. Dies begrenzt die Zeitfenster der Gefährdung (Exposure Windows) strikt, während der Notfallzugriff erhalten bleibt.

7. Verschlüsselungsoptionen standardisieren: SSE mit CMK für Datenträger; Trusted Launch für VMs.

• Begründung: SSE mit CMK minimiert den Betriebsaufwand und zentralisiert den Lebenszyklus der Schlüssel in Key Vault, während Trusted Launch/vTPM die Integrität des Boot-Vorgangs und den Schlüsselschutz verbessert. ADE ist nur für Fälle reserviert, in denen ein Nachweis über eine gastbasierte Krypto-Domäne vertraglich erforderlich ist.

8. Azure Policy und Admission Control als Leitplanken (Guardrails) anwenden.

• Begründung: Azure Policy-Initiativen erzwingen Trusted Launch, erforderliche VM-Erweiterungen und verweigern den öffentlichen Zugriff auf ACR/Function. Gatekeeper-Constraints implementieren Admission Checks zur Laufzeit für AKS. Zusammen stellen sie sicher, dass die Konfigurationen konform bleiben, während die Teams iterieren.

9. Validieren und betreiben mit kontinuierlicher Governance.

• Begründung: Integrieren Sie Warnungen von Defender for Cloud und MDE in das SIEM von Adobe, messen Sie die Auswirkungen der Richtlinien (Deny vs. Audit) und überprüfen Sie Ausnahmen monatlich. Dies verwandelt einmalige Kontrollen in ein dauerhaftes Sicherheitsbetriebsmodell.

← Netzwerksicherheitsarchitektur · Alle Domänen · Daten- →

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

Microsoft durchsuchen →