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

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

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

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

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

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

DefaultAzureCredential

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

Дополнительные сведения об использовании DefaultAzureCredential класса рассматриваются далее в этой статье в разделе "Использование DefaultAzureCredential в приложении".

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

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

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

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

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

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

Authentication method	Description
Приложения, размещенные в Azure	Приложения, размещенные в Azure, должны использовать субъект-службу управляемого удостоверения. Управляемые удостоверения предназначены для представления удостоверения приложения, размещенного в Azure, и могут использоваться только с размещенными приложениями Azure. Например, веб-приложение .NET, размещенное в службе приложение Azure, будет назначено управляемое удостоверение. Затем управляемое удостоверение, назначенное приложению, будет использоваться для проверки подлинности приложения в других службах Azure. Сведения о проверке подлинности из размещенных в Azure приложениях
Приложения, размещенные за пределами Azure (например, локальные приложения)	Приложения, размещенные за пределами Azure (например, локальные приложения), которые должны подключаться к службам Azure, должны использовать субъект-службу приложений. Субъект-служба приложений представляет удостоверение приложения в Azure и создается с помощью процесса регистрации приложения. Например, рассмотрим веб-приложение .NET, размещенное в локальной среде, которое использует Хранилище BLOB-объектов Azure. Вы создадите субъект-службу приложений для приложения с помощью процесса регистрации приложений. Значение AZURE_CLIENT_ID, AZURE_TENANT_IDи AZURE_CLIENT_SECRET все они будут храниться в виде переменных среды, которые будут считываться приложением во время выполнения и разрешать приложению проходить проверку подлинности в Azure с помощью субъекта-службы приложений. Сведения о проверке подлинности из приложений, размещенных за пределами Azure

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

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

Authentication method	Description
Создание выделенных объектов субъекта-службы приложений для использования во время локальной разработки	В этом методе выделенные объекты субъекта-службы приложений настраиваются с помощью процесса регистрации приложений для использования во время локальной разработки. Затем удостоверение субъекта-службы сохраняется в виде переменных среды, к которым обращается приложение при запуске в локальной разработке. Этот метод позволяет назначать определенные разрешения ресурсов, необходимые приложению для объектов субъекта-службы, используемых разработчиками во время локальной разработки. Это гарантирует, что приложение имеет доступ только к определенным ресурсам, которые он нуждается, и реплика выполняет разрешения, которые приложение будет иметь в рабочей среде. Недостатком этого подхода является необходимость создания отдельных объектов субъекта-службы для каждого разработчика, работающего в приложении. Сведения о проверке подлинности из размещенных в Azure приложениях
Проверка подлинности приложения в Azure с помощью учетных данных разработчика во время локальной разработки	В этом методе разработчик должен войти в Azure из Visual Studio, расширение средств Azure для VS Code, Azure CLI или Azure PowerShell на локальной рабочей станции. Затем приложение может получить доступ к учетным данным разработчика из хранилища учетных данных и использовать эти учетные данные для доступа к ресурсам Azure из приложения. Этот метод имеет преимущество более простой настройки, так как разработчику нужно войти только в учетную запись Azure из Visual Studio, VS Code или Azure CLI. Недостатком этого подхода является то, что учетная запись разработчика, скорее всего, имеет больше разрешений, чем требуется для приложения. Таким образом, этот подход не точно реплика te разрешения, с которыми приложение будет работать в рабочей среде. Сведения о проверке подлинности из размещенных в Azure приложениях

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

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

Порядок и расположения, в которых DefaultAzureCredential поиск учетных данных найден в DefaultAzureCredential.

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

Командная строка

Откройте среду терминала в каталоге проекта приложения и введите следующую команду.

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

диспетчер пакетов NuGet

Щелкните правой кнопкой мыши узел проекта в Visual Studio и выберите пункт "Управление пакетами NuGet". Найдите Azure.Identity в поле поиска и установите соответствующий пакет. Повторите этот процесс для пакета Microsoft.Extensions.Azure , а также.

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

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

Пример этого показан в следующем сегменте кода.

using Microsoft.Extensions.Azure;
using Azure.Identity;

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

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

using Azure.Identity;

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

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

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

Изучение последовательности методов проверки подлинности DefaultAzureCredential

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

Порядок и расположения, в которых DefaultAzureCredential поиск учетных данных найден в DefaultAzureCredential.

Тип учетных данных	Description
Субъект-служба приложений	DefaultAzureCredential считывает набор переменных среды, чтобы определить, настроен ли субъект-служба приложения (пользователь приложения) для приложения. В этом случае использует эти значения для DefaultAzureCredential проверки подлинности приложения в Azure. Этот метод чаще всего используется в средах сервера, но также может использоваться при разработке локально.
Управляемое удостоверение	Если приложение развернуто на узле Azure с включенным управляемым удостоверением, DefaultAzureCredential будет проходить проверку подлинности приложения в Azure с помощью этого управляемого удостоверения. Проверка подлинности с помощью управляемого удостоверения рассматривается в разделе проверки подлинности в средах сервера в этом документе. Этот метод доступен только в том случае, если приложение размещено в Azure с помощью службы, например службы приложение Azure, Функции Azure или Azure Виртуальные машины.
Visual Studio	Если разработчик прошел проверку подлинности в Azure, войдите в Visual Studio, DefaultAzureCredential выполните проверку подлинности приложения в Azure с помощью той же учетной записи.
Visual Studio Code	Если разработчик прошел проверку подлинности в Azure с помощью подключаемого модуля учетной записи Azure Visual Studio Code, DefaultAzureCredential будет проходить проверку подлинности приложения в Azure с помощью той же учетной записи.
Azure CLI	Если разработчик прошел проверку подлинности в Azure с помощью az login команды в Azure CLI, DefaultAzureCredential проверит приложение в Azure с помощью той же учетной записи.
Azure PowerShell	Если разработчик прошел проверку подлинности в Azure с помощью командлета Connect-AzAccount Из Azure PowerShell, DefaultAzureCredential будет проходить проверку подлинности приложения в Azure с помощью той же учетной записи.
Интерактивный	Если этот параметр включен, DefaultAzureCredential он будет выполнять интерактивную проверку подлинности разработчика через браузер по умолчанию текущей системы. По умолчанию этот параметр отключен.