Microsoft AZ-801: Microsoft Sentinel i monitorowanie bezpieczeństwa — Przewodnik do nauki

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Część Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Microsoft Sentinel to natywny dla chmury system SIEM i SOAR, który ujednolica pozyskiwanie logów, analitykę, wykrywanie zagrożeń, reagowanie na incydenty i proaktywne polowanie na zagrożenia (hunting) w hybrydowych środowiskach Windows Server. W scenariuszach egzaminu AZ-801 mistrzostwo w tym zakresie obejmuje podłączanie na dużą skalę źródeł Windows Security Events, Linux Syslog i zewnętrznych źródeł CEF, projektowanie analityki z minimalnym opóźnieniem, mapowanie alertów na encje w celu dokładnego dochodzenia oraz automatyzację powstrzymywania zagrożeń za pomocą podręczników (playbooks) opartych na Logic Apps. Sukces zależy również od zdyscyplinowanej architektury obszaru roboczego Log Analytics, dobrze zarządzanych reguł zbierania danych (DCR) dla agenta Azure Monitor Agent (AMA), przemyślanej strategii przechowywania danych oraz biegłości operacyjnej w zakresie UEBA, list obserwacyjnych (watchlists), polowania na zagrożenia (hunting) i skoroszytów (workbooks).

Konektory i pozyskiwanie danych

Windows Security Events via AMA to kanoniczne źródło zdarzeń logowania, tworzenia procesów, zmiany zasad i innych zdarzeń inspekcji z serwerów Windows Server. Włącz konektor „Windows Security Events via AMA” w Microsoft Sentinel i utwórz regułę DCR, która wybiera zestawy zdarzeń odpowiednie dla Twojego profilu ryzyka (Minimal, Common lub All, albo niestandardowy wybór według Event ID). Dane trafiają głównie do tabeli SecurityEvent; zdarzenia z kanałów Windows niezwiązanych z bezpieczeństwem (jeśli są włączone) trafiają do tabeli WindowsEvent. Połącz to z zasadami grupy (Group Policy), aby upewnić się, że podstawowe zasady bezpieczeństwa (Security baseline) i podkategorie inspekcji (np. Logon/Logoff, Account Logon, Object Access, DS Access) są włączone na serwerach źródłowych w celu generowania niezbędnej telemetrii.

Syslog via AMA zbiera dane z serwerów Linux i urządzeń sieciowych, które komunikują się za pomocą protokołu Syslog. Zainstaluj AMA na hostach Linux (lub na dedykowanym kolektorze Linux) i skonfiguruj regułę DCR, aby określić obiekty (facilities) i poziomy ważności (severities) do pozyskania. Zdarzenia są zapisywane w tabeli Syslog. W przypadku obiektów o dużej objętości, ale niskiej wartości, rozważ selektywne zbieranie lub transformację u źródła, aby kontrolować koszty i szum informacyjny.

CEF via AMA umożliwia pozyskiwanie znormalizowanych logów bezpieczeństwa z produktów zabezpieczających innych firm (zapory sieciowe, IDS/IPS, serwery proxy, EDR). Wdróż AMA na kolektorze Linux i skonfiguruj urządzenia swoich dostawców tak, aby przekierowywały komunikaty CEF do lokalnego demona syslog (rsyslog/syslog-ng), zazwyczaj na portach 514/UDP lub TCP. W usłudze Sentinel włącz konektor danych „CEF via AMA” i połącz hosta za pomocą reguły DCR, która przetwarza (parsuje) format CEF. Przetworzone dane trafiają do tabeli CommonSecurityLog ze spójnym schematem (pola deviceVendor, deviceProduct, destination/source oraz atrybuty rozszerzeń), co upraszcza analitykę i korelację danych od różnych dostawców.

W przypadku lokalnych serwerów Windows Server użyj serwerów z obsługą Azure Arc, aby połączyć je z Azure. Dołącz maszyny za pomocą agenta Azure Connected Machine, a następnie wdróż rozszerzenie AMA za pomocą Azure Policy w celu zapewnienia skalowalności. Twórz reguły DCR ukierunkowane na zakresy serwerów Arc, aby przekierowywać zdarzenia Windows Security Events, logi Zapory systemu Windows oraz, jeśli używasz narzędzia Sysmon, niestandardową regułę DCR dla kanału Microsoft-Windows-Sysmon/Operational. Ten wzorzec centralizuje konfigurację, wersjonowanie i targetowanie oparte na zakresie, zapewniając spójne pozyskiwanie danych bez ręcznej pracy na każdym hoście.

