Планирование обязательной многофакторной проверки подлинности для Azure и других порталов администрирования

В Корпорации Майкрософт мы стремимся предоставить нашим клиентам наивысший уровень безопасности. Одним из наиболее эффективных мер безопасности, доступных для них, является многофакторная проверка подлинности (MFA). Исследования Корпорации Майкрософт показывают, что MFA может блокировать более 99.2% атак на компрометацию учетных записей.

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

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

Область применения

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

Приложения

В следующей таблице перечислены затронутые приложения, идентификаторы приложений и URL-адреса для Azure.

В следующей таблице перечислены затронутые приложения и URL-адреса для Microsoft 365.

Аккаунты

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

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

Удостоверения рабочей нагрузки, такие как управляемые удостоверения и субъекты-службы, не подвержены влиянию ни на один из этапов применения MFA. Если удостоверения пользователей используются для входа в систему в качестве служебной учетной записи для выполнения автоматизации (включая скрипты или другие автоматизированные задачи), эти удостоверения пользователей должны один раз пройти многофакторную аутентификацию (MFA), как только начнется её применение. Удостоверения пользователей не рекомендуется использовать для автоматизации. Эти удостоверения пользователей следует перенести в удостоверения для рабочих процессов.

Клиентские библиотеки

Поток выдачи токена по паролю владельца ресурса OAuth 2.0 (ROPC) несовместим с MFA. После включения MFA в клиенте Microsoft Entra, используемые в приложениях API на основе ROPC начинают вызывать исключения. Дополнительные сведения о миграции из API на основе ROPC в библиотеках проверки подлинности Майкрософт (MSAL) см. в статье "Как перейти из ROPC". Инструкции по MSAL для конкретного языка см. на следующих вкладках.

Те же общие рекомендации MSAL применяются к библиотекам удостоверений Azure. Класс UsernamePasswordCredential, предоставленный в этих библиотеках, использует API на основе MSAL ROPC. Инструкции по языку см. на следующих вкладках.

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

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

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

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

• Вход в Azure с использованием управляемого удостоверения через Azure CLI
• Вход в Azure с использованием учетной записи службы через Azure CLI
• Вход в Azure PowerShell в неинтерактивном режиме для сценариев автоматизации содержит рекомендации по использованию управляемого удостоверения и субъекта-службы.

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

Внедрение

Это требование для MFA при входе реализуется для порталов администрирования и других приложений. Журналы входа в Microsoft Entra ID показывают его как источник требования MFA.

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

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

Этапы принудительного применения

Применение MFA выполняется на двух этапах:

• Этап 1. Начиная с октября 2024 года, MFA требуется для входа на портал Azure, Центр администрирования Microsoft Entra и Центр администрирования Microsoft Intune. Принудительное применение постепенно коснется всех клиентов по всему миру. Начиная с февраля 2025 г. применение MFA постепенно начинается для входа в Центр администрирования Microsoft 365. Этот этап не влияет на другие клиенты Azure, такие как Azure CLI, Azure PowerShell, мобильное приложение Azure или средства IaC.

• Этап 2. Начиная с 1 июля 2025 г. применение MFA постепенно начнется для Azure CLI, Azure PowerShell, мобильного приложения Azure, средств IaC и конечных точек REST API. Некоторые клиенты могут использовать учетную запись пользователя в идентификаторе Microsoft Entra в качестве учетной записи службы. Рекомендуется мигрировать эти пользовательские учетные записи службы на безопасные облачные сервисные учетные записи с идентификациями рабочих нагрузок.

Каналы уведомлений

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

• Электронная почта: глобальные администраторы, которые настроили адрес электронной почты, будут проинформированы по электронной почте о предстоящем применении MFA и действиях, необходимых для подготовки.

• Уведомление о работоспособности службы: глобальные администраторы получают уведомление о работоспособности службы через портал Azure с идентификатором отслеживания 4V20-VX0. Это уведомление содержит те же сведения, что и электронная почта. Глобальные администраторы также могут подписаться на получение уведомлений о работоспособности службы по электронной почте.

• Уведомление на портале: уведомление появляется в портале Azure, в Центре администрирования Microsoft Entra и в Центре администрирования Microsoft Intune при входе. Ссылки в уведомлении портала ведут к этой теме для получения дополнительной информации об обязательном применении MFA.

• Центр сообщений Microsoft 365: сообщение отображается в центре сообщений Microsoft 365 с идентификатором сообщения: MC862873. Это сообщение содержит те же сведения, что и уведомление о работоспособности электронной почты и службы.

После принудительного применения баннер появится на портале Azure:

Внешние методы проверки подлинности и поставщики удостоверений

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

Если вы используете федеративного поставщика удостоверений (IdP), например службы федерации Active Directory (AD FS), и поставщик MFA интегрирован непосредственно с этим федеративным IdP, федеративный поставщик удостоверений должен быть настроен для отправки запроса MFA. Дополнительные сведения см. в разделе "Ожидаемые входящие утверждения" для Microsoft Entra MFA.

Запросите больше времени для подготовки к принудительному применению

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

Глобальные администраторы могут перейти к https://aka.ms/managemfaforazure, чтобы выбрать дату начала принудительного применения для своего клиента на порталах администрирования в рамках этапа 1. Если вы отложили дату начала этапа 1, принудительное применение этапа 2 не начинается до выбранной даты начала. Глобальные администраторы должны повысить уровень доступа и использовать MFA, прежде чем они смогут отложить дату начала применения MFA.

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

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

Вопросы и ответы

