Microsoft AZ-500: Microsoft Sentinel i operacje bezpieczeństwa — Przewodnik do nauki

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Część Microsoft Azure Security Engineer Associate AZ-500 — 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 natywna dla chmury platforma SIEM i SOAR platformy Azure, zbudowana na bazie Azure Monitor Log Analytics. Centralizuje telemetrię bezpieczeństwa, stosuje analitykę do wykrywania zagrożeń, generuje incydenty do wstępnej analizy przez analityków i organizuje zautomatyzowaną odpowiedź za pomocą Logic Apps. Efektywne działanie zależy od dobrze zaprojektowanej architektury obszaru roboczego, przemyślanego dołączania danych, przechowywania z uwzględnieniem kosztów, precyzyjnej analityki i mapowania encji oraz reżimu automatyzacji i dostrajania, który dopasowuje alerty do przepływów pracy SOC i ryzyka biznesowego.

Architektura Sentinel i zarządzanie danymi

• Obszary robocze i zagadnienia wielodostępności

  • Sentinel działa w oparciu o obszar roboczy Log Analytics. Granice obszaru roboczego należy wyznaczać na podstawie suwerenności danych, opóźnień i izolacji administracyjnej. Pojedynczy, „centralny obszar roboczy SOC” upraszcza korelację i zarządzanie zawartością; wiele obszarów roboczych może być odpowiednie w przypadku ścisłych wymogów dotyczących rezydencji danych, autonomii lub modeli MSSP/Lighthouse. Zapytania między obszarami roboczymi są obsługiwane, ale zwiększają opóźnienia i koszty; preferuj konsolidację, gdy korelacja między encjami jest kluczowa.
  • Użyj RBAC w kontekście zasobu w obszarze roboczym, aby rozdzielić obowiązki: Sentinel Reader dla pulpitów nawigacyjnych, Responder do obsługi incydentów, Contributor do zarządzania zawartością i Automation Contributor dla elementarzy.

• Ścieżki pozyskiwania danych

  • Dane trafiają do tabel w obszarze roboczym za pośrednictwem natywnych konektorów, agentów Azure Monitor lub interfejsów API. Preferuj natywne konektory dla źródeł Microsoft (zoptymalizowany schemat, niezawodność) oraz AMA+DCR dla Windows/Syslog, aby uzyskać możliwość filtrowania i kontrolę planu na poziomie tabeli. W przypadku urządzeń firm trzecich kieruj dane CEF przez Syslog do tabeli CommonSecurityLog, aby skorzystać z wbudowanych parserów i zawartości analitycznej.

• Przechowywanie, archiwizacja i wyszukiwanie

  • Skonfiguruj przechowywanie na poziomie tabeli, aby trzymać „gorące dane” (do analizy interaktywnej) na czas operacyjnego okna wykrywania (zwykle 30–120 dni). Archiwizuj starsze dane w warstwie Log Analytics Archive na okres do 7 lat, aby spełnić wymogi zgodności przy znacznie niższych kosztach; do dochodzeń używaj zadań wyszukiwania (Search Jobs) lub przywracania (Restore). Uzasadnienie operacyjne: przechowuj tylko te dane, których analitycy rutynowo używają; resztę archiwizuj, aby spełnić potrzeby audytowe/regulacyjne bez zawyżania wydatków na dane z szybkim dostępem.

