Планирование фишинго-устойчивого развертывания проверки подлинности без пароля в идентификаторе Microsoft Entra

При развертывании и эксплуатации фишингозащищенной проверки подлинности без пароля в вашей среде рекомендуется использовать подход на основе пользователя. Различные методы без пароля, устойчивые к фишингу, более эффективны, чем другие для определенных пользователей. В этом руководстве по развертыванию вы увидите, какие типы методов и планов развертывания подходят для пользователей в вашей среде. Подход к фишингу без пароля обычно содержит 6 шагов, которые примерно выполняются в порядке, но не нужно выполнять 100 % перед переходом к другим шагам:

Определение пользователей

Определите пользователей, соответствующие вашей организации. Этот шаг очень важен для вашего проекта, так как разные лица имеют разные потребности. Корпорация Майкрософт рекомендует рассмотреть и оценить по крайней мере 4 универсальных пользователей в организации.

Пользователь	Description
Информационные работники	Примерами являются сотрудники по повышению производительности офиса, такие как маркетинг, финансы или кадровые ресурсы. Другие типы информационных работников могут быть руководителями и другими высокочувствительными работниками, которым требуются специальные средства контроля Обычно связь 1:1 с мобильными устройствами и вычислительными устройствами Может принести собственные устройства (BYOD), особенно для мобильных устройств
Фронтовые работники	Примеры: работники розничного магазина, рабочие фабрики, производственные работники Как правило, работают только на общих устройствах или киосках Может быть запрещено переносить мобильные телефоны
ИТ-специалисты и сотрудники DevOps	Примерами являются ИТ-администраторы для локальная служба Active Directory, идентификатора Microsoft Entra или других привилегированных учетных записей. другими примерами будут рабочие роли DevOps или сотрудники DevSecOps, которые управляют и развертывают автоматизацию. Как правило, несколько учетных записей пользователей, включая обычную учетную запись пользователя, а также одну или несколько учетных записей администратора. Обычно используют протоколы удаленного доступа, такие как протокол удаленного рабочего стола (RDP) и протокол Secure Shell (SSH), для администрирования удаленных систем Может работать на заблокированных устройствах с отключенным Bluetooth Может использовать вторичные учетные записи для запуска неинтерактивных автоматизации и сценариев
Строго регулируемые работники	Примеры включают федеральных государственных работников США в соответствии с требованиями 14028 , государственными и местными государственными работниками или работниками, действующими в соответствии с конкретными правилами безопасности Как правило, связь 1:1 с их устройствами, но имеют определенные нормативные элементы управления, которые должны выполняться на этих устройствах и для проверки подлинности Мобильные телефоны могут быть запрещены в безопасных областях Доступ к средам, подключенным к воздуху без подключения к Интернету Может работать на заблокированных устройствах с отключенным Bluetooth

Корпорация Майкрософт рекомендует широко развертывать фишинговую проверку подлинности без пароля в организации. Традиционно информационные работники — самый простой пользователь, с которого следует начать. Не откладывайте развертывание защищенных учетных данных для информационных работников во время устранения проблем, влияющих на ИТ-специалистов. Возьмите подход "не позволяйте идеально быть врагом хорошего" и развертывайте безопасные учетные данные как можно больше. По мере того как пользователи войдите с помощью фишинговых учетных данных без пароля, вы сокращаете область атаки вашей среды.

Корпорация Майкрософт рекомендует определить ваши лица, а затем поместить каждую персону в группу идентификаторов Microsoft Entra специально для этого пользователя. Эти группы используются в последующих шагах для развертывания учетных данных для разных типов пользователей и при начале применения фишинговых учетных данных без пароля.

Планирование готовности устройства

Устройства являются важным аспектом любого успешного фишинго-устойчивого развертывания без пароля, так как одна из целей фишингозащищенных учетных данных без пароля заключается в защите учетных данных с помощью оборудования современных устройств. Сначала ознакомитесь с поддержкой FIDO2 для идентификатора Microsoft Entra.

Убедитесь, что ваши устройства готовы к фишингу без пароля путем исправления до последних поддерживаемых версий каждой операционной системы. Корпорация Майкрософт рекомендует, чтобы ваши устройства работали с этими версиями как минимум:

• Windows 10 22H2 (для Windows Hello для бизнеса)
• Windows 11 22H2 (для лучшего взаимодействия с пользователем при использовании секретных ключей)
• macOS 13 Ventura
• iOS 17
• Android 14