Вопрос: Если арендатор используется только для тестирования, требуется многофакторная аутентификация?

Ответ. Да, каждому клиенту Azure потребуется многофакторная проверка подлинности без исключения для тестовых сред.

Вопрос. Как это требование влияет на Центр администрирования Microsoft 365?

Ответ. Обязательный MFA будет развернут в Центре администрирования Microsoft 365, начиная с февраля 2025 года. Дополнительные сведения о обязательном требовании MFA для Центра администрирования Microsoft 365 см. в записи блога Об объявлении обязательной многофакторной проверки подлинности для Центра администрирования Microsoft 365.

Вопрос. Является ли MFA обязательным для всех пользователей или только администраторов?

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

Вопрос: Нужно ли выполнить многофакторную проверку подлинности, если выбрать параметр «Оставаться в системе»?

Ответ. Да, даже если вы выбрали "Оставаться в системе", необходимо выполнить MFA, прежде чем войти в эти приложения.

Вопрос: Применяются ли правила к гостевым учетным записям B2B?

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

Вопрос: Применяется ли это к Azure для правительства США или суверенных облаков Azure?

Ответ. Корпорация Майкрософт применяет обязательную MFA только в общедоступном облаке Azure. Корпорация Майкрософт в настоящее время не применяет MFA в Azure для государственных организаций США или других национальных облаков Azure.

Вопрос: Как мы можем соблюдать требования, если применяем MFA с помощью другого поставщика удостоверений или решения MFA, а не с использованием решения Microsoft Entra MFA?

Ответ. Сторонняя MFA может быть интегрирована непосредственно с идентификатором Microsoft Entra. Дополнительные сведения см. в справочнике по поставщику внешних методов многофакторной проверки подлинности Microsoft Entra. Идентификатор Microsoft Entra можно настроить при необходимости с помощью федеративного поставщика удостоверений. В этом случае необходимо правильно настроить решение для провайдера удостоверений, чтобы отправить утверждение multipleauthn в Microsoft Entra ID. Дополнительные сведения см. в разделе "Выполнение требований многофакторной проверки подлинности (MFA) Microsoft Entra ID с использованием утверждений MFA от федеративного поставщика удостоверений".

Вопрос. Будет ли обязательный MFA влиять на мою возможность синхронизации с Microsoft Entra Connect или Microsoft Entra Cloud Sync?

Ответ: Нет. Учетная запись службы синхронизации не влияет на обязательное требование MFA. Для входа в систему с использованием MFA требуются только приложения, перечисленные ранее.

Вопрос: Могу ли я отказаться?

Ответ: Нет способа отказаться. Это движение безопасности крайне важно для всей безопасности платформы Azure и повторяется в разных поставщиках облачных служб. Например, см. раздел Secure by Design: AWS для улучшения требований MFA в 2024 году.

Возможность отложить дату начала принудительного применения доступна для клиентов. Глобальные администраторы могут перейти на портал Azure , чтобы отложить дату начала применения для своего клиента. Глобальные администраторы должны иметь повышенный доступ , прежде чем откладывать дату начала применения MFA на этой странице. Они должны выполнить это действие для каждого клиента, который нуждается в отсрочке.

Вопрос. Можно ли протестировать MFA перед применением политики Azure, чтобы гарантировать, что ничего не прерывается?

Ответ. Да, можно протестировать MFA путем ручной настройки MFA. Мы рекомендуем вам настроить это и проверить. При использовании условного доступа для принудительного применения MFA можно использовать шаблоны условного доступа для тестирования политики. Дополнительные сведения см. в разделе "Требовать многофакторную проверку подлинности" для администраторов, обращаюющихся к порталам администрирования Майкрософт. Если вы запускаете бесплатный выпуск идентификатора Microsoft Entra, вы можете включить параметры безопасности по умолчанию.

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

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

Вопрос. Как проверить действие MFA в идентификаторе Microsoft Entra?

Ответ. Чтобы просмотреть сведения о том, когда пользователю предлагается войти с помощью MFA, используйте журналы входа Microsoft Entra. Дополнительные сведения см. в разделе "Сведения о событии входа для многофакторной аутентификации Microsoft Entra" .

Вопрос: Что делать, если у меня есть сценарий «разбить стекло»?

Ответ. Мы рекомендуем обновить эти учетные записи, чтобы использовать секретный ключ (FIDO2) или настроить проверку подлинности на основе сертификатов для MFA. Оба метода соответствуют требованию MFA.

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

Ответ. Пользователи не должны быть заблокированы, но они могут получить сообщение, которое предложит им включить MFA после запуска принудительного применения для своего клиента. Если пользователь заблокирован, могут возникнуть другие проблемы. Дополнительные сведения см. в статье "Учетная запись заблокирована".

Связанный контент

Дополнительные сведения о настройке и развертывании MFA см. в следующих разделах:

• Как отложить принудительное применение для клиента, где пользователи не могут войти после развертывания обязательной многофакторной проверки подлинности (MFA) для портала Azure, Центра администрирования Microsoft Entra или Центра администрирования Microsoft Intune
• Как убедиться, что пользователи настроены для обязательной многофакторной проверки подлинности
• Руководство. Защита событий входа пользователей с помощью многофакторной проверки подлинности Microsoft Entra
• Обеспечение безопасности событий аутентификации с помощью многофакторной аутентификации Microsoft Entra
• Планирование развертывания многофакторной проверки подлинности Microsoft Entra
• Методы MFA, устойчивые к фишингу
• Многофакторная проверка подлинности Microsoft Entra
• Методы проверки подлинности