Entra ID Protection w praktyce: polityki ryzyka, "leaked credentials" i jak przeżyć masową blokadę kont

TL;DR: Entra ID Protection wykrywa ryzykownych użytkowników i może ich zablokować automatycznie — w tym przez fałszywe alarmy, jak incydent MACE z kwietnia 2025, który dotknął setki organizacji globalnie. W tym artykule wyjaśniamy jak działają polityki ryzyka, jak je bezpiecznie wdrożyć, oraz — co ważniejsze — jak szybko odblokować dziesiątki lub setki użytkowników PowerShellem bez wchodzenia ręcznie w panel każdego z nich.

Problem

Wyobraź sobie poniedziałkowy poranek: otwierasz Outlook, a tam 200 alertów z Entra ID Protection — połowa użytkowników twojego klienta ma status High Risk z powodu "leaked credentials". Telefon się urywa od helpdesku. Użytkownicy nie mogą się zalogować — dostają komunikat o konieczności zmiany hasła, ale SSPR nie był skonfigurowany. Masz pół godziny na opanowanie sytuacji.

To właśnie przydarzyło się dziesiątkom administratorów w weekend 19–20 kwietnia 2025. Microsoft uruchomił nową funkcję MACE Credential Revocation, która wykrywa konta z wyciekłymi hasłami — tyle że w trakcie wdrożenia przez pomyłkę zaczęła generować masowe fałszywe alarmy. Konta oznaczone jako High Risk z powodu "leaked credentials" zostały automatycznie zablokowane przez polityki Conditional Access. Efekt: jedna trzecia kont w wielu organizacjach przestała działać w piątek wieczór.

Problem polega na tym, że Entra ID Protection to mechanizm, który przy złej konfiguracji może wyrządzić więcej szkód niż atakujący. Ale przy dobrej konfiguracji — i znajomości pułapek — to jeden z najskuteczniejszych systemów ochrony tożsamości w chmurze. Różnica leży w szczegółach.

Jak działa Entra ID Protection

Entra ID Protection to usługa, która analizuje sygnały z logowań i zachowań użytkowników, a następnie przypisuje ryzyko na poziomie użytkownika (user risk) i logowania (sign-in risk). Każde z nich ma trzy poziomy: Low, Medium i High.

Wykrycia dzielą się na dwa typy czasowe:

• Real-time — blokada następuje już podczas logowania (np. Anonymous IP address, Unfamiliar sign-in properties)
• Offline — ocena następuje po fakcie, na podstawie zebranych danych (np. Atypical travel, Leaked credentials)

Kluczowe wykrycia dla administratorów M365:

Ważne: Leaked credentials jest dostępny nawet bez licencji Entra ID P2 — ale polityki ryzyka (risk policies) wymagają już P2. Bez P2 widzisz alerty, ale nie możesz skonfigurować automatycznej blokady.

Microsoft skanuje dark web, fora z wyciekami danych, bazy law enforcement i inne źródła poprzez Microsoft Threat Intelligence Center (MSTIC) i Digital Crimes Unit (DCU). Gdy znajdzie parę login+hasło pasującą do konta w twoim tenancie, waliduje hash hasła przed emisją wykrycia. To wykrycie zawsze emitowane jest jako High — nie ma możliwości obniżenia tego progu. Jest jedynym wykryciem twardzo ustawionym na maksymalny priorytet.

Incydent MACE z kwietnia 2025: case study

W piątek 18 kwietnia 2025 wewnętrzny system Microsoft przez pomyłkę zapisał podzbiór krótkotrwałych tokenów odświeżania (refresh tokens) zamiast tylko ich metadanych. Aby chronić użytkowników, Microsoft unieważnił te tokeny — co nieumyślnie wygenerowało masowe alerty "leaked credentials" w Entra ID Protection między godziną 4:00 a 9:00 UTC w niedzielę 20 kwietnia.

Winowajcą okazał się nowy service principal o nazwie MACE Credential Revocation (Application ID: 7d636ec3-f39c-44f5-8b73-fa28a0e0c5bc), który pojawił się automatycznie w tenantach tuż przed incydentem. Administratorzy w r/sysadmin zaczęli raportować problem w tym samym czasie: konta oznaczone jako High Risk mimo posiadania unikalnych haseł, nigdy wcześniej nieużytych poza firmą — w tym konta passwordless, które w ogóle nie mają hasła do wycieku.

