Microsoft AZ-801: Microsoft Sentinel und Sicherheitsüberwachung — Lernleitfaden

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Teil des Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Microsoft Sentinel ist ein cloud-natives SIEM und SOAR, das Protokollerfassung, Analysen, Bedrohungserkennung, Reaktion auf Vorfälle und proaktive Suche über hybride Windows-Server-Umgebungen hinweg vereinheitlicht. Für AZ-801-Szenarien erfordert die Beherrschung das Verbinden von Windows-Sicherheitsereignissen, Linux-Syslog und CEF-Quellen von Drittanbietern in großem Umfang, das Entwickeln von Analyse-Regeln mit minimaler Latenz, das Zuordnen von Warnungen zu Entitäten für eine präzise Untersuchung und das Automatisieren der Eindämmung durch auf Logic Apps basierende Playbooks. Der Erfolg hängt auch von einer disziplinierten Architektur für Log Analytics-Arbeitsbereiche, gut verwalteten Datensammlungsregeln (DCRs) für den Azure Monitor Agent (AMA), einer soliden Aufbewahrungsstrategie und operativer Kompetenz in UEBA, Watchlists, Hunting und Workbooks ab.

Konnektoren und Datenerfassung

Windows Security Events via AMA sind die kanonische Quelle für Anmelde-, Prozesserstellungs-, Richtlinienänderungs- und andere Überwachungsereignisse von Windows Server. Aktivieren Sie den Connector „Windows Security Events via AMA“ in Microsoft Sentinel und erstellen Sie eine DCR, die die für Ihr Risikoprofil geeigneten Ereignissätze auswählt (Minimal, Common oder All oder eine benutzerdefinierte Auswahl nach Ereignis-ID). Die Daten landen hauptsächlich in der Tabelle SecurityEvent; Nicht-sicherheitsrelevante Windows-Kanäle (falls aktiviert) landen in WindowsEvent. Kombinieren Sie dies mit Gruppenrichtlinien, um sicherzustellen, dass die Sicherheitsbaseline und die Überwachungsunterkategorien (z. B. Logon/Logoff, Account Logon, Object Access, DS Access) auf den Quellservern aktiviert sind, um die notwendige Telemetrie zu erzeugen.

Syslog via AMA sammelt Daten von Linux-Servern und Netzwerkgeräten, die Syslog verwenden. Installieren Sie den AMA auf Linux-Hosts (oder einem dedizierten Linux-Collector) und konfigurieren Sie eine DCR, um die zu erfassenden Facilities und Schweregrade anzugeben. Ereignisse werden in die Tabelle Syslog geschrieben. Für Facilities mit hohem Volumen, aber geringem Wert, sollten Sie eine selektive Sammlung oder eine Transformation an der Quelle in Betracht ziehen, um Kosten und Rauschen zu kontrollieren.

CEF via AMA ermöglicht die Erfassung normalisierter Sicherheitsprotokolle von Sicherheitsprodukten von Drittanbietern (Firewalls, IDS/IPS, Proxys, EDR). Stellen Sie den AMA auf einem Linux-Collector bereit und konfigurieren Sie Ihre Anbieter so, dass sie CEF an den lokalen Syslog-Daemon (rsyslog/syslog-ng) weiterleiten, typischerweise über die Ports 514/UDP oder TCP. Aktivieren Sie in Sentinel den Datenconnector „CEF via AMA“ und verknüpfen Sie den Host über eine DCR, die CEF parst. Geparste Daten gelangen in die Tabelle CommonSecurityLog mit einem konsistenten Schema (deviceVendor, deviceProduct, destination/source-Felder und Erweiterungsattribute), was herstellerübergreifende Analysen und Korrelationen vereinfacht.

Für lokale Windows Server verwenden Sie Azure Arc-fähige Server, um eine Brücke zu Azure zu schlagen. Führen Sie das Onboarding von Maschinen mit dem Azure Connected Machine Agent durch und stellen Sie dann die AMA-Erweiterung für die Skalierung über Azure Policy bereit. Erstellen Sie DCRs, die auf Arc-Server-Bereiche abzielen, um Windows-Sicherheitsereignisse, Windows-Firewall-Protokolle und, falls Sysmon verwendet wird, eine benutzerdefinierte DCR für den Kanal Microsoft-Windows-Sysmon/Operational weiterzuleiten. Dieses Muster zentralisiert die Konfiguration, Versionierung und bereichsbasierte Zielausrichtung und gewährleistet eine konsistente Erfassung ohne manuelle Arbeit pro Host.

Arbeitsbereichsarchitektur und Datenlebenszyklus

Sentinel wird pro Bereitstellung an einen einzigen Log Analytics-Arbeitsbereich angehängt. Das Design des Arbeitsbereichs sollte regionsübergreifende Latenz und ausgehenden Datenverkehr minimieren – platzieren Sie Arbeitsbereiche am selben Standort wie die Mehrheit der Datenproduzenten und vermeiden Sie eine übermäßige Fragmentierung, die Abfragen, die Triage von Vorfällen und RBAC erschwert. Gängige Muster sind ein einziger Sicherheitsarbeitsbereich pro Mandant oder einer pro Hauptregion, wo Datenresidenz und Latenz eine Trennung erfordern. Verwenden Sie nach Möglichkeit den ressourcenkontextbezogenen Zugriff, um sicherzustellen, dass Teams Protokolle für die Ressourcen abfragen können, die ihnen gehören, ohne weitreichende Berechtigungen für den Arbeitsbereich zu benötigen, während die Sentinel-Rollen (Reader, Responder, Contributor) die SOC-Operationen steuern.

DCRs steuern, welche Telemetrietypen, Kanäle und Ereignissätze gesammelt und wohin sie gesendet werden. Behandeln Sie DCRs wie Code: standardisieren Sie Benennung, Versionskontrolle und Geltungsbereiche (Abonnements, Ressourcengruppen, Tags). Gruppieren Sie zusammengehörige Quellen und Ziele und bevorzugen Sie mehrere gezielte DCRs gegenüber einer monolithischen Regel, um den Explosionsradius und das Lebenszyklusmanagement zu vereinfachen. Bei hohen Syslog- und CEF-Volumen sollten Sie separate DCRs in Betracht ziehen, um Facility/Schweregrad unabhängig voneinander abzustimmen und gestaffelte Tests zu unterstützen.

Aufbewahrung und Kosten werden auf Tabellenebene gesteuert. Legen Sie die standardmäßige Aufbewahrungsdauer für den Arbeitsbereich fest, um die Richtlinien zu erfüllen (z. B. 90–180 Tage für die aktive Suche), und überschreiben Sie dann bei Bedarf die Aufbewahrungsdauer pro Tabelle. Tabellen mit hohem Wert (SecurityEvent, CommonSecurityLog, SecurityAlert) werden in der Regel länger aufbewahrt; ausführliche Tabellen (Syslog mit DEBUG) können kürzer aufbewahrt werden. Verwenden Sie das Archiv für eine langfristige, kostengünstige Speicherung mit Suchaufträgen; stufen Sie sie bei Bedarf für Untersuchungen auf „Hot“ hoch. Verschieben Sie gegebenenfalls einige ausführliche Tabellen (wie Syslog) in Basic Logs, um die Kosten zu senken, wobei die Abfrageeinschränkungen und die Tatsache zu beachten sind, dass bestimmte Sicherheitstabellen (z. B. SecurityEvent) nicht für Basic qualifiziert sind. Überprüfen Sie regelmäßig Datenobergrenzen, Reservierungsstufen und Erfassungstrends, um Drosselung zu vermeiden und die Kosten zu optimieren.

Analysen, Vorfälle und Automatisierung von Reaktionen

