Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Podczas wdrażania i operacjonalizacji uwierzytelniania bez hasła odpornego na wyłudzanie informacji w środowisku zalecamy podejście oparte na persona użytkownika. Różne odporne na phishing metody bezhasłowe są bardziej skuteczne niż inne dla niektórych typów użytkowników. Ten przewodnik wdrażania ułatwia sprawdzenie, jakie typy metod i planów wdrażania mają sens dla osób użytkowników w danym środowisku. Podejście do odpornego na phishing wdrażania bezhasłowego zwykle składa się z 6 kroków, które zazwyczaj mają ustaloną kolejność, ale nie muszą być w 100% zakończone przed przejściem do innych kroków.
Określanie osób użytkownika
Określ osoby użytkowników odpowiednie dla twojej organizacji. Ten krok ma kluczowe znaczenie dla projektu, ponieważ różne osoby mają różne potrzeby. Firma Microsoft zaleca rozważenie i ocenę co najmniej 4 ogólnych osób użytkowników w organizacji.
Osoba użytkownika | opis |
---|---|
Pracownicy przetwarzający informacje | |
Pracownicy linii frontu | |
Pracownicy IT/DevOps | |
Pracownicy z wysokimi regulacjami |
Firma Microsoft zaleca szeroko wdrażać uwierzytelnianie bez hasła odporne na wyłudzanie informacji w całej organizacji. Tradycyjnie pracownicy przetwarzający informacje są najłatwiejszą osobą użytkownika, od której należy zacząć. Nie opóźniaj wdrażania bezpiecznych poświadczeń dla pracowników przetwarzających informacje podczas rozwiązywania problemów, które mają wpływ na informatyków. Weź pod uwagę podejście "nie pozwól, aby idealny był wrogiem dobrego" i jak najwięcej wdrażaj bezpieczne poświadczenia. W miarę jak coraz więcej użytkowników loguje się, używając poświadczeń odpornych na wyłudzanie informacji i nie wymagających hasła, zmniejszasz podatność swojego środowiska na ataki.
Microsoft zaleca zdefiniowanie person, a następnie umieszczenie każdej persony w grupie Microsoft Entra ID specjalnie dla danego persony. Te grupy są używane w kolejnych krokach w celu wdrożenia poświadczeń dla różnych typów użytkowników, a kiedy zaczniesz wymuszać stosowanie poświadczeń bez hasła odpornych na wyłudzanie informacji.
Planowanie gotowości urządzenia
Urządzenia są istotnym aspektem każdego pomyślnego wdrożenia bezhasłowego odpornego na wyłudzanie informacji, ponieważ jednym z celów odpornych na wyłudzanie poświadczeń bezhasłowych jest ochrona poświadczeń za pomocą sprzętu nowoczesnych urządzeń. Najpierw zapoznaj się z obsługą standardu FIDO2 dla identyfikatora Entra firmy Microsoft.
Upewnij się, że twoje urządzenia są przygotowane na bezhasłowe zabezpieczenia odporne na phishing, aktualizując do najnowszych obsługiwanych wersji każdego systemu operacyjnego. Firma Microsoft zaleca, aby na urządzeniach były uruchomione co najmniej następujące wersje:
- Windows 10 22H2 (dla Windows Hello dla firm)
- Windows 11 22H2 (aby uzyskać najlepsze doświadczenie użytkownika podczas korzystania z kluczy dostępu)
- MacOS 13 Ventura
- iOS 17
- Android 14
Te wersje zapewniają najlepszą obsługę natywnie zintegrowanych funkcji, takich jak hasła, Windows Hello dla firm i poświadczenia platformy systemu macOS. Starsze systemy operacyjne mogą wymagać zewnętrznych wystawców uwierzytelnienia, takich jak klucze zabezpieczeń FIDO2, do obsługi uwierzytelniania bez hasła odpornego na wyłudzanie informacji.
Rejestrowanie użytkowników na potrzeby poświadczeń odpornych na wyłudzanie informacji
Rejestracja poświadczeń i konfiguracja początkowa są pierwszymi głównymi działaniami ukierunkowanymi na użytkownika końcowego w projekcie wdrożenia bezhasłowego odpornego na wyłudzanie informacji. W tej sekcji omówiono wdrażanie poświadczeń przenośnych i lokalnych .
Poświadczenia | opis | Świadczenia |
---|---|---|
Przenośne | Może być używany na różnych urządzeniach. Możesz użyć przenośnych poświadczeń, aby zalogować się do innego urządzenia lub zarejestrować poświadczenia na innych urządzeniach. | Najważniejszym typem poświadczeń do zarejestrowania się dla większości użytkowników, ponieważ mogą być używane na różnych urządzeniach i zapewniają uwierzytelnianie odporne na wyłudzanie informacji w wielu scenariuszach. |
Lokalny | Możesz użyć poświadczeń lokalnych do uwierzytelniania na urządzeniu bez konieczności polegania na sprzęcie zewnętrznym, takim jak używanie Windows Hello dla firm rozpoznawania biometrycznego w celu zalogowania się do aplikacji w przeglądarce Microsoft Edge na tym samym komputerze | Mają one dwie główne korzyści w porównaniu do przenośnych poświadczeń: |
- W przypadku nowych użytkowników proces rejestracji i wdrażania prowadzi użytkownika bez istniejących poświadczeń przedsiębiorstwa i weryfikuje jego tożsamość. Uruchamia je w pierwszym przenośnym poświadczeniu i używa tego przenośnego poświadczenia do rozruchu innych poświadczeń lokalnych na każdym urządzeniu obliczeniowym. Po rejestracji administrator może wymusić uwierzytelnianie odporne na wyłudzanie informacji dla użytkowników w usłudze Microsoft Entra ID.
- W przypadku istniejących użytkowników ta faza umożliwia im rejestrowanie się do systemu odpornego na phishing i działającego bezhasłowo na ich istniejących urządzeniach bezpośrednio lub za pomocą istniejących poświadczeń uwierzytelniania wieloskładnikowego w celu utworzenia nowych, odpornych na phishing poświadczeń bezhasłowych. Celem końcowym jest to samo co nowi użytkownicy — większość użytkowników powinna mieć co najmniej jedno przenośne poświadczenia, a następnie poświadczenia lokalne na każdym urządzeniu obliczeniowym. Jeśli jesteś administratorem, który wdraża odporną na phishing technologię uwierzytelniania bezhasłowego dla istniejących użytkowników, możesz przejść bezpośrednio do sekcji Krok 2: Bootstrapping przenośnego poświadczenia (Wdrażanie przenośnego poświadczenia).
Przed rozpoczęciem firma Microsoft zaleca włączenie klucza dostępu i innych poświadczeń dla użytkowników przedsiębiorstwa w dzierżawie. Jeśli użytkownicy są zmotywowani do samodzielnego rejestrowania się w celu uzyskania silnych poświadczeń, korzystne jest zezwolenie na to. Co najmniej należy włączyć zasady Passkey (FIDO2), aby użytkownicy mogli rejestrować się w celu uzyskania kluczy dostępu i kluczy zabezpieczeń, jeśli wolą.
Ta sekcja koncentruje się na fazach 1–3:
Użytkownicy powinni mieć co najmniej dwie zarejestrowane metody uwierzytelniania. W przypadku zarejestrowania innej metody użytkownik ma dostępną metodę tworzenia kopii zapasowej, jeśli coś się stanie z ich podstawową metodą, na przykład w przypadku utraty lub kradzieży urządzenia. Dobrym rozwiązaniem jest na przykład zarejestrowanie kluczy dostępu zarówno na telefonie, jak i lokalnie na stacji roboczej w systemie Windows Hello for Business.
Uwaga
Zawsze zaleca się, aby użytkownicy mieli co najmniej dwie zarejestrowane metody uwierzytelniania. Dzięki temu użytkownik ma dostępną metodę tworzenia kopii zapasowej, jeśli coś się stanie z ich podstawową metodą, taką jak w przypadku utraty lub kradzieży urządzenia. Dobrym rozwiązaniem jest na przykład to, że użytkownicy mają zarejestrowane klucz dostępu zarówno na telefonie, jak i lokalnie na stacji roboczej w Windows Hello dla firm.
Uwaga
Te wskazówki są dostosowane do obecnie istniejącej obsługi kluczy dostępu w usłudze Microsoft Entra ID, która obejmuje klucze dostępu związane z urządzeniem w aplikacji Microsoft Authenticator oraz klucze dostępu związane z fizycznymi kluczami zabezpieczeń. Microsoft Entra ID planuje dodać obsługę zsynchronizowanych kluczy dostępu. Aby uzyskać więcej informacji, zobacz Publiczna wersja zapoznawcza: rozszerzanie obsługi klucza dostępu w usłudze Microsoft Entra ID. Ten przewodnik zostanie zaktualizowany w celu uwzględnienia zsynchronizowanych wskazówek dotyczących klucza dostępu po udostępnieniu. Na przykład wiele organizacji może korzystać z synchronizacji z fazą 3 na powyższym diagramie zamiast uruchamiania całkowicie nowych poświadczeń.
Krok 1 dołączania: Weryfikacja tożsamości
Dla użytkowników zdalnych, którzy nie udowodnili swojej tożsamości, proces onboardingu w przedsiębiorstwie jest istotnym wyzwaniem. Bez odpowiedniej weryfikacji tożsamości organizacja nie może być całkowicie pewna, że dołącza osobę, którą zamierza. Zweryfikowany identyfikator Microsoft Entra może zapewnić weryfikację tożsamości o wysokiej pewności. Organizacje mogą współpracować z partnerem weryfikacji tożsamości (IDV), aby zweryfikować tożsamości nowych zdalnych użytkowników w procesie wprowadzania. Po przetworzeniu dowodu tożsamości wydanego przez rząd, IDV może dostarczyć zweryfikowany dowód tożsamości, który potwierdza tożsamość użytkownika. Nowy użytkownik przedstawia ten zweryfikowany identyfikator tożsamości organizacji zatrudniającej, aby zbudować zaufanie i potwierdzić, że organizacja zatrudnia odpowiednią osobę. Organizacje mogą dodawać funkcję sprawdzania twarzy przy użyciu Zweryfikowanego identyfikatora tożsamości Microsoft Entra, co dodaje do weryfikacji warstwę dopasowania twarzy, zapewniając, że zaufany użytkownik prezentuje w tej chwili zweryfikowany identyfikator tożsamości.
Po zweryfikowaniu tożsamości za pośrednictwem procesu sprawdzania nowi pracownicy otrzymują dostęp tymczasowy (TAP), których mogą użyć do uruchomienia pierwszego przenośnego poświadczenia.
Zapoznaj się z następującymi przewodnikami, aby włączyć onboarding Zweryfikowanego identyfikatora Microsoft Entra i wydawanie TAP:
- Dołączanie nowych pracowników zdalnych przy użyciu weryfikacji identyfikatora
- Używanie Face Check z Zweryfikowanym identyfikatorem Microsoft Entra w celu odblokowania weryfikacji o wysokim poziomie zaufania na dużą skalę
- Włącz zasady dostępu tymczasowego
Zapoznaj się z poniższymi linkami, aby uzyskać szczegóły na temat licencjonowania Microsoft Entra Verified ID.
- Weryfikacja twarzy w połączeniu z cennikiem dla usługi Microsoft Entra Verified ID
- Plany i ceny Microsoft Entra
Niektóre organizacje mogą wybrać inne metody niż Zweryfikowany identyfikator Microsoft Entra, aby dołączyć użytkowników i wystawić im ich pierwsze poświadczenia. Firma Microsoft zaleca, aby te organizacje nadal korzystały z funkcji TAPs lub innego sposobu, który umożliwia użytkownikowi dołączanie bez hasła. Można na przykład aprowizować klucze zabezpieczeń FIDO2 przy użyciu interfejsu API programu Microsoft Graph.
Etap 2 wdrożenia: Skonfiguruj przenośne poświadczenie
Aby wdrożyć istniejących użytkowników do korzystania z poświadczeń odpornych na phishing i nie wymagających haseł, najpierw określ, czy użytkownicy są już zarejestrowani w tradycyjnej usłudze MFA. Użytkownicy z tradycyjnymi zarejestrowanymi metodami uwierzytelniania wieloskładnikowego mogą być objęci zasadami rejestracji bez hasła odpornymi na wyłudzanie informacji. Mogą użyć tradycyjnego uwierzytelniania wieloskładnikowego do zarejestrowania się w celu uzyskania pierwszego przenośnego poświadczenia odpornego na phishing, a następnie zarejestrować się w celu uzyskania poświadczeń lokalnych zgodnie z potrzebami.
W przypadku nowych użytkowników lub użytkowników bez uwierzytelniania wieloskładnikowego przeprowadź proces wydania użytkownikom Tymczasowego Dostępu (TAP). Możesz wydać TAP w taki sam sposób, jak nadać nowym użytkownikom ich pierwsze poświadczenia lub przy użyciu integracji Zweryfikowanego identyfikatora Microsoft Entra. Gdy użytkownicy mają już TAP, są gotowi do utworzenia swojego pierwszego poświadczenia odpornego na phishing.
Ważne jest, aby pierwsze poświadczenie użytkownika bez hasła było przenośnym poświadczeniem, które może służyć do uwierzytelniania na innych urządzeniach obliczeniowych. Na przykład można użyć kluczy dostępu do uwierzytelniania lokalnego na telefonie z systemem iOS, ale mogą być również używane do uwierzytelniania na komputerze z systemem Windows przy użyciu przepływu uwierzytelniania między urządzeniami. Ta funkcja między urządzeniami umożliwia używanie przenośnego klucza dostępu do uruchamiania Windows Hello dla firm na komputerze z systemem Windows.
Ważne jest również, aby każde urządzenie, na którym użytkownik regularnie pracuje, miało lokalnie dostępne poświadczenie, aby zapewnić najbardziej płynne doświadczenie użytkownika. Poświadczenia dostępne lokalnie skracają czas potrzebny do uwierzytelnienia, ponieważ użytkownicy nie muszą używać wielu urządzeń i jest mniej kroków. Użycie funkcji TAP z kroku 1 w celu zarejestrowania przenośnego poświadczenia, które może uruchomić te inne poświadczenia, umożliwia użytkownikowi używanie poświadczeń odpornych na wyłudzanie informacji natywnie na wielu urządzeniach, które mogą posiadać.
W poniższej tabeli wymieniono zalecenia dotyczące różnych osób:
Persona użytkownika | Zalecane przenośne poświadczenia | Alternatywne przenośne poświadczenia |
---|---|---|
Pracownicy wiedzy | Klucz dostępu (aplikacja Authenticator) | Klucz zabezpieczeń, karta inteligentna |
Pracownik pierwszego kontaktu | Klucz zabezpieczeń | Klucz dostępu (aplikacja Authenticator), karta inteligentna |
Pracownik it/DevOps | Klucz dostępu (aplikacja Authenticator) | Klucz zabezpieczeń, karta inteligentna |
Wysoce regulowany pracownik | Certyfikat (karta inteligentna) | Klucz dostępu (aplikacja Authenticator), klucz zabezpieczeń |
Skorzystaj z poniższych wskazówek, aby włączyć zalecane i alternatywne przenośne poświadczenia dla odpowiednich osób użytkowników w organizacji:
Metoda | Wskazówki |
---|---|
Klucz dostępu | |
Klucze zabezpieczeń | |
Uwierzytelnianie oparte na kartach inteligentnych/certyfikatach (CBA) |
Krok 3 dołączania: konfigurowanie poświadczeń lokalnych na urządzeniach obliczeniowych
Gdy użytkownicy zarejestrowali przenośne poświadczenia, są gotowi do inicjowania innych poświadczeń na każdym urządzeniu obliczeniowym, z którego regularnie korzystają w relacji 1:1, co wspiera ich codzienne doświadczenie użytkownika. Ten typ poświadczeń jest typowy dla pracowników przetwarzających informacje i informatyków, ale nie dla pracowników pierwszej linii, którzy udostępniają urządzenia. Użytkownicy, którzy udostępniają tylko urządzenia, powinni używać tylko przenośnych poświadczeń.
Twoja organizacja musi określić, który typ poświadczeń jest preferowany dla każdej osoby użytkownika na tym etapie. Firma Microsoft zaleca:
Osoba użytkownika | Zalecane lokalne poświadczenie — Windows | Zalecane poświadczenie lokalne: macOS | Zalecane poświadczenia lokalne — iOS | Zalecane lokalne poświadczenie — Android | Zalecane poświadczenia lokalne — Linux |
---|---|---|---|---|---|
Pracownik wiedzy | Windows Hello for Business | Klucz bezpiecznej enklawy jednokrotnego logowania (SSO) platformy | Klucz dostępu (aplikacja Authenticator) | Klucz dostępu (aplikacja Authenticator) | Nie dotyczy (zamiast tego użyj przenośnych poświadczeń) |
Pracownik pierwszego kontaktu | Nie dotyczy (zamiast tego użyj przenośnych poświadczeń) | Nie dotyczy (zamiast tego użyj przenośnych poświadczeń) | Nie dotyczy (zamiast tego użyj przenośnych poświadczeń) | Nie dotyczy (zamiast tego użyj przenośnych poświadczeń) | Nie dotyczy (zamiast tego użyj przenośnych poświadczeń) |
Pracownik it/DevOps | Windows Hello for Business | Klucz bezpiecznej enklawy platformy jednokrotnego logowania | Klucz dostępu (aplikacja Authenticator) | Klucz dostępu (aplikacja Authenticator) | Nie dotyczy (zamiast tego użyj przenośnych poświadczeń) |
Wysoce regulowany pracownik | Windows Hello dla firm lub uwierzytelnianie oparte na certyfikatach | Klucz bezpiecznej enklawy logowania jednokrotnego platformy lub CBA | Klucz dostępu (aplikacja Authenticator) lub CBA | Klucz dostępu (aplikacja Authenticator) lub CBA | Nie dotyczy (zamiast tego użyj karty inteligentnej) |
Skorzystaj z poniższych wskazówek, aby włączyć zalecane poświadczenia lokalne w środowisku dla odpowiednich użytkowników w Twojej organizacji.
Metoda | Wskazówki |
---|---|
Windows Hello for Business | |
Klucz Enklawy Zabezpieczonej Logowania Jednokrotnego Platformy | |
Klucz dostępu |
Zagadnienia specyficzne dla danej osoby
Każda osoba ma własne wyzwania i zagadnienia, które często pojawiają się podczas wdrożeń bez hasła odpornych na wyłudzanie informacji. Podczas identyfikowania osób, które należy uwzględnić, należy uwzględnić te zagadnienia w planowaniu projektu wdrożenia. Poniższe linki zawierają szczegółowe wskazówki dla każdej osoby:
- Pracownicy przetwarzający informacje
- Pracownicy linii frontu
- Informatyka/pracownicy DevOps
- Pracownicy z wysokimi regulacjami
Napędzanie użycia poświadczeń odpornych na wyłudzanie informacji
W tym kroku opisano, jak ułatwić użytkownikom wdrażanie poświadczeń odpornych na wyłudzanie informacji. Należy przetestować strategię wdrażania, zaplanować wdrożenie i przekazać plan użytkownikom końcowym. Następnie możesz tworzyć raporty i monitorować postęp przed wymuszeniem poświadczeń odpornych na wyłudzanie informacji w całej organizacji.
Strategia wdrażania testowego
Firma Microsoft zaleca przetestowanie strategii wdrażania utworzonej w poprzednim kroku przy użyciu zestawu użytkowników testowych i pilotażowych. Ta faza powinna obejmować następujące kroki:
- Utwórz listę użytkowników testowych i wczesnych użytkowników. Ci użytkownicy powinni reprezentować różne osoby użytkowników, a nie tylko administratorów IT.
- Utwórz grupę Microsoft Entra ID i dodaj użytkowników testowych do grupy.
- Włącz polityki metod uwierzytelniania w Microsoft Entra ID i określ, które metody będą używane dla grupy testowej.
- Zmierz przebieg rejestracji dla użytkowników pilotażowych przy użyciu raportu Działania metod uwierzytelniania.
- Utwórz zasady dostępu warunkowego, aby wymusić użycie poświadczeń odpornych na wyłudzanie informacji, które nie wymagają hasła dla każdego typu systemu operacyjnego i skierować do grupy pilotażowej.
- Oceń sukces egzekwowania przy użyciu Azure Monitor i skoroszytów.
- Zbieraj opinie od użytkowników na temat sukcesu wdrożenia.
Planowanie strategii wdrażania
Firma Microsoft zaleca kierowanie użyciem w oparciu o osoby użytkowników, które są najbardziej gotowe do wdrożenia. Zazwyczaj oznacza to wdrożenie dla użytkowników w tej kolejności, ale może to ulec zmianie w zależności od organizacji:
- Pracownicy przetwarzający informacje
- Pracownicy linii frontu
- Informatyka/pracownicy DevOps
- Pracownicy z wysokimi regulacjami
Poniższe sekcje służą do tworzenia komunikacji użytkowników końcowych dla każdej grupy osób, zakresu i wdrażania funkcji rejestracji kluczy dostępu oraz raportowania i monitorowania użytkowników w celu śledzenia postępu wdrażania.
Przygotowanie do uruchomienia z Phishing-Resistant zeszytem roboczym bez użycia hasła (wersja przedpremierowa)
Organizacje mogą opcjonalnie wyeksportować dzienniki logowania identyfikatora Entra firmy Microsoft do usługi Azure Monitor na potrzeby długoterminowego przechowywania, wyszukiwania zagrożeń i innych celów. Firma Microsoft opublikowała skoroszyt , który organizacje z dziennikami w usłudze Azure Monitor mogą używać do pomocy w różnych fazach bezhasłowego wdrożenia odpornego na phishing. Dostęp do skoroszytu bez hasła Phishing-Resistant można uzyskać tutaj: aka.ms/PasswordlessWorkbook. Wybierz skoroszyt zatytułowany Phishing-Resistant Wdrożenie bez hasła (wersja zapoznawcza):
Skoroszyt zawiera dwie główne sekcje:
- Faza gotowości rejestracji
- Faza gotowości wymuszania
Faza gotowości rejestracji
Użyj zakładki Faza gotowości rejestracji, aby przeanalizować dzienniki logowania w dzierżawie, określając, którzy użytkownicy są gotowi do rejestracji, a którzy mogą napotkać blokady. Na przykład na karcie Faza gotowości rejestracji możesz wybrać system iOS jako platformę systemu operacyjnego, a następnie klucz dostępu aplikacji Authenticator jako typ poświadczeń, dla których chcesz ocenić gotowość. Następnie możesz kliknąć wizualizacje skoroszytu, aby odfiltrować je do użytkowników, którzy mają problemy z rejestracją i wyeksportować listę:
Karta fazy gotowości do rejestracji w skoroszycie może pomóc w ocenie gotowości dla następujących systemów operacyjnych i poświadczeń:
- Windows
- Windows Hello for Business
- Klucz zabezpieczeń FIDO2
- Klucz dostępu aplikacji Authenticator
- Certificate-Based Uwierzytelnianie / Karta inteligentna
- macOS
- Klucz logowania jednokrotnego do bezpiecznej enklawy platformy
- Klucz zabezpieczeń FIDO2
- Klucz dostępu aplikacji Authenticator
- Certificate-Based Uwierzytelnianie / karta inteligentna
- Ios
- Klucz zabezpieczeń FIDO2
- Klucz dostępu aplikacji Authenticator
- Certificate-Based Uwierzytelnianie / Karta inteligentna
- Android
- Klucz zabezpieczeń FIDO2
- Klucz dostępu aplikacji Authenticator
- Uwierzytelnianie Certificate-Based / Karta inteligentna
Użyj każdej wyeksportowanej listy, aby sklasyfikować użytkowników, którzy mogą mieć problemy z rejestracją. Odpowiedzi na problemy z rejestracją powinny obejmować pomoc użytkownikom w uaktualnianiu wersji systemu operacyjnego urządzenia, zastępowaniu starzejących się urządzeń i wybieraniu alternatywnych poświadczeń, w przypadku których preferowana opcja nie jest opłacalna. Na przykład Organizacja może zdecydować się na udostępnienie fizycznych kluczy zabezpieczeń FIDO2 użytkownikom systemu Android 13, którzy nie mogą używać kluczy dostępu w aplikacji Microsoft Authenticator.
Podobnie użyj raportu gotowości do rejestracji, aby ułatwić tworzenie list użytkowników gotowych do rozpoczęcia komunikacji i kampanii związanych z rejestracją, zgodnie z Twoją ogólną strategią wdrażania .
Faza gotowości wymuszania
Pierwszym krokiem fazy gotowości wymuszania jest utworzenie polityki dostępu warunkowego w trybie Report-Only. Ta zasada wypełni dzienniki logowania danymi dotyczącymi tego, czy dostęp zostałby zablokowany, gdyby użytkownicy/urządzenia były objęte zakresem wymuszania odporności na wyłudzanie informacji. Utwórz nowe zasady dostępu warunkowego dla dzierżawcy przy użyciu następujących ustawień:
Ustawienie | Wartość |
---|---|
Przypisanie użytkownika/grupy | Wszyscy użytkownicy z wyjątkiem kont awaryjnego dostępu |
Zadanie aplikacji | Wszystkie zasoby |
Udzielanie kontrolek | Wymagaj siły uwierzytelniania — uwierzytelnianie wieloskładnikowe odporne na wyłudzanie informacji |
Włącz politykę | Tylko raportowanie |
Utwórz te zasady tak szybko, jak to możliwe w ramach wdrożenia, najlepiej przed rozpoczęciem kampanii rejestracji. To zapewni, że masz dobry historyczny zbiór danych, którzy użytkownicy i logowania byłyby zablokowane przez politykę, gdyby została wymuszona.
Następnie użyj skoroszytu, aby przeanalizować, gdzie pary użytkowników/urządzeń są gotowe do wymuszania. Pobierz listy użytkowników, którzy są gotowi do wdrożenia działań egzekucyjnych i dodaj je do grup utworzonych zgodnie z politykami egzekucyjnymi . Zacznij od wybrania zasad dostępu warunkowego tylko do odczytu w filtrze zasad:
Raport dostarczy listę użytkowników, którzy byliby w stanie pomyślnie spełnić wymóg bezhasłowy odporny na wyłudzenia na każdej platformie urządzeń. Pobierz każdą listę i umieść odpowiednich użytkowników w grupie egzekwowania, która jest zgodna z platformą urządzenia.
Powtórz ten proces w czasie, dopóki nie osiągniesz punktu, w którym każda grupa nadzoru zawiera większość lub wszystkich użytkowników. W końcu powinno być możliwe włączenie polityki tylko do raportowania, aby zapewnić egzekwowanie dla wszystkich użytkowników i platform urządzeń w środowisku dzierżawy. Po osiągnięciu tego stanu ukończenia można usunąć poszczególne zasady wymuszania dla każdego systemu operacyjnego urządzenia, zmniejszając liczbę wymaganych zasad dostępu warunkowego.
Analiza użytkowników, którzy nie są gotowi na wdrożenie
Użyj karty Dalsza analiza danych, aby dowiedzieć się, dlaczego niektórzy użytkownicy nie są przygotowani do wdrażania na różnych platformach. Wybierz pole Zasady Niespełnione, aby przefiltrować dane do logowań użytkowników, które zostałyby zablokowane przez zasady dostępu warunkowego w trybie raportu.
Użyj danych dostarczonych przez ten raport, aby określić, którzy użytkownicy zostaliby zablokowani, których systemów operacyjnych urządzeń używali, jakiego typu aplikacje klienckie używali i jakich zasobów próbowali uzyskać dostęp. Te dane powinny ułatwić skierowanie tych użytkowników do różnych akcji korygowania lub rejestracji, dzięki czemu można je skutecznie przenieść do zakresu wymuszania.
Planowanie komunikacji użytkowników końcowych
Firma Microsoft udostępnia szablony komunikacji dla użytkowników końcowych. Materiał wdrożeniowy z zakresu uwierzytelniania zawiera dostosowywalne szablony wiadomości e-mail, które mają na celu informowanie użytkowników o wdrażaniu uwierzytelniania bezhasłowego odpornego na phishing. Użyj następujących szablonów, aby komunikować się z użytkownikami, aby zrozumieć wdrożenie bez hasła odporne na wyłudzanie informacji:
- klucze dostępu dla pomocy technicznej
- Klucze dostępu wkrótce
- Zarejestruj się, aby uzyskać klucz dostępu aplikacji uwierzytelniającej
- Przypomnienie o rejestracji klucza dostępu w aplikacji Authenticator
Komunikacja powinna być powtarzana wiele razy, aby ułatwić przechwytywanie jak największej liczby użytkowników. Na przykład Twoja organizacja może zdecydować się na komunikowanie różnych faz i osi czasu, korzystając z takiego wzorca:
- Za 60 dni do egzekwowania: przekazuj wartość metod uwierzytelniania odpornych na wyłudzanie informacji i zachęcaj użytkowników do aktywnego zapisywania się.
- 45 dni od wymuszania: powtarzanie komunikatu
- 30 dni do wejścia w życie: komunikat, że w ciągu 30 dni rozpocznie się wprowadzenie mechanizmu odpornego na wyłudzanie informacji, zachęcić użytkowników do aktywnej rejestracji.
- 15 dni od wymuszania: powtórz komunikat, poinformuj ich o tym, jak skontaktować się z pomocą techniczną
- 7 dni od wymuszania: powtarzanie komunikatu, informowanie o tym, jak skontaktować się z pomocą techniczną
- 1 dzień od wymuszania: poinformuj ich o wymuszaniu nastąpi w ciągu 24 godzin, poinformuj ich o tym, jak skontaktować się z pomocą techniczną
Firma Microsoft zaleca komunikację z użytkownikami za pośrednictwem innych kanałów poza pocztą e-mail. Inne opcje mogą obejmować wiadomości w Microsoft Teams, plakaty w pokoju wypoczynkowym oraz programy ambasadorskie, w których wybrani pracownicy są przeszkoleni, aby promować program wśród swoich rówieśników.
Raportowanie i monitorowanie
Użyj wcześniej omówionego Phishing-Resistant skoroszytu bez hasła, aby ułatwić monitorowanie i raportowanie wdrożenia. Ponadto użyj raportów omówionych poniżej lub polegaj na nich, jeśli nie możesz użyć skoroszytu Phishing-Resistant Passwordless.
Raporty Microsoft Entra ID (takie jak Aktywność metod uwierzytelniania i Szczegóły zdarzenia logowania dla uwierzytelniania wieloskładnikowego Microsoft Entra) zapewniają szczegółowe informacje techniczne i biznesowe, które mogą pomóc w mierzeniu i zwiększaniu wdrażania.
Na pulpicie nawigacyjnym metod uwierzytelniania możesz wyświetlać rejestrację i użycie.
- Rejestracja pokazuje liczbę użytkowników zdolnych do uwierzytelniania bez hasła odpornego na wyłudzanie informacji oraz inne metody uwierzytelniania. Widoczne są wykresy pokazujące, które metody uwierzytelniania zarejestrowali użytkownicy, oraz ostatnią rejestrację dla każdej metody.
- Użycie pokazuje, które metody uwierzytelniania zostały użyte do logowania.
Właściciele aplikacji biznesowych i technicznych powinni posiadać i otrzymywać raporty na podstawie wymagań organizacji.
- Śledzenie wdrażania poświadczeń bez hasła odpornych na wyłudzanie informacji za pomocą raportów działań rejestracji metod uwierzytelniania.
- Śledź przyjęcie przez użytkowników mechanizmów uwierzytelniania bezhasłowego odpornych na phishing przy użyciu raportów aktywności związanych z metodami uwierzytelniania i dzienników logowania.
- Raport aktywności logowania umożliwia śledzenie metod uwierzytelniania używanych do logowania się do różnych aplikacji. Wybierz wiersz użytkownika; wybierz opcję Szczegóły uwierzytelniania, aby wyświetlić metodę uwierzytelniania i odpowiednią aktywność logowania.
Identyfikator entra firmy Microsoft dodaje wpisy do dzienników inspekcji, gdy wystąpią następujące warunki:
- Administrator zmienia metody uwierzytelniania.
- Użytkownik wprowadza dowolne zmiany w swoich poświadczeniach wewnątrz Microsoft Entra ID.
Identyfikator entra firmy Microsoft przechowuje większość danych inspekcji przez 30 dni. Zalecamy dłuższe przechowywanie na potrzeby inspekcji, analizy trendów i innych potrzeb biznesowych.
Uzyskiwanie dostępu do danych inspekcji w centrum administracyjnym Microsoft Entra lub interfejsie API i pobieranie ich do systemów analitycznych. Jeśli potrzebujesz dłuższego przechowywania, eksportuj i korzystaj z dzienników w narzędziu Do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), takim jak Microsoft Sentinel, Splunk lub Sumo Logic.
Monitorowanie liczby zgłoszeń do pomocy technicznej
Dział pomocy technicznej IT może dostarczyć nieocenione informacje o postępach wdrożenia, dlatego firma Microsoft zaleca śledzenie liczby zgłoszeń do działu pomocy technicznej przy wdrażaniu rozwiązania bez hasła chroniącego przed phishingiem.
W miarę zwiększania liczby zgłoszeń do help desk, należy spowolnić tempo wdrożeń, komunikacji z użytkownikami i działań egzekwowania. W miarę spadku ilości biletów można ponownie zwiększyć intensywność tych działań. Użycie tego podejścia wymaga zachowania elastyczności w planie wdrażania.
Możesz na przykład wykonać wdrożenia, a następnie wymuszenia w falach, które mają zakresy dat, a nie określone daty:
- 1-15 czerwca: Wdrażanie i kampanie rejestracji kohorty Wave 1
- 16-30 czerwca: Wdrożenie rejestracji i kampanie dla kohorty Wave 2
- 1-15 lipca: Wdrażanie rejestracji kohort Wave 3 oraz uruchomienie kampanii
- 16 lipca–31 lipca: Włączono wymuszanie kohorty Wave 1
- 1-15 sierpnia: Egzekwowanie kohorty II fali zostało włączone
- 16 sierpnia–31 sierpnia: Aktywowane egzekwowanie zasad dla grupy 3
Podczas realizacji tych różnych faz może być konieczne zwolnienie tempa w zależności od liczby otwartych zgłoszeń w help desku, a następnie wznowienie, gdy liczba zgłoszeń zmaleje. Aby wykonać tę strategię, firma Microsoft zaleca utworzenie grupy zabezpieczeń Microsoft Entra ID dla każdej fali i dodanie każdej grupy do zasad pojedynczo. Takie podejście pomaga uniknąć przeciążenie zespołów pomocy technicznej.
Wymuszanie metod odpornych na wyłudzanie informacji na potrzeby logowania
Ta sekcja koncentruje się na fazie 4.
Ostatnia faza wdrożenia bezhasłowego odpornego na phishing wymusza używanie poświadczeń odpornych na phishing. Podstawowym mechanizmem w tym celu w usłudze Microsoft Entra ID jest siła uwierzytelniania dostępu warunkowego. Firma Microsoft zaleca podejście do wdrażania dla każdej persony na podstawie metodologii pary użytkownik/urządzenie. Na przykład wdrożenie egzekwowania może być zgodne z tym wzorcem:
- Pracownicy przetwarzający informacje w systemach Windows i iOS
- Pracownicy przetwarzający informacje w systemach macOS i Android
- Specjaliści IT na iOS i Android
- FlWs w systemach iOS i Android
- FLWs w systemach Windows i macOS
- Profesjonaliści IT korzystający z Windows i macOS
Microsoft zaleca opracowanie raportu wszystkich Twoich par użytkownik-urządzenie, korzystając z danych logowania Twojego dzierżawcy. Możesz użyć narzędzi do wykonywania zapytań, takich jak Usługa Azure Monitor i skoroszyty. Spróbuj co najmniej zidentyfikować wszystkie pary użytkowników/urządzeń, które pasują do tych kategorii.
Użyj wcześniej omówionego Phishing-Resistant skoroszytu bez hasła, aby pomóc w fazie wymuszania, jeśli to możliwe.
Dla każdego użytkownika utwórz listę systemów operacyjnych, które regularnie używają do pracy. Zamapuj listę na gotowość do wymuszania logowania odpornego na wyłudzanie informacji dla tej pary użytkowników/urządzeń.
Typ systemu operacyjnego | Gotowe do wymuszania | Brak gotowości do egzekwowania |
---|---|---|
Windows | Ponad 10 | 8.1 i starsze wersje systemu Windows Server |
iOS | 17+ | 16 i starsze |
Android | 14+ | 13 i starsze |
macOS | 13+ (Ventura) | 12 i starsze |
Infrastruktura VDI | Zależyod 1 | Zależyod 1 |
Inne | Zależyod 1 | Zależyod 1 |
1Dla każdej pary użytkownik/urządzenie, w której wersja urządzenia nie jest natychmiast gotowa do wdrożenia, określ, jak rozwiązać konieczność wdrożenia mechanizmów odporności na wyłudzanie informacji. Rozważ następujące opcje dla starszych systemów operacyjnych, infrastruktury pulpitu wirtualnego (VDI) i innych systemów operacyjnych, takich jak Linux:
- Wymuszanie odporności na wyłudzanie informacji przy użyciu sprzętu zewnętrznego — klucze zabezpieczeń FIDO2
- Wymuszanie odporności na wyłudzanie informacji przy użyciu sprzętu zewnętrznego — karty inteligentne
- Wymuszanie odporności na wyłudzanie informacji przy użyciu zdalnych poświadczeń, takich jak klucze dostępu w przepływie uwierzytelniania między urządzeniami
- Wymuszanie odporności na phishing przy użyciu poświadczeń zdalnych w tunelach RDP (zwłaszcza dla VDI)
Kluczowym zadaniem jest mierzenie, przy pomocy danych, którzy użytkownicy i persony są gotowi do egzekwowania działań na określonych platformach. Rozpocznij egzekwowanie działań na parach użytkowników/urządzeń, które są gotowe do zabezpieczenia, aby "powstrzymać kryzys" i zmniejszyć liczbę uwierzytelnień podatnych na phishing w twoim środowisku.
Następnie przejdź do innych scenariuszy, w których pary użytkowników/urządzeń wymagają wysiłków związanych z gotowością. Pracuj nad listą par użytkowników/urządzeń, aż wymusisz stosowanie uwierzytelniania odpornego na phishing wszędzie.
Utwórz zestaw grup Microsoft Entra ID, aby stopniowo wdrażać wymuszanie. Ponownie użyj grup z poprzedniego kroku, jeśli użyto podejścia do wdrażania opartego na falach.
Zalecane egzekwowanie zasad dostępu warunkowego
Zastosuj do każdej grupy określoną zasadę dostępu warunkowego. Takie podejście ułatwia stopniowe wdrażanie mechanizmów egzekwowania kontroli przez parę użytkownik/urządzenie.
Polityka | Nazwa grupy docelowa w zasadach | Polityka – warunek platformy urządzenia | Polityka — Przydzielanie kontroli |
---|---|---|---|
1 | Użytkownicy systemu Windows gotowi do pracy bez hasła i odporni na phishing | Windows | Wymagać silnego uwierzytelniania — wieloskładnikowe uwierzytelnianie odporne na phishing |
2 | Użytkownicy systemu macOS gotowi na rozwiązania bezhasłowe odporni na phishing | macOS | Wymagana siła uwierzytelniania — odporne na phishing uwierzytelnianie wieloskładnikowe |
3 | Użytkownicy gotowi do korzystania z systemu iOS odpornie na phishing bez użycia haseł | iOS | Wymagana siła uwierzytelnienia – wieloskładnikowe uwierzytelnianie odporne na phishing |
4 | Użytkownicy gotowi do korzystania z odpornej na phishing technologii bez hasła w systemie Android | Android | Wymagaj silnego uwierzytelniania — uwierzytelnianie wieloskładnikowe odporne na wyłudzanie informacji |
5 | Inni użytkownicy gotowi na system odporny na phishing i bez użycia haseł | Dowolne z wyjątkiem systemów Windows, macOS, iOS lub Android | Wymagaj siły uwierzytelniania — uwierzytelnianie wieloskładnikowe odporne na wyłudzanie informacji |
Dodaj każdego użytkownika do każdej grupy, określając, czy ich urządzenie i system operacyjny są gotowe, czy nie mają urządzenia tego typu. Na końcu wdrożenia każdy użytkownik powinien znajdować się w jednej z grup.
Reagowanie na ryzyko dla użytkowników bez hasła
Ochrona tożsamości Microsoft Entra pomaga organizacjom wykrywać, badać i korygować zagrożenia oparte na tożsamościach. Ochrona tożsamości Microsoft Entra zapewnia ważne i przydatne wykrywanie użytkowników nawet po przełączeniu się na używanie poświadczeń bez hasła odpornych na wyłudzanie informacji. Na przykład niektóre istotne wykrycia dla użytkowników odpornych na wyłudzanie informacji obejmują:
- Działanie z anonimowego adresu IP
- Administrator potwierdził naruszenie zabezpieczeń użytkownika
- Nietypowy token
- Złośliwy adres IP
- Microsoft Entra inteligencja zagrożeń
- Podejrzana przeglądarka
- Środkowy napastnik
- Możliwa próba uzyskania dostępu do podstawowego tokenu odświeżania (PRT)
- Inne: Wykrycia ryzyk przypisane do typu zdarzenia ryzyka
Firma Microsoft zaleca, aby klienci usługi Microsoft Entra ID Protection podejmowali następujące działania, aby najlepiej chronić użytkowników korzystających z logowania bezhasłowego odpornego na wyłudzanie informacji:
- Zapoznaj się ze wskazówkami dotyczącymi wdrażania Microsoft Entra ID Protection: Planowanie wdrożenia ID Protection
- Konfigurowanie dzienników ryzyka w celu wyeksportowania do rozwiązania SIEM
- Badanie i podejmowanie działań w sprawie ryzyka średniego użytkownika
- Skonfiguruj zasady dostępu warunkowego, aby blokować użytkowników wysokiego ryzyka
Po wdrożeniu ochrony identyfikatora Microsoft Entra rozważ użycie ochrony tokenu dostępu warunkowego. Gdy użytkownicy logują się przy użyciu poświadczeń bez hasła odpornych na wyłudzanie informacji, ataki i wykrycia nadal ewoluują. Na przykład, gdy poświadczenia użytkownika nie mogą być już łatwo wyłudzane, atakujący mogą spróbować eksfiltrować tokeny z urządzeń użytkowników. Ochrona tokenów pomaga ograniczyć to ryzyko przez powiązanie tokenów ze sprzętem urządzenia, do którego zostały wystawione.