Architektura obszaru roboczego i cykl życia danych

Usługa Sentinel jest dołączana do jednego obszaru roboczego Log Analytics na wdrożenie. Projekt obszaru roboczego powinien minimalizować opóźnienia międzyregionalne i koszty transferu wychodzącego (egress) — współlokalizuj obszary robocze z większością producentów danych i unikaj nadmiernej fragmentacji, która komplikuje zapytania, klasyfikację incydentów i RBAC. Typowe wzorce to jeden obszar roboczy ds. bezpieczeństwa na dzierżawę lub jeden na główny region, jeśli rezydencja danych i opóźnienia wymagają rozdzielenia. W miarę możliwości używaj dostępu w kontekście zasobów, aby zespoły mogły odpytywać logi zasobów, których są właścicielami, bez szerokich uprawnień do obszaru roboczego, podczas gdy role Sentinel (Reader, Responder, Contributor) zarządzają operacjami SOC.

Reguły DCR określają, jakie typy telemetrii, kanały i zestawy zdarzeń są zbierane oraz dokąd są wysyłane. Traktuj DCR jak kod: standaryzuj nazewnictwo, kontrolę wersji i zakresy (subskrypcje, grupy zasobów, tagi). Grupuj powiązane źródła i miejsca docelowe, preferując wiele ukierunkowanych reguł DCR zamiast jednej monolitycznej reguły, aby uprościć zarządzanie promieniem rażenia (blast radius) i cyklem życia. Gdy wolumeny danych syslog i CEF są wysokie, rozważ użycie oddzielnych reguł DCR, aby niezależnie dostrajać parametry facility/severity i wspierać testowanie etapowe.

Przechowywanie i koszty są kontrolowane na poziomie tabeli. Ustaw domyślny okres przechowywania dla obszaru roboczego, aby spełnić wymogi zasad (np. 90–180 dni dla aktywnego wyszukiwania), a następnie w razie potrzeby nadpisz go dla poszczególnych tabel. Tabele o wysokiej wartości (SecurityEvent, CommonSecurityLog, SecurityAlert) są zazwyczaj przechowywane dłużej; tabele szczegółowe (np. Syslog z poziomem DEBUG) mogą być przechowywane krócej. Użyj archiwum do długoterminowego, taniego przechowywania z zadaniami wyszukiwania; w razie potrzeby promuj dane do warstwy gorącej (hot) na czas dochodzeń. W stosownych przypadkach przenieś niektóre szczegółowe tabele (takie jak Syslog) do logów podstawowych (Basic Logs) w celu zmniejszenia kosztów, pamiętając o ograniczeniach zapytań i o tym, że niektóre tabele bezpieczeństwa (np. SecurityEvent) nie kwalifikują się do warstwy Basic. Regularnie przeglądaj limity danych, plany taryfowe (commitment tiers) i trendy pozyskiwania danych, aby zapobiegać ograniczaniu przepustowości (throttling) i optymalizować koszty.

Analityka, incydenty i automatyzacja odpowiedzi

Reguły analityczne są silnikiem detekcji. Reguły zapytania oparte na harmonogramie (Scheduled query rules) uruchamiają KQL zgodnie z harmonogramem (np. co 5 minut) w zdefiniowanym okresie przeszukiwania (lookback period, np. 30 minut), wspierając agregacje, złączenia, wzbogacanie danymi z list obserwacyjnych (watchlist) i okna wyciszania (suppression windows). Są idealne do wykrywania dobrze znanych wzorców, takich jak wielokrotne nieudane logowania, po których następuje sukces, heurystyki ruchu bocznego (lateral movement) czy podejrzane drzewo procesów (process lineage). Reguły działające w czasie niemal rzeczywistym (NRT) minimalizują opóźnienie detekcji, ciągle przetwarzając nowe dane z wykonaniami co około minutę i generowaniem alertów w ciągu około dwóch minut; projektuj reguły NRT tak, aby były zwięzłe i opierały się na ingestion_time() lub wąskich oknach czasowych, aby unikać obciążających skanów historycznych. Reguły Fusion wykorzystują wieloetapową analitykę ataków Microsoftu do korelowania alertów o niskim poziomie istotności (low-signal) z różnych produktów (np. Defender for Endpoint, Defender for Identity, Entra ID Protection, zewnętrzne źródła CEF) w incydenty o wysokim stopniu wiarygodności (high-fidelity) dla kampanii takich jak kradzież poświadczeń czy ransomware. Reguły anomalii (Anomaly rules) wykorzystują wbudowane szablony ML, które uczą się wzorców bazowych (np. nietypowe lokalizacje logowania, rzadkie wykonania procesów) i generują alerty o odchyleniach; zazwyczaj odczytują one dane z BehaviorAnalytics i innych znormalizowanych źródeł.

