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

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

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

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

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

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

Приложения

Организация

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

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

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

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

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

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

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

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

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

Внедрение

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

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

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

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

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

• Этап 1. Начиная со второй половины 2024 года MFA потребуется для входа в портал Azure, Центра администрирования Microsoft Entra и Центра администрирования Microsoft Intune. Принудительное применение постепенно коснется всех клиентов по всему миру. Этот этап не влияет на другие клиенты 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ. Необходимо правильно настроить решение поставщика удостоверений для отправки утверждения multipleauthn в идентификатор Microsoft Entra. Дополнительные сведения см . в справочнике по поставщику внешних методов многофакторной проверки подлинности Microsoft Entra.

Вопрос. Будет ли этап 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 см. в следующих разделах:

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