Partager via

Connexion de votre application à des ressources sans gérer les informations d’identification

  • Article

Les ressources Azure avec prise en charge des identités managées fournissent toujours une option permettant de spécifier une identité managée pour se connecter aux ressources Azure qui prennent en charge l’authentification Microsoft Entra. Avec la prise en charge des identités managées, les développeurs n’ont pas besoin de gérer les informations d’identification dans le code. Les identités managées représentent l’option d’authentification recommandée quand des ressources Azure qui les prennent en charge sont utilisées. Consultez la vue d’ensemble des identités managées.

Cette page explique comment configurer un service d’application pour qu’il puisse se connecter à Azure Key Vault, au Stockage Azure et à Microsoft SQL Server. Les mêmes principes peuvent être utilisés pour toute ressource Azure prenant en charge les identités managées et qui se connectera aux ressources prenant en charge l’authentification Microsoft Entra.

Les exemples de code utilisent la bibliothèque de client Azure Identity. Il s’agit de la méthode recommandée, car elle gère automatiquement de nombreuses étapes pour vous, notamment l’obtention d’un jeton d’accès utilisé pour la connexion.

À quelles ressources les identités managées peuvent-elles se connecter ?

Une identité managée peut se connecter à n’importe quelle ressource prenant en charge l’authentification Microsoft Entra. En règle générale, aucune prise en charge spéciale n’est requise pour que la ressource autorise des identités managées à se connecter à celle-ci.

Certaines ressources ne prennent pas en charge l’authentification Microsoft Entra ou leur bibliothèque cliente ne prend pas en charge l’authentification avec un jeton. Poursuivez votre lecture pour connaître nos conseils sur l’utilisation d’une identité managée pour accéder de manière sécurisée aux informations d’identification sans avoir à les stocker dans votre code ou dans votre configuration d’application.

Création d’une identité managée

Il existe deux types d’identités managées : celles qui sont attribuées par le système et celles qui sont attribuées par l’utilisateur. Les identités attribuées par le système sont directement liées à une seule ressource Azure. Quand la ressource Azure est supprimée, l’identité l’est aussi. Une identité managée affectée par l’utilisateur peut être associée à plusieurs ressources Azure, et son cycle de vie est indépendant de ces ressources.

Nous vous recommandons d’utiliser une identité managée attribuée par l’utilisateur pour la plupart des scénarios. Si la ressource source que vous utilisez ne prend pas en charge les identités managées attribuées par l’utilisateur, vous devez vous reporter à la documentation du fournisseur de cette ressource pour savoir comment la configurer pour qu’elle ait une identité managée attribuée par le système.

Important

Le compte utilisé pour créer des identités managées a besoin d’un rôle tel que « Contributeur d’identités managées » pour créer une identité managée attribuée par l’utilisateur.

Créez une identité managée attribuée par l’utilisateur à l’aide de votre option préférée :

Après avoir créé une identité managée attribuée par l’utilisateur, notez les valeurs clientId et principalId retournées lors de la création de l’identité managée. Vous utiliserez principalId quand vous ajouterez des autorisations et clientId dans le code de votre application.

Configurer App Service avec une identité managée attribuée par l’utilisateur

Avant de pouvoir utiliser l’identité managée dans votre code, nous devons l’affecter à l’App Service qui l’utilisera. Le processus de configuration d’un App Service pour utiliser une identité managée attribuée par l’utilisateur nécessite que vous spécifiiez l’identificateur de ressource de l’identité managée dans la configuration de votre application.

Ajout d’autorisations à l’identité

Une fois que vous avez configuré votre App Service pour utiliser une identité managée attribuée par l’utilisateur, accordez les autorisations nécessaires à l’identité. Dans ce scénario, nous utilisons cette identité pour interagir avec Stockage Azure. Vous devez donc utiliser le système RBAC (Role Based Access Control) Azure pour accorder les autorisations d’identité managée attribuées par l’utilisateur à la ressource.

Important

Vous aurez besoin d’un rôle tel que « Administrateur d’accès utilisateur » ou « Propriétaire » pour la ressource cible afin d’ajouter des attributions de rôle. Veillez à accorder le privilège minimum nécessaire à l’exécution de l’application.

Toutes les ressources auxquelles vous souhaitez accéder nécessitent l’octroi des autorisations d’identité. Par exemple, si vous demandez un jeton pour accéder à Key Vault, vous devez également ajouter une stratégie d’accès qui comprend l’identité managée de votre application ou de votre fonction. Sinon, vos appels à Key Vault seront rejetés, même si vous utilisez un jeton valide. Il en va de même pour Azure SQL Database. Pour en savoir plus sur les ressources qui prennent en charge les jetons Microsoft Entra, consultez Services Azure prenant en charge l’authentification Microsoft Entra.

Utilisation d’identités managées dans votre code

Une fois que vous avez effectué les étapes décrites ci-dessus, votre App Service dispose d’une identité managée avec des autorisations pour une ressource Azure. Vous pouvez utiliser l’identité managée pour obtenir un jeton d’accès que votre code peut utiliser pour interagir avec les ressources Azure au lieu de stocker les informations d’identification dans votre code.

Nous vous recommandons d’utiliser la bibliothèque Azure Identity pour votre langage de programmation préféré. La bibliothèque obtient des jetons d’accès pour vous, ce qui simplifie la connexion aux ressources cibles.

Apprenez-en davantage sur les bibliothèques Azure Identity ci-dessous :

Utilisation de la bibliothèque Azure Identity dans votre environnement de développement

Les bibliothèques Azure Identity fournissent chacun un type de DefaultAzureCredential. DefaultAzureCredential tente automatiquement une authentification par le biais de plusieurs mécanismes, notamment avec des variables d’environnement ou une connexion interactive. Ce type d’informations d’identification peut être utilisé dans votre environnement de développement avec vos propres informations d’identification. Il peut également être utilisé dans votre environnement Azure de production à l’aide d’une identité managée. Aucune modification de code n’est nécessaire quand vous déployez votre application.

Si vous utilisez des identités managées attribuées par l’utilisateur, vous devez également spécifier explicitement celle avec laquelle vous souhaitez vous authentifier en passant l’ID client de l’identité comme paramètre. Vous pouvez récupérer l’ID client en accédant à l’identité dans le portail Azure.

Accès à un blob dans Stockage 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();                
}

Accès à un secret stocké dans 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;

Accès à Azure SQL Database

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();

Connexion à des ressources qui ne prennent pas en charge l’authentification Microsoft Entra ID ou basée sur un jeton dans les bibliothèques

Certaines ressources Azure ne prennent pas encore en charge l’authentification Microsoft Entra ou leurs bibliothèques clientes ne prennent pas en charge l’authentification avec un jeton. En règle générale, ces ressources sont des technologies open source qui attendent un nom d’utilisateur et un mot de passe ou une clé d’accès dans une chaîne de connexion.

Pour éviter de stocker des informations d’identification dans votre code ou votre configuration d’application, vous pouvez les stocker comme secret dans Azure Key Vault. En utilisant l’exemple ci-dessus, vous pouvez récupérer le secret à partir d’Azure Key Vault à l’aide d’une identité managée et passer les informations d’identification dans votre chaîne de connexion. Avec cette approche, aucune information d’identification ne doit être gérée directement dans votre code ou votre environnement.

Instructions à suivre si vous gérez directement des jetons

Dans certains scénarios, vous devrez peut-être obtenir des jetons pour des identités managées manuellement au lieu d’utiliser une méthode intégrée pour vous connecter à la ressource cible. Ces scénarios incluent l’absence de bibliothèque de client pour le langage de programmation que vous utilisez ou la ressource cible à laquelle vous vous connectez, ou encore la connexion à des ressources qui ne s’exécutent pas sur Azure. Pour obtenir des jetons manuellement, nous vous recommandons de suivre les instructions suivantes :

Mise en cache des jetons que vous obtenez

À des fins de performances et de fiabilité, nous recommandons que votre application mette en cache les jetons en mémoire locale ou de manière chiffrée si vous souhaitez les enregistrer sur disque. Étant donné que les jetons d’identité managée sont valides pendant 24 heures, il n’y a aucun avantage à demander régulièrement de nouveaux jetons. En effet, un jeton mis en cache est retourné à partir du point de terminaison émetteur de jetons. Si vous dépassez les limites de requête, vous serez limité en débit et recevrez une erreur HTTP 429.

Quand vous obtenez un jeton, vous pouvez définir votre cache de jetons pour qu’il expire 5 minutes avant la valeur de la propriété expires_on (ou d’une propriété équivalente) retournée quand le jeton est généré.

Inspection des jetons

Votre application ne doit pas s’appuyer sur le contenu d’un jeton. Le contenu du jeton est destiné uniquement à l’audience (ressource cible) à laquelle il accède et non au client qui demande le jeton. Le contenu du jeton peut changer ou être chiffré par la suite.

Pas d’exposition ou de déplacement de jetons

Les jetons doivent être traités comme des informations d’identification. Ne les exposez pas aux utilisateurs ou à d’autres services, par exemple, à des solutions de journalisation/de monitoring. Ils ne doivent pas être déplacés à partir de la ressource source qui les utilise, sauf pour une authentification auprès de la ressource cible.

Étapes suivantes