Создание устойчивой стратегии управления доступом с помощью идентификатора Microsoft Entra

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

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

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

Основное руководство

В этом документе четыре основных вывода:

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

Перед сбоем

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

Зачем вам нужно устойчивое управление доступом?

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

• Блокировка администратора: администраторы не могут управлять клиентом или службами.
• Блокировка пользователя: у пользователей нет доступа к приложениям и ресурсам.

Непредвиденный случай блокировки администратора

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

Уменьшение риска блокировки пользователя

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

Рекомендации корпорации Майкрософт

Включите в существующие политики условного доступа для организации следующие элементы управления доступом.

• Подготовьте несколько методов проверки подлинности для каждого пользователя, который использует различные каналы связи, например приложение Microsoft Authenticator (интернет-интерфейс), токен OATH (созданный на устройстве) и SMS (телефония).
• Разверните Windows Hello для бизнеса на устройствах Windows 10, чтобы соответствовать требованиям MFA непосредственно после входа в систему.
• Используйте доверенные устройства с помощью гибридного соединения Microsoft Entra или Microsoft Intune. Доверенные устройства улучшают взаимодействие с пользователем, так как само доверенное устройство может удовлетворить строгие требования к проверке подлинности политики без вызова MFA пользователю. Тогда MFA потребуется при регистрации нового устройства и при доступе к приложениям или ресурсам с ненадежных устройств.
• Вместо фиксированных политик многофакторной аутентификации (MFA) используйте политики на основе оценки рисков Защиты идентификаций Microsoft Entra, которые запрещают доступ, если существует риск для пользователя или входа.
• Если вы защищаете VPN-доступ с помощью расширения NPS многофакторной проверки подлинности Microsoft Entra, рассмотрите возможность федеративного VPN-решения в качестве приложения SAML и определите категорию приложений , как показано ниже.

В следующем примере описываются политики, которые вам необходимо создать, чтобы предоставить пользователю устойчивое управление доступом к своим приложениям и ресурсам. В этом примере вам нужна группа AppUsers безопасности с целевыми пользователями, которым вы хотите предоставить доступ, группа CoreAdmins с основными администраторами, и группа EmergencyAccess с учетными записями аварийного доступа. В этом примере набора политик выбранным пользователям в AppUsers будет предоставлен доступ к выбранным приложениям, если они подключаются с доверенного устройства или используют надежную проверку подлинности, например многофакторную аутентификацию (MFA). Это исключает учетные записи для аварийного доступа и основных администраторов.

Набор политик устранения рисков условного доступа:

• Политика 1. Блокировка доступа к пользователям за пределами целевых групп
  • Пользователи и группы: включает всех пользователей. исключает AppUsers, CoreAdmins и EmergencyAccess
  • Облачные приложения: включает все приложения
  • Условия: нет.
  • Управление доступом: блокировка
• Политика 2: предоставление доступа для AppUsers, требующих MFA или доверенного устройства.
  • Пользователи и группы: включает AppUsers. исключает CoreAdmins и EmergencyAccess
  • Облачные приложения: включает все приложения
  • Условия: нет.
  • Управление предоставлением: предоставление доступа, требование многофакторной проверки подлинности, требование соответствия устройства. Для нескольких элементов управления: требуется один из выбранных элементов управления.

Меры в случае блокировки пользователя

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

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

1. Заранее определите критически важные приложения: к каким приложениям необходимо предоставить доступ, даже с более низким состоянием риска или безопасности? Составьте список этих приложений и убедитесь, что все другие заинтересованные лица (бизнес, безопасность, юристы, руководство) согласны с тем, что если все управление доступом исчезнет, эти приложения все равно должны продолжать работу. Скорее всего, у вас в итоге будут такие категории:
   • Категория 1 критически важных приложений, которые не могут быть недоступны в течение более чем нескольких минут, например приложения , которые напрямую влияют на доход организации.
   • Категория 2 — важные приложения, которые должны быть доступны бизнесу в течение нескольких часов.
   • Категория 3 — приложения с низким приоритетом, которые могут выдержать сбой на несколько дней.
