Jędrzej Boguszyński

Polityki dostępu warunkowego w Microsoft Entra ID to potężne narzędzie, które pozwala wdrażać zasady architektury bezpieczeństwa Zero Trust. Jednak ogrom opcji i możliwości ich konfiguracji potrafi przytłoczyć nawet doświadczonych administratorów.

W tym artykule wyjaśnię, czym dokładnie jest Conditional Access, jakie licencje są wymagane do jego obsługi oraz jak skutecznie konfigurować polityki i co dzięki nim możemy osiągnąć. Na koniec podzielę się z Wami sprawdzonymi przykładami, które najczęściej wdrażam u swoich klientów, aby skutecznie zabezpieczyć ich środowiska chmurowe. Zaczynajmy!

Wymagania licencyjne

Aby korzystać z polityk dostępu warunkowego w Entra ID, potrzebujemy przynajmniej licencji Microsoft Entra ID P1. Oferuje ona większość funkcji niezbędnych do skonfigurowania solidnych zasad bezpieczeństwa. Jeśli jednak chcemy skorzystać z pełnego wachlarza możliwości, jakie daje Conditional Access (w skrócie CA) – takich jak weryfikacja oparta na ryzyku użytkownika (risk-based validation) czy zaawansowane funkcje ochrony tożsamości (Identity Protection) – niezbędna będzie wersja P2.

Warto pamiętać, że Microsoft wymaga licencji dla każdego użytkownika, który jest objęty działaniem polityk, a nie tylko dla administratorów czy samego tenanta. Najbardziej opłacalnym rozwiązaniem jest zakup licencji w pakiecie z innymi usługami Microsoft 365, np. w ramach planów Business Premium, E3 lub E5. Aby ułatwić Wam odnalezienie się w tym „licencyjnym bałaganie”, poniżej znajdziecie kompletną mapę dostępnych opcji: https://m365maps.com/

Konfiguracja polityk CA

Wyłączenie security defaults

Gdy mamy już odpowiednie licencje, musimy wykonać jeszcze jeden krok przed przystąpieniem do konfiguracji: wyłączyć Security Defaults. Funkcja ta jest domyślnie uruchamiana na wszystkich nowych tenantach Entra ID. Jest to podstawowy mechanizm bezpieczeństwa, który automatycznie zarządza procesem logowania i wymusza m.in. MFA. Ponieważ jednak Security Defaults to rozwiązanie typu „wszystko albo nic”, musimy je dezaktywować, aby móc tworzyć własne, precyzyjne polityki dostępu warunkowego.

Aby wyłączyć Security Defaults, przechodzimy do Entra ID -> Overview -> Properties. Na samym dole panelu znajdziecie odnośnik odpowiadający za ich konfigurację – klikamy „Manage security defaults”, zmieniamy status na „Disabled” i zatwierdzamy przyciskiem Save.

Musimy oczywiście odczekać około 15 minut, aż zmiany się rozpropagują, i możemy zabierać się za konfigurację naszych polityk CA!

Omówienie polityk CA

Tak jak wspomniałem wcześniej – najprościej ujmując, polityki CA odpowiadają za zarządzanie procesem logowania. Przy ich pomocy możemy konfigurować zaawansowane reguły określające, kto, kiedy i na jakich zasadach ma otrzymać dostęp do naszych aplikacji i usług. Każda próba logowania jest weryfikowana w czasie rzeczywistym i zestawiana z naszymi regułami. Na tej podstawie system podejmuje decyzję o przyznaniu dostępu, wymuszeniu dodatkowej weryfikacji lub całkowitym zablokowaniu użytkownika.

Warto jednak pamiętać, że wraz z ogromną mocą polityk CA wiąże się też ryzyko („With great power comes great responsibility!”). Błędna konfiguracja może utrudnić pracę, a w skrajnych przypadkach całkowicie zablokować dostęp do tenanta, usług czy aplikacji (w dalszej części pokażę Wam, jak bezpiecznie testować ich działanie i jak skutecznie przeprowadzać troubleshooting).

Aby skonfigurować naszą pierwszą politykę CA, przechodzimy do Entra ID -> Protection -> Conditional Access -> Policies i wybieramy opcję „+ New policy”.
Możemy również wybrać opcję „+ New policy from template”, aby skorzystać z gotowych szablonów dostarczonych przez Microsoft. Warto tam zajrzeć, jeśli szukacie inspiracji lub gotowych instrukcji dotyczących zabezpieczania dostępu. My jednak skupimy się na samodzielnej konfiguracji od zera, abyście w pełni zrozumieli, jak działa każdy z mechanizmów.

