La tassonomia delle identità dei carichi di lavoro in Entra ID: entità di servizio, applicazioni aziendali e altre forme di confusione organizzata

A questo punto la nostra guida entra nel merito di aspetti più tecnici, quindi procediamo con attenzione.

Cominciamo dall’inizio: in parole povere, il termine “identità del carico di lavoro” è un concetto generico utilizzato da Microsoft per descrivere diversi tipi di identità non umane che operano all’interno di Entra ID. Queste identità consentono ad applicazioni, servizi, risorse cloud, carichi di lavoro di automazione — e ora anche agli agenti —di autenticarsi e interagire con altri sistemi con un intervento umano minimo o nullo.

Ecco il punto fondamentale: tutte le identità dei carichi di lavoro, compresi i tipi di identità degli agenti di recente introduzione, alla fine si risolvono in un unico tipo di oggetto sottostante: il Service Principal.

E, onestamente, ha senso.

Come considerare i Service Principal

Il servicePrincipal L'entità è probabilmente l'oggetto di identità più versatile in Entra ID. Se si esamina il suo schema tramite l'endpoint OData $metadata di Microsoft Graph, il numero di proprietà, proprietà di navigazione e azioni associate esposte da questo oggetto fornisce già molte indicazioni sul suo ruolo all'interno della piattaforma.

Quel servizio principale, Foundation, svolge qui un lavoro importante, anche se spesso passa inosservato. Si collega a molte delle interfacce e dei sottosistemi gestiti da Entra ID per supportare funzionalità quali la gestione delle credenziali, la concessione di autorizzazioni OAuth, l’assegnazione di ruoli alle app, l’appartenenza ai gruppi, la titolarità, la valutazione dell’accesso condizionale, i meccanismi RBAC, l’audit e la registrazione degli accessi.

Pertanto, quando Microsoft ha sviluppato le identità degli agenti, non ha scelto di creare da zero una primitiva di identità completamente nuova, ma piuttosto di estenderne una esistente.

Come indicato nella documentazione, entrambi agentIdentity¹ e agentIdentityBlueprintPrincipal² gli oggetti (di cui parleremo più approfonditamente in un capitolo successivo) sono tipi specializzati di entità di servizio che rappresentano le istanze di identità degli agenti all’interno dell’ecosistema Microsoft Entra ID. In pratica, ciò significa che ereditano l’architettura esistente delle entità di servizio, compresi i vantaggi, la compatibilità con le API esistenti e, naturalmente, parte della complessità.

È proprio qui che l’architettura assume rilevanza in termini di sicurezza.

Un buon esempio è la^scoperta³ resa nota poco tempo fa dal team di Silverfort.

Quando Microsoft ha introdotto il ruolo di Amministratore dell'ID agente per gestire il nuovo piano di controllo delle identità degli agenti, è stato specificato che il suo ambito di applicazione fosse strettamente limitato agli oggetti relativi agli agenti. In pratica, tale limite non è stato rispettato. Le identità a cui era stato assegnato solo questo ruolo potevano assumere il controllo di entità di servizio arbitrarie, comprese quelle che non avevano nulla a che fare con le identità degli agenti, aggiungendosi come proprietari, aggiungendo credenziali all'entità di servizio e quindi autenticandosi come tale entità.

Si tratta di un’acquisizione totale della società madre.

La probabile causa principale è direttamente riconducibile al modello descritto sopra.

Se agentIdentity e agentIdentityBlueprintPrincipal gli oggetti sono implementati sulla base del servicePrincipal fondamento, allora il livello di autorizzazione deve distinguere in modo affidabile tra entità di servizio supportate da agenti ed entità di servizio “normali”. Tale distinzione deve essere applicata in modo esplicito.

Questo è uno dei motivi per cui Microsoft ha introdotto nuovi ruoli di directory (Amministratore ID agente, Sviluppatore ID agente e Amministratore registro agenti) e ruoli di gestione specifici per gli oggetti (proprietario, sponsor e responsabile) insieme al nuovo modello di identità degli agenti.

Dal punto di vista concettuale, questi ruoli dovrebbero gestire la nuova superficie specifica dell'agente:

• Identità degli agenti
• Principi fondamentali del modello di identità degli agenti
• Modelli di identità degli agenti
• Utenti agenti

La loro autorità dovrebbe essere limitata al modello di agente, non a ogni entità di servizio presente nel tenant.