Incydenty łączą wiele alertów, encji i dowodów w ramach jednego dochodzenia. Poziom ważności (Severity) jest przypisywany przez regułę analityczną (lub dynamicznie przez Fusion) i może być eskalowany lub obniżany za pomocą reguł automatyzacji. Mapowanie encji ma kluczowe znaczenie dla skuteczności dochodzenia: w kreatorze reguł zmapuj kolumny zapytania na typy encji (Account, Host, IP, URL, File, Process, CloudApplication, AzureResource). Prawidłowe mapowanie wypełnia graf dochodzenia (investigation graph), który wizualizuje relacje między alertami, zdarzeniami i encjami, umożliwiając przechodzenie (pivoting) między kontami, hostami, procesami i adresami IP. Używaj komentarzy, tagów, właściciela (owner) i klasyfikacji, aby rejestrować decyzje analityka i trenować procesy dostrajania (tuning workflows).

Automatyzacja łączy w sobie reguły automatyzacji (Automation rules) i podręczniki (Playbooks). Reguły automatyzacji oceniają metadane incydentu podczas jego tworzenia lub aktualizacji, aby przypisywać właścicieli, zmieniać poziom ważności, dodawać tagi, zamykać fałszywe alarmy (false positives) lub wywoływać podręczniki (playbooks). Playbooks to aplikacje Azure Logic Apps zbudowane przy użyciu konektorów Microsoft Sentinel. Playbooki wyzwalane przez incydent (Incident-triggered) reagują na zdarzenia cyklu życia incydentu (np. gdy incydent jest tworzony) i są przeznaczone do działań w zakresie incydentu, takich jak powiadamianie zespołu, wzbogacanie wszystkich encji czy tworzenie zgłoszenia w ServiceNow. Playbooki wyzwalane przez alert (Alert-triggered) uruchamiają się dla pojedynczych alertów, zanim zostaną one zgrupowane w incydent — jest to przydatne do wzbogacania danych specyficznego dla dostawcy lub do wstępnej klasyfikacji (pre-triage). Stosuj tożsamości zarządzane (managed identity) dla playbooków, nadawaj minimalne uprawnienia (least-privilege) za pomocą Azure RBAC i uprawnień API oraz parametryzuj identyfikatory obszaru roboczego, punkty końcowe systemu zgłoszeń i ścieżki do list blokowania, aby promować ponowne użycie. Gdy uzasadnione jest powstrzymanie ataku (containment), uwzględnij akcje, które poddają kwarantannie punkty końcowe (Defender for Endpoint), wyłączają konta (Entra ID), blokują adresy IP (firewalle) lub unieważniają sesje (Conditional Access) dopiero po osiągnięciu progów pewności.

Proaktywne operacje bezpieczeństwa (Threat Hunting, UEBA, Watchlisty, Skoroszyty)

Poszukiwanie zagrożeń (threat hunting) w usłudze Sentinel opiera się na biegłości w KQL i module hunting. Zacznij od wbudowanych zapytań łowieckich uporządkowanych według taktyk; dostosuj je do swojego środowiska, odwołując się do tabel takich jak SecurityEvent (inspekcja Windows), tabele Device* z Defender, CommonSecurityLog (CEF) i SigninLogs (Entra). Używaj zakładek (bookmarks), aby zapisywać interesujące rekordy, dodawać do nich adnotacje i dzielić się kontekstem w zespole; wiele zakładek można przekształcić w nowy lub istniejący incydent. Funkcja Livestream stale uruchamia wzorzec KQL, aby wykrywać nowe pasujące zdarzenia niemal w czasie rzeczywistym — jest to idealne rozwiązanie do dochodzeń ograniczonych czasowo lub scenariuszy nagłego wzrostu aktywności. Przekształcaj dojrzałe zapytania łowieckie w zaplanowane reguły analityczne, aby zoperacjonalizować wykrywanie.

UEBA (User and Entity Behavior Analytics) wzbogaca wykrywanie o behawioralne punkty odniesienia i ocenę anomalii. Włącz UEBA w konfiguracji Sentinel i upewnij się, że źródła danych o tożsamości i aktywności (logowania Microsoft Entra, Defender for Endpoint, Defender for Identity, aktywność M365) są podłączone. Strony jednostek (entity pages) dla użytkowników i hostów pokazują osie czasu, porównania z podobnymi jednostkami (peer comparisons), anomalne działania (rzadka geolokalizacja logowania, nietypowy proces) i zagregowane oceny ryzyka. Analitycy mogą przechodzić od incydentów do stron jednostek, aby ocenić, czy dane działanie jest typowe dla tej tożsamości lub urządzenia; oceny anomalii i sekwencje zdarzeń pomagają w priorytetyzacji analizy oraz szybkim potwierdzeniu lub obaleniu hipotez.

Watchlisty (listy obserwowanych) dostarczają szybkich danych referencyjnych utrzymywanych przez analityków. Twórz watchlisty poprzez przesyłanie plików CSV lub ze ścieżki na koncie magazynu, zdefiniuj alias i wybierz kolumnę klucza dla wydajnych wyszukiwań. Używaj funkcji watchlist() w KQL do złączeń — typowe zastosowania obejmują listy dozwolonych/zablokowanych kont administracyjnych, wrażliwych hostów, usankcjonowanych domen lub użytkowników VIP. Włącz watchlisty do reguł analitycznych, aby wyciszyć znaną, prawidłową aktywność (zmniejszyć liczbę fałszywych alarmów) lub podnieść wagę incydentu, gdy dopasowanie dotyczy krytycznego zasobu. Integruj z analityką zagrożeń (threat intelligence), łącząc watchlisty z tabelą ThreatIntelligenceIndicator w celu uzyskania kontekstu (np. wzbogacenie wykrytych adresów IP o wewnętrzną wagę lub notatki do sprawy) lub konwertując wyselekcjonowane kanały TI na watchlistę w celu szybkiego odniesienia i nadpisywania.

Skoroszyty (Workbooks) wspierają monitorowanie i zapewniają wgląd dla kadry zarządzającej. Zacznij od wbudowanych szablonów, takich jak Security Operations Efficiency, Active Directory Sign-ins, Fusion Detections i UEBA insights. Twórz niestandardowe skoroszyty, używając zapytań KQL, parametrów i wizualizacji, aby budować pulpity nawigacyjne SOC do monitorowania kondycji pozyskiwania danych, wydajności reguł, SLA dla incydentów i pojawiających się zagrożeń. Zastosuj RBAC na zasobie skoroszytu i sparametryzuj subskrypcje, obszary robocze i zakresy czasowe, aby ten sam skoroszyt mógł służyć różnym zespołom. Łącz kafelki z wielu tabel, aby skorelować stan zabezpieczeń (Defender for Cloud), wykrycia (Sentinel) i metryki odpowiedzi w jednym widoku.

Praktyczny scenariusz problemowy

Firma Spotify musi scentralizować monitorowanie bezpieczeństwa dla 2000 serwerów Windows w Azure i lokalnych centrach danych, a także dla zapór sieciowych i serwerów proxy innych firm. Potrzebują wykrywania nadużyć poświadczeń z niskim opóźnieniem, zautomatyzowanego tworzenia zgłoszeń i izolowania zasobów oraz przejrzystych pulpitów nawigacyjnych i przepływów pracy dla zespołu SOC.

Wdrożenie serwerów hybrydowych za pomocą Azure Arc i AMA

Wdróż na dużą skalę onboarding serwerów z obsługą Azure Arc za pomocą Azure Policy, a następnie przypisz politykę rozszerzenia AMA do zakresu Arc. Utwórz reguły DCR dla „Windows Security Events via AMA” (zestaw Common), Windows Firewall oraz niestandardową regułę DCR dla Sysmon, jeśli jest zainstalowany. Takie podejście zapewnia spójne, centralnie zarządzane zbieranie danych bez konieczności tworzenia skryptów dla każdego hosta i gwarantuje, że tabela SecurityEvent jest zasilana danymi na potrzeby analityki tożsamości i procesów.

Pozyskiwanie telemetrii z urządzeń sieciowych i bezpieczeństwa za pomocą Syslog i CEF

Uruchom maszynę wirtualną z systemem Linux jako kolektor z agentem AMA. Skonfiguruj „Syslog via AMA” dla odpowiednich obiektów (facilities) i włącz „CEF via AMA”, aby parsować dane CEF z zapór sieciowych i serwerów proxy do tabeli CommonSecurityLog. Użycie formatu CEF normalizuje dane od wielu dostawców, umożliwiając przenośność reguł i łatwe łączenie danych z różnych źródeł.

Zaprojektowanie analityki pod kątem szybkości i wiarygodności

