Identità degli agenti: approfondimento sul design

Nota dell'editore: Benvenuti al Capitolo 4 di “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 precedente di questa guida completa alla prevenzione degli attacchi all’identità degli agenti Entra ID, abbiamo definito gli oggetti fondamentali che costituiscono il modello Agent ID. Tenendo presente tale modello generale — e, si spera, dopo aver fatto una breve digressione per esercitarsi nella creazione di Agent ID con MS Graph — siamo pronti ad approfondire la comprensione di come sono strutturate le identità nella piattaforma Agent ID.

Riprendiamo da dove eravamo rimasti.

Alla scoperta del modello di dati di Microsoft Graph

Per comprendere in che modo i quattro elementi costitutivi dell'identità siano rappresentati nella gerarchia di dati sottostante di Microsoft Graph, possiamo esaminare l'endpoint dei metadati di Graph.

Microsoft Graph rende accessibile il proprio modello di dati tramite l'endpoint dei metadati OData all'indirizzo https://graph.microsoft.com/beta/$metadata. Accedendovi, si ottiene un documento XML che definisce i tipi di entità, i tipi complessi, le enumerazioni e le relazioni supportate dall’API. In termini più semplici, si tratta della mappa strutturale di Microsoft Graph. Non ci dice tutto ciò che la piattaforma consentirà in fase di esecuzione, ma ci mostra come Microsoft abbia scelto di modellare gli oggetti.

Microsoft spiega che questi metadati aiutano gli sviluppatori a comprendere il modello di dati e le relazioni tra le entità. Per i ricercatori nel campo della sicurezza, questo endpoint è estremamente prezioso perché mette in luce la gerarchia di ereditarietà e le definizioni delle proprietà che determinano il comportamento degli oggetti Entra ID, compresi i nuovi tipi di Agent ID.

Detto questo, l’Agent ID è ancora in fase di sviluppo e alcuni dettagli dello schema potrebbero subire modifiche man mano che la piattaforma matura.

Prima di addentrarci nel merito degli oggetti stessi, chiariamo che esistono due tipi di metadati che vale la pena distinguere: EntityType e ComplexType.

• Un EntityType di solito rappresenta un oggetto che può essere interrogato direttamente tramite il proprio endpoint, possiede proprietà di navigazione (relazioni con altre entità) e può essere memorizzato, recuperato e aggiornato in modo indipendente. Esempi di tali tipi di entità sono user, application, servicePrincipal, e group.
• A ComplexType è un tipo di valore strutturato che raggruppa più proprietà. Non ha un'identità propria, ma esiste incorporato all'interno di un'entità (o anche all'interno di un altro ComplexType) e non possono essere interrogati direttamente come oggetti autonomi. Esempi di tali tipi sono apiApplication, appRole, federatedIdentityCredential, e keyCredential.

Pensala in questo modo: un EntityType è come una riga di una tabella di un database, e un ComplexType è un oggetto JSON annidato all'interno di quella riga.

Nella risposta dei metadati XML, possiamo vedere il tipo di entità base astratto da cui derivano quasi tutti i tipi di entità di Graph (ed è per questo che quasi tutte le risorse di Microsoft Graph alla fine hanno una stringa ID):

Il prossimo brano è il directoryObject entità, che eredita da entità.

Da lì, possiamo esaminare servicePrincipal tipo e struttura.

Un'interfaccia utente testuale non è, a dir poco, il formato più leggibile per navigare in un documento di metadati da 428 KB, quindi abbiamo creato al volo un'app web locale per rendere un po' più gestibile l'esplorazione di queste relazioni tra entità.

Ora, invece di cercare di comprendere il tipo di entità `agentIdentity` fissando i suoi metadati grezzi:

… possiamo esplorare visivamente la gerarchia degli oggetti e interagire con le relazioni che caratterizzano ciascun tipo in modo più approfondito:

I metadati ci indicano che agentIdentity deriva da servicePrincipal (con OpenType="true", il che significa che potrebbero esistere anche proprietà dinamiche o non documentate) e aggiunge la seguente piccola serie di elementi specifici dell'agente a livello di sottotipo:

• Due proprietà:
  • agentIdentityBlueprintId (una stringa obbligatoria che collega l'identità dell'agente al suo blueprint padre)
  • createdDateTime