Analyseregeln sind der Motor der Erkennung. Geplante Abfrageregeln führen KQL nach einem Zeitplan (z. B. alle 5 Minuten) über einen Rückblickzeitraum (z. B. 30 Minuten) aus und unterstützen Aggregationen, Joins, Anreicherungen durch Watchlists und Unterdrückungsfenster. Sie sind ideal für gut verstandene Muster wie mehrfache fehlgeschlagene Anmeldungen gefolgt von einer erfolgreichen, Heuristiken für die laterale Bewegung oder verdächtige Prozessketten. Nahezu-Echtzeit-Regeln (NRT) minimieren die Erkennungslatenz, indem sie kontinuierlich neue Daten verarbeiten, wobei die Ausführung etwa jede Minute erfolgt und die Alarmierung innerhalb von etwa zwei Minuten stattfindet; entwerfen Sie NRT-Regeln so, dass sie prägnant sind und sich auf ingestion_time() oder enge Zeitfenster stützen, um aufwändige historische Scans zu vermeiden. Fusion-Regeln nutzen die mehrstufigen Angriffsanalysen von Microsoft, um Alarme mit geringer Signifikanz über verschiedene Produkte hinweg (z. B. Defender for Endpoint, Defender for Identity, Entra ID Protection, Drittanbieter-CEF) zu hochzuverlässigen Vorfällen für Kampagnen wie Anmeldeinformationsdiebstahl oder Ransomware zu korrelieren. Anomalieregeln nutzen integrierte ML-Vorlagen, die Baselines erlernen (z. B. ungewöhnliche Anmeldeorte, seltene Prozessausführungen) und Abweichungen melden; diese lesen üblicherweise aus BehaviorAnalytics und anderen normalisierten Quellen.

Vorfälle (Incidents) fassen mehrere Alarme, Entitäten und Beweismittel in einem einzigen Untersuchungsfall zusammen. Der Schweregrad wird durch die Analyseregel (oder dynamisch durch Fusion) zugewiesen und kann über Automatisierungsregeln eskaliert oder reduziert werden. Die Entitätszuordnung ist entscheidend für die Effektivität der Untersuchung: Ordnen Sie im Regel-Assistenten die Abfragespalten den Entitätstypen (Account, Host, IP, URL, File, Process, CloudApplication, AzureResource) zu. Eine korrekte Zuordnung füllt das Untersuchungsdiagramm (Investigation Graph), das Beziehungen zwischen Alarmen, Ereignissen und Entitäten visualisiert und das Schwenken (Pivoting) auf Konten, Hosts, Prozesse und IPs ermöglicht. Verwenden Sie Kommentare, Tags, Besitzer (Owner) und Klassifizierungen, um die Einschätzung des Analysten zu erfassen und um Workflows für die Feinabstimmung zu trainieren.

Die Automatisierung kombiniert Automatisierungsregeln und Playbooks. Automatisierungsregeln werten Metadaten von Vorfällen bei deren Erstellung oder Aktualisierung aus, um Besitzer zuzuweisen, den Schweregrad zu ändern, Tags hinzuzufügen, False Positives zu schließen oder Playbooks aufzurufen. Playbooks sind Azure Logic Apps, die mit den Microsoft Sentinel-Konnektoren erstellt werden. Durch Vorfälle ausgelöste Playbooks (Incident-triggered) reagieren auf Lebenszyklus-Ereignisse von Vorfällen (z. B. wenn ein Vorfall erstellt wird) und eignen sich für vorfallsbezogene Aktionen wie die Benachrichtigung eines Teams, die Anreicherung aller Entitäten oder die Erstellung eines ServiceNow-Tickets. Durch Alarme ausgelöste Playbooks (Alert-triggered) werden bei einzelnen Alarmen ausgeführt, bevor diese zu einem Vorfall gruppiert werden – nützlich für herstellerspezifische Anreicherungen oder eine Vortriage. Verwenden Sie verwaltete Identitäten (Managed Identity) für Playbooks, gewähren Sie die geringsten Rechte (Least Privilege) über Azure RBAC und API-Berechtigungen und parametrisieren Sie Workspace-IDs, Ticketing-Endpunkte und Pfade für Sperrlisten, um die Wiederverwendbarkeit zu fördern. Wo eine Eindämmung (Containment) gerechtfertigt ist, sollten Aktionen wie die Quarantäne von Endpunkten (Defender for Endpoint), die Deaktivierung von Konten (Entra ID), das Blockieren von IPs (Firewalls) oder der Widerruf von Sitzungen (Conditional Access) erst dann ausgeführt werden, wenn die Konfidenzschwellenwerte erreicht sind.