Skala była znaczna. Dotknęło to zarówno dużych organizacji enterprise, jak i małych firm. Tenanci z Microsoft 365 Business Basic aż po E5 byli dotknięci. Organizacje z Conditional Access i bez niego — obie grupy dostały alerty.

Dla organizacji bez polityk ryzyka: użytkownicy widzieli flagę w raportach, ale mogli się logować normalnie.

Dla organizacji z politykami user risk ustawionymi na blokadę: użytkownicy nie mogli się zalogować w ogóle. Jeśli SSPR nie był skonfigurowany, nie mieli żadnej ścieżki wyjścia bez interwencji admina.

Oficjalne zalecenie Microsoft: użyj funkcji Confirm User Safe w raporcie Risky Users. To oznacza wykrycie jako fałszywy alarm i natychmiast usuwa blokadę.

Incydent MACE nie jest wyjątkiem — to zapowiedź tego, co dzieje się za każdym razem, gdy polityki ryzyka są włączone bez przetestowanej procedury remediacji. Następna przyczyna może być prawdziwy kompromis, błąd Microsoft, albo pentest, który nie został odpowiednio wykluczony. Miej procedurę gotową zanim jej potrzebujesz.

Konfiguracja polityk ryzyka krok po kroku

Microsoft zaleca konfigurację przez Conditional Access, a nie przez starą konsolę ID Protection. To więcej niż preferencja: stare polityki ryzyka (Legacy Risk Policies) w ID Protection zostaną wycofane 1 października 2026. Jeśli nadal ich używasz, zaplanuj migrację przed tym terminem.

Wymagania wstępne (bez nich polityki blokują, ale nie pomagają)

Przed włączeniem polityki user risk musisz skonfigurować:

1. SSPR (Self-Service Password Reset) Bez SSPR zablokowany użytkownik trafia na komunikat o resetowaniu hasła, klika link — i dostaje stronę "Self-service password reset is not enabled". Zablokowany bez wyjścia. Sprawdź: Entra admin center → Protection → Password reset → Properties.

2. Password Writeback dla środowisk hybrydowych Jeśli synchronizujesz z lokalnym AD przez Entra Connect, password writeback musi być włączony po stronie serwera Entra Connect. Bez tego cloud-initiated reset hasła nie propaguje się do AD, a ryzyko pozostaje wysokie bo hash się nie zmienia.

3. Rejestracja MFA dla wszystkich użytkowników przed włączeniem polityk Jeśli użytkownik nie ma zarejestrowanej metody MFA, nie przejdzie przez wyzwanie MFA wymagane do remediacji. Użyj raportu Authentication Methods Activity przed przełączeniem polityki na "On".

Polityka user risk (rekomendacja Microsoft: High)

Entra admin center → Conditional Access → New policy
- Assignments → Users: All users
  - Exclude: break-glass accounts, konta serwisowe
- Target resources: All resources
- Conditions → User risk: High
- Access controls → Grant: Require risk remediation
  (automatycznie dodaje "Require authentication strength" i "Sign-in frequency: Every time")
- Enable policy: Report-only (ZAWSZE zaczynaj od Report-only!)

Polityka sign-in risk (rekomendacja: Medium and above)

Entra admin center → Conditional Access → New policy
- Assignments → Users: All users
  - Exclude: break-glass accounts
- Target resources: All resources
- Conditions → Sign-in risk: High, Medium
- Access controls → Grant: Require authentication strength → MFA
- Session → Sign-in frequency: Every time
- Enable policy: Report-only

Nigdy nie twórz jednej polityki łączącej user risk i sign-in risk w tym samym warunku. Microsoft explicite ostrzega przed tym — te dwa typy ryzyka muszą być w osobnych politykach.

Po co najmniej 7 dniach w trybie Report-only przejrzyj logi w Conditional Access Insights — sprawdź czy polityka nie blokuje nieoczekiwanych kont, kont serwisowych, skryptów automatyzacji. Dopiero potem przełącz na On.

Masowe false positives: jak szybko odblokować setki użytkowników

