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

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

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

Это важно

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

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

Замечание

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

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

  • Сбои аутентификации в сценариях автоматизации: В сценариях автоматизации, таких как автоматическое выполнение скриптов Azure CLI, использование удостоверения пользователя с поддержкой MFA приводит к сбою аутентификации при попытке провести проверку подлинности скрипта. Так как многофакторная проверка подлинности требует взаимодействия с пользователем, она несовместима с неинтерактивными скриптами. Это означает, что необходимо переключиться на управляемое удостоверение или служебный принципал, оба из которых используют неинтерактивную аутентификацию.

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

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

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

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

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

  • Персонализированные или специфические разрешения: задачи автоматизации, которые требуют разрешений конкретного пользователя, например, действия, связанные с ролью отдельного пользователя или определенными атрибутами ID 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, выполните следующие действия.

  1. Определите, какой идентификатор рабочей нагрузки лучше всего подходит для вас.

    • Принципал службы
    • Манажируемая идентичность
    • Федеративная идентичность

  2. Получите необходимые разрешения для создания идентификатора рабочей нагрузки или обратитесь к администратору Azure за помощью.

  3. Создайте идентификатор рабочей нагрузки.

  4. Назначьте роли новой учетной записи. Дополнительные сведения о назначениях ролей Azure см. в шагах по назначению роли Azure. Сведения о назначении ролей с помощью Azure CLI см. в статье Назначение ролей Azure с помощью Azure CLI.

  5. Обновите скрипты Azure CLI для входа с помощью служебного принципала или управляемого удостоверения.

Основные понятия сервисного принципала

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

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

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

Ключевые концепции управляемой идентичности

  • Привязан к определенному ресурсу Azure, позволяющему одному ресурсу получить доступ к другим приложениям Azure.
  • Учетные данные не видны вам. Azure обрабатывает секреты, учетные данные, сертификаты и ключи.
  • Идеально подходит для ресурсов Azure, которым требуется доступ к другим ресурсам Azure в рамках одной подписки.
  • Считается менее гибким, чем субъектов-служб, но более безопасным.
  • Существует два типа доверенных удостоверений:
    • назначенная системой: этот тип представляет собой ссылку на доступ между двумя ресурсами Azure (один-к-одному, 1:1).
    • назначено пользователем: этот тип имеет отношение 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 предлагает более подробные сведения о многофакторной аутентификации (MFA).

См. также