Microsoft AZ-400: Sicherheit, Compliance und DevSecOps — Lernleitfaden

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

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

Überblick

Sicherheit, Compliance und DevSecOps in auf Azure ausgerichteten Delivery-Pipelines erfordern die Verlagerung der Risikoerkennung in die frühestmöglichen Phasen, die kontinuierliche Durchsetzung von Richtlinien und die Automatisierung der Erfassung von Nachweisen. Effektive Implementierungen vereinen Application Security Testing (SAST/DAST/SCA), Secrets Governance, Scans von Infrastructure-as-Code (IaC) und regulatorische Kontrollen im CI/CD-Lebenszyklus. In Azure DevOps und GitHub bedeutet dies, Analysatoren bei jedem Pull Request auszuführen, Merges durch Qualitätsschwellenwerte zu steuern, mit Identitäten mit den geringsten Rechten (Least-Privilege) bereitzustellen, die zeitlich begrenzte Geheimnisse aus Azure Key Vault abrufen, und die Sicherheitslage kontinuierlich mit Microsoft Defender for DevOps und Defender for Cloud zu überwachen. Das Ziel ist nicht nur, Probleme zu finden, sondern auch zu verhindern, dass unsichere Änderungen geschützte Ressourcen erreichen, die Compliance durch Audit-Trails nachzuweisen und eine sichere Entwicklungsgeschwindigkeit aufrechtzuerhalten.

Shift-Left-Security, OWASP Top 10-Gegenmaßnahmen und Pipeline-Härtung

Shift-Left-Security beginnt mit SAST und SCA zum Zeitpunkt des PRs, ergänzt durch Secrets Scanning und gezieltes DAST vor der Beförderung (Promotion). SAST deckt Schwachstellen auf Code-Ebene auf, wie z. B. Injection-Punkte, unsichere Deserialisierer und fehlende Ausgabekodierung. Integrieren Sie SonarQube/SonarCloud oder GitHub code scanning (z. B. CodeQL), um jedes Changeset zu analysieren; versehen Sie Pull Requests mit Issues, die an bestimmte Zeilen gebunden sind; und erzwingen Sie Quality Gates, die den Build fehlschlagen lassen, wenn Schwachstellen- oder Abdeckungsschwellenwerte nicht erfüllt werden. Konzentrieren Sie SAST auf die OWASP Top 10-Klassen:

• Injection: Schreiben Sie die Verwendung von parametrisierten Abfragen/ORM vor, validieren/normalisieren Sie Eingaben und verbieten Sie dynamisches SQL/String-Verkettung. Erzwingen Sie dies durch SAST-Regelsätze und Unit-Tests, die die Verwendung von geprüften Datenzugriffs-Helpern sicherstellen.
• Cross-Site Scripting (XSS): Fordern Sie Ausgabekodierung und eine Content Security Policy. Die SAST Taint-Analyse sollte nicht vertrauenswürdige Eingaben zu Senken (Sinks) wie

undefined

oder

undefined

verfolgen.

• Cross-Site Request Forgery (CSRF): Erzwingen Sie Anti-Forgery-Tokens und SameSite-Cookies. Pipelines können Framework-Analysatoren ausführen, um sicherzustellen, dass Middleware/Einstellungen aktiviert sind.
• Unsichere Deserialisierung: Verbieten Sie unsichere binäre/XML-Serialisierer, beschränken Sie erlaubte Typen und bevorzugen Sie JSON-Serialisierer, die mit sicheren Standardeinstellungen konfiguriert sind. SAST-Prüfungen und Abhängigkeitsrichtlinien verhindern die Verwendung bekanntermaßen unsicherer Bibliotheken.

DAST validiert laufende Builds in einer Staging-Umgebung. Automatisieren Sie OWASP ZAP oder ein Äquivalent als Pipeline-Job nach dem Deployment in die Nicht-Produktivumgebung, unter Verwendung von authentifizierten Scans und einem auf Ihr App-Profil abgestimmten Regelsatz. Steuern Sie die Promotion basierend auf einer Schwachstellen-Baseline: Blockieren Sie bei neu eingeführten hohen/kritischen Befunden und speichern Sie akzeptierte Ausnahmen mit einem Ablaufdatum.

