Nota del editor: Bienvenido al cuarto y último tutorial práctico de «Comprender y prevenir los ataques a la identidad del agente Entra ID: una guía completa». Esta guía técnica, dividida en varias partes, te ayuda a comprender el enfoque de Microsoft respecto a las identidades de los agentes y cómo puedes protegerlas frente a los autores de amenazas. Para repasar los capítulos anteriores y las lecciones prácticas, empieza aquí.
En el capítulo 5 de nuestra guía, has aprendido a utilizar el Registro de agentes de Microsoft y has realizado ejercicios prácticos al respecto, además de seguir paso a paso las operaciones de tres flujos de autenticación de identidad de agentes en Entra ID.
En este «Practice Checkpoint», verificaremos los tres flujos que hemos comentado, siguiendo cada uno de ellos de principio a fin a través de Microsoft Graph y mostrando las reclamaciones reales del token en cada paso para atar todos los cabos.
En aras de la coherencia y la claridad, seguiremos utilizando la misma identidad de agente que creamos en los pasos anteriores y analizaremos los tokens resultantes generados en cada flujo.
A continuación te ofrecemos un breve resumen de la información que necesitas:
- ID del plano = 3534ec06-21ea-4080-abd4-95116e260203
- ID del plano SP = 17a48807-f813-421b-85b9-8c7e794bc4b9
- Identidad del agente: ID = b85d92be-fa90-486b-94ed-b5ad91d35ceb
- ID del agente de usuario = 2954440b-1617-46b1-9156-dad15f1f824f
- Permisos delegados heredables = Group.Read.All
- Permisos directos exclusivos de la aplicación a nivel de identidad del agente = User.Read.All
Flujo autónomo
En este flujo, la propia identidad del agente necesita acceder a un recurso.
Para empezar, tenemos que obtener el token T1. El proceso es similar al de obtener un token de acceso para un modelo de identidad de agente, pero con dos diferencias clave:
- ámbito =
api://AzureADTokenExchange/.default - incluye fmi_path =
<agent-identity-id>
Podemos descodificar el token T1, en el que:
- El mapa «oid» se asigna al identificador SP del plano.
- «azp» se corresponde con el ID del modelo de identidad del agente.
- aud pertenece a la aplicación «AAD Token Exchange Endpoint», que es
api://AzureADTokenExchange.
Con el token T1, ya podemos obtener el token de acceso de identidad del agente.
Al analizar el token Graph, podemos observar que:
- La afirmación de aud es Microsoft Graph.
- El «appid», al igual que el campo «oid», corresponde al identificador del agente.
- En funciones La reclamación incluye el
User.Read.Allpermiso, que habíamos asignado anteriormente y que se asignó directamente a la identidad del agente como un permiso exclusivo de la aplicación.
En este punto, la identidad del agente puede llamar a Graph en el inquilino de acuerdo con sus permisos exclusivos para la aplicación.
Flujo «en nombre de»
En este flujo, la identidad del agente realiza acciones delegadas en nombre de un usuario y muestra los ámbitos de delegación heredables.
Para empezar, tendremos que obtener un token de cliente (TC). Para ello, primero debemos configurar los ámbitos de permiso de OAuth2 en el blueprint y dar mi consentimiento como usuario.
Como siguiente paso, crearemos una aplicación SAP a través de la interfaz de usuario.
Añadiremos los permisos de Blueprint que acabamos de crear a nuestra aplicación DemoSAP:
Para esta demostración, también permitiremos el flujo de clientes públicos:
Ahora podemos obtener un token TC. El ClientID es el ID de la aplicación que acabamos de crear:
A continuación, tenemos que pasar por los mensajes habituales de solicitud de consentimiento.
Esto devolverá el token TC, que me pertenece a mí como usuario. Podemos ver que la reclamación «aud» es el ID del Blueprint:
Ahora podemos obtener el token T1 utilizando el mismo método que ya hemos utilizado.
Antes de continuar, tendríamos que dar nuestro consentimiento para que la identidad del agente pueda actuar en nombre de nuestro usuario mediante una llamada estándar a OAuth2PermissionGrants con el ámbito que hemos asignado como permisos heredables.
Si ya has dado tu consentimiento a «AllPrincipals» en la sección «Configuración de permisos heredables», puedes saltarte este paso.
Por último, utilizando los tokens TC y T1, podemos obtener el token de acceso (TR).
El token de acceso descodificado muestra lo siguiente:
- Reclamación SCP con los permisos «Group.Read.All» heredables que hemos añadido anteriormente a nivel de blueprint.
- el nombre de visualización de la aplicación y la reclamación «appid», que identifican la identidad del agente que actúa en nombre del usuario.
- Las reclamaciones «idtyp», «name» y «oid» pertenecen todas al usuario (ya que se trata de un token delegado).
Flujo de usuario del agente
Este flujo es relevante para un usuario agente que necesite realizar acciones con un contexto de usuario.
Al igual que en el flujo autónomo de identidad del agente, necesitamos obtener un token T1.
A continuación, tendríamos que dar nuestro consentimiento para que la identidad del agente pueda actuar en nombre del usuario del agente, tal y como hicimos en el flujo OBO.
En esta ocasión, especificaremos el ID de usuario del agente como ID del principal. Si ya has dado tu consentimiento para «AllPrincipals» en la sección «Configuración de permisos heredables», puedes saltarte este paso.
Ahora, utilizando el token T1, podemos obtener el token T2.
El token T2 descodificado revela las reclamaciones «azp», «oid» y «sub», todas ellas establecidas con el ID de identidad del agente.
Utilizando los tokens T1 y T2, podemos obtener el token de acceso TR.
Como podemos ver, este token de acceso se ha emitido para Microsoft Graph. En él se indica:
- La reclamación «idtyp» corresponde a un usuario
- La reclamación «oid» se corresponde con el ID de usuario del agente
- El parámetro «appid» se establece en el ID de identidad del agente, que es el padre del usuario del agente.
- scp contiene el
Group.Read.All, los visores que habíamos añadido antes.
Ahora ya tienes una identidad de agente operativa. ¿Cómo la proteges?
El desarrollo de tu identidad como agente a través de estas sesiones prácticas debería haberte proporcionado una comprensión práctica de cómo trabajarán los agentes en tu cuenta de inquilino de Entra ID.
Ahora, lee el último capítulo de nuestra guía para tener una visión general de lo que puede salir mal y de cómo proteger estas nuevas identidades.
Descubre cómo evitar un desastre en el capítulo 6.
Explora la guía
- Introducción: Cómo comprender y prevenir los ataques a la identidad de los agentes de Entra ID: una guía completa
- Capítulo 1: Conoce las identidades de los agentes de Entra ID (por cierto, no son personas)
- Capítulo 2: La taxonomía de las identidades de carga de trabajo en Entra ID: aplicaciones empresariales, entidades de servicio y otras formas de confusión organizada
- Capítulo 3: Introducción al ID de Microsoft Agent y a la plataforma de identidad de Agent
- Punto de control práctico 1: Creación de un identificador de agente con MS Graph
- Capítulo 4: Identidades de los agentes: análisis en profundidad del diseño
- Punto de control práctico 2: Configuración de los permisos de identidad de los agentes
- Capítulo 5: El registro de agentes y cómo funcionan las identidades de los agentes en Entra ID
- Punto de control práctico n.º 3: Registro de un agente: con y sin ID de agente
- Capítulo 6: Dónde pueden surgir problemas con las identidades de los agentes en Entra ID, y cómo evitar el desastre
