Microsoft AZ-500: Anwendungssicherheit und DevSecOps — 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

Application Security und DevSecOps in Azure konzentrieren sich darauf, den Missbrauch von Identitäten zu verhindern, Ingress und APIs zu schützen, Sicherheit in den Pipelines nach links zu verlagern (Shift Left), Geheimnisse im Ruhezustand (at rest) und während der Übertragung (in transit) zu sichern und eine robuste Release-Governance durchzusetzen. Effektive Architekturen eliminieren langlebige Geheimnisse, wenden das Prinzip der geringsten Rechte (Least Privilege) an, validieren jeden Aufrufer und institutionalisieren die kontinuierliche Erkennung und Behebung von Schwachstellen in Code, Abhängigkeiten, Infrastruktur und zur Laufzeit.

Sichere Anwendungsidentität, Ingress und API-Schutz

Die sichere Anwendungsidentität in Microsoft Entra ID (Azure AD) beginnt mit einer App-Registrierung mit klar definiertem Geltungsbereich und dem korrekten OAuth 2.0-Flow:

• Delegierte Berechtigungen gelten, wenn ein Benutzer angemeldet ist, und die Zustimmung kann auf Apps von verifizierten Herausgebern oder nur auf vom Administrator genehmigte Bereiche beschränkt werden. Anwendungsberechtigungen (nur für Apps) erfordern immer die Zustimmung des Administrators, da sie Hintergrund-Daemons oder -Dienste autorisieren, die ohne einen Benutzer agieren.
• Setzen Sie das Prinzip der geringsten Rechte (Least Privilege) durch, indem Sie nur die minimal erforderlichen Bereiche oder Anwendungsrollen gewähren und eine Überprüfung der Zustimmungsanfragen durch einen Administrator vorschreiben. Deaktivieren Sie die Zustimmung durch Endbenutzer oder erlauben Sie sie nur für verifizierte Herausgeber mit geringem Risiko, um Consent-Phishing zu reduzieren.
• Bevorzugen Sie Zertifikatsanmeldeinformationen oder föderierte Identitäten gegenüber Client-Secrets. Zertifikate bieten eine höhere Sicherheit und eine vorhersagbare Rotation. Konfigurieren Sie kurze Lebensdauern und automatisieren Sie die Rotation. Blockieren Sie Public-Client-Flows, sofern sie nicht benötigt werden.
• Verwenden Sie für Azure-Dienste verwaltete Identitäten anstelle von App-Secrets. Weisen Sie Rollen auf Datenebene wie Key Vault Secrets User oder Storage Blob Data Reader zu und beschränken Sie den Netzwerkzugriff gegebenenfalls mithilfe von Private Endpoints.

Application Gateway WAF v2 und Azure Front Door WAF schützen den öffentlichen Ingress vor den OWASP Top 10-Bedrohungen:

• Aktivieren Sie das neueste von Microsoft verwaltete OWASP Core Rule Set und führen Sie es nach einer Feinabstimmung im Präventionsmodus (Prevention Mode) aus. Verwenden Sie anfangs die Anomaliebewertung (Anomaly Scoring), um False Positives während der Lernphase zu reduzieren.
• Konfigurieren Sie benutzerdefinierte Regeln für Geofencing, Blockierungen basierend auf IP-Reputation, Header-Durchsetzung und Begrenzungen der Anforderungsgröße. Fügen Sie für Front Door Ratenbegrenzungsregeln pro Client-IP hinzu, um Credential Stuffing und einfache L7-DoS-Angriffe abzuschwächen.
• Beenden Sie TLS mit starken Cipher Suites und Richtlinien; verwenden Sie End-to-End-TLS bis zum Ursprungsserver (Origin). Konfigurieren Sie für Szenarien, die mTLS erfordern, die Validierung von Client-Zertifikaten auf den Application Gateway-Listenern.
• Weisen Sie WAF-Richtlinien präzise den Listenern/Routen zu; verwenden Sie Regelausnahmen nur dann, wenn Sie den False Positive vollständig verstehen. Streamen Sie WAF-Protokolle zu Log Analytics für Detection Engineering und Incident Response.

