Надежность проверки подлинности условного доступа
Уровень проверки подлинности — это элемент управления условным доступом, указывающий, какие сочетания методов проверки подлинности можно использовать для доступа к ресурсу. Пользователи могут удовлетворить требования к силе, выполнив проверку подлинности с помощью любой из разрешенных комбинаций.
Например, для доступа к конфиденциальному ресурсу могут потребоваться только методы проверки подлинности, устойчивые к фишингу. Чтобы получить доступ к нечувствительному ресурсу, администраторы могут создать другую силу проверки подлинности, которая позволяет использовать менее безопасные сочетания многофакторной проверки подлинности (MFA), например пароль и текстовое сообщение.
Надежность проверки подлинности основана на политике методов проверки подлинности, где администраторы могут область методы проверки подлинности для определенных пользователей и групп, которые будут использоваться в федеративных приложениях Microsoft Entra ID. Уровень проверки подлинности позволяет дополнительно контролировать использование этих методов на основе определенных сценариев, таких как доступ к конфиденциальным ресурсам, риск пользователя, расположение и многое другое.
Сценарии для сильных сторон проверки подлинности
Преимущества проверки подлинности могут помочь клиентам решить следующие сценарии:
- Для доступа к конфиденциальному ресурсу требуются определенные методы проверки подлинности.
- Требуется определенный метод проверки подлинности, когда пользователь принимает конфиденциальное действие в приложении (в сочетании с контекстом проверки подлинности условного доступа).
- Требовать, чтобы пользователи использовали определенный метод проверки подлинности при доступе к конфиденциальным приложениям за пределами корпоративной сети.
- Требовать более безопасные методы проверки подлинности для пользователей с высоким риском.
- Требовать определенные методы проверки подлинности от гостевых пользователей, которые получают доступ к клиенту ресурсов (в сочетании с параметрами между клиентами).
Сильные стороны проверки подлинности
Администратор istrators может указать силу проверки подлинности для доступа к ресурсу, создав политику условного доступа с помощью Требовать контроль надежности проверки подлинности. Они могут выбирать из трех встроенных сильных сторон проверки подлинности: многофакторная проверка подлинности, надежность MFA без пароля и устойчивость к фишингу MFA. Они также могут создать настраиваемую силу проверки подлинности на основе сочетаний методов проверки подлинности, которые они хотят разрешить.
Встроенные преимущества проверки подлинности
Встроенные преимущества проверки подлинности — это сочетания методов проверки подлинности, которые предопределяются корпорацией Майкрософт. Встроенные возможности проверки подлинности всегда доступны и не могут быть изменены. Корпорация Майкрософт обновит встроенные преимущества проверки подлинности, когда новые методы становятся доступными.
Например, встроенная устойчивость к фишингу MFA позволяет использовать следующие сочетания:
Windows Hello для бизнеса
Or
Ключ безопасности FIDO2
Or
Проверка подлинности на основе сертификатов Microsoft Entra (Multifactor)
Сочетания методов проверки подлинности для каждой встроенной силы проверки подлинности перечислены в следующей таблице. Эти сочетания включают методы, которые должны быть зарегистрированы пользователями и включены в политике методов проверки подлинности или устаревшей политике параметров MFA.
- Сила MFA — тот же набор сочетаний, которые можно использовать для удовлетворения параметра многофакторной проверки подлинности .
- Надежность MFA без пароля — включает методы проверки подлинности, удовлетворяющие MFA, но не требуют пароля.
- Устойчивость к фишингу MFA — включает методы, требующие взаимодействия между методом проверки подлинности и поверхностью входа.
| Сочетание методов проверки подлинности | Сила MFA | Сила MFA без пароля | Устойчивость к фишингу MFA |
|---|---|---|---|
| Ключ безопасности FIDO2 | ✅ | ✅ | ✅ |
| Windows Hello для бизнеса | ✅ | ✅ | ✅ |
| Проверка подлинности на основе сертификатов (Multi-Factor) | ✅ | ✅ | ✅ |
| Microsoft Authenticator (вход Телефон) | ✅ | ✅ | |
| Временный проход доступа (однократное использование и многопользовать) | ✅ | ||
| Пароль + то, что у вас есть1 | ✅ | ||
| Федеративный однофактор + то, что у вас есть1 | ✅ | ||
| Федеративный многофактор | ✅ | ||
| Проверка подлинности на основе сертификатов (однофакторная проверка подлинности) | |||
| Вход с помощью SMS | |||
| Пароль | |||
| Федеративный однофактор |
1 То, что у вас есть, относится к одному из следующих методов: текстовое сообщение, голосовое сообщение, push-уведомление, программного токена OATH или аппаратный токен OATH.
Следующий вызов API можно использовать для перечисления определений всех встроенных преимуществ проверки подлинности:
GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?$filter=policyType eq 'builtIn'
Условный доступ Администратор istrator также может создавать пользовательские сильные стороны проверки подлинности для точного соответствия требованиям к доступу. Дополнительные сведения см. в статье о преимуществах проверки подлинности пользовательского условного доступа.
Ограничения
Политики условного доступа оцениваются только после первоначальной проверки подлинности. В результате сила проверки подлинности не ограничивает начальную проверку подлинности пользователя. Предположим, что вы используете встроенную устойчивость к фишингу MFA. Пользователь по-прежнему может вводить свой пароль, но он должен войти с помощью фишингового метода, например ключа безопасности FIDO2, прежде чем они смогут продолжить работу.
Требовать многофакторную проверку подлинности и требовать силу проверки подлинности нельзя использовать вместе в одной политике условного доступа. Эти два элемента управления условного доступа не могут использоваться вместе, так как встроенная многофакторная проверка подлинности эквивалентна элементу управления "Требовать многофакторную проверку подлинности".
Методы проверки подлинности, которые в настоящее время не поддерживаются силой проверки подлинности. Метод однократной проверки подлинности электронной почты (гостевой) не включается в доступные сочетания.
Windows Hello для бизнеса. Если пользователь вошел в систему с помощью Windows Hello для бизнеса в качестве основного метода проверки подлинности, его можно использовать для удовлетворения требования к надежности проверки подлинности, включая Windows Hello для бизнеса. Однако если пользователь вошел в систему с помощью другого метода, например пароля в качестве основного метода проверки подлинности, и для проверки подлинности требуется Windows Hello для бизнеса, они не будут запрашивать вход с помощью Windows Hello для бизнеса. Пользователь должен перезапустить сеанс, выбрать параметры входа и выбрать метод, необходимый для проверки подлинности.
Известные проблемы
Дополнительные параметры ключа безопасности FIDO2. Дополнительные параметры не поддерживаются для внешних пользователей с домашним клиентом, расположенным в другом облаке Майкрософт, чем клиент ресурсов.
В колонке "Надежность проверки подлинности" двойное представление — учетные данные платформы, такие как Windows Hello для бизнеса и учетные данные платформы для macOS, представлены в силе проверки подлинности в Windows Hello for Business. Чтобы настроить настраиваемую силу проверки подлинности, которая позволяет использовать учетные данные платформы для macOS, используйте Windows Hello For Business.
Вопросы и ответы
Следует ли использовать силу проверки подлинности или политику методов проверки подлинности?
Надежность проверки подлинности основана на политике методов проверки подлинности. Политика методов проверки подлинности помогает область и настраивать методы проверки подлинности для использования в идентификаторе Microsoft Entra определенными пользователями и группами. Сила проверки подлинности позволяет другим ограничениям методов для определенных сценариев, таких как доступ к конфиденциальным ресурсам, риск пользователя, расположение и многое другое.
Например, администратор Contoso хочет разрешить пользователям использовать Microsoft Authenticator с push-уведомлениями или режимом проверки подлинности без пароля. Администратор переходит в параметры Microsoft Authenticator в политике методов проверки подлинности, область политику для соответствующих пользователей и задает режимпроверки подлинности any.
Затем для наиболее конфиденциального ресурса Contoso администратор хочет ограничить доступ только к методам проверки подлинности без пароля. Администратор создает новую политику условного доступа, используя встроенную силу MFA без пароля.
В результате пользователи в Contoso могут получить доступ к большинству ресурсов в клиенте с помощью пароля и push-уведомлений из Microsoft Authenticator ИЛИ только с помощью Microsoft Authenticator (вход телефона). Однако, когда пользователи в клиенте получают доступ к конфиденциальному приложению, они должны использовать Microsoft Authenticator (вход по телефону).
Необходимые компоненты
- Идентификатор Microsoft Entra ID P1 . Клиент должен иметь лицензию Microsoft Entra ID P1 для использования условного доступа. При необходимости можно включить бесплатную пробную версию.