Gdy nastąpi incydent taki jak MACE, nie masz czasu na ręczne klikanie w portalu dla każdego użytkownika z osobna. Oto pełny workflow PowerShell.

Połączenie z Microsoft Graph

# Wymagana rola: Security Administrator
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All","IdentityRiskyUser.ReadWrite.All"

Wyświetlenie wszystkich użytkowników High Risk

$riskyUsers = Get-MgRiskyUser -Filter "RiskLevel eq 'high'" | 
    Select-Object UserDisplayName, RiskDetail, RiskLastUpdatedDateTime, Id

$riskyUsers | Format-Table UserDisplayName, RiskDetail, RiskLastUpdatedDateTime -AutoSize

Bulk "Confirm User Safe" — remediacja fałszywych alarmów

Gdy potwierdzisz, że wykrycia to false positives, użyj Confirm User Safe. Ta akcja:

• Natychmiast usuwa blokadę
• Informuje Microsoft, że alerty były błędne (pomaga trenować model)
• Ustawia ryzyko na None i uruchamia tryb "learning mode" dla danego konta

# Pobierz ID wszystkich użytkowników High Risk
$userIds = Get-MgRiskyUser -Filter "RiskLevel eq 'high'" | 
    Select-Object -ExpandProperty Id

# Potwierdź wszystkich jako bezpiecznych (fałszywy alarm)
$body = @{
    userIds = $userIds
} | ConvertTo-Json

Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/confirmSafe" `
    -Body $body `
    -ContentType "application/json"

Write-Host "Potwierdzono $($userIds.Count) użytkowników jako bezpiecznych."

Bulk Dismiss — stare lub łagodne ryzyka

Użyj Dismiss dla starych wpisów ryzyka lub gdy ryzyko było realne ale niegroźne (np. autoryzowany pentest). Uwaga: Dismiss NIE informuje Microsoftu o błędach modelu — podobne zdarzenia będą nadal flagowane.

# Wyczyść ryzyka flagowane ponad 90 dni temu
$staleRiskyUsers = Get-MgRiskyUser -Filter "RiskLevel eq 'high'" | 
    Where-Object { $_.RiskLastUpdatedDateTime -lt (Get-Date).AddDays(-90) }

if ($staleRiskyUsers.Count -gt 0) {
    Invoke-MgDismissRiskyUser -UserIds $staleRiskyUsers.Id
    Write-Host "Wyczyszczono $($staleRiskyUsers.Count) starych wpisów ryzyka."
}

Sprawdź konkretny typ wykrycia

# Tylko wykrycia "leaked credentials"
Get-MgRiskDetection -Filter "RiskEventType eq 'leakedCredentials'" | 
    Select-Object UserDisplayName, DetectedDateTime, RiskLevel |
    Sort-Object DetectedDateTime -Descending |
    Format-Table -AutoSize

Typowe pułapki i edge cases

Pułapka 1: Konta passwordless i user risk policy

Użytkownicy logujący się przez FIDO2 lub Windows Hello for Business nie mają hasła do zresetowania. Jeśli twoja polityka user risk wymaga "secure password change" jako remediacji — są trwale zablokowani bez ścieżki wyjścia. Dla kont passwordless potrzebujesz osobnej polityki z grantem Require authentication strength: Passwordless MFA i oddzielnym targetowaniem tej grupy. Mieszanie passwordless i password users w jednej polityce user risk to pułapka, która uderza gdy najmniej się spodziewasz.

Pułapka 2: Opóźnienia danych Report-only i offline detections

Dane w Conditional Access Insights mogą się opóźniać do godziny. Co gorsza, wykrycia offline (Atypical travel, Leaked credentials) są oceniane PO zakończeniu logowania. Użytkownik może zalogować się o 9:00 z poziomem ryzyka None, a o 9:30 zostać oznaczony jako High Risk na podstawie zdarzenia offline. Twoje logi Report-only pokażą "would have blocked" dla przyszłych logowań — nie dla tego, które już się odbyło. Dlatego minimum 10–14 dni w Report-only, obejmujące różne dni tygodnia i wzorce pracy zmianowej, zanim przejdziesz na "On".

Pułapka 3: Konta serwisowe i konta sync

Konto synchronizacji Entra Connect, połączenia Power Automate, konta serwisowe aplikacji trzecich — wszystkie wykonują logowania, które mogą wyzwolić wykrycia jak Anomalous Token lub Unfamiliar sign-in properties. Jeśli nie wykluczysz tych kont z polityk ryzyka, możesz zablokować automatyzację całego środowiska. Każde konto serwisowe musi być explicite w grupie wykluczeń. Docelowo zastąp konta interaktywne Managed Identities.

Pułapka 4: Hybrydowe środowiska bez Password Hash Synchronization

Wykrycie Leaked credentials działa przez porównanie hashy. Dla kont zsynchronizowanych z lokalnego AD poprzez Entra Connect, Password Hash Synchronization (PHS) musi być włączony — bez tego Microsoft nie może walidować hashów i wykrycia leaked credentials po prostu nie działają dla tych kont. Jeśli twoja organizacja wybrała Pass-through Authentication (PTA) lub ADFS zamiast PHS właśnie po to, żeby nie wysyłać hashów do chmury — straciłeś przy tym wykrycia leaked credentials dla kont AD. To świadomy kompromis, który warto mieć odnotowany.

Pułapka 5: Confirm Safe vs Dismiss — różnica ma znaczenie długoterminowo

Obie akcje natychmiast usuwają ryzyko, ale ich efekt długoterminowy jest inny. Confirm Safe informuje model ML Microsoftu, że wykrycie było błędne — pomaga redukować podobne fałszywe alarmy w przyszłości w twoim tenantcie i globalnie. Dismiss traktuje ryzyko jako prawdziwe ale niegroźne — podobne zdarzenia nadal będą generować alerty. Używanie Dismiss zamiast Confirm Safe podczas incydentów takich jak MACE oznacza, że Microsoft nie uczy się z twoich danych. Przy masowych fałszywych alarmach: zawsze Confirm Safe.

Jak my to rozwiązujemy w Evolit

W Evolit zarządzamy dziesiątkami tenantów klientów i incydenty takie jak MACE z kwietnia 2025 pokazały nam jak ważna jest ustrukturyzowana procedura masowego odblokowania. Kiedy nagle 30 użytkowników jednocześnie zgłasza "nie mogę się zalogować", używamy Nexmy do triage'u napływających zgłoszeń helpdesk — zamiast każdego "I can't log in" jako oddzielnego wątku mailowego, wszystkie trafiają do wspólnej kolejki z automatycznym grupowaniem po typie wykrycia. Technik widzi od razu skalę incydentu, konfrontuje z monitoringiem ID Protection i uruchamia skrypt masowego Confirm Safe. Nexma dokumentuje akcję, kto i kiedy ją podjął, i automatycznie informuje użytkowników o przywróceniu dostępu. Alternatywnie, bez Nexmy, możesz użyć samego PowerShella opisanego wyżej — ale zarządzanie 50+ równoległymi zgłoszeniami przez Teams i maile podczas incydentu to przepis na chaos i pominięte konta. Więcej na nexma.app.

Podsumowanie

• Leaked credentials zawsze = High Risk — nie ma konfigurowalnego progu; błędy Microsoft (jak MACE) mogą masowo fałszywie flagować cały tenant
• SSPR i rejestracja MFA muszą być skonfigurowane przed włączeniem polityk — bez nich zablokowany użytkownik nie ma ścieżki wyjścia i każde konto wymaga ręcznej interwencji admina
• Zawsze zaczynaj od Report-only — minimum 7 dni — wykrycia offline i opóźnienia danych sprawiają, że zbyt krótki okres obserwacji daje fałszywe poczucie bezpieczeństwa
• Nigdy nie łącz user risk i sign-in risk w jednej polityce CA — osobne polityki dla każdego typu ryzyka, zgodnie z rekomendacją Microsoft
• Confirm Safe dla fałszywych alarmów, Dismiss dla łagodnych wykryć — różnica ma długoterminowy wpływ na jakość modelu detekcji
• Miej skrypt bulk Confirm Safe gotowy przed incydentem — przetestowany wcześniej skrypt PowerShell to różnica między 30-minutową a 4-godzinną awarią
• Legacy risk policies w ID Protection wychodzą z użycia 1 października 2026 — zaplanuj migrację do Conditional Access już teraz