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

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

Это важно

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

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

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

Замечание

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

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

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

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

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

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

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

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

  • Персонализованные или определенные разрешения: задачи автоматизации, требующие разрешений для конкретных пользователей, таких как действия, связанные с ролью пользователя или определенными атрибутами Microsoft Entra ID.

  • Поток OAuth 2.0 ROPC (поток предоставления маркера учетных данных пароля владельца ресурса OAuth 2.0) несовместим с многофакторной аутентификацией (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 PowerShell с использования Connect-AzAccount с учетной записью пользователя Microsoft Entra ID и паролем, выполните следующие действия:

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

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

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

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

  4. Назначьте роли новой учетной записи. Дополнительные сведения о назначениях ролей Azure см. в разделе Шаги по назначению роли Azure. Чтобы назначать роли с помощью Azure PowerShell, см. в статье Назначение ролей Azure с помощью Azure PowerShell.

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

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

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

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

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

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

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

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

Сведения о том, как войти в Azure с помощью Azure PowerShell и управляемого удостоверения, см. в статье Вход в Azure с управляемым удостоверением с использованием Azure PowerShell

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

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

Подробнее о федеративных идентификаторах см. в следующем разделе:

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

Сайт документации Microsoft Entra ID содержит дополнительные сведения о MFA.

См. также

  • Last updated on