Microsoft AZ-500: Microsoft Sentinel und Security Operations — 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

Microsoft Sentinel ist die cloud-native SIEM- und SOAR-Plattform von Azure, die auf Azure Monitor Log Analytics aufbaut. Sie zentralisiert Sicherheits-Telemetriedaten, wendet Analysen zur Bedrohungserkennung an, generiert Incidents für die Triage durch Analysten und orchestriert die automatisierte Reaktion mit Logic Apps. Ein effektiver Betrieb hängt von einer gut konzipierten Arbeitsbereichsarchitektur, einer bewussten Datenaufnahme, einer kostenbewussten Aufbewahrung, präzisen Analysen und Entitätszuordnungen sowie einem Automatisierungs- und Feinabstimmungsprozess ab, der Warnungen auf SOC-Workflows und Geschäftsrisiken ausrichtet.

Sentinel-Architektur und Datenmanagement

• Arbeitsbereiche und Überlegungen zur Mandantenfähigkeit

  • Sentinel wird pro Log Analytics-Arbeitsbereich ausgeführt. Wählen Sie die Grenzen des Arbeitsbereichs nach Datensouveränität, Latenz und administrativer Trennung. Ein einzelner „zentraler SOC“-Arbeitsbereich vereinfacht die Korrelation und das Content-Management; mehrere Arbeitsbereiche können für strenge Residenzanforderungen, Autonomie oder MSSP/Lighthouse-Modelle geeignet sein. Arbeitsbereichsübergreifende Abfragen werden unterstützt, erhöhen aber die Abfragelatenz und -kosten; bevorzugen Sie eine Konsolidierung, wenn die Korrelation zwischen Entitäten entscheidend ist.
  • Verwenden Sie ressourcenkontextbezogene RBAC für den Arbeitsbereich, um Aufgaben zu trennen: Sentinel Reader für Dashboards, Responder für die Incident-Bearbeitung, Contributor für das Content-Management und Automation Contributor für Playbooks.

• Erfassungspfade

  • Daten gelangen über native Konnektoren, Azure Monitor Agents oder APIs in Tabellen im Arbeitsbereich. Bevorzugen Sie native Konnektoren für Microsoft-Quellen (optimiertes Schema, Zuverlässigkeit) und AMA+DCR für Windows/Syslog, um Filterung und Kontrolle über den Tarif pro Tabelle zu erhalten. Leiten Sie für Geräte von Drittanbietern CEF über Syslog an die Tabelle CommonSecurityLog weiter, um von integrierten Parsern und Analyseinhalten zu profitieren.

• Aufbewahrung, Archivierung und Suche

  • Konfigurieren Sie die Aufbewahrung pro Tabelle, um heiße Daten (für interaktive Analysen) für das operative Erkennungsfenster (üblicherweise 30–120 Tage) vorzuhalten. Archivieren Sie ältere Daten für bis zu 7 Jahre im Log Analytics Archive-Tier, um Compliance-Anforderungen zu drastisch niedrigeren Kosten zu erfüllen; verwenden Sie Search Jobs oder Restore für Untersuchungen. Operative Begründung: Bewahren Sie nur das auf, was Analysten routinemäßig für ihre Analysen benötigen; archivieren Sie den Rest, um Audit-/Regulierungsanforderungen zu erfüllen, ohne die Kosten für den schnellen Zugriff zu erhöhen.

