Планирование фишинго-устойчивого развертывания проверки подлинности без пароля в идентификаторе Microsoft Entra
При развертывании и эксплуатации фишингозащищенной проверки подлинности без пароля в вашей среде рекомендуется использовать подход на основе пользователя. Различные методы без пароля, устойчивые к фишингу, более эффективны, чем другие для определенных пользователей. В этом руководстве по развертыванию вы увидите, какие типы методов и планов развертывания подходят для пользователей в вашей среде. Подход развертывания, устойчивый к фишингу и без паролей, обычно включает 6 этапов, которые выполняются в установленном порядке, но не обязательно завершать на 100% перед переходом к другим этапам.
Определение ваших пользовательских персонажей
Определите персоны пользователей, соответствующие вашей организации. Этот шаг очень важен для вашего проекта, так как разные лица имеют разные потребности. Корпорация Майкрософт рекомендует рассмотреть и оценить по крайней мере 4 универсальных пользователей в организации.
| Портрет пользователя | Описание |
|---|---|
| Информационные работники | |
| Фронтовые работники | |
| ИТ-специалисты и сотрудники DevOps | |
| Строго регулируемые работники |
Корпорация Майкрософт рекомендует широко развертывать авторизацию, защищенную от фишинга и не требующую пароля, по всей вашей организации. Традиционно информационные работники — самый простой пользователь, с которого следует начать. Не откладывайте развертывание защищенных учетных данных для информационных работников во время устранения проблем, влияющих на ИТ-специалистов. Следуйте принципу "не делайте из хорошего врага лучшего" и развертывайте безопасные учетные данные как можно чаще. По мере того как всё больше пользователей входят в систему, используя устойчивые к фишингу учетные данные без пароля, вы сокращаете поверхность атаки вашей среды.
Корпорация Майкрософт рекомендует определить ваши лица, а затем поместить каждую персону в группу идентификаторов Microsoft Entra специально для этого пользователя. Эти группы используются в последующих шагах для развертывания учетных данных для разных типов пользователей, и при начале применения устойчивых к фишингу безпарольных учетных данных.
Планирование готовности устройства
Устройства являются важным аспектом любого успешного фишинго-устойчивого развертывания без пароля, так как одна из целей фишингозащищенных учетных данных без пароля заключается в защите учетных данных с помощью оборудования современных устройств. Сначала ознакомитесь с поддержкой FIDO2 для идентификатора Microsoft Entra.
Убедитесь, что ваши устройства готовы к безпарольной аутентификации, устойчивой к фишинговым атакам, установив последние поддерживаемые версии каждой операционной системы. Корпорация Майкрософт рекомендует, чтобы ваши устройства работали с этими версиями как минимум:
- Windows 10 22H2 (для Windows Hello для бизнеса)
- Windows 11 22H2 (для наилучшего пользовательского опыта при использовании ключей доступа)
- macOS 13 Ventura
- iOS 17
- Android 14
Эти версии обеспечивают оптимальную поддержку встроенных функций, таких как ключи доступа, Windows Hello для бизнеса и учетные данные платформы macOS. Старые операционные системы могут требовать внешних аутентификаторов, таких как ключи безопасности FIDO2, для поддержки фишинговой проверки подлинности без пароля.
Регистрация пользователей для учетных данных, устойчивых к фишинговым атакам
Регистрация учетных данных и настройка начальных параметров являются первыми значительными действиями для конечных пользователей в проекте развертывания надежной к фишингу безпарольной системы. В этом разделе рассматривается развертывание переносимых и локальныхучетных данных.
| Подтверждение компетенции | Описание | Льготы |
|---|---|---|
| Портативный | Можно использовать на разных устройствах. Вы можете использовать переносимые учетные данные для входа на другое устройство или регистрации учетных данных на других устройствах. | Наиболее важный тип учетных данных для регистрации для большинства пользователей, так как они могут использоваться на разных устройствах и обеспечивают фишинговую проверку подлинности во многих сценариях. |
| Локальная среда | Локальные учетные данные локальные можно использовать для проверки подлинности на устройстве без необходимости полагаться на внешнее оборудование, например, используя биометрическое распознавание в Windows Hello для бизнеса для входа в приложение в браузере Microsoft Edge на том же компьютере. | Они имеют два основных преимущества по сравнению с переносимыми учетными данными: |
- Для новых пользователей процесс регистрации и начальной загрузки проводит пользователя без существующих корпоративных учетных данных и проверяет их личность. Он загружает их в свои первые переносимые учетные данные и использует эти переносные учетные данные для загрузки других локальных учетных данных на каждом из своих вычислительных устройств. После регистрации администратор может потребовать от пользователей использовать аутентификацию, устойчивую к фишингу, в Microsoft Entra ID.
- Для существующих пользователей этот этап позволяет зарегистрироваться для защищенной от фишинга безпарольной авторизации на существующих устройствах напрямую или с использованием существующих учетных данных MFA для настройки защищенных от фишинга безпарольных учетных данных. Конечной целью является то же самое, что и новые пользователи- большинство пользователей должны иметь по крайней мере одну переносимую учетные данные, а затем локальные учетные данные на каждом вычислительном устройстве. Если вы являетесь администратором, который развертывает фишинг-устойчивый безпарольный вход для существующих пользователей, то вы можете перейти к шагу 2: Начало работы с разделом "Переносимые учетные данные".
Перед началом работы корпорация Майкрософт рекомендует включить секретный ключ и другие учетные данные для корпоративных пользователей в клиенте. Если пользователи мотивированы самостоятельно регистрироваться для получения надежных учетных данных, стоит это разрешить. Как минимум, следует включить политику Passkey (FIDO2), чтобы пользователи могли регистрировать ключи доступа и ключи безопасности, если они предпочитают их.
В этом разделе рассматриваются этапы 1-3.
У пользователей должно быть по крайней мере два метода проверки подлинности. При регистрации другого метода пользователь имеет доступный метод резервного копирования, если что-то происходит с основным методом, например при потере или краже устройства. Например, рекомендуется, чтобы пользователи регистрировали ключи как на телефоне, так и локально на своей рабочей станции в Windows Hello для бизнеса.
Примечание.
Всегда рекомендуется, чтобы пользователи зарегистрировали по крайней мере два метода проверки подлинности. Это гарантирует, что пользователь имеет метод резервного копирования, если что-то происходит с их основным методом, например в случаях потери устройства или кражи. Например, рекомендуется, чтобы пользователи регистрировали ключи доступа как на телефоне, так и локально на рабочей станции в Windows Hello для бизнеса.
Примечание.
Это руководство адаптировано для текущей поддержки ключей доступа в системе Microsoft Entra ID, включая ключи доступа, привязанные к устройствам, в приложении Microsoft Authenticator, а также на физических ключах безопасности. Идентификатор Microsoft Entra планирует добавить поддержку синхронизированных секретных ключей. Дополнительные сведения см. в общедоступной предварительной версии: расширение поддержки секретного ключа в идентификаторе Microsoft Entra. Это руководство будет обновлено, чтобы включить синхронизированные инструкции по ключу доступа после доступности. Например, многие организации могут получить пользу, полагаясь на синхронизацию на этапе 3 на предыдущей схеме, вместо того чтобы полностью создавать новые учетные данные.
Шаг 1: Проверка идентификации в процессе адаптации
Для удаленных пользователей, не доказавших свою личность, вовлечение в рабочий процесс предприятия представляет собой значительную проблему. Без надлежащей проверки удостоверения личности организация не может быть полностью уверена, что принимает на работу именно того человека, которого намеревалась. Microsoft Entra Verified ID может обеспечить удостоверение личности с высоким уровнем надежности. Организации могут работать с партнером по проверке удостоверений (IDV), чтобы проверить удостоверения новых удаленных пользователей в процессе подключения. После обработки государственного удостоверения личности пользователя, IDV может предоставить проверенное удостоверение личности, подтверждающее личность пользователя. Новый пользователь предоставляет этот проверенный ID в организацию найма, чтобы установить доверие и подтвердить, что организация принимает на работу правильного человека. Организации могут добавить Face Check с Microsoft Entra Verified ID, добавляющая уровень сопоставления лиц к процессу проверки, гарантируя, что доверенный пользователь предъявляет удостоверяющий идентификатор Verified ID в данный момент.
После подтверждения личности через процесс подтверждения новые сотрудники получают временный доступ (TAP), который они могут использовать для инициализации своего первого переносимого удостоверения.
Ознакомьтесь со следующими руководствами для настройки Проверенных учетных данных Microsoft Entra и выпуска TAP.
- Подключение новых удаленных сотрудников с помощью проверки идентификатора
- Использование Face Check с проверенными учетными данными Microsoft Entra для разблокировки масштабной проверки с высокой степенью надежности
- Включите политику временного доступа
Обратитесь к следующим ссылкам для получения сведений о лицензировании Проверенные учетные данные Microsoft Entra:
- Цены на идентификацию лиц с помощью проверенных учетных данных Microsoft Entra
- Планы и цены Microsoft Entra
Некоторые организации могут выбирать другие методы, кроме Microsoft Entra Verified ID, для регистрации пользователей и выдачи им первых учетных данных. Корпорация Майкрософт рекомендует тем организациям по-прежнему использовать TAP или другой способ, позволяющий пользователю подключиться без пароля. Например, можно подготовить ключи безопасности FIDO2 с помощью API Microsoft Graph.
Этап адаптации 2: Инициализация переносимых учетных данных
Чтобы помочь существующим пользователям перейти на учетные данные без пароля, устойчивые к фишингу, сначала определите, зарегистрированы ли ваши пользователи для традиционной многофакторной аутентификации. Пользователи, зарегистрированные с традиционными методами MFA, могут быть нацелены на политики регистрации без пароля, защищённые от фишинговых атак. Они могут использовать свою традиционную многофакторную аутентификацию (MFA) для регистрации первых переносимых учетных данных, устойчивых к фишингу, а затем по мере необходимости перейти к регистрации локальных учетных данных.
Для новых пользователей или пользователей без многофакторной аутентификации оформите временный пропуск доступа (TAP). Вы можете выдать TAP так же, как предоставляете новым пользователям их первые учетные данные, или с помощью интеграции с Microsoft Entra Verified ID. После того как пользователи получают TAP, они готовы приступить к созданию своих первых учетных данных, устойчивых к фишингу.
Важно, чтобы первые учетные данные пользователя без пароля были переносимыми учетными данными, которые можно использовать для проверки подлинности на других вычислительных устройствах. Например, ключи доступа можно использовать для локальной проверки подлинности на телефоне iOS, но их также можно использовать для проверки подлинности на компьютере с Windows с помощью потока проверки подлинности между устройствами. Эта межустройствовая функциональность позволяет использовать переносимый ключ доступа для настройки Windows Hello для бизнеса на компьютере с Windows.
Кроме того, важно, чтобы каждое устройство, на которое пользователь регулярно работал, имеет локальные учетные данные, чтобы предоставить пользователю самый удобный пользовательский интерфейс. Локальные доступные учетные данные сокращают время, необходимое для проверки подлинности, так как пользователям не нужно использовать несколько устройств, и меньше шагов. Использование TAP из шага 1 для регистрации переносимых учетных данных, которые могут инициализировать эти другие учетные данные, позволяет пользователю использовать устойчивые к фишингу учетные данные нативно на многих устройствах, которые они могут иметь.
В следующей таблице перечислены рекомендации для разных пользователей:
| Пользователь Persona | Рекомендуемое переносимое удостоверение | Альтернативные переносимые учетные данные |
|---|---|---|
| Информационный работник | Passkey (приложение Authenticator) | Ключ безопасности, смарт-карта |
| Работник передней линии | Ключ безопасности | Passkey (приложение Authenticator), смарт-карта |
| ИТ-специалист или DevOps-инженер | Passkey (приложение Authenticator) | Ключ безопасности, смарт-карта |
| Строго регулируемый работник | Сертификат (смарт-карта) | Секретный ключ (приложение Authenticator), ключ безопасности |
Используйте следующее руководство, чтобы включить рекомендуемые и альтернативные переносимые учетные данные для соответствующих пользователей для вашей организации:
| Способ | Руководство |
|---|---|
| Ключи доступа | |
| Ключи безопасности | |
| Проверка подлинности на основе смарт-карт или сертификатов (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 для бизнеса | Ключ безопасного анклава SSO для платформы | Passkey (приложение Authenticator) | Passkey (приложение Authenticator) | N/A (вместо этого используйте переносимые учетные данные) |
| Строго регламентированный сотрудник | Windows Hello для бизнеса или CBA | Ключ безопасного анклава SSO платформы или CBA | Ключ доступа (приложение Authenticator) или CBA | Ключ доступа (приложение аутентификации) или CBA | N/A (вместо этого используйте смарт-карту) |
Используйте следующее руководство, чтобы включить рекомендуемые локальные учетные данные в вашей среде для соответствующих пользователей для вашей организации:
| Способ | Руководство |
|---|---|
| Windows Hello для бизнеса | |
| Ключ для защищенного анклава платформы SSO | |
| Ключи доступа |
Учитывания, связанные с персоной
Каждый сценарий использования имеет свои собственные проблемы и соображения, которые обычно возникают во время развертываний без паролей, устойчивых к фишинговым атакам. При определении того, какие лица необходимо разместить, следует учитывать эти факторы в планировании проекта развертывания. Следующие ссылки содержат конкретные рекомендации для каждого человека:
- Информационные работники
- Фронтовые работники
- ИТ-специалисты/сотрудники DevOps
- Строго регулируемые работники
Повышение использования учетных данных, устойчивых к фишингу
На этом шаге описывается, как упростить использование учетных данных, устойчивых к фишингу. Вы должны протестировать стратегию развертывания, запланировать развертывание и сообщить о плане конечным пользователям. Затем вы можете создавать отчеты и отслеживать ход выполнения, прежде чем применять учетные данные, устойчивые к фишинговым атакам, по всей организации.
Тестирование стратегии развертывания
Корпорация Майкрософт рекомендует протестировать стратегию развертывания, созданную на предыдущем шаге, с набором тестовых и пилотных пользователей. Этот этап должен включать следующие шаги:
- Создайте список тестовых пользователей и ранних пользователей. Эти пользователи должны представлять разные персоны пользователей, а не только ИТ-администраторов.
- Создайте группу идентификаторов Microsoft Entra и добавьте тестовых пользователей в группу.
- Включите политики методов проверки подлинности в Microsoft Entra ID и определите тестовую группу, которая будет ограничена методами, которые вы включаете.
- Оцените процесс развертывания регистрации у пилотных пользователей с помощью отчета активности методов аутентификации.
- Создайте политики условного доступа, чтобы обеспечить использование безпарольных учетных данных, стойких к фишингу, для каждого типа операционной системы и направьте их на вашу пилотную группу.
- Оценивайте успешность выполнения с помощью Azure Monitor и рабочих тетрадей.
- Собрать отзывы пользователей о результатах успешного развертывания.
Стратегия развертывания плана
Корпорация Майкрософт рекомендует управлять использованием на основе того, какие пользователи наиболее готовы к развертыванию. Как правило, это означает развертывание для пользователей в этом порядке, но это может измениться в зависимости от вашей организации:
- Информационные работники
- Фронтовые работники
- ИТ-специалисты/сотрудники DevOps
- Строго регулируемые работники
Используйте следующие разделы, чтобы создать коммуникации с конечными пользователями для каждой группы персонажей, определить область и развернуть функцию регистрации секретных ключей, а также для пользовательской отчетности и мониторинга хода развертывания.
Готовность к работе с книгой Phishing-Resistant без пароля (предварительная версия)
Организации могут при необходимости экспортировать журналы входа Microsoft Entra ID в Azure Monitor для долгосрочного хранения, охоты на угрозы и других целей. Корпорация Майкрософт выпустила рабочую тетрадь , которую организации с журналами в Azure Monitor могут использовать для помощи в различных этапах развертывания системы без паролей с защитой от фишинга. Phishing-Resistant Инструментарий без паролей можно получить здесь: aka.ms/PasswordlessWorkbook. Выберите рабочую книгу с заголовком Phishing-Resistant Развертывание без паролей (предварительная версия):
Книга содержит два основных раздела:
- Этап готовности регистрации
- Этап готовности к применению
Этап готовности регистрации
Перейдите на вкладку "Этап готовности регистрации", чтобы проанализировать журналы входа в вашей среде, определив, какие пользователи готовы к регистрации и какие пользователи не могут зарегистрироваться. Например, на вкладке «Этап готовности регистрации» можно выбрать iOS в качестве платформы ОС, а затем тип учетных данных "Ключ доступа приложения Authenticator", чтобы оценить вашу готовность. Затем можно щелкнуть на визуализациях рабочей книги, чтобы отфильтровать пользователей, у которых ожидаются проблемы с регистрацией, и экспортировать список.
Вкладка этапа готовности регистрации таблицы или документа может помочь оценить готовность к следующим операционным системам и данным учетной записи:
- Виндоус
- Windows Hello для бизнеса
- Ключ безопасности FIDO2
- Ключ доступа к приложению Authenticator
- Аутентификация / смарт-карта Certificate-Based
- macOS
- Ключ безопасного анклава для платформы
- Ключ безопасности FIDO2
- Ключ доступа к приложению Authenticator
- Certificate-Based Аутентификация/Смарт-карта
- iOS
- Ключ безопасности FIDO2
- Ключ доступа к приложению Authenticator
- Certificate-Based проверка подлинности / смарт-карта
- Android
- Ключ безопасности FIDO2
- Ключ доступа к приложению Authenticator
- Аутентификация / смарт-карта Certificate-Based
Используйте каждый экспортируемый список для сортировки пользователей, у которых могут возникнуть проблемы с регистрацией. Ответы на проблемы с регистрацией должны включать помощь пользователям в обновлении версий ОС устройства, замене стареющих устройств и выборе альтернативных учетных данных, где предпочтительный вариант не является жизнеспособным. Например, ваша организация может предоставить физические ключи безопасности FIDO2 пользователям Android 13, которые не могут использовать секретные ключи в приложении Microsoft Authenticator.
Аналогичным образом используйте отчет о готовности к обучению, чтобы помочь вам в создании списков пользователей, готовых начать коммуникации и кампании по регистрации, в соответствии с вашей общей стратегией развертывания .
Этап готовности к применению
Первым шагом этапа готовности к применению является создание политики условного доступа в режиме Report-Only. Эта политика будет заполнять журналы входа данными о том, был бы ли доступ заблокирован, если бы вы включили пользователей или устройства в рамки применения мер защиты от фишинга. Создайте новую политику условного доступа в клиенте с помощью следующих параметров:
| Настройки | Ценность |
|---|---|
| Назначение пользователей или групп | Все пользователи, за исключением учетных записей с разрывом стекла |
| Назначение приложений | Все ресурсы |
| Предоставление прав управления | Требовать степень проверки подлинности — фишингозащищенная многофакторная проверка подлинности |
| Включить политику | Только отчет |
Создайте эту политику как можно раньше в процессе развертывания, желательно до начала кампании по регистрации. Это гарантирует, что у вас есть хороший исторический набор данных о том, какие пользователи и входы были бы заблокированы политикой, если бы она была применена.
Затем используйте рабочую тетрадь для анализа того, где пары пользователей и устройств готовы к внедрению. Скачайте списки пользователей, готовых к принудительному применению, и добавьте их в группы, созданные в соответствии с политиками принудительного применения. Начните с выбора политики условного доступа только для чтения в фильтре политики:
Отчет предоставит вам список пользователей, которые смогли бы успешно соответствовать требованию парольной безопасности с защитой от фишинга на каждой платформе устройства. Скачайте каждый список и разместите соответствующих пользователей в группу контроля, которая соответствует платформе устройства.
Повторяйте этот процесс с течением времени, пока не достигнете точки, в которой каждая группа принуждения содержит большинство или всех пользователей. В конечном итоге вы сможете включить политику только для отчетов, чтобы обеспечить принудительное применение для всех пользователей и платформ устройств в клиенте. После достижения этого состояния можно удалить отдельные политики принудительного применения для каждой ОС устройства, уменьшая количество необходимых политик условного доступа.
Исследование пользователей, не готовых к реализации
Используйте вкладку дальнейшего анализа данных, чтобы изучить, почему некоторые пользователи не готовы к применению на различных платформах. Выберите поле политика не выполнена, чтобы фильтровать данные до входов пользователей, которые были бы заблокированы отчетной политикой условного доступа.
Используйте данные, предоставленные в этом отчете, чтобы определить, какие пользователи оказались бы заблокированы, на каких ОС устройств они находились, какие клиентские приложения они использовали, и к каким ресурсам они пытались получить доступ. Эти данные помогут вам нацеливаться на пользователей разными способами исправления или регистрации, чтобы они могли быть эффективно включены в процесс осуществления.
Планирование коммуникаций с конечными пользователями
Корпорация Майкрософт предоставляет шаблоны связи для конечных пользователей. Материал развертывания аутентификации включает настраиваемые шаблоны электронной почты для информирования пользователей о развертывании устойчивой к фишингу аутентификации без пароля. Используйте следующие шаблоны для общения с пользователями, чтобы они понимали защиту от фишинга при безпарольном развертывании:
- ключи доступа для службы поддержки
- Ключи доступа появятся в ближайшее время
- Регистрация ключа доступа в приложении Authenticator
- Напоминание о регистрации для использования ключа доступа в приложении Authenticator
Обмен данными должен повторяться несколько раз, чтобы помочь поймать максимальное количество пользователей. Например, ваша организация может выбрать общение о различных этапах и временных рамках по следующему шаблону:
- 60 дней до вступления в силу: сообщите о значении методов аутентификации, устойчивых к фишингу, и поощряйте пользователей заранее регистрироваться.
- 45 дней после принудительного применения: повторение сообщения
- Через 30 дней начнется применение фишинг-устойчивых мер: сообщение о том, что через 30 дней начнется такое применение, поощряйте пользователей заблаговременно зарегистрироваться.
- За 15 дней до начала принудительного применения: повторно отправьте сообщение, сообщите им, как связаться со службой технической поддержки.
- за 7 дней до вступления в силу: повторно отправьте сообщение, проинформируйте их о способах обращения в службу технической поддержки
- 1 день до начала принудительного применения: сообщите им, что принудительное применение начнется через 24 часа, сообщите им, как обратиться в службу технической поддержки.
Корпорация Майкрософт рекомендует взаимодействовать с пользователями через другие каналы за пределами только электронной почты. Другие варианты могут включать сообщения в Microsoft Teams, плакаты в комнате отдыха и программы амбассадоров, где выбранные сотрудники обучены выступать за программу для своих коллег.
Создание отчетов и мониторинг
Используйте ранее описанную Phishing-Resistant Безпарольную рабочую тетрадь, чтобы помочь с мониторингом и отчитыванием о развертывании. Кроме того, используйте отчеты, рассмотренные ниже, или положитесь на них, если вы не можете использовать учебник без паролей Phishing-Resistant.
Отчеты Microsoft Entra ID (например, Деятельность методов аутентификации и Сведения о событии входа для многофакторной аутентификации Microsoft Entra) предоставляют технические и бизнес-аналитические сведения, которые помогают оценивать и стимулировать внедрение.
На панели мониторинга действий методов проверки подлинности можно просмотреть регистрацию и использование.
- Регистрация показывает количество пользователей, способных на аутентификацию без паролей, устойчивую к фишингу, и другие методы аутентификации. Вы можете увидеть графики, показывающие, какие методы проверки подлинности зарегистрировали пользователи, и недавнюю регистрацию для каждого метода.
- Использование показывает, какие методы проверки подлинности использовались для входа.
Владельцы бизнес-приложений и технических приложений должны нести ответственность и получать отчеты на основе требований организации.
- Отслеживайте развертывание учетных данных, не требующих пароля и устойчивых к фишингу, с помощью отчетов о действиях регистрации методов аутентификации.
- Отслеживайте использование устойчивых к фишингу методик без пароля с помощью отчетов и журналов активности входа методов аутентификации.
- Используйте отчет о действиях входа, чтобы отслеживать методы проверки подлинности, используемые для входа в различные приложения. Выберите строку пользователя; Выберите "Сведения о проверке подлинности", чтобы просмотреть метод проверки подлинности и соответствующее действие входа.
Идентификатор Microsoft Entra добавляет записи в журналы аудита при возникновении следующих условий:
- Администратор изменяет методы проверки подлинности.
- Пользователь изменяет свои учетные данные в идентификаторе Microsoft Entra.
Идентификатор Microsoft Entra сохраняет большинство данных аудита в течение 30 дней. Мы рекомендуем более длительное хранение для аудита, анализа тенденций и других бизнес-потребностей.
Откройте доступ к данным аудита в Центре администрирования Microsoft Entra или API и загрузите в свои системы анализа. Если требуется более длительное хранение, экспортируйте и обрабатывайте журналы в системе управления информацией и событиями безопасности (SIEM), например в Microsoft Sentinel, Splunk или Sumo Logic.
Мониторинг объема запросов в службу технической поддержки
Служба IT-поддержки может предоставить ценный сигнал о том, насколько хорошо продвигается развертывание, поэтому корпорация Майкрософт рекомендует отслеживать объем билетов службы поддержки при выполнении устойчивого к фишингу безпарольного развертывания.
По мере увеличения объема запросов в службу поддержки вы должны замедлить темпы развертывания, связь с пользователями и меры принудительного характера. По мере уменьшения объема билетов вы можете вновь активизировать эти мероприятия. Этот подход требует обеспечения гибкости в плане развертывания.
Например, можно выполнить развертывания, а затем осуществлять их поэтапно, используя диапазоны дат, а не конкретные даты.
- 1-15 июня: развертывание и кампании по регистрации для первой волны
- 16–30 июня: внедрение системы и кампании по регистрации для второй группы
- 1-15 июля: развертывание и регистрационные кампании для 3-й волны
- С 16 по 31 июля: активация принуждения первой волны
- С 1 по 15 августа: включение механизма принудительного выполнения для когорты 2 волны
- 16 августа-31 августа: Включено принудительное соблюдение для третьей волны когорты
При выполнении этих различных этапов может потребоваться замедлить работу в зависимости от объема открытых заявок в службу технической поддержки, а затем возобновить работу, когда наплыв билетов уменьшится. Чтобы реализовать эту стратегию, корпорация Майкрософт рекомендует создать группу безопасности Microsoft Entra ID для каждой волны и добавить каждую группу в политики по одной за раз. Этот подход помогает избежать перегрузки ваших команд поддержки.
Применение методов, устойчивых к фишингу для входа
В этом разделе рассматривается этап 4.
схема 
Последний этап развертывания технологии без паролей, устойчивой к фишингу, заключается в обеспечении использования учетных данных, защищенных от фишинга. Основной механизм для этого в Microsoft Entra ID — уровни проверки подлинности условного доступа. Корпорация Майкрософт рекомендует применять меры принуждения для каждой роли на основе методологии пары пользователь/устройство. Например, развертывание принудительного применения может соответствовать следующему шаблону:
- Информационные работники в Windows и iOS
- Информационные работники в macOS и Android
- ИТ-специалисты в iOS и Android
- FLWs в iOS и Android
- FLWs в Windows и macOS
- ИТ-специалисты в Windows и macOS
Корпорация Майкрософт рекомендует создать отчет обо всех парах пользователей и устройств с помощью данных входа из клиента. Вы можете использовать такие средства запроса, как Azure Monitor и Рабочие тетради. По крайней мере попробуйте определить все пары пользователей и устройств, соответствующие этим категориям.
Используйте ранее описанную Phishing-Resistant рабочую тетрадь без пароля, чтобы помочь в этапе принудительного выполнения, если возможно.
Для каждого пользователя создайте список операционных систем, которые они регулярно используют для работы. Сопоставьте список с готовностью к применению устойчивого к фишингу входа для этой пары пользователь/устройство.
| Тип ОС | Готово к принудительному применению | Не готов к принудительному применению |
|---|---|---|
| Windows | 10+ | 8.1 и более ранние версии Windows Server |
| iOS | 17 и выше | 16 и более ранние |
| Android | 14+ | 13 и более ранние |
| macOS | 13+ (Вентура) | 12 и ранее |
| VDI (виртуальная рабочая инфраструктура) | Зависитот 1 | Зависитот 1 |
| Другие | Зависитот 1 | Зависитот 1 |
1Для каждой пары пользователя и устройства, где версия устройства не сразу готова к принудительному применению, определите, как решать необходимость обеспечения защиты от фишинга. Рассмотрим следующие варианты для старых операционных систем, инфраструктуры виртуальных рабочих столов (VDI) и других операционных систем, таких как Linux:
- Обеспечение защиты от фишинга с помощью внешних устройств — ключи безопасности FIDO2
- Принудительное применение фишингового сопротивления с помощью внешнего оборудования — смарт-карт
- Обеспечьте защиту от фишинга с помощью удаленных учетных данных, таких как ключи доступа, в процессе аутентификации между устройствами.
- Применение защиты от фишинга с помощью удаленных учетных данных внутри туннелей RDP (особенно для VDI)
Ключевая задача — с помощью данных определить, какие пользователи и персоны готовы к применению мер на определенных платформах. Начните принудительные меры на парах пользователей и устройств, которые готовы к их применению, чтобы "остановить негативные последствия" и уменьшить количество фишинговой аутентификации в вашей среде.
Затем перейдите к другим сценариям, где пары пользователей и устройств требуют усилий по готовности. Пройдите по списку пар пользователей и устройств, пока не будете применять устойчивую к фишингу аутентификацию повсеместно.
Создайте набор групп Microsoft Entra ID для поэтапного внедрения принудительных мер. Повторно используйте группы из предыдущего шага, если вы использовали метод развертывания, основанный на волнах.
Рекомендуемые политики применения условного доступа
Нацеливайте каждую группу с конкретной политикой условного доступа. Этот подход помогает постепенно развертывать средства управления для исполнения политики по парам пользователь/устройство.
| Политика | Имя группы, на которое нацелена политика | Политика — условие платформы устройства | Политика — предоставление контроля |
|---|---|---|---|
| 1 | Пользователи Windows, готовые к безопасной аутентификации без паролей, защищённой от фишинга | Windows | Требовать усиленной аутентификации — многофакторная аутентификация, защищенная от фишинга |
| 2 | пользователи macOS, готовые к безпарольной защите от фишинга | macOS | Требовать степень проверки подлинности — фишингозащищенная MFA |
| 3 | Пользователи iOS, готовые к использованию безпарольной аутентификации и устойчивые к фишингу | iOS | Требовать степень проверки подлинности — фишингозащищенная MFA |
| 4 | Пользователи Android, готовые к использованию без пароля и устойчивые к фишингу | Android | Требуется высокая степень аутентификации — устойчивая к фишингу многофакторная аутентификация |
| 5 | Другие пользователи, готовые к безпарольным фишингоустойчивым системам | Любые, кроме Windows, macOS, iOS или Android | Требовать степень проверки подлинности — фишингозащищенная MFA |
Добавьте каждого пользователя в каждую группу в зависимости от того, готово ли их устройство и операционная система, или если у них нет устройства этого типа. В конце развертывания каждый пользователь должен находиться в одной из групп.
Реагирование на риск для пользователей без пароля
Защита идентификации Microsoft Entra помогает организациям обнаруживать, исследовать и устранять риски, связанные с идентификацией. Защита идентификации Microsoft Entra предоставляет важные и полезные обнаружения для пользователей даже после перехода на использование фишинговых учетных данных без пароля. Например, некоторые соответствующие обнаружения для пользователей, устойчивых к фишингу:
- Действия, выполняемые с анонимных IP-адресов
- Администратор подтвердил, что пользователь был скомпрометирован
- Аномальный токен
- Вредоносный IP-адрес
- Аналитика угроз Microsoft Entra
- Подозрительный браузер
- Злоумышленник в середине
- Возможная попытка доступа к основному токену обновления
- И другие: обнаружения рисков, сопоставленные с типом события риска
Корпорация Майкрософт рекомендует клиентам сервиса Microsoft Entra ID Protection выполнять следующие действия, чтобы оптимально защитить пользователей, устойчивых к фишингу и использующих аутентификацию без пароля:
- Ознакомьтесь с руководством по развертыванию Защита идентификации Microsoft Entra. Планирование развертывания защиты идентификаторов
- Настройка журналов рисков для экспорта в SIEM
- Изучите и примите меры в отношении любого среднего риска пользователя.
- Настройка политики условного доступа для блокировки пользователей с высоким риском
После развертывания Microsoft Entra ID Защита рассмотрите возможность использования защиты токенов условного доступа. При входе пользователей с помощью устойчивых к фишингу учетных данных без пароля, атаки и обнаружения продолжают развиваться. Например, когда учетные данные пользователя больше не могут быть легко перехвачены с помощью фишинга, злоумышленники могут попытаться эксфильтровать токены с пользовательских устройств. Защита маркеров помогает снизить этот риск путем привязки маркеров к оборудованию устройства, на которое они были выданы.