API Management (APIM) setzt eine mehrschichtige Sicherheitsarchitektur (Multilayer Security Posture) durch:

• Validieren Sie OAuth-Token am Gateway mit strengen Prüfungen von Aussteller (Issuer), Zielgruppe (Audience) und Geltungsbereich (Scope). Erzwingen Sie überall HTTPS und setzen Sie mTLS durch, wenn die Vertrauensgrenze des Clients dies erfordert.
• Kombinieren Sie Abonnementschlüssel mit OAuth für eine tiefgreifende Verteidigung (Defense-in-Depth) und zur Drosselung der Identität. Verwenden Sie Abonnementschlüssel auf Produktebene, um Consumer zu partitionieren und Schlüssel zu rotieren, ohne andere zu beeinträchtigen.
• Wenden Sie Ratenbegrenzungen und Kontingente mit einer Granularität pro Consumer, pro Geltungsbereich oder pro Abonnement an. Verwenden Sie IP-Filterung, um gegebenenfalls Partnernetzwerke auf eine Allowlist zu setzen.
• Schützen Sie Backend-Dienste mithilfe von Mutual TLS oder verwalteten Identitäten. Speichern Sie Geheimnisse als benannte Werte (Named Values), die durch Key Vault-Referenzen gestützt werden, um Klartext in der Konfiguration zu vermeiden.

Beispiel für eine APIM-Richtlinie zur Durchsetzung von JWT-Scopes und zur Drosselung:

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

Härtung der DevSecOps-Pipeline und Defender for DevOps

Azure DevOps und GitHub Actions müssen sich bei Azure ohne langlebige Geheimnisse authentifizieren:

• Verwenden Sie Workload Identity Federation (OIDC) für Dienstverbindungen (Service Connections). Erstellen Sie eine App-Registrierung/einen Dienstprinzipal in Entra ID und fügen Sie dann eine föderierte Anmeldeinformation hinzu, die das Repo, den Branch und den Workflow/die Umgebung an die Identität bindet. Dies erzeugt kurzlebige Token ohne gespeicherte Geheimnisse und unterstützt die Festlegung des Geltungsbereichs nach dem Prinzip der geringsten Rechte über Azure RBAC.
• Sichern Sie die Pipeline-Berechtigungen: Fordern Sie Genehmigungen für die Nutzung von Dienstverbindungen an, beschränken Sie die Pipeline auf geschützte Branches und deaktivieren Sie „Skripten den Zugriff auf das OAuth-Token erlauben“, sofern nicht erforderlich. Verwenden Sie Variablengruppen und Geheimnisse mit Maskierung; unterbinden Sie die Ausgabe von Geheimnissen über Protokollierungsbefehle. Bevorzugen Sie in GitHub Umgebungs- und Organisationsgeheimnisse gegenüber Repo-Geheimnissen für eine zentrale Steuerung und verwenden Sie gegebenenfalls die Einstellungen „prevent secrets in logs“ in gehosteten Runnern.
• Wenden Sie Schutzregeln für Umgebungen an: erforderliche Prüfer, Überprüfungen (z. B. Change-Management-Tickets, bestandene Tests) und zeitbasierte Genehmigungen.

Erstellen einer föderierten Anmeldeinformation mit der Azure CLI (GitHub OIDC-Beispiel):

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOps lässt sich in Azure Repos und GitHub integrieren, um Folgendes aufzuzeigen:

