Managed Identity

general

Définition

Une Managed Identity (identité managée) est un type de principal de sécurité dans les plateformes cloud (Azure, AWS, GCP) qui fournit automatiquement une identité à une ressource cloud (machine virtuelle, fonction serverless, conteneur) sans nécessiter de stocker ou de gérer manuellement des credentials (mots de passe, clés d'API, certificats). L'objectif est d'éliminer les secrets applicatifs codés en dur dans le code ou les fichiers de configuration. Le problème que les Managed Identities résolvent est celui des "secrets applicatifs" — comment une application s'authentifie-t-elle auprès d'autres services (base de données, Azure Key Vault, S3 bucket) sans stocker de credentials dans son code ? La solution traditionnelle (stocker un identifiant/mot de passe dans les variables d'environnement ou un fichier de config) est risquée : ces credentials peuvent être exposés via des dépôts Git publics (secret scanning de GitHub trouve des milliers de credentials exposés chaque jour), des dumps de logs, ou des accès non autorisés aux fichiers de configuration. Les Managed Identities délèguent ce problème à la plateforme cloud. Sur Azure, une VM avec une System-assigned Managed Identity obtient automatiquement un token Azure AD via l'API IMDS (Instance Metadata Service) en local (169.254.169.254) — sans stocker de credentials. Le code de l'application appelle l'API IMDS pour obtenir un token JWT, puis utilise ce token pour s'authentifier auprès d'Azure Key Vault, Azure Storage, Azure SQL, etc. Azure gère automatiquement la rotation des credentials sous-jacents — l'application n'a jamais accès aux credentials réels. Sur AWS, le mécanisme équivalent est l'Instance Profile (pour EC2) ou les IAM Roles pour les fonctions Lambda, conteneurs ECS/EKS. Les permissions IAM sont attachées directement à la ressource cloud, et les credentials temporaires (Access Key, Secret Key, Session Token) sont disponibles via l'API IMDSv2. GCP propose les Service Accounts attachés aux instances Compute Engine et Cloud Run. Les Managed Identities sont la fondation du principe "no secrets in code" — elles éliminent la classe entière des vulnérabilités liées aux secrets exposés et simplifient la gestion des rotations de credentials.

Azure Managed Identity — System-assigned vs User-assigned

Azure propose deux types de Managed Identities. System-assigned : créée automatiquement pour une ressource Azure spécifique (une VM, une Azure Function, un App Service), liée au cycle de vie de cette ressource (supprimée quand la ressource est supprimée), avec une identité unique par ressource. User-assigned : créée indépendamment, peut être attachée à plusieurs ressources Azure (utile si plusieurs VMs ont besoin des mêmes accès — plutôt que d'assigner les mêmes rôles Azure RBAC à chaque identité système, on assigne à l'identité user-assigned une fois). Le code utilisant le SDK Azure (Python: `DefaultAzureCredential()`, .NET: `new DefaultAzureCredential()`) obtient automatiquement le token via la Managed Identity si disponible, ou via d'autres mécanismes (environnement, certificat) en fallback — pas de modification de code entre développement et production.

AWS IMDSv2 — sécurité des instance profiles

AWS IMDSv1 (Instance Metadata Service version 1) présentait une vulnérabilité : des requêtes HTTP depuis n'importe quel processus sur l'instance (y compris des attaques SSRF — Server-Side Request Forgery) pouvaient accéder aux credentials temporaires de l'instance via http://169.254.169.254/latest/meta-data/iam/security-credentials/. La célèbre attaque Capital One (2019) utilisait exactement ce vecteur : un SSRF dans une application web permettait à l'attaquant d'extraire les credentials AWS de l'EC2 depuis l'IMDS v1. IMDSv2 résout ce problème par un token de session requis : avant d'accéder aux métadonnées, une requête PUT doit d'abord obtenir un token TTL — les attaques SSRF simples (GET uniquement) ne peuvent pas obtenir ce token. AWS recommande de forcer IMDSv2 sur toutes les instances (via `HttpTokens: required` dans le launch template).

Secrets Manager vs Managed Identity — complémentarité

Managed Identities et Secrets Managers (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault) sont complémentaires. Les Managed Identities permettent à une ressource cloud de s'authentifier auprès d'autres services Azure/AWS SANS credentials stockés. AWS Secrets Manager stocke les secrets nécessaires pour des ressources qui ne supportent pas les rôles IAM natifs (bases de données RDS avec username/password, APIs tierces avec clés d'API). La combinaison idéale : une Lambda ou EC2 utilise son IAM Role (Managed Identity) pour s'authentifier auprès de Secrets Manager, Secrets Manager retourne les credentials de la base de données — la Lambda elle-même n'a jamais de credentials stockés. La rotation automatique des secrets (Secrets Manager peut automatiquement faire tourner les mots de passe RDS toutes les X jours) complète l'élimination des secrets statiques long-terme.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis