Odblokowanie widoczności M365: dlaczego domyślne łączniki SIEM zostawiają Cię bez wglądu

By Mirko Peters · 2026-08-11

Witamy ponownie na blogu! Jeśli zarządzasz operacjami bezpieczeństwa w organizacji korzystającej z Microsoft 365, prawdopodobnie masz fałszywe poczucie bezpieczeństwa. Kliknąłeś „en…

Automatically translated with AI from the original post. Read the English original

Witaj ponownie na blogu! Jeśli zarządzasz operacjami bezpieczeństwa w organizacji korzystającej z Microsoft 365, pewnie czujesz się bezpiecznie, ale tylko pozornie. Kliknąłeś „włącz” w domyślnym łączniku M365 swojego SIEM-u, sprawdziłeś, czy logi napływają, i odhaczyłeś wymóg zgodności. Ale czy naprawdę jesteś chroniony? Niewygodna prawda jest taka, że domyślne łączniki SIEM często pozostawiają ogromne martwe punkty, całkowicie pomijając zaawansowane obciążenia chmurowe, w których współcześni atakujący najchętniej działają. Aby w pełni zgłębić ten istotny temat, koniecznie posłuchaj naszego towarzyszącego odcinka podcastu Send Critical Microsoft 365 Logs to Your SIEM, w którym szczegółowo omawiamy te luki.

W tym wpisie szczegółowo przyjrzymy się temu, dlaczego domyślne konfiguracje zawodzą, gdzie kryją się ukryte martwe punkty oraz jak zbudować odporny, opłacalny potok pozyskiwania danych, który dostarcza wykrycia o wysokiej wartości sygnałowej, z których Twoi analitycy rzeczywiście mogą skorzystać.

Martwe punkty Microsoft 365 w popularnych systemach SIEM

Niezależnie od tego, czy korzystasz z Microsoft Sentinel, Splunk czy QRadar, domyślne szablony pozyskiwania danych zwykle koncentrują się na podstawowych logowaniach w Azure Active Directory i ogólnych logach aktywności Office 365. Choć to pokrywa absolutne podstawy, pozostawia krytyczne obciążenia całkowicie bez ochrony. W popularnych platformach SIEM konsekwentnie pojawia się kilka głównych martwych punktów:

• Exchange: Domyślne łączniki często pomijają dostęp do skrzynek pocztowych przez osoby, które nie są ich właścicielami, podejrzane tworzenie reguł i przekierowań, aktywności SendAs lub SendOnBehalf oraz nagłe zmiany uprawnień do skrzynek pocztowych.
• SharePoint i OneDrive: Możesz widzieć pobieranie plików, ale czy widzisz tworzenie i używanie zewnętrznych linków anonimowych, ponowne udostępnianie plików lub zmiany uprawnień do witryn o podwyższonym dostępie?
• Teams: Atakujący chętnie współpracują na otwartych kanałach. Domyślne konfiguracje rzadko rejestrują udostępnianie zewnętrzne przez kanały oparte na SharePoint, usuwanie i edycję wiadomości, zmiany zasad spotkań ani nieautoryzowane sideloadowanie aplikacji.
• Power Platform: Rozwój środowisk low-code/no-code wiąże się z ukrytym ryzykiem. Nagłe wzrosty liczby tworzonych przepływów i aplikacji, ryzykowne użycie łączników (np. Outlook, Teams lub dowolnych łączników HTTP) oraz obejścia zasad ochrony danych (DLP) są często pomijane.
• Poufność i DLP: Zdarzenia zastosowania i usunięcia etykiet, trafienia zasad oraz ręczne nadpisania są często całkowicie nieobecne, chyba że zostaną wyraźnie uwzględnione.
• Kontekst Azure AD: Kluczowy kontekst dotyczący ryzykownych logowań, wyników warunkowego dostępu oraz anomalii urządzeń lub lokalizacji geograficznych jest często pomijany w standardowych zapytaniach.

Przyczyny źródłowe: dlaczego brakuje krytycznych zdarzeń