• Kontrola kosztów

  • Warstwy zobowiązań (rezerwacje pojemności) w przewidywalny sposób zmniejszają koszt pozyskiwania danych dla stabilnych wolumenów; włącz je po ustaleniu 30–60-dniowego poziomu bazowego, aby uniknąć nadmiernego zobowiązania.
  • Plany rozliczeniowe na poziomie tabeli: używaj trybu Analytics dla tabel o znaczeniu krytycznym dla bezpieczeństwa (SecurityEvent, SignInLogs, CommonSecurityLog). Używaj dzienników podstawowych (Basic Logs) dla szczegółowych, niskowartościowych danych diagnostycznych, do których rzadko wykonujesz zapytania; nigdy nie umieszczaj tabel bezpieczeństwa o wysokiej wartości sygnału w trybie Basic, ponieważ tracą one pełne funkcje zapytań i nie kwalifikują się do alertów.
  • Transformacje w czasie pozyskiwania za pomocą DCR usuwają lub maskują pola i wiersze (minimalizacja PII, redukcja szumu) przed naliczeniem opłat. Operacyjnie, eliminacja szumu przed pozyskaniem danych jest najpotężniejszą metodą kontroli kosztów i wierności danych.
  • Ustaw dzienne limity dla obszaru roboczego i alerty dotyczące anomalnych skoków, aby wychwycić błędne konfiguracje lub ataki generujące burze logów.

Konektory danych i pozyskiwanie

• Azure Activity

  • Użyj konektora Azure Activity, aby przesyłać strumieniowo operacje płaszczyzny sterowania na poziomie subskrypcji do tabeli AzureActivity za pomocą ustawień diagnostycznych. Uzasadnienie: przechwytuje zmiany ról, aktualizacje zasad i wdrożenia — główne wskaźniki eskalacji uprawnień lub manipulacji przez atakującego.

• Microsoft Entra ID (Azure AD)

  • Włącz konektory AuditLogs i SignInLogs. Opcjonalnie, jeśli posiadasz licencję, pozyskuj wzbogacone logi Azure AD. Uzasadnienie: tożsamość jest główną powierzchnią ataku; anomalie logowania i zmiany w katalogu stanowią podstawę większości mechanizmów wykrywania i UEBA.

• Produkty Microsoft Defender

  • Konektory Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps i Defender for Cloud dostarczają alerty i telemetrię o wysokiej wiarygodności. Uzasadnienie: alerty bezpieczeństwa Microsoft są głęboko skorelowane i podnoszą jakość incydentów; pozyskuj je, aby zasilać mechanizm Fusion i reguły bezpieczeństwa Microsoft przy minimalnym dostrajaniu.

• Zdarzenia Windows

  • Użyj Azure Monitor Agent (AMA) z DCR: zdarzenia zabezpieczeń systemu Windows do tabeli SecurityEvent (zestaw Common, Minimal lub All) dla kontrolerów domeny i serwerów krytycznych; ogólne kanały zdarzeń Windows do tabeli WindowsEvent w razie potrzeby. Uzasadnienie: tabela SecurityEvent jest podstawą audytu uwierzytelniania i procesów; filtrowanie za pomocą DCR redukuje szum (np. wykluczenie zdarzenia 4688 bez CommandLine).

• Syslog i CEF

  • Dla systemu Linux, DCR dla Syslog w AMA wybiera obiekty/poziomy ważności do tabeli Syslog. W przypadku zapór sieciowych/IDS/EDR firm trzecich, przekazuj dane CEF do usługi przesyłania dalej opartej na agencie Log Analytics lub do mechanizmu pozyskiwania opartego na AMA, który zapisuje dane w tabeli CommonSecurityLog; użyj zawartości parsera od dostawcy. Uzasadnienie: CEF utrzymuje znormalizowane pola i zmniejsza obciążenie związane z parsowaniem; CommonSecurityLog odblokowuje gotowe reguły wykrywania.

• Higiena operacyjna

  • Synchronizacja czasu (NTP) i spójne strefy czasowe na urządzeniach dla dokładnej korelacji.
  • Deduplikuj nakładające się źródła (np. nie pozyskuj jednocześnie surowych i znormalizowanych duplikatów).
  • Zweryfikuj schemat za pomocą list obserwowanych (Watchlists) lub przykładowych zapytań przed włączeniem analityki, aby uniknąć fałszywych alarmów (false positives).

Analityka, wykrywanie i dochodzenie