Software Composition Analysis (SCA) erkennt anfällige Pakete von Drittanbietern vor dem Merge. Verwenden Sie Dependabot, um PRs für Versionserhöhungen zu erstellen, und OWASP Dependency-Check, um SBOMs und CVE-Berichte in der CI zu erzeugen. Erzwingen Sie die Lizenz-Compliance, indem Sie Allow/Deny-Listen definieren (z. B. Copyleft für proprietäre Produkte verbieten) und Builds fehlschlagen lassen, die nicht erlaubte Lizenzen enthalten. Secrets Scanning muss bei jedem Commit und in der CI ausgeführt werden: Nutzen Sie GitHub Advanced Security Secret Scanning oder integrieren Sie Gitleaks/Microsoft Security DevOps, um hartcodierte Anmeldeinformationen, Tokens und Schlüssel zu finden; blockieren Sie den Merge, wenn ein Secret-Muster erkannt wird, und rotieren Sie die betroffenen Anmeldeinformationen.

Die Absicherung der Pipeline (Pipeline Hardening) ist nicht verhandelbar. Sichern Sie Branch-Schutzmechanismen, fordern Sie PR-Reviews und erzwingen Sie Statusprüfungen für SAST/SCA/DAST. Verwenden Sie in Azure Pipelines geschützte Ressourcen, Umgebungs-Genehmigungen und -Prüfungen sowie erforderliche Vorlagen (Required Templates), um Sicherheitsstufen zu standardisieren. Bevorzugen Sie kurzlebige Tokens mit den geringsten Rechten; vermeiden Sie statische Anmeldeinformationen vollständig durch Workload Identity Federation. Beschränken Sie selbstgehostete Agents auf private Netzwerke, legen Sie den Geltungsbereich ihrer Identitäten minimal fest und deaktivieren Sie Script-Injection, indem Sie Vorlagen erzwingen, die beliebige Skriptschritte für nicht vertrauenswürdige Repositories verbieten.

Geheimnisse, Identitäten, Azure Key Vault und Zertifikatsrotation

Azure Key Vault ist der maßgebliche Speicher für Geheimnisse, Schlüssel und Zertifikate. Integrieren Sie ihn direkt in CI/CD, um Geheimnisse im Klartext zu eliminieren:

• Pipeline-Geheimnisse: Verknüpfen Sie in Azure DevOps eine Variablengruppe über eine Service Connection mit einem Key Vault, deren Geltungsbereich auf die benötigten Secret-Namen beschränkt ist. Geheimnisse werden zur Laufzeit abgerufen und in Protokollen maskiert. Verwenden Sie in GitHub Actions

undefined

mit föderierter Identität, um Tokens zu erhalten und Key Vault aufzurufen; vermeiden Sie das Speichern von Client Secrets in den Repository-Einstellungen.

• Zugriff über Managed Identity: Lassen Sie Workloads und Deployment-Agents wann immer möglich mit Microsoft Entra ID über Managed Identity oder Workload Identity Federation authentifizieren, sodass keine Geheimnisse gespeichert werden. Beschränken Sie den Key Vault-Zugriff mithilfe von RBAC oder Zugriffsrichtlinien nach dem Prinzip der geringsten Rechte (Least Privilege) (nur get/list für bestimmte Secret-Versionen; kein purge/delete).
• Zertifikatsrotation: Speichern Sie TLS/MTLS-Zertifikate in Key Vault Certificates mit automatischer Rotation über integrierte CAs. Konfigurieren Sie konsumierende Dienste (App Service, Application Gateway, AKS Ingress über CSI Secrets Store) so, dass sie auf den Key Vault verweisen, damit erneuerte Zertifikate ohne erneutes Deployment übernommen werden. Nutzen Sie Event Grid für

undefined

-Ereignisse des Key Vault, um ein Automatisierungs-Runbook oder eine Function auszulösen, die Bindungen validiert und Caches aufwärmt. Verfolgen Sie die Verwendung von Zertifikatsversionen in Deployment-Manifesten; pinnen Sie Versionen bei Bedarf und führen Sie während der Wartungsfenster gezielt ein Roll-Forward durch.