• Ergebnisse der Codesicherheitsprüfung (SAST) in gängigen Sprachen; Anmerkungen in Pull Requests heben neue Probleme hervor, um Regressionen zu verhindern.
• Abhängigkeitsrisiken (SCA) durch Nutzung von Schwachstelleninformationen für OSS-Bibliotheken mit Anleitungen zur Behebung und Angabe von korrigierten Versionen.
• Erkennung von offengelegten Geheimnissen und empfohlene Rotationen für geleakte Token/Schlüssel.
• Fehlkonfigurationen in Infrastructure-as-Code über ARM/Bicep/Terraform (z. B. öffentlicher Speicher, freizügige NSGs) mit richtliniengesteuerter Governance und Drift-Tracking. Die Ergebnisse werden in Defender for Cloud zusammengefasst und mit Repository- und Pipeline-Kontext zur Priorisierung versehen. Steuern Sie Releases basierend auf Schweregrad-Schwellenwerten, um unsichere Bereitstellungen zu stoppen.

Verwaltung von Geheimnissen und Plattformintegration

Key Vault bietet eine zentralisierte Verwaltung von Geheimnissen, Schlüsseln und Zertifikaten mit umfassenden Kontrollen:

• Erzwingen Sie Löschschutz (Purge Protection) und vorläufiges Löschen (Soft Delete), um destruktiven Verlust zu verhindern. Bevorzugen Sie RBAC gegenüber Zugriffsrichtlinien für eine einheitliche Autorisierung; aktivieren Sie Private Endpoints und deaktivieren Sie den öffentlichen Netzwerkzugriff, wo immer möglich; aktivieren Sie die Protokollierung in einem sicheren Workspace.
• App Service und Functions verwenden Key Vault-Referenzen in den App-Einstellungen mit verwalteten Identitäten (Managed Identities); rotieren Sie Geheimnisse transparent ohne erneute Bereitstellung.
• AKS ruft Geheimnisse zur Laufzeit über den Secrets Store CSI Driver mit dem Azure Key Vault Provider ab, authentifiziert durch Azure AD Workload Identity (empfohlen). Vermeiden Sie es, Geheimnisse im Klartext in Kubernetes Secret-Objekten zu speichern.

Beispiel für eine App Service Key Vault-Referenz:

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

AKS SecretProviderClass (gekürzt):

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

Pipelines sollten Geheimnisse zur Laufzeit des Jobs abrufen:

• Azure DevOps: Key Vault-Task mit einer durch eine verwaltete Identität (Managed Identity) gestützten Service Connection; beschränken Sie den Download von Geheimnissen auf die geringstmögliche Anzahl von Stages.
• GitHub Actions: azure/login für OIDC und azure/keyvault, um nur die erforderlichen Namen abzurufen.

Sicherer SDLC, Container, Protokollierung und Releases

Sichere SDLC-Praktiken reduzieren das Risiko vor der Bereitstellung:

• Eine frühzeitige Bedrohungsmodellierung mit STRIDE oder einem Äquivalent stellt sicher, dass Authentifizierung, Autorisierung und Datenflüsse explizit validiert werden. Modelle müssen bei Architekturanpassungen aktualisiert werden.
• SAST wird bei jeder PR ausgeführt; Builds werden bei Problemen mit hohem Schweregrad und klarer Zuständigkeit abgebrochen. DAST wird nach der Bereitstellung in einem Staging-Slot/einer Staging-Umgebung mit sicheren Testdaten ausgeführt.
• SCA überwacht Pakete kontinuierlich; erzwingt feste Versionen und die Einhaltung von Lizenzen.
• Strenge Code-Reviews mit Branch-Richtlinien: erforderliche Reviewer, verknüpfte Arbeitselemente, Build-Validierung und signierte Commits.

Die Sicherheit von Container-Images ist grundlegend für die Integrität der Lieferkette:

