Od strażnika do obserwatora: łączenie zabezpieczeń przed i po uwierzytelnieniu

By Mirko Peters · 2026-08-11

Witamy ponownie w podcaście i w towarzyszącym mu szczegółowym omówieniu technicznym! Jeśli kiedykolwiek miałeś wrażenie, że strategia zabezpieczania tożsamości ma martwy punkt zaraz po tym, jak użytkownik…

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

Witamy ponownie w podcaście i w towarzyszącym mu szczegółowym omówieniu technicznym! Jeśli kiedykolwiek miałeś wrażenie, że strategia zabezpieczania tożsamości ma martwy punkt zaraz po tym, jak użytkownik pomyślnie się zaloguje, na pewno nie jesteś w tym sam. Przez lata organizacje w dużym stopniu polegały na mechanizmach kontroli przed uwierzytelnieniem, aby nie wpuścić złych aktorów, traktując wejście główne jak ostatnią linię obrony. Ale co się dzieje, gdy napastnik przedostanie się przez te drzwi z ważnym tokenem lub skradzionym zestawem poświadczeń? Właśnie ten dylemat był osią naszego ostatniego odcinka, Conditional Access with Defender for Identity Signals. W tym wpisie rozwiniemy te koncepcje i pokażemy, jak połączyć strażnika działającego przed uwierzytelnieniem z obserwatorem działającym po nim, aby zbudować naprawdę odporną architekturę tożsamości.

Najważniejsze wnioski (TL;DR)

Aby naprawdę zrozumieć nowoczesną ochronę tożsamości, trzeba patrzeć na swoje narzędzia jako na wyspecjalizowane role, które współpracują ze sobą w czasie rzeczywistym:

• Conditional Access (CA) to Twój bramkarz. Doskonale podejmuje decyzje przed uwierzytelnieniem na podstawie tego, kto próbuje wejść, skąd się łączy i w jakim stanie jest jego urządzenie.
• Defender for Identity (DfI) to Twój system CCTV połączony z ochroną wewnętrzną. Specjalizuje się w monitorowaniu zachowań po uwierzytelnieniu, ruchu bocznego i anomalii wewnątrz sieci.
• Prawdziwa odporność pojawia się dopiero wtedy, gdy ryzyko po uwierzytelnieniu automatycznie i dynamicznie podnosi próg wymagań przed uwierzytelnieniem – właśnie tu, w trakcie sesji.

Model mentalny

Doprecyzujmy model mentalny tego, jak te komponenty współdziałają w Twoim ekosystemie:

• Strażnik (CA): ocenia, kto się loguje, skąd, stan urządzenia i ryzyko w momencie logowania, a także egzekwuje natychmiastowe kontrole sesji.
• Obserwator (DfI + M365 Defender): wyszukuje ruch boczny, nietypowe wzorce dostępu do zasobów, Kerberoasting, nadużycia NTLM oraz nieoczekiwane eskalacje uprawnień.
• Pętla sprzężenia zwrotnego: Obserwator oznacza podejrzane zachowanie, co z kolei podnosi wynik ryzyka użytkownika lub ryzyka sesji. Zmusza to Strażnika do natychmiastowego zaostrzenia kontroli: wymuszenia MFA, całkowitego zablokowania dostępu lub ograniczenia aktywnej sesji.

Plan integracji (co włączyć i w jakiej kolejności)

Aby te systemy zaczęły ze sobą współpracować, potrzebne jest uporządkowane wdrożenie. Oto plan, którego warto się trzymać:

1. CA uwzględniające ryzyko (konfiguracja bazowa)
   • Entra ID Protection: włącz ocenę ryzyka użytkownika i ryzyka logowania.
   • Utwórz zasady CA:
     • Blokuj, gdy ryzyko użytkownika = wysokie (lub wymagaj zmiany hasła, jeśli procesy w dziale pomocy technicznej to umożliwiają).
     • Wymagaj MFA, gdy ryzyko logowania ≥ średnie.
     • Wymagaj zgodnego urządzenia dla aplikacji o średniej i wysokiej wrażliwości; użyj filtrów urządzeń dla niezarządzanych punktów końcowych, aby kierować je bezpośrednio do ograniczonych kontroli sesji.
