Влияние многофакторной проверки подлинности в Azure CLI в сценариях автоматизации

Статья
2025-04-01

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

Важный

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

Ограничения пользовательских идентичностей с многофакторной аутентификацией в автоматизации

Заметка

Может появиться сообщение об ошибке: необходима интерактивная аутентификация при автоматизированном использовании учетных данных пользователя.

интерактивная проверка подлинности: MFA активируется во время интерактивного входа при использовании удостоверения пользователя Microsoft Entra. Для сценариев автоматизации, основанных на удостоверении пользователя, MFA нарушает процесс, так как для него требуются дополнительные шаги проверки. Например, приложение authenticator, телефонный звонок и т. д., которое невозможно автоматизировать. Эта проверка предотвращает выполнение автоматизированных процессов, если проверка подлинности не осуществляется в неинтерактивном режиме, например, с управляемым удостоверением или участником службы.
Сбои аутентификации в сценариях автоматизации: В сценариях автоматизации, таких как автоматическое выполнение скриптов Azure CLI, использование удостоверения пользователя с поддержкой MFA приводит к сбою аутентификации при попытке провести проверку подлинности скрипта. Так как многофакторная проверка подлинности требует взаимодействия с пользователем, она несовместима с неинтерактивными скриптами. Это означает, что необходимо переключиться на управляемое удостоверение или служебный принципал, оба из которых используют неинтерактивную аутентификацию.
вопросы безопасности. Хотя MFA добавляет дополнительный уровень безопасности, он может ограничить гибкость автоматизации, особенно в рабочих средах, где автоматизация должна выполняться без ручного вмешательства. Переход на управляемые удостоверения, субъекты-службы или федеративные удостоверения, которые предназначены для автоматизации и не требуют многофакторной проверки подлинности, является более практичным и безопасным в таких средах.

Сценарии, требующие обновлений

В следующем списке приведены примеры сценариев, в которых клиенты могут использовать удостоверение пользователя Microsoft Entra для автоматизации с помощью Azure CLI. Этот список не является исчерпывающим для всех сценариев.

Предупреждение

Любой сценарий автоматизации, использующий удостоверение пользователя Microsoft Entra, требует обновления.

Персонализированные или конкретные разрешения: Задачи автоматизации, требующие прав доступа, специфичных для пользователя, такие как действия, связанные с ролью отдельного пользователя или конкретными атрибутами идентификатора Microsoft Entra.
поток OAuth 2.0 ROPC: поток предоставления учетных данных владельца ресурса OAuth 2.0 (ROPC) несовместим с многофакторной аутентификацией (MFA). Сценарии автоматизации, использующие ROPC для проверки подлинности, завершаются сбоем, когда требуется многофакторная аутентификация (MFA), так как ее невозможно завершить в неинтерактивном потоке.
Доступ к ресурсам, внешним в Azure: сценарии автоматизации, требующие доступа к ресурсам Microsoft 365. Например, SharePoint, Exchange или другие облачные службы, привязанные к учетной записи Майкрософт отдельного пользователя.
учетные записи служб, синхронизированные из Active Directory в Microsoft Entra ID: организации, использующие учетные записи служб, синхронизированные из Active Directory (AD) в Microsoft Entra ID. Важно отметить, что эти учетные записи также подлежат требованиям многофакторной аутентификации (MFA) и вызывают те же проблемы, что и другие идентификационные данные пользователей.
Контекст пользователя для аудита или соответствия: случаи, когда действия необходимо отслеживать на индивидуальном уровне пользователя по причинам соблюдения требований.
простая конфигурация для автоматизации с небольшим или низким уровнем риска: для задач автоматизации с небольшими или низкими рисками. Например, сценарий, который управляет несколькими ресурсами.
автоматизация, управляемая пользователем в непроизводственных условиях: если автоматизация предназначена для личных или непроизводственных условий, где отдельный пользователь отвечает за выполнение задачи.
Процесс автоматизации в собственной подписке Azure пользователя. Если пользователю необходимо автоматизировать задачи в собственной подписке Azure, где у пользователя уже есть достаточные права.

Переключение на управляемое удостоверение или учетную запись службы требуется для сценариев автоматизации из-за обязательного использования MFA для удостоверений пользователей Microsoft Entra.

Начало работы

Чтобы перенести скрипты Azure CLI из az login с учетной записью пользователя и паролем пользователя Microsoft Entra ID, выполните следующие действия.