Po wybraniu opcji tworzenia nowej polityki otworzy się formularz konfiguracyjny. Na start musimy oczywiście podać jej nazwę. Warto już na tym etapie opracować standard nazewnictwa i konsekwentnie się go trzymać. Dzięki temu, gdy liczba polityk wzrośnie, łatwo będziecie mogli na pierwszy rzut oka ocenić, za co odpowiada każda z nich.

Przejdziemy po kolei przez wszystkie dostępne opcje i dokładnie je omówimy, zaczynając od sekcji „Users or agents”.

Users or agents

W tej rubryce wskazujemy, kogo ma dotyczyć nasza polityka CA. Mogą być to konkretni użytkownicy (w tym goście zewnętrzni), grupy (zarówno Microsoft 365, jak i grupy bezpieczeństwa) czy określone role w Microsoft Entra ID. Warto zaznaczyć, że od niedawna możemy konfigurować polityki CA również dla agentów AI zarejestrowanych w naszym tenancie.

Oprócz wskazania, kogo ma dotyczyć nasza polityka, możemy również skonfigurować wyjątki (Exclude). Podobnie jak w przypadku przypisań, wykluczenia mogą obejmować gości, użytkowników, grupy, role czy agentów AI.

Zgodnie z najlepszymi praktykami (best practices), wyjątki najlepiej konfigurować dla grup (np. dedykowana grupa dla kont serwisowych wyłączonych z MFA). Unikamy dodawania pojedynczych użytkowników, ponieważ przy większej skali drastycznie utrudnia to administrację i audyt.

Konto „Break-glass” – Twoja polisa ubezpieczeniowa

Kluczowym elementem strategii bezpieczeństwa jest skonfigurowanie konta „break-glass”. To awaryjne konto administracyjne, wyłączone ze wszystkich polityk CA. Działa ono niczym gaśnica za szybą, którą zbijamy tylko w razie poważnej awarii. Aby takie konto było bezpieczne, należy przestrzegać rygorystycznych zasad higieny:

• Anonimowość: Nazwa konta nie powinna sugerować uprawnień (np. unikaj administrator@... lub breakglass@...), aby nie przyciągać uwagi potencjalnych atakujących.
• Bezpieczeństwo hasła: Hasło powinno być przechowywane w bezpiecznym miejscu (np. w fizycznym sejfie). Dobrą praktyką jest podzielenie go na dwie części i przekazanie ich różnym osobom (np. szefowi IT oraz Security).
• Jednorazowość: Konto break-glass traktujemy jako jednorazowe. Po każdym użyciu należy je usunąć (lub zresetować mu uprawnienia i hasło) i skonfigurować na nowo.

Pamiętajcie, że konto to będzie posiadało uprawnienia Global Administrator i nie będzie chronione przez MFA ani inne polityki CA. Oznacza to, że do przejęcia pełnej kontroli nad tenantem wystarczy samo hasło. Używamy go wyłącznie w sytuacjach krytycznych – na przykład wtedy, gdy błędnie skonfigurowana polityka CA odetnie dostęp wszystkim administratorom korzystającym z kont imiennych.

Target resources

W tej sekcji wskazujemy zasoby, których ma dotyczyć nasza polityka. Do wyboru mamy trzy główne opcje:

• Resources (formerly cloud apps): Tutaj wybieramy konkretne aplikacje zarejestrowane w naszym tenancie (lub poza nim) oraz zasoby agentów AI.
• User actions: Pozwala na zabezpieczenie konkretnych działań użytkownika, takich jak dodawanie informacji bezpieczeństwa (Security info) do konta czy rejestracja nowego urządzenia w Entra ID.
• Authentication context: To zaawansowana funkcja pozwalająca na tworzenie własnych definicji kontekstu logowania, które możemy następnie przypisywać do konkretnych danych w aplikacjach (np. wymuszenie mocniejszego uwierzytelnienia tylko przy dostępie do szczególnie wrażliwych dokumentów w SharePoint).

Na tej samej zasadzie możemy oczywiście dodawać wyjątki. Jest to przydatne, gdy chcemy na przykład, aby panele administracyjne Microsoftu były wyłączone z konkretnej polityki, podczas gdy reszta aplikacji zarejestrowanych w tenancie pozostaje nią objęta.