Эти версии обеспечивают оптимальную поддержку встроенных функций, таких как ключи доступа, Windows Hello для бизнеса и учетные данные платформы macOS. Старые операционные системы могут требовать внешних аутентификаторов, таких как ключи безопасности FIDO2, для поддержки фишинговой проверки подлинности без пароля.

Регистрация пользователей для фишинговых учетных данных

Регистрация учетных данных и начальная загрузка — это первые основные действия, с которыми сталкиваются конечные пользователи в проекте развертывания без фишинга. В этом разделе рассматривается развертывание переносимых и локальных учетных данных.

Подтверждение компетенции	Description	Льготы
Портативный	Можно использовать на разных устройствах. Вы можете использовать переносимые учетные данные для входа на другое устройство или регистрации учетных данных на других устройствах.	Наиболее важный тип учетных данных для регистрации для большинства пользователей, так как они могут использоваться на разных устройствах и обеспечивают фишинговую проверку подлинности во многих сценариях.
Локальная среда	Локальные учетные данные можно использовать для проверки подлинности на устройстве без необходимости полагаться на внешнее оборудование, например использование Windows Hello для бизнеса биометрического распознавания для входа в приложение в браузере Microsoft Edge на том же компьютере.	Они имеют два основных преимущества по сравнению с переносимыми учетными данными: Они обеспечивают избыточность. Если пользователи теряют переносимое устройство, забудуте его дома или имеют другие проблемы, локальные учетные данные предоставляют им метод резервного копирования для продолжения работы на вычислительном устройстве. Они обеспечивают отличный пользовательский интерфейс. С помощью локальных учетных данных пользователям не нужно извлекать телефоны из кармана, сканировать QR-коды или выполнять другие задачи, которые замедляют проверку подлинности и добавляют трения. Локальные доступные фишинговые учетные данные помогают пользователям легко входить на устройствах, которые они регулярно используют.

• Для новых пользователей процесс регистрации и начальной загрузки принимает пользователя без существующих корпоративных учетных данных и проверяет свое удостоверение. Он загружает их в свои первые переносимые учетные данные и использует эти переносные учетные данные для загрузки других локальных учетных данных на каждом из своих вычислительных устройств. После регистрации администратор может применить фишинговую проверку подлинности для пользователей в идентификаторе Microsoft Entra.
• Для существующих пользователей этот этап позволяет пользователям регистрироваться для фишинга без пароля на существующих устройствах напрямую или использовать существующие учетные данные MFA для загрузки фишинговых учетных данных без пароля. Конечной целью является то же самое, что и новые пользователи- большинство пользователей должны иметь по крайней мере одну переносимую учетные данные, а затем локальные учетные данные на каждом вычислительном устройстве. Если вы являетесь администратором, который развертывает фишинговый пароль без пароля для существующих пользователей, вы можете перейти к шагу 2. Загрузка раздела "Переносимые учетные данные".

Перед началом работы корпорация Майкрософт рекомендует включить секретный ключ и другие учетные данные для корпоративных пользователей в клиенте. Если пользователи мотивированы самостоятельно зарегистрировать для надежных учетных данных, это полезно. Как минимум, следует включить политику Passkey (FIDO2), чтобы пользователи могли регистрировать ключи доступа и ключи безопасности, если они предпочитают их.

В этом разделе рассматриваются этапы 1-3.

У пользователей должно быть по крайней мере два метода проверки подлинности. При регистрации другого метода пользователь имеет доступный метод резервного копирования, если что-то происходит с основным методом, например при потере или краже устройства. Например, рекомендуется, чтобы пользователи регистрировали ключи как на телефоне, так и локально на своей рабочей станции в Windows Hello для бизнеса.

Примечание.

Всегда рекомендуется, чтобы пользователи зарегистрировали по крайней мере два метода проверки подлинности. Это гарантирует, что пользователь имеет метод резервного копирования, если что-то происходит с их основным методом, например в случаях потери устройства или кражи. Например, рекомендуется, чтобы пользователи регистрировали ключи доступа как на телефоне, так и локально на рабочей станции в Windows Hello для бизнеса.

Примечание.