2. Для приложений категории 1 и 2 корпорация Майкрософт рекомендует предварительно спланировать тип доступа, который требуется разрешить:
   • Хотите ли вы разрешить полный доступ или ограниченный сеанс, например ограничение загрузок?
   • Хотите ли вы разрешить доступ к части приложения, но не ко всему приложению?
   • Хотите ли вы разрешить доступ информационному работнику и заблокировать доступ администратора, пока контроль доступа не будет восстановлен?
3. Для этих приложений Корпорация Майкрософт также рекомендует спланировать способы доступа, которые вы намеренно откроете и какие из них вы закроете:
   • Хотите ли вы разрешить лишь браузеру получать доступ и блокировать клиентов с расширенными возможностями, которые могут сохранять автономные данные?
   • Хотите ли вы разрешить доступ только для внутренних пользователей корпоративной сети и заблокировать внешних пользователей?
   • Хотите ли вы разрешить доступ из определенных стран или регионов только во время сбоев?
   • Хотите ли вы, чтобы политики на случай непредвиденных ситуаций, особенно для критически важных приложений, были успешными или проваливались, если недоступен альтернативный контроль доступа?

Рекомендации корпорации Майкрософт

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

• Настройте набор резервных политик, если нарушение доступа к одному типу учетных данных или одному механизму контроля доступа влияет на доступ к вашим приложениям. Настройте политику в режиме только отчетов, которая требует присоединения к домену в качестве элемента управления, в качестве резервной копии для активной политики, для которой требуется сторонний поставщик MFA.
• Уменьшите риск того, что злоумышленники угадают пароли, если MFA не требуется, следуя рекомендациям в руководстве по паролям.
• Разверните microsoft Entra Self-Service Password Reset (SSPR) и Microsoft Entra Password Protection , чтобы убедиться, что пользователи не используют общий пароль и условия, которые вы решили запретить.
• Используйте политики, ограничивающие доступ в приложениях, если определенный уровень проверки подлинности не достигнут, а не просто вернуться к полному доступу. Например:
  • Настройте политику резервного копирования, которая отправляет утверждение ограниченного сеанса в Exchange и SharePoint.
  • Если ваша организация использует Microsoft Defender for Cloud Apps, рассмотрите возможность переключения на запасную политику, которая задействует Defender for Cloud Apps и разрешает доступ только для чтения, но не для загрузки.
• Присвойте политикам название, чтобы легко найти их во время технологического сбоя. Включите следующие элементы в имя политики:
  • Номер метки для политики.
  • Текст для отображения: эта политика предназначена только для чрезвычайных ситуаций. Пример. ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ
  • Сбой, к которому оно относится. Пример: Во время сбоя в работе MFA.
  • Порядковый номер для указания порядка, в котором необходимо активировать политики.
  • Приложения, к которым он применяется.
  • Контролы, которые будут применяться.
  • Требуемые условия.

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

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

Следующий пример. Пример A — политика условного доступа на случай непредвиденных обстоятельств для восстановления доступа к критически важным приложениям для совместной работы является обычным корпоративным непредвиденным случаем. В этом сценарии организации обычно требуется многофакторная проверка подлинности для всех доступа Exchange Online и SharePoint Online, а нарушение в этом случае — поставщик MFA для клиента имеет сбой (будь то многофакторная проверка подлинности Microsoft Entra, локальный поставщик MFA или сторонний MFA). Эта политика устраняет этот сбой, позволяя конкретным целевым пользователям получать доступ к этим приложениям с доверенных устройств Windows только при доступе к приложению из доверенной корпоративной сети. Она также исключит из этих ограничений учетные записи для экстренных ситуаций и основных администраторов. Затем целевые пользователи получат доступ к Exchange Online и SharePoint Online, тогда как другие пользователи по-прежнему не будут иметь доступ к приложениям из-за сбоя. В этом примере требуется именованное сетевое расположение CorpNetwork и группа безопасности ContingencyAccess с целевыми пользователями, группа с именем CoreAdmins с основными администраторами и группа с именем EmergencyAccess с учетными записями аварийного доступа. На случай непредвиденных обстоятельств для обеспечения желаемого доступа необходимы четыре политики.