Dlaczego te krytyczne strumienie telemetrii są niekompletne? Rzadko dzieje się to przypadkowo; jest to raczej wynik decyzji architektonicznych i komercyjnych podejmowanych zarówno przez dostawców platform, jak i nabywców korporacyjnych.

Po pierwsze, istotną rolę odgrywają ograniczenia licencyjne. Zaawansowane audytowanie, szczegółowa telemetria Exchange oraz rozbudowane rejestrowanie zdarzeń SharePoint są często dostępne dopiero w wyższych licencjach, takich jak Microsoft 365 E5, lub w dodatkach Advanced Audit. Jeśli Twoja dzierżawa korzysta z poziomu E3, te zdarzenia po prostu nie są generowane ani przechowywane.

Po drugie, zakres łączników ogranicza zbieranie danych. Standardowe łączniki zwykle pobierają podstawowe strumienie „OfficeActivity”, pomijając zaawansowane obciążenia. Po trzecie, ograniczanie przepustowości API i opóźnienia wynikające z grupowania danych mogą przeciążyć natywne kolektory w godzinach szczytu, prowadząc do utraty logów. Po czwarte, luki w parserach oznaczają, że nawet jeśli surowe obiekty JSON trafiają do SIEM-u, niezmapowane pola i ciche zmiany schematu sprawiają, że wyglądają jak bezsensowny ciąg znaków. Wreszcie, kontrole kosztów wprowadzane przez zespoły dbające o budżet po cichu wykluczają hałaśliwe kategorie, nie rozumiejąc skutków dla bezpieczeństwa.

Kontrola kosztów bez utraty widoczności

Jednym z największych sprzeciwów wobec pozyskiwania „pełnej” widoczności Microsoft 365 jest koszt. Pozyskiwanie każdego pojedynczego logu generowanego przez duży dzierżawę M365 może zrujnować budżet na przechowywanie danych bezpieczeństwa. Nie musisz jednak wybierać między bankructwem a ślepotą. Potrzebujesz mądrzejszego filtrowania, a nie mniejszej ilości danych.

Zacznij od filtrowania po stronie źródła. Skonfiguruj mechanizmy pozyskiwania tak, aby uwzględniały wyłącznie operacje o wysokiej wartości sygnałowej, takie jak New-InboxRule, Add-MailboxPermission lub zdarzenia tworzenia i użycia anonimowych linków udostępniania. Zanim zdarzenia trafią do Twojego SIEM, deduplikuj i agreguj gadatliwe, mało wartościowe zdarzenia, takie jak tło zapisów wersji plików w SharePoint.

Wdróż wielopoziomowe strategie przechowywania. Utrzymuj gorącą warstwę krótko (30 do 60 dni) na potrzeby aktywnych dochodzeń, a dane zimne lub archiwalne kieruj do tańszych magazynów obiektów, aby spełnić wymagania zgodności w dłuższych horyzontach czasowych. Ponadto, zanim włączysz nowe strumienie, modeluj wolumen danych. Prognozuj liczbę gigabajtów dziennie w podziale na źródła i podwój te szacunki, aby uwzględnić szczyty biznesowe, audyty kwartalne lub okresy postępowań sądowych (legal discovery).

Projektowanie odpornego potoku pozyskiwania danych

Opieranie się na kruchych, bezpośrednio odpytywanych konektorach to prosta droga do pominięcia alertów podczas stresujących incydentów bezpieczeństwa. Zamiast tego zaprojektuj odporny potok uwzględniający ograniczenia przepustowości (throttling). Sprawdzony wzorzec wygląda następująco:

• Źródło: Pobieraj dane z ujednoliconego dziennika audytu Microsoft 365, zaawansowanego audytu, logów logowań i logów ryzyka Azure AD, Microsoft Information Protection (MIP), alertów DLP oraz alertów zabezpieczeń Microsoft Defender.
• Transport: Kieruj dane z interfejsu Graph lub Management API do usługi Azure Event Hub (która działa jako bufor i mechanizm ponownego odtwarzania) przed przekazaniem ich do SIEM.
• Przetwarzanie: Normalizuj i wzbogacaj dane już w strefie docelowej (landing zone), dodając kontekst użytkownika, flagi działów, oznaczenia VIP, stany urządzeń oraz dane geograficzne.
• Zarządzanie: Wdróż codzienne kontrole kompletności danych, obsługę wycofywania żądań przy limicie 429 (rate-limit backoff), monitorowanie zmian schematu oraz alerty z kolejki martwych listów (dead-letter queue).