Это руководство предназначено для существующей поддержки ключей доступа в идентификаторе Microsoft Entra ID, включающем ключи доступа, привязанные к устройству, в Microsoft Authenticator и ключи доступа, привязанные к устройству, для физических ключей безопасности. Идентификатор Microsoft Entra планирует добавить поддержку синхронизированных секретных ключей. Дополнительные сведения см. в общедоступной предварительной версии: расширение поддержки секретного ключа в идентификаторе Microsoft Entra. Это руководство будет обновлено, чтобы включить синхронизированные инструкции по ключу доступа после доступности. Например, многие организации могут воспользоваться синхронизацией на этапе 3 на предыдущей схеме, а не загрузочными учетными данными.

Шаг 1. Проверка подлинности

Для удаленных пользователей, которые не доказали свою личность, подключение предприятия является значительной проблемой. Без надлежащей проверки подлинности организация не может быть полностью уверена в том, что они подключены к лицу, которому они намерены. Проверенные учетные данные Microsoft Entra может обеспечить проверку подлинности с высоким уровнем надежности. Организации могут работать с партнером по проверке удостоверений (IDV), чтобы проверить удостоверения новых удаленных пользователей в процессе подключения. После обработки выданного пользователем идентификатора idV может предоставить проверенный идентификатор, подтверждающий удостоверение пользователя. Новый пользователь представляет этот проверенный идентификатор в организации найма для установления доверия и подтверждения того, что организация подключена к правильному лицу. Организации могут добавить проверку лиц с помощью Проверенные учетные данные Microsoft Entra, которая добавляет уровень сопоставления лиц к проверке, гарантируя, что доверенный пользователь представляет проверяемый идентификатор в этот момент.

После проверки личности с помощью процесса проверки правописания новые сотрудники получают временный проход доступа (TAP), который они могут использовать для загрузки своих первых переносимых учетных данных.

Ознакомьтесь со следующими руководствами, чтобы включить Проверенные учетные данные Microsoft Entra подключение и выдачу TAP:

• Подключение новых удаленных сотрудников с помощью проверки идентификатора
• Использование проверки лиц с Проверенные учетные данные Microsoft Entra для разблокировки проверки высокой надежности в масштабе
• Включение политики временного доступа

Дополнительные сведения о лицензировании Проверенные учетные данные Microsoft Entra см. по следующим ссылкам:

• Проверка лиц с ценами на Проверенные учетные данные Microsoft Entra
• Планы и цены Microsoft Entra

Некоторые организации могут выбирать другие методы, кроме Проверенные учетные данные Microsoft Entra для подключения пользователей и выдачи им первых учетных данных. Корпорация Майкрософт рекомендует тем организациям по-прежнему использовать TAP или другой способ, позволяющий пользователю подключиться без пароля. Например, можно подготовить ключи безопасности FIDO2 с помощью API Microsoft Graph.

Подключение шага 2. Загрузка переносимых учетных данных

Чтобы загрузить существующих пользователей на фишинговые учетные данные без пароля, сначала определите, зарегистрированы ли ваши пользователи для традиционной MFA. Пользователи с традиционными методами MFA, зарегистрированные, могут быть нацелены на фишинговые политики регистрации без пароля. Они могут использовать традиционную MFA, чтобы зарегистрировать свои первые переносимые фишинговые учетные данные, а затем перейти к регистрации для локальных учетных данных по мере необходимости.

Для новых пользователей или пользователей без многофакторной проверки подлинности выполните процедуру выдачи пользователям временной передачи доступа (TAP). Вы можете создать TAP так же, как предоставить новым пользователям свои первые учетные данные или с помощью интеграции Проверенные учетные данные Microsoft Entra. После того как пользователи имеют TAP, они готовы загрузить свои первые фишинговые учетные данные.

Важно, чтобы первые учетные данные пользователя без пароля были переносимыми учетными данными, которые можно использовать для проверки подлинности на других вычислительных устройствах. Например, ключи доступа можно использовать для локальной проверки подлинности на телефоне iOS, но их также можно использовать для проверки подлинности на компьютере с Windows с помощью потока проверки подлинности между устройствами. Эта возможность кросс-устройства позволяет использовать переносимый секретный ключ для загрузки Windows Hello для бизнеса на компьютере с Windows.

Кроме того, важно, чтобы каждое устройство, на которое пользователь регулярно работал, имеет локальные учетные данные, чтобы предоставить пользователю самый удобный пользовательский интерфейс. Локальные доступные учетные данные сокращают время, необходимое для проверки подлинности, так как пользователям не нужно использовать несколько устройств, и меньше шагов. Использование TAP из шага 1 для регистрации переносимых учетных данных, которые могут загрузить эти другие учетные данные, позволяет пользователю использовать фишинговые учетные данные, устойчивые к фишингу, на многих устройствах, которые они могут иметь.

В следующей таблице перечислены рекомендации для разных пользователей:

Пользователь Persona	Рекомендуемые переносимые учетные данные	Альтернативные переносимые учетные данные
Информационный работник	Passkey (приложение Authenticator)	Ключ безопасности, смарт-карта
Работник передней линии	Ключ безопасности	Passkey (приложение Authenticator), смарт-карта
ИТ-специалист или рабочая роль DevOps	Passkey (приложение Authenticator)	Ключ безопасности, смарт-карта
Строго регулируемый рабочий работник	Сертификат (смарт-карта)	Секретный ключ (приложение Authenticator), ключ безопасности

Используйте следующее руководство, чтобы включить рекомендуемые и альтернативные переносимые учетные данные для соответствующих пользователей для вашей организации:

Способ	Руководство
Секретные ключи	Корпорация Майкрософт рекомендует пользователям входить в Microsoft Authenticator непосредственно для загрузки секретного ключа в приложении. Пользователи могут использовать tap для входа в Microsoft Authenticator непосредственно на устройстве iOS или Android. Секретные ключи отключены по умолчанию в идентификаторе Microsoft Entra. Вы можете включить ключи доступа в политике методов проверки подлинности. Зарегистрируйте ключи доступа в Authenticator на устройствах Android или iOS.
Ключи безопасности	Ключи безопасности отключены по умолчанию в идентификаторе Microsoft Entra. Ключи безопасности FIDO2 можно включить в политике методов проверки подлинности. Рекомендуется зарегистрировать ключи от имени пользователей с помощью API подготовки идентификаторов Microsoft Entra. Дополнительные сведения см. в разделе "Подготовка ключей безопасности FIDO2 с помощью API Microsoft Graph".
Проверка подлинности на основе смарт-карт или сертификатов (CBA)	Проверка подлинности на основе сертификатов сложнее настроить, чем ключи доступа или другие методы. При необходимости рекомендуется использовать только его. Настройка проверки подлинности на основе сертификатов Microsoft Entra. Обязательно настройте локальные PKI и политики CBA идентификатора Microsoft Entra ID, чтобы пользователи действительно выполнили многофакторную проверку подлинности для входа. В конфигурации обычно требуется идентификатор объекта политики смарт-карт (OID) и необходимые параметры привязки сходства. Дополнительные сведения о конфигурациях CBA см. в разделе "Общие сведения о политике привязки проверки подлинности".

Шаг 3. Локальные учетные данные начальной загрузки на вычислительных устройствах

После того как пользователи зарегистрировали переносимые учетные данные, они готовы загрузить другие учетные данные на каждом вычислительном устройстве, которые они регулярно используют в отношениях 1:1, что обеспечивает их повседневное взаимодействие с пользователем. Этот тип учетных данных распространен для информационных работников и ИТ-специалистов, но не для сотрудников передней линии, которые совместно используют устройства. Пользователи, которые совместно используют только устройства, должны использовать только переносимые учетные данные.

Вашей организации необходимо определить, какой тип учетных данных предпочтителен для каждого пользователя на этом этапе. Корпорация Майкрософт рекомендует:

Пользователь	Рекомендуемые локальные учетные данные — Windows	Рекомендуемые локальные учетные данные — macOS	Рекомендуемые локальные учетные данные — iOS	Рекомендуемые локальные учетные данные — Android	Рекомендуемые локальные учетные данные — Linux
Информационный работник	Windows Hello для бизнеса	Единый вход платформы (единый вход) Безопасный ключ анклава	Passkey (приложение Authenticator)	Passkey (приложение Authenticator)	N/A (вместо этого используйте переносимые учетные данные)
Работник передней линии	N/A (вместо этого используйте переносимые учетные данные)	N/A (вместо этого используйте переносимые учетные данные)	N/A (вместо этого используйте переносимые учетные данные)	N/A (вместо этого используйте переносимые учетные данные)	N/A (вместо этого используйте переносимые учетные данные)
ИТ-специалист или рабочая роль DevOps	Windows Hello для бизнеса	Ключ безопасного анклава для платформы	Passkey (приложение Authenticator)	Passkey (приложение Authenticator)	N/A (вместо этого используйте переносимые учетные данные)
Строго регулируемый рабочий работник	Windows Hello для бизнеса или CBA	Безопасный ключ анклава или CBA для платформы	Секретный ключ (приложение Authenticator) или CBA	Секретный ключ (приложение Authenticator) или CBA	N/A (вместо этого используйте смарт-карту)

