La taxonomía de las identidades de carga de trabajo en Entra ID: entidades de servicio, aplicaciones empresariales y otras formas de confusión organizada

A partir de aquí, nuestra guía entra en detalles más técnicos, así que vamos a analizarlo con detenimiento.

Empecemos por lo básico: en pocas palabras, el término «identidad de carga de trabajo» es un concepto genérico que utiliza Microsoft para describir múltiples tipos de identidades no humanas que operan dentro de Entra ID. Estas identidades permiten que las aplicaciones, los servicios, los recursos en la nube, las cargas de trabajo de automatización —y ahora también los agentes—se autentiquen e interactúen con otros sistemas con poca o ninguna intervención humana.

Esto es lo importante: todas las identidades de carga de trabajo, incluidos los tipos de identidad de agente recientemente introducidos, se resuelven en última instancia en un único tipo de objeto subyacente: el «Service Principal».

Y, sinceramente, tiene sentido.

Cómo entender los «Service Principals»

En servicePrincipal La entidad es probablemente el objeto de identidad más flexible de Entra ID. Si se examina su esquema a través del punto final $metadata de Microsoft Graph OData, el número de propiedades, propiedades de navegación y acciones vinculadas que expone este objeto ya dice mucho sobre su función en la plataforma.

Esa base del principal de servicio está realizando una labor muy discreta en este ámbito. Se conecta con muchas de las interfaces y subsistemas que gestiona Entra ID para dar soporte a funciones como la gestión de credenciales, la concesión de permisos OAuth, la asignación de roles a aplicaciones, la pertenencia a grupos, la titularidad, la evaluación del acceso condicional, los mecanismos RBAC, la auditoría y el registro de inicios de sesión.

Así pues, cuando Microsoft desarrolló las identidades de agente, no optó por crear una primitiva de identidad totalmente nueva desde cero, sino que decidió ampliar una ya existente.

Tal y como se indica en la documentación, ambos agentIdentity¹ y agentIdentityBlueprintPrincipal² los objetos (que analizaremos con más detalle en un capítulo posterior) son tipos especializados de entidades de servicio que representan instancias de identidad de agente dentro del ecosistema de Microsoft Entra ID. En la práctica, esto significa que heredan la arquitectura existente de entidades de servicio, incluidas las ventajas, la compatibilidad con las API existentes y, naturalmente, parte de la complejidad.

Es aquí donde la arquitectura adquiere relevancia en materia de seguridad.

Un buen ejemplo es el^hallazgo³ publicado hace poco por el equipo de Silverfort.

Cuando Microsoft introdujo el rol de «Administrador de ID de agente» para gestionar el nuevo plano de control de identidades de agente, se documentó que su ámbito de aplicación se limitaba estrictamente a los objetos relacionados con los agentes. En la práctica, ese límite no se cumplió. Las identidades a las que solo se les había asignado este rol podían hacerse con el control de entidades de servicio arbitrarias, incluidas aquellas que no tenían nada que ver con las identidades de agente, añadiéndose a sí mismas como propietarias, añadiendo credenciales a la entidad de servicio y, a continuación, autenticándose como dicha entidad.

Se trata de una adquisición total de la empresa matriz.

La causa raíz probable se corresponde directamente con el modelo descrito anteriormente.

Si agentIdentity y agentIdentityBlueprintPrincipal Los objetos se implementan sobre la servicePrincipal Si se parte de esta base, la capa de autorización debe distinguir de forma fiable entre entidades de servicio respaldadas por agentes y entidades de servicio «normales». Esa distinción debe aplicarse de forma explícita.

Esta es una de las razones por las que Microsoft introdujo nuevas funciones de directorio (administrador de identificadores de agente, desarrollador de identificadores de agente y administrador del registro de agentes) y funciones de gestión específicas para cada objeto (propietario, patrocinador y gestor) junto con el nuevo modelo de identidad de agente.

En teoría, estas funciones deben gestionar la nueva superficie específica del agente:

• Identidades de los agentes
• Principios del modelo de identidad del agente
• Plantillas de identidad de agentes
• Usuarios de agentes

Su autoridad debería limitarse al modelo de agente, y no a todos los sujetos de servicio del inquilino.

