Identité managée pour une authentification sans mot de passe

Traditionnellement, les applications se connectent à des services Azure comme Storage ou Key Vault à l’aide de chaînes de connexion ou de clés API stockées dans des fichiers de configuration ou des variables d’environnement. Ces identifiants peuvent être accidentellement validés dans le contrôle de version, exposés dans les journaux ou dérobés lors d’une violation de sécurité. Une identité managée supprime entièrement la nécessité pour les applications de stocker des identifiants : Azure émet et renouvelle lui-même un jeton au nom de la ressource, et l’application demande simplement à Azure le jeton actuel lors de l’exécution.

Une identité managée est un principal de service géré automatiquement dans Microsoft Entra ID et lié à une ressource Azure (comme une VM, App Service ou Function App). La plateforme Azure crée et gère les identifiants de l’identité — en les renouvelant régulièrement — afin que votre code ne manipule jamais de mot de passe ni de secret. Les applications exécutées sur la ressource appellent le point de terminaison du service de métadonnées d’instance Azure (IMDS) à l’adresse http://169.254.169.254 pour obtenir un jeton OAuth de courte durée, qu’elles présentent ensuite aux services Azure.

Il existe deux types d’identité managée : une identité affectée par le système est liée à une seule ressource Azure ; elle est créée lorsque vous l’activez sur la ressource et supprimée automatiquement lorsque la ressource est supprimée. Une identité affectée par l’utilisateur est une identité Entra ID indépendante que vous créez séparément avant de l’attacher à une ou plusieurs ressources Azure. Les identités affectées par l’utilisateur sont utiles lorsque plusieurs services (par exemple, plusieurs Function Apps) doivent partager la même identité et les mêmes autorisations RBAC, ce qui évite la duplication des attributions de rôles.

Après avoir activé une identité managée, vous devez lui accorder des autorisations RBAC sur la ressource Azure cible. Par exemple, pour autoriser un App Service à lire des objets blob, attribuez le rôle Storage Blob Data Reader à l’identité managée de l’App Service sur le compte de stockage. Les attributions RBAC suivent le principe du moindre privilège : accordez uniquement les autorisations minimales nécessaires. N’attribuez jamais Owner ou Contributor à une identité managée, sauf en cas de nécessité absolue.

Le Azure SDK fournit une classe DefaultAzureCredential qui essaie automatiquement plusieurs méthodes d’authentification dans l’ordre : variables d’environnement, identité de charge de travail, identité managée, Azure CLI, Visual Studio et d’autres encore. Lorsque votre application s’exécute dans Azure (App Service, VM, Function App), DefaultAzureCredential utilise automatiquement l’identité managée sans aucune modification du code. En local, les développeurs s’authentifient via leur session Azure CLI. Cette classe d’identifiants unique fonctionne dans tous les environnements sans logique conditionnelle.

Un modèle courant consiste à utiliser une identité managée pour accéder aux secrets Azure Key Vault lors de l’exécution. Au lieu de stocker un mot de passe de base de données dans les paramètres de l’application, vous le stockez dans Key Vault et attribuez à l’identité managée de l’application le rôle Key Vault Secrets User sur ce coffre. Au démarrage, l’application récupère le secret depuis Key Vault à l’aide de DefaultAzureCredential. Ce modèle garantit que les secrets ne sont jamais stockés dans le code, les fichiers de configuration ou les variables d’environnement : ils existent uniquement dans Key Vault et sont récupérés de manière éphémère.

Azure SQL Database prend en charge l’authentification Entra ID, ce qui signifie qu’une identité managée peut s’authentifier auprès de SQL sans nom d’utilisateur ni mot de passe. Pour l’activer : définissez un administrateur Entra ID sur le serveur SQL, puis exécutez une instruction CREATE USER dans la base de données cible pour le nom d’affichage de l’identité managée, et accordez-lui le rôle de base de données approprié. L’application se connecte à l’aide de DefaultAzureCredential de l’Azure SDK et d’un jeton d’accès limité à https://database.windows.net/, entièrement sans mot de passe.

Dans Azure Kubernetes Service, les pods individuels peuvent obtenir des jetons d’identité managée à l’aide de l’identité de charge de travail (qui succède à AAD Pod Identity). Vous créez une identité managée affectée par l’utilisateur, la fédérez avec l’émetteur OIDC AKS, annotez le compte de service Kubernetes, puis le webhook Azure Workload Identity injecte les variables d’environnement nécessaires afin que le DefaultAzureCredential du pod puisse obtenir un jeton. Cela étend l’authentification sans mot de passe aux microservices conteneurisés sans stocker de secrets dans des objets Kubernetes Secrets.

Même si les identifiants d’identité managée sont invisibles aux développeurs, tous les événements d’émission de jetons et d’accès aux ressources sont consignés. Les journaux de connexion Entra ID enregistrent chaque demande de jeton effectuée par une identité managée, y compris la ressource consultée, l’heure et le succès ou l’échec de la demande. Les journaux d’activité Azure Storage et les journaux d’audit Key Vault enregistrent les opérations précises effectuées à l’aide du jeton. Ces journaux sont essentiels pour les audits de sécurité et les enquêtes sur les incidents impliquant des identités managées.

Si votre application utilise actuellement des chaînes de connexion ou des clés API, migrez vers une identité managée en trois étapes : Étape 1 — Activez une identité managée sur la ressource de calcul. Étape 2 — Attribuez les rôles RBAC appropriés à l’identité sur chaque service cible. Étape 3 — Mettez à jour le code de l’application afin d’utiliser DefaultAzureCredential à la place de la chaîne de connexion. Supprimez la chaîne de connexion de la configuration App Service et de Key Vault une fois la migration vérifiée. Cette migration peut généralement être réalisée avec un minimum de modifications de code dans les applications Azure SDK modernes.

L’identité managée offre quatre avantages de sécurité essentiels par rapport à l’authentification fondée sur des identifiants : aucun stockage d’identifiants — rien à dérober ou à valider accidentellement. Renouvellement automatique — Azure renouvelle les certificats sous-jacents sans interruption de service. Autorisations limitées — les identités reçoivent uniquement les rôles RBAC dont elles ont besoin, conformément au principe du moindre privilège. Traçabilité complète — toutes les tentatives d’accès sont consignées dans Entra ID et dans les journaux d’audit du service consulté. Pour toute nouvelle intégration de service Azure, l’identité managée devrait être l’approche d’authentification par défaut.

Vérifiez votre compréhension des concepts de Fondamentaux de Microsoft Azure (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’identité managée élimine les identifiants stockés en attribuant aux ressources Azure une identité Entra ID gérée automatiquement, que DefaultAzureCredential dans le SDK Azure utilise de manière transparente l’identité managée dans Azure et les identifiants du développeur en local, et que les affectations de rôles RBAC sur les services cibles contrôlent ce à quoi l’identité peut accéder. Ensuite, nous découvrirons Azure Service Bus pour la messagerie découplée entre les composants d’une application.