Используйте следующее руководство, чтобы включить рекомендуемые локальные учетные данные в вашей среде для соответствующих пользователей для вашей организации:

Способ	Руководство
Windows Hello для бизнеса	Корпорация Майкрософт рекомендует использовать метод Cloud Kerberos Trust для развертывания Windows Hello для бизнеса. Дополнительные сведения см. в руководстве по развертыванию доверия Cloud Kerberos. Метод Cloud Kerberos Trust применяется к любой среде, в которой пользователи синхронизируются с локальная служба Active Directory с идентификатором Microsoft Entra. Это помогает синхронизировать пользователей на компьютерах, присоединенных к Microsoft Entra или гибридных присоединенных к Microsoft Entra. Windows Hello для бизнеса следует использовать только в том случае, если каждый пользователь на компьютере входит в этот компьютер как сам. Его не следует использовать на устройствах киоска, использующих общую учетную запись пользователя. Windows Hello для бизнеса поддерживает до 10 пользователей на устройство. Если общие устройства должны поддерживать больше пользователей, вместо этого используйте переносимые учетные данные, такие как ключи безопасности. Биометрические данные являются необязательными, но рекомендуется. Дополнительные сведения см. в статье "Подготовка пользователей к подготовке и использованию Windows Hello для бизнеса".
Ключ безопасного анклава для платформы	Единый вход платформы поддерживает 3 различных метода проверки подлинности пользователей (безопасный ключ Анклава, смарт-карта и пароль). Разверните метод ключа Secure Enclave, чтобы зеркально отображать Windows Hello для бизнеса на компьютерах Mac. Для единого входа платформы требуется, чтобы компьютеры Mac регистрировались в мобильных Управление устройствами (MDM). Инструкции по Intune см. в разделе "Настройка единого входа платформы для устройств macOS" в Microsoft Intune. Обратитесь к документации поставщика MDM, если вы используете другую службу MDM на компьютерах Mac.
Секретные ключи	Корпорация Майкрософт рекомендует использовать тот же параметр регистрации устройств для загрузки секретных ключей в Microsoft Authenticator (а не параметр регистрации между устройствами). Пользователи используют TAP для входа в Microsoft Authenticator непосредственно на устройстве iOS или Android. Секретные ключи отключены по умолчанию в идентификаторе Microsoft Entra, включите их в политике методов проверки подлинности. Дополнительные сведения см. в разделе "Включение ключей доступа" в Microsoft Authenticator. Зарегистрируйте ключи доступа в Authenticator на устройствах Android или iOS.

Рекомендации, связанные с персоной

Каждый человек имеет свои собственные проблемы и рекомендации, которые обычно возникают во время фишинговых развертываний без пароля. При определении того, какие лица необходимо разместить, следует учитывать эти факторы в планировании проекта развертывания. Следующие ссылки содержат конкретные рекомендации для каждого человека:

• Информационные работники
• Фронтовые работники
• ИТ-специалисты/сотрудники DevOps
• Строго регулируемые работники

Использование фишинговых учетных данных

На этом шаге описывается, как упростить прием фишинговых учетных данных, устойчивых к фишингу. Вы должны протестировать стратегию развертывания, запланировать развертывание и сообщить о плане конечным пользователям. Затем вы можете создавать отчеты и отслеживать ход выполнения, прежде чем применять фишинговые учетные данные в организации.

Тестирование стратегии развертывания

Корпорация Майкрософт рекомендует протестировать стратегию развертывания, созданную на предыдущем шаге, с набором тестовых и пилотных пользователей. Этот этап должен включать следующие шаги:

