Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Приложения могут использовать библиотеку удостоверений Azure для проверки подлинности в идентификаторе Microsoft Entra, что позволяет приложениям получать доступ к службам и ресурсам Azure. Это требование проверки подлинности применяется, развертывается ли приложение в Azure, размещено локально или работает локально на рабочей станции разработчика. В разделах, описанных выше, описаны рекомендуемые подходы к проверке подлинности приложения в идентификаторе Microsoft Entra в разных средах при использовании клиентских библиотек пакета SDK Azure.
Рекомендуемый подход к проверке подлинности приложений
Аутентификация с использованием токенов через Microsoft Entra ID является рекомендованным подходом для аутентификации приложений в Azure вместо использования строк подключения или ключей. Клиентская библиотека Azure Identity для C++ предоставляет аутентификацию на основе токенов и позволяет приложениям аутентифицироваться в ресурсах Azure как локально, так и в облаке Azure или на локальном сервере.
Преимущества проверки подлинности на основе токенов
Проверка подлинности на основе маркеров обеспечивает следующие преимущества по сравнению со строками подключения:
- Проверка подлинности на основе маркеров гарантирует, что только определенные приложения, предназначенные для доступа к ресурсу Azure, могут это сделать, в то время как любой пользователь или любое приложение со строкой подключения может подключиться к ресурсу Azure.
- Проверка подлинности на основе маркеров позволяет дополнительно ограничить доступ к ресурсам Azure только определенным разрешениям, необходимым для приложения. Это соответствует принципу наименьших привилегий. В отличие от этого, строка подключения предоставляет полные права ресурсу Azure.
- При использовании управляемого удостоверения для проверки подлинности на основе маркеров Azure обрабатывает административные функции, поэтому вам не нужно беспокоиться о таких задачах, как защита или смена секретов. Это делает приложение более безопасным, так как нет строки подключения или секрета приложения, которые могут быть скомпрометированы.
- Строки подключения функционально эквивалентны учетным данным и требуют специальной обработки, чтобы предотвратить случайную утечку. Они должны храниться безопасно (например, в Azure Key Vault) и никогда не должны быть жестко закодированы в вашем приложении или добавлены в систему управления версиями. Инициатива Microsoft Secure Future Initiative (SFI) запрещает использование строк подключения и аналогичных долгосрочных секретов, так как их можно использовать для компрометации приложения, если ими не управлять тщательно.
- Библиотека идентификационных данных Azure получает токены Microsoft Entra и управляет ими.
Использование строк подключения должно быть ограничено сценариями, в которых проверка подлинности на основе маркеров не является вариантом, начальными приложениями проверки концепции или прототипами разработки, которые не обращаются к рабочим или конфиденциальным данным. По возможности используйте типы учетных данных в библиотеке удостоверений Azure для проверки подлинности в ресурсах Azure.
Проверка подлинности в разных средах
Конкретный тип проверки подлинности на основе маркеров, который приложение должно использовать для проверки подлинности в ресурсах Azure, зависит от того, где работает приложение. На следующей схеме приведены рекомендации по различным сценариям и средам:
Когда приложение:
- Размещено в Azure: приложение должно пройти проверку подлинности в ресурсах Azure с помощью управляемого удостоверения. Этот параметр подробно рассматривается при проверке подлинности для размещенных в Azure приложений.
- Выполнение локально во время разработки: Приложение может проходить аутентификацию в Azure, используя служебный принципал приложения для локальной разработки или учетные данные разработчика Azure. Каждый вариант подробно рассматривается в разделе , посвященном аутентификации, во время локальной разработки.
- Размещенные локально: приложение должно пройти аутентификацию в ресурсах Azure с помощью служебного субъекта приложения или управляемой идентичности при использовании Azure Arc. Локальные рабочие процессы подробно рассматриваются в разделе аутентификация для приложений, размещаемых в локальной среде.
Проверка подлинности для размещенных в Azure приложений
Если приложение размещено в Azure, оно может использовать управляемые удостоверения для проверки подлинности в ресурсах Azure без необходимости управлять учетными данными. Существует два типа управляемых удостоверений: назначаемые пользователем и назначаемые системой.
Использование управляемого удостоверения, назначаемого пользователем
Управляемое удостоверение, назначаемое пользователем, создается как отдельный ресурс Azure. Его можно назначить одному или нескольким ресурсам Azure, что позволяет этим ресурсам совместно использовать одинаковые удостоверения и разрешения. Чтобы пройти проверку подлинности с помощью управляемого удостоверения, назначаемого пользователем, создайте удостоверение, назначьте его ресурсу Azure, а затем настройте приложение для проверки подлинности, указав его идентификатор клиента, идентификатор ресурса или идентификатор объекта.
Использование управляемого удостоверения, назначаемого системой
Управляемое удостоверение, назначаемое системой, включается непосредственно в ресурс Azure. Идентификатор привязан к жизненному циклу этого ресурса и автоматически удаляется при удалении ресурса. Чтобы пройти проверку подлинности с помощью управляемого удостоверения, назначаемого системой, включите удостоверение в ресурсе Azure, а затем настройте приложение для использования этого удостоверения для проверки подлинности.
Проверка подлинности во время локальной разработки
Во время локальной разработки вы можете авторизоваться к ресурсам Azure с помощью учетных данных разработчика или служебного субъекта. Это позволяет протестировать логику проверки подлинности приложения, не развертывая ее в Azure.
Использование учетных данных разработчика
Вы можете использовать собственные учетные данные Azure для проверки подлинности в ресурсах Azure во время локальной разработки. Обычно это делается с помощью средства разработки, например Azure CLI, который может предоставить приложению необходимые маркеры для доступа к службам Azure. Этот метод удобно, но его следует использовать только для целей разработки.
Использование служебного принципала
Субъект-служба создается в клиенте Microsoft Entra для представления приложения и использования для проверки подлинности в ресурсах Azure. Вы можете настроить приложение для использования учетных данных сервисного принципала во время локальной разработки. Этот метод является более безопасным, чем использование учетных данных разработчика и ближе к тому, как приложение проходит проверку подлинности в рабочей среде. Однако это все еще менее оптимально, чем использование управляемой идентичности, из-за необходимости в конфиденциальных данных.
Проверка подлинности для приложений, размещенных в локальной среде
Для приложений, размещенных в локальной среде, можно использовать служебный принципал для аутентификации в Azure. Это включает создание сервисного объекта в директории Microsoft Entra, назначение необходимых разрешений и настройку вашего приложения для использования этих учетных данных. Этот метод позволяет локальному приложению безопасно получать доступ к службам Azure.