Proaktive Sicherheitsoperationen (Hunting, UEBA, Watchlists, Workbooks)

Threat Hunting in Sentinel basiert auf KQL-Kenntnissen und dem Hunting-Blade. Beginnen Sie mit den integrierten, nach Taktiken geordneten Hunting-Abfragen. Passen Sie diese an Ihre Umgebung an, indem Sie auf Tabellen wie SecurityEvent (Windows-Audit), Device*-Tabellen von Defender, CommonSecurityLog (CEF) und SigninLogs (Entra) verweisen. Verwenden Sie Bookmarks, um interessante Datensätze als Momentaufnahme zu erfassen, sie zu kommentieren und den Kontext im Team zu teilen. Mehrere Bookmarks können zu einem neuen oder bestehenden Incident hochgestuft werden. Livestream führt kontinuierlich ein KQL-Muster aus, um neue passende Ereignisse nahezu in Echtzeit zu erkennen – ideal für zeitlich begrenzte Untersuchungen oder Szenarien mit schnellem Anstieg von Aktivitäten. Wandeln Sie ausgereifte Hunting-Abfragen in geplante Analyseregeln um, um die Erkennungen zu operationalisieren.

UEBA (User and Entity Behavior Analytics) reichert die Erkennung mit Verhaltens-Baselines und Anomalie-Bewertungen an. Aktivieren Sie UEBA in der Sentinel-Konfiguration und stellen Sie sicher, dass Identitäts- und Aktivitätsdatenquellen (Microsoft Entra-Anmeldungen, Defender for Endpoint, Defender for Identity, M365-Aktivitäten) angebunden sind. Entitätsseiten für Benutzer und Hosts zeigen Zeitachsen, Vergleiche mit Peers, anomale Aktivitäten (seltene Anmelde-Geostandorte, ungewöhnliche Prozesse) und aggregierte Risikobewertungen. Analysten können von Incidents zu Entitätsseiten wechseln, um zu beurteilen, ob eine Aktion für diese Identität oder dieses Gerät typisch ist. Anomalie-Bewertungen und -Sequenzen helfen dabei, die Triage zu priorisieren und Hypothesen schnell zu bestätigen oder zu widerlegen.

Watchlists stellen schnelle, von Analysten gepflegte Referenzdaten bereit. Erstellen Sie Watchlists aus CSV-Uploads oder einem Storage-Account-Pfad, definieren Sie einen Alias und wählen Sie eine Schlüsselspalte für effiziente Lookups aus. Verwenden Sie die Funktion watchlist() in KQL für Joins – gängige Anwendungsfälle sind Allow-/Deny-Listen für administrative Konten, sensible Hosts, sanktionierte Domains oder VIP-Benutzer. Integrieren Sie Watchlists in Analyseregeln, um bekannte unbedenkliche Aktivitäten zu unterdrücken (Reduzierung von False Positives) oder um den Schweregrad zu erhöhen, wenn eine Übereinstimmung ein kritisches Asset betrifft. Integrieren Sie sie mit Threat Intelligence, indem Sie Watchlists mit der Tabelle ThreatIntelligenceIndicator für zusätzlichen Kontext verknüpfen (z. B. Anreicherung erkannter IPs mit internem Schweregrad oder Fallnotizen) oder indem Sie kuratierte TI-Feeds in eine Watchlist für schnellen Zugriff und Overrides umwandeln.

