Les opérateurs cachés d'Azure : un modèle de menace pour les identités gérées au niveau de la plateforme

Dans cet article, nous allons examiner, nommer, définir et modéliser les menaces liées à un type d'identité Azure qui fonctionne discrètement au sein de chaque tenant client — jamais documenté sous un nom précis, dont vous n'êtes pas propriétaire et qui ne vous est jamais entièrement visible. Si un membre de l'équipe Azure souhaite clarifier le terme officiel désignant ces identités, je suis à sa disposition par message privé.

Introduction

Lorsque les équipes de sécurité pensent aux identités gérées dans Azure, elles pensent à celles qu'elles créent : une identité attribuée par le système sur une machine virtuelle, ou une identité gérée attribuée par l'utilisateur et associée à un service d'application. Ces identités sont gérées par le client : c'est vous qui les créez, leur donnez un nom, leur attribuez des rôles et les supprimez.

Il existe toutefois une autre catégorie d'identités gérées que vous n'avez pas créées, que vous ne pouvez pas voir dans votre portail et que vous ne pouvez pas contrôler. Il s'agit des identités qu'Azure crée pour lui-même afin d'exploiter la plateforme en votre nom.

Je les appelle « identités gérées au niveau de la plateforme » (PLMI).

De quoi s'agit-il ?

Les identités gérées au niveau de la plateforme sont des identités gérées par Azure. Elles utilisent le même chemin d'accès aux jetons, les mêmes points de terminaison de métadonnées et le même modèle RBAC que toutes les autres identités gérées, mais leur propriété et leur cycle de vie diffèrent radicalement de ceux des identités gérées attribuées par le système ou des identités gérées attribuées par l'utilisateur auxquelles nous sommes tous habitués :

Ces identités sont attribuées aux fournisseurs de ressources Azure, c'est-à-dire aux services d'arrière-plan qui constituent Azure. Par exemple, lorsque vous déployez une connexion API ou une application logique, c'est l'identité au niveau de la plateforme qui opère en arrière-plan, effectuant des actions en votre nom pour assurer le bon fonctionnement du service.

Le problème du choix du nom

Il n'existe pas de terme unique et accessible au grand public pour désigner ces identités. La documentation de l'écosystème Microsoft leur a toutefois donné de nombreuses appellations :

• Identités de plateforme ou MSI de plateforme : un terme générique utilisé en interne pour désigner les identités détenues par Azure lui-même
• Identités des fournisseurs de ressources — par exemple, l'identité utilisée par Microsoft.ApiManagement ou Microsoft.Logic
• Identités gérées en interne
• Identités de service ou MSI de service : terme générique désignant les identités utilisées par les services Azure
• « Identité backend » ou « Entité backend » - terminologie utilisée dans les outils internes
• Identités gérées en interne (Internal MSI)

⚠️ Ce qu'elles ne sont PAS : il ne faut pas confondre les identités gérées au niveau de la plateforme avec les entités de service propriétaires (également appelées applications propriétaires Microsoft, ou FPSP). Les FPSP sont les identités dont je parle dans la livre blanc « Comparaison des identités de machine gérées par CSP » : elles résident dans Entra ID en tant qu’applications d’entreprise (par exemple, SharePoint Online, Microsoft Teams) et sont visibles dans votre tenant. Les identités gérées au niveau de la plateforme constituent une catégorie totalement distincte.

Si vous travaillez chez Azure et que vous savez exactement comment ces éléments devraient s'appeler, n'hésitez pas à nous contacter. 

Comment en repérer un

Étant donné que les identités gérées au niveau de la plateforme (PLMI) résident dans le tenant de Microsoft et non dans le vôtre, la seule indication que vous verrez sera une entrée de journal RBAC indiquant que l'entité provient de l'extérieur de votre tenant. L'entrée de journal ci-dessous est un exemple extrait d'un tenant Azure illustrant le fonctionnement d'une PLMI (les informations identifiables ont été masquées) :

An object ID that returns no result when you run az ad sp show --id <objectId> is a strong indicator that you are looking at a Platform-Level Managed Identity.

Principales caractéristiques architecturales

Voici un bref aperçu de cette architecture :