Network

W tej rubryce definiujemy, dla jakich lokalizacji sieciowych ma obowiązywać nasza polityka. Mogą to być konkretne publiczne adresy IP lub koordynaty geolokalizacyjne (np. określony kraj). Własne lokalizacje konfigurujemy wcześniej w zakładce Entra ID -> Conditional Access -> Named locations. Możemy tam utworzyć np. pozycję o nazwie „Biuro Warszawa” i przypisać do niej publiczne adresy IP, z których po NAT wychodzi ruch sieciowy z naszego biura. Funkcja ta integruje się również z Microsoft Entra Global Secure Access (GSA), jednak temat ten wykracza poza zakres niniejszego artykułu.

Conditions

W tej rubryce wskazujemy warunki, które muszą zostać spełnione, aby dana polityka CA zadziałała dla wybranych przez nas zasobów. Możemy skonfigurować następujące parametry:

• User risk (Ryzyko użytkownika): Określa aktualny status bezpieczeństwa konta. Na tę statystykę wpływają podejrzane logowania oraz incydenty wykryte przez Microsoft Defender dla danego użytkownika lub jego urządzeń. Ryzyko to może przyjmować trzy wartości: High, Medium oraz Low.

• Sign-in risk (Ryzyko logowania): Dotyczy analizy samej sesji logowania. System bierze pod uwagę np. adresy IP oznaczone przez Microsoft Threat Intelligence jako złośliwe (malicious) lub podejrzane zachowania behawioralne, takie jak „niemożliwa podróż” (np. logowanie z Polski, a sekundę później z Rosji). W tym przypadku mamy do wyboru cztery wartości: High, Medium, Low oraz No risk.

• Insider Risk (Ryzyko wewnętrzne): Funkcja ta korzysta z adaptacyjnej ochrony dostępnej w pakiecie Microsoft Purview, służącym do dbania o bezpieczeństwo danych w ekosystemie Microsoft 365. Insider Risk dotyczy zagrożeń pochodzących od osób wewnątrz organizacji (pracowników). Odpowiednio skonfigurowana usługa pozwala wykryć np. masowe kopiowanie danych na nośnik USB lub wysyłanie dużej liczby poufnych plików na prywatną pocztę przez pracownika będącego na okresie wypowiedzenia. Poziom ryzyka może przyjmować wartości: Elevated, Moderate oraz Minor.

• Device platforms (Platformy urządzeń): Ta sekcja pozwala wskazać systemy operacyjne, na których pracuje (lub z których łączy się) użytkownik. Możemy tu zdefiniować platformy, dla których polityka ma być aktywna, oraz określić wyjątki. Do dyspozycji mamy większość systemów wykorzystywanych w biznesie, takich jak: Windows, iOS, Android, macOS czy Linux.

• Locations (Lokalizacje): Jest to to samo ustawienie, które widzieliśmy wcześniej w sekcji Network. Microsoft obecnie przenosi konfigurację sieci poza kontekst warunków (Conditions) w politykach CA, dlatego przejściowo te same opcje możemy znaleźć w dwóch różnych miejscach.
• Client apps (Aplikacje klienckie): Ta sekcja pozwala wskazać, jakich programów lub protokołów używa użytkownik podczas łączenia się z zasobami. Do wyboru mamy:
  • Przeglądarki,
  • Aplikacje mobilne i desktopowe,
  • A także starsze metody uwierzytelniania (Legacy Authentication), uważane aktualnie za niebezpiecznie ponieważ nie obsługują MFA:
    • Klienty Exchange ActiveSync,
    • Inne klienty (np. protokoły poczty IMAP czy POP3).

• Filter for devices (Filtry urządzeń): Tutaj możemy skonfigurować własne filtry, jeśli chcemy, aby polityka CA działała tylko dla wybranych urządzeń spełniających określone kryteria. Składnia budowania zapytań jest zbliżona do tej znanej z PowerShell i bazuje na atrybutach urządzeń (np. nazwa, producent, model lub Custom Security Attributes – czyli pary nazwa:wartość, które możemy zdefiniować w Entra ID i przypisać do konkretnych zasobów sprzętowych).

• Authentication flows (Przepływy uwierzytelniania): W tej sekcji możemy wskazać specyficzne przepływy (workflow) procesu logowania. Pozwala to na kontrolowanie np. transferu tokenów między aplikacjami lub wymuszanie konkretnych ścieżek uwierzytelniania dla nowoczesnych protokołów. Jest to nowa funkcjonalność dostępna od niedawna w Entra ID.

