Zacznij od administratorów i wymuś na nich przez Conditional Access wbudowaną siłę uwierzytelniania (authentication strength) Phishing-resistant MFA. Dopuszcza ona wyłącznie Windows Hello for Business lub poświadczenie platformy, klucz bezpieczeństwa FIDO2 albo uwierzytelnianie certyfikatem Entra (wieloskładnikowe). SMS i zatwierdzenia push przestają spełniać politykę dla tych kont na zasobach, które ona obejmuje, choć monit o hasło nadal się pojawia (zobacz Co może pójść nie tak).
Dlaczego admini idą pierwsi
Przegląd metod uwierzytelniania Microsoft wskazuje, że MFA oparte na SMS, jednorazowych kodach e-mail lub aplikacjach uwierzytelniających jest podatne na zdalny phishing, w którym atakujący wykradają hasła lub kody jednorazowe bez dotykania urządzenia użytkownika. Microsoft zaleca zamiast tego Windows Hello for Business, passkeys (FIDO2), klucze bezpieczeństwa FIDO2 lub uwierzytelnianie certyfikatem. Na koncie administratora skradziony kod kosztuje najwięcej, a mały zespół ma do przeniesienia zaledwie kilka takich kont.
Uważaj na środkową z wbudowanych opcji. Zgodnie z dokumentacją authentication strengths siła Passwordless MFA obejmuje logowanie przez telefon w Microsoft Authenticator. Siła Phishing-resistant go nie obejmuje.
Przygotuj tenant
Passkeys (FIDO2) są dostępne we wszystkich edycjach Entra ID bez dodatkowej licencji. Conditional Access wymaga Entra ID P1.
Ustawienia znajdziesz w Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2). Potrzebujesz co najmniej roli Authentication Policy Administrator. Liczą się trzy szczegóły:
- Przejście na profile passkey jest jednokierunkowe. Nie można się potem wycofać, a dotychczasowe ustawienia globalne trafiają do profilu Default. Obsługiwane są maksymalnie trzy profile, wliczając Default.
- Opcja Allow self-service set up musi mieć wartość Yes, inaczej użytkownicy nie zarejestrują passkey przez Security info. To ustawienie globalne, a nie per profil.
- Rejestracja wymaga MFA zakończonego w ciągu ostatnich pięciu minut.
Dla adminów przykład z dokumentacji to profil z typem passkey Device-bound i opcją Enforce attestation ustawioną na Yes. Device-bound oznacza, że klucz prywatny nigdy nie opuszcza jednego fizycznego urządzenia, takiego jak klucz bezpieczeństwa czy Microsoft Authenticator. Synchronizowane passkeys nie obsługują attestation, a Microsoft każe traktować je jako odporne na phishing, ale o poziomie bezpieczeństwa innych authenticatorów bez attestation. Tekst NIST wymaga na AAL3, czyli najwyższym poziomie, authenticatora odpornego na phishing z kluczem, którego nie da się wyeksportować, więc klucze device-bound są najbliższym dopasowaniem wśród opcji Entra.
Wymuś politykę przez authentication strength
Utwórz politykę Conditional Access, wskaż jako cel role administratorskie lub grupę, a w grant controls wybierz Require authentication strength. Zaznacz Phishing-resistant MFA. Nie można tego łączyć z Require multifactor authentication w tej samej polityce, bo wbudowana siła MFA jest równoważna tej kontroli.
Wbudowanych sił nie da się edytować, a Microsoft aktualizuje je, gdy pojawiają się nowe metody. Jeśli potrzebujesz stałego zestawu dozwolonych metod, utwórz własną siłę (custom strength).
Nie musisz wyłączać SMS dla wszystkich. Authentication strength działa nad polityką Authentication methods i zawęża ją dla danego scenariusza. Pracownicy mogą zachować hasło i zatwierdzanie push przy zwykłych zasobach, a adminów obowiązuje ostrzejsza polityka.
Co może pójść nie tak
Admin nadal najpierw wpisuje hasło. Conditional Access jest oceniany po uwierzytelnieniu początkowym, więc siła wymusza metodę odporną na phishing dopiero wtedy.
Jeśli użytkownik loguje się hasłem jako metodą podstawową, a siła wymaga Windows Hello for Business, nie zobaczy monitu o nie. Musi zrestartować sesję, wybrać Sign-in options i wskazać wymaganą metodę. Wpisz to do instrukcji dla adminów.
Dwie kontrole działają w różnych momentach. Enforce attestation obowiązuje tylko przy rejestracji, więc passkey zarejestrowany bez attestation nie jest blokowany przy logowaniu po włączeniu tej opcji. Zarejestruj klucze adminów ponownie. Ograniczenia kluczy według AAGUID dotyczą zarówno rejestracji, jak i logowania, więc usunięcie wcześniej dozwolonego AAGUID blokuje wszystkich, którzy zarejestrowali ten model.
Nakładanie się profili jest permisywne i wpływa na rejestrację oraz logowanie na poziomie polityki passkey. Gdy użytkownik podlega kilku profilom, passkey jest dozwolony, jeśli w pełni spełnia co najmniej jeden z nich, w dowolnej kolejności. Admin, który należy też do grupy "wszystkie synchronizowane lub device-bound", może więc zarejestrować i używać synchronizowanego passkey, o ile patrzeć tylko na politykę passkey. Źródła nie mówią, czy siła w Conditional Access go zaakceptuje, więc przetestuj ten przypadek.
Po przejściu na profile sprawdź profil Default w sekcji Enable and target. Jeśli jego celem jest All users i dopuszcza on synchronizowane passkeys, zmień cel na grupy, które nie zawierają Twoich adminów. Nie wykluczaj adminów w polityce Passkey (FIDO2): wykluczona grupa ma całkowicie zablokowaną rejestrację i logowanie FIDO2, a to nadpisuje każde włączenie.
Częstotliwość logowania (sign-in frequency) i siła uwierzytelniania mogą zostać spełnione w różnych momentach. Przy sile opartej na passkey i sign-in frequency równej 1 godzinie logowanie passkey sprzed 24 godzin plus dzisiejsze odblokowanie urządzenia przez Windows Hello spełniają oba warunki. Jeśli dla adminów polegasz na krótkich interwałach, przetestuj ten przypadek.
Temporary Access Pass występuje w sile MFA, ale nie w odpornej na phishing. Nasz własny wniosek, którego źródła nie potwierdzają: proces odzyskiwania dostępu lub bootstrapu oparty na Temporary Access Pass nie spełni tej polityki, więc potrzebuje wykluczenia lub osobnej polityki. Zdecyduj o tym przed wymuszeniem, a nie w trakcie incydentu.
Od czego zacząć
- Wypisz wszystkie konta z rolą administratora i wybierz dwa lub trzy do grupy pilotażowej.
- Przejdź na profile passkey, sprawdź cel profilu Default, utwórz profil dla adminów z typem Device-bound i Enforce attestation ustawionym na Yes i skieruj go tylko na grupę pilotażową.
- Zarejestruj co najmniej dwa authenticatory na każdego admina z pilota, na przykład klucz bezpieczeństwa i Windows Hello, i potwierdź, że logowanie działa z każdym z nich.
- Utwórz politykę Conditional Access z siłą Phishing-resistant MFA dla grupy pilotażowej. Jako ogólną praktykę (strony Microsoft użyte tutaj nie omawiają kont break-glass) wyklucz konta awaryjne i daj każdemu z nich własny klucz FIDO2.
- Rozszerz politykę na wszystkich adminów. Usuń passkeys zarejestrowane, zanim wymuszono attestation, dopiero gdy każdy admin zarejestruje ponownie klucz z attestation, żeby nikt nie został zablokowany.
- Zleć przetestowanie wyniku. Nasz zespół konsultingowy może przejrzeć politykę, a test penetracyjny pokaże, czy jakaś ścieżka admina nadal akceptuje słabszą metodę.