• Locataire interne de Microsoft: le MI au niveau de la plateforme réside dans le locataire interne de Microsoft.
• Client-locataire: le client détient les ressources en aval (par exemple, Key Vault, Storage).
• RBAC attribué par le client: Contrairement à leurs équivalents sur AWS et GCP, l'autorisation RBAC permettant au PLMI d'accéder à la ressource est attribuée par le client au sein de son propre tenant.
• Accès inter-locataires: le PLMI utilise ces autorisations attribuées par le client pour effectuer des actions au-delà des limites des locataires.

Deux caractéristiques distinctives les différencient des identités gérées par les clients :

1. Multitenance: une identité gérée au niveau de la plateforme, unique pour un fournisseur de ressources donné, est utilisée pour gérer l'ensemble des locataires clients. Il s'agit d'un acteur global, et non d'un acteur propre à chaque client.
2. Entièrement gérée par CSP: l'identité elle-même réside dans l'environnement propre à Microsoft. Les clients ne peuvent ni la modifier, ni la restreindre, ni même en répertorier les détails.

C'est là que réside la tension fondamentale : ces identités sont des acteurs mondiaux jouissant de privilèges importants. Comme elles n'appartiennent pas à votre environnement, le seul contrôle direct que vous exercez sur elles réside dans les autorisations RBAC que vous leur attribuez. Mais comme nous le verrons, ces attributions sont généralement nécessaires pour permettre le fonctionnement de la plateforme PaaS. La seule « option de refus » consiste souvent simplement à ne pas utiliser le service en question.

Quels sont les risques ?

L'architecture décrite ci-dessus donne lieu à un type particulier de vulnérabilité : une « confusion de mandataires entre locataires » (Cross-Tenant Confused Deputy).

Une attaque par « deputy confused » se produit lorsqu'un intermédiaire puissant – un service ou un processus agissant pour le compte de plusieurs mandants – est amené par la ruse à utiliser ses propres privilèges pour effectuer une action au nom d'une partie non autorisée. Lorsque ce « deputy » est multi-locataire, l'ampleur des répercussions de cette confusion s'étend au-delà des frontières de l'organisation.

Étude de cas : Étude sur les connexions de l'API Binary Security

En mars 2025, des chercheurs de Binary Security ont publié des conclusions qui constituent l'exemple le plus concret et le mieux documenté publiquement d'une utilisation abusive de l'identité gérée au niveau de la plateforme dans le cadre d'une « confusion de rôle ».

Contexte : Qu'est-ce que les connexions API ?

Les connexions API sont des ressources Azure, souvent créées automatiquement lorsque vous ajoutez une action à une application logique. Lorsque vous configurez une application logique pour qu'elle effectue une action à votre place, par exemple récupérer un secret dans un Key Vault, une ressource de connexion API est créée dans votre abonnement ; celle-ci stocke le contexte d'authentification pour ce service backend. C'est la connexion API qui détient – et utilise – l'autorisation d'accéder à votre Key Vault.

En coulisses, cette connexion API est gérée par une identité gérée au niveau de la plateforme appartenant au fournisseur de ressources Microsoft.Web. Lorsque la connexion a été autorisée par la personne ayant configuré l'application logique, cette autorisation a nécessité l'octroi d'un accès RBAC à cette identité au niveau de la plateforme sur la ressource backend.

La vulnérabilité

Alors que la décision de l'administration d'accorder des autorisations RBAC à Microsoft.Web PLMI semblait justifiée, Binary Security a découvert une faille de type « path traversal » dans endpoint/extensions/proxy/{action} du service APIM. Cette faille permettait à toute personne disposant d'un accès « Reader » à l'abonnement d'utiliser ce proxy pour accéder aux secrets Key Vault, à l'instance SQL ou aux connexions externes de N'IMPORTE QUEL locataire — tout ce pour quoi Microsoft.Web avait été configuré.

Ce qui était à la portée d'un agresseur :

Ressource backend

Accessible via un proxy de connexion API

Azure Key Vault

Répertorier tous les secrets ; récupérer les valeurs des secrets

Base de données SQL Azure

Répertorier les bases de données, les ensembles de données et les tables ; lire les lignes des tables

Jira

Répertorier les projets, les utilisateurs et les tickets ; consulter le contenu des tickets

Salesforce

Données de compte, fiches de contact

Azure Defender ATP

Alertes, incidents et données d'enquête

Blobs de stockage Azure

Contenu du blob

Dans l'exemple de Jira, Binary Security a également découvert une vulnérabilité SSRF : l'en-tête X-Request-Jirainstance n'était pas validé, ce qui permettait à un pirate de rediriger les requêtes vers un serveur sous son contrôle et d'extraire le jeton API Jira stocké dans la connexion.

Le schéma d'attaque

Voici comment se déroule l'attaque :

• Étape 1: Un attaquant (disposant uniquement d'un accès « Reader » à l'abonnement de la victime) envoie une requête GET au endpoint proxy de la connexion, en utilisant une charge utile de type « path traversal » (« ../../../ ») pour contourner la portée prévue de l'API.
• Étape 2: Azure Resource Manager (ARM) vérifie si l'attaquant dispose d'un accès de type « Reader ». Comme il s'agit d'une requête GET, ARM répond « ✅ Oui - opération en cours ».
• Étape 3: ARM transfère l'appel vers l'interface de gestion au niveau de la plateforme afin d'appeler l'API du backend.
• Étape 4: L'interface de gestion (MI) au niveau de la plateforme vérifie ses propres autorisations RBAC sur Key Vault. Comme l'accès lui a été accordé lors de la création de la connexion, elle poursuit l'opération.
• Étape 5: Le module d'identification (MI) au niveau de la plateforme récupère le secret dans le Key Vault et le transmet à ARM, qui le transmet à son tour à l'attaquant.

‍

Pourquoi il s'agit d'un « deputy » confus entre plusieurs locataires

Si le schéma ci-dessus montre comment cette entité agit en tant qu’« agent malavisé », la véritable gravité de la vulnérabilité réside dans son impact inter-locataires. La PLMI étant un acteur global, un attaquant situé dans un locataire totalement différent qui découvrirait un endpoint proxy exposé endpoint exploiter les privilèges de la PLMI pour franchir les frontières entre les locataires. Le « confused deputy » (l'identité gérée au niveau de la plateforme) disposait d'une autorité légitime sur plusieurs clients. Il a été amené à exercer cette autorité au nom d'une partie non autorisée issue d'un autre tenant, ce qui en fait un problème inter-tenants plutôt qu'une simple élévation de privilèges locale.

Que faisons-nous pour y remédier ?

Contrairement à AWS – où les clients ont à la fois la possibilité et la responsabilité d'ajouter des clés de condition aux politiques de ressources afin de limiter les attaques de type « confused deputy » –, les clients Azure n'ont aucun contrôle sur l'impact inter-locataires. Ils ont toutefois la possibilité de gérer les risques de type « confused deputy » au sein d'un même locataire, car les autorisations RBAC pour les PLMI ne sont pas attribuées automatiquement ; un administrateur doit les attribuer manuellement. Mais réfléchissons de manière critique : quelle est l'efficacité d'un contrôle lorsque, pour l'utiliser (en n'attribuant pas d'autorisation RBAC), il suffit de ne pas utiliser la fonctionnalité du service ? De plus, la responsabilité des véritables mesures d'atténuation inter-locataires incombe entièrement à Microsoft.

Cela reflète le modèle observé avec les agents Cloud Google Cloud : le fournisseur gère l'identité, c'est donc à lui qu'incombe la responsabilité de la sécurité de son utilisation. L'absence de contrôle du côté du client ne résulte pas d'un outil manquant, mais du fait que le fournisseur assume lui-même la charge de la sécurité.

Mesure d'atténuation n° 1 : Application des chemins de niveau de service (côté fournisseur)

Dans le cas précis de la gestion des API, la mesure d'atténuation prévue consistait en un document Swagger/OpenAPI qui limitait les chemins d'accès pouvant être appelés via le proxy API Connection. L'identité de la plateforme n'invoquait que les chemins d'accès du backend déclarés valides par le document Swagger.

Il s'agit là d'une mesure de protection en principe : limiter les actions auxquelles le PLMI peut être affecté, quel que soit le demandeur.

Le problème : Binary Security a découvert que cette validation Swagger était vulnérable à une attaque par traversée de chemin. En manipulant le chemin, un pirate pouvait sortir du périmètre défini et accéder à des points de terminaison backend arbitraires. Microsoft a corrigé ce problème en silence : les clients ont été protégés à leur insu par un correctif dont ils ignoraient l'existence.

Plus fondamentalement, ce type de contrôle au niveau du chemin d'accès n'est pas applicable de manière universelle à l'ensemble des services Azure. Il s'agit d'un contrôle spécifique à la manière dont le service APIM traite les demandes de connexion API. Les autres fournisseurs de ressources utilisant des identités gérées au niveau de la plateforme ne disposent pas de contrôles équivalents.

Mesure d'atténuation n° 2 : autorisation RBAC lors de la création de la connexion (à la charge du client)

La deuxième mesure d'atténuation est celle qui relève du contrôle du client, même si ce n'est qu'indirectement : l'étape de validation lors de la création d'une connexion API.

Lorsqu'un développeur Logic App crée une connexion API vers un Key Vault, il doit (ou une personne disposant des droits d'accès appropriés) autoriser cette connexion. Cette étape d'autorisation donne lieu à l'octroi d'une autorisation RBAC à l'identité gérée au niveau de la plateforme sur la ressource backend.

