Многофакторная аутентификация и условный доступ

Кража учётных данных — основная причина нарушений безопасности в облаке. Пароль можно выманить с помощью фишинга, подобрать перебором или получить из утечки данных стороннего сервиса. Многофакторная аутентификация (MFA) требует дополнительного фактора проверки, которым злоумышленник с малой вероятностью располагает даже после получения пароля, что значительно снижает риск несанкционированного доступа к вашей среде Azure.

Entra ID поддерживает несколько факторов проверки MFA. Самый безопасный и рекомендуемый вариант — приложение Microsoft Authenticator, которое поддерживает сопоставление номеров и push-уведомления. Другие варианты включают ключ безопасности FIDO2 (аппаратный токен), программный токен OATH, текстовое сообщение SMS или голосовой вызов. SMS и голосовые вызовы считаются менее безопасными и должны использоваться только как резервные варианты.

MFA в Entra ID можно включить с помощью трёх механизмов. Security по умолчанию — это бесплатный вариант, включаемый одним нажатием, который применяет MFA ко всем пользователям, но не поддерживает настройку. MFA для отдельных пользователей (устаревший вариант) включает MFA для определённых учётных записей пользователей. Рекомендуемый современный подход — политики Conditional Access (Entra ID P1/P2), которые требуют MFA только при выполнении заданных условий риска, уменьшая неудобства для пользователей при входе с низким уровнем риска.

Conditional Access (Entra ID P1) — это механизм политик «если — то»: если пользователь (или группа) пытается получить доступ к ресурсу при определённых условиях, то доступ предоставляется, блокируется или требуется выполнить дополнительные требования, например использовать MFA или соответствующее требованиям устройство. Условия могут включать удостоверение пользователя, соответствие устройства требованиям, IP-адрес, приложение, к которому осуществляется доступ, и оценку риска Entra ID Identity Protection.

Политика Conditional Access состоит из двух частей: назначений (к кому и чему применяется политика) и элементов управления доступом (что происходит при срабатывании политики). Назначения определяют пользователей и группы, облачные приложения, к которым осуществляется доступ, и условия (расположение, платформа устройства, риск входа). Элементы управления доступом определяют, следует ли предоставить доступ (при необходимости потребовав MFA, соответствующее требованиям устройство или одобренное приложение) или полностью заблокировать его.

Именованные расположения Conditional Access позволяют определить доверенные диапазоны IP-адресов (например, сеть корпоративного офиса) или страны. Распространённый шаблон политики: требовать MFA, когда пользователь входит в систему из-за пределов доверенного именованного расположения, но разрешать беспрепятственный вход из известного офисного IP-адреса. Это уменьшает неудобства для сотрудников на территории офиса и одновременно повышает безопасность для удалённых и путешествующих пользователей.

Conditional Access может требовать, чтобы устройство, с которого осуществляется доступ, было соответствующим требованиям (соответствовало политикам соответствия устройств Intune) или было гибридным корпоративным устройством, присоединённым к Azure AD. Это гарантирует, что даже при действительных учётных данных вход с личных или неуправляемых устройств будет заблокирован либо для него потребуется выполнить дополнительные требования. Элементы управления на основе устройств — важная составляющая модели безопасности нулевого доверия.

Entra ID Identity Protection (P2) использует машинное обучение для оценки каждого входа и присваивает ему оценку риска: низкую, среднюю или высокую. Факторы риска включают невозможное перемещение (вход из двух стран в течение нескольких минут), анонимный IP-адрес, утёкшие учётные данные и обнаружение перебора паролей. Политики Conditional Access могут срабатывать в зависимости от уровня риска — например, автоматически требовать MFA при среднем риске и блокировать доступ при высоком.

Перед применением политики Conditional Access можно установить для неё режим «Только отчёт». В этом режиме политика анализирует все входы и записывает, что произошло бы (доступ был бы предоставлен, заблокирован или потребовался бы MFA), но фактически не применяет элементы управления. Это позволяет проверить влияние политики на пользователей перед её включением и предотвратить неожиданные блокировки из-за неправильно заданных условий.

Инструмент «Что будет, если» на странице Conditional Access позволяет имитировать сценарий входа — указать пользователя, приложение, IP-адрес, платформу устройства и уровень риска — и посмотреть, какие политики будут применяться и каким будет их совокупный результат. Это незаменимый инструмент для устранения проблем с доступом и проверки того, что набор политик даёт ожидаемый результат для заданных пользователей и условий.

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

В этом уроке Вы узнали, что MFA требует второго фактора помимо пароля, значительно снижая риск кражи учётных данных, политики Conditional Access применяют правила предоставления или блокировки доступа на основе пользователя, приложения, расположения и условий риска, а Identity Protection использует оценку риска на основе машинного обучения для запуска автоматических элементов управления доступом. Далее мы рассмотрим единый вход и внешние удостоверения в Entra ID.