Härten Sie den Key Vault mit Private Endpoints, Firewall-Regeln, Purge Protection, Soft-Delete und Protokollierung in Log Analytics oder Storage für Audits. Verweigern Sie mandantenübergreifenden Zugriff, es sei denn, er ist ausdrücklich gerechtfertigt, und rotieren Sie routinemäßig den Zugriff für Break-Glass-Konten.

Abhängigkeiten, Container, IaC und Compliance as Code

Das Scannen von Abhängigkeiten muss sowohl Sicherheitslücken als auch Lizenzen abdecken. Dependabot schlägt kontinuierlich sichere Updates vor; verwenden Sie Richtlinien zur Überprüfung von Abhängigkeiten (dependency review policies), um PRs zu blockieren, die anfällige Versionen einführen. OWASP Dependency-Check (oder ökosystem-native Tools wie npm audit, pip-audit) sollte in der CI ausgeführt werden, um SBOMs (CycloneDX/SPDX) zu generieren und den Build fehlschlagen zu lassen, wenn Schwellenwerte für den Schweregrad oder Lizenzregeln verletzt werden. Für eine erweiterte Lizenz-Governance kombinieren Sie dies mit einer SCA-Plattform, die in der Lage ist, rechtliche Richtlinien durchzusetzen und Workflows zur Behebung zu ermöglichen.

Die Sicherheit von Container-Images beginnt in der CI und wird in der Registry und zur Laufzeit fortgesetzt:

• Trivy: Als Pipeline-Schritt ausführen, um Dockerfiles und erstellte Images auf CVEs in Betriebssystemen/Paketen und Fehlkonfigurationen zu scannen; den Build bei kritischen/hohen (Critical/High) Befunden abbrechen. Erzwingen Sie minimale Basis-Images und rootless Container.
• Azure Container Registry Schwachstellenscans: Aktivieren Sie Microsoft Defender for Containers, um Images bei Push/Import und nach einem Zeitplan zu scannen. Zeigen Sie die Ergebnisse in Defender for Cloud an, exportieren Sie sie in Arbeitselemente (work items) und erzwingen Sie Deployment-Gates, die Images mit ungelösten kritischen/hohen (Critical/High) Problemen blockieren.
• Defender for Containers: Erweitern Sie den Schutz auf AKS/ECS/Kubernetes mit Bedrohungserkennung zur Laufzeit, Prüfungen im Stil von kube-bench und Admission Control. Verwenden Sie Richtlinien, um nur von vertrauenswürdigen ACRs zu pullen, die mit Notation/ACR Content Trust signiert sind, und verifizieren Sie die Signaturen in der CI und bei der Cluster-Admission.

IaC-Sicherheit stellt sicher, dass Cloud-Ressourcen standardmäßig sicher bereitgestellt werden:

• Checkov und tfsec: Scannen Sie Terraform- und Kubernetes-Manifeste auf unsichere Konfigurationen (öffentlicher Speicher, offene Security Groups, fehlende Verschlüsselung). Lassen Sie Builds bei Überschreitung von Schwellenwerten für den Schweregrad fehlschlagen; erstellen Sie eine Baseline für bestehende technische Schulden (existing debt), um sich auf neue/geänderte Ressourcen zu konzentrieren.
• ARM/Bicep-Linting: Aktivieren Sie den Bicep-Linter (bicepconfig.json) und das ARM Template Tool Kit (arm-ttk), um Regeln für Tagging, reine HTTPS-Endpunkte, kundenseitig verwaltete Schlüssel (customer-managed keys) und Diagnoseeinstellungen durchzusetzen. Kombinieren Sie dies mit What-If-Deployments, um Abweichungen (drift) vor der Anwendung (apply) zu erkennen.

Compliance as Code nutzt Azure Policy und Defender for Cloud, um Kontrollen kontinuierlich durchzusetzen und darüber zu berichten:

