Identités managées affectées par le système ou par l’utilisateur dans Azure : laquelle choisir ?

By Mirko Peters · 2026-10-26

Comparez les identités managées affectées par le système et celles affectées par l’utilisateur dans Azure. Découvrez quel type d’identité choisir pour réduire la charge administrative et faire évoluer vos solutions en toute sécurité.

Automatically translated with AI from the original post. Read the English original

Choisir entre une identité managée affectée par le système et une identité managée affectée par l’utilisateur dans Azure est l’une des décisions d’architecture les plus importantes pour la sécurité cloud et la charge administrative. Si les identités affectées par le système sont directement liées au cycle de vie d’une ressource Azure unique, les identités affectées par l’utilisateur fonctionnent comme des entités autonomes pouvant être partagées entre plusieurs ressources. Elles réduisent considérablement les attributions de rôles redondantes et évitent les goulets d’étranglement liés aux limites de jetons dans les environnements automatisés.

Points clés

• Les identités affectées par le système sont créées, gérées et supprimées automatiquement avec la ressource Azure parente.
• Les identités affectées par l’utilisateur existent indépendamment, en tant que ressources Azure autonomes, et peuvent être partagées entre plusieurs machines virtuelles, applications et fonctions.
• Microsoft recommande les identités affectées par l’utilisateur pour la plupart des scénarios impliquant plusieurs ressources, afin de limiter les tâches de gestion et la complexité des attributions de rôles.
• Utiliser des identités affectées par le système dans des environnements de test à forte croissance ou de courte durée peut entraîner une accumulation d’identités et déclencher les limites de débit d’Azure.
• Une même ressource Azure peut héberger à la fois une identité affectée par le système, pour une journalisation isolée, et une ou plusieurs identités affectées par l’utilisateur, pour des charges de travail partagées.

Comprendre les différences fondamentales

Lorsque vous commencez à concevoir des applications cloud sécurisées, sans secrets codés en dur ni chaînes de connexion, vous devez décider de la manière dont vos charges de travail vont s’authentifier auprès de Microsoft Entra ID. Azure propose deux variantes distinctes d’identités managées : affectées par le système et affectées par l’utilisateur. Comprendre leur fonctionnement interne vous fera gagner d’innombrables heures de dépannage et de maintenance administrative pour votre équipe d’ingénierie.

Fonctionnement des identités affectées par le système

Une identité managée affectée par le système s’active directement dans une ressource Azure spécifique, comme une machine virtuelle Azure, un App Service ou une application de fonction. On peut la considérer comme étant créée avec la ressource et supprimée avec elle. Lorsque vous activez une identité affectée par le système sur une machine virtuelle, Azure crée dans Microsoft Entra ID une identité portant exactement le nom de cette ressource.

Le principal avantage de cette approche réside dans sa simplicité et le couplage de son cycle de vie. Comme l’identité est liée à la ressource, vous n’avez jamais à craindre la présence d’identités orphelines dans votre annuaire après la mise hors service d’une machine virtuelle. Si vous supprimez la ressource, Azure supprime automatiquement l’identité à votre place. Toutefois, ce couplage étroit crée des limites architecturales lorsque plusieurs ressources doivent disposer des mêmes autorisations d’accès.

Fonctionnement des identités affectées par l’utilisateur

Une identité managée affectée par l’utilisateur, en revanche, est d’abord créée en tant que ressource Azure autonome. Vous lui donnez un nom personnalisé, vous la gérez indépendamment au sein de vos groupes de ressources et vous la rattachez explicitement à un ou plusieurs services Azure nécessitant un accès. Comme elle n’est liée au cycle de vie d’aucune machine virtuelle ni d’aucun App Service en particulier, elle persiste même si toutes les ressources qui lui sont rattachées sont supprimées.

Cette nature autonome transforme la manière dont les architectes cloud gèrent les accès à grande échelle. Plutôt que de considérer l’authentification comme une relation un-à-un entre un serveur unique et une base de données, les identités affectées par l’utilisateur permettent de construire des modèles d’authentification plusieurs-à-un, dans lesquels des grappes de microservices partagent un même contexte de sécurité, bien géré.

Surcharge administrative et attributions de rôles

Les différences pratiques entre ces deux types d’identités deviennent très nettes lorsqu’on examine la gestion du contrôle d’accès basé sur les rôles (RBAC) dans les grands environnements. Chaque fois que vous accordez à une identité l’accès à un compte de stockage, à un coffre de clés ou à une base de données, vous devez créer une attribution de rôle Azure.