• Typy reguł analitycznych

  • Reguły zaplanowane (Scheduled): KQL na danych historycznych w określonych odstępach czasu (np. co 5 minut, z zakresem 1 godziny wstecz). Używaj do większości detekcji; dostosuj zakres czasowy (lookback), aby przekraczał typowe opóźnienie danych i unikać pominięć.
  • Reguły bliskie czasu rzeczywistego (NRT): wykrywanie w czasie poniżej minuty z ograniczonym KQL i stałym, krótkim zakresem czasowym. Używaj oszczędnie dla wzorców o wysokim priorytecie, gdzie liczą się sekundy (np. masowe przypisywanie ról). Działaj z minimalną liczbą złączeń i prostymi filtrami w celu zapewnienia wydajności.
  • Fusion: wieloetapowa korelacja oparta na ML na podstawie sygnałów z usług Microsoft (Defender, Entra, Cloud Apps). Uzasadnienie: drastycznie redukuje zmęczenie alertami, tworząc pojedynczy incydent dla całego łańcucha ataku (attack kill chain).
  • Reguły anomalii: profile bazowe użytkowników/jednostek z dynamicznymi progami. Zapewniają szybkie rezultaty dla nietypowej geolokalizacji, wolumenu lub wzorców procesów; utrzymuj listy wykluczeń dla zatwierdzonych anomalii (np. okna serwisowe).
  • Reguły bezpieczeństwa Microsoft: automatycznie tworzą incydenty z alertów usługi Defender. Pozostaw włączone i dostosuj reguły automatyzacji do routingu/poziomu ważności; dostarczają sygnałów o wysokim stopniu pewności przy niskim nakładzie pracy na dostrajanie.

• Mapowanie jednostek i incydenty

  • Mapuj kolumny wyjściowe KQL na jednostki (Konto, Host, IP, URL, Plik) w konfiguracji reguły, aby zasilać grafy incydentów i UEBA. Słabe mapowanie obniża jakość dochodzenia.
  • Polityka grupowania alertów wpływa na liczbę i kontekst incydentów. Grupuj według jednostek/okna czasowego, aby połączyć powiązane alerty, redukując szum informacyjny przy jednoczesnym zachowaniu spójności zdarzeń.

• Dochodzenie i UEBA

  • Incydenty prezentują oś czasu, dowody i powiązane jednostki; graf dochodzenia (investigation graph) automatycznie buduje relacje na podstawie mapowania jednostek i wyszukiwania danych.
  • Włącz UEBA, aby wzbogacać jednostki o profile bazowe grup porównawczych (peer baselines), role urządzeń i sygnały ryzyka. Uzasadnienie: kontekst skraca czas wstępnej analizy (triage) i pomaga określić zakres reakcji.

• Podstawy KQL w inżynierii detekcji

  • Filtrowanie i projekcja

    SignInLogs
    | where TimeGenerated > ago(24h) and ResultType != 0
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
    ```

  - Parsowanie i normalizacja

CommonSecurityLog
| extend Url = extract(@"request=([^;\s]+)", 1, AdditionalExtensions)
| parse DeviceCustomString1 with * "cmd=" CommandLine
```

• Złączenia

    SecurityEvent
    | where EventID == 4624 and AccountType == "User"
    | summarize logons = count() by Account, bin(TimeGenerated, 1h)
    | join kind=inner (
        SignInLogs
        | summarize aad_logons = count() by UserPrincipalName, bin(TimeGenerated, 1h)
    ) on $left.Account == $right.UserPrincipalName, TimeGenerated
    ```

  - Agregacja i analiza w oknach czasowych

SignInLogs
| where TimeGenerated between (ago(1d) .. now())
| summarize attempts = count(), byIP = dcount(IPAddress) by UserPrincipalName
| where attempts > 50 or byIP > 10
```

← Zarządzanie postawą bezpieczeństwa i ład · Wszystkie domeny · Bezpieczeństwo aplikacji i DevSecOps →

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

Przeglądaj Microsoft →