• Weisen Sie Azure Policy-Initiativen zu, die auf CIS, NIST, ISO 27001 oder interne Baselines ausgerichtet sind; wählen Sie Effekte wie Deny für kritische Leitplanken (z. B. öffentliche IPs auf Datenbanken), DeployIfNotExists für die Diagnose und Audit für die Beobachtbarkeit (observability). Speichern Sie Richtliniendefinitionen als versionierte Artefakte, testen Sie sie mit Policy-as-Code-Pipelines und führen Sie die Beförderung (promote) über Pull Requests durch.
• Nutzen Sie die Dashboards zur Einhaltung gesetzlicher Vorschriften (regulatory compliance) von Defender for Cloud, um die Konformität der Kontrollen über Abonnements und Verwaltungsgruppen hinweg zu visualisieren. Integrieren Sie es mit Azure Monitor und exportieren Sie Nachweise zur Aufnahme in ein SIEM nach Log Analytics oder Event Hubs.
• Führen Sie Audit-Protokolle (audit trails): Azure Activity Logs für Richtlinienereignisse und -zuweisungen, Resource Graph für Compliance-Abfragen, Azure DevOps/GitHub-Audit-Logs für Änderungen an Repos und Pipelines und Release-Nachweise, die automatisch als Artefakte von Pipeline-Durchläufen erfasst werden.

SonarQube/SonarCloud, Pipeline-Sicherheit und Microsoft Defender for DevOps

SonarQube/SonarCloud bietet durchsetzbare Qualitäts-Gates, die Engineering-Qualität mit Sicherheit in Einklang bringen. Übernehmen Sie den „Clean as You Code“-Ansatz, indem Sie Gates für neuen Code festlegen: minimale Code-Abdeckung für neue/geänderte Zeilen (z. B. 80 %+), keine neuen kritischen Schwachstellen oder Blocker-Code-Smells und geringe Duplizierung. Ein Scheitern am Gate muss zum Scheitern der Pipeline führen. Veröffentlichen Sie die Abdeckung von Test-Frameworks (JaCoCo, Cobertura, VSTest) und passen Sie die Qualitätsprofile pro Sprache an, um Security Hotspots und OWASP-konforme Regeln einzubeziehen. Verfolgen Sie Kennzahlen zur technischen Schuld und die Behebungszeiten; berichten Sie Trends, um die Verantwortlichkeit im Team zu fördern.

Die Sicherheit von Pipelines basiert auf Dienstverbindungen mit geringsten Rechten, geschützten Ressourcen und einer umfassenden Maskierung von Geheimnissen:

• Dienstverbindungen sollten Workload-Identitätsverbunde oder verwaltete Identitäten mit eng gefassten Geltungsbereichen (Abonnement/Ressourcengruppe, spezifische ACR oder Key Vault) verwenden. Aktivieren Sie Genehmigungen und Prüfungen für Dienstverbindungen und Umgebungen, sodass Eigentümer die Nutzung autorisieren müssen. Beschränken Sie die „Verwenden“-Berechtigungen auf vertrauenswürdige Pipelines; deaktivieren Sie „Allen Pipelines Zugriffsberechtigung erteilen“.
• Geschützte Ressourcen in Azure DevOps sichern Dienstverbindungen, Variablengruppen, sichere Dateien und Umgebungen. Fordern Sie Prüfungen wie Genehmiger, Geschäftszeitfenster, Ergebnisse von Azure Monitor-Abfragen und externe REST-Richtlinien-Engines. Behandeln Sie sie als Gates vor Deployments und als Vorbedingungen für sensible Lesezugriffe (z. B. das Abrufen von Produktionsgeheimnissen).
• Die Maskierung von Geheimnissen muss in allen Protokollen durchgesetzt werden; schränken Sie die Variablenerweiterung in Skripten ein; vermeiden Sie die Ausgabe von Geheimnissen; und bevorzugen Sie APIs mit dem Geltungsbereich system.accessToken gegenüber der Speicherung von PATs. Scannen Sie Pipeline-Protokolle regelmäßig auf unbeabsichtigt veröffentlichte Geheimnisse und rotieren Sie diese bei Entdeckung.