• Создайте список тестовых пользователей и ранних пользователей. Эти пользователи должны представлять разные пользователи, а не только ИТ-администраторы.
• Создайте группу идентификаторов Microsoft Entra и добавьте тестовых пользователей в группу.
• Включите политики методов проверки подлинности в идентификаторе Microsoft Entra и оставьте область тестовой группы для методов, которые вы включаете.
• Измеряйте развертывание регистрации для пилотных пользователей с помощью отчета о действиях методов проверки подлинности.
• Создайте политики условного доступа для принудительного применения фишинговых учетных данных без пароля для каждого типа операционной системы и целевой группы пилотного проекта.
• Измеряйте успешность применения с помощью Azure Monitor и книг.
• Сбор отзывов от пользователей об успешном выполнении развертывания.

Стратегия развертывания плана

Корпорация Майкрософт рекомендует управлять использованием на основе того, какие пользователи наиболее готовы к развертыванию. Как правило, это означает развертывание для пользователей в этом порядке, но это может измениться в зависимости от вашей организации:

1. Информационные работники
2. Фронтовые работники
3. ИТ-специалисты/сотрудники DevOps
4. Строго регулируемые работники

Используйте следующие разделы, чтобы создать обмен данными пользователей для каждой группы пользователей, области и развертывания функции регистрации секретных ключей, а также для отслеживания хода развертывания и мониторинга пользователей.

Планирование обмена данными пользователей

Корпорация Майкрософт предоставляет шаблоны связи для конечных пользователей. Материал по развертыванию проверки подлинности включает настраиваемые плакаты и шаблоны электронной почты для информирования пользователей о развертывании проверки подлинности без фишинга без пароля. Используйте следующие шаблоны для обмена данными с пользователями, чтобы они понимали фишинговое развертывание без пароля:

• Вход без пароля с помощью Microsoft Authenticator
• Регистрация метода проверки сброса пароля для рабочей или учебной учетной записи
• Сброс рабочего или учебного пароля с помощью сведений о безопасности
• Настройка ключа безопасности в качестве метода проверки
• Вход в учетные записи с помощью приложения Microsoft Authenticator
• Войдите в рабочую или учебную учетную запись с помощью двухфакторной проверки подлинности
• Вход в рабочую или учебную учетную запись, заблокированный ограничениями клиента

Обмен данными должен повторяться несколько раз, чтобы помочь поймать максимальное количество пользователей. Например, ваша организация может использовать различные этапы и временные шкалы с шаблоном, следующим образом:

1. 60 дней после принудительного применения: сообщение о значении методов проверки подлинности, устойчивых к фишингу, и поощряйте пользователей заранее регистрировать
2. 45 дней после принудительного применения: повторение сообщения
3. 30 дней от принудительного применения: сообщение о том, что в 30 дней будет начинаться фишинговое применение, поощряйте пользователей заранее регистрировать
4. 15 дней из принудительного применения: повторите сообщение, сообщите им о том, как связаться со службой технической поддержки
5. 7 дней из принудительного применения: повторите сообщение, сообщите им о том, как обратиться в службу технической поддержки
6. 1 день от принудительного применения: сообщите им о применении в течение 24 часов, сообщите им о том, как обратиться в службу технической поддержки

Корпорация Майкрософт рекомендует взаимодействовать с пользователями через другие каналы за пределами только электронной почты. Другие варианты могут включать сообщения Microsoft Teams, плакаты комнаты останова и программы чемпиона, где выбор сотрудников обучен выступать за программу для своих коллег.

Создание отчетов и мониторинг

Отчеты об идентификаторе Microsoft Entra (например , действия методов проверки подлинности и сведения о событии входа для многофакторной проверки подлинности Microsoft Entra) предоставляют технические и бизнес-аналитические сведения, которые помогают измерять и внедрять диски.

На панели мониторинга действий методов проверки подлинности можно просмотреть регистрацию и использование.

• Регистрация показывает количество пользователей, способных фишинговую проверку подлинности без пароля и другие методы проверки подлинности. Вы увидите графики, показывающие, какие методы проверки подлинности зарегистрированы пользователи, и последняя регистрация для каждого метода.
• Использование показывает, какие методы проверки подлинности использовались для входа.

Владельцы бизнес-и технических приложений должны принадлежать и получать отчеты на основе требований организации.

