Проверка подлинности приложений Java в службах 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 с помощью учетной записи службы приложения или управляемого идентификатора в случае Azure Arc. Локальные рабочие процессы подробно рассматриваются в Аутентификация для приложений, размещенных в локальной среде.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аутентификация локально с помощью служебных принципалов

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

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

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