Microsoft Defender for DevOps vereinheitlicht den Sicherheitsstatus von Repositories und Pipelines über GitHub und Azure DevOps hinweg. Verbinden Sie Organisationen/Projekte mit Defender for Cloud, um Risiko-Signale aus Code, Geheimnissen, IaC und Abhängigkeiten zu erfassen und konsolidierte Empfehlungen darzustellen. Es korreliert Ergebnisse mit den Eigentümern, unterstützt Unterdrückungs-Workflows mit Ablaufdatum und misst die Einführung von Branch-Schutzmaßnahmen, erforderlichen Reviewern und Statusprüfungen. Kombinieren Sie Defender for DevOps mit dem Microsoft Security DevOps Task/Action, um mehrere Analysetools (z. B. Semgrep, Trivy, tfsec, Gitleaks, Bandit) in einem Schritt zu orchestrieren und SARIF-Dateien im Code-Scanning zu veröffentlichen. Nutzen Sie Defender for Cloud, um Governance-Initiativen zu erstellen, die DevOps-Best-Practices verfolgen und durchsetzen (z. B. Secret-Scanning aktiviert, erforderliche Anzahl an Reviewern ≥ 2, Merges durch Nicht-Administratoren deaktiviert), und heben Sie so die Repository-Hygiene auf das Niveau einer prüffähigen Kontrolle.

Praktisches Problemszenario

Spotify muss die sichere Bereitstellung für einen neuen, auf AKS gehosteten Microservice-Stack standardisieren, der .NET und Node.js umfasst. Die Repositories befinden sich in GitHub Enterprise Cloud und die Deployments erfolgen über mehrstufige YAML-Pipelines in Azure DevOps. Die Herausforderung besteht darin, anfällige Abhängigkeiten und fehlkonfigurierte Infrastruktur vor dem Merge zu stoppen, statische Anmeldeinformationen zu eliminieren und das Hochstufen von Images mit kritischen CVEs zu blockieren, während gleichzeitig prüffähige Konformitätsnachweise erstellt werden.

1. SAST/SCA und Secret-Scanning zur PR-Zeit erzwingen

• Wählen Sie SonarCloud für mehrsprachiges SAST mit PR-Dekoration und Qualitäts-Gates; legen Sie eine Code-Abdeckung für neuen Code von ≥ 80 % und null neue kritische Schwachstellen fest. Dependabot ist aktiviert, um sichere Upgrades automatisch per PR bereitzustellen, und die GitHub Dependency Review blockiert PRs, die bekannte CVEs einführen. Das Secret-Scanning von GitHub Advanced Security plus Gitleaks in der CI gewährleisten eine Tiefenverteidigung (Defense-in-Depth) gegen die Offenlegung von Anmeldeinformationen.

2. Authentifiziertes DAST vor dem Hochstufen hinzufügen

• Verwenden Sie OWASP ZAP in einer Pipeline-Stage, die auf die Staging-Umgebung mit vorbereiteten Testkonten abzielt. Eine Release-Prüfung blockiert die Produktion, wenn neue Probleme mit hohem/kritischem Schweregrad auftreten. ZAP wird aufgrund seiner OWASP-konformen Abdeckung und der einfachen CI-Automatisierung gewählt.

3. Identitäten und Geheimnisse mit Key Vault und Workload-Identitätsverbund absichern

• Ersetzen Sie Client-Geheimnisse von Dienstprinzipalen durch den Microsoft Entra Workload-Identitätsverbund für Dienstverbindungen, um gespeicherte Geheimnisse zu entfernen. Pipelines rufen Laufzeitgeheimnisse und DB-Anmeldeinformationen aus Azure Key Vault über get/list-Berechtigungen mit geringsten Rechten ab. Dies eliminiert langlebige Anmeldeinformationen und zentralisiert die Rotation.

4. Zertifikatsautomatisierung implementieren

• Speichern Sie Ingress- und mTLS-Zertifikate in Key Vault mit automatischer Rotation. AKS ruft Zertifikate über den Secrets Store CSI-Treiber ab, um das Kopieren von Geheimnissen in Kubernetes zu vermeiden. Event Grid löst eine Function aus, um die Bindungen nach der Erneuerung zu überprüfen. Dieses Design minimiert Ausfallzeiten und menschliche Fehler bei der Rotation.

