Normalizacja czasu pozyskiwania

  • Artykuł

Analizowanie czasu zapytania

W ramach dyskusji na temat przeglądu karty ASIM usługa Microsoft Sentinel używa zarówno czasu zapytania, jak i normalizacji czasu pozyskiwania, aby korzystać z zalet każdego z nich.

Aby użyć normalizacji czasu zapytania, użyj czasu ujednolicania analizatorów zapytań, takich jak _Im_Dns w zapytaniach. Normalizacja przy użyciu analizowania czasu zapytania ma kilka zalet:

  • Zachowanie oryginalnego formatu: normalizacja czasu kwerendy nie wymaga modyfikacji danych, co pozwala zachować oryginalny format danych wysyłany przez źródło.
  • Unikanie potencjalnego zduplikowanego magazynu: ponieważ znormalizowane dane są tylko widokiem oryginalnych danych, nie ma potrzeby przechowywania zarówno oryginalnych, jak i znormalizowanych danych.
  • Łatwiejsze programowanie: ponieważ analizatory czasu zapytań przedstawiają widok danych i nie modyfikują danych, można je łatwo opracowywać. Tworzenie, testowanie i naprawianie analizatora można wykonać na istniejących danych. Ponadto analizatory można rozwiązać po wykryciu problemu, a poprawka zostanie zastosowana do istniejących danych.

Analizowanie czasu pozyskiwania

Podczas gdy analizatory czasu zapytania ASIM są zoptymalizowane, analizowanie czasu zapytania może spowolnić zapytania, zwłaszcza w przypadku dużych zestawów danych.

Analizowanie czasu pozyskiwania umożliwia przekształcanie zdarzeń w znormalizowany schemat podczas pozyskiwania do usługi Microsoft Sentinel i przechowywania ich w znormalizowanym formacie. Analizowanie czasu pozyskiwania jest mniej elastyczne, a analizatory są trudniejsze do opracowania, ale ponieważ dane są przechowywane w znormalizowanym formacie, zapewnia lepszą wydajność.

Znormalizowane dane można przechowywać w natywnych tabelach znormalizowanych przez usługę Microsoft Sentinel lub w niestandardowej tabeli korzystającej ze schematu ASIM. Tabela niestandardowa, która ma schemat zbliżony do schematu ASIM, ale nie identyczna, zapewnia również korzyści z wydajności normalizacji czasu pozyskiwania.

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

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

Łączenie normalizacji czasu pozyskiwania i czasu zapytania

Zapytania powinny zawsze używać czasu ujednolicania analizatorów zapytań, takich jak _Im_Dns korzystanie z czasu zapytania i normalizacji czasu pozyskiwania. Natywne znormalizowane tabele są uwzględniane w danych zapytanych przy użyciu analizatora wycinków.

Analizator wycinków jest analizatorem czasu zapytania, który używa jako danych wejściowych znormalizowanej tabeli. Ponieważ znormalizowana tabela nie wymaga analizowania, analizator wycinków jest wydajny.

Analizator wycinków przedstawia widok zapytania wywołującego, który dodaje do tabeli natywnej ASIM:

  • Aliasy — aby nie marnować miejsca na powtarzające się wartości, aliasy nie są przechowywane w tabelach natywnych ASIM i są dodawane w czasie zapytania przez analizatory wycinków.
  • Wartości stałe — podobnie jak aliasy i z tego samego powodu znormalizowane tabele ASIM również nie przechowują wartości stałych, takich jak EventSchema. Analizator wycinków dodaje te pola. Znormalizowana tabela ASIM jest współużytkowana przez wiele źródeł, a analizatory czasu pozyskiwania mogą zmieniać ich wersję wyjściową. W związku z tym pola, takie jak EventProduct, EventVendor i EventSchemaVersion , nie są stałe i nie są dodawane przez analizator wycinków.
  • Filtrowanie — analizator wycinków implementuje również filtrowanie. Podczas gdy tabele natywne ASIM nie wymagają analizatorów filtrowania w celu uzyskania lepszej wydajności, filtrowanie jest potrzebne do obsługi dołączania do analizatora ujednolicania.
  • Aktualizacje i poprawki — używanie analizatora wycinkowego umożliwia szybsze rozwiązywanie problemów. Jeśli na przykład dane zostały pozyskane niepoprawnie, adres IP mógł nie zostać wyodrębniony z pola komunikatu podczas pozyskiwania. Adres IP można wyodrębnić za pomocą analizatora wycinków w czasie zapytania.

W przypadku korzystania z niestandardowych znormalizowanych tabel utwórz własny analizator wycinków, aby zaimplementować tę funkcję i dodaj ją do ujednolicających analizatorów zgodnie z opisem w temacie Manage Parsers (Zarządzanie analizatorami). Użyj analizatora wycinków dla tabeli natywnej, takiej jak natywny analizator tabeli DNS i jego odpowiednik filtrowania, jako punkt wyjścia. Jeśli tabela jest częściowo znormalizowana, użyj analizatora wycinków, aby wykonać dodatkowe analizy i normalizację wymagane.

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

Implementowanie normalizacji czasu pozyskiwania

Aby znormalizować dane podczas pozyskiwania, należy użyć reguły zbierania danych (DCR). Procedura implementowania kontrolera domeny zależy od metody używanej do pozyskiwania danych. Aby uzyskać więcej informacji, zapoznaj się z artykułem Przekształcanie lub dostosowywanie danych w czasie pozyskiwania w usłudze Microsoft Sentinel.

Zapytanie przekształcania KQL jest rdzeniem dcR. Wersja KQL używana w kontrolerach DCR jest nieco inna niż wersja używana w innym miejscu w usłudze Microsoft Sentinel, aby spełnić wymagania dotyczące przetwarzania zdarzeń potoku. W związku z tym należy zmodyfikować dowolny analizator czasu zapytania, aby używał go w kontrolerze DCR. Aby uzyskać więcej informacji na temat różnic i sposobu konwertowania analizatora czasu zapytania na analizator czasu pozyskiwania, przeczytaj o ograniczeniach KQL kontrolera DCR.

Następne kroki

Aby uzyskać więcej informacji, zobacz: