Надежность проверки подлинности условного доступа
Уровень проверки подлинности — это элемент управления условным доступом, указывающий, какие сочетания методов проверки подлинности можно использовать для доступа к ресурсу. Пользователи могут удовлетворить требования к силе, выполнив проверку подлинности с помощью любой из разрешенных комбинаций.
Например, для доступа к конфиденциальному ресурсу могут потребоваться только методы проверки подлинности, устойчивые к фишингу. Чтобы получить доступ к нечувствительному ресурсу, администраторы могут создать другую силу проверки подлинности, которая позволяет использовать менее безопасные сочетания многофакторной проверки подлинности (MFA), например пароль и текстовое сообщение.
Сила проверки подлинности основана на политике методов проверки подлинности, где администраторы могут применять методы проверки подлинности для определенных пользователей и групп, которые будут использоваться в федеративных приложениях Microsoft Entra ID. Уровень проверки подлинности позволяет дополнительно контролировать использование этих методов на основе определенных сценариев, таких как доступ к конфиденциальным ресурсам, риск пользователя, расположение и многое другое.
Сценарии для сильных сторон проверки подлинности
Преимущества проверки подлинности могут помочь клиентам решить следующие сценарии:
- Для доступа к конфиденциальному ресурсу требуются определенные методы проверки подлинности.
- Требуется определенный метод проверки подлинности, когда пользователь принимает конфиденциальное действие в приложении (в сочетании с контекстом проверки подлинности условного доступа).
- Требовать, чтобы пользователи использовали определенный метод проверки подлинности при доступе к конфиденциальным приложениям за пределами корпоративной сети.
- Требовать более безопасные методы проверки подлинности для пользователей с высоким риском.
- Требовать определенные методы проверки подлинности от гостевых пользователей, которые получают доступ к клиенту ресурсов (в сочетании с параметрами между клиентами).
Сильные стороны проверки подлинности
Администраторы могут указать силу проверки подлинности для доступа к ресурсу, создав политику условного доступа с помощью элемента управления "Требовать надежность проверки подлинности". Они могут выбирать из трех встроенных сильных сторон проверки подлинности: многофакторная проверка подлинности, надежность 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'
Администраторы условного доступа также могут создавать настраиваемые преимущества проверки подлинности, чтобы точно соответствовать требованиям к доступу. Дополнительные сведения см. в статье о преимуществах проверки подлинности пользовательского условного доступа.
Ограничения
Политики условного доступа оцениваются только после первоначальной проверки подлинности. В результате сила проверки подлинности не ограничивает начальную проверку подлинности пользователя. Предположим, что вы используете встроенную устойчивость к фишингу MFA. Пользователь по-прежнему может вводить свой пароль, но он должен войти с помощью фишингового метода, например ключа безопасности FIDO2, прежде чем они смогут продолжить работу.
Требовать многофакторную проверку подлинности и требовать силу проверки подлинности нельзя использовать вместе в одной политике условного доступа. Эти два элемента управления условного доступа не могут использоваться вместе, так как встроенная многофакторная проверка подлинности эквивалентна элементу управления "Требовать многофакторную проверку подлинности".
Методы проверки подлинности, которые в настоящее время не поддерживаются силой проверки подлинности. Метод однократной проверки подлинности электронной почты (гостевой) не включается в доступные сочетания.
Windows Hello для бизнеса. Если пользователь вошел в систему с помощью Windows Hello для бизнеса в качестве основного метода проверки подлинности, его можно использовать для удовлетворения требования к надежности проверки подлинности, включая Windows Hello для бизнеса. Однако если пользователь вошел в систему с помощью другого метода, например пароля в качестве основного метода проверки подлинности, и для проверки подлинности требуется Windows Hello для бизнеса, они не будут запрашивать вход с помощью Windows Hello для бизнеса. Пользователь должен перезапустить сеанс, выбрать параметры входа и выбрать метод, необходимый для проверки подлинности.
Известные проблемы
Интенсивность проверки подлинности и частота входа. Если ресурсу требуется проверка подлинности и частота входа, пользователи могут удовлетворять оба требования в два разных раза.
Например, предположим, что ресурсу требуется секретный ключ (FIDO2) для обеспечения надежности проверки подлинности и частота входа в 1 час. 24 часа назад пользователь вошел с помощью секретного ключа (FIDO2) для доступа к ресурсу.
Когда пользователь разблокирует устройство Windows с помощью Windows Hello для бизнеса, он снова сможет получить доступ к ресурсу. Вчерашний вход удовлетворяет требованиям к надежности проверки подлинности, и сегодняшнее устройство разблокирует требование частоты входа.
В колонке "Надежность проверки подлинности" двойное представление — учетные данные платформы, такие как 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 для использования условного доступа. При необходимости можно включить бесплатную пробную версию.