Erfassen von Windows-Ereignissen mit dem Azure Monitor-Agent

  • Artikel

Windows-Ereignisse sind eine der Datenquellen, die in einer Datensammlungsregel (Data Collection Rule, DCR) verwendet werden. Details zur Erstellung der DCR finden Sie unter Sammeln von Daten mit dem Azure Monitor-Agent. Dieser Artikel enthält weitere Details zum Datenquellentyp für Windows-Ereignisse.

Windows-Ereignisprotokolle sind eine der am häufigsten verwendeten Datenquellen für Windows-Computer mit Azure Monitor-Agent, da es sich um eine allgemeine Quelle für Integrität und Informationen für das Windows-Betriebssystem und die darauf ausgeführten Anwendungen handelt. Sie können Ereignisse aus Standardprotokollen, wie z. B. „System“ und „Anwendung“, und aus benutzerdefinierten Protokollen sammeln, die von zu überwachenden Anwendungen erstellt wurden.

Voraussetzungen

Konfigurieren der Windows-Ereignisdatenquelle

Wählen Sie im Schritt Sammeln und übermitteln der DCR die Option Windows-Ereignisprotokolle aus der Dropdownliste Datenquellentyp aus. Wählen Sie aus einer Reihe von zu erfassenden Protokollen und Schweregraden aus.

Screenshot: Konfiguration einer Windows-Ereignisdatenquelle in einer Datensammlungsregel

Wählen Sie Benutzerdefiniert aus, um Ereignisse mithilfe von XPath-Abfragen zu filtern. Sie können dann einen XPath angeben, um bestimmte Werte zu sammeln.

Screenshot: Benutzerdefinierte Konfiguration einer Windows-Ereignisdatenquelle in einer Datensammlungsregel

Sicherheitsereignisse

Es gibt zwei Methoden, mit denen Sie Sicherheitsereignisse mit dem Azure Monitor-Agent sammeln können:

  • Wählen Sie das Sicherheitsereignisprotokoll in Ihrer DCR genau wie die System- und Anwendungsprotokolle aus. Diese Ereignisse werden in Ihrem Log Analytics-Arbeitsbereich mit anderen Ereignissen an die Ereignistabelle gesendet.
  • Aktivieren Sie Microsoft Sentinel im Arbeitsbereich, der auch den Azure Monitor-Agent zum Sammeln von Ereignissen verwendet. Sicherheitsereignisse werden an das SecurityEvent-Element gesendet.

Filtern von Ereignissen mithilfe von XPath-Abfragen

Ihnen werden alle Daten, die Sie in einem Log Analytics-Arbeitsbereich sammeln, in Rechnung gestellt. Sammeln Sie daher nur die benötigten Ereignisdaten. Die Grundkonfiguration im Azure-Portal bietet Ihnen eine begrenzte Möglichkeit, Ereignisse herauszufiltern. Um weitere Filter festzulegen, verwenden Sie die benutzerdefinierte Konfiguration und geben einen XPath an, der die nicht erforderlichen Ereignisse herausfiltert.

XPath-Einträge haben folgende Form: LogName!XPathQuery. Angenommen, Sie möchten aus dem Anwendungsereignisprotokoll nur Ereignisse mit der Ereignis-ID 1035 abrufen. In diesem Fall würde die *[System[EventID=1035]]-Abfrage für diese Ereignisse XPathQuery lauten. Da Sie die Ereignisse aus dem Anwendungsereignisprotokoll abrufen möchten, lautet die XPath-Abfrage Application!*[System[EventID=1035]].

Tipp

Strategien zum Reduzieren Ihrer Azure Monitor-Kosten finden Sie unter Kostenoptimierung und Azure Monitor.

Extrahieren von XPath-Abfragen aus der Windows-Ereignisanzeige

Unter Windows können Sie die Ereignisanzeige verwenden, um XPath-Abfragen zu extrahieren (siehe folgende Screenshots).

Wenn Sie die XPath-Abfrage in das Feld auf dem Bildschirm Datenquelle hinzufügen einfügen (wie in Schritt 5 gezeigt), müssen Sie die Protokolltypkategorie gefolgt von einem Ausrufezeichen (!) anfügen.

Screenshot: Schritte zum Erstellen einer XPath-Abfrage in der Windows-Ereignisanzeige.

Tipp

Sie können das PowerShell-Cmdlet Get-WinEvent mit dem Parameter FilterXPath verwenden, um die Gültigkeit einer XPath-Abfrage zunächst lokal auf Ihrem Computer zu testen. Weitere Informationen finden Sie im Tipp in den Anweisungen unter Auf Windows-Agent-basierende Verbindungen. Das PowerShell-Cmdlet Get-WinEvent unterstützt bis zu 23 Ausdrücke. Azure Monitor-Datensammlungsregeln unterstützen bis zu 20. Das folgende Skript ist ein Beispiel hierfür:

$XPath = '*[System[EventID=1035]]'
Get-WinEvent -LogName 'Application' -FilterXPath $XPath
  • Im obigen Cmdlet ist der Wert des Parameters -LogName der erste Teil der XPath-Abfrage bis zum Ausrufezeichen (!). Der Rest der XPath-Abfrage kommt in den Parameter $XPath.
  • Wenn das Skript Ereignisse zurückgibt, ist die Abfrage gültig.
  • Wenn Sie die Meldung erhalten, dass keine Ereignisse gefunden wurden, die mit den angegebenen Auswahlkriterien übereinstimmen, ist die Abfrage möglicherweise gültig, aber es sind keine übereinstimmenden Ereignisse auf dem lokalen Computer vorhanden.
  • Wenn Sie die Meldung „Die angegebene Abfrage ist ungültig“ erhalten, ist die Abfragesyntax ungültig.

Beispiele für die Verwendung eines benutzerdefinierten XPath zum Filtern von Ereignissen:

Beschreibung XPath
Es werden nur Systemereignisse mit der Ereignis-ID 4648 gesammelt. System!*[System[EventID=4648]]
Es werden nur Ereignisse des Sicherheitsprotokolls mit der Ereignis-ID 4648 und dem Prozessnamen „consent.exe“ gesammelt. Security!*[System[(EventID=4648)]] and *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\consent.exe']]
Es werden alle kritischen, Fehler-, Warnungs- und Informationsereignisse aus dem Systemereignisprotokoll mit Ausnahme der Ereignis-ID 6 (Treiber geladen) gesammelt. System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]]
Es werden alle erfolgreichen und fehlerhaften Sicherheitsereignisse für die Ereignis-ID 4624 (Erfolgreiche Anmeldung) gesammelt. Security!*[System[(band(Keywords,13510798882111488)) and (EventID != 4624)]]

Hinweis

Eine Liste der Einschränkungen in XPath, die vom Windows-Ereignisprotokoll unterstützt werden, finden Sie unter Einschränkungen für XPath 1.0. Sie können beispielsweise die Funktionen „position“, „Band“ und „timediff“ innerhalb der Abfrage verwenden, aber andere Funktionen wie „starts-with“ und „contains“ werden derzeit nicht unterstützt.

Destinations

Windows-Ereignisdaten können an die folgenden Speicherorte gesendet werden.

Destination Tabelle/Namespace
Log Analytics-Arbeitsbereich Ereignis

Screenshot: Konfiguration eines Azure Monitor-Protokollziels in einer Datensammlungsregel

Nächste Schritte