Czy wiesz, że niektóre logowania są bardziej ryzykowne niż inne? Co więcej, aby je rozróżnić, nie musisz przeglądać logów z usług Microsoft 365 ani bawić się w detektywa na własną rękę. Brzmi ciekawie? Zapraszam do lektury wpisu na temat Azure AD Identity Protection… ekhem Entra ID Protection, usługi, która ma na celu wykrywanie i ochronę przed logowaniami i użytkownikami podwyższonego ryzyka.
Czym jest Entra ID Protection?
Entra ID Protection dawniej znana jako Azure AD Identity Protection to usługa, której celem jest monitorowanie, wykrywanie oraz blokowanie podejrzanych i ryzykownych zdarzeń (Risk detections). W skrócie, Microsoft dba o identyfikację i reakcję na wszelkie anomalie oraz potencjalne próby wykorzystania przejętych kont przy pomocy magii chmury.
Warto wspomnieć, że usługa działa w pełni w chmurze i nie musimy instalować dodatkowych agentów, czy serwerów proxy jak w przypadku Microsoft Entra Password Protection.
Na jakich danych opiera się usługa ID Protection?
Na danych z Twojego tenanta Entra ID oraz sygnałów z innych usług Active Directory, kont Microsoft, a nawet cloud gamingu Xbox 🙂
Te dane przetwarzane są przy użyciu machine learning, ponieważ Microsoft gromadzi tak ogromną ilość danych, że ręczna analiza zdarzeń byłaby niemożliwa. Jest to trochę przerażające, ale z drugiej strony, jeśli Microsoft wykryje jakiekolwiek zagrożenie lub atak, automatycznie zostaniemy objęci ochroną oferowaną przez Entra ID Protection.
Przed czym chroni Entra ID Protection?
Przed wieloma rzeczami. Lista jest dość długa, a ja nie chcę kopiować kropka w kropkę dokumentacji Microsoftu, więc podzielę się z Tobą linkiem.
Nie zostawię Cię jednak z samą nudną dokumentacją. Poniżej znajdziesz krótki opis kilku ryzyk, które mogą pojawić się w naszych testach.
Wybrane zagrożenia, przed którymi chroni Entra ID Protection:
- Hasła będące częścią wycieku (Leaked credentials / offline) - Entra ID sprawdza, czy hasła naszych pracowników nie wyciekły. Jeśli Microsoft odnajdzie w swoich źródłach dopasowanie z naszym użytkownikiem to zostaniemy o tym poinformowani. Całkiem wygodna alternatywa dla ręcznej weryfikacji, o której wspominałem w poprzednim wpisie, ale niekoniecznie ją zastępuje, o czym przeczytasz później.
- Nietypowa podróż (Atypical travel / offline) - wykrywanie logowań, które fizycznie nie byłyby możliwe np. logowanie z Polski i z Chin w odstępie 5 minut.
- Logowania z anonimowych adresów IP (Anonymous IP address / real-time) - wykrywanie wszelkich prób ukrycia swojej prawdziwej lokalizacji, takie jak logowanie za pomocą VPN lub przeglądarki TOR.
- Nietypowe właściwości logowania (Unfamiliar sign-in properties / real-time) - Entra ID analizuje historię logowań naszych użytkowników pod kątem nieprawidłowości, takich jak logowanie z nowego, nieznanego urządzenia lub z adresu IP, z którego pracownik nigdy wcześniej nie korzystał.
PS: W zalinkowanym artykule w kolumnie Detection type możemy sprawdzić, które z ryzyk są weryfikowane w czasie rzeczywistym (real-time - zazwyczaj 5-10 minut), a które wymagają dłuższego czasu na analizę przez Microsoft (offline - do 48 godzin).
Wymagania Entra ID Protection
Pamiętaj, aby zawsze sprawdzić wymagania usługi/produktu, zanim rozpoczniesz testy. Z własnego doświadczenia wiem, że część projektów kończy się właśnie na tym etapie :winking_face:
Licencje
Sprawa jest prosta. Potrzebujemy licencji Azure AD Premium P2 Microsoft Entra ID P2. Co prawda w niższych planach coś tam możemy zobaczyć, ale raczej się tym nie zadowolimy.
Using this feature requires Microsoft Entra ID P2 licenses.
— Microsoft Docs - License requirements - What is Identity Protection?
Dodatkowo, jeśli mamy wiele zintegrowanych aplikacji w Entra ID, możemy zakupić dla nich licencję Workload Identities Premium. Dzięki niej możemy monitorować, czy dane dostępowe do tych aplikacji przypadkiem nie znalazły się w jakimś publicznym repozytorium na GitHub.
AD Connect aka Entra Connect
Co łączy AD Connect Entra Connect z Entra ID Protection? Hasła, a dokładniej ich skróty. Entra Connect może, ale nie musi przesyłać skróty haseł (opcja Password Hash Synchronization) do Entra ID. Jeśli tego nie robi, to Entra ID Protection nie będzie mogła wykrywać wycieków haseł dla kont z lokalnej domeny Active Directory, a na tym nam bardzo zależy.
Jak sprawdzić, czy mam PHS (Password Hash Synchronization)?
Przechodzimy do: Entra admin center -> Identity -> Hybrid management -> Azure AD Connect i wybieramy nasz Entra Connect. W moim przypadku będzie to Connect Sync.
Jak widać opcja Password Hash Sync jest aktywna dla mojej domeny Active Directory.
Microsoft Defender for Cloud Apps (MDCA)
W dokumentacji Entra ID Protection, a dokładniej w opisie alertów, pojawia się nazwa Microsoft Defender for Cloud Apps, ale co to w ogóle jest?
Czym jest Microsoft Defender for Cloud Apps?
Alerty Entra ID Protection głównie bazują na Sign-in logs. Znajdziemy tam m.in. adresy IP, z których były wykonywane logowania, nazwy aplikacji, informacje o kliencie / urządzeniu, a także szczegóły dotyczące uwierzytelniania (MFA) / blokady Conditional Access.
Jak widzisz, nie znajdziesz tu wszystkich danych wymaganych do obsługi alertów z dokumentacji. Weźmy jako przykład alert Mass access to sensitive files. Generuje się on, gdy użytkownik uzyskuje dostęp do zbyt dużej ilości plików w SharePoint lub OneDrive. Czy Entra ID przechowuje takie informacje? Nie :winking_face:
Calculated offline. This detection is discovered using information provided by Microsoft Defender for Cloud Apps. This detection looks at your environment and triggers alerts when users access multiple files from Microsoft SharePoint or Microsoft OneDrive. An alert is triggered only if the number of accessed files is uncommon for the user and the files might contain sensitive information.
— Microsoft Docs - What are risk detections? - Mass access to sensitive files
W Sign-in logs mamy zdarzenia logowania do SharePoint / OneDrive, ale nie znajdziemy tam szczegółów aktywności użytkownika wewnątrz aplikacji. I tu pojawia się Microsoft Defender for Cloud Apps, czyli Cloud Access Security Broker (CASB), który już takie dane zawiera, a Entra ID Protection po prostu z nich korzysta.
Podczas wdrażania Entra ID Protection konieczniej przejrzyj ustawienia Microsoft Defender for Cloud Apps i, jeśli tego wcześniej jeszcze nie zrobiłeś/aś - włącz monitorowanie usług Office 365 oraz Azure AD. Pozwoli Ci to uzyskać dostęp do danych o aktywności użytkowników wewnątrz aplikacji Microsoft 365.
Conditional Access (CA)
W tym momencie najchętniej przekierowałbym Cię do oddzielnego wpisu na temat Conditional Access, jednakże jeszcze takiego nie udostępniłem… Zacznijmy więc od krótkiego wyjaśnienia, czym jest Conditional Access.
Opis CA w pigułce
Conditional Access to taki must-have dla każdej organizacji korzystającej z usług Microsoft 365, więc nie będę tutaj się jakoś mocno rozpisywał. W skrócie jest to taki chmurowy firewall, ale bez portów i protokołów, ale z aplikacjami zintegrowanymi z Entra ID. W regułach CA określamy, którzy użytkownicy i aplikacje mają być chronione, a także jakie warunki muszą zostać spełnione, aby uzyskać dostęp do zasobów firmowych.
Przykład
Załóżmy, że Twoje urządzenia są zarządzane przez Microsoft Intune. Każde z nich posiada atrybut Compliant / Not Compliant kontrolowany przez twoje polityki - Compliance Policies. Jeśli chcesz, aby urządzenia niezgodne lub niezarejestrowane w Intune nie miały dostępu do aplikacji Microsoft 365, możesz stworzyć regułę Conditional Access, która będzie je blokować.
Risk-based Conditional Access
Wracając do Entra ID Protection. Conditional Access dla naszego obrońcy tożsamości stanowi środek przymusu bezpośredniego, który może albo blokować potencjalnie ryzykowne logowania, albo pozwalać na obniżenie ryzyka takich logowań przez użytkowników.
Myślę, że blokada dostępu nie wymaga dodatkowych wyjaśnień, ale czym dokładnie jest możliwość naprawy/obniżenia ryzyka (risk remediation)?
Nie wszystkie ryzyka, które Entra ID Protection zidentyfikuje, wymagają błyskawicznego nalotu działu IT na pracownika. Czasami wystarczy poprosić pracownika o dodatkową weryfikację MFA lub zmianę hasła, zamiast blokować mu dostęp do aplikacji. To właśnie określa się jako risk remediation policy.
Oczywiście to od Ciebie zależy, które ryzyko kwalifikuje się do “naprawy”, a które wymaga zablokowania dostępu i rozmowy z IT.
Porady i wskazówki dla Risk-based Conditional Access
Co warto wiedzieć przed rozpoczęciem tworzenia polityk Conditional Access dla Entra ID Protection?
Pamiętaj o kontach awaryjnych - break glass accounts.
Co może się stać, jeśli jedyne konto Global Adminstratora zostanie zablokowane przez Entra ID Protection? Nie wiem, choć się domyślam 🙂
Upewnij się, że Twoi pracownicy mają skonfigurowane MFA.
Jeśli stworzysz politykę, która umożliwia obniżenie ryzyka poprzez dodatkową weryfikację MFA, a pracownik wcześniej tego MFA nie skonfigurował, to zablokujesz mu dostęp do aplikacji.
Upewnij się, że Twoi pracownicy mają skonfigurowane SSPR.
Tak samo jak w przypadku MFA, resetowanie hasła zależy od innej usługi - Self-Service Password Reset (SSPR), która może być wyłączona lub nieskonfigurowana. Więcej informacji o SSPR znajdziesz w moim wcześniejszym wpisie.
Entra ID Protection bazuje na ryzyku…
…a to jest określane na podstawie poziomów: High, Medium, Low oraz No risk (dla Sign-in risk). Jak pewnie się domyślasz, nie każde logowanie będzie miało najwyższy poziom ryzyka, dlatego używaj opcji wymuszania zmiany hasła / MFA z rozwagą.
Nie twórz polityk w zakładce Identity Protection
Chociaż tworzenie polityk z poziomu Identity Protection jest jeszcze możliwe, nie wiadomo kiedy zostanie to wycofane. Microsoft zaleca tworzenie polityk opartych na ryzyku (risk based) przy użyciu standardowych reguł Conditional Access. Daje nam to większą liczbę ustawień, które możemy wykorzystać w naszych politykach. Po co więc utrudniać sobie życie?
Poziomy ryzyk Entra ID Protection
Skoro możemy tworzyć polityki Conditional Access, określając konkretne poziomy ryzyka, to pewnie są one gdzieś spisane i udokumentowane prawda? No cóż, nie do końca…
Microsoft doesn’t provide specific details about how risk is calculated. Each level of risk brings higher confidence that the user or sign-in is compromised. For example, something like one instance of unfamiliar sign-in properties for a user might not be as threatening as leaked credentials for another user.
Jednak w Internecie nic nie ginie, i w odmętach Internetu można znaleźć starą dokumentację, która klasyfikuje ryzyka w następujący sposób:
| Risk Event | Severity |
|---|---|
| Leaked credentials | High |
| Impossible travel to atypical locations | Medium |
| Sign-ins from anonymous IP addresses | Medium |
| Sign-ins from IP addresses with suspicious activity | Medium |
| Sign-ins from unfamiliar locations | Medium |
| Sign-ins from infected devices | Low |
Czy powyższe dane są aktualne? Pewnie nie, ale zawsze lepsze coś niż nic 🙂
Konfiguracja Entra ID Protection
Identity Protection nie posiada przełącznika, który uruchamia usługę w naszym tenancie. Jeśli mamy odpowiednie licencje, usługa po prostu zacznie oceniać ryzyko i dostarczać nam informacje w portalu administracyjnym. To, co możemy skonfigurować, to alerty i działania, które są widoczne dla naszych pracowników.
Konfiguracja MFA i SSPR
Jak już wspomniałem wcześniej, jeśli nie skonfigurujemy MFA i SSPR, a będziemy ich wymagać, to pracownik straci dostęp do firmowych aplikacji, czego oczywiście nie chcemy. Jak więc skonfigurować obie te usługi?
Konfiguracja MFA
Usługę MFA niekoniecznie musimy konfigurować, co bardziej zmusić pracownika do jej aktywacji (wybór metod uwierzytelniania). Jak to zrobić? Możemy wymusić MFA w ramach dowolnej polityki Conditional Access lub skorzystać z opcji dostępnych w zakładce Identity Protection.
Przechodzimy do: Entra admin center -> Protection -> Identity Protection -> Multifactor authentication registration policy i konfigurujemy ustawienie.
Jak widać na zrzucie ekranu, uruchomiłem rejestrację MFA dla grupy MFA-ADUsers-Enabled, która zawiera moich testowych użytkowników, a jednocześnie wykluczyłem swoje konta administracyjne (break glass accounts).
Efekt? Podczas logowania użytkownik otrzymał prośbę o rejestrację MFA, którą może pomijać przez pierwsze 14 dni, ale akceptujemy to ryzyko.
Konfiguracja SSPR
Kolejną rzeczą, którą możemy użyć do obniżenia ryzyka użytkownika jest zmiana hasła. W usłudze Microsoft 365 za reset haseł odpowiada Self-Service Password Reset (SSPR). Konfigurację SSPR opisałem już wcześniej, dlatego zachęcam do lektury tamtego wpisu.
Szybkie przypomnienie jak uruchomić rejestrację SSPR
Przechodzimy do: Entra admin center -> Protection -> Password reset -> Registration, a następnie zaznaczamy opcję Require users to register when signing in? na Yes.
Konfiguracja SSPR - ważne
Microsoft niedawno usprawnił Entra ID Protection dla kont hybrydowych (zsynchronizowanych z lokalnym AD). Aby włączyć możliwość obniżenia ryzyka poprzez reset hasła dla takich kont, poza konfiguracją SSPR, należy dodatkowo zaznaczyć odpowiednią opcję w panelu administracyjnym.
Przechodzimy do: Entra admin center -> Protection -> Identity Protection -> Settings i zaznaczamy Allow on-premises password change to reset user risk.
Powiadomienia e-mail
Skoro dopłacamy do powiadomień e-mail (w darmowej wersji nie mamy możliwości ich konfiguracji), to warto je włączyć.
Mamy dwa rodzaje powiadomień:
- Weekly digest - Cotygodniowe podsumowanie zdarzeń.
- Users at risk detected alerts - Powiadomienie o pojawieniu się nowego pracownika (lub pracowników) na określonym przez nas poziomie ryzyka (risk level).
Weekly digest
Przechodzimy do: Entra admin center -> Protection -> Identity Protection -> Weekly digest i… no właśnie nie możemy dodać nowych członków!
Na liście znajdują się pracownicy z aktywnymi rolami Global Administrator, Security Administrator lub Security Reader, a pierwsze 20 osób (per rola) otrzyma powiadomienia. Jeśli nie chcemy, aby takie powiadomienia były przesyłane do konkretnej osoby, możemy je dla niej wyłączyć. Jest też opcja wyłączenia wszystkich powiadomień na dole strony (Send weekly digest emails).
Jak wygląda taka wiadomość?
Users at risk detected alerts
Podobnie jak w przypadku Weekly digest pracownicy z aktywnymi rolami Global Administrator, Security Administrator lub Security Reader otrzymują domyślnie powiadomienia. Tym razem mamy jednak możliwość dodania własnego adresu e-mail np. dla naszego działu bezpieczeństwa, który niekoniecznie obsługuje pocztę na kontach z wyższymi uprawnieniami.
Na dole strony możemy też zmienić poziom ryzyka, który wywołuje alert.
Jak wygląda taka wiadomość?
Conditional Access
Czas przejść do ustawień Conditional Access i rozpocząć tworzenie naszych polityk.
Known network locations
Jeszcze przed samą konfiguracją CA warto skonfigurować coś, co automatycznie zwiększy wiarygodność naszych pracowników, czyli Named locations.
Przechodzimy do: Entra admin center -> Protection -> Conditional Access -> Named locations i dodajemy nasze publiczne adresy IP z opcją Mark as trusted location.
Od teraz logowania pracowników z zaufanych adresów będą traktowane łaskawiej przez Entra ID Protection.
Rekomendacja Microsoftu
Nie mogę powiedzieć Ci, jakie dokładnie polityki powinieneś/aś stworzyć. Każda firma jest inna, a to, co może być uciążliwe dla jednych, niekoniecznie będzie takie samo dla innych. Możemy jednak zobaczyć wspólnie, co rekomenduje Microsoft w swojej dokumentacji :winking_face:
Microsoft recommends the below risk policy configurations to protect your organization:
User risk policy - Require a secure password change when user risk level is High. Microsoft Entra multifactor authentication is required before the user can create a new password with password writeback to remediate their risk.
Sign-in risk policy - Require Microsoft Entra multifactor authentication when sign-in risk level is Medium or High, allowing users to prove it’s them by using one of their registered authentication methods, remediating the sign-in risk.
Requiring access control when risk level is low will introduce more user interrupts. Choosing to block access rather than allowing self-remediation options, like secure password change and multifactor authentication, will impact your users and administrators. Weigh these choices when configuring your policies.
Mamy zalecane wartości dla naszych ustawień. Czas stworzyć polityki!
Sign-in risk policy
Zanim zaczniemy tworzyć politykę, zastanówmy się czym właściwie jest Sign-in risk?
Sign-in risk jest analizowane podczas logowania i oznacza prawdopodobieństwo, że próba uwierzytelnienia nie pochodzi od naszego pracownika.
Wymuszenie MFA brzmi świetnie, aby potwierdzić wątpliwości dotyczące takiej nieautoryzowanej próby logowania. Stwórzmy politykę, która będzie to egzekwować.
Przechodzimy do Entra admin center -> Protection -> Conditional Access -> Policies i klikamy przycisk + New policy.
Nasze ustawienia:
- Name: Test Sign-in risk policy
- Assignments: All users (Include), Break-glass accounts (Exclude)
- Cloud apps or actions: All cloud apps (Include)
- Conditions / Sign-in risk: Configure - Yes, Sign-in risk level - Medium, High
- Access controls / Grant: Require multifactor authentication
- Session: Sign-in frequency - Every time
- Enable policy: On
Gotowe! Nasza polityka powinna zacząć działać w przeciągu kilku minut.
User risk policy
Ponownie zaczniemy od definicji naszego ryzyka:
User risk dotyczy konta naszego pracownika i jest weryfikowane offline (nie w czasie rzeczywistym), czyli gdy Microsoft odkryje, że z kontem naszego pracownika może być coś nie tak i najprawdopodobniej jest ono skompromitowane np. hasło pracownika wyciekło.
W takim przypadku samo wymuszenie MFA może nie wystarczyć, dlatego powinniśmy po podaniu MFA dodatkowo poprosić o zmianę hasła do konta pracownika.
Nasze ustawienia:
- Name: Test User risk policy
- Assignments: All users (Include), Break-glass accounts (Exclude)
- Cloud apps or actions: All cloud apps (Include)
- Conditions / User risk: Configure - Yes, Sign-in risk level - High
- Access controls / Grant: Require multifactor authentication, Require password change
- Session: Sign-in frequency - Every time
- Enable policy: On
Gotowe! Nasza polityka powinna zacząć działać w przeciągu kilku minut.
Testy
Koniec teorii, czas na praktykę 🙂 Jednak zanim zaczniemy małe wyjaśnienie, dlaczego możesz poczuć się oszukany/a, choć wcale nie było to moim zamiarem.
Wszystkie rzeczy, które pokazuję na blogu są testowane i uruchamiane na moim tenancie demo. Nie prezentuję tu żadnych informacji z tenantów firm, z którymi współpracuję. Jak się pewnie domyślasz, nie mam tu danych, na których mogę pracować! Testy alertów Identity Protection wymagają logowań i zdarzeń, które karmią algorytmy Microsoftu, a ja niestety nie mam użytkowników, którzy codziennie logują się na swoje komputery i tworzą cyfrowy ślad w Entra ID. Dlatego testy są ograniczone wyłącznie do tego, co mogę pokazać bez takich danych, ale jednocześnie w jakiś stopniu pokazują działanie usługi.
Jeśli możesz pracować na produkcyjnych danych, to Microsoft przygotował scenariusze testów, które możesz wykorzystać - Simulating risk detections in Identity Protection.
Leaked credentials
Na pierwszy ogień idzie test Leaked credentials. Utworzyłem wcześniej użytkownika z bardzo słabym hasłem, które według haveibeenpwned.com jest skompromitowane (wyciekło).
Niestety, nie otrzymałem żadnego alertu od Entra ID Protection. Myślałem, że Microsoft w ramach Leaked credentials aktywnie monitoruje nasze hasła i zwraca nam informację o użytkownikach z wyciękniętymi hasłami, ale jednak nie działa to tak, jak początkowo przypuszczałem. W dokumentacji jest jeden istotny szczegół, który mi umknął, mianowicie:
Why am I not seeing any leaked credentials?
Leaked credentials are processed anytime Microsoft finds a new, publicly available batch. Because of the sensitive nature, the leaked credentials are deleted shortly after processing. Only new leaked credentials found after you enable password hash synchronization (PHS) are processed against your tenant. Verifying against previously found credential pairs isn’t done.
Prawdopodobnie moje hasło nie zostało wykryte, ponieważ: 1) Nie zostało znalezione w żadnym nowym wycieku danych wykrytym przez Microsoft i/lub 2) usługa musi znaleźć zarówno nazwę użytkownika (login), jak i hasło w jednym dopasowaniu/wycieku (para poświadczeń).
No cóż, lekki zawód na samym początku testów. Wychodzi na to, że Entra ID Protection nie zastąpi wdrożenia Entra Password Protection oraz manualnych weryfikacji haseł, o których pisałem wcześniej.
Conditional Access - Sign-in risk policy
Dobrze, to może chociaż przetestujemy utworzone wcześniej polityki Conditional Access i wygenerujemy trochę złowieszczych komunikatów w panelu administracyjnym. Zaczniemy od Sign-in risk policy.
Jak wygląda nasz scenariusz testowy:
Logujemy się na nasze konto testowe (gdziekolwiek), aby sprawdzić, czy nadal działa i czy ma skonfigurowane MFA i SSPR.
Logujemy się na maszynę wirtualną i pobieramy przeglądarkę Tor.
Nie muszę chyba przypominać, aby nie robić tego na firmowym sprzęcie. Sama przeglądarka Tor nie jest niebezpieczna, ale za to źródło, z którego ją pobierzesz może już takie być. Dodatkowo pobranie i uruchomienie przeglądarki Tor najprawdopodobniej wygeneruje alert w konsoli AV/EDR, więc lepiej nie utrudniać życia Twoim adminom.
Uruchamiamy przeglądarkę i łączymy się z siecią Tor. Następnie przechodzimy do dowolnej strony logowania M365 np. https://myapps.microsoft.com
Sprawdzamy, czy otrzymamy prośbę o podanie MFA.
Powyższe działania powinny zostać skategoryzowane przez Entra ID Protection jako Anonymous IP address (Real-time).
Rezultat?
Polityka zadziałała i zostałem poproszony o podanie MFA. Technicznie rzecz biorąc, ryzykowne logowanie zostało “naprawione” poprzez potwierdzenie logowania w aplikacji Microsoft Authenticator, co możemy zobaczyć w panelu administracyjnym w zakładce Risky sign-ins.
Czy takie logowanie spowodowało wysłanie alertu do administratora (e-mail)? Nie, ponieważ zmniejszyliśmy ryzyko pracownika poprzez podanie MFA, a jego poziom w Risky users nie został podniesiony do poziomu Medium/High.
Ciekawostka!
Co widzi pracownik, gdy nie ma skonfigurowanego MFA, a nasza polityka wymaga jego użycia?
Taki błąd, który niekoniecznie mówi, że nie mamy MFA 🙂
Conditional Access - User risk policy
Czas na drugą politykę Conditional Access User risk policy, która może zostać wywołana np. po wycieknięciu hasła pracownika. Niestety, tu pojawia się problem z testowymi tenantami - jak podnieść poziom ryzyka pracownika do poziomu High, jednocześnie nie mając historii jego aktywności w Entra ID?
Odpowiedź to: MFA Fraud alert, a dokładniej ustawienie Report Suspicious Activity.
Report Suspicious Activity
Co to w ogóle jest ‘Report Suspicious Activity’?
Report Suspicious Activity to ulepszona wersja ustawienia Fraud alert. Jak nazwa wskazuje ustawienie służy do zgłaszania przez użytkowników podejrzanych próśb MFA (w aplikacji Microsoft Authenticator lub od fotowoltaiki Microsoftu - automatu telefonicznego), które nie pochodzą od pracowników, a od złodzieja 🙂
Po takim zgłoszeniu użytkownik otrzymuje status High User Risk i będzie obsłużony przez naszą politykę Conditional Access / Identity Protection.
Jak to włączyć?
Przechodzimy do: Entra admin center -> Protection -> Authentication Methods -> Settings
Następnie zmieniamy opcję State na Enabled i zapisujemy przyciskiem Save. Gotowe!
Możliwość zgłoszenia próby MFA włączona, czas na testy User risk policy.
Test User risk policy
Jak wygląda nasz scenariusz testowy:
W zasadzie tak samo, jak w przypadku Sign-in risk policy. Musimy wywołać logowanie, które poprosi nas o MFA, a następnie zgłosić je na telefonie komórkowym.
Po odrzuceniu prośby dostęp do konta nie jest natychmiastowo blokowany. Dzieje się tak, ponieważ nasze ryzyko musi się najpierw zaktualizować. W międzyczasie użytkownik zobaczy ekran z odrzuceniem MFA, ale jeśli ponownie spróbuje się zalogować i potwierdzi MFA, to uzyska dostęp do zasobów.
Po kilku minutach w zakładce Risky users powinniśmy zobaczyć naszego użytkownika z nowym poziomem ryzyka - Risk level High. Na naszą skrzynkę powinien też przyjść alert od Entra ID Protection (User at risk detected).
Nie pozostało nam nic innego, niż naprawa ryzyka poprzez zmianę hasła! Logujemy się raz jeszcze i sprawdzamy, czy zostaniemy poproszeni o zmianę hasła.
Mamy to! Użytkownik otrzymał komunikat, a hasło zostało zmienione bez błędów. Co więcej, konto było zsynchronizowane z lokalnym AD, co dodatkowo potwierdza, że ostatnia opcja dodana przez Microsoft działa, pomimo dopisku preview 🙂
Ostatnia szybka weryfikacja statusu użytkownika w Entra admin center - ryzyko zostało usunięte, co kończy nasze testy.
Podsumowanie
Mam nadzieję, że teraz już wiesz, jak wykrywać i radzić sobie z ryzykownymi logowaniami i użytkownikami w Microsoft 365 / Entra ID.
Jeśli masz jeszcze jakieś pytania lub czujesz, że pozostało coś niewyjaśnionego, to serdecznie zapraszam do odwiedzenia powiązanych linków poniżej. Do zobaczenia w kolejnym wpisie 🙂