5. Container und Registries härten

• Führen Sie Trivy in der CI aus, um Dockerfiles und erstellte Images zu scannen; lassen Sie den Build bei kritischen/hohen Schwachstellen fehlschlagen. Pushen Sie nur saubere Images in die ACR. Aktivieren Sie Defender for Containers, um die ACR bei jedem Push und periodisch zu scannen und die Ergebnisse in Defender for Cloud anzuzeigen. Richtlinienbasierte Release-Prüfungen blockieren das Deployment von Images mit ungelösten kritischen/hohen CVEs. Trivy liefert schnelles Feedback; Defender fügt eine kontinuierliche, Registry-native Absicherung hinzu.

6. IaC scannen und Bicep/ARM linten

• Verwenden Sie Checkov und tfsec, um Terraform- und Helm-Charts zu scannen; erzwingen Sie Tagging, Verschlüsselung und Netzwerkkontrollen. Der Bicep Linter und das ARM TTK laufen in der CI für Azure-native Vorlagen. Fehlschlagende Prüfungen blockieren Merges; Baselines beschränken das Rauschen auf neue/geänderte Ressourcen. Diese Tools werden aufgrund ihrer breiten Regelabdeckung und starken Azure-Unterstützung gewählt.

7. Compliance und Nachweise kodifizieren

• Weisen Sie Azure Policy-Initiativen für CIS Azure und Unternehmens-Baselines zu; erzwingen Sie Deny für kritische Leitplanken und DeployIfNotExists für die Diagnose. Speisen Sie die Ergebnisse in die regulatorischen Dashboards von Defender for Cloud ein. Exportieren Sie Aktivitätsprotokolle und Defender-Empfehlungen nach Log Analytics für unveränderliche Nachweise. Policy sorgt für kontinuierliche Durchsetzung; Dashboards bieten prüfbereite Ansichten.

8. Pipelines und geschützte Ressourcen absichern

• Beschränken Sie Dienstverbindungen auf bereichsbezogene Abonnements/Ressourcengruppen; fordern Sie Umgebungs-Genehmigungen und Prüfungen von Azure Monitor-Abfragen für die Produktion. Schützen Sie Variablengruppen und sichere Dateien; maskieren Sie alle Geheimnisse. Härten Sie selbstgehostete Agents mit privatem Netzwerk. Diese Funktionen reduzieren den „Blast Radius“ und stellen eine menschliche Überprüfung (Human-in-the-Loop) für risikoreiche Aktionen sicher.

9. Sicherheitsstatus mit Microsoft Defender for DevOps konsolidieren

• Verbinden Sie die GitHub-Organisation und das Azure-DevOps-Projekt mit Defender for Cloud, um Ergebnisse aus Code-, Secret- und IaC-Scans zu aggregieren und die Einführung von Repository-Schutzmaßnahmen zu verfolgen. Nutzen Sie die Microsoft Security DevOps Action/Task, um Semgrep, Trivy, tfsec und Gitleaks mit Veröffentlichung im SARIF-Format zu orchestrieren und so ein standardisiertes Scannen über alle Dienste hinweg sicherzustellen. Dies zentralisiert das Risikomanagement und die Workflows zur Problembehebung.

Jedes Tool/Feature wird für die frühestmögliche Erkennung, automatische Durchsetzung und Prüfbarkeit ausgewählt: SonarCloud und ZAP fungieren als Gate für Code- und Laufzeitrisiken; Dependabot und Trivy beschleunigen sichere Updates; Key Vault und der Identitätsverbund entfernen statische Geheimnisse; Checkov/tfsec und Azure Policy verhindern Drift; geschützte Ressourcen und Genehmigungen kontrollieren den „Blast Radius“; Defender for DevOps und Defender for Cloud liefern ein einheitliches, umsetzbares Management des Sicherheitsstatus.

← Release-Management und Deployment-Strategien · Alle Domänen · Teststrategie und Quality Engineering →

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

Microsoft durchsuchen →