Grant

Jest to pierwsza funkcja z podkategorii kontroli dostępu. Do tej pory konfigurowaliśmy, kogo, czego oraz jakich specyficznych warunków ma dotyczyć nasza polityka. W momencie, gdy próba logowania spełni wszystkie te kryteria, system uruchamia zdefiniowane w tym miejscu kontrole dostępu.

W tej sekcji decydujemy, czy próba dostępu ma zostać zablokowana (Block access), czy dopuszczona (Grant access). W przypadku przyznania dostępu możemy określić dodatkowe wymogi, takie jak:

• Konieczność ukończenia weryfikacji dwuetapowej (MFA) poza samym hasłem.
• Konieczność aby urządzenie z którego łączy się użytkownik było członkiem organizacji (Microsoft Entra hybrid joined device).

Co ważne, przy zezwalaniu na dostęp możemy zdecydować, czy użytkownik musi spełnić wszystkie zaznaczone wymagania, czy wystarczy spełnienie tylko jednego z nich.

Warto wspomnieć, że od jakiegoś czasu, zamiast standardowego wymuszania MFA, możemy skorzystać z funkcji Require authentication strength. Pozwala ona precyzyjnie określić, jak silnej metody uwierzytelniania oczekujemy od użytkownika. Do wyboru mamy m.in.:

• Multifactor authentication: Standardowe MFA, czyli połączenie hasła z kodem SMS, połączeniem telefonicznym lub powiadomieniem w aplikacji Microsoft Authenticator.
• Passwordless MFA: Użytkownik w ogóle nie podaje hasła – loguje się za pomocą aplikacji Microsoft Authenticator z potwierdzeniem biometrycznym lub korzysta z funkcji Windows Hello for Business.
• Phishing-resistant MFA: Najwyższy poziom bezpieczeństwa. Obejmuje metody odporne na przejęcie sesji, takie jak klucze FIDO2 oraz uwierzytelnianie oparte na certyfikatach. W przypadku aplikacji Microsoft Authenticator opcja ta wykorzystuje funkcję device bound, która może wymagać np. obecności urządzenia mobilnego w pobliżu komputera (Bluetooth), co gwarantuje, że osoba logująca się jest fizycznie przy urządzeniu.

Session

Jest to druga podkategoria kontroli dostępu. Pozwala ona zarządzać parametrami sesji użytkownika, na której uruchomienie zezwoliliśmy za pomocą polityki CA.

Mamy tutaj do dyspozycji szereg zaawansowanych opcji, które pozwalają m.in.:

• Skorzystać z Conditional Access App Control: Wykorzystać integrację z pakietem Microsoft Defender for Cloud Apps, aby np. zablokować użytkownikowi możliwość pobierania plików na niezaufane urządzenie podczas trwania sesji przeglądarkowej.
• Wyznaczyć częstotliwość logowania (Sign-in frequency): Określić, co ile godzin lub dni sesja wymaga ponownego uwierzytelnienia użytkownika.
• Uruchomić ochronę tokenów (Token protection): Powiązać token OAuth z konkretnym urządzeniem, co zapobiega jego przejęciu i użyciu na innym sprzęcie przez cyberprzestępcę.

Jak testować polityki CA?

Kiedy nasza polityka jest już skonfigurowana, przed jej ostatecznym zapisaniem mamy do wyboru trzy opcje w sekcji Enable policy: On, Off oraz Report-only. O ile dwie pierwsze są oczywiste, o tyle warto zatrzymać się przy trybie Report-only.

Jest to swego rodzaju „dry run” (test na sucho). Polityka jest aktywna i weryfikuje próby logowania, ale nie wymusza żadnych restrykcji. Zamiast tego zbiera dane i tworzy raporty z faktycznego zastosowania reguł. To najlepsze rozwiązanie po stworzeniu nowej polityki – zaleca się pozostawienie jej w tym trybie na tydzień lub dwa (zależnie od wielkości organizacji).

Pozwala to sprawdzić, na jakie logowania wpływa polityka i czy nie blokuje ona dostępu w niepożądany sposób – dotyczy to zarówno logowań interaktywnych (użytkowników), jak i nieinteraktywnych (aplikacji czy kont serwisowych). Dopiero gdy mamy pewność, że reguły działają precyzyjnie i bezpiecznie, możemy przełączyć politykę w tryb On, aby stała się w pełni egzekwowalna.