Пример A — политики условного доступа на случай непредвиденных обстоятельств для восстановления доступа к критически важным приложениям для совместной работы:

• Политика 1. Требовать присоединенные к домену устройства для Exchange и SharePoint
  • Имя: EM001 — ВКЛЮЧЕНИЕ В ЧРЕЗВЫЧАЙНОЙ СИТУАЦИИ: нарушение MFA[1/4] — Exchange SharePoint — требуется гибридное соединение Microsoft Entra
  • Пользователи и группы: включает доступ на случай непредвиденных обстоятельств. исключает CoreAdmins и EmergencyAccess
  • Облачные приложения: Exchange Online и SharePoint Online
  • Условия: любые
  • Предоставление контроля: требуется присоединение к домену
  • Состояние: только отчет
• Политика 2. Блокировка платформ, отличных от Windows
  • Имя: EM002 — АВАРИЙНОЕ ВКЛЮЧЕНИЕ: нарушение MFA [2/4] — Exchange SharePoint — блокировка доступа за исключением Windows.
  • Пользователи и группы: включает всех пользователей. исключает CoreAdmins и EmergencyAccess
  • Облачные приложения: Exchange Online и SharePoint Online
  • Условия: платформа устройства включает все платформы, кроме Windows
  • Управление доступом: блокировка
  • Состояние: только отчет
• Политика 3. Блокировка сетей, отличных от CorpNetwork
  • Имя: EM003 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ: нарушение MFA [3/4] — Exchange SharePoint — блокировка доступа, кроме корпоративной сети
  • Пользователи и группы: включает всех пользователей. исключает CoreAdmins и EmergencyAccess
  • Облачные приложения: Exchange Online и SharePoint Online
  • Условия: местоположения включают любое, за исключением CorpNetwork
  • Управление доступом: блокировка
  • Состояние: только отчет
• Политика 4. Явно блокировать EAS
  • Имя: EM004 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ: прерывание MFA [4/4] — Exchange — блокировка EAS для всех пользователей
  • Пользователи и группы: включает всех пользователей
  • Облачные приложения: включает Exchange Online
  • Условия: клиентские приложения: Exchange Active Sync
  • Предоставление управления: блокировка
  • Состояние: только отчет

Порядок активации:

1. Исключите ContingencyAccess, CoreAdmins и EmergencyAccess из существующей политики MFA. Убедитесь в том, что пользователь в ContingencyAccess может получить доступ к SharePoint Online и Exchange Online.
2. Включить политику 1: Убедитесь, что пользователи на устройствах, присоединенных к домену, которые не входят в группы исключений, могут получить доступ к Exchange Online и SharePoint Online. Убедитесь в том, что пользователи группы "Исключить" могут получить доступ к SharePoint Online и Exchange с любого устройства.
3. Включите политику 2. Проверьте, что пользователи, которые не входят в группу исключений, не могут получить доступ к SharePoint Online и Exchange Online с мобильных устройств. Убедитесь в том, что пользователи группы "Исключить" могут получить доступ к SharePoint и Exchange с любого устройства (Windows/iOS/Android).
4. Включите Политику 3: Проверьте, что пользователи, которые не входят в группы исключений, не могут получить доступ к SharePoint и Exchange с корпоративной сети, даже если они используют компьютер, присоединенный к домену. Убедитесь в том, что пользователи группы "Исключить" могут получить доступ к SharePoint и Exchange с любой сети.
5. Включение политики 4. Убедитесь, что все пользователи не могут получать Exchange Online из собственных почтовых приложений на мобильных устройствах.
6. Отключите существующую политику MFA для SharePoint Online и Exchange Online.