• Generieren und speichern Sie SBOMs (SPDX oder CycloneDX) während der Builds und veröffentlichen Sie diese zusammen mit den Images als OCI-Artefakte zur Nachverfolgbarkeit.
• Scannen Sie Images vor dem Push und im Ruhezustand (at-rest) in Registries mit dem Container-Scanning von Defender for Cloud; blockieren Sie die Heraufstufung (Promotion) bei kritischen Befunden.
• Signieren Sie Images und Attestierungen mit Notary v2/OCI-Artefakten unter Verwendung von cosign. Erzwingen Sie die Signaturüberprüfung bei der Aufnahme (Admission) (z. B. mit Gatekeeper/OPA oder AKS Policy für Kubernetes).
• Registry-Kontrollen in Azure Container Registry (ACR): Deaktivieren Sie den Admin-Benutzer, schränken Sie das Netzwerk über Private Endpoints ein, aktivieren Sie kundenseitig verwaltete Schlüssel, verwenden Sie Repository-bezogene Token für granularen Zugriff und wenden Sie Aufbewahrungs- und Quarantänemuster an. Gewähren Sie Laufzeitumgebungen nur AcrPull und der CI nur AcrPush. Für AKS, verbinden Sie die ACR mit dem unterstützten Befehl, um die korrekte Zuweisung zu erstellen, anstatt die Rollenkonfiguration manuell vorzunehmen.
• Wenn Container VNet-Dienstendpunkte von einem VM-Host verwenden müssen, installieren Sie ein unterstütztes CNI-Plugin, damit der Datenverkehr pro Container aus dem Subnetz stammt.

Die Anwendungsprotokollierung darf keine Geheimnisse oder personenbezogenen Daten (PII) preisgeben:

• Konfigurieren Sie Application Insights so, dass sensible Felder mit Telemetry Processors geschwärzt oder verworfen werden; vermeiden Sie die Protokollierung von rohen Headern, Token oder Payloads, die Geheimnisse oder PII enthalten. Beschränken Sie Datenfelder auf den geschäftlichen Bedarf und aktivieren Sie Sampling, um die Exposition zu reduzieren.
• Leiten Sie Diagnosedaten an einen dedizierten Log Analytics-Workspace mit striktem RBAC (Log Analytics Reader als geringstes Recht) und unveränderlichem Speicher beim Export in Storage (zeitbasierte Aufbewahrungssperren) weiter.
• Schützen Sie Endpunkte für die Telemetrieerfassung und -abfrage mit Private Link, wo verfügbar. Speichern Sie Verbindungszeichenfolgen für die Instrumentierung in Key Vault und rotieren Sie diese regelmäßig.

Sichere Release-Praktiken erzwingen eine kontrollierte Heraufstufung:

• Genehmigungs-Gates in Azure DevOps Environments oder GitHub Environments erfordern benannte Reviewer, bestandene Qualitätsprüfungen und Change-Tickets. Automatisieren Sie Zurückhaltungsfenster (Hold-back windows) für risikoreiche Bereitstellungen.
• Wenden Sie das Prinzip der geringsten Rechte auf Service-Verbindungen und Agents an; beschränken Sie den Geltungsbereich auf Ressourcengruppen oder Abonnements pro Umgebung. Verwenden Sie verwaltete Identitäten mit eng gefassten Rollen.
• Umgebungstrennung zwischen Dev, Test und Prod mit separaten Abonnements, VNets, Key Vaults und ACRs; unterbinden Sie laterale Bewegungen zwischen Umgebungen und verwenden Sie in jeder Umgebung unterschiedliche Geheimnisse/Schlüssel.

Praktisches Problemszenario

Fabrikam, Inc. veröffentlicht eine mandantenfähige SaaS-API im Internet. Anforderungen: Blockieren von OWASP Top 10-Angriffen, Validieren von OAuth-Scopes pro Operation, Verhindern von Geheimnissen in Repos, Drosseln von missbräuchlichen Clients und Sicherstellen, dass nur signierte Container-Images in der Produktion ausgeführt werden.

1. Fronting und WAF

• Bereitstellen von Azure Front Door Standard mit einer WAF-Richtlinie, die das neueste verwaltete OWASP-Regelwerk im Präventionsmodus sowie benutzerdefinierte Ratenbegrenzungsregeln und Geo-Blocking verwendet. Begründung: Die zentralisierte, globale Durchsetzung am Edge reduziert die Angriffsfläche und fängt L7-Angriffe ab, bevor sie den Ursprung erreichen.

2. API-Gateway-Richtlinie