Aby wyświetlić raport działania danej polityki, wystarczy w nią kliknąć, a następnie wybrać opcję View policy impact. Zostanie wyświetlony interaktywny wykres, dzięki któremu możemy zweryfikować pokrycie polityki oraz przeanalizować konkretne zdarzenia: udane próby logowania, na które reguła zezwoliła, oraz te nieudane, które zostałyby zablokowane.

Najczęściej konfigurowane przeze mnie polityki CA

Tak jak obiecałem na początku artykułu, przedstawię teraz kilka przykładów polityk CA, które najczęściej konfiguruję u moich klientów lub które regularnie pojawiają się w środowiskach biznesowych, w jakich pracuję:

Przykład 1: Wymuszanie MFA dla wszystkich użytkowników
To podstawowa i niezwykle skuteczna polityka. Jej konfiguracja wygląda następująco:

• Users (Użytkownicy): Wybieramy All users. Z polityki bezwzględnie wyłączamy (Exclude) konta serwisowe oraz konta typu Breakglass (awaryjne).
• Goście (Guest users): Zostawiamy ich w polityce! Częstym błędem, który widzę, jest dodawanie gości do wyjątków, ponieważ MFA utrudnia im pracę (zwłaszcza gdy pracują na wielu tenantach i mają kilka osobnych kont w aplikacji Authenticator). Zamiast osłabiać bezpieczeństwo wyjątkami, lepiej skonfigurować B2B cross-tenant access settings. Pozwala to na włączenie Trust settings, dzięki którym nasz tenant będzie akceptował MFA wykonane przez gościa w jego macierzystej domenie (akceptacja tokenów OAuth).
• Target resources: Wybieramy All resources (dawniej „All cloud apps”).
• Grant: Zaznaczamy Require multi-factor authentication.

Przykład 2: Wzmocnione MFA dla administratorów
Polityka ta pozwala na dodatkowe zabezpieczenie kont z uprawnieniami administracyjnymi, które są najbardziej narażone na ataki.

• Users (Użytkownicy): Wybieramy Selected users and groups, a następnie wskazujemy konkretne Directory roles (np. Global Administrator, Privileged Role Administrator) lub dedykowaną grupę, w której znajdują się wszyscy administratorzy.
• Target resources: Wybieramy All resources (dawniej „All cloud apps”) lub ograniczamy się do portali administracyjnych Microsoftu (np. Microsoft Admin Portals).
• Grant: Zaznaczamy Require authentication strength i wskazujemy na Passwordless MFA lub Phishing-resistant MFA. Dzięki temu administratorzy nie będą mogli korzystać ze słabszych metod, takich jak SMS, wymuszając użycie np. kluczy FIDO2.
• Session (Sesja): Włączamy Sign-in frequency i ustawiamy wartość na 24 godziny (podejście restrykcyjne) lub 7 dni (podejście zrównoważone). Wymusza to na administratorach regularne odświeżanie sesji i generowanie nowego tokena OAuth.
  • Warto również włączyć funkcję Token protection, aby powiązać token z konkretnym urządzeniem administratora.

Przykład 3: Blokowanie przestarzałych protokołów (Legacy Authentication)
Polityka ta ma na celu całkowite odcięcie metod logowania, które nie wspierają nowoczesnych standardów bezpieczeństwa. Protokoły takie jak IMAP4, POP3 czy Authenticated SMTP nie obsługują MFA, co czyni je idealnym celem dla ataków typu password spray, brute-force czy MFA bypass.

• Users: Wybieramy All users. Warto włączyć do tej polityki również konta serwisowe, chyba że masz absolutną pewność, iż są one wykorzystywane w starszych aplikacjach, które wymagają tych protokołów do działania.
• Target resources: Wybieramy All resources (dawniej „All cloud apps”).
• Conditions (Warunki): Przechodzimy do zakładki Client apps, a następnie zaznaczamy:
  • Exchange ActiveSync clients
  • Other clients (to tutaj kryją się m.in. IMAP i POP3).
• Grant: Zaznaczamy Block access.

Przykład 4: Dostęp wyłącznie z urządzeń firmowych (Compliant Devices)
Polityka ta stanowi fundament modelu Zero Trust. Jej celem jest upewnienie się, że zasoby firmy nie są otwierane na prywatnych, niezarządzanych urządzeniach, które mogą być zainfekowane lub nie spełniać norm bezpieczeństwa.
Ważne: Ta opcja wymaga posiadania licencji na Microsoft Intune oraz urządzeń zarejestrowanych w usłudze MDM (Mobile Device Management).