Workbooks ermöglichen Überwachung und bieten Transparenz für die Führungsebene. Beginnen Sie mit integrierten Vorlagen wie Security Operations Efficiency, Active Directory Sign-ins, Fusion Detections und UEBA Insights. Erstellen Sie benutzerdefinierte Workbooks mit KQL-Abfragen, Parametern und Visualisierungen, um SOC-Dashboards für den Zustand der Datenerfassung (Ingestion Health), die Regel-Performance, Incident-SLAs und aufkommende Bedrohungen zu erstellen. Wenden Sie RBAC auf die Workbook-Ressource an und parametrisieren Sie Abonnements, Workspaces und Zeitbereiche, sodass dasselbe Workbook von verschiedenen Teams genutzt werden kann. Kombinieren Sie Kacheln aus mehreren Tabellen, um Haltung (Posture, mit Defender for Cloud), Erkennungen (Sentinel) und Reaktionsmetriken in einer einzigen Ansicht zu korrelieren.

Praktisches Problemszenario

Spotify muss die Sicherheitsüberwachung für 2.000 Windows Server in Azure und lokalen Rechenzentren sowie für Firewalls und Proxys von Drittanbietern zentralisieren. Sie benötigen Erkennungen mit geringer Latenz für den Missbrauch von Anmeldeinformationen, automatisiertes Ticketing und Containment sowie übersichtliche Dashboards und Hunting-Workflows für das SOC.

Onboarding von hybriden Servern mit Azure Arc und AMA

Führen Sie das Onboarding von Azure Arc-fähigen Servern skaliert mithilfe von Azure Policy durch und weisen Sie dann die AMA-Erweiterungsrichtlinie dem Arc-Geltungsbereich (Scope) zu. Erstellen Sie DCRs für „Windows Security Events via AMA“ (Common Set), Windows Firewall und eine benutzerdefinierte DCR für Sysmon, sofern installiert. Dieser Ansatz ermöglicht eine konsistente, zentral verwaltete Sammlung ohne host-spezifisches Scripting und stellt sicher, dass die Tabelle SecurityEvent für Identitäts- und Prozessanalysen gefüllt wird.

Erfassen von Netzwerk- und Sicherheits-Appliance-Telemetrie über Syslog und CEF

Richten Sie eine Linux-Collector-VM mit AMA ein. Konfigurieren Sie „Syslog via AMA“ für die relevanten Facilities und aktivieren Sie „CEF via AMA“, um CEF-Daten von Firewalls und Proxys in die Tabelle CommonSecurityLog zu parsen. Die Verwendung von CEF normalisiert Daten von verschiedenen Anbietern, was die Portabilität von Regeln und einfache Joins über verschiedene Quellen hinweg ermöglicht.

Entwickeln von Analysen für Geschwindigkeit und Genauigkeit

Aktivieren Sie Fusion, um mehrstufige Angriffe mit minimalem Tuning zu erfassen. Erstellen Sie NRT-Regeln für gehäufte fehlgeschlagene Anmeldungen, gefolgt von einer erfolgreichen Anmeldung auf privilegierten Konten, unter Verwendung von SecurityEvent und ingestion_time(), um eine Erkennung in unter zwei Minuten zu gewährleisten. Erstellen Sie geplante Regeln für Lateral-Movement-Muster (z. B. Process Create von net.exe auf Servern, verbunden mit ungewöhnlichen Administratorkonten) und für Anomalien beim Proxy-Egress, die mit Watchlists für VIPs und Kronjuwelen-Hosts verknüpft sind. Diese Mischung minimiert die MTTR und dämmt gleichzeitig False Positives ein.