Определите, какой идентификатор рабочей нагрузки лучше всего подходит для вас.
- Субъект-служба
- Управляемое удостоверение
- Федеративная идентификация
Получите необходимые разрешения для создания идентификатора рабочей нагрузки или обратитесь к администратору Azure за помощью.
Создайте идентификацию рабочей нагрузки.
Назначьте роли новому идентификатору. Дополнительные сведения о назначениях ролей Azure см. в шагах по назначению роли Azure. Сведения о назначении ролей с помощью Azure CLI см. в статье Назначение ролей Azure с помощью Azure CLI.
Обновите скрипты Azure CLI для входа с помощью служебного принципала или управляемого удостоверения.

Основные понятия субъекта-службы

Нечеловеческое удостоверение, которое может получить доступ к нескольким ресурсам Azure. Субъект-служба используется многими ресурсами Azure и не привязан к одному ресурсу Azure.
При необходимости можно изменить свойства и учетные данные учетной записи службы.
Идеально подходит для приложений, которым требуется доступ к нескольким ресурсам Azure в разных подписках.
Считается более гибкими, чем управляемые удостоверения, но менее безопасными.
Часто называются "объектом приложения" в клиенте Azure или каталоге Идентификатора Microsoft Entra.

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

Приложения & субъекты-службы в идентификатора Microsoft Entra
защита субъектов-служб в идентификатора Microsoft Entra

Сведения о входе в Azure с использованием Azure CLI и учетной записи службы см. в статье Вход в Azure с учетной записью службы через Azure CLI

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

Привязан к определенному ресурсу Azure, позволяющему одному ресурсу получить доступ к другим приложениям Azure.
Учетные данные не видны вам. Azure обрабатывает секреты, учетные данные, сертификаты и ключи.
Идеально подходит для ресурсов Azure, которым требуется доступ к другим ресурсам Azure в рамках одной подписки.
Считается менее гибким, чем субъекты-службы, но более безопасными.
Существует два типа доверенных удостоверений:
- назначенная системой: этот тип — это ссылка на доступ между двумя ресурсами Azure (один к одному).
- назначенный пользователем: этот тип имеет отношение 1:M (один ко многим), где управляемое удостоверение может получить доступ к нескольким ресурсам Azure.

Дополнительные сведения об управляемых удостоверениях см. в статье Управляемые удостоверения для ресурсов Azure.

Сведения о входе в Azure с помощью Azure CLI и управляемого удостоверения см. в статье Вход в Azure с помощью управляемого удостоверения с помощью Azure CLI

Основные понятия ключа федеративного удостоверения

Федеративное удостоверение позволяет учетным данным служб (регистрации приложений) и назначаемым пользователем управляемым удостоверениям доверять токенам от внешнего поставщика удостоверений (IdP), например GitHub или Google.
После создания отношения доверия ваши внешние программные рабочие нагрузки обменивают доверенные токены из внешнего поставщика удостоверений на токены доступа из платформы удостоверений Майкрософт.
Ваша рабочая нагрузка программного обеспечения использует этот маркер доступа для доступа к защищенным ресурсам Microsoft Entra, к которым предоставляется доступ рабочей нагрузки.
Федеративные удостоверения часто являются лучшим решением для следующих сценариев:
- Рабочая нагрузка, выполняемая в любом кластере Kubernetes
- Действия GitHub
- Рабочая нагрузка на вычислительных платформах Azure с использованием удостоверений приложений
- Google Cloud
- Amazon Web Services (AWS)
- Рабочая нагрузка, выполняющаяся на вычислительных платформах за пределами Azure

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

Устранение неполадок

Ошибка ROPC: из-за изменения конфигурации, внесенного администратором

При попытке входа в Azure с помощью пароля это называется потоком ROPC (учетные данные владельца ресурса). Этот метод проверки подлинности не поддерживается с MFA. Ниже приведен пример:

az login --username $username –password $password

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

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access ‘’. Trace ID Correlation ID: Timestamp:

Решение: Переключитесь на использование метода аутентификации, совместимого с многофакторной аутентификацией.

Предупреждение для учетных записей между клиентами: ошибка аутентификации для клиента

Если у вас есть доступ к нескольким клиентам и одному из них требуется многофакторная проверка подлинности, Azure CLI может отобразить предупреждение, аналогичное этому:

Authentication failed against tenant 00000000-0000-0000-0000-000000000000 'Tenant Name': AADSTSXXXXX: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000000-0000-0000-0000-000000000000'. Trace ID: 00000000-0000-0000-0000-000000000000 Correlation ID: 00000000-0000-0000-0000-000000000000 Timestamp: yyyy-mm-dd hh:mm:ss.

На этапе входа Azure CLI пытается войти, используя первого найденного арендатора. Хотя мы работаем над решением этой проблемы, укажите арендатора, которого вы хотите использовать с параметром --tenant.

az login --tenant 00000000-0000-0000-0000-000000000000

Дополнительные сведения о многофакторной проверке подлинности

Сайт документации Microsoft Entra ID предлагает более подробную информацию о многофакторной аутентификации.