Przejdź do treści
Powrót do Centrum Pomocy
Microsoft 365
Bezpieczeństwo

Runbook reagowania na incydenty Microsoft 365 — kompletna procedura krok po kroku (2026)

Runbook incydentowy dla Microsoft 365 to operacyjny dokument proceduralny, który przekłada ogólne fazy reagowania na incydenty (przygotowanie, detekcja, analiza

11 min czytania·Zaktualizowano dzisiaj
Faktura VAT 23% + KSeFDostawa 1-3 min e-mailemGwarancja działania klucza5,0 / 5,0(KluczeSoft)

Runbook reagowania na incydenty Microsoft 365 to udokumentowana, powtarzalna procedura postępowania w przypadku naruszenia bezpieczeństwa w środowisku Microsoft 365 — od wykrycia alertu, przez analizę i izolację, aż po przywrócenie normalnego działania i wyciągnięcie wniosków. Obejmuje zarówno automatyczne mechanizmy wbudowane w Microsoft Defender XDR (automatyczne badanie, automatyczne zakłócanie ataku), jak i ręczne czynności zespołu SOC — triaż, eskalację, analizę forensiczną i raportowanie poincydentalne.

W skrócie

  • Runbook M365 to szczegółowa instrukcja — nie ogólny framework (NIST, SANS) — dostosowana do konkretnych narzędzi: Defender for Endpoint, Defender for Identity, Defender for Office 365, Microsoft Sentinel
  • Microsoft Defender XDR automatycznie koreluje alerty w incydenty, redukując szum nawet o 90% i prezentując pełną historię ataku (attack story)
  • Automatyczne badanie (AIR — Automated Investigation and Response) wykonuje wstępny triaż i podejmuje działania naprawcze bez udziału człowieka
  • Automatyczne zakłócanie ataku (automatic attack disruption) — funkcja dostępna od 2024 roku, stale rozbudowywana — izoluje urządzenia, wyłącza konta i blokuje komunikację w czasie rzeczywistym przy poziomie pewności ≥99%
  • Każdy incydent w portalu Defender przechodzi przez ścieżkę statusów: Active → In Progress → Resolved, z obowiązkową klasyfikacją (True Positive / False Positive / Informational)
  • Dobrze zaprojektowany runbook skraca średni czas reagowania (MTTR) o 40-60% w porównaniu z działaniem ad-hoc — wynika to z analiz Microsoft Digital Defense Report 2025

Pełna definicja — czym jest runbook M365

Runbook incydentowy dla Microsoft 365 to operacyjny dokument proceduralny, który przekłada ogólne fazy reagowania na incydenty (przygotowanie, detekcja, analiza, izolacja, eradykacja, odtwarzanie, lessons learned) na konkretne czynności wykonywane w ekosystemie Microsoft. W przeciwieństwie do planów reagowania (IRP), które definiują role i odpowiedzialności, runbook koncentruje się na technicznych krokach: które narzędzie uruchomić, jakie polecenie KQL wykonać w advanced hunting, jak przeprowadzić izolację urządzenia, jak wyłączyć konto w Microsoft Entra ID.

W ekosystemie Microsoft 365 runbook opiera się na pięciu filarach narzędziowych:

  1. Microsoft Defender XDR — ujednolicony portal (security.microsoft.com), który koreluje alerty z Defender for Endpoint, Defender for Identity, Defender for Office 365, Microsoft Defender for Cloud Apps i Microsoft Sentinel w spójne incydenty. To tutaj odbywa się triaż i zarządzanie incydentem.
  2. Microsoft Sentinel — SIEM/SOAR dostarczający reguły automatyzacji (automation rules) i playbooki (oparte na Azure Logic Apps) do automatycznej reakcji na alerty z dowolnych źródeł.
  3. Advanced Hunting — możliwość przeszukiwania surowych logów telemetrycznych za pomocą Kusto Query Language (KQL) w celu proaktywnego polowania na zagrożenia.
  4. Microsoft Security Copilot — asystent AI zintegrowany z portalem Defender, który podsumowuje incydenty w języku naturalnym, generuje zapytania KQL i rekomenduje działania naprawcze (od 2025 roku dostępny jako osobna licencja).
  5. Action Center — centralne miejsce monitorowania wszystkich automatycznych i ręcznych działań naprawczych (izolacja urządzenia, wyłączenie konta, skanowanie antywirusowe) wraz z historią i statusem każdego działania.

Trzy poziomy dojrzałości runbooka M365

PoziomCharakterystykaNarzędzia
PodstawowyRęczne sprawdzanie alertów w portalu, reakcja ad-hocDefender XDR (incidents queue)
ŚredniAutomatyczny triaż przez AIR, ręczna analiza i decyzjeAIR + Defender XDR + Advanced Hunting
ZaawansowanyPełna automatyzacja od detekcji do izolacji, playbooki SOARSentinel automation rules + Attack Disruption + Security Copilot

Fazy runbooka — procedura krok po kroku

Faza 1: Przygotowanie (przed incydentem)

Runbook zaczyna się, zanim cokolwiek się wydarzy. W tej fazie definiujesz:

  • Role i uprawnienia RBAC w portalu Defender — minimum: Security Operator (triaż), Security Administrator (działania naprawcze), Security Reader (audyt)
  • Reguły priorytetyzacji — które typy alertów automatycznie podnoszą severity incydentu
  • Konfigurację powiadomień e-mail o nowych incydentach z filtrami po severity i źródle detekcji
  • Listę assetów krytycznych (critical assets) oznaczonych w Microsoft Security Exposure Management — urządzenia, konta i zasoby chmurowe, których izolacja wymaga dodatkowej autoryzacji
  • Kanał komunikacji kryzysowej — dedykowany kanał w Microsoft Teams zintegrowany z portalem Defender

Faza 2: Detekcja i triaż (pierwsze 15 minut)

  1. Otwórz portal Defender (security.microsoft.com) → Incidents & alerts → Incidents
  2. Posortuj kolejkę po severity (High → Medium → Low → Informational) i przypisz incydent do analityka (Assign to)
  3. Oceń nazwę incydentu — Defender automatycznie nadaje nazwę opisową, np. "Multi-stage incident involving ransomware on multiple devices"
  4. Sprawdź automatyczne działania — jeśli przy incydencie widnieje żółty baner "Attack Disruption", Defender już automatycznie odizolował urządzenia lub wyłączył konta
  5. Zmień status na In Progress i dodaj tagi ułatwiające późniejsze filtrowanie (np. #ransomware, #phishing, #credential-theft)

Faza 3: Analiza i badanie

  1. Przejrzyj atak story — wizualny graf przedstawiający wszystkie elementy ataku: konta, urządzenia, pliki, procesy i relacje między nimi
  2. Wykorzystaj Advanced Hunting do poszerzenia kontekstu — przykładowe zapytanie KQL do wyszukania wszystkich logowań skompromitowanego użytkownika w ostatnich 24 godzinach:
AADSignInEventsBeta
| where AccountUpn == "compromised_user@domena.pl"
| where Timestamp > ago(24h)
| project Timestamp, Application, IPAddress, DeviceName, ErrorCode
  1. Security Copilot generuje podsumowanie w języku naturalnym i sugeruje kolejne kroki
  2. Collect investigation package z podejrzanego urządzenia — pakiet zawiera m.in. logi zdarzeń bezpieczeństwa, listę procesów, połączenia sieciowe, zaplanowane zadania i pliki Prefetch

Faza 4: Izolacja i powstrzymanie

Działania w tej fazie dzielą się na automatyczne i ręczne:

DziałanieAutomatyczne (Attack Disruption)Ręczne
Izolacja urządzeniaTak — izoluje od sieci, zachowując łączność z DefenderIsolate device z panelu urządzenia
Wyłączenie kontaTak — w Active Directory, Entra ID lub obuDisable user w Entra ID
Zablokowanie IPTak — dla niezarządzanych urządzeń (Contain IP, Preview)Ręczne dodanie wskaźnika (indicator)
Ograniczenie wykonywania aplikacjiNieRestrict app execution (tylko podpisane przez Microsoft)
Skanowanie antywirusoweNieRun antivirus scan (Quick / Full)

Automatyczne zakłócanie ataku działa na podstawie korelacji sygnałów z endpointów, tożsamości, poczty e-mail i aplikacji SaaS. Zawiera aktywa kontrolowane przez atakującego w czasie rzeczywistym, zanim dojdzie do ruchu bocznego lub szyfrowania danych (ransomware). Wszystkie automatyczne działania można cofnąć — przycisk Undo w Action Center przywraca stan sprzed izolacji.

Uwaga: Przy izolacji assetów krytycznych (kontrolery domeny, serwery DNS, DHCP) Defender stosuje izolację granularną — blokuje tylko konkretne porty i kierunki komunikacji związane z atakiem, nie przerywając normalnego działania usługi.

Faza 5: Eradykacja i odtwarzanie

  1. Usuń artefakty ataku: złośliwe reguły skrzynki odbiorczej w Exchange Online, przekierowania poczty, ukryte aplikacje w Entra ID
  2. Wymuś reset haseł dla skompromitowanych kont i unieważnij tokeny sesji (revoke sessions w Entra ID)
  3. Przywróć urządzenia z izolacji (Release from isolation) i z ograniczenia aplikacji (Remove app restrictions)
  4. Przeprowadź pełne skanowanie antywirusowe na wszystkich urządzeniach objętych incydentem

Faza 6: Zamknięcie i lessons learned

  1. Zmień status na Resolved z obowiązkowym opisem przyczyny zamknięcia
  2. Sklasyfikuj incydent:
    • True Positive → wybierz typ zagrożenia (ransomware, phishing, BEC fraud, credential theft itd.)
    • False Positive → incydent błędnie wygenerowany
    • Informational, expected activity → np. testy penetracyjne, aktywność Red Team
  3. Wygeneruj raport PDF (Export incident as PDF) — zawiera podsumowanie, graf ataku, listę dotkniętych assetów i pełną historię działań
  4. Przeprowadź post-mortem z zespołem — przeanalizuj Activity Log incydentu i zaktualizuj runbook o nowe wykryte wzorce

Porównanie automatycznego badania a automatycznego zakłócania ataku

CechaAIR (Automated Investigation)Attack Disruption
CelZbadanie alertu i wykonanie podstawowych działań naprawczychZatrzymanie aktywnego ataku w czasie rzeczywistym
WyzwalaczPojedynczy alert (np. podejrzany plik)Incydent skorelowany z wielu sygnałów o wysokiej pewności (≥99%)
ZakresPojedyncze urządzenie / konto / skrzynkaCały incydent — wiele urządzeń, kont, adresów IP
Przykładowe działaniaKwarantanna pliku, zatrzymanie procesuIzolacja urządzenia, wyłączenie konta, blokada IP
Wymagana konfiguracjaAutomatycznie włączone dla urządzeń onboardowanychWymaga włączenia w ustawieniach Defender XDR
Możliwość cofnięciaTak, przez Action CenterTak, przez Undo w Action Center

Kiedy runbook M365 jest wystarczający — a kiedy potrzebujesz Microsoft Sentinel

Sam Defender XDR z wbudowanym AIR i attack disruption pokrywa potrzeby małych i średnich zespołów SOC (1-5 analityków). Jeśli jednak Twoja organizacja:

  • Korzysta z niestandardowych źródeł logów spoza ekosystemu Microsoft (firewalle Palo Alto, Fortinet, rozwiązania chmurowe AWS/GCP)
  • Potrzebuje zaawansowanych reguł korelacji wykraczających poza wbudowane detekcje Defender
  • Wymaga playbooków SOAR opartych na Azure Logic Apps do automatyzacji reakcji na alerty spoza Microsoft

— wtedy niezbędny jest Microsoft Sentinel jako nadrzędna warstwa SIEM/SOAR, zintegrowana z portalem Defender od 2024 roku w ramach unified security operations platform.

Częste pytania

Czy runbook M365 wymaga licencji Microsoft 365 E5?

Nie w całości. Podstawowe funkcje — kolejka incydentów, AIR, izolacja urządzeń, advanced hunting (ograniczony zakres) — są dostępne w ramach Microsoft 365 Business Premium oraz Microsoft Defender for Business. Pełne możliwości attack disruption, zaawansowane advanced hunting na wszystkich tabelach i Microsoft Sentinel wymagają licencji Microsoft 365 E5 lub odpowiednich licencji add-on (Defender for Endpoint Plan 2, Defender for Identity, Defender for Office 365 Plan 2).

Czy automatyczne zakłócanie ataku może przypadkowo zablokować legalną aktywność?

Microsoft utrzymuje poziom pewności (confidence) na poziomie ≥99% dla wszystkich detektorów attack disruption — mierzone jako stosunek sygnału do szumu na podstawie rzeczywistych danych produkcyjnych. Każdy detektor przechodzi walidację w trybie audytu przed wdrożeniem, a wszystkie automatyczne działania można natychmiast cofnąć. Dodatkowo dla assetów krytycznych Defender stosuje izolację granularną zamiast pełnej.

Ile czasu zajmuje wdrożenie podstawowego runbooka M365?

Dla organizacji z już onboardowanymi urządzeniami i skonfigurowanym Defender XDR — 2-3 dni robocze. Obejmuje to: zdefiniowanie ról RBAC, skonfigurowanie powiadomień e-mail, testowy suchy przebieg na symulowanym incydencie (np. przez Attack Simulation Training) i dokumentację wewnętrzną. Pełny, zaawansowany runbook z playbookami Sentinel to projekt na 2-3 tygodnie.

Czy po zamknięciu incydentu dane z badania są dostępne do późniejszego audytu?

Tak. Activity log incydentu zachowuje pełną historię wszystkich działań (zarówno systemowych, jak i ręcznych) i jest dostępny bezterminowo. Dodatkowo możesz wyeksportować pełny raport PDF zawierający podsumowanie, graf ataku, listę assetów i dowody. Dane telemetryczne w Advanced Hunting są przechowywane zgodnie z retencją licencji (domyślnie 30 dni, z możliwością rozszerzenia).

Jaka jest różnica między runbookiem a playbookiem w kontekście Microsoft 365?

Runbook to dokument proceduralny — kompletna instrukcja postępowania od A do Z, obejmująca wszystkie fazy reagowania. Playbook w terminologii Microsoft to automatyczny scenariusz SOAR (zbudowany w Azure Logic Apps), który wykonuje konkretne, zaprogramowane działania w odpowiedzi na alert — np. "jeśli alert phishingowy, automatycznie zablokuj nadawcę i usuń wiadomość ze skrzynek". Runbook może zawierać wiele playbooków jako elementy automatyzacji w poszczególnych fazach.

Jakie są najczęstsze błędy przy pierwszym wdrożeniu runbooka M365?

Trzy najczęstsze: (1) pominięcie konfiguracji RBAC — analitycy nie widzą incydentów lub nie mogą wykonywać działań naprawczych; (2) brak oznaczenia assetów krytycznych — automatyczna izolacja kontrolera domeny może zatrzymać firmę; (3) nieprzeprowadzenie testowego suchego przebiegu — pierwszy prawdziwy incydent ujawnia luki w procedurze, których można było uniknąć.

Czy runbook M365 obejmuje też reagowanie na incydenty w Microsoft Teams i SharePoint?

Tak, pod warunkiem posiadania Microsoft Defender for Office 365 Plan 2 oraz Microsoft Defender for Cloud Apps. Alerty dotyczące podejrzanego udostępniania plików w SharePoint, masowego usuwania wiadomości w Teams czy nietypowego wzorca logowania do aplikacji SaaS są korelowane w tych samych incydentach co alerty z endpointów i tożsamości.


Niezależnie od tego, jaki poziom licencji Microsoft 365 posiadasz — od Business Basic po E5 — skuteczna ochrona zaczyna się od legalnego, prawidłowo aktywowanego oprogramowania. W KluczeSoft.pl znajdziesz licencje Microsoft 365, Windows i Office nawet 50% taniej niż w oficjalnym sklepie Microsoft, z natychmiastową dostawą klucza i polską fakturą VAT. Każda licencja jest w pełni legalna w UE — zgodnie z wyrokiem TSUE UsedSoft vs Oracle i Dyrektywą 2009/24/WE.

<!-- IL-V1 -->

Powiązane artykuły

Najczęściej zadawane pytania

Nie w całości. Podstawowe funkcje — kolejka incydentów, AIR, izolacja urządzeń, advanced hunting (ograniczony zakres) — są dostępne w ramach **Microsoft 365 Business Premium** oraz **Microsoft Defender for Business**. Pełne możliwości attack disruption, zaawansowane advanced hunting na wszystkich tabelach i Microsoft Sentinel wymagają licencji **Microsoft 365 E5** lub odpowiednich licencji add-on (Defender for Endpoint Plan 2, Defender for Identity, Defender for Office 365 Plan 2).
Microsoft utrzymuje poziom pewności (confidence) na poziomie ≥99% dla wszystkich detektorów attack disruption — mierzone jako stosunek sygnału do szumu na podstawie rzeczywistych danych produkcyjnych. Każdy detektor przechodzi walidację w trybie audytu przed wdrożeniem, a wszystkie automatyczne działania można natychmiast cofnąć. Dodatkowo dla assetów krytycznych Defender stosuje izolację granularną zamiast pełnej.
Dla organizacji z już onboardowanymi urządzeniami i skonfigurowanym Defender XDR — **2-3 dni robocze**. Obejmuje to: zdefiniowanie ról RBAC, skonfigurowanie powiadomień e-mail, testowy suchy przebieg na symulowanym incydencie (np. przez Attack Simulation Training) i dokumentację wewnętrzną. Pełny, zaawansowany runbook z playbookami Sentinel to projekt na 2-3 tygodnie.
Tak. Activity log incydentu zachowuje pełną historię wszystkich działań (zarówno systemowych, jak i ręcznych) i jest dostępny bezterminowo. Dodatkowo możesz wyeksportować pełny raport PDF zawierający podsumowanie, graf ataku, listę assetów i dowody. Dane telemetryczne w Advanced Hunting są przechowywane zgodnie z retencją licencji (domyślnie 30 dni, z możliwością rozszerzenia).
Runbook to **dokument proceduralny** — kompletna instrukcja postępowania od A do Z, obejmująca wszystkie fazy reagowania. Playbook w terminologii Microsoft to **automatyczny scenariusz SOAR** (zbudowany w Azure Logic Apps), który wykonuje konkretne, zaprogramowane działania w odpowiedzi na alert — np. "jeśli alert phishingowy, automatycznie zablokuj nadawcę i usuń wiadomość ze skrzynek". Runbook może zawierać wiele playbooków jako elementy automatyzacji w poszczególnych fazach.
Trzy najczęstsze: (1) pominięcie konfiguracji RBAC — analitycy nie widzą incydentów lub nie mogą wykonywać działań naprawczych; (2) brak oznaczenia assetów krytycznych — automatyczna izolacja kontrolera domeny może zatrzymać firmę; (3) nieprzeprowadzenie testowego suchego przebiegu — pierwszy prawdziwy incydent ujawnia luki w procedurze, których można było uniknąć.
Tak, pod warunkiem posiadania **Microsoft Defender for Office 365 Plan 2** oraz **Microsoft Defender for Cloud Apps**. Alerty dotyczące podejrzanego udostępniania plików w SharePoint, masowego usuwania wiadomości w Teams czy nietypowego wzorca logowania do aplikacji SaaS są korelowane w tych samych incydentach co alerty z endpointów i tożsamości. --- *Niezależnie od tego, jaki poziom licencji Microsoft 365 posiadasz — od Business Basic po E5 — skuteczna ochrona zaczyna się od legalnego, prawidłowo aktywowanego oprogramowania. W [KluczeSoft.pl](https://kluczesoft.pl) znajdziesz licencje Microsoft 365, Windows i Office nawet 50% taniej niż w oficjalnym sklepie Microsoft, z natychmiastową dosta

Czy ten artykuł był pomocny?

Runbook reagowania na incydenty Microsoft 365 — kompletna… | Centrum Pomocy KluczeSoft