Normalizacja i wzbogacanie danych gotowych dla analityków

Surowe logi Microsoft 365 są notorycznie nieuporządkowane, pełne zagnieżdżonych obiektów JSON i niespójnych konwencji nazewnictwa pól między poszczególnymi usługami. Jeśli przekażesz surowe dane analitykowi pierwszej linii (Tier 1), spędzi on połowę zmiany na odczytywaniu ładunków zamiast na triażu zagrożeń.

Spłaszczaj kluczowe pola już na etapie pozyskiwania: Actor, Target, Action, ResourcePath, LinkType (anonymous, organization lub specific people), ExternalRecipient oraz LabelName. Mapuj te pola na zunifikowany schemat, taki jak Azure Monitor Common Security Incident Model (ASIM) lub Elastic Common Schema (ECS), aby Twoja inżynieria wykrywania zagrożeń obejmowała wszystkie usługi bez przerw. Na koniec wzbogacaj zdarzenia o dane z HR (rola, typ zatrudnienia, dział), listy VIP, listy dozwolonych partnerów, stany zgodności urządzeń oraz klasyfikacje poufności.

Wykrycia o wysokiej wartości sygnałowej do wdrożenia od zaraz

Gdy potok działa, a dane są znormalizowane, możesz wdrożyć wykrycia o wysokiej wartości sygnałowej, które faktycznie wychwytują wyrafinowane zachowania atakujących. Oto osiem podstawowych wykryć, które warto uruchomić natychmiast:

• Mailbox Exfiltration: Wykryj nową regułę skrzynki odbiorczej, która przekazuje wiadomości na zewnątrz lub przenosi je do folderów RSS/Wiadomości-śmieci, występującą w ciągu godziny od logowania z nowej lokalizacji geograficznej lub nierozpoznanego urządzenia.
• Stealth Access: Oznaczaj dostęp do skrzynki VIP przez użytkownika, który nie jest jej właścicielem, jeśli wcześniej, w ciągu 24 godzin, wystąpiło zdarzenie Add-MailboxPermission.
• SharePoint Spill: Generuj alert dla anonimowych linków udostępniania lub linków typu „określone osoby” utworzonych dla plików oznaczonych etykietami Confidential lub Restricted.
• Link Abuse: Wykryj duży wolumen zewnętrznych pobrań w ciągu 15-minutowego okna, pochodzących z świeżo utworzonego linku udostępniania z nowego adresu IP lub ASN.
• Teams Pivot: Wychwytuj scenariusze, w których plik zostaje udostępniony na zewnątrz, a ten sam użytkownik w ciągu dwóch godzin dodaje zewnętrznego gościa do zespołu (Team).
• Power Automate Abuse: Oznaczaj nagły wzrost liczby co najmniej trzech dziennych utworzeń przepływów przez konto niebędące deweloperem, zwłaszcza z użyciem konektorów HTTP lub Outlook.
• Privilege Creep: Śledź powtarzające się dodawania i usuwania ról członka lub administratora w tym samym wrażliwym obszarze roboczym lub witrynie w ciągu 24-godzinnego okna.
• Stale Truth: Wykryj sytuacje, w których zestawy danych z treściami dla kadry zarządzającej lub finansów nie odświeżają się przez dwa lub więcej cykli, chroniąc kierownictwo przed podejmowaniem decyzji na podstawie nieaktualnych danych.

Twój 30-dniowy plan zamykania luk we widoczności

Naprawa widoczności Twojego środowiska Microsoft 365 nie musi zajmować roku. Systematycznie zamkniesz luki we widoczności w zaledwie 30 dni:

