Normalizacja czasu pozyskiwania

Analizowanie czasu zapytania

Jak omówiono w omówieniu ASIM, usługa Microsoft Sentinel stosuje zarówno normalizację w czasie wykonywania zapytania, jak i podczas pozyskiwania danych, aby wykorzystać zalety obu tych podejść.

Aby użyć normalizacji czasu zapytania, użyj analizatorów ujednolicających czas zapytania, na przykład _Im_Dns w zapytaniach. Normalizacja przy użyciu analizowania czasu zapytania ma kilka zalet:

  • Zachowanie oryginalnego formatu: Normalizacja czasu zapytania nie wymaga modyfikacji danych, co zachowuje oryginalny format danych wysyłany przez źródło.
  • Unikanie potencjalnego powielania danych: Ponieważ znormalizowane dane są jedynie widokiem danych oryginalnych, nie ma potrzeby przechowywania zarówno danych oryginalnych, jak i znormalizowanych.
  • Łatwiejsze opracowywanie: Ponieważ analizatory czasu zapytań przedstawiają widok danych i nie modyfikują danych, można je łatwo opracować. Tworzenie, testowanie i naprawianie analizatora można wykonać na istniejących danych. Ponadto analizatory można rozwiązać, gdy problem zostanie wykryty, a poprawka zostanie zastosowana do istniejących danych.

Analizowanie czasu pozyskiwania

Analizatory czasu zapytań ASIM są zoptymalizowane, ale analizowanie czasu zapytań może spowolnić zapytania, szczególnie w przypadku dużych zestawów danych.

Analizowanie danych podczas pozyskiwania umożliwia przekształcanie zdarzeń do znormalizowanego schematu podczas ich pozyskiwania do Microsoft Sentinel oraz przechowywanie ich w znormalizowanym formacie. Parsowanie podczas ingestii jest mniej elastyczne, a parsery są trudniejsze w opracowaniu, ale ponieważ dane są przechowywane w znormalizowanym formacie, zapewnia lepszą wydajność.

Znormalizowane dane mogą być przechowywane w natywnych znormalizowanych tabelach Microsoft Sentinel lub w tabeli niestandardowej używającej schematu ASIM. Niestandardowa tabela, której schemat jest zbliżony do schematu ASIM, ale nie jest z nim identyczny, również zapewnia korzyści pod względem wydajności związane z normalizacją podczas pozyskiwania danych.

Obecnie usługa ASIM obsługuje następujące natywne znormalizowane tabele jako miejsce docelowe dla normalizacji w czasie pozyskiwania danych:

Zaletą natywnych tabel znormalizowanych jest to, że są one domyślnie uwzględniane w analizatorach ujednolicania ASIM. Niestandardowe znormalizowane tabele można uwzględnić w parserach unifikujących, zgodnie z opisem w Zarządzanie parserami.

Łączenie czasu pozyskiwania danych i normalizacji w czasie zapytania

Zapytania powinny zawsze używać parserów unifikujących w czasie wykonywania zapytania, takich jak _Im_Dns, aby wykorzystać zarówno normalizację w czasie wykonywania zapytania, jak i w czasie pozyskiwania danych. Natywne znormalizowane tabele są uwzględniane w danych zapytań przy użyciu analizatora wycinka.

Parser zastępczy to parser wykonywany w czasie wykonywania zapytania, który jako dane wejściowe wykorzystuje znormalizowaną tabelę. Ponieważ znormalizowana tabela nie wymaga analizowania, analizator wycinka jest wydajny.

Parser pośredni udostępnia zapytaniu wywołującemu widok, który rozszerza natywną tabelę ASIM:

  • Aliasy — aby nie marnować magazynu na powtarzające się wartości, aliasy nie są przechowywane w tabelach natywnych usługi ASIM i są dodawane w czasie wykonywania zapytań przez analizatory wycinków.
  • Wartości stałe — podobnie jak aliasy i z tego samego powodu tabele znormalizowane przez usługę ASIM również nie przechowują wartości stałych, takich jak EventSchema. Analizator wycinka dodaje te pola. Znormalizowana tabela ASIM jest współdzielona przez wiele źródeł, a parsery czasu pozyskiwania mogą zmieniać wersję danych wyjściowych. W związku z tym pola, takie jak EventProduct, EventVendor i EventSchemaVersion , nie są stałe i nie są dodawane przez analizator wycinka.
  • Filtrowanie — parser stub również implementuje filtrowanie. Chociaż natywne tabele ASIM nie wymagają parserów filtrujących do osiągnięcia lepszej wydajności, filtrowanie jest potrzebne, aby umożliwić uwzględnienie ich w parserze ujednolicającym.
  • Aktualizacje i poprawki — użycie parsera zastępczego umożliwia szybsze naprawianie problemów. Jeśli na przykład dane zostały nieprawidłowo zaimportowane, adres IP mógł nie zostać wyodrębniony z pola message podczas importu. Adres IP może zostać wyodrębniony przez analizator wycinka w czasie wykonywania zapytania.

W przypadku korzystania z niestandardowych znormalizowanych tabel utwórz własny analizator wycinka w celu zaimplementowania tej funkcji i dodaj ją do analizatorów ujednolicających, jak opisano w temacie Zarządzanie analizatorami. Użyj analizatora wycinka dla tabeli natywnej, na przykład analizatora wycinka tabeli natywnej DNS i jego odpowiednika filtrowania, jako punktu początkowego. Jeśli tabela jest częściowo znormalizowana, użyj analizatora wycinka, aby wykonać wymagane dodatkowe analizy i normalizację.

Dowiedz się więcej na temat pisania analizatorów w temacie Tworzenie analizatorów ASIM.

Implementowanie normalizacji czasu pozyskiwania

Aby znormalizować dane na etapie pozyskiwania, należy użyć reguły zbierania danych (DCR). Procedura implementowania dcr zależy od metody używanej do pozyskiwania danych. Aby uzyskać więcej informacji, zobacz artykuł Transform or customize data at ingestion time in Microsoft Sentinel (Przekształcanie lub dostosowywanie danych w czasie pozyskiwania w Microsoft Sentinel).

Zapytanie transformacji KQL stanowi podstawę DCR. Wersja KQL używana w elementach DCR jest nieco inna niż wersja używana w innych miejscach w usłudze Microsoft Sentinel, aby spełnić wymagania dotyczące przetwarzania zdarzeń w potoku. W związku z tym należy zmodyfikować dowolny analizator czasu zapytania, aby używać go w funkcji DCR. Aby uzyskać więcej informacji o różnicach oraz o tym, jak przekonwertować parser używany w czasie wykonywania zapytania na parser używany na etapie pozyskiwania, zapoznaj się z ograniczeniami KQL DCR.

Zawartość pokrewna

  • Last updated on