В этом примере пример В — политики условного доступа на случай непредвиденных обстоятельств, которые разрешают мобильный доступ к Salesforce, восстанавливается доступ бизнес-приложения. В этом сценарии клиенту обычно требуется, чтобы доступ сотрудников отдела продаж к Salesforce (настроенному для единого входа с помощью Microsoft Entra ID) с мобильных устройств разрешался только с соответствующих устройств. Нарушение в этом случае заключается в том, что существует проблема с оценкой соответствия устройств и сбой происходит в конфиденциальное время, когда команда продаж нуждается в доступе к Salesforce для закрытия сделок. Эти политики непредвиденных обстоятельств предоставляют критически важный доступ пользователей к Salesforce с мобильного устройства, чтобы они могли продолжать закрывать сделки и не нарушать бизнес. В этом примере SalesforceContingency содержит всех сотрудников отдела продаж, которым необходимо сохранить доступ, а SalesAdmins — необходимых администраторов Salesforce.

Пример B — политики условного доступа на случай непредвиденных обстоятельств:

• Политика 1. Блокировать всех, не входящих в команду SalesContingency
  • Имя: EM001 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ: нарушение соответствия устройства [1/2] — Salesforce — блокировка всех пользователей, кроме SalesforceContingency
  • Пользователи и группы: включает всех пользователей. исключает SalesAdmins и SalesforceContingency
  • Облачные приложения: Salesforce
  • Условия: Нет
  • Управление доступом: Блокировать
  • Состояние: только отчет
• Политика 2. Блокировать группу продаж от любой платформы, отличной от мобильных устройств (чтобы уменьшить область атаки)
  • Имя: EM002 — ВКЛЮЧЕНИЕ В АВАРИЙНОМ РЕЖИМЕ — нарушение соответствия устройства [2/2] — Salesforce — блокировка всех платформ, за исключением iOS и Android
  • Пользователи и группы: включите SalesforceContingency. Исключить SalesAdmins
  • Облачные приложения: Salesforce
  • Условия: платформа устройства включает все платформы, кроме iOS и Android
  • Управление доступом: блокировка
  • Состояние: только отчет

Порядок активации:

1. Исключите SalesAdmins и SalesforceContingency из существующей политики соответствия устройств для Salesforce. Убедитесь в том, что пользователь группы SalesforceContingency имеет доступ к Salesforce.
2. Активировать политику 1: Убедиться, что пользователи за пределами SalesContingency не имеют доступа к Salesforce. Убедитесь в том, что пользователи SalesAdmins и SalesforceContingency могут получить доступ к Salesforce.
3. Включите политику 2: Убедитесь, что пользователи группы SalesContingency не могут получить доступ к Salesforce с ноутбуков Windows или Mac, но могут получить доступ к нему с мобильных устройств. Убедитесь в том, что SalesAdmin может получить доступ к Salesforce с любого устройства.
4. Отключите существующую политику соответствия устройств для Salesforce.

Меры предосторожности на случай блокировки пользователей от локальных ресурсов (расширение NPS)

Если вы защищаете VPN-доступ с помощью расширения NPS многофакторной проверки подлинности Microsoft Entra, рассмотрите возможность федеративного VPN-решения в качестве приложения SAML и определите категорию приложений , как показано ниже.

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

В этом случае можно отключить расширение NPS, в результате сервер NPS будет проверять только первичную проверку подлинности и не будет применять MFA для пользователей.

Отключить расширение NPS:

• Экспортируйте ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters в качестве резервной копии.
• Удалите значения реестра для AuthorizationDLLs и ExtensionDLLs, но не для ключа параметров.
• Перезапустите службу сетевой политики (IAS), чтобы изменения вступили в силу.
• Определите, успешно ли выполнена основная проверка подлинности для VPN.