• Tre proprietà di navigazione:
  • sponsor (una raccolta di directoryObject)
  • inheritedAppRoleAssignments (una raccolta di appRoleAssignment)
  • inheritedOauth2PermissionGrants (una raccolta di oAuth2PermissionGrant)

Le ultime due sono aggiunte recenti allo schema beta e sono particolarmente importanti perché rappresentano il meccanismo di ereditarietà delle autorizzazioni dal soggetto principale “Agent Identity Blueprint” all’identità dell’agente. Microsoft descrive queste assegnazioni ereditate di ruoli applicativi e queste concessioni delegate come autorizzazioni effettive applicate al momento dell’emissione del token.

È proprio qui che la differenza tra “agenti classici” e “agenti moderni” in Entra ID comincia a diventare più chiara.

• Gli agenti classici, come quelli creati da Copilot Studio e Azure AI Foundry prima dell'introduzione del nuovo modello di ID agente, sono rappresentati in background tramite normali oggetti di entità di servizio.
• Agenti moderni, d'altra parte, sono rappresentati attraverso il nuovo agentIdentity sottotipo.

Sapendo questo, è facile capire perché il filtro in base alla colonna “Agent Blueprint ID” nel portale Agent ID (anteprima) possa aiutare a separare questi due mondi. Gli oggetti con un agentIdentityBlueprintId appartengono al nuovo modello di ID agente, mentre gli agenti più vecchi basati su entità di servizio non ne fanno parte.

Vale la pena notare che i metadati della versione 1.0 presentano attualmente una definizione più snella dello schema, senza i due inherited* proprietà di navigazione attivate agentIdentity. Questo tipo di divario tra la versione beta e la v1.0 è tipico delle funzionalità in anteprima, ma ha un impatto concreto sulla sicurezza per gli addetti alla sicurezza che desiderano valutare agenti Entra già integrati all’interno della loro organizzazione. Qualsiasi strumento di audit, prodotto CSPM o script di enumerazione delle autorizzazioni che non tenga conto di queste relazioni di autorizzazioni ereditate potrebbe non rilevare parte del quadro completo delle autorizzazioni effettive relative agli oggetti con ID agente.

E se configuriamo autorizzazioni ereditabili su un blueprint, concediamo il consenso amministrativo al soggetto del blueprint e interroghiamo un agente ad esso associato tramite diverse versioni dell'API, tale discrepanza diventa evidente.

Tutto il resto — tutte le oltre 40 proprietà e le oltre 20 proprietà di navigazione provenienti dal servicePrincipal oggetto — viene ereditato a livello strutturale. Ciò include proprietà quali keyCredentials, passwordCredentials, owners, federatedIdentityCredentials, e memberOf.

Tuttavia, è proprio qui che lo schema può indurci in errore.

L'ereditarietà OData descrive la struttura del modello a oggetti. Non garantisce che ogni funzionalità ereditata sia effettivamente disponibile in fase di esecuzione. La documentazione di Microsoft sottolinea esplicitamente questo principio per le risorse relative all'ID agente:

…sebbene questa risorsa derivi da `servicePrincipal`, alcune proprietà non sono applicabili.

Le proprietà delle credenziali ne sono l'esempio più evidente, poiché le identità degli agenti non dispongono di credenziali proprie: né password, né certificati, né segreti client. Esse si affidano al blueprint padre per acquisire i token per loro conto; i tentativi di aggiungere credenziali direttamente a un oggetto identità agente vengono respinti dall'API.

Quindi, mentre keyCredentials e passwordCredentials se compaiono nello schema ereditato, risultano nulli o vuoti per le identità degli agenti e sono di fatto non disponibili. Tale applicazione non deriva dal file dei metadati stesso, bensì dai percorsi di codice della logica di runtime nel livello API, che devono riconoscere il sottotipo e rifiutare le operazioni che non dovrebbero essere applicate.

Una situazione simile si verifica anche nel caso del agentIdentityBlueprintPrincipal oggetto, che a sua volta eredita da servicePrincipal e aggiunge solo il rapporto di proprietà nella definizione del suo sottotipo. Come l’identità dell’agente, eredita l’insieme completo delle credenziali da servicePrincipal sulla carta, ma nella pratica le sue credenziali vengono gestite tramite l'oggetto applicativo "blueprint", e le operazioni sull'oggetto sono vincolate a misure di protezione specifiche per ogni endpoint, controlli dinamici in fase di esecuzione e così via.

Questa è una delle lezioni più importanti in materia di sicurezza nel modello Agent ID: lo schema ci indica ciò che l'oggetto eredita, ma spetta comunque alla piattaforma garantire il rispetto delle operazioni che l'oggetto è autorizzato a compiere.

La parte del problema legata all'utente

Il agentUser L'entità segue lo stesso schema di ereditarietà che abbiamo esaminato, ma questa volta si colloca al di sopra del user oggetto anziché servicePrincipal.

E se sovrapporre i sottotipi di agente alla superficie del soggetto di servizio è una questione delicata, sovrapporli alla superficie dell’utente è probabilmente ancora più delicato. L’oggetto utente riguarda le politiche di autenticazione, le licenze, le funzionalità di collaborazione, l’appartenenza ai gruppi, la struttura organizzativa e i flussi di assegnazione amministrativa che erano stati originariamente progettati attorno alle identità umane.

Dando un'occhiata ai metadati, agentUser deriva da graph.user e non aggiunge nessuna nuova proprietà né nessuna nuova proprietà di navigazione a livello di sottotipo. In altre parole, ogni proprietà e ogni documentato Il tipo di relazione che un utente agente ha dipende dal tipo di base utenti.

Ma “zero nuovi attributi” non significa che non vi sia alcun segnale distintivo.

Il identityParentId La proprietà, che collega l'utente agente alla sua identità di agente padre, è definita sul tipo di base dell'utente stesso. Per i normali umano Per gli utenti, questa proprietà è sempre nulla, mentre per gli utenti agente contiene l'ID dell'oggetto dell'identità dell'agente associata ed è obbligatoria al momento della creazione. La documentazione di Microsoft sottolinea inoltre che questa relazione, una volta stabilita, è immutabile e non può essere cancellata né modificata.

A differenza di quanto avviene nel agentIdentity e agentIdentityBlueprintPrincipal Per quanto riguarda gli oggetti, Microsoft ha adottato una scelta architettonica che prevede di trasferire la proprietà distintiva al tipo padre anziché assegnarla al sottotipo; ciò significa che i metadati OData da soli non ci consentiranno di sapere che agentUser è qualcosa di diverso da un utente e l'unico segnale a livello di schema è il @odata.type discriminatore sull'oggetto stesso.

Questa distinzione è importante in considerazione della funzione per cui sono stati progettati gli utenti-agente. A differenza delle identità degli agenti, che sono oggetti derivati dai service principal e si autenticano tramite flussi di token riservati alle app, gli utenti-agente esistono specificamente per contesti in cui è richiesta un’identità che rispecchi l’utente.

In termini di token, ricevono token con il idtyp=user autorizzazione, il che significa che possono accedere alle API e ai servizi che verificano specificatamente la presenza di un token utente anziché di un token app (Outlook, Teams, SharePoint e qualsiasi altro servizio che dipenda dal tipo di identità), in modo da poter disporre di caselle di posta, unirsi ai canali di Teams e comparire negli organigrammi. Una visione dell’assistente personale basato sull’intelligenza artificiale nel suo massimo splendore.

Microsoft ha documentato diverse restrizioni di sicurezza relative alle identità degli utenti degli agenti:

• Non possono avere password o chiavi di accesso.
• Non è possibile assegnare loro ruoli di amministratore con privilegi.
• Non possono usufruire dell'assegnazione personalizzata dei ruoli né dei gruppi a cui è possibile assegnare ruoli.
• Il loro modello di autorizzazioni predefinito è simile a quello degli utenti ospiti, con capacità leggermente più ampie per quanto riguarda l'enumerazione di utenti e gruppi.

Si tratta di misure di sicurezza importanti. Tuttavia, ognuna di esse deve essere applicata a livello di API e di policy, singolarmente, per ogni percorso di codice che coinvolga un user oggetto.

È proprio questa la parte scomoda. Se un endpoint gestisce agentUser come se fosse solo un altro user e se si dimentica di applicare le restrizioni specifiche del sottotipo, il risultato non è solo un bug. Potrebbe diventare un problema di delimitazione dei privilegi.

Ad esempio, nonostante il vincoli di sicurezza ufficiali per quanto riguarda l'assegnazione dei ruoli privilegiati, durante i test siamo riusciti ad assegnare agli utenti agenti 3 su 32 ruoli contrassegnati con isPrivileged=true:

