Прочитать на английском

Поделиться через


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

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

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

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

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

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

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

DefaultAzureCredential (учетные данные Azure по умолчанию)

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

Сведения об использовании DefaultAzureCredential рассматриваются в разделе Use DefaultAzureCredential в приложении.

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

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

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

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

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

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

Метод проверки подлинности Описание
Приложения, размещенные в Azure ** Приложения, размещенные в Azure, должны использовать субъект службы управляемого удостоверения . Управляемые удостоверения предназначены для представления удостоверения приложения, размещенного в Azure, и могут использоваться только с приложениями, размещенными в Azure.

Например, веб-приложению .NET, размещённому в Службе приложений Azure, будет присвоено управляемое удостоверение. Затем управляемое удостоверение, назначенное приложению, будет использоваться для проверки подлинности приложения в других службах Azure.

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

Например, рассмотрим веб-приложение .NET, размещенное в локальной среде, которая использует хранилище BLOB-объектов Azure. Вы создадите учетную запись службы для приложения с помощью процесса регистрации приложений. AZURE_CLIENT_ID, AZURE_TENANT_IDи AZURE_CLIENT_SECRET будут храниться в виде переменных среды, которые будут считываться приложением во время выполнения и обеспечивать возможность аутентификации приложения в Azure с помощью субъекта-службы приложений.

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

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

Метод проверки подлинности Описание
Создание специальных объектов службы приложений для локальной разработки В этом методе выделенные объекты принципала службы приложения настраиваются с помощью процесса регистрации приложений для использования во время локальной разработки. Затем удостоверение сервисного принципала сохраняется в виде переменных среды, которые доступны приложению при его запуске в локальной разработке.

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

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

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

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

Использование DefaultAzureCredential в приложении

DefaultAzureCredential — это упорядоченная последовательность предпочитаемых механизмов для аутентификации в службе Microsoft Entra ID. Каждый механизм проверки подлинности является классом, производным от класса TokenCredential и называется учетными данными. Во время выполнения DefaultAzureCredential пытается пройти проверку подлинности с помощью первых учетных данных. Если эти учетные данные не удается получить токен доступа, выполняется попытка использования следующих учетных данных в последовательности и так далее, пока токен доступа не будет успешно получен. Таким образом, приложение может использовать разные учетные данные в разных средах без написания кода для конкретной среды.

Чтобы использовать DefaultAzureCredential, добавьте Azure.Identity и при необходимости пакеты Microsoft.Extensions.Azure в приложение:

В выбранном терминале перейдите к каталогу проекта приложения и выполните следующие команды:

Интерфейс командной строки.NET
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

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

  1. Включите пространства имен Azure.Identity и Microsoft.Extensions.Azure с помощью директив using.
  2. Зарегистрируйте клиент службы Azure, используя соответствующий метод расширения с префиксом Add.
  3. Передайте экземпляр DefaultAzureCredential методу UseCredential.

Например:

c#
using Microsoft.Extensions.Azure;
using Azure.Identity;

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));
    clientBuilder.UseCredential(new DefaultAzureCredential());
});

Альтернативой UseCredential является создание экземпляра DefaultAzureCredential напрямую:

c#
using Azure.Identity;

builder.Services.AddSingleton<BlobServiceClient>(_ =>
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

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

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