• Отслеживайте развертывание фишинговых учетных данных без пароля с помощью отчетов о действиях регистрации методов проверки подлинности.
• Отслеживание внедрения фишинговых учетных данных без пароля с помощью методов проверки подлинности в отчетах о действиях входа и входа в журналы.
• Используйте отчет о действиях входа, чтобы отслеживать методы проверки подлинности, используемые для входа в различные приложения. Выберите строку пользователя; Выберите "Сведения о проверке подлинности", чтобы просмотреть метод проверки подлинности и соответствующее действие входа.

Идентификатор Microsoft Entra добавляет записи в журналы аудита при возникновении следующих условий:

• Администратор изменяет методы проверки подлинности.
• Пользователь изменяет свои учетные данные в идентификаторе Microsoft Entra.

Идентификатор Microsoft Entra сохраняет большинство данных аудита в течение 30 дней. Мы рекомендуем более длительное хранение для аудита, анализа тенденций и других бизнес-потребностей.

Доступ к данным аудита в Центре администрирования Microsoft Entra или API и скачивание в системы анализа. Если требуется более длительное хранение, экспорт и использование журналов в средстве управления сведениями и событиями безопасности (SIEM), например Microsoft Sentinel, Splunk или Sumo Logic.

Мониторинг объема запросов в службу технической поддержки

Ит-служба технической поддержки может предоставить бесценный сигнал о том, насколько хорошо выполняется развертывание, поэтому корпорация Майкрософт рекомендует отслеживать объем билетов службы поддержки при выполнении фишинго-устойчивого развертывания без пароля.

По мере увеличения объема запросов в службу поддержки вы должны замедлить темпы развертывания, взаимодействия пользователей и действия по принудительному применению. По мере уменьшения объема билетов вы можете выполнить резервное копирование этих действий. Этот подход требует обеспечения гибкости в плане развертывания.

Например, можно выполнить развертывания, а затем принудительно применять волны с диапазоном дат, а не конкретными датами:

1. 1 июня-15: развертывание и кампании по регистрации волны 1
2. 16 июня–30: развертывание и кампании по регистрации волны 2
3. 1 июля–15:15: развертывание и кампании по регистрации 3 волны 3
4. 16 июля–31-го: включение принудительного применения волны 1
5. 1 августа–15:15: включение принудительного применения волны 2
6. 16 августа-31st: Волны 3 когорты включено принудительное применение

При выполнении этих различных этапов может потребоваться замедлить работу в зависимости от объема открытых билетов в службу технической поддержки, а затем возобновить, когда объем утих. Чтобы выполнить эту стратегию, корпорация Майкрософт рекомендует создать группу безопасности идентификатора Microsoft Entra для каждой волны и добавить каждую группу в политики по одному за раз. Этот подход помогает избежать подавляющей группы поддержки.

Применение методов, устойчивых к фишингу для входа

В этом разделе рассматривается этап 4.

Последний этап фишинго-устойчивого развертывания без пароля применяет использование фишинговых учетных данных. Основной механизм для этого в идентификаторе Microsoft Entra — это преимущества проверки подлинности условного доступа. Корпорация Майкрософт рекомендует применять принудительное применение для каждого человека на основе методологии пары пользователей и устройств. Например, развертывание принудительного применения может соответствовать следующему шаблону:

1. Информационные работники в Windows и iOS
2. Информационные работники в macOS и Android
3. ИТ-специалисты в iOS и Android
4. FLWs в iOS и Android
5. FLWs в Windows и macOS
6. ИТ-специалисты в Windows и macOS

Корпорация Майкрософт рекомендует создать отчет обо всех парах пользователей и устройств с помощью данных входа из клиента. Вы можете использовать такие средства запроса, как Azure Monitor и книги. По крайней мере попробуйте определить все пары пользователей и устройств, соответствующие этим категориям.

Для каждого пользователя создайте список операционных систем, которые они регулярно используют для работы. Сопоставите список с готовностью к принудительному входу с устойчивостью к фишингу для этой пары пользователей и устройств.

Тип ОС	Готово к принудительному применению	Не готов к принудительному применению
Windows	10+	8.1 и более ранних версий Windows Server
iOS	17 и выше	16 и более ранних версий
Android	14+	13 и более ранних версий
macOS	13+ (Вентура)	12 и более ранних версий
VDI	Зависитот 1	Зависитот 1
Другие	Зависитот 1	Зависитот 1