2. Pozwól obserwatorowi komunikować się ze strażnikiem
   • Upewnij się, że DfI aktywnie przesyła alerty do Microsoft 365 Defender i Sentinel (jeśli używasz go jako SIEM/SOAR).
   • Zautomatyzuj działania "Potwierdź naruszenie" dla użytkowników w przypadku alertów DfI o wysokiej wadze. Ustawia to ryzyko użytkownika = wysokie w Entra ID Protection, dzięki czemu zasady CA reagują natychmiast.
   • Ścieżka automatyzacji: incydent M365 Defender → Logic App lub Power Automate → Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) → opcjonalnie wymuszenie wylogowania.
   • Włącz Continuous Access Evaluation (CAE) we wszystkich obsługiwanych aplikacjach (Exchange, SharePoint, Graph), aby zmiany zasad rzeczywiście unieważniały aktywne tokeny.
3. Kontrola sesji w celu izolacji zagrożenia
   • W przypadku niezarządzanych lub ryzykownych sesji wdróż Defender for Cloud Apps (serwer proxy sesji) bezpośrednio z poziomu CA:
     • CA → Use Conditional Access App Control (najpierw monitoruj, a następnie blokuj wyprowadzanie danych, takie jak pobieranie, kopiowanie i wklejanie, drukowanie i synchronizacja).
   • Połącz to z ryzykiem urządzenia w MDE → zgodnością w Intune → CA „Wymagaj zgodnego urządzenia” dla wszystkich wrażliwych aplikacji.
4. Zabezpieczenia uprzywilejowanych tożsamości
   • PIM musi wymuszać dostęp Just-in-Time. Przed zezwoleniem na podniesienie uprawnień wymagaj MFA + zgodnego urządzenia oraz braku ryzykownego stanu użytkownika.
   • Wdróż zasadę CA, która blokuje uprzywilejowane role, gdy ryzyko użytkownika ≥ Low (tak, nawet przy niskim ryzyku), aby wymusić natychmiastową analizę przed przejęciem roli administracyjnej.

„Jeśli to, to tamto”: mapowanie sygnałów DfI na działania CA

Mapowanie konkretnych sygnałów wykrywania z Defender for Identity na automatyczne działania dostępu warunkowego i reagowania łączy pasywną obserwację z aktywną obroną:

Zacznij od uruchomienia tych reguł w trybie audytu/monitorowania przez 1–2 tygodnie, a następnie przełączaj reakcje w tryb wymuszania dla każdej klasy alertów, w miarę wzrostu pewności.

Przykładowe zasady (praktyczne, minimalne)

Aby wdrożyć te strategie w środowisku produkcyjnym, oto cztery podstawowe zasady, które warto skonfigurować:

1. Blokuj, gdy ryzyko użytkownika = High
   • Przypisanie: wszyscy użytkownicy (z wyłączeniem kont awaryjnych), wszystkie aplikacje chmurowe
   • Warunki: ryzyko użytkownika = High
   • Udzielenie dostępu: Blokuj dostęp
2. Podwyższenie uwierzytelniania przy ryzyku logowania
   • Przypisanie: wszyscy użytkownicy, aplikacje o wysokiej wartości (portale administracyjne, Exchange, SharePoint, centrum administracyjne Entra)
   • Warunki: ryzyko logowania ≥ Medium
   • Udzielenie dostępu: Wymagaj MFA + Wymagaj zgodnego urządzenia (lub zarządzanego urządzenia)
3. Ograniczenie sesji niezarządzanych
   • Przypisanie: wszyscy użytkownicy, SharePoint/OneDrive/Teams
   • Stan urządzenia: hybrydowe/zgodne = pomiń; niezarządzane = wymuszaj
   • Sesja: Użyj Conditional Access App Control (blokuj pobieranie)
4. Zabezpieczenie podniesienia uprawnień
   • Przypisanie: role katalogowe = uprzywilejowane role administracyjne
   • Warunki: ryzyko użytkownika ≥ Low LUB ryzyko logowania ≥ Medium
   • Udzielenie dostępu: Wymagaj MFA + Wymagaj zgodnego urządzenia; Blokuj, jeśli ryzyko ≥ High

