Прочитать на английском

Поделиться через

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

  • Статья

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

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

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

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

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

Приложения

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

Имя приложения ИД приложения Начало исполнения
Портал Azure c44b4083-3bb0-49c1-b47d-974e53cbdf3c Вторая половина 2024 года
Центр администрирования Microsoft Entra c44b4083-3bb0-49c1-b47d-974e53cbdf3c Вторая половина 2024 года
Центр администрирования Microsoft Intune c44b4083-3bb0-49c1-b47d-974e53cbdf3c Вторая половина 2024 года
Интерфейс командной строки Azure (Azure CLI) 04b07795-8ddb-461a-bbee-02f9e1bf7b46 Начало 2025 г.
Azure PowerShell 1950a258-227b-4e31-a9cf-717495945fc2 Начало 2025 г.
мобильные приложения Azure; 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa Начало 2025 г.
Средства инфраструктуры как кода (IaC) Использование идентификаторов Azure CLI или Azure PowerShell Начало 2025 г.

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

Имя приложения URL-адрес Принудительное применение начинается
Центр администрирования Microsoft 365 https://portal.office.com/adminportal/home Февраль 2025 г.
Центр администрирования Microsoft 365 https://admin.cloud.microsoft Февраль 2025 г.
Центр администрирования Microsoft 365 https://admin.microsoft.com Февраль 2025 г.

Аккаунты

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

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

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

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

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

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

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

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

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

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

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

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

Внедрение

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

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

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

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

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

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

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

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

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

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

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

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

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

После принудительного применения баннер появится в многофакторной проверке подлинности Microsoft Entra:

Снимок экрана баннера в многофакторной аутентификации Microsoft Entra, на котором показано, что обязательная многофакторная аутентификация введена.

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

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

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

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

Примечание

Дата, когда глобальные администраторы могут выбрать дату начала применения, изменилась с 24 февраля 2025 г. на 3 марта 2025 г.

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

Начиная с 3 марта 2025 г. глобальные администраторы могут перейти на портал Azure , чтобы выбрать дату начала применения для своего клиента для порталов администрирования на этапе 1. Глобальные администраторы должны повысить уровень доступа, прежде чем они смогут отложить дату начала применения MFA.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможность отложить дату начала принудительного применения доступна для клиентов. В период с 15 августа 2024 г. по 15 октября 2024 г. глобальные администраторы могут перейти к портал Azure, чтобы отложить дату начала применения для своего клиента до 15 марта 2025 г. Глобальные администраторы должны иметь повышенный доступ , прежде чем откладывать дату начала применения 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 см. в следующих разделах: