Sicherheitsereignisse untersuchen? Microsoft Sentinel konfigurieren

Eine Ressourcengruppe verschwindet aus deinem Abonnement. Du musst klären, wer sie wann gelöscht hat und ob die Aktion erwartet war. Microsoft Sentinel sammelt sicherheitsrelevante Protokolle, erkennt ausgewählte Ereignisse und bündelt Warnungen zu untersuchbaren Vorfällen. Diese Übung erkennt die Löschung einer leeren Testressourcengruppe.

Workspace erstellen und Protokolle verbinden

Die Protokolle benötigen einen Speicherort, bevor Sentinel sie analysieren kann. Ein Log Analytics Workspace speichert Ereignisse in Tabellen; Sentinel ergänzt Erkennungsregeln, Warnungen und die Untersuchung von Vorfällen. Du kannst Sentinel auch auf einem bestehenden Workspace aktivieren.

Erstelle unter Log Analytics workspaces → Create:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-sentinel-test-weu
Workspace: law-ctsentinelweu
Region: West Europe

Öffne Microsoft Sentinel → Create, wähle law-ctsentinelweu und füge Sentinel hinzu. Prüfe die angezeigten Preise oder Testbedingungen. Du benötigst Berechtigungen zum Erstellen des Workspaces, zur Sentinel-Konfiguration und für Diagnoseeinstellungen des Abonnements; dein Owner-Konto auf Abonnementebene deckt diese Übung ab.

Öffne in Sentinel Content hub, suche Azure Activity und installiere die Lösung. Ihr Connector verwendet Diagnoseeinstellungen des Abonnements. Verbinde dieses einzelne Übungsabonnement direkt über Subscriptions → CloudTrips TEST → Activity log → Export Activity Logs → Add diagnostic setting.

Name: activity-to-sentinel
Logs: Administrative
Destination: Send to Log Analytics workspace
Workspace: law-ctsentinelweu

Speichere. Administrative Protokolle erfassen Änderungen an Ressourcen im gesamten Abonnement. Neue Ereignisse landen in der Tabelle AzureActivity des Workspaces.

Erstelle eine separate, leere Ressourcengruppe rg-ctsentinel-event-weu in West Europe. Lösche ausschließlich diese leere Gruppe, um das Testereignis auszulösen. Notiere den Löschzeitpunkt.

KQL (Kusto Query Language) durchsucht und analysiert diese Tabellen. In der folgenden Abfrage filtert where die Ereignisse, project wählt die angezeigten Spalten aus und jedes | übergibt die Ergebnisse an den nächsten Schritt.

Öffne Logs im Sentinel-Workspace, wechsle bei Bedarf in den KQL mode und führe aus:

AzureActivity
| where TimeGenerated > ago(2h)
| where ResourceGroup =~ "rg-ctsentinel-event-weu"
| where OperationNameValue =~ "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE"
| where ActivityStatusValue =~ "Success"
| project TimeGenerated, Caller, CallerIpAddress,
          OperationNameValue, ResourceGroup, ResourceId, CorrelationId

Vergleiche TimeGenerated in UTC, Caller, Operation und Ressourcengruppenname mit deiner Aktion. CorrelationId verbindet Datensätze derselben Operation. Die erste Übertragung kann dauern; wiederhole die Abfrage, bis das Ereignis erscheint. Fehlt die Tabelle oder bleibt sie leer, prüfe den Zielworkspace der Diagnoseeinstellung und erzeuge nach aktiver Erfassung eine neue Testlöschung.

Aus der Abfrage eine Erkennungsregel erstellen

Öffne Microsoft Defender portal → Advanced hunting, wähle den Workspace law-ctsentinelweu, füge die obige Abfrage ein und wähle Run query. Klicke anschließend auf Create detection rule. Verwende CloudTrips - Test resource group deleted als Namen, Low als Schweregrad und lasse die Regel aktiviert. Behalte die Abfrage aus Advanced hunting.

Custom detection name: CloudTrips - Test resource group deleted
Frequency: Custom
Run every: 5 minutes
Lookback: 2 hours
MITRE ATT&CK: T1485 Data Destruction

Trage unter Alert settings → Alert details ein:

Alert title: CloudTrips - Test resource group deleted
Description: Erkennt die erfolgreiche Löschung der CloudTrips-Testressourcengruppe. Prüfe Benutzer, Quell-IP und Zeitpunkt, um festzustellen, ob die Löschung autorisiert war.

Trage unter Alert settings → Entity mapping ein:

Impacted Assets
Entity: Azure resource
Identifier: ResourceId
Column: ResourceId

Related Evidence
Entity: IP
Identifier: Address
Column: CallerIpAddress

Die vollständige Ressourcen-ID identifiziert die gelöschte Gruppe; die IP bezeichnet die Anfragequelle. Fehlt eine Spalte, ergänze sie in der project-Ausgabe, führe die Abfrage erneut aus und öffne die Regelerstellung erneut. Prüfe und erstelle die Regel.

Die Regel sucht alle fünf Minuten nach der erfolgreichen Löschung. Der Rückblick von zwei Stunden berücksichtigt aktuelle Übungsereignisse; passende Ergebnisse lösen Warnungen aus. Plane Zeit für die Regelausführung und Vorfallerstellung ein. Ist dein Ereignis älter als zwei Stunden, erstelle und lösche dieselbe leere Testgruppe erneut.

Öffne im Defender-Portal Incidents im Navigationsmenü, um die erzeugte Warnung zu untersuchen.

Vorfall untersuchen

Öffne Incidents, aktualisiere die Liste und wähle den Vorfall mit deiner Testwarnung. Weise ihn dir zu und setze den Status je nach Portal auf Active oder In progress. Öffne die Warnung und ihre Ereignisse; prüfe die zugeordnete Quell-IP, sofern verfügbar.

Vergleiche Benutzer, UTC-Zeit, Quell-IP und gelöschte Gruppe mit deinem Test. Damit klärst du, wer die Aktion ausgeführt hat und was betroffen war. Dokumentiere die absichtliche Testlöschung als Kommentar und schließe den Vorfall mit Benign positive / Suspicious but expected: Die Regel hat eine erwartete Aktion korrekt erkannt.

Abschließen

Deaktiviere die Testregel. Behalte den Workspace bei Bedarf für die nächsten Sentinel-Übungen. Zum Entfernen der Übung löschst du zuerst activity-to-sentinel aus den Diagnoseeinstellungen des Abonnement-Aktivitätsprotokolls und anschließend rg-cloudtrips-sentinel-test-weu. Prüfe bei weiterem Betrieb die Kosten für Datenerfassung und Aufbewahrung.