.jpeg){kind=logo}
En esta entrada, analizaremos, nombraremos, definiremos y elaboraremos un modelo de amenazas para un tipo de identidad de Azure que ha estado funcionando discretamente dentro de cada tenant de cliente: nunca se ha documentado con un nombre concreto, nunca ha sido de tu propiedad y nunca ha sido totalmente visible para ti. Si alguien del equipo de Azure quiere aclarar cuál es el término canónico para estas identidades, mis mensajes directos están abiertos.
Introducción
Cuando los equipos de seguridad piensan en las identidades gestionadas de Azure, se refieren a las que ellos mismos crean: una identidad asignada por el sistema en una máquina virtual o una identidad gestionada asignada por el usuario y vinculada a un servicio de aplicaciones. Estas identidades son gestionadas por el cliente: tú las creas, les asignas un nombre, les asignas roles y las eliminas.
Sin embargo, existe otro tipo de identidad administrada que no has creado, que no puedes ver en tu portal y que no puedes controlar. Se trata de las identidades que Azure crea para sí mismo con el fin de gestionar la plataforma en tu nombre.
Las denomino «identidades gestionadas a nivel de plataforma» (PLMI).
Qué son
Las identidades administradas a nivel de plataforma son identidades gestionadas por Azure. Utilizan la misma ruta de tokens, los mismos puntos de conexión de metadatos y el mismo modelo RBAC que cualquier otra identidad administrada, pero su propiedad y su ciclo de vida son radicalmente diferentes a los de las identidades administradas asignadas por el sistema o las identidades administradas asignadas por el usuario a las que todos estamos acostumbrados:
Estas identidades se asignan a los proveedores de recursos de Azure, los servicios de fondo que conforman Azure. Por ejemplo, cuando se implementa una conexión API o una aplicación lógica, es la identidad a nivel de plataforma la que actúa en segundo plano, realizando acciones en nombre del usuario para garantizar el funcionamiento del servicio.
El problema de los nombres
No existe un término único y de uso público para referirse a estas identidades. Aunque en la documentación de todo el ecosistema de Microsoft se les ha dado muchos nombres:
- Identidades de plataforma o MSI de plataforma: un término genérico que se utiliza internamente para referirse a las identidades que son propiedad de Azure
- Identidades de proveedores de recursos: por ejemplo, la identidad utilizada por Microsoft.ApiManagement o Microsoft.Logic
- Identidades gestionadas por el propio proveedor
- Identidades de servicio o MSI de servicio: término genérico que se utiliza para referirse a las identidades que emplean los servicios de Azure
- «Identidad de backend» o «Entidad de backend»: terminología utilizada en las herramientas internas
- Identidades gestionadas internamente (Internal MSI)
⚠️ Lo que NO son: Las identidades gestionadas a nivel de plataforma no deben confundirse con los sujetos de servicio propios (también denominados «aplicaciones propias de Microsoft» o FPSP). Los FPSP son las identidades de las que hablo en la comparación de identidades de máquina gestionadas por CSP ; estas residen en Entra ID como aplicaciones empresariales (por ejemplo, SharePoint Online, Microsoft Teams) y son visibles en su inquilino. Las identidades gestionadas a nivel de plataforma son una categoría completamente distinta.
Si trabajas en Azure y sabes con certeza cómo se deben llamar, ponte en contacto con nosotros.
Cómo detectarlo
Dado que las identidades gestionadas a nivel de plataforma residen en el inquilino de Microsoft, y no en el suyo, lo único que verá es una entrada de registro RBAC que indica que el sujeto procede de fuera de su inquilino. La siguiente entrada de registro es un ejemplo extraído de un inquilino de Azure que muestra una PLMI en funcionamiento (con la información identificable ocultada):
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.
Características arquitectónicas principales
Un breve resumen de esta arquitectura:
- Entidad interna de Microsoft: La infraestructura de TI a nivel de plataforma se encuentra en la propia entidad interna de Microsoft.
- Cliente-inquilino: El cliente es el titular de los recursos subordinados (por ejemplo, Key Vault, almacenamiento).
- RBAC asignado por el cliente: A diferencia de sus equivalentes en AWS y GCP, la autorización RBAC que permite al PLMI acceder al recurso es asignada por el cliente dentro de su propio entorno.
- Acceso entre inquilinos: El PLMI utiliza estas autorizaciones asignadas por el cliente para realizar acciones que traspasan los límites de los inquilinos.
Hay dos características distintivas que las diferencian de las identidades gestionadas por el cliente:
- Multitenencia: se utiliza una única identidad gestionada a nivel de plataforma para un proveedor de recursos concreto con el fin de operar en todos los entornos de los clientes. Se trata de un elemento global, no específico para cada cliente.
- Gestión íntegramente a cargo de CSP: La identidad se encuentra en el propio entorno de Microsoft. Los clientes no pueden manipularla, restringirla ni siquiera enumerarla directamente.
Esta es la tensión fundamental: estas identidades son agentes globales con amplios privilegios. Dado que operan fuera de tu entorno, el único control directo que tienes sobre ellas son los permisos RBAC que les asignas. Pero, como veremos, esas asignaciones suelen ser necesarias para que la funcionalidad PaaS funcione. A menudo, la única forma de «excluirse» es, sencillamente, no utilizar el servicio.
¿Qué puede salir mal?
La arquitectura anterior da lugar a un tipo específico de vulnerabilidad: un «Confused Deputy» entre distintos inquilinos.
Un ataque de «delegado confundido» se produce cuando se engaña a un intermediario con amplios poderes —un servicio o proceso que actúa en nombre de varios mandantes— para que utilice sus propios privilegios con el fin de realizar una acción en nombre de una parte no autorizada. Cuando el delegado es multitenant, el alcance de esa confusión traspasa los límites de la organización.
Estudio de caso: Investigación sobre las conexiones de la API de Binary Security
En marzo de 2025, investigadores de Binary Security publicaron unos hallazgos que constituyen el ejemplo más concreto y documentado públicamente de un uso indebido de la identidad gestionada a nivel de plataforma como «agente confuso».
Antecedentes: ¿Qué son las conexiones API?
Las conexiones de API son recursos de Azure que, a menudo, se crean automáticamente al añadir una acción a una aplicación lógica. Cuando configuras una aplicación lógica para que realice una acción en tu nombre —por ejemplo, recuperar un secreto de un Key Vault—, se crea un recurso de conexión de API en tu suscripción que almacena el contexto de autenticación para ese servicio de backend. La conexión de API es la que contiene —y utiliza— el permiso para acceder a tu Key Vault.
Entre bastidores, esa conexión API es gestionada por una identidad administrada a nivel de plataforma que pertenece al proveedor de recursos Microsoft.Web. Cuando quien configuró la aplicación lógica autorizó la conexión, dicha autorización requirió una concesión RBAC a esta identidad a nivel de plataforma en el recurso de fondo.
La vulnerabilidad
Aunque parecía lógico que la administración tuviera que autorizar permisos RBAC para Microsoft.Web PLMI, Binary Security descubrió un problema de traversal de ruta en el punto final /extensions/proxy/{action} del servicio APIM. Esta vulnerabilidad permitía a cualquier persona con acceso de «Lector» a la suscripción aprovechar ese delegado para acceder a los secretos de Key Vault, a la instancia de SQL o a las conexiones externas de CUALQUIER cliente, independientemente de lo que se hubiera configurado en Microsoft.Web para permitir el acceso.
Lo que quedó al alcance del atacante:
Recurso de backend
Accesible a través de un proxy de conexión API
Azure Key Vault
Mostrar todos los secretos; recuperar los valores de los secretos
Azure SQL Database
Mostrar bases de datos, conjuntos de datos y tablas; leer filas de tablas
Jira
Mostrar proyectos, usuarios y incidencias; leer el contenido de las incidencias
Salesforce
Datos de la cuenta, registros de contacto
Azure Defender ATP
Alertas, incidentes y datos de investigación
Blobs de Azure Storage
Contenido del blob
En el ejemplo de Jira, Binary Security también detectó un SSRF: el encabezado X-Request-Jirainstance no se validaba, lo que permitía a un atacante redirigir las solicitudes a un servidor controlado por él y sustraer el token de la API de Jira almacenado en la conexión.
El patrón de ataque
A continuación se detalla cómo se desarrolla el ataque:
- Paso 1: Un atacante (que solo tiene acceso de «Lector» a la suscripción de la víctima) envía una solicitud GET al punto final del proxy de la conexión, utilizando una carga útil de recorrido de ruta («../../../») para eludir el ámbito previsto de la API.
- Paso 2: Azure Resource Manager (ARM) comprueba si el atacante tiene acceso de lectura. Al tratarse de una solicitud GET, ARM indica «✅ Sí: se continúa».
- Paso 3: ARM reenvía la llamada al MI a nivel de plataforma para invocar la API del backend.
- Paso 4: El MI a nivel de plataforma comprueba sus propios permisos RBAC en Key Vault. Dado que se le concedió acceso al crear la conexión, continúa.
- Paso 5: El MI a nivel de plataforma recupera el secreto del Key Vault y lo devuelve a ARM, que a su vez se lo entrega al atacante.
Por qué se trata de un «deputado confundido» entre inquilinos
Aunque el flujo anterior ilustra cómo actúa como un «agente confuso», la verdadera gravedad de la vulnerabilidad radica en su impacto entre distintos inquilinos. Dado que la PLMI es un agente global, un atacante de un inquilino completamente diferente que descubra un punto final de proxy expuesto puede aprovechar la autoridad de la PLMI para traspasar los límites entre inquilinos. El «confused deputy» —la identidad gestionada a nivel de plataforma— tenía autoridad legítima sobre múltiples clientes. Fue engañado para que ejerciera esa autoridad en nombre de una parte no autorizada de otro inquilino, lo que lo convirtió en un problema entre inquilinos en lugar de una simple escalada de privilegios local.
¿Qué estamos haciendo al respecto?
A diferencia de AWS —donde los clientes tienen tanto la capacidad como la responsabilidad de añadir claves de condición a las políticas de recursos para limitar los ataques de «confused deputy»—, los clientes de Azure no disponen de controles sobre el impacto entre tenants. Sí tienen control sobre los riesgos de «confused deputy» dentro de un mismo tenant, ya que los permisos RBAC para los PLMI no se asignan automáticamente; debe ser un administrador quien los asigne. Pero pensándolo con espíritu crítico: ¿qué eficacia tiene un control cuando, para utilizarlo (al no asignar un permiso RBAC), lo único que hay que hacer es no utilizar la funcionalidad del servicio? Además, la responsabilidad de las verdaderas medidas de mitigación entre inquilinos recae íntegramente en Microsoft.
Esto refleja el patrón observado con los agentes Cloud Google Cloud : el proveedor controla la identidad, por lo que también debe asumir la responsabilidad de la seguridad de su uso. La ausencia de un control por parte del cliente no se debe a la falta de una herramienta, sino a que el proveedor asume su propia responsabilidad en materia de seguridad.
Medida de mitigación 1: Aplicación de la ruta de nivel de servicio (por parte del proveedor)
En el caso concreto de la gestión de API, la medida de mitigación prevista consistía en un documento Swagger/OpenAPI que restringía las rutas a las que se podía acceder a través del proxy de conexión de la API. La identidad de la plataforma solo invocaría las rutas del backend que el documento Swagger declarara válidas.
En principio, se trata de una medida de mitigación: limitar las acciones a las que se puede destinar el PLMI, independientemente de quién lo solicite.
El problema: Binary Security descubrió que esta validación de Swagger era vulnerable a un ataque de recorrido de ruta. Al manipular la ruta, un atacante podía salirse del ámbito declarado y acceder a puntos finales del backend arbitrarios. Microsoft solucionó este problema de forma silenciosa: los clientes quedaron protegidos sin saberlo gracias a un parche del que nunca supieron que era necesario.
Más importante aún, este tipo de aplicación a nivel de ruta no es aplicable de forma universal en todos los servicios de Azure. Se trata de un control específico de la forma en que el servicio APIM procesa las solicitudes de conexión a la API. Otros proveedores de recursos que utilizan identidades gestionadas a nivel de plataforma no disponen de controles equivalentes.
Medida de mitigación 2: Autorización RBAC al establecer la conexión (responsabilidad del cliente)
La segunda medida de mitigación es aquella que está bajo el control del cliente, aunque solo sea de forma indirecta: el paso de aprobación al crear una conexión API.
Cuando un desarrollador de Logic Apps crea una conexión API con un Key Vault, él mismo (o alguien con los permisos adecuados) debe autorizar la conexión. Este paso de autorización da lugar a una concesión de permisos RBAC a la identidad administrada a nivel de plataforma en el recurso de fondo.
Este es el único punto de control relevante en el flujo:
Este control de aprobación es importante, pero no tanto como Microsoft podría pensar. Para aplicar esta medida de mitigación (al no asignar los permisos RBAC), en la práctica se está optando por no utilizar el servicio. Claro, en su sentido más estricto, es una medida de mitigación (¿tienes código vulnerable? ¡Elimina la aplicación!). Pero confiar únicamente en esto significa que no hay controles por parte del cliente para impedir que un inquilino malintencionado acceda a tus recursos a través de un PLMI de ámbito global una vez que se conceden esos permisos para habilitar la funcionalidad PaaS.
Medida de mitigación 3: Enlace por referencia (del lado del proveedor)
Azure cuenta con una comprobación adicional del plano de control que actúa como un control de «vínculo por referencia». Este control mitiga en cierta medida el uso indebido de PLMI al garantizar que un solicitante que haga referencia a un recurso subordinado durante una implementación de ARM posea realmente permisos equivalentes sobre dicho recurso.
Por ejemplo, si intentas crear una configuración de autoescalado de Azure Monitor dirigida a un conjunto de máquinas virtuales en escala (VMSS), ARM comprueba que dispongas de permisos de tipo «Microsoft.Compute/virtualMachineScaleSets/Write» sobre el VMSS. Si no es así, la implementación falla con un error «LinkedAuthorizationFailed» antes incluso de que se active la identidad de la plataforma.
Entonces, ¿por qué no se aplicó esta medida de mitigación en el servicio API Management/Logic Apps? Porque el control «Link by Reference» suele ser aplicado por Azure Resource Manager (ARM) durante la creación o actualización de un recurso en el plano de control. La vulnerabilidad de APIM afectaba a un punto de conexión de tiempo de ejecución del proxy del plano de datos (/extensions/proxy/{action}) que aceptaba un URI de recurso de destino de forma dinámica y reenviaba la solicitud de inmediato. Dado que el punto de conexión del proxy operaba fuera del flujo estándar de creación de recursos de ARM y no implementaba de forma independiente una comprobación de recursos vinculados para la ruta reenviada, se invocaba la identidad de la plataforma sin validar la autoridad del lado del destino del solicitante.
Faltan controles de cliente
El control clave que le falta a Azure con las identidades gestionadas a nivel de plataforma es cualquier tipo de control preventivo por parte del cliente que evite problemas de «confused deputy» entre tenants. AWS cuenta con ese control mediante las claves de condición en las políticas de recursos, y Google Cloud mitigado este problema al prescindir por completo de las identidades de servicio globales. Lo que Microsoft no ha sabido comprender es que los actores globales con altos privilegios tienen, por naturaleza, la capacidad de hacer un uso indebido de los recursos más allá de los límites de la organización. En estos casos, los proveedores cloud deben poner controles preventivos directamente en manos de sus clientes, dándoles la tranquilidad de que pueden prevenir de forma efectiva tales abusos, lo que supone la máxima violación de la confianza con sus clientes.
La investigación que se presenta en esta entrada se basa en la divulgación de conexiones de la API de seguridad binaria (marzo de 2025), el informe técnico «Comparación de identidades de máquina gestionadas por CSP» (Vectra AI, octubre de 2025) y en la investigación original presentada en la Conferencia RSA de 2026.
📣 Una nota para el equipo de Azure: si pueden indicarme alguna documentación oficial sobre las identidades gestionadas a nivel de plataforma —incluida la nomenclatura canónica o el ámbito de control de políticas—, estaría encantado de que me corrigieran.