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


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

Ресурсы 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, а не для хранения учетных данных в коде.

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

Дополнительные сведения о библиотеках удостоверений Azure см. ниже:

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

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

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

Доступ к большому двоичному объекту в служба хранилища 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();	

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

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

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

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

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

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

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

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

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

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

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

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

Дальнейшие действия