¹Для каждой пары пользователей или устройств, где версия устройства не сразу готова к принудительному применению, определите, как устранить необходимость принудительного применения фишинга. Рассмотрим следующие варианты для старых операционных систем, инфраструктуры виртуальных рабочих столов (VDI) и других операционных систем, таких как Linux:

• Принудительное применение фишингового сопротивления с помощью внешнего оборудования — ключи безопасности FIDO2
• Принудительное применение фишингового сопротивления с помощью внешнего оборудования — смарт-карт
• Применение защиты от фишинга с помощью удаленных учетных данных, таких как ключи доступа в потоке проверки подлинности между устройствами
• Применение защиты от фишинга с помощью удаленных учетных данных внутри туннелей RDP (особенно для VDI)

Основная задача — измерять данные, которые пользователи и лица готовы к применению на определенных платформах. Начните действия принудительного применения на парах пользователей и устройств, которые готовы к принудительному применению, чтобы "остановить кровотечение", и уменьшить количество фишинговой проверки подлинности в вашей среде.

Затем перейдите к другим сценариям, где пары пользователей и устройств требуют усилий по готовности. Пройдите по списку пар пользователей и устройств, пока не будете применять фишинговую проверку подлинности через доску.

Создайте набор групп идентификаторов Microsoft Entra для постепенного развертывания принудительного применения. Повторно используйте группы из предыдущего шага , если вы использовали подход развертывания на основе волн.

Целевая группа с определенной политикой условного доступа. Этот подход помогает постепенно развертывать элементы управления принудительной применением по паре пользователей и устройств.

Политика	Имя группы, целевое в политике	Политика — условие платформы устройства	Политика — предоставление элемента управления
1	Готовые пользователи без фишинга Windows	Windows	Требовать степень проверки подлинности — фишингозащищенная MFA
2	пользователи с защитой от фишинга без пароля macOS	macOS	Требовать степень проверки подлинности — фишингозащищенная MFA
3	Готовые пользователи без фишинга iOS	iOS	Требовать степень проверки подлинности — фишингозащищенная MFA
4	Готовые пользователи без фишинга Android	Android	Требовать степень проверки подлинности — фишингозащищенная MFA
5	Другие фишинговые без пароля готовые пользователи	Любые, кроме Windows, macOS, iOS или Android	Требовать степень проверки подлинности — фишингозащищенная MFA

Добавьте каждого пользователя в каждую группу по мере готовности устройства и операционной системы, или у них нет устройства этого типа. В конце развертывания каждый пользователь должен находиться в одной из групп.

Реагирование на риск для пользователей без пароля

Защита идентификации Microsoft Entra помогает организациям обнаруживать, исследовать и устранять риски, связанные с идентификацией. Защита идентификации Microsoft Entra предоставляет важные и полезные обнаружения для пользователей даже после перехода на использование фишинговых учетных данных без пароля. Например, некоторые важные обнаружения для фишинговых пользователей:

• Действия, выполняемые с анонимных IP-адресов
• Подтвержденная администратором компрометация пользователя
• Аномальный маркер
• Вредоносный IP-адрес
• Аналитика угроз Microsoft Entra
• Подозрительный браузер
• Злоумышленник в середине
• Возможная попытка доступа к основному маркеру обновления
• И другие: обнаружения рисков, сопоставленные с riskEventType

Корпорация Майкрософт рекомендует Защита идентификации Microsoft Entra клиентам выполнять следующие действия, чтобы лучше защитить пользователей без фишинга:

1. Ознакомьтесь с руководством по развертыванию Защита идентификации Microsoft Entra. Планирование развертывания защиты идентификаторов
2. Настройка журналов рисков для экспорта в SIEM
3. Изучение и действие на любой средний риск пользователя
4. Настройка политики условного доступа для блокировки пользователей с высоким риском

После развертывания Защита идентификации Microsoft Entra рассмотрите возможность использования защиты маркера условного доступа. При входе пользователей с помощью фишинговых учетных данных без пароля атаки и обнаружения продолжают развиваться. Например, когда учетные данные пользователя больше не могут быть легко фишинговыми, злоумышленники могут перейти к попытке эксфильтровать маркеры с пользовательских устройств. Защита маркеров помогает снизить этот риск путем привязки маркеров к оборудованию устройства, на которое они были выданы.

Следующие шаги

Рекомендации по использованию определенных лиц в развертывании без пароля без фишинга в идентификаторе Microsoft Entra