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


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

Ресурсы 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 или маркера в библиотеках

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

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

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

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

Кэширование приобретаемых маркеров

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

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

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

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

Не предоставляйте и не перемещайте маркеры

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

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