Microsoft AZ-500: Incident Response, Wiederherstellung und Resilienz — Lernleitfaden
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
Incident Response, Wiederherstellung und Resilienz in Azure sind eine kontinuierliche Fähigkeit, die gut eingeübte operative Verfahren mit plattformnativen Kontrollen verbindet. Ein effektives Programm antizipiert Ausfälle oder Kompromittierungen, erkennt und bewertet diese schnell, dämmt den Schaden (Blast Radius) durch Automatisierung ein, stellt Dienste gemäß definierter Ziele wieder her, sichert unveränderliche Beweismittel und härtet dann die Umgebung auf der Grundlage der gewonnenen Erkenntnisse. Azure-native Dienste – Microsoft Sentinel, Defender for Cloud, Logic Apps, Azure Backup, Azure Site Recovery (ASR), DDoS Protection, Web Application Firewall (WAF), Traffic Manager/Front Door und Microsoft Entra – stellen die Bausteine dafür bereit. Die Design-Anforderung besteht darin, die richtige Telemetrie, Notfallzugriffswege für Identitäten (Break-Glass) und automatisierte Durchsetzungsmechanismen vorzubereiten, damit Teams innerhalb von Minuten statt Stunden handeln können.
Lebenszyklus der Incident Response und Sentinel-Operationen
Vorbereitung
- Definieren, wer was, wann und mit welchen Werkzeugen tut. Microsoft Sentinel-Workspaces vorab bereitstellen, Datenquellen (Activity Log, Ressourcenprotokolle, NSG-Flussprotokolle, Microsoft Entra Anmelde-/Auditprotokolle, Defender-Signale) anbinden und Zugriffskontrollen sowie RBAC für Analysten, Responder und Incident Commander implementieren.
- Playbooks (Logic Apps) für gängige Eindämmungsmaßnahmen wie VM-Isolierung, Widerruf von Benutzer-Tokens oder Schlüsselrotation erstellen. Quarantäne-NSGs und dedizierte „Forensik“-Subscriptions vorbereiten.
- Unveränderliche Protokollaufbewahrung über Diagnoseeinstellungen (Diagnostic Settings) in Log Analytics und in einem Azure Storage-Konto mit Unveränderlichkeit (WORM) einrichten.
Erkennung
- In Sentinel Analyse-Regeln für Anmeldeinformationsdiebstahl, seltene Anmeldemuster, verdächtige Prozessausführungen, Missbrauch von Key Vault und Datenexfiltration aktivieren. Mit UEBA- und Fusionsregeln erweitern, um unbedenkliche Ereignisse zu aussagekräftigen Incidents zu korrelieren. Regelschwellenwerte und Unterdrückung kalibrieren, um Alert Fatigue zu minimieren.
Eindämmung
- Vorab genehmigte Aktionen ausführen: NICs über NSG unter Quarantäne stellen, kompromittierte Dienstprinzipale deaktivieren, Entra-Aktualisierungstokens widerrufen, Secrets rotieren, eingehende öffentliche Endpunkte deaktivieren oder WAF in den Präventionsmodus versetzen. Sentinel-Automatisierungsregeln verwenden, um nach Schweregrad zu routen, Tags hinzuzufügen, Verantwortliche zuzuweisen und Playbooks auszulösen.
Beseitigung
- Persistenzmechanismen entfernen (Starttasks, geplante Aufträge, Cloud-Init-Skripte, bösartige Erweiterungen), Anmeldeinformationen rotieren, Golden Images neu bereitstellen und von Defender for Cloud gemeldete Schwachstellen patchen. Bei identitätsbezogenen Incidents Passwort-Resets erzwingen und den bedingten Zugriff (Conditional Access) stärken.
Wiederherstellung
- Aus Azure Backup in saubere VNets wiederherstellen; Failover mit ASR-Wiederherstellungsplänen durchführen; Integrität validieren und Secrets sowie Konfigurationen aus bekanntermaßen guten Quellen (IaC-Templates, Key Vault mit Soft Delete/Purge Protection) wiederherstellen. Sicherstellen, dass RTO und RPO eingehalten werden.
Lessons Learned
- Eine „Blameless Review“ (schuldfreie Überprüfung) durchführen. Sentinel-Regeln und Playbooks, Azure Policy-Zuweisungen, Basis-Images und Runbooks aktualisieren. Korrekturmaßnahmen in IaC kodifizieren und über Verwaltungsgruppen (Management Groups) erzwingen.
Sentinel-Triage, Beweiserhebung, Untersuchung und Fallmanagement
Triage
- Incidents nach Schweregrad, Kritikalität des Assets und Blast Radius priorisieren, unter Verwendung von Entitätsanreicherung (Host, Benutzer, IP) und Watchlists. Incident-Gruppierung nutzen, um Duplikate zu reduzieren, und die Zeitleistenansicht (Timeline View), um die Abfolge zu verstehen.
Beweiserhebung
- Bemerkenswerte Ereignisse mit Lesezeichen versehen, Rohprotokolle in unveränderlichen Speicher exportieren, Snapshots betroffener VM-Festplatten für die Offline-Analyse erstellen und Prozessbäume über Defender for Endpoint-Integrationen erfassen. Die Beweiskette (Chain of Custody) wahren, indem Hashes gespeichert und der Zugriff auf eine Forensik-Ressourcengruppe beschränkt wird.
Untersuchung
- Untersuchungsdiagramme (Investigation Graphs) und Entitätsseiten (Anmeldeverlauf des Benutzers, Prozessbaum des Hosts) verwenden. Mit KQL in SigninLogs, AuditLogs, SecurityEvent und AzureDiagnostics suchen (hunten). Ergebnisse aufzeichnen, Artefakte anhängen und IOCs für die zukünftige Erkennung taggen.
Fallmanagement
- Status (Neu, Aktiv, In Bearbeitung, Gelöst), Verantwortliche und SLA-Timer standardisieren. Sentinel mit ITSM (ServiceNow/Azure DevOps) für Ticketing und Change Control integrieren. Automatisierungsregeln können bekanntermaßen unbedenkliche Alerts automatisch schließen oder spezifische Taktiken an Tier 2 eskalieren.
Automatisierte Eindämmung und Workflow-Orchestrierung
Sentinel-Automatisierungsregeln
- Bei Erstellung/Aktualisierung eines Incidents auslösen. Dynamisch Verantwortlichkeit zuweisen, Schweregrad festlegen, Tags hinzufügen (z. B. QuarantineCandidate) und ein oder mehrere Playbooks aufrufen. Begründung: Innerhalb von Sekunden von der Erkennung zur Aktion übergehen, konsistent mit dem Prinzip der geringsten Rechte (Least Privilege) und vorab genehmigten Playbooks.
Logic Apps-Playbooks
- Gängige Aktionen: Quarantäne-NSG auf eine VM-NIC anwenden, einen Benutzer deaktivieren, Tokens widerrufen, eine IP in der WAF blockieren oder ein ITSM-Ticket mit vollständigem Kontext öffnen. Verwaltete Identitäten (Managed Identities) und Azure RBAC verwenden, um die Berechtigungen jedes Playbooks auf den exakten Ressourcensatz zu beschränken.
Defender for Cloud Workflow-Automatisierung
- Bei Empfehlungen oder Alerts (z. B. „Offener RDP-Port zum Internet“) automatisch Playbooks auslösen, um Abhilfe zu schaffen (NSG-Regeln verschärfen), Ressourcen zur Nachverfolgung zu taggen oder Besitzer zu benachrichtigen. Begründung: Sicherheitslücken schnell schließen, um den Secure Score zu verbessern und die Verweildauer von Angreifern (Attacker Dwell Time) zu verkürzen.
Beispiel: Eine VM-NIC in Sekunden unter Quarantäne stellen
# Create a high-priority deny-all inbound NSG rule and associate a quarantine NSG to the NIC
az network nsg rule create -g rg-prod -n QuarantineDenyAll --nsg-name nsg-quarantine \
--priority 100 --access Deny --direction Inbound --protocol '*' --source-address-prefixes '*' \
--source-port-ranges '*' --destination-address-prefixes '*' --destination-port-ranges '*'
az network nic update -g rg-prod -n vm1-nic --network-security-group nsg-quarantine
Token-Widerruf für einen kompromittierten Benutzer
az rest --method POST \
--uri "https://graph.microsoft.com/v1.0/users/user@contoso.com/revokeSignInSessions"
Sicherung, Replikation, RTO/RPO und Resilienz
Sicherheit von Azure Backup
Recovery Services-Tresore und Backup-Tresore
- Verwenden Sie Tresore pro Workload-Grenze und Region. Aktivieren Sie die vorläufige Löschung (Soft Delete), um vor versehentlichem/böswilligem Löschen von Backup-Elementen zu schützen; legen Sie einen angemessenen Aufbewahrungszeitraum fest, der den regulatorischen Anforderungen entspricht. Aktivieren Sie den Bereinigungsschutz (Purge Protection), wo unterstützt, um unwiderrufliche Löschungen zu verhindern.
Unveränderlichkeit (Immutability)
- Konfigurieren Sie die Unveränderlichkeit des Tresors. Verwenden Sie den entsperrten Modus (Unlocked Mode) während der anfänglichen Feinabstimmung und wechseln Sie dann in den gesperrten Modus (Locked Mode), um eine Reduzierung der Aufbewahrungsdauer oder die Manipulation von Richtlinien zu verhindern. Begründung: Stellt sicher, dass Backups einmal geschrieben und nicht mehr verändert werden können (Write-Once), eine zentrale Maßnahme gegen Ransomware.
Mehrbenutzer-Autorisierung (MUA)
- Schützen Sie kritische Backup-Vorgänge (z. B. Schutz beenden mit Datenlöschung, Tresoreinstellungen ändern) mit Azure Backup Resource Guard in einer separaten Subscription/Ressourcengruppe, die einem anderen Team gehört. Begründung: Erzwingt eine Funktionstrennung (Separation of Duties); Angreifer müssen zwei Identitäten in unterschiedlichen Geltungsbereichen kompromittieren, um die Wiederherstellbarkeit zu zerstören.
Regionsübergreifende Funktionen
- Aktivieren Sie für RSV mit GRS die regionsübergreifende Wiederherstellung (Cross-Region Restore), um eine Wiederherstellung auch dann zu ermöglichen, wenn die primäre Region nicht verfügbar ist. Stellen Sie sicher, dass die von Workloads verwendeten kryptografischen Schlüssel ebenfalls resilient sind (vorläufige Löschung/Bereinigungsschutz in Key Vault und, falls erforderlich, georedundante Wiederherstellungsplanung).
Azure Site Recovery (ASR)
Replikation
- Azure-zu-Azure, VMware/Hyper-V-zu-Azure und physische Server. Definieren Sie Replikationsrichtlinien (RPO-Schwellenwert, Aufbewahrung von Wiederherstellungspunkten, Häufigkeit von anwendungskonsistenten Snapshots). Stellen Sie den Mobility Service bereit, wo erforderlich.
Wiederherstellungspläne
- Orchestrieren Sie das Failover von mehrschichtigen Anwendungen mit Startreihenfolge, manuellen Schritten und Runbooks (z. B. DNS-Aktualisierungen, Wechsel von Verbindungszeichenfolgen). Bewahren Sie Anmeldeinformationen und Skripte in Key Vault auf.
Testfailover
- Führen Sie regelmäßige, unterbrechungsfreie Tests in einem isolierten VNet mit maskierten IPs durch. Verwenden Sie „Testfailover bereinigen“, um den Zustand zurückzusetzen. Begründung: Validiert die End-to-End-Wiederherstellung ohne Auswirkungen auf die Produktion.
Failback
- Nach der Wiederherstellung des primären Standorts führen Sie einen erneuten Schutz und ein Failback durch, wobei die Änderungen resynchronisiert werden. Planen Sie Bandbreitenfenster und Wartungsarbeiten ein, um die Geschäfts-SLAs zu erfüllen.
Auswahl der Architektur zur Erfüllung von RTO/RPO
Kurzes RPO (Sekunden bis Minuten) und niedriges RTO (Minuten)
- Bevorzugen Sie ASR oder native Anwendungsreplikation (z. B. SQL Always On, Cosmos DB Multi-Region) gegenüber Backups; halten Sie einen Hot- oder Warm-Standby vor; verwenden Sie Front Door/Traffic Manager für regionales Failover.
Moderates RPO (Stunden) und RTO (Stunden)
- Kombinieren Sie häufige Backups mit ASR für kritische Tiers; nutzen Sie Funktionen zur Backup-Beschleunigung (Instant Restore Snapshots), um die Wiederherstellungszeit zu verkürzen.
Langes RPO (Tage) und RTO (Tage)
- Nur Backup mit längerer Aufbewahrung; kostenoptimierte Archiv-Tiers.
Operative Begründung: Replikation liefert ein kurzes RPO zu höheren laufenden Kosten; Backups bieten eine günstigere langfristige Aufbewahrung, aber ein langsameres RTO/RPO. Kombinieren Sie die Ansätze pro Tier, um der Business Impact Analysis zu entsprechen.
Netzwerkverteidigung, Forensik, Kontinuität und Härtung
Reaktion auf Azure DDoS, WAF-Tuning und Failover der Datenverkehrsverwaltung
DDoS Protection Standard
- Mit VNets verknüpfen, die öffentliche IPs hosten. Bietet adaptive Echtzeit-Mitigation und Unterstützung durch DDoS Rapid Response (DRR) während Angriffen. Warnungen und Diagnosen für Sentinel konfigurieren. Begründung: Automatische Mitigation am Edge, bevor der Datenverkehr die Workloads erreicht.
WAF-Tuning
- Verwaltete OWASP-Regelsätze verwenden und in den Präventionsmodus wechseln. Ausnahmen für bekannte unbedenkliche Muster hinzufügen, bei Bedarf die Überprüfung von Anforderungsgröße/-body aktivieren und benutzerdefinierte Regeln für Zulassen/Verweigern sowie Ratenbegrenzung für missbräuchliche IPs oder Regionen erstellen. Kontinuierliche Verfeinerung basierend auf Protokollen.
Traffic-Failover
- Traffic Manager (DNS-basiert) mit Prioritätsrouting und niedrigem TTL für regionales Failover oder Azure Front Door (Anycast L7) für schnelleres, durch Integritätsprüfungen gesteuertes Failover und globalen Ingress verwenden. Kritische Endpunkte prüfen und regelmäßige Failover-Übungen durchführen.
Forensik: Protokolle und unveränderliche Aufbewahrung
Activity Log
- Aktionen auf der Steuerungsebene (Erstellen/Löschen/Rollenzuweisungen) überwachen. An Sentinel und an Azure Storage mit Unveränderlichkeit für die rechtssichere Aufbewahrung (Legal Hold) streamen.
Ressourcenprotokolle
- Über Diagnoseeinstellungen für wichtige Dienste (Key Vault, App Service, Storage, SQL, AKS) aktivieren. An Log Analytics, Event Hub und unveränderlichen Storage weiterleiten.
NSG-Flow-Protokolle
- In Network Watcher aktivieren; mit Traffic Analytics analysieren, um Netzwerkflüsse bei Vorfällen zu rekonstruieren.
Anmelde- und Audit-Protokolle von Microsoft Entra
- Für Identitätsuntersuchungen in Sentinel erfassen. Riskante Anmeldungen und Ergebnisse des bedingten Zugriffs überwachen. Aufbewahrungsfrist über das Log Analytics-Archiv und/oder den Export in unveränderlichen Storage verlängern.
Notfallzugriff- und Kontinuitätskontrollen
- Mindestens zwei reine Cloud-Konten für den Notfallzugriff (Break-Glass) mit der Rolle „Globaler Administrator“ pflegen, die lange, komplexe Passwörter haben und von Richtlinien für bedingten Zugriff und MFA ausgeschlossen sind, um Ausfälle zu überstehen. Anmeldeinformationen sicher offline speichern und jede Anmeldung mit Echtzeit-Warnungen überwachen. Ansonsten nur eingeschränkte dauerhafte Rollen zuweisen; PIM für Just-in-Time-Rechteerweiterung im Normalbetrieb verwenden.
- Verfahren für den Notfallzugriff dokumentieren, einschließlich der Entra-Funktion „Zugriff zum Verwalten aller Azure-Abonnements erhöhen“ und der Schritte zur Zuweisung der Rolle „Besitzer“ auf der Stammverwaltungsgruppe, falls RBAC nicht funktioniert.
- Kritische Ressourcen mit Verwaltungssperren (CanNotDelete) schützen und den Geltungsbereich von Rollenzuweisungen mithilfe von Verwaltungsgruppen einschränken.
Härtung nach einem Vorfall
- Azure Policy auf Verwaltungsgruppenebene anwenden, um Baselines durchzusetzen (z. B. DeployIfNotExists für Antimalware-Erweiterungen, Datenträgerverschlüsselung, Diagnoseeinstellungen, JIT-VM-Zugriff). Nichtkonformität mit Richtlinien-Wartungstasks beheben.
- Die Erkennung durch Tuning von Sentinel-Analysen (neue IOCs hinzufügen, Schwellenwerte anpassen), Umwandlung erfolgreicher Suchen (Hunts) in geplante Regeln und Hinzufügen von Automatisierungsregeln zur Triage verbessern.
- Sicherheits-Baselines aktualisieren (Images, Key Vault-Richtlinien, NSG/WAF-Regeln). Alle Änderungen als Code (Bicep/Terraform) erfassen und mit CI/CD und Change Control validieren. Secure Score und die Einhaltung gesetzlicher Vorschriften verfolgen, um den Fortschritt zu messen.
Praktisches Problemszenario
Bei Starbucks kommt es zu einem Anstieg verdächtiger Anmeldungen, gefolgt von anomalem ausgehendem Speicherverkehr (Egress) aus einem Produktionsabonnement, das eine Bestell-API hostet. Das Sicherheitsteam muss den Vorfall eindämmen, untersuchen und den Dienst wiederherstellen, während es Beweise sichert und eine RTO von zwei Stunden sowie eine RPO von 15 Minuten für die API-Schicht einhält.
- Triage automatisieren und den Explosionsradius eindämmen
- In Sentinel löst eine Automatisierungsregel bei Vorfällen mit hohem Schweregrad, die Entitäten aus der Ressourcengruppe der Bestell-API enthalten, aus, weist den diensthabenden Analysten zu, versieht den Vorfall mit dem Tag QuarantineCandidate und führt ein Playbook aus, um:
- Sitzungen für den kompromittierten Benutzer zu widerrufen.
- Eine Quarantäne-NSG auf die NICs der API-VM-Skalierungsgruppe anzuwenden.
- Eine benutzerdefinierte WAF-Regel hinzuzufügen, um die angreifenden IP-Bereiche zu blockieren.
- Begründung: Die Automatisierung führt vorab genehmigte Aktionen mit den geringsten Rechten innerhalb von Sekunden aus, was die Verweildauer des Angreifers verkürzt und weiteren Datenabfluss verhindert.
- Beweissicherung durch Unveränderlichkeit
- Das Playbook erstellt Snapshots der betroffenen VM-Betriebssystem-/Datenträger und exportiert das Activity Log, NSG-Flow-Protokolle und die Protokolle des Speicherkontos für die Zielcontainer in ein Azure Storage-Konto mit zeitbasierter Unveränderlichkeit und rechtssicherer Aufbewahrung (Legal Hold). Lesezeichen und KQL-Abfragen werden dem Sentinel-Vorfall angehängt.
- Begründung: Unveränderlicher Speicher gewährleistet die Beweiskette (Chain of Custody); Snapshots ermöglichen eine Offline-Forensik, ohne die kompromittierten Systeme zu verändern.
- Dienstwiederherstellung gemäß RTO/RPO
- Da die API-Schicht durch ASR mit einer Frequenz von 15 Minuten für anwendungskonsistente Snapshots geschützt ist, führt das Team einen priorisierten Wiederherstellungsplan aus, um ein Failover der API-Schicht in die gekoppelte Region durchzuführen. Azure Front Door führt ein auf Integritätsprüfungen basierendes Failover zum sekundären Endpunkt durch.
- Begründung: Die Replikation erfüllt die RPO von 15 Minuten, und das orchestrierte Failover plus Front Door-Routing erfüllt die RTO von zwei Stunden, ohne dass eine Wiederherstellung aus einem Backup erforderlich ist.
- Identitäten und Geheimnisse bereinigen
- Privilegierte Administratoren rotieren Anmeldeinformationen und Schlüssel in Key Vault (mit aktiviertem Soft Delete und Purge Protection) und deaktivieren das kompromittierte Konto, wobei sie einen stärkeren bedingten Zugriff für privilegierte Rollen erzwingen.
- Begründung: Geheimnisse und Identitäten sind gängige Persistenzvektoren; eine schnelle Rotation und strengere Zugriffskontrollen unterbinden den erneuten Zugriff des Angreifers.
- Härtung und Validierung nach dem Vorfall
- Das Team optimiert die verwalteten WAF-Regeln, fügt eine benutzerdefinierte Regel zur Ratenbegrenzung hinzu, bindet das Speicherkonto mit Anomaliewarnungen in Defender for Cloud ein und stellt Azure Policy bereit, um Diagnoseeinstellungen und NSG-Baselines standardmäßig zu erzwingen. Eine Sentinel-Analyse-Regel wird hinzugefügt, um ähnliche Egress-Muster zu erkennen, und es wird eine Übung geplant, um die ASR-Wiederherstellungspläne vierteljährlich zu validieren.
- Begründung: Die Institutionalisierung von Korrekturen durch Richtlinien und Analysen reduziert das erneute Auftreten und stellt sicher, dass die Resilienz überprüfbar und wiederholbar bleibt.
← Hybrid- und Multi-Cloud-Sicherheit · Alle Domänen
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →