Comment les identités managées éliminent les mots de passe codés en dur dans Azure

Par Mirko Peters · 2026-08-13

Bienvenue sur le blog d’accompagnement de notre podcast ! Si vous développez des applications depuis un certain temps, vous avez sans doute rencontré le problème éternel o…

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Bienvenue de nouveau sur le blog d’accompagnement de notre podcast ! Si vous développez des applications depuis un certain temps, vous avez sans doute déjà été confronté au problème ancestral de la connexion de votre code à une base de données, une API ou un compte de stockage cloud. Traditionnellement, les développeurs résolvaient ce problème en plaçant une chaîne de connexion, un mot de passe de base de données ou un secret client directement dans un fichier de configuration, une variable d’environnement ou, pire encore, en le codant en dur dans le dépôt de code source. Tant que l’application pouvait lire ce secret, elle pouvait s’authentifier et remplir sa mission. Mais que se passe-t-il lorsque ce code est accidentellement poussé vers un dépôt GitHub public ? Que se passe-t-il lorsqu’un employé mécontent quitte l’entreprise, ou qu’un attaquant obtient un accès en lecture à vos paramètres d’application ? En un instant, toute votre infrastructure est compromise. Dans l’architecture cloud moderne, ce risque est inacceptable. Aujourd’hui, nous allons examiner en détail comment les identités managées dans Microsoft Azure éliminent totalement le besoin de mots de passe codés en dur, en remplaçant les secrets statiques par des jetons d’accès dynamiques et de courte durée.

Introduction à la sécurité cloud et aux secrets codés en dur

Le modèle de sécurité traditionnel fondé sur le périmètre reposait largement sur l’idée qu’une fois à l’intérieur du réseau de l’entreprise, on pouvait faire confiance. À l’intérieur de ce périmètre, les applications communiquaient à l’aide de comptes de service statiques, de mots de passe codés en dur et de jetons de longue durée qui expiraient rarement, voire jamais. Si un acteur malveillant parvenait à franchir ce périmètre, il disposait d’un véritable trésor d’identifiants statiques pouvant être réutilisés indéfiniment.

Le cloud computing a totalement fait voler ce périmètre en éclats. Nos charges de travail s’étendent désormais sur des environnements multicloud, des centres de données sur site, des plateformes SaaS et des fonctions serverless distribuées. Dans ce nouveau contexte, la sécurité doit suivre l’identité de la charge de travail elle-même. Les secrets codés en dur sont des bombes à retardement. Ils ne sont pas renouvelés automatiquement, sont notoirement difficiles à auditer et ne laissent aucune marge d’erreur en cas d’exposition. Pour atteindre une véritable sécurité Zero Trust, nous devons totalement dissocier les identifiants de notre code source. Il nous faut un mécanisme d’authentification permettant aux applications de prouver qui elles sont, sans jamais avoir besoin de connaître ou de stocker un mot de passe.

Comprendre les identités utilisateur et les identités de charge de travail dans Entra ID

Pour comprendre l’évolution de la sécurité cloud, il faut d’abord examiner la manière dont Microsoft Entra ID gère les entités qui accèdent à nos systèmes. D’une manière générale, Microsoft Entra ID classe les identités en deux grandes catégories : les identités utilisateur et les identités de charge de travail.

Les identités utilisateur représentent des êtres humains : employés, partenaires, prestataires et clients. Les humains interagissent avec les systèmes de manière dynamique et s’authentifient à l’aide de méthodes adaptées aux personnes, comme les mots de passe, Windows Hello Entreprise, les clés de sécurité FIDO2 et l’authentification multifacteur. Les humains oublient leurs mots de passe, sont victimes d’attaques par hameçonnage et nécessitent des réinitialisations de mot de passe par les administrateurs.

Les identités de charge de travail, en revanche, représentent des logiciels. Cela inclut les applications, les services d’arrière-plan, les scripts d’automatisation, les Azure Functions, les Logic Apps, les pipelines de déploiement DevOps et les agents IA. Les charges de travail ne boivent pas de café, ne cliquent pas sur des courriels d’hameçonnage et ne peuvent pas valider une invite d’authentification multifacteur interactive sur un smartphone. Elles doivent s’authentifier de manière non interactive, programmatique et continue. Traiter une identité de charge de travail comme une identité utilisateur en lui attribuant un mot de passe statique est l’un des écueils les plus courants de l’architecture cloud. Les identités de charge de travail exigent leurs propres modèles de gouvernance spécialisés, une gestion de leur cycle de vie et des flux d’authentification automatisés.

Démystifier les inscriptions d’applications, les principaux de service et les identités managées

