Jak Conditional Access i PIM faktycznie zatrzymują ataki?

Polityki haseł zatrzymują ataki siłowe. Nic nie robią wobec skradzionego tokenu sesji, wyłudzonego promptu MFA czy stałego konta administratora, które siedzi sobie z prawami Global Administrator od dwóch lat. Conditional Access i Privileged Identity Management (PIM) to dwie kontrole Azure AD / Entra ID, które faktycznie adresują te luki, i działają najlepiej razem.

Co robi Conditional Access pod maską

Conditional Access to silnik if-this-then-that obliczany w momencie logowania. Strona "if" (sygnały) obejmuje przynależność użytkownika/grupy, stan zgodności urządzenia, lokalizację sieciową, ryzyko logowania (z Identity Protection), aplikację, do której się uzyskuje dostęp, i typ aplikacji klienckiej (przeglądarka vs. starszy protokół). Strona "then" (kontrole) obejmuje: wymaganie MFA, wymaganie zgodnego urządzenia, wymaganie zatwierdzonej aplikacji klienckiej, całkowite zablokowanie dostępu lub wymaganie akceptacji warunków użytkowania.

Polityka, która ma znaczenie w prawie każdej dzierżawie: blokowanie starszego uwierzytelniania. Protokoły takie jak POP, IMAP i starszy SMTP nie obsługują nowoczesnych wyzwań MFA, więc są pierwszą rzeczą, którą próbują narzędzia do atakowania kredencjali. Sprawdź logi logowania filtrowane po "Client App = Other clients" zanim zablokowujesz — często znajdziesz jeden stary skaner lub starą wielofunkcyjną drukarkę nadal uwierzytelniającą się z basic auth.

Druga, którą warto mieć od pierwszego dnia: wymaganie MFA dla wszystkich użytkowników, ograniczone wyłącznie grupą wyjątków dla kont awaryjnych. Nie ograniczaj MFA tylko do "administratorów". Skompromitowane konta użytkowników standardowych to sposób, w jaki atakujący uzyskują swój pierwszy przyczółek jeszcze przed eskalacją uprawnień.

Ryzyko logowania vs. ryzyko użytkownika — inne sygnały, inne odpowiedzi

Identity Protection (część Entra ID P2) generuje dwie oddzielne oceny ryzyka i łatwo je pomylić:

• Sign-in risk — ta konkretna próba uwierzytelnienia wygląda anomalnie (niemożliwa podróż, anonimowy IP, nieznane właściwości logowania).
• User risk — to konto zostało oflagowane z powodu związanym z samą tożsamością (przecieki kredencjali znalezione w zbiorze danych naruszenia, potwierdzona aktywność kompromisu).

Polityka Conditional Access reagująca na ryzyko logowania powinna zwykle wyzwać MFA — jeśli rzeczywisty użytkownik może zrealizować wyzwanie, pozwól mu przejść. Polityka reagująca na ryzyko użytkownika powinna wymusić reset hasła, bo MFA samo w sobie nie pomaga, jeśli samo hasło zostało już skompromitowane.

Dlaczego stały dostęp administratora to większy problem

Nawet przy nieskazitelnym Conditional Access, konto, które stale posiada uprawnienia Global Administrator, to cel leżący w świetle w katalogu. Każdy, kto je skompromituje, dziedziczy pełną kontrolę dzierżawy bez żadnego dodatkowego kroku. PIM usuwa część "stały".

Z PIM, role administratora są przypisywane jako eligible zamiast active. Użytkownik musi jawnie aktywować rolę, co powoduje wymagane uzasadnienie, opcjonalny przepływ zatwierdzeń, potwierdzenie MFA i okno czasowe — zwykle 1 do 8 godzin — po którym rola automatycznie się dezaktywuje. Nikt, łącznie z właścicielem konta, nie ma stałego Global Admin, chyba że właśnie go używa.

Minimalna konfiguracja PIM, która faktycznie się sprawdza

• Każda rola powyżej Helpdesk Administrator: eligible, nie permanentna.
• Global Administrator i Privileged Role Administrator: wymagaj zatwierdzenia od drugiego administratora, nie tylko self-activation.
• Aktywacja MFA wymagana, bez wyjątków.
• Maksymalny czas aktywacji 4 godziny zmusza ludzi do ponownej aktywacji dla rzeczywiście odrębnych sesji pracy, co również tworzy czystsze ścieżki audytu.
• Przeglądy dostępu co 90 dni dla wszystkich uprawnionych przypisań — konta są dodawane do jednego projektu i nigdy nie usuwane.

Gdzie zespoły to źle robią

Najczęstsze błędy to nie projekt polityki, ale lista wyjątków. Polityka Conditional Access z rosnącą grupą "wyklucz tych użytkowników, bo aplikacja nie obsługuje MFA" ostatecznie wyklucza połowę dzierżawy. Śledź wyjątki jako element zaległości z właścicielem i datą usunięcia, nie jako permanentny bucket.

Drugie błędy to konta awaryjne, które nie są faktycznie testowane. Dwa konta awaryjne, wykluczone z Conditional Access i PIM, z długimi losowymi hasłami przechowywanymi offline i alertami na jakiekolwiek logowanie — i ktoś powinien próbować się na nich logować co kwartał, aby potwierdzić, że nadal działają.

Conditional Access i PIM nie są checkboxem dla audytu compliance. To różnica między tym, że wyłudzone hasło jest niedogodnością, a tym, że jest pełnym kompromisem dzierżawy. Jeśli mapujesz kontrole tożsamości w ramach budowy Blue Team, segmenty Cloud and Blue Team Korra Studio omawiają stronę detekcji — jak wyglądają rzeczywiste zdarzenia ryzyka Identity Protection w Sentinel i jak alertować na niemożliwe wzorce aktywacji PIM.