• Kostenkontrolle

  • Commitment Tiers (Kapazitätsreservierungen) reduzieren die Erfassungskosten für stabile Datenmengen vorhersagbar; aktivieren Sie diese nach Ermittlung einer 30–60-tägigen Baseline, um eine Überbuchung zu vermeiden.
  • Abrechnungstarife auf Tabellenebene: Verwenden Sie den Analytics-Modus für sicherheitskritische Tabellen (SecurityEvent, SignInLogs, CommonSecurityLog). Verwenden Sie Basic Logs für ausführliche, weniger wertvolle Diagnosedaten, die Sie selten abfragen; platzieren Sie niemals sicherheitsrelevante Tabellen mit hoher Signalqualität in Basic, da diese den vollen Abfragefunktionsumfang verlieren und nicht für Warnungen qualifiziert sind.
  • Transformationen zur Erfassungszeit mit DCRs verwerfen oder maskieren Felder und Zeilen (Minimierung von PII, Rauschunterdrückung) vor der Abrechnung. Operativ ist die Eliminierung von Rauschen vor der Erfassung die wirksamste Methode zur Kosten- und Qualitätskontrolle.
  • Richten Sie tägliche Obergrenzen für den Arbeitsbereich und Warnungen bei anomalen Anstiegen ein, um Fehlkonfigurationen oder Angriffe, die Protokollstürme erzeugen, zu erkennen.

Datenkonnektoren und Erfassung

• Azure Activity

  • Verwenden Sie den Azure Activity-Konnektor, um Vorgänge auf der Steuerungsebene auf Abonnementebene über Diagnoseeinstellungen in die Tabelle AzureActivity zu streamen. Begründung: Erfasst Rollenänderungen, Richtlinienaktualisierungen und Bereitstellungen – erstklassige Indikatoren für die Eskalation von Angreiferprivilegien oder Manipulation.

• Microsoft Entra ID (Azure AD)

  • Aktivieren Sie die Konnektoren für AuditLogs und SignInLogs. Erfassen Sie optional angereicherte Azure AD-Protokolle, falls lizenziert. Begründung: Identität ist die primäre Angriffsfläche; Anmeldeanomalien und Verzeichnisänderungen untermauern die meisten Erkennungen und UEBA.

• Microsoft Defender-Produkte

  • Die Konnektoren für Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps und Defender for Cloud liefern hochwertige Warnungen und Telemetriedaten. Begründung: Microsoft-Sicherheitswarnungen sind stark korreliert und erhöhen die Qualität von Incidents; erfassen Sie sie, um Fusion und Microsoft-Sicherheitsregeln mit minimaler Feinabstimmung zu unterstützen.

• Windows-Ereignisse

  • Verwenden Sie den Azure Monitor Agent (AMA) mit DCR: Windows Security Events in die Tabelle SecurityEvent (Common, Minimal oder All) für DCs und kritische Server; allgemeine Windows Event-Kanäle nach Bedarf in die Tabelle WindowsEvent. Begründung: SecurityEvent ist das Rückgrat für die Authentifizierungs- und Prozessüberwachung; DCR-Filterung reduziert Rauschen (z. B. Ausschluss von 4688 ohne CommandLine).

• Syslog und CEF

  • Für Linux wählt die AMA Syslog DCR Facilities/Severities für die Syslog-Tabelle aus. Leiten Sie für Firewalls/IDS/EDR von Drittanbietern CEF an den Agent-basierten Log Analytics-Forwarder oder eine AMA-basierte Erfassung weiter, die in CommonSecurityLog landet; verwenden Sie die Parser-Inhalte des Herstellers. Begründung: CEF behält normalisierte Felder bei und reduziert den Parsing-Aufwand; CommonSecurityLog schaltet vorgefertigte Erkennungen frei.

• Betriebshygiene

  • Zeitsynchronisation (NTP) und konsistente Zeitzonen der Geräte für eine genaue Korrelation.
  • Deduplizieren Sie überlappende Quellen (z. B. erfassen Sie nicht sowohl rohe als auch normalisierte Duplikate).
  • Validieren Sie das Schema mit Watchlists oder Beispielabfragen, bevor Sie Analysen aktivieren, um False Positives zu vermeiden.

Analyse, Erkennung und Untersuchung