• Platzieren Sie Azure API Management hinter Front Door; implementieren Sie validate-jwt mit Überprüfungen von Issuer/Audience/Scope pro Operation und abonnementbasierten Schlüsseln auf Produktebene mit Quotas. Begründung: APIM bietet eine identitätsbewusste Durchsetzung und Mandantenisolierung; Schlüssel plus OAuth bieten eine mehrschichtige Verteidigung und präzise Drosselung.

3. Identität und Zustimmung

• Registrieren Sie die SPA- und Daemon-Anwendungen in Entra ID mit delegierten Bereichen (Scopes) für Benutzerflüsse und Anwendungsrollen für den Daemon; beschränken Sie die Benutzerzustimmung auf verifizierte Herausgeber und fordern Sie die Zustimmung des Administrators für App-Berechtigungen an. Verwenden Sie Zertifikatsanmeldeinformationen für den Daemon. Begründung: Eliminiert schwache Geheimnisse, erzwingt das Prinzip der geringsten Rechte und reduziert das Risiko von Consent-Phishing.

4. DevSecOps mit OIDC

• Konfigurieren Sie GitHub Actions für die Verwendung von OIDC-Föderation mit einem Azure Service Principal, dessen Geltungsbereich für den Build auf eine Nicht-Produktions-Subscription und für das Release auf einen produktionsbezogenen Principal beschränkt ist, jeweils mit minimalen Rollen (AcrPush für den Build, Contributor beschränkt auf eine Prod-RG für das Release). Begründung: keine gespeicherten Geheimnisse; der Explosionsradius (Blast Radius) wird pro Umgebung minimiert.

5. Container-Lieferkette

• Erstellen Sie Images über ACR Tasks, generieren Sie SBOMs (CycloneDX) und signieren Sie Images mit cosign; speichern Sie Attestierungen als OCI-Artefakte. Konfigurieren Sie die AKS-Admission mit einer Richtlinie, die gültige Signaturen erfordert. Begründung: Herkunft und Integrität sind zum Zeitpunkt der Bereitstellung überprüfbar, was manipulierte Images blockiert.

6. Registry- und Laufzeit-Kontrollen

• Deaktivieren Sie den ACR-Admin-Benutzer, aktivieren Sie den Private Endpoint, weisen Sie der AKS-Kubelet-Identität über den unterstützten attach-acr-Flow die Rolle AcrPull zu und aktivieren Sie das Image-Scanning von Defender for Cloud. Begründung: Netzwerk- und Identitätshärtung entfernen standardmäßige Hintertüren; das Scannen deckt bekannte CVEs vor der Laufzeit auf.

7. Geheimnisse und Konfiguration

• Verwenden Sie Key Vault mit Private Endpoint und RBAC; App Service und Functions nutzen Key Vault-Referenzen, und AKS verwendet den Secret Store CSI mit Workload Identity. Begründung: Geheimnisse befinden sich niemals in Repos oder App-Konfigurationen; die Rotation ist zentralisiert und prüfbar.

8. Release-Governance

• Schützen Sie den main-Branch von GitHub mit erforderlichen Reviews und Prüfungen; fordern Sie vor der Produktionsbereitstellung Umgebungsfreigaben und das Bestehen von Sicherheits-Gates (keine kritischen SAST/SCA/IaC-Befunde) an. Begründung: Stellt sicher, dass nur validierte, sichere Builds weitergegeben werden; menschliche Aufsicht bleibt für risikoreiche Änderungen bestehen.

9. Observability-Hygiene

• Konfigurieren Sie Application Insights so, dass PII mit benutzerdefinierten Telemetry Processors geschwärzt werden, und leiten Sie WAF/APIM-Diagnosedaten an einen gesicherten Log Analytics-Workspace mit dem geringstmöglichen Reader-Zugriff weiter. Begründung: Bewahrt den forensischen Wert, ohne sensible Daten preiszugeben; der Zugriff ist prüfbar und eingeschränkt.

← Microsoft Sentinel und Security Operations · Alle Domänen · Hybrid- und Multi-Cloud-Sicherheit →

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

Microsoft durchsuchen →