После восстановления службы и вы будете готовы снова применить MFA для пользователей, включите расширение NPS:

• Импортируйте ключ реестра из резервной копии HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters.
• Перезапустите службу сетевой политики (IAS), чтобы изменения вступили в силу.
• Определите, успешно ли выполнена первичная проверка подлинности и дополнительная проверка подлинности для VPN.
• Проверьте NPS-сервер и журнал VPN, чтобы определить, какие пользователи зарегистрировались в системе во время аварийного окна.

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

Блокировка пользователя также может произойти, если выполняются следующие условия.

• Ваша организация использует гибридное решение для идентификации со сквозной проверкой подлинности или федерацией.
• Ваши локальные системы идентификации (например, Active Directory, AD FS или зависимый компонент) недоступны.

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

Рекомендации корпорации Майкрософт

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

Во время сбоя

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

1. Включите ваши политики на случай непредвиденных обстоятельств, которые предоставляют целевым пользователям доступ к определенным приложениям из определенных сетей.
2. Отключите свои обычные политики на основе контроля.

Рекомендации корпорации Майкрософт

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

1. Документируйте каждое изменение и предыдущее состояние в рамках вашей стратегии управления изменениями, чтобы иметь возможность отменить любые меры, которые вы внедрили, как только управление доступом станет полностью функциональным.
2. Предположите, что злоумышленники попытаются добыть пароли с помощью атак на подбор паролей или фишинговых атак, в то время как MFA отключена. Кроме того, у злоумышленников уже могут быть пароли, которые ранее не предоставляли доступ ни к одному ресурсу, доступ к которому можно попытаться получить во время этого окна. Для руководителей и других критически важных пользователей вы можете частично снизить этот риск, предварительно сбросив их пароли перед отключением MFA.
3. Архивировать все действия по входу в систему, чтобы определить, кто к чему имеет доступ при отключенной MFA.
4. Рассмотрите все сообщения об обнаружении рисков, пока открыто это окно.

После сбоя

Отмените изменения, внесенные вами как часть активированного плана на непредвиденные случаи, после восстановления службы, которая вызвала сбой.

1. Включите регулярные политики.
2. Отключите политики на непредвиденные случаи и вернитесь обратно в режим "только отчеты".
3. Откатите любые другие изменения, которые вы сделали и задокументировали во время сбоя.
4. Если вы использовали учетную запись для аварийного доступа, не забудьте повторно создать учетные данные и физически защитить детали новых учетных данных как часть процедур учетной записи для аварийного доступа.
5. Продолжайте рассматривать все сообщения об обнаружении угроз после сбоя на предмет подозрительной активности.
6. Отмените все токены обновления, выданные для целевого набора пользователей. Отмена всех токенов обновления важна для привилегированных учетных записей, используемых во время сбоя. Это заставит их повторно пройти проверку подлинности и получить контроль над восстановленными политиками.

Параметры аварийного режима

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

• Если у вас есть исходящий IP-адрес корпоративной сети, вы можете добавить его в качестве доверенных IP-адресов, чтобы включить проверку подлинности только в корпоративной сети.
• Если у вас нет перечня исходящих IP-адресов или вам нужно включить доступ внутри и за пределами корпоративной сети, вы можете добавить все адресное пространство IPv4 в качестве доверенных IP-адресов, указав 0.0.0.0/1 и 128.0.0.0/1.

Подробнее

• документация по проверке подлинности Microsoft Entra
• Управление учетными записями администратора экстренного доступа в Microsoft Entra ID
• Настройка именованных расположений в Microsoft Entra ID
• Настройка гибридных устройств, присоединенных к Microsoft Entra
• Руководство по развертыванию Windows Hello для бизнеса
  • Password Guidance - Microsoft Research (Руководство о паролях — Microsoft Research)
• Каковы условия условного доступа Microsoft Entra?
• Что такое элементы управления доступом в условном доступе Microsoft Entra?
• Режим условного доступа "только отчет"