C'est un classique redouté par tous les auditeurs en cybersécurité : un développeur a besoin que son application web (hébergée sur Azure) communique avec une base de données Azure SQL ou lise un secret dans un Key Vault. Pour gagner du temps, il copie la chaîne de connexion ou la clé d'API et la colle directement dans son fichier appsettings.json ou, pire, dans le code source hébergé sur GitHub.
Si ce dépôt est compromis, l'attaquant obtient un accès direct à vos données critiques.
Pour éradiquer ce problème, Microsoft a introduit une fonctionnalité redoutable de simplicité et d'efficacité : les Identités Managées (Managed Identities) pour les ressources Azure.
1. Qu'est-ce qu'une Identité Managée ?
Une identité managée est une fonctionnalité gratuite de Microsoft Entra ID (anciennement Azure AD). Elle fournit à une ressource Azure (comme une machine virtuelle, une App Service, ou une Azure Function) une identité automatiquement gérée dans l'annuaire.
L'avantage majeur ? Vous n'avez aucun identifiant à créer, aucun mot de passe à stocker, et aucune rotation de clé à gérer. Azure s'occupe de tout en arrière-plan. Votre application utilise cette identité pour obtenir des jetons Microsoft Entra (Tokens) et s'authentifier auprès des autres services Azure (Key Vault, SQL, Storage, etc.).
2. Les deux saveurs : System-assigned vs User-assigned
Il est crucial de bien choisir le type d'identité selon l'architecture de votre application :
| Type d'identité | Cycle de vie | Cas d'usage idéal |
|---|---|---|
| System-assigned (Attribuée par le système) | Liée directement à la ressource Azure. Si vous supprimez la ressource (ex: la VM), l'identité est détruite avec. | Une application monolithique tournant sur un seul serveur. La sécurité est strictement confinée à cette ressource. |
| User-assigned (Attribuée par l'utilisateur) | Ressource Azure indépendante. Vous la créez séparément et vous pouvez l'attacher à plusieurs ressources différentes. | Un cluster de plusieurs machines virtuelles (VM Scale Set) qui ont toutes besoin du même accès à une base de données. |
3. Sous le capot : Comment la magie opère-t-elle ?
Prenons l'exemple d'une Azure App Service (votre site web) configurée avec une identité System-assigned qui veut lire un secret dans un Azure Key Vault :
-
Demande de jeton (Token) : Le code de votre application fait une requête HTTP locale vers un point de terminaison spécifique à l'environnement Azure (le Service Metadata Endpoint), accessible uniquement depuis l'intérieur de la ressource.
-
Délivrance : Azure vérifie l'identité de l'App Service et lui délivre un jeton d'accès (Access Token) valide pour Microsoft Entra ID.
-
Authentification : L'application envoie ce jeton au Key Vault.
-
Vérification RBAC : Le Key Vault vérifie si cette identité possède le rôle "Lecteur de secrets" (via Azure RBAC). Si oui, le secret est retourné.
Tout ce flux se déroule sans qu'à aucun moment une clé secrète n'ait été écrite dans votre code.
4. Activer via PowerShell
L'interface du portail Azure est pratique, mais l'automatisation est la clé du Cloud. Voici comment activer une identité System-assigned sur une machine virtuelle existante et lui donner le droit de lire un Key Vault, le tout en PowerShell :
# Prérequis : Module Az installé et session connectée (Connect-AzAccount)
$ResourceGroup = "RG-Production"
$VMName = "SRV-WEB-01"
$KeyVaultName = "kv-secrets-prod-01"
Write-Host "Activation de l'identité managée sur la VM..." -ForegroundColor Cyan
# 1. Activer l'identité System-assigned sur la VM
$VM = Update-AzVM -ResourceGroupName $ResourceGroup -Name $VMName -IdentityType SystemAssigned
Write-Host "Identité générée avec le Principal ID : $($VM.Identity.PrincipalId)" -ForegroundColor Green
# 2. Assigner le rôle RBAC pour lire les secrets du Key Vault
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName
Write-Host "Attribution des droits RBAC sur le Key Vault..." -ForegroundColor Cyan
New-AzRoleAssignment -ObjectId $VM.Identity.PrincipalId `
-RoleDefinitionName "Key Vault Secrets User" `
-Scope $KeyVault.ResourceId
Write-Host "Configuration terminée. La VM peut désormais interroger le Key Vault sans mot de passe !" -ForegroundColor Green
5. Références officielles Microsoft
Pour intégrer ces concepts dans vos développements (.NET, Python, Node.js) ou valider les services compatibles, référez-vous toujours à la documentation de l'éditeur :
Conclusion
Le passage aux identités managées n'est plus une simple recommandation, c'est un standard de sécurité (Zero Trust) incontournable pour tout déploiement sur Azure. En supprimant la gestion des mots de passe du cycle de développement, vous soulagez vos équipes de développement tout en fermant l'une des portes d'entrée préférées des pirates. Une architecture moderne est une architecture sans secrets en dur.
