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

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

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

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

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

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

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

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

Приложения этапа 1

Начиная с октября 2024 года MFA требуется для учетных записей, которые выполняют вход в портал Azure, Центр администрирования Microsoft Entra и Центр администрирования Microsoft Intune для выполнения любой операции создания, чтения, обновления или удаления (CRUD). Принудительное применение постепенно коснется всех клиентов по всему миру. Начиная с февраля 2025 года применение MFA постепенно начинается для входа в Microsoft 365 admin center. Этап 1 не влияет на другие клиенты Azure, такие как Azure CLI, Azure PowerShell, мобильное приложение Azure или средства IaC.

Приложения этапа 2

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

Некоторые клиенты могут использовать учетную запись пользователя в Microsoft Entra ID в качестве учетной записи службы. Рекомендуется перенести эти учетные записи служб, основанные на пользователях, в безопасные облачные учетные записи служб с удостоверениями рабочей нагрузки.

Идентификаторы приложений и URL-адреса

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

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

Accounts

Все учетные записи, входящие для выполнения операций, указанных в разделе приложений, должны пройти многофакторную аутентификацию, когда начинается его принудительное применение. Пользователям не требуется использовать многофакторную аутентификацию, если они получают доступ к другим приложениям, веб-сайтам или службам, размещенным в 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 доступна с использованием внешних MFA и может использоваться для удовлетворения требований MFA. Устаревшая предварительная версия пользовательских элементов управления условного доступа не соответствует требованию многофакторной аутентификации (MFA). Чтобы использовать внешнее решение с Microsoft Entra ID, необходимо перейти на внешнюю многофакторную аутентификацию.

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

Подготовка к обязательному применению MFA

Чтобы подготовиться к применению MFA, настройте политику Conditional Access, требующую входа пользователей с помощью MFA. Если в политике настроены исключения или исключения из обработки, они больше не применяются. Если у вас есть более строгие политики условной Access, предназначенные для Azure и требующие более строгой проверки подлинности, например фишинговый MFA, они остаются примененными.

Для условного доступа требуется лицензия Microsoft Entra ID P1 или P2. Если вы не можете использовать условный доступ, включите security defaults.

Вы можете самостоятельно применять MFA с помощью встроенных определений в Azure Policy. Дополнительные сведения и пошаговые сведения о применении этих назначений политик в вашей среде см. в статье Tutorial: применение самоприменения MFA через Azure Policy.

Для обеспечения оптимальной совместимости убедитесь, что пользователи в клиенте используют Azure CLI версии 2.76 и Azure PowerShell версии 14.3 или более поздней. В противном случае вы можете увидеть сообщения об ошибках, как описано в следующих разделах:

• Устранение ошибок MFA в Azure PowerShell
• Устранение ошибок MFA в Azure CLI

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

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

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

Запросите дополнительное время, чтобы подготовиться к введению в действие MFA на этапе 2.

Корпорация Майкрософт позволяет клиентам с сложными средами или техническими барьерами отложить применение этапа 2 для своих клиентов до 1 июля 2026 года. Вы можете запросить больше времени для подготовки к обязательному внедрению MFA второго этапа на https://aka.ms/postponePhase2MFA. Выберите другую дату начала и нажмите кнопку "Применить". После начала принудительного применения этапа 2 вы можете отправить запрос в службу справки и поддержки Майкрософт, чтобы временно отменить принудительное применение. Запрос должен выполняться глобальным администратором из-за последствий для безопасности.

Проверка обязательного внедрения MFA

Подтверждение осуществления этапа 1

Чтобы убедиться, что для клиента применяется обязательная MFA этапа 1:

1. Войдите на портал Azure в качестве глобального администратора.

2. Перейдите по ссылке https://aka.ms/managemfaforazure.

3. Убедитесь, что на странице многофакторной проверки подлинности (этап 1) отображается баннер, подтверждающий начало применения для клиента.

   

Подтверждение принудительного применения этапа 2

Чтобы убедиться, что для клиента применяется обязательная MFA этапа 2.

1. Войдите на портал Azure в качестве глобального администратора.

2. Перейдите по ссылке https://aka.ms/postponePhase2MFA.

3. Убедитесь, что на странице многофакторной проверки подлинности (этап 2) отображается баннер, который подтверждает начало принудительного применения для вашего клиента.

   

Microsoft Entra ID журналы входа показывают приложение, которое выступило в качестве инициатора запроса MFA.

FAQs

Вопрос: Какие учетные записи затрагиваются применением MFA этапа 2?

Answer: Azure этап 2 применяется ко всем учетным записям пользователей, которые выполняют Azure действия по управлению ресурсами через любой клиент Azure, включая PowerShell, CLI, пакеты SDK или даже REST API. Принудительное применение осуществляется на стороне сервера Azure Resource Manager, поэтому все запросы, направленные на https://management.azure.com, подлежат принудительному применению. Учетные записи служб автоматизации не подпадают под действие, если они используют управляемое удостоверение или учетную запись службы. Все учетные записи автоматизации, которые настроены как идентификаторы пользователей, будут подлежать принудительному исполнению.

Question: Как понять влияние применения МФА без Условного доступа?

Answer: Если лицензия Microsoft Entra ID не включает условный доступ, вы можете использовать Azure Policy, чтобы понять, как применение MFA влияет на ваш арендатор. Во время применения системы корпорация Майкрософт развертывает Azure Policy для вашего арендатора. Эти действия можно выполнить для развертывания одного и того же Azure policy самостоятельно в любое время. Политику можно развернуть в режиме аудита, а затем преобразовать в режим принудительного применения. Вы можете выбрать дату применения этой политики в своем тенанте в режиме принудительного применения. Затем, когда корпорация Майкрософт применит многофакторную проверку подлинности, дальнейшего влияния на ваш арендатор не будет.

Вопрос. Существуют ли исключения для определенных учетных записей?

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

Вопрос: Являются ли API Microsoft Graph частью области применения второго этапа?

Answer. Как правило, Microsoft Graph API не являются областью применения Azure MFA. Только запросы, отправленные в https://management.azure.com/, подпадают под действия принуждения.

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

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

Question: как это требование влияет на Microsoft 365 admin center?

Answer: Обязательная многофакторная аутентификация (MFA) будет развернута в Центре администрирования Microsoft 365 начиная с февраля 2025 года. Дополнительные сведения об обязательном требовании обязательной многофакторной проверки подлинности для центра администрирования Microsoft 365 в записи блога «Обязательная многофакторная проверка подлинности для центра администрирования Microsoft 365».

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

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

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

Answer. Да, MFA должно соблюдаться либо от арендатора ресурса партнера, либо домашнего арендатора пользователя, если он настроен правильно для отправки запросов MFA арендатору ресурсов с помощью межтенантного доступа.

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

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

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

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

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

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

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

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

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

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

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

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

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

Question: Как просмотреть и проанализировать активность MFA в Microsoft Entra ID?

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

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

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

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

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

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

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

• Как отложить принудительное применение для клиента, где пользователи не могут подписаться
• Как убедиться, что пользователи настроены для обязательной многофакторной проверки подлинности
• Учебник: Защита событий входа пользователей с помощью многофакторной аутентификации Microsoft Entra
• Планирование развертывания многофакторной проверки подлинности Microsoft Entra
• Методы MFA, устойчивые к фишингу
• Многофакторная проверка подлинности Microsoft Entra
• Методы аутентификации