Włącz Fusion, aby wychwytywać wieloetapowe ataki przy minimalnym dostrajaniu. Utwórz reguły NRT dla serii nieudanych logowań, po których następuje udane logowanie na konta uprzywilejowane, używając tabeli SecurityEvent i funkcji ingestion_time(), co zapewnia wykrywanie w czasie poniżej dwóch minut. Zbuduj zaplanowane reguły dla wzorców ruchu bocznego (np. utworzenie procesu net.exe na serwerach połączone z nietypowymi kontami administracyjnymi) oraz dla anomalii w ruchu wychodzącym przez proxy, połączonych z watchlistami VIP i hostów o kluczowym znaczeniu. Ta kombinacja minimalizuje MTTR, jednocześnie ograniczając fałszywe alarmy.

Mapowanie jednostek i kształtowanie incydentów

W każdej zaplanowanej regule mapuj jednostki Account, Host, IP i Process z kolumn zapytania. Użyj reguł automatyzacji, aby przypisywać incydenty według jednostki biznesowej (na podstawie tagów hosta), standaryzować wagę, dodawać tagi MITRE i automatycznie zamykać znane sygnały testowe. Prawidłowe mapowanie umożliwia grafowi dochodzenia (investigation graph) pokazywanie relacji, po których analitycy Spotify mogą szybko nawigować.

Automatyzacja wzbogacania danych, tworzenia zgłoszeń i izolowania zasobów za pomocą playbooków

Zbuduj playbook wyzwalany przez incydent, który wzbogaca wszystkie konta i hosty (wyszukiwania w grafie, ryzyko urządzenia), publikuje post w Teams i otwiera zgłoszenie w Jira. Osobny playbook wyzwalany przez alert wzbogaca określone alerty CEF za pomocą API dostawców. Używaj tożsamości zarządzanych z RBAC o najniższych uprawnieniach i warunkowego rozgałęziania, które izoluje urządzenia (przez Defender for Endpoint) lub wyłącza użytkowników (przez Entra ID) tylko wtedy, gdy zostaną osiągnięte progi pewności (np. wiele potwierdzających alertów i wysoka ocena UEBA). Pozwala to zachować ciągłość biznesową, jednocześnie umożliwiając szybką, zarządzaną odpowiedź.

Włączenie UEBA i operacjonalizacja threat huntingu

Włącz UEBA i zweryfikuj źródła danych (SigninLogs, aktywność M365, sygnały z Defender). Przeszkól analityków, aby przechodzili od incydentów do stron jednostek w celu sprawdzenia ocen anomalii i porównań z podobnymi jednostkami. Przekształć dwa wartościowe zapytania łowieckie — „Nowe narzędzia do zdalnej administracji na serwerach” i „Rzadkie wzorce eksfiltracji danych do zewnętrznych adresów IP” — w zaplanowane reguły analityczne po ich zweryfikowaniu za pomocą zakładek i funkcji livestream. UEBA w połączeniu z zdyscyplinowanym poszukiwaniem zagrożeń zacieśnia wykrywanie nowych technik.

Zarządzanie cyklem życia danych i wizualizacja stanu zabezpieczeń

Ustaw przechowywanie danych na 180 dni dla SecurityEvent i CommonSecurityLog, 30 dni dla szczegółowego Syslog z archiwizacją do 1 roku, i monitoruj koszty za pomocą warstw zobowiązania (commitment tiers). Opublikuj niestandardowy skoroszyt SOC, który śledzi kondycję pozyskiwania danych, najbardziej hałaśliwe reguły, MTTA/MTTR, kolejki incydentów według wagi oraz anomalie UEBA w czasie. Zapewnia to transparentność dla kierownictwa i napędza ciągłe dostrajanie.

Każde narzędzie zostało wybrane ze względu na swoją siłę w konkretnym zastosowaniu: Arc i AMA+DCR zapewniają skalowalne, sterowane politykami pozyskiwanie danych; CEF gwarantuje znormalizowane logi bezpieczeństwa od wielu dostawców; Fusion i NRT obniżają opóźnienie wykrywania bez nadmiernego dostrajania; mapowanie jednostek i graf dochodzenia przyspieszają analizę; playbooki zapewniają zarządzaną automatyzację opartą na tożsamościach; UEBA dostarcza kontekstu behawioralnego; narzędzia do threat huntingu doskonalą wykrywanie; a skoroszyty sprawiają, że operacje są mierzalne i widoczne.

← Microsoft Defender for Cloud i bezpieczeństwo punktów końcowych · Wszystkie domeny · Bezpieczeństwo Active Directory Domain Services →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →