Semion Vasilevitzky e Jonathan Elkabas

Nota dell'editore: Benvenuti alla quarta e ultima lezione pratica della serie “Comprendere e prevenire gli attacchi all'identità degli agenti Entra ID: una guida completa”. Questa guida tecnica in più parti vi aiuta a comprendere l'approccio di Microsoft alle identità degli agenti e come proteggerle dagli autori delle minacce. Per rivedere i capitoli precedenti e le lezioni pratiche, iniziate da qui.

Nel capitolo 5 della nostra guida hai appreso e messo in pratica l'uso del Registro degli agenti di Microsoft e hai seguito passo passo le operazioni relative a tre flussi di autenticazione dell'identità degli agenti in Entra ID.

In questo "Practice Checkpoint" verificheremo i tre flussi di cui abbiamo parlato, seguendoli uno per uno dall'inizio alla fine attraverso Microsoft Graph e mostrando i claim effettivi dei token in ogni fase, in modo da collegare tutti i punti.

Per motivi di coerenza e chiarezza, continueremo a utilizzare la stessa identità dell'agente che abbiamo creato nei passaggi precedenti ed esamineremo i token risultanti generati in ciascun flusso.

Ecco un breve riassunto delle informazioni che ti servono:

  • ID del progetto = 3534ec06-21ea-4080-abd4-95116e260203
  • ID Blueprint SP = 17a48807-f813-421b-85b9-8c7e794bc4b9
  • ID agente = b85d92be-fa90-486b-94ed-b5ad91d35ceb
  • ID agente utente = 2954440b-1617-46b1-9156-dad15f1f824f
  • Autorizzazioni delegate ereditabili = Group.Read.All
  • Autorizzazioni dirette riservate all'app a livello di identità dell'agente = User.Read.All

Flusso autonomo

In questo flusso, è l'identità dell'agente stessa a dover accedere a una risorsa.

Per cominciare, dobbiamo ottenere il token T1. Il procedimento è simile a quello per ottenere un token di accesso per un blueprint di identità agente, ma con due differenze fondamentali:

  • ambito = api://AzureADTokenExchange/.default
  • include fmi_path = <agent-identity-id>
Figura 1. Ottenimento del token T1

Possiamo decodificare il token T1, in cui:

  • Le mappe oid corrispondono all'ID SP del progetto.
  • azp corrisponde all'ID del modello di identità dell'agente.
  • aud appartiene all'applicazione "AAD Token Exchange Endpoint", che è api://AzureADTokenExchange.
Figura 2: Decodifica del token T1

Utilizzando il token T1, ora possiamo ottenere il token di accesso dell'agente.

Figura 3: Ottenimento del token di accesso con identità dell'agente

Osservando il token Graph possiamo notare che:

  • L'affermazione di AUD riguarda Microsoft Graph.
  • L'appid, così come il claim oid, corrisponde all'ID identificativo dell'agente.
  • Il ruoli la richiesta comprende il User.Read.All autorizzazione, che abbiamo assegnato in precedenza e attribuito direttamente all'identità dell'agente come autorizzazione riservata esclusivamente all'app.

A questo punto, l'identità dell'agente può richiamare Graph nel tenant in base alle proprie autorizzazioni limitate all'app.

Figura 4: Decodifica del token di accesso dell'identità dell'agente Graph

Flusso "per conto di"

In questo flusso, l'identità dell'agente esegue azioni delegate in qualità di utente e illustra gli ambiti di delega ereditabili.

Per iniziare, dovremo ottenere un token client (TC). Per farlo, dobbiamo innanzitutto impostare gli ambiti di autorizzazione OAuth2 sul blueprint e dare il consenso tramite il mio account utente.

Figura 5: Impostazione degli ambiti di autorizzazione OAuth2 nel blueprint

Come passo successivo, creeremo un'applicazione SAP tramite l'interfaccia utente.

Figura 6: Registrazione della nostra applicazione SAP

Aggiungeremo le autorizzazioni Blueprint che abbiamo appena creato alla nostra applicazione DemoSAP:

Figura 7: Aggiunta delle autorizzazioni al blueprint alla nostra applicazione SAP dimostrativa

Per questa demo, consentiremo anche il flusso del client pubblico:

Figura 8: Attivazione dei flussi client pubblici nella nostra autenticazione dimostrativa

Ora possiamo ottenere un token TC. Il ClientID è l'ID dell'applicazione che abbiamo appena creato:

Figura 9. Ottenimento di un token TC utilizzando l'ID dell'applicazione appena creato

A questo punto, dobbiamo esaminare le richieste di consenso periodiche previste.

Figura 10. Concessione delle autorizzazioni per la nostra applicazione dimostrativa

Questo restituirà il token TC, che mi appartiene in qualità di utente. Possiamo notare che il campo " aud claim" corrisponde all'ID del Blueprint:

Figura 11. La decodifica del token TC mostra che l’aud claim corrisponde all’ID del modello di identità dell’agente

Ora possiamo ottenere il token T1 utilizzando lo stesso metodo che abbiamo già utilizzato.

Figura 12. Ottenere nuovamente il token T1

Prima di proseguire, dovremo fornire il consenso affinché l'identità dell'agente possa agire per conto del nostro utente, utilizzando una chiamata standard OAuth2PermissionGrants con l'ambito che abbiamo assegnato come autorizzazioni ereditabili.

Se hai già fornito il consenso a “AllPrincipals” nella sezione “Configurazione delle autorizzazioni ereditabili”, puoi saltare questa fase.

Figura 13. Autorizzazione all'identità dell'agente ad agire per conto dell'utente

Infine, utilizzando sia il token TC che il token T1, possiamo ottenere il token di accesso (TR).

Figura 14. Ottenimento del token di accesso TR

Il token di accesso decodificato riporta:

  • Richiesta SCP con le autorizzazioni Group.Read.All ereditabili che abbiamo aggiunto in precedenza a livello di blueprint.
  • il nome visualizzato dell'app e il claim "appid", che identificano l'identità dell'agente che opera per conto dell'utente.
  • I campi "idtyp", " name" e "oid" appartengono tutti all'utente (poiché si tratta di un token delegato).
Figura 15. Decodifica del token di accesso TR

Flusso utente dell'agente

Questo flusso è rilevante per un utente agente che deve eseguire azioni nel contesto di un utente.

Come nel caso del flusso autonomo basato sull'identità dell'agente, dobbiamo ottenere un token T1.

Figura 16. Ottenimento del token T1 per il flusso di autenticazione dell'utente del nostro agente

Successivamente, dovremmo dare il nostro consenso affinché l'identità dell'agente possa agire per conto dell'utente agente, come abbiamo fatto nel flusso OBO.

Questa volta specificheremo l'ID utente dell'agente come ID del soggetto. Se avete già acconsentito a "AllPrincipals" nella sezione "Configurazione delle autorizzazioni ereditabili", potete saltare questa chiamata.

Figura 17. Autorizzazione all'identità dell'agente ad agire per conto dell'utente dell'agente

Ora, utilizzando il token T1 possiamo ottenere il token T2.

Figura 18. Ottenimento del token T2 per il flusso di autenticazione dell'utente del nostro agente

Il token T2 decodificato rivela i claim azp, oid e sub, tutti impostati sull'ID dell'agente.

Figura 19. Rivelazione dell’ID identificativo dell’agente nelle nostre rivendicazioni dei token T2 decodificati

Utilizzando sia il token T1 che il token T2, possiamo ottenere il token di accesso TR.

Figura 20. Ottenimento del token di accesso TR per il flusso di autenticazione dell'utente del nostro agente

Come possiamo vedere, questo token di accesso è stato emesso per Microsoft Graph. Riporta quanto segue:

  • La richiesta idtyp è un utente
  • La richiesta "oid " corrisponde all'ID utente dell'agente
  • Il campo "appid" è impostato sull'ID di identità dell'agente, che è il genitore dell'utente agente.
  • scp contiene il Group.Read.All, i cannocchiali che abbiamo aggiunto in precedenza.
Figura 21. Decodifica del token di accesso del flusso di autenticazione dell'utente dell'agente emesso per Microsoft Graph

Ora disponi di un'identità di agente funzionante. Come la proteggi?

Sviluppare la propria identità di agente attraverso queste sessioni pratiche dovrebbe avervi fornito una comprensione concreta di come gli agenti opereranno nel vostro tenant Entra ID.

Ora, leggi l'ultimo capitolo della nostra guida per avere una panoramica di cosa può andare storto e di come proteggere queste nuove identità.

Scopri come prevenire le catastrofi nel capitolo 6.


Scopri la guida