• Global Reader: lettura completa dei dati presenti nella directory e in Microsoft 365
• Security Reader: accesso in lettura agli strumenti di sicurezza, a Microsoft Defender e a Identity Protection
• Amministratore IA: controllo amministrativo sulle funzionalità relative all'IA e agli agenti

Siamo inoltre riusciti ad assegnare molti ruoli che non sono contrassegnati come privilegiati (o che vengono trattati come standardAssigned) ma che, nella pratica, sono di fatto di livello 0, come l’amministratore della fatturazione, l’amministratore di Exchange, l’amministratore di SharePoint e gli account di sincronizzazione delle directory.

Questo schema non è nuovo, né è esclusivo delle identità degli agenti.

L’eccessiva concessione di autorizzazioni al ruolo di Amministratore AI e^{il caso Silverfort¹} di cui abbiamo parlato nel capitolo precedente sono gli esempi più recenti, ma si inseriscono in una serie ben documentata di “lacune di ambito” di Entra ID. In questi casi, un’autorizzazione o un ruolo che sembra operare su una classe più ristretta di oggetti finisce per raggiungere il tipo di base più ampio o un ambito di controllo più sensibile del previsto. I classici percorsi di escalation dei privilegi dell’“Amministratore delle applicazioni” e dell’“Amministratore delle applicazioni cloud” ne sono esempi lampanti.

Ampiamente documentato da Dirk-jan Mollema²e SpecterOps,³ questi percorsi di escalation sfruttano il fatto che i ruoli possano aggiungere credenziali a qualsiasi entità di servizio nel tenant. Se un’entità di servizio dispone di autorizzazioni per applicazioni ad alto impatto, quali RoleManagement.ReadWrite.Directory o AppRoleAssignment.ReadWrite.All—oppure a cui sono stati assegnati ruoli di directory con privilegi—l'aggiunta di credenziali a tale servizio può consentire all'autore dell'attacco di autenticarsi come entità di servizio e di ereditarne i privilegi effettivi.

La questione relativa all’ambito di applicazione è qui piuttosto sottile; il ruolo è descritto in modo onesto come “gestione delle applicazioni”. Il presupposto pericoloso è che “gestire le applicazioni” non debba significare anche “essere in grado di assumere il controllo di entità di servizio arbitrarie con privilegi elevati”. Microsoft ha successivamente introdotto controlli di blocco delle proprietà delle istanze delle app per ridurre in parte questo rischio, ma la questione di fondo rimane importante: il controllo su un oggetto può trasformarsi in controllo sulle autorizzazioni già associate a quell’oggetto.

La ricerca di Semperis del 2024 su UnOAuthorized ha evidenziato un’altra variante di questo schema. Diversi subject di servizio di prima parte di Microsoft (ricordate questa tipologia dalla tassonomia?) potevano essere utilizzati dagli amministratori di applicazioni e dagli amministratori di applicazioni cloud per aggiungere e rimuovere utenti da ruoli privilegiati. Il problema non era semplicemente quello di “autorizzazioni eccessive” in senso astratto. Si trattava piuttosto di una discrepanza tra i confini previsti per i ruoli e il modo in cui, nella pratica, venivano valutati gli ambiti OAuth 2.0 e i subject di servizio di prima parte.

Allo stesso modo, Datadog I SPy⁴I dati resi noti a partire dal 2025 hanno evidenziato un’ulteriore variazione. In determinati scenari, i soggetti di servizio con i ruoli di Amministratore delle applicazioni cloud, Amministratore delle applicazioni o Application.ReadWrite.All potrebbe dirottare l'entità di servizio di Exchange Online di Office 365 aggiungendovi delle credenziali. Negli ambienti ibridi, ciò potrebbe portare, attraverso una relazione di fiducia tra domini federati, all'accesso con privilegi di amministratore globale. Contesto diverso, stessa lezione: le autorizzazioni limitate alle “applicazioni” possono diventare molto più pericolose quando l'applicazione presa di mira è essa stessa un'entità di fiducia privilegiata.

E la vulnerabilità “Actor Token” di Dirk-jan Mollema,^⁵ CVE-2025-55241, sebbene strutturalmente diversa, rientra nella stessa ampia famiglia. In quel caso, token di impersonazione da servizio a servizio non documentati, combinati con una lacuna nella convalida dei tenant nella vecchia API Azure AD Graph, hanno consentito l’impersonazione tra tenant di qualsiasi utente, inclusi gli amministratori globali, senza registrazioni e senza applicazione dell’accesso condizionale. In questo caso, la lacuna di ambito riguardava il confine del tenant piuttosto che quello del sottotipo di oggetto, ma la lezione fondamentale è la stessa: quando viene introdotta una primitiva privilegiata senza una rigorosa convalida in ogni punto di consumo, alla fine uno di quei punti diventa una via d’accesso.

Allora, cosa significa tutto questo?

Beh, innanzitutto, quell’Agent ID non è un nuovo tipo di oggetto a sé stante. Si tratta di un nuovo modello di identità che si sovrappone alle entità primitive che Entra ID conosce già molto bene: applicazioni, entità di servizio, utenti, autorizzazioni OAuth, assegnazioni di ruoli alle app, credenziali e ruoli di directory.

In secondo luogo, tale progettazione è pratica, ma implica anche che il modello di sicurezza dipenda da un elemento più delicato. La gerarchia dello schema dei metadati può indicarci cosa eredita un oggetto, ma solo il comportamento in fase di esecuzione ci permette di capire quali capacità ereditate siano effettivamente accessibili.

Questa è la tensione fondamentale di Agent ID: Microsoft sta assegnando agli agenti di intelligenza artificiale una rappresentazione di primo piano all’interno di Entra ID, ma lo sta facendo estendendo tipi di oggetti che già da anni rivestono un significato in termini di sicurezza. Ogni proprietà ereditata, ogni azione di ruolo, ogni flusso di token e ogni endpoint diventa ora parte integrante della questione.

Quindi, prima di parlare di come sfruttare, proteggere o monitorare le identità degli agenti, dobbiamo innanzitutto capire la natura stessa di questo concetto.

E ora, speriamo, il quadro sia un po’ più chiaro.

Ok, parliamo di autorizzazioni

La piattaforma Agent ID introduce nuovi tipi di identità in grado di eseguire azioni autonome, agire per conto degli utenti e disporre di autorizzazioni permanenti. Comprendere il loro modello di autorizzazioni è fondamentale per prevenire l’escalation dei privilegi ed evitare percorsi di accesso indesiderati con un impatto significativo. Questo modello introduce inoltre un nuovo concetto di autorizzazione ereditabile, che è necessario comprendere.

Autorizzazioni riservate alle app e autorizzazioni delegate

Come per le normali applicazioni e i principali di servizio, ai modelli di identità degli agenti e alle identità degli agenti possono essere assegnate autorizzazioni limitate all'applicazione o autorizzazioni delegate.

Come abbiamo visto in precedenza, il modello di identità dell’agente contiene sempre un’autorizzazione riservata esclusivamente all’app— AgentIdentity.CreateAsManager—per impostazione predefinita, il che gli consente di creare e gestire le identità degli agenti.

Per quanto riguarda le identità degli agenti, le autorizzazioni "solo app" devono essere utilizzate quando l'agente opera in modo completamente autonomo. Le autorizzazioni delegate si applicano quando un utente è coinvolto nel flusso di lavoro e l'agente deve agire per conto di tale utente.

Autorizzazioni ereditabili

Le autorizzazioni ereditabili sono una configurazione di eredità delle autorizzazioni definita a livello di modello di identità dell'agente. Consentono alle identità degli agenti create a partire dal modello di ereditare automaticamente le autorizzazioni approvate dal modello, evitando così di dover concedere separatamente lo stesso consenso per ogni singola identità dell'agente.

Inizialmente, questo aspetto riguardava principalmente le autorizzazioni delegate, ma l'attuale documentazione Microsoft descrive ora le autorizzazioni ereditabili come compatibili sia con gli ambiti delegati che con i ruoli delle applicazioni. Gli ambiti delegati compaiono nel token di accesso delegato dell'identità dell'agente nel scp rivendicazione, mentre i ruoli dell'applicazione compaiono nel token di accesso "solo app" nel roles affermazione.

Affinché le autorizzazioni ereditabili abbiano effetto, la configurazione del blueprint non è di per sé sufficiente. Devono verificarsi due condizioni:

• L'app di risorse pertinente deve essere configurata nel blueprint inheritablePermissions.
• L'autorizzazione deve essere concessa anche al soggetto principale del blueprint.