• Users: Wybieramy All users (lub konkretną grupę pracowników operujących na wrażliwych danych) i ponownie bezwględnie wyłączamy z tej polityki konta Breakglass (serwisowe) i techniczne.
• Target resources: Wybieramy All resources (lub kluczowe aplikacje, jak SharePoint czy Teams).
• Grant: Wybieramy opcję Grant access, a następnie zaznaczamy:
  • Require device to be marked as compliant – wymusza, aby urządzenie spełniało reguły zgodności zdefiniowane w Intune (np. aktywny BitLocker, aktualny system, brak jailbreaka).
  • Require multi-factor authentication – aby wzmocnić bezpieczeństwo (opcjonalne).
  • Logika: Koniecznie zaznaczamy opcję „Require all the selected controls”, aby użytkownik musiał spełnić oba warunki jednocześnie (jeżeli dodaliśmy też wymóg MFA).

Na co uważać? Administratorzy często konfigurując tę politykę, zapominają o platformach urządzeń. Jeśli nie ograniczymy polityki do Windows / macOS / iOS / Android, możemy przypadkowo zablokować dostęp z urządzeń, których Intune nie wspiera, a które są niezbędne do pracy. Warto też pamiętać o wyłączeniu z tej polityki kont typu breakglass, aby w razie awarii Intune’a nie stracić całkowicie dostępu do tenanta.

Przykład 5: Dostęp wyłącznie z lokalizacji firmowych (Trusted Locations)
Polityka ta ogranicza możliwość logowania do zasobów firmy wyłącznie do zaufanych sieci biurowych lub bezpiecznych połączeń VPN.

• Named Locations (Warunek wstępny): Zanim stworzysz politykę, musisz w panelu Entra ID (zakładka Named locations) zdefiniować publiczne adresy IP Twojego biura lub bramy VPN.
• Users: Wybieramy All users (lub specyficzną grupę, np. dział finansowy) i oczywiście dodajemy nasze konta serwisowe i konto Breakglass do wyjątków.
• Target resources: All resources lub wrażliwe aplikacje.
• Conditions (Location): W zakładce Locations wybieramy Include -> Selected locations, a następnie wskazujemy stworzone wcześniej lokalizacje firmowe.
• Grant: Zaznaczamy Grant access (często łączone z wymogiem MFA).

Ważna uwaga: Pamiętaj, że polityka ta obejmie również ruch po VPN tylko wtedy, gdy Twój VPN jest skonfigurowany w trybie Full Tunnel (cały ruch internetowy przechodzi przez biuro). Jeśli korzystasz ze Split Tunneling, ruch do usług Microsoft 365 będzie wychodził bezpośrednio z domowego adresu IP pracownika, co spowoduje zablokowanie dostępu przez tę politykę.

Przykład 6: Automatyczne reagowanie na wysokie ryzyko (User Risk)
Polityka ta pozwala systemowi na błyskawiczną reakcję, gdy Microsoft Entra ID Protection wykryje, że konto użytkownika zostało prawdopodobnie przejęte (np. dane logowania pojawiły się w sieci lub wykryto nietypowy sposób logowania).

• Users: Wybieramy All users. Oczywiście wyłączamy z niej konta administracyjne i techniczne (Breakglass) – to złota zasada każdej polityki, która może odciąć dostęp do tenanta.
• Target resources: All resources.
• Conditions (User risk): Ustawiamy poziom ryzyka na High.
• Grant: Grant: Grant: Wybieramy opcję Require risk remediation.

Jak to działa w praktyce? Funkcja ta, zależnie od kategorii zdarzenia, które sprawiło, że status ryzyka użytkownika wskoczył na wyższy poziom, wykona odpowiednie akcje naprawcze. System, wspierany przez globalne dane Threat Intelligence Microsoftu, może m.in.:

• Unieważnić wszystkie aktywne sesje i wymusić ponowną reautentykację z użyciem MFA.
• Wymusić bezpieczną zmianę hasła (Self-Service Password Reset), jeśli istnieją dowody na to, że aktualne hasło wyciekło do sieci.

Dzięki temu zagrożenie jest neutralizowane automatycznie i w czasie rzeczywistym, co drastycznie skraca czas reakcji na incydent.