Проверка подлинности приложений Python в службах Azure с помощью библиотеки удостоверений Azure

Приложения могут использовать библиотеку удостоверений Azure для проверки подлинности в Microsoft Entra ID, что позволяет приложениям получать доступ к службам и ресурсам Azure. Это требование проверки подлинности применяется, развертывается ли приложение в Azure, размещено локально или работает локально на рабочей станции разработчика. В разделах выше описаны рекомендуемые подходы к проверке подлинности приложения для Microsoft Entra ID в разных средах при использовании клиентских библиотек Azure SDK.

Рекомендуемый подход к проверке подлинности приложений

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

Преимущества проверки подлинности на основе токенов

Проверка подлинности на основе маркеров обеспечивает следующие преимущества по сравнению со строками подключения:

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

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

Проверка подлинности в разных средах

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

Когда приложение:

• Hosted в Azure: приложение должно аутентифицироваться в ресурсах Azure с помощью управляемого удостоверения. Этот параметр более подробно рассматривается при аутентификации в серверных средах.
• Запуск локально во время разработки: приложение может пройти проверку подлинности для Azure с помощью учетной записи разработчика, брокера или служебного принципала. Каждый вариант подробно рассматривается в разделе , посвященном аутентификации, во время локальной разработки.
• Размещенное в локальной среде: приложение должно пройти проверку подлинности для ресурсов Azure с помощью учетной записи службы приложения или управляемого идентификатора в случае Azure Arc. Локальные рабочие процессы подробно рассматриваются в Аутентификация для приложений, размещенных в локальной среде.

Проверка подлинности для Azure размещенных приложений

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

Использование управляемого удостоверения, назначаемого пользователем

Пользовательское управляемое удостоверение создается как автономный Azure-ресурс. Его можно назначить одному или нескольким ресурсам Azure, что позволяет этим ресурсам совместно использовать одинаковые удостоверения и разрешения. Чтобы выполнить проверку подлинности с помощью управляемого удостоверения, назначаемого пользователем, создайте удостоверение, назначьте его ресурсу Azure, а затем настройте приложение для использования этого удостоверения для проверки подлинности, указав его идентификатор клиента, идентификатор ресурса или идентификатор объекта.

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

Использование управляемого удостоверения, назначаемого системой

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

Проверка подлинности с помощью управляемого удостоверения, назначаемого системой

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

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

Использование учетных данных разработчика

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

Проверка подлинности локально с помощью учетных данных разработчика

Использование брокера

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

Проверка подлинности локально с помощью брокера

Использование служебного принципала

Служебный принципал создается в клиенте Microsoft Entra для представления приложения и использования для аутентификации в ресурсах Azure. Вы можете настроить приложение для использования учетных данных сервисного принципала во время локальной разработки. Этот метод является более безопасным, чем использование учетных данных разработчика и ближе к тому, как ваше приложение будет проходить проверку подлинности в рабочей среде. Однако это все еще менее оптимально, чем использование управляемой идентичности, из-за необходимости в конфиденциальных данных.

Локальная аутентификация с использованием служебного объекта

Проверка подлинности для приложений, размещенных в локальной среде

Для приложений, размещенных в локальной среде, можно использовать сервисный принципал для аутентификации ресурсов Azure. Это включает создание субъекта-службы в Microsoft Entra ID, назначение необходимых разрешений и настройку приложения для использования учетных данных. Этот метод позволяет локальному приложению безопасно получать доступ к службам Azure.

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