C'est le seul point de contrôle significatif dans le flux :

Cette étape d'approbation a son importance, mais pas autant que Microsoft pourrait le croire. Pour mettre en œuvre cette mesure de protection (en n'attribuant pas les autorisations RBAC), vous choisissez en réalité de ne pas utiliser le service. Certes, au sens strict, il s'agit d'une mesure d'atténuation (vous avez du code vulnérable ? Supprimez l'application !). Mais s'appuyer uniquement sur cela signifie qu'il n'existe aucun contrôle côté client pour empêcher un locataire malveillant d'accéder à vos ressources via un PLMI à portée globale une fois que ces autorisations ont été accordées pour activer la fonctionnalité PaaS.

Mesure d'atténuation n° 3 : Lien par référence (côté serveur)

Azure dispose d'un contrôle supplémentaire au niveau du plan de contrôle qui fonctionne comme un contrôle de type « Link by Reference ». Ce contrôle atténue dans une certaine mesure les abus liés au PLMI en garantissant qu'un appelant qui fait référence à une ressource en aval lors d'un déploiement ARM dispose effectivement des autorisations équivalentes sur cette ressource.

Par exemple, si vous essayez de créer un paramètre d'autoscaling Azure Monitor ciblant un ensemble de machines virtuelles (VMSS), ARM vérifie que vous disposez des autorisations Microsoft.Compute/virtualMachineScaleSets/Write sur le VMSS. Si ce n'est pas le cas, le déploiement échoue avec une erreur LinkedAuthorizationFailed avant même que l'identité de la plateforme ne soit utilisée.

Alors, pourquoi cette mesure de protection n'était-elle pas présente dans le service API Management/Logic Apps ? Parce que le contrôle « Link by Reference » est généralement appliqué par Azure Resource Manager (ARM) lors de la création ou de la mise à jour d'une ressource au niveau du plan de contrôle. La vulnérabilité APIM concernait un endpoint d'exécution de proxy du plan de données endpoint /extensions/proxy/{action}) qui acceptait dynamiquement l'URI d'une ressource cible et transférait immédiatement la requête. Étant donné que le endpoint du proxy endpoint en dehors du flux standard de création de ressources ARM et ne mettait pas en œuvre de manière indépendante une vérification des ressources liées pour le chemin transféré, l'identité de la plateforme était invoquée sans validation de l'autorité côté cible de l'appelant.

Éléments de contrôle client manquants

Le contrôle clé qui fait défaut à Azure avec les identités gérées au niveau de la plateforme est toute forme de contrôle préventif côté client visant à éviter les problèmes de « confused deputy » entre locataires. AWS dispose d’un tel contrôle grâce aux clés conditionnelles dans les politiques de ressources, et Google Cloud atténué ce problème en renonçant purement et simplement aux identités de service globales. Ce que Microsoft n'a pas compris, c'est que les acteurs globaux disposant de privilèges élevés ont intrinsèquement la capacité d'abuser des ressources au-delà des frontières organisationnelles. Dans ces scénarios, les fournisseurs cloud doivent mettre des contrôles préventifs directement entre les mains de leurs clients, leur offrant ainsi la tranquillité d'esprit de savoir qu'ils peuvent empêcher de manière effective de tels abus, qui constituent la violation ultime de la confiance de leurs clients.

Les recherches présentées dans cet article s'appuient sur la publication « Binary Security API Connections » (mars 2025), le livre blanc intitulé « Comparing CSP-Managed Machine Identities » (Vectra AI, octobre 2025) et des recherches originales présentées lors de la conférence RSA 2026.

📣 À l'attention de l'équipe Azure : si vous pouvez m'indiquer une documentation de référence concernant les identités gérées au niveau de la plateforme (notamment en ce qui concerne la nomenclature canonique ou la surface de contrôle des politiques), je serais ravi que vous me corrigiez.

‍