• Tydzień 1: Włącz zaawansowany audyt tam, gdzie jest to potrzebne, sporządź inwentarz obecnych konektorów SIEM i zmapuj brakujące kategorie zdarzeń.
• Tydzień 2: Uruchom potok Event Hub. Skieruj do niego telemetrię Unified Audit Logs, Advanced Audit, Azure AD i Defender oraz wdróż filtry po stronie źródła.
• Tydzień 3: Znormalizuj i wzbogać strumienie danych, uzupełnij logi krytyczne z ostatnich 30 dni i wdróż siedem wykrywań o wysokiej wartości, o których mowa powyżej, z odpowiednimi oknami wyciszania.
• Tydzień 4: Zoptymalizuj koszty, usuwając pozostały szum i dostosowując poziomy przechowywania. Dodaj monitory kompletności i przeprowadź ćwiczenie purple team na poziomie stołu, testując reguły skrzynek pocztowych, udostępnianie zewnętrzne oraz nagłe skoki przepływów.

Kluczowe wskaźniki KPI dla kierownictwa potwierdzające skuteczność

Gdy kierownictwo pyta, czy budżet na bezpieczeństwo wydany na ulepszenia potoku się opłacił, potrzebujesz metryk, które udowodnią sukces. Śledź następujące wskaźniki KPI dla kierownictwa:

• Pokrycie: Odsetek docelowych rodzin zdarzeń Microsoft 365, które zostały pomyślnie pobrane i przetworzone (cel: 95% lub więcej).
• Szybkość: Średni czas potwierdzenia (MTTA) i średni czas rozwiązania (MTTR) incydentów związanych z Microsoft 365 (trend spadkowy).
• Szum: Stosunek alertów do prawdziwie pozytywnych wyników (trend wzrostowy jakości sygnału).
• Koszt: Koszt za pobrany gigabajt (trend spadkowy o około 40% dzięki filtrowaniu po stronie źródła).
• Niezawodność: Liczba dni z lukami w pobieraniu danych (cel: zero) oraz terminy obsługi zmian schematu (aktualizacje parserów w ciągu siedmiu dni od zmiany schematu przez firmę Microsoft).

Typowe pułapki i sposoby ich unikania

Nawet najlepiej przemyślane plany mogą napotkać przeszkody. Uważaj na następujące typowe pułapki:

Zespoły często twierdzą: "Włączyliśmy to", ale logi nigdy się nie pojawiają, ponieważ licencje Advanced Audit lub bazowe ustawienia audytu skrzynek pocztowych nigdy nie zostały właściwie zweryfikowane. Innym częstym problemem jest to, że reguły SIEM milczą podczas ataków, ponieważ oceniają zdarzenia w izolacji, zamiast korelować tworzenie reguł, zmiany geograficzne i udostępnianie zewnętrzne.

Eksplozje kosztów następują, gdy pomija się filtry wstępne. Zawsze filtruj wstępnie hałaśliwe operacje i wyłączaj zdarzenia synchronizacji w tle. Degradacja parserów to kolejny cichy zabójca; ustanów miesięczną procedurę porównywania schematów i uruchamiaj testy jednostkowe na przykładowych ładunkach. Wreszcie zmęczenie analityków narasta szybko, gdy alerty nie zawierają kontekstu. Zawsze upewnij się, że alerty zawierają informacje o tym, kto, co, gdzie i jakie etykiety poufności, wraz z bezpośrednimi linkami do Microsoft Compliance Center w celu dogłębnej analizy.

Podsumowanie: przestań polegać na zgodności jako ochronie

Sedno sprawy jest proste: domyślne łączniki SIEM zapewniają zgodność, ale nie zapewniają ochrony. Pobierając właściwe logi Microsoft 365, normalizując je do jednolitego schematu, wzbogacając o kluczowy kontekst biznesowy i prowadząc polowanie za pomocą wykryć dostrojonych do rzeczywistych zachowań atakujących, możesz całkowicie wyeliminować martwe punkty. Tak sprawia się, że SIEM przestaje pomijać historię, a zaczyna ją pisać. Aby zgłębić tę strategię jeszcze dokładniej, posłuchaj pełnego odcinka pod tytułem Send Critical Microsoft 365 Logs to Your SIEM i zacznij już dziś likwidować luki w widoczności!