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 affectées par le système et celles qui sont affectées par l’utilisateur. Les identités affecté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.

Cet article explique comment créer et configurer une identité managée affectée par l’utilisateur. Ce type d’identité est recommandé pour la plupart des scénarios. Si la ressource source que vous utilisez ne prend pas en charge les identités managées affecté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 affectée par le système.

Créer une identité managée affectée par l’utilisateur

Notes

Vous aurez besoin d’un rôle tel que « Contributeur d’identité managée » pour créer une identité managée affectée par l’utilisateur.

  1. Recherchez « Identités managées » à l’aide de la barre de recherche en haut du portail et sélectionnez le résultat correspondant.

Screenshot of searching for managed identities in the portal.

  1. Sélectionnez le bouton « Créer ».

Screenshot showing a managed identity create button in the portal.

  1. Sélectionnez l’abonnement et le groupe de ressources, puis entrez un nom pour l’identité managée.

Screenshot showing a managed identity create screen in the portal.

  1. Sélectionnez « Vérifier + créer » pour exécuter le test de validation, puis sélectionnez le bouton « Créer ».

  2. Quand l’identité est créée, un écran de confirmation s’affiche.

Screenshot showing a managed identity confirmation screen after creation in the portal.

Vous disposez maintenant d’une identité qui peut être associée à une ressource source Azure. Apprenez-en plus sur la gestion des identités managées affectées par l’utilisateur.

Configuration de votre ressource source pour utiliser une identité managée affectée par l’utilisateur

Effectuez les étapes suivantes afin de configurer votre ressource Azure pour qu’elle ait une identité managée à l’aide du portail. Reportez-vous à la documentation relative au type de ressource spécifique pour savoir comment configurer l’identité de la ressource à l’aide de l’interface de ligne de commande, de PowerShell ou du modèle ARM.

Notes

Vous aurez besoin des autorisations d’« écriture » afin de configurer une ressource Azure pour qu’elle ait une identité affectée par le système. Vous aurez besoin d’un rôle tel que « Opérateur d’identité managée » pour associer une identité affectée par l’utilisateur à une ressource Azure.

  1. Recherchez la ressource à l’aide de la barre de recherche en haut du portail.

Screenshot showing a resource being searched for in the portal.

  1. Sélectionnez le lien Identité dans le volet de navigation.

Screenshot showing the link to the identity screen for a resource in the portal.

  1. Sélectionnez l’onglet « Affectée par l’utilisateur ».

  2. Sélectionnez le bouton « Ajouter ».

Screenshot showing a user-assigned identity screen in the portal.

  1. Sélectionnez l’identité affectée par l’utilisateur que vous avez créée précédemment et sélectionnez « Ajouter ».

Screenshot showing a user-assigned identity being selected in the portal.

  1. L’identité est associée à la ressource et la liste est mise à jour.

Screenshot showing a user-assigned identity has been associated with the Azure resource in the portal.

Votre ressource source dispose désormais d’une identité affectée par l’utilisateur qu’elle peut utiliser pour se connecter aux ressources cibles.

Ajout d’autorisations à l’identité

Notes

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.

Votre service d’application a maintenant une identité managée. À présent, vous devez donner à l’identité les autorisations appropriées. Quand vous utilisez cette identité pour interagir avec Stockage Azure, vous devez utiliser le système de contrôle d’accès en fonction du rôle (RBAC) Azure.

  1. Recherchez la ressource à laquelle vous souhaitez vous connecter à l’aide de la barre de recherche en haut du portail.
  2. Sélectionnez le lien « Contrôle d’accès (IAM) » dans le volet de navigation de gauche.

Screenshot showing a resource summary screen in the portal.

  1. Sélectionnez le bouton « Ajouter » en haut de l’écran, puis sélectionnez « Ajouter une attribution de rôle ».

Screenshot showing the add role assignment navigation in the portal.

  1. Une liste de rôles s’affiche. Vous pouvez voir les autorisations spécifiques dont dispose un rôle en sélectionnant le lien « Voir ». Sélectionnez le rôle que vous souhaitez accorder à l’identité et sélectionnez le bouton « Suivant ».

Screenshot showing a role being selected in the portal.

  1. Vous serez invité à sélectionner les membres auxquels le rôle doit être accordé. Sélectionnez l’option « Identité managée », puis le lien « Ajouter des membres ».

Screenshot showing the identity type being selected in the portal.

  1. Un volet contextuel s’affiche à droite. Vous pouvez y effectuer une recherche en fonction du type de l’identité managée. Pour l’option « Identité managée », sélectionnez « Identité managée affectée par l’utilisateur ».

Screenshot showing managed identity being selected in the portal.

  1. Sélectionnez l’identité que vous avez créée précédemment et le bouton « Sélectionner ». Le volet contextuel se ferme et l’identité est ajoutée à la liste.

Screenshot showing an identity being added to a resource in the portal.

  1. Sélectionnez le bouton « Vérifier + attribuer » pour voir le résumé de l’attribution de rôle, puis sélectionnez encore ce bouton pour confirmer.
  2. Sélectionnez l’option « Attributions de rôles ». Une liste des attributions de rôles pour la ressource s’affiche.

Screenshot showing the role assignment has been added in the portal.

Votre identité managée dispose désormais des autorisations appropriées pour accéder à la ressource cible Azure. Apprenez-en davantage sur le contrôle d’accès en fonction du rôle Azure.

Utilisation de l’identité managée dans votre code

Votre service d’application dispose désormais d’une identité managée avec des autorisations. Vous pouvez utiliser l’identité managée dans votre code pour interagir avec les ressources cibles au lieu de stocker les informations d’identification dans votre code.

La méthode recommandée consiste à utiliser la bibliothèque Azure Identity pour votre langage de programmation préféré. Les langages pris en charge incluent .NET, Java, JavaScript, Python, Go et C++. La bibliothèque obtient des jetons d’accès pour vous, ce qui simplifie la connexion aux ressources cibles.

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

À l’exception de la bibliothèque C++, les bibliothèques Azure Identity prennent en charge un type 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 affecté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.

Screenshot showing the client ID for the managed identity in the portal.

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

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 KeyVault à 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