Gotowe playbooki automatyzacji (do podłączenia)

Automatyzacja to tajny składnik, który skraca średni czas powstrzymania zagrożenia (MTTC). Oto dwa playbooki, które można zbudować już dziś:

Playbook A: alert DfI o wysokiej wadze → powstrzymanie tożsamości

• Wyzwalacz: incydent w M365 Defender oznaczony IdentityThreatHigh
• Działania:
  1. Graph API – potwierdź kompromitację użytkownika (ustawia ryzyko użytkownika na High)
  2. Entra ID – natychmiast unieważnij tokeny odświeżania
  3. Intune/MDE – izoluj urządzenie (jeśli jest przypisane jedno główne urządzenie)
  4. ServiceNow/JSM – utwórz zgłoszenie incydentu z osią czasu i zebranymi artefaktami
  5. Powiadom SOC i właściciela użytkownika przez adaptacyjną kartę w Teams z przyciskiem wycofania jednym kliknięciem na wypadek fałszywych alarmów

Playbook B: anomalny wzrost dostępu do SharePoint

• Wyzwalacz: alert Defendera „Nietypowe pobieranie pliku”
• Działania:
  1. Oznacz użytkownika UnderInvestigation za pomocą atrybutów rozszerzeń AAD
  2. Przenieś użytkownika do zasady CA, która kieruje go do App Control (blokada pobierania i drukowania)
  3. Uruchom wstrzymanie eDiscovery dla dotkniętych witryn SharePoint (opcjonalnie, zależnie od wymagań zgodności)
  4. Automatycznie wygaś powstrzymanie po 72 godzinach, chyba że SOC przedłuży je ręcznie

Polowanie i przydatne zapytania

Proaktywne polowanie pomaga wykrywać luki, zanim zostaną wykorzystane przez atakujących. Użyj tych zapytań w Zaawansowanym polowaniu w M365 Defender:

Wzrost dostępu użytkownika do witryn SharePoint w porównaniu z 30-dniowym poziomem bazowym:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Skoki ryzyka logowania ściśle powiązane z późniejszymi alertami DfI:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Metryki potwierdzające skuteczność

Przedstawiając wyniki kierownictwu, potrzebujesz wskaźników, które pokazują realne ograniczenie ryzyka. Śledź te kluczowe wskaźniki efektywności (KPI):

• Średni czas powstrzymania (MTTC) incydentów tożsamości (czas od wygenerowania alertu do egzekwowania zasad dostępu warunkowego) ↓
• Czas przebywania atakującego w środowisku (czas od pierwszej podejrzanej czynności do pełnego usunięcia skutków) ↓
• Zablokowane ryzykowne sesje (zdarzenia, w których uruchomiły się zasady) ↑, przy jednoczesnym spadku wskaźnika fałszywie dodatnich ↓
• Wiek zaległych ryzykownych użytkowników (otwarte sprawy starsze niż 24 godziny) ↓
• Opóźnienie unieważnienia tokenu (mierzone w sekundach) ↓
• Nieudane próby podniesienia uprawnień z powodu ryzyka (wychwycone wcześnie, zanim dojdzie do szkód) ↑, a następnie stabilizacja w czasie
• Secure Score w obszarach tożsamości, urządzeń i aplikacji ↑ bez żadnego odpowiadającego mu wzrostu liczby zgłoszeń do działu pomocy technicznej

Strategia wdrożenia 30/60/90

Nie próbuj zmieniać wszystkiego naraz. Skorzystaj z tego etapowego harmonogramu:

Dni 0–30 (fundamenty)

• Włącz ustawienia ryzyka użytkownika i ryzyka logowania w Entra oraz wdróż podstawowe zasady dostępu warunkowego w trybie audytu, a następnie przejdź do trybu wymuszania.
• Podłącz Defender for Identity do M365 Defender; zweryfikuj alerty i mapowania podstawowych encji.
• Włącz Continuous Access Evaluation (CAE) dla obsługiwanych aplikacji i zintegruj ryzyko urządzenia z MDE z zgodnością w Intune.