Zuordnen von Entitäten und Gestalten von Incidents

Ordnen Sie in jeder geplanten Regel die Entitäten Account, Host, IP und Process aus den Abfragespalten zu. Verwenden Sie Automatisierungsregeln, um Incidents nach Geschäftsbereich (abgeleitet aus Host-Tags) zuzuweisen, den Schweregrad zu standardisieren, MITRE-Tags hinzuzufügen und bekannte Test-Signale automatisch zu schließen. Eine korrekte Zuordnung ermöglicht es dem Investigation Graph, Beziehungen darzustellen, durch die Spotifys Analysten schnell navigieren (pivoten) können.

Automatisieren von Anreicherung, Ticketing und Containment mit Playbooks

Erstellen Sie ein durch einen Incident ausgelöstes Playbook, das alle Konten und Hosts anreichert (Graph-Lookups, Geräterisiko), in Teams postet und ein Jira-Ticket öffnet. Ein separates, durch einen Alert ausgelöstes Playbook reichert spezifische CEF-Alerts mit Anbieter-APIs an. Verwenden Sie Managed Identities mit Least-Privilege-RBAC und bedingten Verzweigungen, die Geräte nur dann isolieren (über Defender for Endpoint) oder Benutzer deaktivieren (über Entra ID), wenn Konfidenzschwellenwerte (z. B. mehrere bestätigende Alerts und eine hohe UEBA-Bewertung) erreicht werden. Dies erhält die Geschäftskontinuität und ermöglicht gleichzeitig eine schnelle, gesteuerte Reaktion.

Aktivieren von UEBA und Operationalisieren des Huntings

Schalten Sie UEBA ein und validieren Sie die Datenquellen (SigninLogs, M365-Aktivität, Defender-Signale). Schulen Sie Analysten darin, von Incidents zu Entitätsseiten zu wechseln, um Anomalie-Bewertungen und Peer-Vergleiche zu prüfen. Wandeln Sie zwei hochwertige Hunting-Abfragen – „Neue Remote-Admin-Tools auf Servern“ und „Seltene externe IP-Exfiltrationsmuster“ – in geplante Analysen um, sobald sie über Bookmarks und Livestream validiert wurden. UEBA in Kombination mit diszipliniertem Hunting verbessert die Erkennung neuartiger Techniken.

Steuern des Datenlebenszyklus und Visualisieren der Haltung (Posture)

Setzen Sie die Aufbewahrungsfrist für SecurityEvent und CommonSecurityLog auf 180 Tage, für ausführliches Syslog auf 30 Tage mit einer Archivierung für 1 Jahr, und überwachen Sie die Kosten mit Commitment Tiers. Veröffentlichen Sie ein benutzerdefiniertes SOC-Workbook, das den Zustand der Datenerfassung (Ingestion Health), die „lautesten“ Regeln, MTTA/MTTR, Incident-Warteschlangen nach Schweregrad und UEBA-Anomalien im Zeitverlauf verfolgt. Dies schafft Transparenz für die Führungsebene und treibt die kontinuierliche Optimierung voran.

Jedes Werkzeug wurde aufgrund seiner zweckmäßigen Stärke ausgewählt: Arc und AMA+DCR liefern eine skalierbare, richtliniengesteuerte Datenerfassung; CEF stellt normalisierte Sicherheitslogs von verschiedenen Anbietern sicher; Fusion und NRT senken die Erkennungslatenz ohne übermäßiges Tuning; Entitätszuordnung und der Investigation Graph beschleunigen die Triage; Playbooks bieten eine gesteuerte, identitätsbasierte Automatisierung; UEBA liefert Verhaltenskontext; Hunting-Tools lassen Erkennungen reifen; und Workbooks halten den Betrieb messbar und sichtbar.

← Microsoft Defender for Cloud und Endpunktsicherheit · Alle Domänen · Sicherheit von Active Directory Domain Services →

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