Si vous avez passé du temps à configurer des applications dans Microsoft Entra ID, vous avez certainement rencontré trois termes qui prêtent fréquemment à confusion : les inscriptions d’applications, les principaux de service et les identités managées. Décortiquons-les simplement.

Un enregistrement d’application constitue la définition globale, ou le plan, de votre application. Lorsque vous enregistrez une application dans Microsoft Entra ID, vous créez son identité globale à l’échelle de l’ensemble de l’écosystème multilocataire. C’est là que vous définissez les autorisations dont l’application pourrait avoir besoin, les points de terminaison d’authentification qu’elle utilise et les URI qui lui sont associés. Considérez l’enregistrement d’application comme le modèle de passeport.

Un principal de service est l’instance locale de cette application au sein d’un locataire donné. Si une application est multilocataire, elle disposera d’un enregistrement d’application dans le locataire de l’éditeur, mais d’un principal de service distinct dans chaque locataire client où elle est déployée et consentie. Le principal de service est l’endroit où les administrateurs attribuent effectivement les autorisations, appliquent les stratégies d’accès conditionnel et contrôlent qui peut accéder à l’application localement. Considérez le principal de service comme le passeport estampillé, celui qui permet d’entrer dans un pays précis.

Une identité managée pousse ce concept plus loin, spécifiquement pour les ressources s’exécutant dans Microsoft Azure. Au lieu qu’un développeur doive créer manuellement un enregistrement d’application, générer un secret client, stocker ce secret dans une variable d’environnement et écrire du code pour gérer le cycle de vie de l’authentification, Azure prend en charge l’ensemble du processus en coulisse. Azure crée, gère et renouvelle automatiquement les informations d’identification sous-jacentes à votre place. Le développeur indique simplement à la ressource Azure d’utiliser son identité managée, et Azure se charge du reste.

Comment les identités managées éliminent les mots de passe et les informations d’identification codées en dur

La force des identités managées réside dans la manière dont elles modifient fondamentalement la transaction d’authentification. Lorsque vous utilisez une identité managée pour une ressource Azure, comme Azure App Service, une machine virtuelle ou une Azure Function, aucun mot de passe, secret ou certificat n’est stocké dans votre code ou dans vos paramètres de configuration.

Lorsque votre application a besoin d’accéder à une ressource protégée, telle qu’une base de données ou une API, elle ne consulte pas un mot de passe enregistré. Elle effectue plutôt un appel local vers le point de terminaison du service de métadonnées d’instance Azure (IMDS), accessible uniquement depuis cette ressource Azure spécifique. La plateforme sous-jacente de la ressource Azure demande directement à Microsoft Entra ID, au nom de l’application, un jeton web JSON (JWT) de courte durée.

Microsoft Entra ID vérifie l’identité de la ressource Azure, émet un jeton d’accès signé cryptographiquement, dont la durée de vie est très courte (généralement d’environ une heure), et le renvoie à l’application. L’application utilise ensuite ce jeton pour s’authentifier auprès du service cible. Comme le jeton expire rapidement, même si un attaquant parvient à l’intercepter, la fenêtre de vulnérabilité reste extrêmement étroite. De plus, comme aucun mot de passe statique n’est inscrit dans le code, il n’existe aucun élément qu’un développeur pourrait divulguer par accident dans un dépôt public.

Intégrer Azure Key Vault et des jetons d’accès à courte durée

Si les identités managées éliminent le besoin de mots de passe applicatifs, vous vous demandez peut-être comment les applications gèrent les secrets véritablement externes, comme les clés d’API de services tiers qui ne prennent pas en charge l’authentification Microsoft Entra. C’est là qu’intervient Azure Key Vault, qui fonctionne main dans la main avec les identités managées.

Plutôt que de coder en dur une clé d’API tierce dans votre code source, vous stockez ce secret de manière sécurisée dans Azure Key Vault. Vous accordez ensuite à l’identité managée de votre ressource Azure l’autorisation de lire les secrets de ce coffre de clés, à l’aide d’Azure RBAC (contrôle d’accès basé sur les rôles) ou de stratégies d’accès Key Vault.

Au démarrage de l’application, celle-ci utilise son identité managée pour s’authentifier auprès d’Azure Key Vault, récupère dynamiquement en mémoire la clé d’API tierce requise, puis l’utilise. À aucun moment, des informations d’identification ne sont exposées dans le code source. L’application utilise un mécanisme sécurisé fondé sur l’identité pour obtenir un secret, au lieu de s’appuyer sur une chaîne statique intégrée dans un fichier de configuration.