Microsoft descrive questa differenza come quella tra dichiarazione, concessione ed eredità: inheritablePermissions è una configurazione, mentre è il consenso relativo al soggetto del modello a conferire l'autorizzazione.

Ciò significa che il allAllowed Questa impostazione non deve essere interpretata nel senso che “l’agente ottiene automaticamente tutte le autorizzazioni esposte dall’applicazione della risorsa”. Significa invece che tutte le autorizzazioni ammissibili di quel tipo, per quell’applicazione della risorsa, concesse al soggetto del blueprint possono essere trasferite alle identità degli agenti. Il token effettivo è quindi il risultato della fusione tra le autorizzazioni ereditate e le eventuali autorizzazioni concesse direttamente alla specifica identità dell’agente.

La configurazione avviene tramite l'applicazione delle risorse; gli ambiti delegati e i ruoli dell'applicazione possono essere configurati in modo indipendente per la stessa risorsa. Ad esempio, un blueprint può ereditare gli ambiti delegati ma non i ruoli dell'applicazione; può ereditare i ruoli dell'applicazione ma non gli ambiti delegati. Gli esempi forniti da Microsoft illustrano questo concetto utilizzando inheritableScopes e inheritableRoles separatamente.

Affinché le autorizzazioni delegabili e ereditarie abbiano effetto, l'entità di servizio del blueprint deve già disporre delle relative OAuth2PermissionGrants voci relative a tali ambiti, a seguito di un consenso a livello di progetto.

Per le autorizzazioni delegate, i modelli di ereditarietà dell'ambito documentati sono:

• allAllowed: Questi modelli ereditano tutti gli ambiti delegati disponibili per la risorsa che hanno concesso.
• noScopes: Questi modelli non ereditano alcun ambito delegato per quell'app di risorse.
• enumerated: Presentati solo nella documentazione dell'API beta, questi modelli includono esclusivamente gli ambiti specificati nell'elenco. Quando si utilizza il modello enumerato, è possibile includere fino a 40 ambiti per ogni applicazione di risorse.

Per quanto riguarda le autorizzazioni delle applicazioni, i modelli di ereditarietà limitati all'app attualmente documentati sono:

• allAllowed: Questi modelli ereditano tutti gli ambiti applicativi disponibili per l'app-risorsa a cui hanno concesso l'accesso.
• noRoles: Questi modelli non ereditano alcun ruolo applicativo per l'app di quella risorsa.

La documentazione ufficiale non prevede alcuna opzione specifica per l'ereditarietà "solo app". Tuttavia, dopo alcuni test, abbiamo scoperto che questa opzione può essere inclusa nel flusso di ereditarietà "solo app".

Lo schema seguente illustra il principio alla base delle autorizzazioni enumerate delegabili ed ereditabili. Uno schema simile sarebbe applicabile anche alle autorizzazioni specifiche dell'app, che funzionano in modo molto simile. (Le differenze saranno illustrate nel Checkpoint pratico 2.)

Un blueprint può definire autorizzazioni ereditabili per un massimo di 60 applicazioni di risorse. Questo limite non è esclusivo dei blueprint.

È inoltre importante notare che alcune autorizzazioni Microsoft Graph ad alto rischio sono bloccate per le identità degli agenti. Microsoft specifica che gli ambiti di autorizzazione delegata o i ruoli applicativi bloccati non possono essere concessi alle identità degli agenti e che l’inclusione di un ambito di autorizzazione delegata o di un ruolo applicativo bloccato comporta il rifiuto della richiesta.

Le autorizzazioni ereditabili sono facoltative. Anche senza utilizzarle, è comunque possibile concedere autorizzazioni direttamente a ciascuna identità di agente singolarmente. La differenza sta nel fatto che le concessioni dirette si applicano solo a quella specifica identità di agente, mentre le autorizzazioni ereditabili consentono all’amministratore di approvare le autorizzazioni una sola volta a livello di modello e di far sì che le autorizzazioni ammissibili vengano trasferite alle identità di agente attuali e future create a partire da quel modello.

Appartenenza al gruppo (solo per utenti agenti)

L'appartenenza a un gruppo è limitata agli utenti agente. Gli utenti agente possono essere aggiunti ai gruppi di sicurezza, ma non ai gruppi a cui è possibile assegnare ruoli. Essi ereditano le autorizzazioni derivanti dalla loro appartenenza ai gruppi allo stesso modo degli utenti normali.

Ruoli di Microsoft Entra

Alle identità degli agenti è possibile assegnare ruoli di directory di Microsoft Entra, analogamente ai soggetti di servizio, ma con importanti limitazioni. I ruoli con privilegi elevati, quali Amministratore globale, Amministratore dei ruoli privilegiati e Amministratore degli utenti, non possono essere assegnati alle identità degli agenti. È supportato solo un sottoinsieme definito di ruoli di Microsoft Entra e alcuni di questi ruoli sono comunque di natura amministrativa; pertanto, devono essere assegnati con cautela in base allo scopo previsto dell’agente e ai requisiti del principio del privilegio minimo.

L'elenco completo dei ruoli supportati è disponibile qui.

Pacchetto di accesso

Oltre ad assegnare l'accesso direttamente all'identità di un agente, le organizzazioni possono utilizzare i pacchetti di accesso. Un pacchetto di accesso consente all'agente o a un gruppo di agenti con le stesse esigenze di accedere alle risorse. I pacchetti di accesso possono includere ruoli Entra, appartenenza a gruppi di sicurezza, autorizzazioni delegate OAuth2 e autorizzazioni applicative, tutte descritte in precedenza.

I pacchetti di accesso vengono configurati da un amministratore, che definisce:

• Quali risorse sono incluse
• Chi può richiedere l'accesso
• Chi deve autorizzare l'accesso
• Quanto dura l'accesso
• E altre impostazioni di politica monetaria

Un agente può richiedere autonomamente un pacchetto di accesso, oppure uno sponsor o un responsabile può richiederlo per suo conto. Il pacchetto può anche essere assegnato direttamente dall'amministratore. Una volta approvato, l'agente riceve un accesso a tempo determinato alle risorse incluse e, se necessario, uno sponsor può richiedere una proroga.

Fare il punto sulla questione dei permessi

Per riassumere il modello delle autorizzazioni, ogni componente della piattaforma Agent ID può disporre delle proprie autorizzazioni. Le identità degli agenti possono avere autorizzazioni limitate all’app o autorizzazioni delegate; gli utenti degli agenti possono far parte di gruppi; infine, i modelli di identità degli agenti possono definire autorizzazioni ereditabili che vengono trasferite a ogni identità di agente creata a partire da essi. A seconda del flusso di autenticazione, gli elementi pertinenti si combinano durante l’esecuzione.

Nel caso di un flusso "Per conto di", combinato con le nuove autorizzazioni ereditabili, le autorizzazioni finali dell'agente saranno le seguenti:

Si prevede un flusso simile anche quando si utilizzano le autorizzazioni "solo per l'app" con autorizzazioni ereditabili. È sufficiente sostituire tutti i termini delegati con termini "solo per l'app".

Successivo: Esercitazione sulla configurazione delle autorizzazioni relative all'identità dell'agente

Ora, fai una deviazione verso il nostro secondo "Practice Checkpoint" e segui i passaggi per assegnare le autorizzazioni all'identità dell'agente che hai configurato nella prima esercitazione.

Esercitarsi a configurare le autorizzazioni relative all'identità degli agenti.

Scopri la guida

• Introduzione: Comprendere e prevenire gli attacchi all’identità degli agenti Entra ID: una guida completa
• Capitolo 1: Scopri le identità degli agenti di Entra ID (a proposito, non sono persone)
• Capitolo 2: La tassonomia delle identità dei carichi di lavoro in Entra ID: applicazioni aziendali, entità di servizio e altre forme di confusione organizzata
• Capitolo 3: Approfondimento sull’ID di Microsoft Agent e sulla piattaforma di identità degli agenti
• Punto di controllo 1 dell'esercitazione: Creazione dell'ID agente con MS Graph
• Punto di verifica 2: Impostazione delle autorizzazioni relative all’identità dell’agente

Note finali

1. https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/
2. Elevazione dei privilegi in Azure AD – Assunzione delle autorizzazioni predefinite dell'applicazione in qualità di amministratore dell'applicazione – dirkjanm.io
3. Escalation dei privilegi in Azure tramite abuso del soggetto di servizio – SpecterOps
4. I SPy: Escalation all’amministratore globale di Entra ID tramite un’app proprietaria | Datadog Security Labs
5. Vulnerabilità dell'Actor Token