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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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