Prenons un scénario d’entreprise courant : quatre machines virtuelles doivent toutes lire des données provenant de deux comptes de stockage Azure distincts. Si vous vous appuyez exclusivement sur des identités affectées par le système, chaque machine virtuelle nécessite sa propre identité dédiée. Pour accorder l’accès, vous devez configurer huit attributions de rôles distinctes, une pour chaque machine sur chaque compte de stockage. Si vous passez à vingt machines virtuelles, le nombre d’attributions de rôles explose de façon exponentielle, ce qui devient un véritable cauchemar administratif.

À l’inverse, si ces mêmes quatre machines virtuelles partagent une seule identité managée affectée par l’utilisateur, vous n’avez besoin de créer que deux attributions de rôles au total. Vous obtenez exactement le même contrôle d’accès granulaire pour une fraction de l’effort de gestion. Lorsque des collaborateurs quittent l’entreprise ou que l’infrastructure est reconstruite, le maintien d’un annuaire propre devient nettement plus simple.

Pièges architecturaux et cas limites

Si les identités affectées par l’utilisateur sont généralement plus efficaces, choisir le mauvais type peut introduire des frictions opérationnelles cachées. Un risque majeur concerne les ressources de calcul éphémères ou les environnements à mise à l’échelle automatique.

Si vous provisionnez et déprovisionnez rapidement, tout au long de la journée, des environnements de développement, de test ou conteneurisés à l’aide d’identités affectées par le système, ces identités s’accumuleront dans Microsoft Entra ID avant que les routines de nettoyage ne s’exécutent. À terme, les organisations peuvent atteindre les limites de débit d’annuaire Azure, ce qui conduit la plateforme à rejeter entièrement les nouvelles demandes de création de ressources. Partager une identité affectée par l’utilisateur entre ces charges de travail éphémères permet d’éviter complètement ce piège.

À l’inverse, les identités affectées par le système se révèlent particulièrement utiles dans deux scénarios précis :

• Audit et non-répudiation : si vos journaux de sécurité doivent prouver de manière certaine quelle machine virtuelle exacte a effectué une action donnée, les identités affectées par le système offrent cette attribution à un niveau très fin, car chaque ressource possède son propre objet d’annuaire unique.
• Nettoyage strict du cycle de vie : si les exigences de conformité imposent que toutes les autorisations d’accès disparaissent à la milliseconde près où une ressource est supprimée, les identités affectées par le système gèrent cela automatiquement, sans intervention humaine.

Gardez à l’esprit que vous n’êtes pas contraint à un choix binaire absolu. Une seule ressource Azure peut disposer à la fois d’une identité affectée par le système pour des opérations privées et sensibles, et d’une ou plusieurs identités affectées par l’utilisateur pour des flux de travail partagés au sein de l’entreprise.

Conclusion

La gestion des identités dans le cloud Microsoft exige de concilier efficacité opérationnelle et frontières de sécurité strictes. En comprenant les différences opérationnelles entre les identités affectées par le système et celles affectées par l’utilisateur, vous pouvez concevoir des architectures robustes et évolutives, qui éliminent les secrets codés en dur sans alourdir inutilement l’administration.

Pour approfondir la manière dont les jetons sont émis, l’intégration d’Azure Key Vault sans mot de passe et les pièges de sécurité courants à éviter, n’hésitez pas à écouter l’épisode complet du podcast pour des analyses d’experts et des stratégies concrètes.

Questions fréquentes

Une seule ressource Azure peut-elle utiliser à la fois une identité managée affectée par le système et une identité managée affectée par l’utilisateur ?

Oui. Une ressource Azure comme une machine virtuelle ou un App Service peut avoir simultanément une identité affectée par le système et une ou plusieurs identités affectées par l’utilisateur activées, ce qui vous permet de combiner des stratégies d’authentification dédiées et partagées.

Que devient une identité affectée par l’utilisateur lorsque la ressource Azure à laquelle elle est rattachée est supprimée ?

Contrairement aux identités affectées par le système, qui sont automatiquement supprimées avec leur ressource parente, les identités affectées par l’utilisateur subsistent en tant qu’objets autonomes indépendants dans Azure, jusqu’à ce qu’un administrateur les supprime explicitement.

Pourquoi Microsoft recommande-t-il les identités affectées par l’utilisateur pour la plupart des scénarios multiressources ?

Microsoft recommande principalement les identités affectées par l’utilisateur afin de réduire la charge administrative et la prolifération des attributions de rôles. Partager une seule identité entre plusieurs ressources de calcul réduit considérablement le nombre d’attributions RBAC à créer et à maintenir.

Les identités managées sont-elles facturées dans Azure ?

Non, les identités gérées attribuées par le système comme celles attribuées par l’utilisateur sont des fonctionnalités gratuites incluses avec Microsoft Entra ID pour les ressources Azure. Des coûts standard peuvent toutefois s’appliquer aux services de calcul ou de stockage sous-jacents auxquels vous accédez.