Come nota a margine interessante e non proprio breve , il modello RBAC visibile non sempre mostra chiaramente l’intera superficie dell’agente. Attualmente, la documentazione di Microsoft relativa all’amministratore degli ID agente fa riferimento alle “Azioni” più generali relative agli agenti, ovvero voci di autorizzazione che definiscono quali operazioni un ruolo di directory è autorizzato a eseguire su specifici tipi di risorse.

Sulla base della documentazione ufficiale, Silverfort ha ipotizzato (a ragione!) che azioni quali microsoft.directory/agentIdentities/owners/update e microsoft.directory/agentIdentityBlueprintPrincipals/owners/update è trapelato dal ruolo integrato al piano di controllo del subject di servizio generale.

Tuttavia, quando si interroga la definizione del ruolo in tempo reale tramite Microsoft Graph, il campo visibile allowedResourceActions sembrano concentrarsi esclusivamente su agentUsers/*.

E elencando le variabili dichiarate microsoft.directory Anche la sezione "Azioni sulle risorse" presenta lo stesso divario: 18 voci relative agli agenti, tutte sotto agentUsers/*. Nessuno per i sottotipi del livello del soggetto di servizio (agentIdentities/*, agentIdentityBlueprintPrincipals/*, e agentIdentityBlueprints/*). Il che, in sostanza, significa che nessun ruolo li prevede.

Un'osservazione in qualche modo simile vale anche per il ruolo di amministratore AI.

A differenza dell'amministratore degli ID degli agenti, che sembra un ruolo altamente specifico per la gestione del piano di controllo degli ID degli agenti, l'amministratore dell'IA è molto più suscettibile di essere delegato in modo più ampio. Le sue responsabilità documentate si concentrano su Microsoft 365 Copilot, i servizi di IA, gli agenti Copilot, le analisi sull'utilizzo, lo stato di salute dei servizi e le operazioni di supporto.

In altre parole, sembra trattarsi di un ruolo operativo nell'ambito dell'intelligenza artificiale, non di un controllo totale sul piano identitario sottostante dell'Agent ID.

Ma nella pratica, il ruolo sembra avere funzionalità di controllo del piano di controllo relative all’ID agente quasi identiche a quelle dell’amministratore dell’ID agente. Su 17 operazioni testate, 17 hanno prodotto risultati identici per entrambi i ruoli. Ciò significa che chiunque detenga il ruolo di amministratore dell’ID agente può assumere la proprietà di qualsiasi identità di agente nel tenant, inserire credenziali in qualsiasi blueprint ed ereditare tutte le autorizzazioni applicative che gli amministratori hanno concesso a tali blueprint.

Nonostante i due ruoli dichiarino cose leggermente diverse allowedResourceActions, e nonostante entrambi ereditino dalla base "Directory Readers" da cui discende quasi ogni ruolo con privilegi (che apporta 55 azioni in sola lettura), la differenza effettiva si limita alle seguenti azioni:

Questi dettagli non figurano nel rapporto Silverfort stesso, ma risultano utili nel contesto. Essi dimostrano che parte del piano di controllo dell’identità degli agenti non è rappresentata come un vocabolario RBAC chiaro e completamente visibile. Parte dell’autorità sugli oggetti relativi agli agenti sembra essere applicata a un livello più profondo del livello API (ad esempio, misure di protezione per singolo endpoint, sovrascritture legate all’ID del modello, controlli dinamici in fase di esecuzione). Ciò spiega anche perché gli oggetti dell’applicazione non siano stati interessati, poiché la vulnerabilità non riguardava la gestione della proprietà.

E questo ci riporta alla questione della sicurezza.

L'ereditarietà conferisce ai sistemi di identità flessibilità, coerenza e riutilizzabilità. Tuttavia, in assenza di confini precisi, può anche ampliare la superficie di attacco a tutti gli oggetti coinvolti.
Tuttavia, la gerarchia di ereditarietà rappresenta solo una delle possibili varianti del modello dei subject di servizio. Oltre a condividere la stessa architettura oggetto sottostante, i subject di servizio sono anche classificati logicamente in diversi tipi di identità.

Tipi di entità di servizio logiche — e in quali casi non funzionano

Nell’ultimo anno ho avuto l’opportunità di viaggiare e presentare EntraGoat, un laboratorio open source e volutamente vulnerabile che abbiamo realizzato in Semperis per condividere e simulare percorsi di attacco all’identità nel mondo reale in Microsoft Entra ID.

I commenti sono stati ottimi, ma ciò che mi è rimasto più impresso sono state le conversazioni che ne sono seguite. Un tema è emerso più volte: le applicazioni e i service principal sono molto più complessi di quanto sembrino a prima vista.

In questa sede speriamo quindi di analizzare tale complessità e di far luce sugli attacchi subiti da queste identità.

Il tipo di entità di servizio può essere identificato tramite il servicePrincipalType proprietà enum, che Entra ID ha assegnato internamente per indicare la categoria logica dell'identità.

Secondo Microsoft, documentazione relativa al servicePrincipal tipo di risorsa, questo campo può contenere cinque valori principali:

• Applicazione
• ManagedIdentity
• Eredità
• SocialIdp
• Identità del servizio

Queste identità sono, secondo la mia esperienza, tra gli oggetti più potenti di Entra ID e spesso si trovano al centro di percorsi di accesso critici.

Comprendere come si comportano questi tipi di entità di servizio, da dove provengono, come si autenticano e cosa li distingue l’uno dall’altro è fondamentale per capire come funziona effettivamente Entra ID “dietro le quinte”.

Comprendere i 5 valori principali dei subject di servizio in Entra ID

Iniziamo a mappare i tipi di entità di servizio logiche nel panorama delle identità dei carichi di lavoro.

Un grande ringraziamento va a Eric Woodruff, Chief Identity Architect di Semperis, per aver individuato per primo questa tassonomia e avercela mostrata.

Applicazioni

Come illustrato nel diagramma delle identità dei carichi di lavoro riportato sopra, il primo gruppo che avvia i subject di servizio in un tenant Entra ID proviene dalle applicazioni che tutti noi utilizziamo e conosciamo, come Microsoft Teams, Salesforce o sistemi sviluppati internamente, ad esempio un portale delle risorse umane.

Un oggetto Application rappresenta la definizione globale di un'applicazione. Viene creato nel tenant in cui l’applicazione è stata originariamente creata (visibile nell’interfaccia utente delle registrazioni delle app ) e funge da modello o schema che definisce la configurazione dell’identità dell’applicazione, inclusi gli URI di reindirizzamento, le autorizzazioni API richieste, le credenziali e altre impostazioni. Ciò significa che l’oggetto descrive come l’IdP possa emettere token che consentono ai client di accedere all’applicazione, le risorse a cui l’applicazione potrebbe dover accedere e le azioni o le autorizzazioni che l’app può eseguire all’interno di un tenant.

Per rendere possibile e integrare tutto ciò, e come potete vedere nell'endpoint dell'API $metadata, anche l'oggetto applicazione è un oggetto complesso (e molto rilevante per le identità degli agenti!) con numerose proprietà e metodi diversi.

A Oggetto "Service Principal" con servicePrincipalType : application rappresenta l'istanza di tale applicazione all'interno di un tenant specifico ed è visualizzabile nel Applicazioni aziendali UI. Si tratta del principio di sicurezza effettivamente utilizzato da Entra ID durante i flussi di autenticazione e autorizzazione.

Il soggetto di servizio consente all'applicazione di effettuare l'accesso o di accedere alle risorse all'interno di quella directory e memorizza i dati specifici del tenant, quali le autorizzazioni concesse, il consenso amministrativo e le assegnazioni dei ruoli alle app. In altre parole, il soggetto di servizio è l'oggetto che ottiene i token, dispone delle autorizzazioni, compare nei registri di accesso—ed è bersaglio di attacchi.

Qual è la differenza tra applicazioni e entità di servizio?

In base alla nostra esperienza, la distinzione tra oggetti applicazione e oggetti entità di servizio è uno dei concetti più spesso fraintesi in Entra ID.

Per cercare di chiarire la differenza, abbiamo elencato i seguenti esempi che mostrano come i due concetti siano correlati pur rimanendo ben distinti. Se avete già familiarità con l'argomento, potete tranquillamente dare solo un'occhiata ai punti elencati.

• Un oggetto applicazione esiste solo nel proprio tenant di appartenenza.
• Un'applicazione a tenant singolo ha esattamente un'entità di servizio, che esiste solo nello stesso tenant (di appartenenza).
• Quando viene concesso il consenso a un'applicazione multi-tenant in un tenant esterno, in tale tenant viene creato solo un entità di servizio e nessun oggetto applicazione.
• Il appId La proprietà (ID applicazione / ID cliente) identifica la definizione dell'oggetto applicazione ed è unico a livello globale tra tutti gli inquilini di Entra ID. Viene assegnato al momento della creazione e non cambia mai.
• Il appId la proprietà di un soggetto di servizio corrisponde sempre al appId del relativo oggetto dell'applicazione. Ecco perché la stessa app di prima parte (come Microsoft Graph) condivide lo stesso appId per tutti i locatari in tutto il mondo.
• Ogni entità di servizio ha il proprio id (ID oggetto) che è univoco all'interno del tenant in cui è presente.
• L'assegnazione dei ruoli alle app e la concessione delle autorizzazioni OAuth2 vengono effettuate a livello del soggetto di servizio, non dell'oggetto applicazione; pertanto, due tenant possono concedere il consenso alla stessa app con ambiti di autorizzazione completamente diversi.
• Le credenziali aggiunte direttamente a un soggetto di servizio sono valide solo per quel tenant specifico e non possono essere utilizzate al di fuori di esso.
• Le credenziali aggiunte all'oggetto dell'applicazione vengono ereditate da tutti i soggetti di servizio in ogni tenant in cui l'app è stata autorizzata, il che consente un vettore di attacco trasversale ai tenant.
• L'eliminazione di un oggetto "service principal" in un tenant non influisce sull'oggetto applicazione (né sui service principal presenti in altri tenant), poiché il ciclo di vita di ciascun service principal è indipendente.
• L'eliminazione dell'oggetto applicazione nel tenant di origine comporta la rimozione automatica del subject di servizio del tenant di origine, ma non comporta la rimozione dei subject di servizio presenti in altri tenant (questi ultimi rimangono fino a quando non vengono rimossi esplicitamente).
• Fino al 1° aprile 2026, e in alcuni casi particolari, era possibile utilizzare un'applicazione senza creare un entità di servizio; tuttavia, questa "autenticazione senza entità di servizio" non dovrebbe più essere supportata.

Tipi di oggetti applicativi

Tutti i subject di servizio associati alle applicazioni provengono generalmente da una delle tre categorie logiche di applicazioni.

Identificazione dei tipi di applicazione

Le applicazioni first-party di Microsoft sono applicazioni di proprietà di Microsoft e da essa gestite che forniscono servizi Azure e M365 quali Exchange Online, SharePoint, Microsoft Graph e centinaia di altri. Vengono visualizzate nel proprio tenant quando un utente ne acconsente, un amministratore ne concede l'accesso oppure Microsoft le configura automaticamente all'attivazione di un servizio o di una licenza (ad esempio E5, Defender o Intune).

Per identificare tali tipi di identità di carico di lavoro, è sufficiente controllare il appOwnerOrganizationId Proprietà GUID su un oggetto "service principal". Nelle app originali di Microsoft, questa proprietà è solitamente impostata sull'ID tenant di Microsoft (f8cdef31-a31e-4b4a-93e4-5f571e91255a), anche se alcuni utilizzano altri ID tenant di proprietà di Microsoft.

È importante comprendere che, sebbene possano comparire nei registri di accesso, la maggior parte dei subject di servizio di prima parte è nascosta per impostazione predefinita nel riquadro " Applicazioni aziendali " dell'interfaccia utente del Portale di Azure, ma è comunque consultabile tramite l'API Graph.

Questo perché il blade dell'interfaccia utente applica un filtro sul WindowsAzureActiveDirectoryIntegratedApp tag, che solitamente identifica le app integrate con Entra ID; tuttavia, i subject di servizio proprietari di Microsoft (volutamente) ne sono sprovvisti.

Inoltre, le app proprietarie di Microsoft funzionano utilizzando meccanismi di autorizzazione interni che vanno oltre gli ambiti standard di OAuth, il che significa che le loro autorizzazioni effettive potrebbero superare quelle visibili tramite le concessioni di autorizzazione e non possono essere verificate completamente tramite le query standard dell'API Graph.

Il tipo successivo di oggetti applicativi, in linea logica, è costituito dalle vostre applicazioni, ovvero le applicazioni di registrazione.

Si tratta di applicazioni registrate direttamente dagli amministratori o dagli sviluppatori tramite l'interfaccia "Registrazioni delle app". In questo caso, l'organizzazione è proprietaria dell'oggetto applicazione e può controllarne integralmente la configurazione, le credenziali e le autorizzazioni. Durante la registrazione, nel tenant di appartenenza viene creato automaticamente un soggetto di servizio corrispondente.

Per mappare i soggetti di servizio creati dalle applicazioni registrate dalla nostra organizzazione, analogamente a come filtriamo le app proprietarie di Microsoft, possiamo enumerare tutti i soggetti di servizio i cui appOwnerOrganizationId è impostato sul nostro ID tenant.

L'ultimo tipo di applicazione supportata è quello delle applicazioni di terze parti/della Galleria.

Si tratta di applicazioni SaaS integrate tramite la Microsoft Entra App Gallery, come Salesforce, ServiceNow o Zoom. Come illustrato in precedenza in questo capitolo, quando viene concesso il consenso a una di queste applicazioni per un tenant, viene creato localmente un entità di servizio (che fa riferimento all’oggetto dell’applicazione multi-tenant del fornitore).

Per identificare i soggetti di servizio creati da applicazioni di terze parti, ovvero applicazioni che non sono state registrate nel nostro tenant e non sono di proprietà di Microsoft, possiamo semplicemente escludere sia il nostro ID tenant che l’ID tenant di Microsoft dall’insieme completo dei soggetti di servizio sul lato client (poiché Microsoft Graph non supporta ne filtri attivi appOwnerOrganizationId).

Vulnerabilità dell'applicazione

Come abbiamo già detto (probabilmente troppe volte ormai), ciascuno di questi tre tipi di applicazione istanzia un oggetto "service principal" locale nel proprio tenant. Il "service principal" rappresenta l'identità di runtime: contiene le autorizzazioni concesse, la configurazione SSO e le impostazioni specifiche del protocollo che Entra ID applica al momento dell'autenticazione.

Esaminando il preferredSingleSignOnMode In base alla proprietà presente sull'oggetto del soggetto di servizio, Entra ID determina quale protocollo SSO utilizza l'applicazione. I valori possibili sono:

• saml: L'applicazione utilizza SAML 2.0, in cui Entra ID funge da provider di identità ed emette asserzioni SAML firmate.
• oidc: L'applicazione utilizza OpenID Connect / OAuth 2.0, il moderno protocollo basato su token.
• password: SSO basato su password, in cui Entra ID inserisce le credenziali nel modulo di accesso dell'applicazione per conto dell'utente.
• notSupported: Non è stato configurato alcun SSO tramite Entra ID.
• null: indica applicazioni SAML o OIDC meno recenti in cui il valore non è stato impostato automaticamente; viene utilizzato anche per altri tipi logici di entità di servizio (come vedremo tra poco).

Dal punto di vista della sicurezza, la modalità SSO comporta conseguenze dirette. Le applicazioni SAML si basano su un certificato di firma dei token configurato sul soggetto di servizio stesso. Se un malintenzionato riesce ad accedere alla chiave privata di tale certificato, può falsificare le asserzioni SAML e autenticarsi come qualsiasi utente di cui l’applicazione si fida.

I ricercatori di Semperis hanno illustrato proprio questo scenario nel blog di ricerca “Meet Silver SAML: Golden SAML in the Cloud”, dimostrando che l’importazione di un certificato di firma generato esternamente in un’entità di servizio (anziché l’utilizzo del certificato autofirmato integrato in Entra ID) crea un vettore di attacco sfruttabile che non richiede alcuna interazione con Entra ID.

Provalo tu stesso su EntraGoat

Poiché nulla illustra meglio come i service principal influenzino l’attuale panorama delle minacce alle identità quanto osservarne l’evoluzione in un ambiente di laboratorio, molti dei percorsi di escalation dei privilegi più significativi presenti in EntraGoat — l’ambiente di laboratorio Entra ID appositamente reso vulnerabile che abbiamo realizzato qui a Semperis — sono interamente incentrati su di essi.

Gli scenari variano per punto di partenza e metodo, ma lo schema è volutamente coerente: una volta individuato un percorso che conduce a un entità di servizio basata su un’applicazione, la strada verso la compromissione dell’intero tenant tende ad essere più breve di quanto chiunque possa immaginare.

Se volete vedere come funziona dall'inizio alla fine, EntraGoat è un ottimo punto di partenza. Leggete gli articoli e seguite le guide passo passo nella nostra serie di post sul blog.

Identità gestite

Le identità gestite rappresentano, in un certo senso, il tentativo di Microsoft di risolvere un problema che noi stessi abbiamo creato: la gestione delle credenziali.

Ogni identità, e in particolare quelle non umane, che si autentica tramite segreti client (password, chiavi di accesso o certificati) comporta una sfida legata al ciclo di vita di tale segreto (rotazione, archiviazione, scadenza e fuga di dati). L’implementazione delle identità gestite ha cercato di eliminare questo onere trasferendo interamente la gestione delle credenziali nel piano di controllo di Azure. L’identità esiste; si autentica, ma nessun essere umano entra mai in contatto (o gestisce in modo improprio) una credenziale ad essa associata.

Tipi di identità gestite

Qualsiasi risorsa che supporti l'autenticazione tramite Entra ID (ad esempio una macchina virtuale, un'App Service, una Logic App, un cluster Kubernetes e molti altri servizi e tipi di risorse di Azure) può utilizzare le identità gestite per ottenere token e accedere ad altre risorse.

Ne esistono due tipi:

• Le identità gestite assegnate dal sistema vengono create come parte integrante e nel contesto della risorsa Azure stessa. Il rapporto è rigorosamente 1:1. Una risorsa, un’identità, un ciclo di vita. L’identità non può esistere in modo indipendente, non può essere condivisa e viene eliminata automaticamente quando viene eliminata la risorsa. Questo stretto accoppiamento rappresenta anche il suo principale vantaggio in termini di sicurezza.
• Le identità gestite assegnate dall'utente, invece, sono risorse Azure autonome. Possono essere associate a una o più risorse e il loro ciclo di vita è indipendente dalle risorse che le utilizzano. Questa natura di disaccoppiamento delle identità gestite assegnate dall'utente rappresenta un vantaggio operativo e, naturalmente, comporta un compromesso in termini di sicurezza.

Identificazione delle identità gestite

Identificare i subject di servizio che rappresentano le identità gestite in Entra ID è piuttosto semplice. È sufficiente eseguire una query sulla directory per trovare il servicePrincipalType proprietà impostata su ManagedIdentity.

In sostanza, entrambi i tipi di identità effettuano l’autenticazione tramite endpoint gestiti da Azure, come ad esempio il Servizio di metadati delle istanze (IMDS) a 169.254.169.254—oppure tramite endpoint di identità resi disponibili da servizi come App Service e Functions. Il flusso di acquisizione dei token avviene interamente all’interno di Azure e nessuna informazione riservata viene trasmessa in rete, né vengono memorizzate credenziali in Key Vault (o, peggio ancora, in appsettings.json), o addirittura rese accessibili agli sviluppatori.

A differenza dei subject di servizio associati alle applicazioni, le identità gestite non sono collegate a un oggetto applicazione nella directory, pertanto non prevedono la registrazione dell'app, né un manifesto, né URI di reindirizzamento. Inoltre, non sono visibili agli utenti e non partecipano ad alcun protocollo SSO.

Ricordate il preferredSingleSignOnMode la proprietà di cui abbiamo parlato in precedenza? Speriamo che ora abbiate compreso perché questa e altre proprietà specifiche dell'autenticazione sono in genere nulle per le identità gestite. Queste, infatti, non effettuano l'autenticazione tramite SAML, OIDC o flussi basati su password. Azure, invece, emette e gestisce certificati con un periodo di validità di 90 giorni, sostituendoli ogni 45 giorni, per ciascuna identità gestita.

Questi certificati sono rilasciati da Microsoft.ManagedIdentity e includere l'ID oggetto dell'entità del servizio di identità gestita nel soggetto del certificato. Azure li utilizza per eseguire l'autenticazione basata su certificato ed emettere token direttamente tramite il proprio piano di controllo, senza esporre le credenziali al tenant (o ai suoi amministratori).

È possibile osservare parte di questo meccanismo attraverso il keyCredentials proprietà dell'oggetto principale del servizio dell'identità gestita.

A differenza dei subject di servizio basati su applicazioni, in cui keyCredentials Di solito contiene certificati caricati da un amministratore o da uno sviluppatore; per le identità gestite, invece, le credenziali delle chiavi vengono inserite e aggiornate interamente da Azure.

E, effettivamente, quando si interroga la proprietà, viene visualizzato un AsymmetricX509Cert voce con l’opzione “Usage” impostata su “Verify”, in cui l’ID dell’oggetto principale del servizio è il soggetto del certificato.

Questo progetto è elegante, finché non lo si guarda dal punto di vista di un malintenzionato.

Vulnerabilità relative alle identità gestite

Esistono due modelli distinti di abuso che vale la pena comprendere e che mostrano come il modello inizi a snodarsi quando la teoria si confronta con le esigenze della realtà.

Il primo è il furto di token tramite la risorsa allegata.

Poiché le identità gestite effettuano l'autenticazione tramite endpoint locali (IMDS o l'endpoint di identità della piattaforma), qualsiasi soggetto con diritti di accesso (ovvero, in grado di eseguire codice sulla risorsa sottostante) può richiedere un token per conto dell'identità gestita.

Questo è il classico vettore di attacco, ampiamente documentato:

1. Compromettere un utente con accesso a una macchina virtuale / un registro dei container / Arc / AKS / account di automazione / App Services / Logic Apps / script di distribuzione / Data Factory
2. Interrogare in qualche modo l'endpoint del token (Invoke-WebRequest 169.254.169.254/metadata/identity/oauth2/token)

Se questa operazione restituisce un risultato, ora disponi di un token OAuth valido, con un ambito limitato alle autorizzazioni di cui dispone quell’identità per l’utilizzo delle API di Azure.

Sebbene questa tecnica si applichi sia alle identità gestite assegnate dal sistema sia a quelle assegnate dall'utente, la superficie di attacco varia direttamente in base al contesto dell'identità.

Nel caso di identità gestite assegnate dall'utente e condivise tra più risorse, una singola identità compromessa può essere utilizzata per richiedere token per ogni risorsa su cui dispone di autorizzazioni. Un classico esempio di movimento laterale.

Oppure, come spiegato brevemente su Microsoft Learn:

Il confine di sicurezza delle identità gestite per le risorse di Azure è rappresentato dalla risorsa in cui viene utilizzata l'identità. Tutti i codici e gli script in esecuzione su una macchina virtuale possono richiedere e recuperare token per qualsiasi identità gestita disponibile su di essa.

Il secondo modello di abuso è quello relativo all’uso improprio delle credenziali federate, che mina il modello di fiducia alla base delle identità gestite.

Come abbiamo visto poco fa, le identità gestite assegnate dall’utente non supportano la configurazione delle credenziali tradizionali; è espressamente vietato modificare queste proprietà sul soggetto di servizio che rappresenta l’identità gestita in Entra ID. Tuttavia, supportano le credenziali di identità federate. Queste consentono ai provider di identità esterni (come GitHub Actions o qualsiasi emittente conforme allo standard OIDC, compreso uno self-hosted) di autenticarsi come identità gestita senza alcuno scambio di segreti.

Non ci addentreremo troppo nei dettagli di implementazione in questa sede, dato che questo capitolo si è già dilungato abbastanza, ma a grandi linee ciò può essere realizzato creando un federatedIdentityCredential oggetto sul soggetto del servizio dell'identità gestita tramite l'API ARM, specificando un URL dell'emittente OIDC e un identificatore del soggetto.

Quindi, al momento dell'autenticazione, Entra ID verifica la validità del token esterno rispetto all'emittente configurato e ne confronta il subject claim. Tuttavia, non verifica la corrispondenza tra l'emittente e il tenant o la risorsa dell'identità gestita.

Ciò significa che qualsiasi committente con il Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write Un'azione nell'ambito delle autorizzazioni RBAC di Azure (che include diversi ruoli predefiniti, quali Collaboratore, Proprietario e Collaboratore con identità gestita) consente di aggiungere una nuova credenziale federata che rimanda a un repository esterno o a un ambiente sotto il proprio controllo.

Una volta configurata tale credenziale, l'autore dell'attacco effettua l'autenticazione dal proprio flusso di lavoro GitHub (o da qualsiasi ambiente conforme allo standard OIDC), riceve un token valido per l'identità gestita e opera con l'intera serie di autorizzazioni (interamente al di fuori dei confini delle risorse di Azure).

In entrambi i casi, il problema fondamentale è lo stesso: le identità gestite sono state progettate per eliminare il rischio legato alle credenziali all’interno dei confini di una risorsa, ma il modello di autorizzazioni di Azure consente a chiunque disponga di un accesso RBAC sufficiente di estendere (o aggirare completamente) tali confini.

L'identità è destinata a risiedere all'interno di uno specifico contesto di esecuzione, ma l'accesso ad essa non rimane sempre confinato a tale contesto. Nel primo caso, è possibile assumerne il controllo ottenendo l'esecuzione del codice su una risorsa a cui è associata l'identità gestita. Nel secondo caso, è possibile assumerne il controllo tramite una relazione di fiducia federata che non richiede alcuna connessione effettiva alla risorsa Azure originale.

Identità Legacy e SocialIdp

I prossimi due tipi di identità dei subject di servizio sono Legacy e SocialIdP. Entrambi sono meno rilevanti ai fini principali della presente guida, pertanto li tratteremo solo brevemente.

Il tipo Legacy indica le applicazioni più datate, create prima dell'introduzione del modello moderno di registrazione delle app o tramite interfacce legacy. Il appId Su di esso è presente una proprietà che però non rimanda a una registrazione dell'app. Un soggetto di servizio legacy può comunque disporre di credenziali e URL di risposta che gli amministratori possono gestire direttamente, e può essere utilizzato solo nel tenant in cui è stato creato.

Il tipo SocialIdp è documentato da Microsoft come “per uso interno”, pertanto sono disponibili poche informazioni pubbliche al riguardo. In base al nome e al contesto di utilizzo, è probabile che si riferisca a provider di identità social (come Google o Facebook) configurati per i flussi utente B2C. In pratica, questo tipo consente a B2C di integrarsi con provider social esterni, ma in genere non si interagisce direttamente con esso, a meno che non si stia lavorando con politiche personalizzate B2C.

ServiceIdentity: il tipo di entità di servizio per gli agenti

Questo ci porta alla categoria più recente di questo ecosistema: ServiceIdentity, il modello di identità introdotto per supportare le operazioni digitali basate sugli agenti.

Le identità degli agenti si basano su due concetti fondamentali di Entra ID: l’oggetto Application e l’oggetto Service Principal. Ecco perché, per comprendere come funzionano le identità degli agenti e quale sia il loro “potenziale”, abbiamo dovuto innanzitutto comprendere i diversi modelli da cui derivano.

A grandi linee, il agentIdentityBlueprint, che è un sottotipo di applicazione, definisce il modello dell'agente e contiene le credenziali. Il agentIdentity, un sottotipo di servicePrincipal con proprietà servicePrincipalType impostato su ServiceIdentity, è l'oggetto di runtime specifico per ciascun agente che ottiene le autorizzazioni e interagisce con le risorse.

Questa distinzione è importante perché le identità degli agenti non dispongono di credenziali proprie.

Al contrario, si affidano al blueprint per acquisire token per loro conto attraverso un modello di impersonificazione. Il blueprint effettua l'autenticazione utilizzando le proprie credenziali ed esegue uno scambio di token in cui il token risultante identifica l'agente come cliente, anche se è stato il blueprint a eseguire l'autenticazione effettiva.

Come si può vedere nel diagramma, c'è anche un terzo oggetto (attenzione: spoiler, ce n'è anche un quarto) nel modello: il agentIdentityBlueprintPrincipal, che eredita da servicePrincipal e funge da rappresentazione locale del blueprint nel tenant. Viene creato quando un blueprint viene istanziato in un tenant ed è ciò che consente al blueprint di ottenere token specifici dell'app per creare e gestire le identità degli agenti.

Un’altra importante distinzione architettonica è il modello di relazione. Le applicazioni tradizionali seguono solitamente una relazione uno a uno tra l’oggetto dell’applicazione e il soggetto di servizio nel tenant di origine, mentre le applicazioni multi-tenant creano un soggetto di servizio per ogni tenant in cui l’applicazione viene utilizzata. Il modello a agente aggiunge un ulteriore livello: un singolo blueprint può generare più soggetti di servizio con identità di agente all’interno di un singolo tenant e tra tenant diversi.

Comprendere questa distinzione è fondamentale per comprendere sia l'architettura che la superficie di attacco, poiché le identità degli agenti non sono semplicemente “un altro tipo di entità di servizio”.

In un capitolo successivo approfondiremo un po’ questa architettura, esamineremo cosa rivela l’endpoint dei metadati OData di Microsoft Graph riguardo alle relazioni tra questi oggetti, quali livelli di autorizzazione sono probabilmente in atto e formuleremo alcune ipotesi fondate su dove potrebbero emergere future vulnerabilità.

Ma prima daremo un’occhiata al framework che Microsoft ha sviluppato per l’autenticazione, l’autorizzazione, la gestione e la protezione di queste identità non umane.

Non perdetevi il prossimo capitolo: "Comprendere l'ID di Microsoft Agent e la piattaforma di identità degli agenti".

Scopri la guida

Passa al prossimo capitolo pubblicato della serie oppure scegli la tua avventura.

• Introduzione: Comprendere e prevenire gli attacchi all’identità degli agenti Entra ID: una guida completa
• Scopri le identità degli agenti di Entra ID (a proposito, non sono persone)

Note finali

• 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/