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


Подключение приложения к ресурсам без обработки учетных данных

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

На этой странице показано, как настроить Службу приложений, чтобы она могла подключаться к Azure Key Vault, службе хранилища Azure и Microsoft SQL Server. Те же принципы можно использовать для любого ресурса Azure, поддерживающего управляемые удостоверения и которые будут подключаться к ресурсам, поддерживающим проверку подлинности Microsoft Entra.

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

К каким ресурсам могут подключаться управляемые удостоверения?

Управляемое удостоверение может подключаться к любому ресурсу, который поддерживает проверку подлинности Microsoft Entra. Как правило, для ресурса не требуется специальная поддержка, позволяющая управляемым удостоверениям подключаться к нему.

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

Создание управляемого удостоверения

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

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

Внимание

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

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

После создания управляемого удостоверения, назначаемого пользователем, запишите значения clientId и principalId, возвращаемые при создании управляемого удостоверения. Вы используете principalId при добавлении разрешений и clientId в коде приложения.

Настройте службу приложений с управляемым удостоверением, назначенным пользователем.

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

Добавление разрешений к удостоверению

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

Внимание

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

Чтобы получить доступ к любым ресурсам, вы должны предоставить разрешения на удостоверение. Например, если вы запрашиваете маркер для доступа к Key Vault, необходимо также добавить политику доступа, включающую в себя управляемое удостоверение приложения или функции. В противном случае ваши вызовы к Key Vault будут отклоняться, даже если вы используете действительный токен. Это же справедливо и для Базы данных SQL Azure. Дополнительные сведения о том, какие ресурсы поддерживают токены Microsoft Entra, см. в службах Azure, поддерживающих проверку подлинности Microsoft Entra.

Использование управляемых удостоверений в коде

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

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

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

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

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

Доступ к объекту BLOB в службе хранилища Azure

using Azure.Identity;
using Azure.Storage.Blobs;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);                        

var blobServiceClient1 = new BlobServiceClient(new Uri("<URI of Storage account>"), credential);
BlobContainerClient containerClient1 = blobServiceClient1.GetBlobContainerClient("<name of blob>");
BlobClient blobClient1 = containerClient1.GetBlobClient("<name of file>");

if (blobClient1.Exists())
{
    var downloadedBlob = blobClient1.Download();
    string blobContents = downloadedBlob.Value.Content.ToString();                
}

Доступ к секрету, хранящемуся в Azure Key Vault

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
using Azure.Core;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);        

var client = new SecretClient(
    new Uri("https://<your-unique-key-vault-name>.vault.azure.net/"),
    credential);
    
KeyVaultSecret secret = client.GetSecret("<my secret>");
string secretValue = secret.Value;

Доступ к Базе данных SQL Azure

using Azure.Identity;
using Microsoft.Data.SqlClient;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};

AccessToken accessToken = await new DefaultAzureCredential(credentialOptions).GetTokenAsync(
    new TokenRequestContext(new string[] { "https://database.windows.net//.default" }));                        

using var connection = new SqlConnection("Server=<DB Server>; Database=<DB Name>;")
{
    AccessToken = accessToken.Token
};
var cmd = new SqlCommand("select top 1 ColumnName from TableName", connection);
await connection.OpenAsync();
SqlDataReader dr = cmd.ExecuteReader();
while(dr.Read())
{
    Console.WriteLine(dr.GetValue(0).ToString());
}
dr.Close();	

Использование библиотеки проверки подлинности Майкрософт (MSAL) для доступа к ресурсам Azure

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

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

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

using Microsoft.Identity.Client;
using System;

string resource = "https://vault.azure.net";

// Applies to system-assigned managed identities only
IManagedIdentityApplication mi = ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.SystemAssigned)
    .Build();

// Applies to user-assigned managed identities only
string userAssignedManagedIdentityClientId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx";
IManagedIdentityApplication mi = ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.WithUserAssignedClientId(userAssignedManagedIdentityClientId))
    .Build();

// Acquire token
AuthenticationResult result = await mi.AcquireTokenForManagedIdentity(resource)
    .ExecuteAsync()
    .ConfigureAwait(false);

if (!string.IsNullOrEmpty(result.AccessToken))
{
    Console.WriteLine(result.AccessToken);
}

Подключение к ресурсам, которые не поддерживают проверку подлинности с Microsoft Entra ID или на основе токенов в библиотеках.

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

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

Рекомендации, если вы обрабатываете токены напрямую

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

Кэшируйте приобретаемые токены

Для повышения производительности и надежности мы рекомендуем, чтобы ваше приложение кэшировало маркеры в локальной памяти или шифровало их, если вы хотите сохранить их на диске. Маркеры управляемого удостоверения действительны в течение 24 часов, поэтому нет смысла регулярно запрашивать новые маркеры, так как из конечной точки, выдавшей маркер, будет возвращен кэшированный маркер. Если вы превысите лимит запросов, вы будете ограничены в скорости и получите ошибку HTTP 429.

Когда вы получаете токен, вы можете установить срок действия кэша токенов за 5 минут до expires_on (или эквивалентного свойства), который будет возвращен при создании токена.

Проверка маркеров

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

Не показывайте и не перемещайте токены

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

Следующие шаги