• Typen von Analyseregeln

  • Geplante Regeln: KQL über historische Daten in einem bestimmten Rhythmus (z. B. alle 5 Minuten, 1 Stunde Rückblick). Für die meisten Erkennungen verwenden; den Rückblick so anpassen, dass er die typische Datenlatenz überschreitet, um Lücken zu vermeiden.
  • Nahezu-Echtzeit (NRT): Erkennung im Sub-Minuten-Bereich mit eingeschränktem KQL und einem festen, kurzen Rückblick. Sparsam für hochdringliche Muster verwenden, bei denen Sekunden zählen (z. B. Massenrollenzuweisung). Für eine gute Performance mit minimalen Joins und einfachen Filtern arbeiten.
  • Fusion: ML-gesteuerte, mehrstufige Korrelation über Microsoft-Signale hinweg (Defender, Entra, Cloud Apps). Begründung: Reduziert die „Alert Fatigue“ drastisch, indem ein einziger Incident für eine Angriffskette (Attack Kill Chain) erstellt wird.
  • Anomalieregeln: Benutzer-/Entitäts-Baselines mit dynamischen Schwellenwerten. Ermöglichen schnelle Erfolge bei ungewöhnlichen Geolokations-, Volumen- oder Prozessmustern; Ausschlusslisten für genehmigte Anomalien (z. B. Wartungsfenster) pflegen.
  • Microsoft-Sicherheitsregeln: Automatische Erstellung von Incidents aus Defender-Warnungen. Aktiviert lassen und Automatisierungsregeln für Routing/Schweregrad anpassen; sie liefern Signale mit hoher Zuverlässigkeit bei geringem Abstimmungsaufwand.

• Entitätszuordnung und Incidents

  • Ordnen Sie in der Regelkonfiguration KQL-Ausgabespalten den Entitäten (Account, Host, IP, URL, File) zu, um Incident-Graphen und UEBA zu unterstützen. Eine schlechte Zuordnung beeinträchtigt die Genauigkeit der Untersuchung.
  • Die Richtlinie zur Gruppierung von Warnungen beeinflusst das Incident-Volumen und den Kontext. Gruppieren Sie nach Entitäten/Zeitfenstern, um zusammengehörige Warnungen zu kombinieren, das Rauschen zu reduzieren und gleichzeitig den Handlungsverlauf zu erhalten.

• Untersuchung und UEBA

  • Incidents stellen eine Zeitachse, Beweise und zugehörige Entitäten dar; der Untersuchungsgraph baut Beziehungen automatisch aus der Entitätszuordnung und Datensuchen auf.
  • Aktivieren Sie UEBA, um Entitäten mit Peer-Baselines, Geräterollen und Risikosignalen anzureichern. Begründung: Der Kontext verkürzt die Triage-Zeit und liefert Informationen für den Umfang der Reaktion.

• KQL-Grundlagen für das Detection Engineering

  • Filtern und Projizieren

    SignInLogs
    | where TimeGenerated > ago(24h) and ResultType != 0
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
    ```

  - Parsen und Normalisieren

CommonSecurityLog
| extend Url = extract(@"request=([^;\s]+)", 1, AdditionalExtensions)
| parse DeviceCustomString1 with * "cmd=" CommandLine
```

• Verknüpfen (Joining)

    SecurityEvent
    | where EventID == 4624 and AccountType == "User"
    | summarize logons = count() by Account, bin(TimeGenerated, 1h)
    | join kind=inner (
        SignInLogs
        | summarize aad_logons = count() by UserPrincipalName, bin(TimeGenerated, 1h)
    ) on $left.Account == $right.UserPrincipalName, TimeGenerated
    ```

  - Zusammenfassen und Zeitfensteranalyse

SignInLogs
| where TimeGenerated between (ago(1d) .. now())
| summarize attempts = count(), byIP = dcount(IPAddress) by UserPrincipalName
| where attempts > 50 or byIP > 10
```

← Security Posture Management und Governance · Alle Domänen · Anwendungssicherheit und DevSecOps →

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

Microsoft durchsuchen →