Como nota al margen interesante y bastante extensa , el modelo RBAC visible no siempre muestra con claridad toda la superficie del agente. Actualmente, la documentación de Microsoft sobre el Administrador de ID de agente hace referencia a las «Acciones» relacionadas con el agente en un sentido más amplio, que son entradas de permisos que definen qué operaciones puede realizar un rol de directorio sobre tipos de recursos específicos.

Basándose en la documentación oficial, Silverfort supuso (¡con toda razón!) que acciones como microsoft.directory/agentIdentities/owners/update y microsoft.directory/agentIdentityBlueprintPrincipals/owners/update se filtró desde el rol integrado al plano de control del sujeto de servicio general.

Sin embargo, al consultar la definición del rol activo a través de Microsoft Graph, el allowedResourceActions parecen centrarse únicamente en agentUsers/*.

Y enumerando los declarados microsoft.directory Las acciones relacionadas con los recursos muestran la misma discrepancia: 18 entradas relacionadas con los agentes, todas ellas bajo agentUsers/*. Ninguno para los subtipos de la capa de entidad de servicio (agentIdentities/*, agentIdentityBlueprintPrincipals/*y agentIdentityBlueprints/*). Lo que, básicamente, significa que ningún papel los incluye.

Se puede hacer una observación algo similar en relación con el rol de administrador de IA.

A diferencia del administrador de Agent ID, cuyo nombre sugiere que se trata de una función muy específica para gestionar el plano de control de Agent ID, es mucho más probable que las funciones del administrador de IA se deleguen de forma más amplia. Sus responsabilidades documentadas se centran en Microsoft 365 Copilot, los servicios de IA, los agentes de Copilot, la información sobre el uso, el estado de los servicios y las operaciones de soporte.

En otras palabras, parece un puesto dedicado a las operaciones de IA, no uno que implique un control total sobre el plano de identidad subyacente de Agent ID.

Sin embargo, en la práctica, el rol parece tener capacidades casi idénticas en el plano de control de Agent ID que el de «Administrador de Agent ID». Las 17 operaciones que probamos arrojaron resultados idénticos para ambos roles. Esto significa que cualquier persona que tenga el rol de «Administrador de Agent ID» puede hacerse cargo de cualquier identidad de agente del inquilino, asignar credenciales a cualquier plantilla e heredar los permisos de aplicación que los administradores hayan concedido a dichas plantillas.

A pesar de que ambas funciones indican valores ligeramente diferentes allowedResourceActions, y a pesar de que ambos heredan de la base «Directory Readers», de la que heredan casi todos los roles con privilegios (lo que aporta 55 acciones de solo lectura), la diferencia real se limita a las siguientes acciones:

Esos detalles no figuran en el propio informe de Silverfort, pero resultan útiles para contextualizar. Muestran que parte del plano de control de la identidad de los agentes no se representa como un vocabulario RBAC claro y totalmente visible. Parte de la autoridad sobre los objetos relacionados con los agentes parece aplicarse a un nivel más profundo de la capa de la API (por ejemplo, medidas de seguridad específicas por punto final, anulaciones vinculadas al ID de la plantilla o comprobaciones dinámicas en tiempo de ejecución). Esto también explica por qué los objetos de la aplicación no se vieron afectados, ya que la brecha no se encontraba en la gestión de la propiedad.

Y eso nos lleva de nuevo a la cuestión de la seguridad.

La herencia aporta flexibilidad, coherencia y reutilización a los sistemas de identidad. Sin embargo, si no se definen límites precisos de ámbito, también puede ampliar la superficie de ataque a todos los objetos implicados.
No obstante, la jerarquía de herencia es solo una de las variantes del modelo de entidad de servicio. Además de compartir la misma arquitectura de objetos subyacente, las entidades de servicio también se clasifican lógicamente en diferentes tipos de identidad.

Tipos de entidades de servicio lógicas: y dónde fallan

Durante el último año, he tenido la oportunidad de viajar y presentar EntraGoat, un laboratorio de código abierto y deliberadamente vulnerable que hemos creado en Semperis para compartir y poner en práctica vías de ataque a la identidad en el mundo real en Microsoft Entra ID.

Las opiniones fueron muy positivas, pero lo que más me llamó la atención fueron las conversaciones que tuvieron lugar a continuación. Hubo un tema que se repitió una y otra vez: las aplicaciones y los principales de servicio son mucho más complejos de lo que parecen a primera vista.

Así pues, aquí esperamos desentrañar esa complejidad y arrojar algo de luz sobre los ataques a los que se enfrentan estas identidades.

El tipo de entidad de servicio se puede identificar a través del servicePrincipalType propiedad enum, que Entra ID asignó internamente para indicar la categoría lógica de la identidad.

Según Microsoft, documentación para el servicePrincipal tipo de recurso, este campo puede contener cinco valores principales:

• Aplicación
• Identidad gestionada
• Legado
• SocialIdp
• ServiceIdentity

Según mi experiencia, estas identidades se encuentran entre los objetos más importantes de Entra ID y suelen situarse en el centro de las rutas de acceso críticas.

Comprender cómo se comportan estos tipos de entidades de servicio, cuál es su origen, cómo se autentican y en qué se diferencian entre sí es fundamental para entender cómo funciona realmente Entra ID «entre bastidores».

Comprender los cinco valores principales de los servicios en Entra ID

Empecemos a identificar los tipos de entidades de servicio lógicas en el panorama de identidades de las cargas de trabajo.

Muchas gracias a Eric Woodruff, arquitecto jefe de identidad de Semperis, por haber dado a conocer esta taxonomía y habérnosla mostrado.

Aplicaciones

Tal y como se detalla en el diagrama de identidades de carga de trabajo anterior, el primer grupo que inicia entidades de servicio en un inquilino de Entra ID procede de las aplicaciones que todos utilizamos y reconocemos, como Microsoft Teams, Salesforce o sistemas desarrollados internamente, como un portal de RR. HH.

Un objeto «Application» representa la definición global de una aplicación. Se crea en el inquilino donde se creó originalmente la aplicación (se puede consultar en la interfaz de usuario de «Registros de aplicaciones» ) y sirve como modelo o plantilla que define la configuración de identidad de la aplicación, incluyendo los URI de redirección, los permisos de API necesarios, las credenciales y otros ajustes. Esto significa que el objeto describe cómo el IdP puede emitir tokens que permiten a los clientes acceder a la aplicación, los recursos a los que la aplicación podría necesitar acceder y las acciones o permisos que la aplicación puede realizar dentro de un inquilino.

Para habilitar e integrar todo eso, y como se puede ver en el punto final de la API $metadata, el objeto «application» es también un objeto complejo (¡y muy relevante para las identidades de los agentes!) con muchas propiedades y métodos diferentes.

A Objeto «Service Principal» con servicePrincipalType : application representa la instancia de esa aplicación dentro de un inquilino concreto y se puede consultar en el Aplicaciones empresariales UI. Es el principio de seguridad que Entra ID utiliza realmente durante los flujos de autenticación y autorización.

El principal de servicio permite a la aplicación iniciar sesión o acceder a recursos dentro de ese directorio y almacena datos específicos del inquilino, como los permisos concedidos, el consentimiento del administrador y las asignaciones de roles de aplicación. Es decir, el principal de servicio es el objeto que obtiene los tokens, tiene permisos, aparece en los registros de inicio de sesión—y es el objetivo de los ataques.

¿Cuál es la diferencia entre aplicaciones y entidades de servicio?

Según nuestra experiencia, la distinción entre objetos de aplicación y objetos de entidad de servicio es uno de los conceptos que más confusiones suscita en Entra ID.

Para intentar aclarar la diferencia, hemos recopilado los siguientes ejemplos que muestran cómo se relacionan ambos conceptos, a pesar de ser muy distintos. No dudes en echar un vistazo rápido a los puntos si ya estás familiarizado con el tema.

• Un objeto de aplicación solo existe en su tenant de origen.
• Una aplicación de un solo inquilino tiene exactamente un entidad de servicio, que existe únicamente en el mismo inquilino (de origen).
• Cuando se concede el consentimiento a una aplicación multitenant en un tenant externo, en este solo se crea una entidad de servicio y no un objeto de aplicación.
• En appId La propiedad (ID de aplicación / ID de cliente) identifica la definición del objeto de aplicación y es único a nivel mundial entre todos los inquilinos de Entra ID. Se asigna al crearse y nunca cambia.
• En appId La propiedad de un sujeto de servicio siempre coincide con la appId de su objeto de aplicación correspondiente. Por eso, la misma aplicación propia (como Microsoft Graph) comparte el mismo appId en todos los inquilinos de todo el mundo.
• Cada entidad de servicio tiene su propio id (ID de objeto) que es único dentro del inquilino en el que se encuentra.
• Las asignaciones de roles de aplicación y las concesiones de permisos OAuth2 se asignan a la entidad de servicio, no al objeto de aplicación, por lo que dos inquilinos pueden dar su consentimiento a la misma aplicación con ámbitos de permisos completamente diferentes.
• Las credenciales añadidas directamente a una entidad de servicio tienen un ámbito de aplicación limitado exclusivamente a ese inquilino concreto y no pueden utilizarse fuera de él.
• Las credenciales añadidas al objeto de la aplicación son heredadas por todas las entidades de servicio en todos los inquilinos en los que se ha concedido permiso a la aplicación, lo que da lugar a un vector de ataque entre inquilinos.
• La eliminación de un objeto de entidad de servicio en un inquilino no afecta al objeto de aplicación (ni a las entidades de servicio de otros inquilinos), ya que el ciclo de vida de cada entidad de servicio es independiente.
• Al eliminar el objeto de aplicación en el inquilino principal, se elimina automáticamente la entidad de servicio de dicho inquilino, pero no se eliminan las entidades de servicio de otros inquilinos (estas permanecen hasta que se eliminen de forma explícita).
• Hasta el 1 de abril de 2026, y en algunos casos concretos, era posible utilizar una aplicación sin crear una entidad de servicio; sin embargo, esta «autenticación sin entidad de servicio» ya no debería ser compatible.

Tipos de objetos de aplicación

Todas las entidades de servicio respaldadas por aplicaciones suelen pertenecer a una de estas tres categorías lógicas de aplicaciones.

Identificación de los tipos de aplicaciones

Las aplicaciones propias de Microsoft son aplicaciones que pertenecen a Microsoft y son gestionadas por esta empresa, y que proporcionan servicios de Azure y M365, como Exchange Online, SharePoint, Microsoft Graph y cientos más. Aparecen en tu inquilino cuando un usuario da su consentimiento, un administrador les concede acceso o Microsoft las aprovisiona automáticamente al habilitar un servicio o una licencia (como E5, Defender o Intune).

Para identificar ese tipo de identidades de carga de trabajo, basta con consultar el appOwnerOrganizationId Propiedad GUID de un objeto de entidad de servicio. En las aplicaciones propias de Microsoft, esta propiedad suele estar configurada con el ID de inquilino de Microsoft (f8cdef31-a31e-4b4a-93e4-5f571e91255a), aunque algunos utilizan otros identificadores de inquilino propiedad de Microsoft.

Es importante tener en cuenta que, aunque puedan aparecer en los registros de inicio de sesión, la mayoría de los sujetos de servicio propios están ocultos de forma predeterminada en el panel «Aplicaciones empresariales» de la interfaz de usuario del Portal de Azure, aunque siguen siendo consultables a través de la API de Graph.

Esto se debe a que la pestaña de la interfaz de usuario filtra según el WindowsAzureActiveDirectoryIntegratedApp etiqueta, que suele identificar las aplicaciones integradas con Entra ID; sin embargo, los propios sujetos de servicio de Microsoft (a propósito) no la tienen.

Además, las aplicaciones propias de Microsoft funcionan mediante mecanismos de autorización internos que van más allá de los ámbitos estándar de OAuth, lo que significa que sus permisos efectivos pueden superar lo que se aprecia a través de las concesiones de permisos y no pueden auditarse por completo mediante consultas estándar de la API de Graph.

El siguiente tipo lógico de objetos de aplicación son tus propias aplicaciones, también conocidas como «solicitudes de inscripción».

Se trata de aplicaciones registradas directamente por administradores o desarrolladores a través de la experiencia de registro de aplicaciones. En este caso, la organización es propietaria del objeto de aplicación y puede controlar por completo su configuración, credenciales y permisos. Durante el registro, se crea automáticamente una entidad de servicio correspondiente en el inquilino de origen.

Para identificar las entidades de servicio creadas a partir de aplicaciones registradas por nuestra organización, de forma similar a como filtramos las aplicaciones propias de Microsoft, podemos enumerar todas las entidades de servicio cuyo appOwnerOrganizationId está configurado con nuestro ID de inquilino.

El último tipo de aplicación lógica es el de las aplicaciones de terceros o de la galería.

Se trata de aplicaciones SaaS integradas a través de Microsoft Entra App Gallery, como Salesforce, ServiceNow o Zoom. Tal y como se ha comentado anteriormente en este capítulo, cuando se concede acceso a una de estas aplicaciones a un inquilino, se crea localmente una entidad de servicio (que hace referencia al objeto de aplicación multinquilino del proveedor).

Para identificar los principales de servicio creados por aplicaciones de terceros —es decir, aplicaciones que no se han registrado en nuestro inquilino y que no son propiedad de Microsoft—, basta con excluir tanto nuestro ID de inquilino como el ID de inquilino de Microsoft del conjunto completo de principales de servicio en el lado del cliente (ya que Microsoft Graph no admite ne filtros activados appOwnerOrganizationId).

Vulnerabilidad de una aplicación

Como ya hemos dicho (probablemente demasiadas veces a estas alturas), cada uno de esos tres tipos de aplicación crea una instancia de un objeto de entidad de servicio local en tu inquilino. La entidad de servicio es la identidad en tiempo de ejecución: contiene las concesiones de permisos, la configuración de SSO y los ajustes específicos del protocolo que Entra ID aplica en el momento de la autenticación.

Al examinar el preferredSingleSignOnMode A partir de la propiedad del objeto principal del servicio, Entra ID determina qué protocolo de SSO utiliza la aplicación. Los valores posibles son:

• saml: La aplicación utiliza SAML 2.0, en la que Entra ID actúa como proveedor de identidad y emite aserciones SAML firmadas.
• oidc: La aplicación utiliza OpenID Connect / OAuth 2.0, el protocolo moderno basado en tokens.
• contraseña: SSO basado en contraseña, en el que Entra ID introduce las credenciales en el formulario de inicio de sesión de la aplicación en nombre del usuario.
• notSupported: No hay ningún SSO configurado a través de Entra ID.
• null: Indica aplicaciones SAML o OIDC más antiguas en las que el valor no se estableció automáticamente; también se utiliza para otros tipos lógicos de entidades de servicio (como veremos en breve).

Desde el punto de vista de la seguridad, el modo SSO tiene implicaciones directas. Las aplicaciones SAML se basan en un certificado de firma de tokens configurado en la propia entidad de servicio. Si un atacante consigue acceder a la clave privada de este certificado, puede falsificar aserciones SAML y autenticarse como cualquier usuario en el que confíe la aplicación.

Los investigadores de Semperis demostraron este escenario concreto en el blog de investigación «Meet Silver SAML: Golden SAML in the Cloud», en el que mostraron que importar un certificado de firma generado externamente a una entidad de servicio (en lugar de utilizar el certificado autofirmado integrado de Entra ID) crea un vector de ataque explotable que no requiere interacción alguna con Entra ID.

Pruébalo tú mismo en EntraGoat

Dado que nada ilustra mejor cómo los «service principals» configuran el panorama actual de las amenazas a la identidad que verlo en acción en un laboratorio, varias de las vías de escalada de privilegios más impactantes de EntraGoat —el laboratorio de Entra ID deliberadamente vulnerable que hemos creado aquí en Semperis— se basan íntegramente en ellos.

Los escenarios varían en cuanto al punto de partida y al método, pero el patrón es intencionadamente coherente: si se encuentra una vía de acceso a una entidad de servicio basada en una aplicación, el camino hacia el compromiso de todo el inquilino suele ser más corto de lo que nadie espera.

Si quieres ver cómo es el proceso de principio a fin, EntraGoat es un buen punto de partida. Lee más y sigue los tutoriales de nuestra serie de entradas del blog.

Identidades gestionadas

Las identidades gestionadas son, en cierto modo, el intento de Microsoft de resolver un problema que nosotros mismos hemos creado: la gestión de credenciales.

Cada identidad, y en particular las identidades no humanas, que se autentican mediante secretos de cliente (contraseñas, claves de acceso o certificados) plantea un reto relacionado con el ciclo de vida de dicho secreto (rotación, almacenamiento, caducidad y filtración). La implementación de identidades gestionadas intentó eliminar esta carga trasladando la gestión de credenciales íntegramente al plano de control de Azure. La identidad existe; se autentica, pero ningún ser humano llega a tocar (ni a manejar de forma incorrecta) ninguna de las credenciales asociadas a ella.

Tipos de identidades gestionadas

Cualquier recurso que admita la autenticación mediante Entra ID (como una máquina virtual, un servicio de aplicaciones, una aplicación lógica, un clúster de Kubernetes y muchos otros servicios y tipos de recursos de Azure) puede utilizar identidades gestionadas para obtener tokens y acceder a otros recursos.

Hay dos tipos:

• Las identidades gestionadas asignadas por el sistema se crean como parte del propio recurso de Azure y en el contexto de este. La relación es estrictamente 1:1. Un recurso, una identidad, un ciclo de vida. La identidad no puede existir de forma independiente, no se puede compartir y se elimina automáticamente cuando se elimina el recurso. Este estrecho acoplamiento es también su principal ventaja en materia de seguridad.
• Las identidades gestionadas asignadas por el usuario, por su parte, son recursos independientes de Azure. Pueden asociarse a uno o varios recursos, y su ciclo de vida es independiente del de los recursos que las utilizan. Esta naturaleza de desacoplamiento de la identidad gestionada asignada por el usuario constituye una ventaja operativa y, naturalmente, una contrapartida en materia de seguridad.

Identificación de identidades gestionadas

Identificar los principales de servicio que representan identidades gestionadas en Entra ID es bastante sencillo. Basta con consultar el directorio para obtener el servicePrincipalType propiedad establecida en ManagedIdentity.

En el fondo, ambos tipos de identidad se autentican a través de puntos finales controlados por Azure, como el Servicio de metadatos de instancias (IMDS) en 169.254.169.254—o a través de puntos finales de identidad expuestos por servicios como App Service y Functions. El flujo de obtención de tokens se lleva a cabo íntegramente en Azure y no se transmiten secretos por la red, ni se almacenan credenciales en Key Vault (o, peor aún, en appsettings.json), ni siquiera se han dado a conocer a los desarrolladores.

A diferencia de las entidades de servicio respaldadas por aplicaciones, las identidades gestionadas no están vinculadas a ningún objeto de aplicación en el directorio, por lo que no hay registro de aplicaciones, ni manifiesto, ni URI de redireccionamiento. Además, no están orientadas al usuario y no participan en ningún protocolo de inicio de sesión único (SSO).

¿Te acuerdas de la preferredSingleSignOnMode ¿La propiedad de la que hemos hablado antes? Esperamos que ahora entiendas por qué esa y otras propiedades específicas de la autenticación suelen ser nulas en el caso de las identidades gestionadas. Estas no se autentican mediante SAML, OIDC ni flujos basados en contraseña. En su lugar, Azure emite y gestiona certificados con un periodo de validez de 90 días, renovándolos cada 45 días, para cada identidad gestionada.

Estos certificados los expide Microsoft.ManagedIdentity e incluir el ID de objeto del sujeto del servicio de identidad gestionada en el asunto del certificado. Azure los utiliza para llevar a cabo la autenticación basada en certificados y emitir tokens directamente a través de su plano de control, sin exponer las credenciales al inquilino (ni a sus administradores).

Parte de este mecanismo puede observarse a través de la keyCredentials propiedad del objeto de entidad de servicio de la identidad gestionada.

A diferencia de las entidades de servicio respaldadas por aplicaciones, en las que keyCredentials Normalmente contiene certificados subidos por un administrador o un desarrollador; en el caso de las identidades gestionadas, Azure se encarga por completo de rellenar y rotar sus credenciales de clave.

Y, al consultar la propiedad, efectivamente aparece un AsymmetricX509Cert entrada con el campo «Usage» establecido en «Verify», y con el ID del objeto principal del servicio como sujeto del certificado.

Este diseño resulta elegante hasta que se analiza desde el punto de vista de un atacante.

Vulnerabilidades en identidades gestionadas

Hay dos patrones distintos de abuso que conviene comprender y que muestran cómo el modelo empieza a desviarse cuando la teoría se enfrenta a las exigencias de la realidad.

La primera es el robo de tokens a través del recurso adjunto.

Dado que las identidades gestionadas se autentican a través de puntos finales locales (IMDS o el punto final de identidad de la plataforma), cualquier entidad con acceso (es decir, con capacidad para ejecutar código en el recurso subyacente) puede solicitar un token en nombre de la identidad gestionada.

Este es el vector de ataque clásico y ampliamente documentado:

1. Comprometer la seguridad de un usuario con acceso a una máquina virtual, un registro de contenedores, Arc, AKS, cuentas de automatización, servicios de aplicaciones, Logic Apps, scripts de implementación o Data Factory.
2. Consulta el punto final del token de alguna forma (Invoke-WebRequest 169.254.169.254/metadata/identity/oauth2/token)

Si esta operación devuelve algún resultado, ya dispones de un token OAuth válido con el ámbito de los permisos que esa identidad tiene para utilizar en las API de Azure.

Aunque esta técnica se aplica tanto a las identidades gestionadas asignadas por el sistema como a las asignadas por el usuario, la superficie de ataque varía directamente en función del contexto de la identidad.

En el caso de las identidades gestionadas asignadas por el usuario y compartidas entre varios recursos, una sola identidad comprometida puede utilizarse para solicitar tokens para todos los recursos sobre los que tenga permisos. Un caso clásico de movimiento lateral.

O, como se explica brevemente en Microsoft Learn:

El perímetro de seguridad de las identidades gestionadas para los recursos de Azure es el recurso en el que se utiliza la identidad. Todo el código o las secuencias de comandos que se ejecuten en una máquina virtual pueden solicitar y obtener tokens para cualquiera de las identidades gestionadas disponibles en ella.

El segundo patrón de uso indebido es el uso indebido de credenciales federadas, que socava el modelo de confianza en el que se basan las identidades gestionadas.

Como hemos visto hace un momento, las identidades gestionadas asignadas por el usuario no admiten la configuración de credenciales tradicionales; está expresamente prohibido modificar estas propiedades en la entidad de servicio que representa a la identidad gestionada en Entra ID. Sin embargo, sí admiten credenciales de identidad federadas. Estas permiten que los proveedores de identidad externos (como GitHub Actions o cualquier emisor compatible con OIDC, incluidos los autohospedados) se autentiquen como la identidad gestionada sin necesidad de intercambiar secretos.

No vamos a entrar aquí en demasiados detalles sobre la implementación, ya que este capítulo ya se ha desviado bastante del tema, pero, a grandes rasgos, esto se puede hacer creando un federatedIdentityCredential objeto en la entidad de servicio de la identidad gestionada a través de la API de ARM, especificando una URL de emisor OIDC y un identificador de sujeto.

A continuación, en el momento de la autenticación, Entra ID valida el token externo con respecto al emisor configurado y comprueba que coincida con la reclamación del sujeto. Sin embargo, no valida la relación de propiedad entre el emisor y el inquilino o el recurso de la identidad gestionada.

Esto significa que cualquier director que tenga el Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write La acción del permiso RBAC de Azure (que incluye varios roles integrados, como «Colaborador», «Propietario» y «Colaborador de identidad gestionada») permite añadir una nueva credencial federada que apunte a un repositorio externo o a un entorno que controlen.

Una vez configurada esa credencial, el atacante se autentica desde su propio flujo de trabajo de GitHub (o cualquier entorno compatible con OIDC), recibe un token válido para la identidad gestionada y opera con todo su conjunto de permisos (totalmente desde fuera de los límites del recurso de Azure).

En ambos casos, la cuestión fundamental es la misma: las identidades gestionadas se diseñaron para eliminar el riesgo asociado a las credenciales dentro de los límites de un recurso, pero el propio modelo de permisos de Azure permite que cualquiera que cuente con acceso RBAC suficiente amplíe esos límites (o los eluda por completo).

La identidad está pensada para funcionar dentro de un contexto de ejecución específico, pero el acceso a ella no siempre se limita a ese contexto. En el primer caso, se puede suplantar obteniendo control sobre la ejecución del código en un recurso al que esté vinculada la identidad gestionada. En el segundo, se puede suplantar a través de una relación de confianza federada que no requiere en absoluto ninguna conexión real con el recurso original de Azure.

Identidades heredadas e Identidades SocialIdp

Los dos siguientes tipos de identidades de entidad de servicio son «Legacy » y «SocialIdP». Ambos son menos relevantes para el objetivo principal de esta guía, por lo que solo los mencionaremos brevemente.

El tipo «Legacy» se refiere a aplicaciones más antiguas creadas antes de que existiera el modelo moderno de registro de aplicaciones, o a través de entornos heredados. El appId existe una propiedad en él, pero no apunta a ningún registro de aplicación. Una entidad de servicio heredada puede seguir teniendo credenciales y URL de respuesta que los administradores pueden gestionar directamente, y solo se puede utilizar en el inquilino en el que se creó.

Microsoft describe el tipo SocialIdp como «para uso interno», por lo que hay menos información pública disponible al respecto. A juzgar por su nombre y su contexto de uso, es probable que haga referencia a proveedores de identidad social (como Google o Facebook) configurados para flujos de usuarios B2C. En la práctica, este tipo permite que B2C se federara con proveedores sociales externos, pero normalmente no interactuarás con él directamente a menos que estés trabajando con políticas personalizadas de B2C.

ServiceIdentity: El tipo de entidad de servicio para los agentes

Esto nos lleva a la categoría más reciente de este ecosistema: ServiceIdentity, el modelo de identidad introducido para dar soporte a las operaciones digitales basadas en agentes.

Las identidades de los agentes se basan en dos conceptos fundamentales de Entra ID: el objeto «Aplicación» y el objeto «Entidad de servicio». Por eso, para comprender cómo funcionan las identidades de los agentes y cuál es su «potencial», primero tuvimos que entender los diferentes modelos de los que heredan.

A grandes rasgos, el agentIdentityBlueprint, que es un subtipo de aplicación, define la plantilla del agente y almacena las credenciales. El agentIdentity, un subtipo de servicePrincipal con propiedades servicePrincipalType ajustado a ServiceIdentity, es el objeto de tiempo de ejecución por agente que obtiene los permisos e interactúa con los recursos.

Esta distinción es importante porque las identidades de los agentes no disponen de credenciales propias.

En cambio, recurren al «blueprint» para que este obtenga tokens en su nombre mediante un modelo de suplantación de identidad. El «blueprint» se autentica utilizando sus propias credenciales y lleva a cabo un intercambio de tokens en el que el token resultante identifica al agente como el cliente, aunque haya sido el «blueprint» quien haya realizado la autenticación propiamente dicha.

Como se puede ver en el diagrama, también hay un tercer objeto (Atención, spoiler: también hay una cuarta parte) en el modelo: el agentIdentityBlueprintPrincipal, que hereda de servicePrincipal y actúa como la representación en tiempo de ejecución local del blueprint en el inquilino. Se crea cuando se instancia un blueprint en un inquilino y es lo que permite al blueprint obtener tokens exclusivos de la aplicación para crear y gestionar identidades de agente.

Otra distinción arquitectónica importante es el modelo de relación. Las aplicaciones tradicionales suelen seguir una relación uno a uno entre el objeto de la aplicación y la entidad de servicio en el inquilino de origen, mientras que las aplicaciones multinquilino crean una entidad de servicio por cada inquilino en el que se utiliza la aplicación. El modelo de agente añade otra capa: un único modelo puede generar múltiples entidades de servicio de identidad de agente tanto dentro de un mismo inquilino como entre distintos inquilinos.

Comprender esta separación es fundamental para entender tanto la arquitectura como la superficie de ataque, ya que las identidades de los agentes no son simplemente «otro tipo de entidad de servicio».

En un capítulo posterior profundizaremos un poco más en esta arquitectura, analizaremos qué nos revela el punto final de metadatos OData de Microsoft Graph sobre estas relaciones entre objetos, qué capas de autorización es probable que existan, y haremos algunas conjeturas fundamentadas sobre dónde podrían surgir futuras vulnerabilidades.

Pero, antes de nada, analizaremos el marco que Microsoft ha creado para autenticar, autorizar, gestionar y proteger estas identidades no humanas.

No te pierdas el próximo capítulo: «Cómo funciona el ID de Microsoft Agent y la plataforma de identidad de Agent».

Explora la guía

Pasa al siguiente capítulo publicado de la serie… o elige tu propia aventura.

• Introducción: Cómo comprender y prevenir los ataques a la identidad de los agentes de Entra ID: una guía completa
• Te presentamos las identidades de Entra ID Agent (por cierto, no son personas)

Notas finales

• 1 https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/beta/resources/agentidentity.md
• 2 https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/beta/resources/agentidentityblueprintprincipal.md
• 3 https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/