Sécuriser les identités de charge de travail par le moindre privilège et la gouvernance

Éliminer les mots de passe codés en dur est un gain considérable pour la sécurité, mais déployer des identités managées ne relève pas d’un modèle opérationnel « on configure et on oublie ». Les identités de charge de travail exigent une gouvernance rigoureuse, tout comme les comptes d’utilisateurs humains.

Avant tout, vous devez appliquer strictement le principe du moindre privilège. N’attribuez pas de rôles de contributeur étendus ni d’autorisations Microsoft Graph excessives à une identité de charge de travail simplement pour faire fonctionner les choses rapidement. Si un script d’automatisation en arrière-plan doit uniquement lire des éléments d’un conteneur Azure Storage précis, accordez-lui le rôle Lecteur de données Blob Storage sur ce conteneur exact, et rien de plus. Si cette identité de charge de travail venait à être compromise, le rayon d’impact resterait minime.

Ensuite, vous devez surveiller et auditer vos identités de charge de travail en continu. Les organisations créent fréquemment des principaux de service et des identités managées pour des projets de preuve de concept, des scripts d’automatisation et des intégrations temporaires, puis les laissent actifs indéfiniment avec des privilèges élevés. Mettez en place des revues de sécurité régulières pour identifier les principaux de service orphelins, les comptes d’automatisation inutilisés et les identifiants obsolètes. L’exploitation de fonctionnalités comme Microsoft Entra ID Protection et la mise en place d’une journalisation robuste via Azure Monitor vous offrent une visibilité complète sur le moment et la manière dont vos identités de charge de travail accèdent à votre environnement.

Choisir la bonne stratégie d’identité pour chaque charge de travail cloud

Face à la multitude d’options disponibles dans l’écosystème d’identité Microsoft, comment choisir la stratégie d’authentification adaptée à votre charge de travail ? La décision dépend généralement de l’endroit où s’exécute votre application et de son architecture.

Si votre code s’exécute dans Microsoft Azure, qu’il s’agisse d’Azure App Services, d’Azure Functions, de machines virtuelles, d’Azure Container Instances ou d’Azure Kubernetes Service, votre premier choix doit toujours être une identité managée. Vous pouvez opter pour une identité managée attribuée par le système (dont le cycle de vie est lié à 1:1 à la ressource Azure) ou pour une identité managée attribuée par l’utilisateur (qui peut être créée indépendamment et attribuée à plusieurs ressources Azure pour faciliter la gestion).

Si votre application s’exécute en dehors d’Azure, par exemple sur des serveurs locaux, dans AWS ou dans le cadre d’un pipeline CI/CD dans GitHub Actions, les identités managées hébergées directement par l’infrastructure Azure ne sont pas une option. Dans ces scénarios, vous devez exploiter la fédération d’identité de charge de travail. Elle permet aux plateformes externes d’échanger directement des jetons avec Microsoft Entra ID via une relation de confiance OpenID Connect (OIDC), ce qui supprime totalement la nécessité de gérer, de faire tourner ou de stocker des secrets client de longue durée.

Enfin, pour les applications d’entreprise personnalisées traditionnelles qui requièrent une authentification client lorsque ni les identités managées ni la fédération ne sont envisageables, des certificats soigneusement gérés doivent toujours être privilégiés aux secrets client de longue durée. En combinant les identités de charge de travail Microsoft Entra, Azure Key Vault, les principes Zero Trust et l’accès au moindre privilège, votre organisation peut complètement éradiquer les mots de passe codés en dur et bâtir une architecture cloud remarquablement résiliente.

Conclusion et prochaines étapes pour une sécurité cloud moderne

Les mots de passe codés en dur et les chaînes de connexion statiques appartiennent à une époque révolue de la sécurité informatique. En adoptant les identités de charge de travail Microsoft Entra et les identités managées Azure, nous pouvons éliminer complètement les risques liés aux identifiants intégrés, protéger nos dépôts de code source contre les fuites accidentelles et appliquer un accès au moindre privilège strict à toutes nos applications cloud natives. Les jetons d’accès de courte durée garantissent que, même si un jeton est intercepté, sa durée de vie est trop courte pour causer des dommages durables, faisant ainsi évoluer fondamentalement notre posture de sécurité d’une défense réactive vers une protection proactive.

Pour approfondir ce sujet et découvrir des conseils de mise en œuvre concrets issus du terrain, n’hésitez pas à écouter l’épisode de podcast associé : Entra Workload Identities - Simply Explained. Écoutez-nous détailler ces concepts afin de vous aider à sécuriser vos environnements Azure et Microsoft 365 comme un pro !