Dni 31–60 (informacje zwrotne i powstrzymywanie)

• Zbuduj podręczniki A i B w Logic Apps; przetestuj je dokładnie w stanie dry-run.
• Przeprowadź pilotaż kontroli aplikacji dla niezarządzanych sesji z 2–3 zespołami biznesowymi współpracującymi ze sobą.
• Wdróż zasady zabezpieczające podnoszenie uprawnień w PIM.

Dni 61–90 (wymuszanie i pomiar)

• Przełącz zautomatyzowane podręczniki w pełny tryb wymuszania dla alertów o wysokiej pewności.
• Utwórz skoroszyt bezpieczeństwa tożsamości (w Sentinel lub Power BI), który śledzi wyżej wymienione wskaźniki.
• Przeprowadź kwartalne ćwiczenie purple team, aby zweryfikować MTTC, szybkość unieważniania tokenów i przełączanie zasad dostępu warunkowego w scenariuszu symulowanego ataku na żywo.

Typowe pułapki (i bezpieczniejsze ustawienia domyślne)

Uważaj na te typowe błędy podczas wdrażania:

• Pułapka: poleganie wyłącznie na ryzyku logowania z zasad dostępu warunkowego → Rozwiązanie: reaguj także na ryzyko użytkownika oraz alerty DfI po uwierzytelnieniu.
• Pułapka: brak skonfigurowanego CAE, przez co nieaktualne tokeny podtrzymują skompromitowane sesje → Rozwiązanie: włącz CAE i uwzględnij unieważnianie tokenów bezpośrednio w zautomatyzowanych podręcznikach.
• Pułapka: szerokie blokowanie pobierania plików w całym przedsiębiorstwie, co wywołuje bunt użytkowników → Rozwiązanie: stosuj kontrolę aplikacji selektywnie, tylko gdy sesje są niezarządzane lub ryzykowne.
• Pułapka: lawina alertów i wyniki fałszywie dodatnie spowodowane agresywnymi automatycznymi przepływami pracy dotyczącymi kompromitacji → Rozwiązanie: uzależniaj automatyzacje od weryfikacji wieloma sygnałami (np. alert DfI o wysokim poziomie + nietypowy wolumen pobrań + dostęp poza godzinami pracy).
• Pułapka: konta awaryjne (break-glass) przypadkowo zablokowane przez zautomatyzowane zasady ryzyka → Rozwiązanie: wyklucz dwa intensywnie monitorowane konta awaryjne i rotuj ich poświadczenia co kwartał.

Artefakty do kopiowania i wklejania

Aby przekazać te zmiany w całej organizacji, skorzystaj z gotowych fragmentów:

Jednozdaniowe podsumowanie CAB dla kadry zarządzającej:

Z powodzeniem powiązaliśmy zachowanie użytkowników po zalogowaniu z decyzjami dotyczącymi kontroli dostępu. Jeśli konto zacznie zachowywać się nietypowo, dodajemy dodatkowe utrudnienia bezpieczeństwa lub blokujemy dostęp w trakcie sesji. Znacznie to skraca czas przebywania atakującego w środowisku, nie spowalniając przy tym codziennej pracy.

Uwaga o zmianach dla administratorów:

• Nowe zasady dostępu warunkowego mogą wymuszać uwierzytelnianie wieloskładnikowe (step-up MFA) lub blokować dostęp, gdy wykryte zostanie anomalne ryzyko. Aktywne tokeny uwierzytelniania można teraz unieważniać w trakcie sesji na podstawie danych telemetrycznych. Konta awaryjne (break-glass) pozostają wyraźnie wyłączone. Prosimy o monitorowanie skoroszytu Identity Resilience w celu analizy wpływu.

Powiadomienie w Teams dla właścicieli (automatyczne):

• „Zauważyliśmy nietypową aktywność plików pochodzącą z Twojego konta. Zastosowaliśmy tymczasowe zabezpieczenia (na przykład wyłączenie pobierania na urządzeniach niezarządzanych). Jeśli to Ty, po prostu kliknij Potwierdzam; jeśli nie, kliknij od razu Zgłoś.”