Semion Vasilevitzky e Jonathan Elkabas

Nota dell'editore: Benvenuti al Capitolo 6 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.

La piattaforma Agent ID introduce nuovi tipi di identità e modelli operativi e, poiché questa funzionalità è ancora agli inizi del proprio sviluppo, le configurazioni errate e le vie di attacco concrete stanno appena iniziando a emergere. In questa sezione non cercheremo di trattare ogni possibile rischio o punto debole. Ci limiteremo invece a evidenziare una piccola serie di configurazioni errate, semplici ma significative, che potrebbero diventare comuni man mano che le organizzazioni inizieranno ad adottare Agent ID su larga scala.


Chi è il titolare di questo agente? ID agente senza titolare né sponsor

Le identità degli agenti non gestite (quelle prive di proprietario e sponsor) creano una lacuna nella governance delle identità. Quando non vi è una persona o un team a cui attribuire la responsabilità, queste identità dei carichi di lavoro rischiano maggiormente di essere trascurate durante gli audit e di sfuggire all’attenzione durante la risposta agli incidenti.

Nella pagina di panoramica dell'ID agente Entra è possibile visualizzare il numero di identità degli agenti non gestiti.

Figura 1. Visualizzazione delle identità degli agenti non gestiti nella panoramica degli ID degli agenti Microsoft

Sebbene sia necessario specificare almeno uno sponsor al momento della creazione dell'identità di un agente, è comunque possibile che, con il passare del tempo, alcune identità diventino non gestite. Ad esempio, questa situazione potrebbe verificarsi se un utente che fungeva da sponsor venisse eliminato, ad esempio dopo aver lasciato l'organizzazione.

Un'altra situazione simile, che però non compare nella pagina di panoramica, si verifica quando l'account dello sponsor o del proprietario viene disattivato. In questi casi, l'identità dell'agente sembra avere un proprietario o uno sponsor assegnato, ma l'account assegnato non è più attivo all'interno dell'organizzazione. Ciò rende l'identità di fatto "orfana" e facile da trascurare da parte degli amministratori.

Idealmente, le identità degli agenti dovrebbero sempre avere una persona in carne e ossa che ne sia responsabile e consapevole della loro finalità. Garantire una gestione continua è una parte essenziale della governance delle identità.

In Semperis Lightning Intelligence e Directory Services Protector DSP)—due soluzioni che fanno parte della Identity Resilience Platform—segnalano già queste due situazioni. In una dashboard chiara, è possibile visualizzare non solo il numero di identità degli agenti non gestiti, ma anche l’elenco esatto.

Figura 2. Visualizzazione delle identità degli agenti non gestiti nella piattaforma Semperis

È inoltre possibile visualizzare le identità degli agenti "orfani" di cui si è parlato e quali siano esattamente gli sponsor o i proprietari disabilitati che, di fatto, rendono tali identità "orfane".

Figura 3. Identificazione degli sponsor e dei proprietari degli agenti disabilitati

Chi conosce il mio segreto? Schemi basati sui segreti dei clienti

Come descritto in precedenza nel “Practice Checkpoint 1” di questa guida, un segreto client è uno dei tipi di credenziali che possono essere assegnati a un modello di identità dell’agente. Questo tipo di credenziale è considerato debole perché viene spesso memorizzato in file di configurazione, script, pipeline CI/CD o repository di codice sorgente, dove potrebbe essere divulgato involontariamente. Se un malintenzionato ottiene un segreto client, può autenticarsi come quel modello di identità dell’agente o come le identità degli agenti ad esso associate senza che sia necessario un accesso interattivo o l’autenticazione a più fattori (MFA).

Microsoft avverte espressamente che:

I segreti del client non dovrebbero essere utilizzati come credenziali del client negli ambienti di produzione per i modelli di identità degli agenti, a causa dei rischi per la sicurezza.

Microsoft raccomanda invece di utilizzare credenziali di identità federate (FIC) con identità gestite o certificati per l'autenticazione.

Gli indicatori di Semperis ti consentono di monitorare tutti i modelli di identità degli agenti contenenti informazioni riservate in un'unica piattaforma centralizzata e di individuare le credenziali configurate in modo errato per ciascun modello.

Figura 4. Panoramica delle credenziali del modello di identità dell'agente configurate in modo errato

Troppo potere: identità di agenti altamente privilegiati

Finora abbiamo parlato di come gli agenti ottengano autorizzazioni esclusive per le app o delegate e di come avvenga l'assegnazione dei ruoli in questo modello. Sebbene Microsoft limiti le autorizzazioni e i ruoli che possono essere assegnati alle identità degli agenti, l'applicazione del principio del privilegio minimo rimane fondamentale.

I permessi con privilegi elevati assegnati a un'identità agente aumentano il rischio anche in assenza di un aggressore. Le identità agente possono essere eseguite automaticamente ed eseguire azioni su larga scala. Se un agente è configurato in modo errato, si comporta in modo imprevisto o è integrato in modo errato in un flusso di lavoro, i privilegi elevati possono trasformare un semplice errore in un incidente che coinvolge l'intero tenant. Dal punto di vista della sicurezza, le identità agente con privilegi eccessivi aumentano la superficie di attacco e potrebbero diventare un bersaglio per gli aggressori.

Gli amministratori dell'organizzazione dovrebbero verificare regolarmente le autorizzazioni assegnate alle identità degli agenti e ridurle al minimo necessario per il funzionamento dell'agente.

Gli indicatori di Semperis ti mostrano in un unico posto le identità degli agenti con privilegi elevati e i loro ruoli con privilegi eccessivi.

Figura 5. Identificazione dei ruoli con privilegi eccessivi

Conclusioni

Le identità degli agenti non sono semplicemente un’altra casella da spuntare nel Centro di amministrazione di Microsoft Entra. Rappresentano il tentativo di Microsoft di attribuire agli agenti IA un’identità formale all’interno della directory. Non si tratta di un vago oggetto di automazione, né semplicemente di un’entità di servizio con una nuova funzione. Si tratta di un nuovo modello di identità che cerca di rappresentare gli agenti come entità che la piattaforma è in grado di riconoscere, gestire, autorizzare e sottoporre a controllo.

E questo è importante perché nel momento in cui un agente deve attraversare il confine di un sistema, chiamare un’API, leggere dati organizzativi, aggiornare uno stato, inviare un messaggio, accedere a una casella di posta o agire per conto di qualcosa di più grande di sé, smette di essere solo “logica di IA”. Diventa un partecipante al sistema di identità. Ha bisogno di un soggetto. Ha bisogno di autorizzazioni. Ha bisogno di un token. Ha bisogno di una posizione nella directory.

Agent ID è la risposta di Microsoft a tale esigenza.

Al centro di questo modello si trova l’Agent Identity Blueprint, il modello a partire dal quale vengono create le identità degli agenti e attraverso il quale possono essere trasmesse le autorizzazioni ereditate. Attorno ad esso, Microsoft ha introdotto diversi oggetti correlati: identità degli agenti, utenti degli agenti, soggetti del modello e agenti legacy supportati da entità di servizio. Insieme, formano un nuovo livello operativo per gli agenti di intelligenza artificiale all’interno di Entra ID.

Ma, come abbiamo visto nel corso di questa guida, l’Agent ID non nasce dal nulla. Si basa sulle primitive esistenti di Entra ID, e tali primitive sono già caratterizzate da una struttura, da autorizzazioni, da presupposti e da un bagaglio storico.

Le identità degli agenti ereditano da quelle dei soggetti di servizio. Gli utenti degli agenti ereditano da quelli degli utenti. I blueprint ereditano dalle applicazioni. Le autorizzazioni vengono gestite tramite i consueti meccanismi OAuth e di assegnazione dei ruoli alle app. L'applicazione dei ruoli dipende ancora dalle azioni RBAC, dai controlli API e dal comportamento in fase di esecuzione. I nomi sono nuovi, ma il piano di controllo sottostante è molto familiare.

E, a dire il vero, questo rappresenta sia il punto di forza (dal punto di vista operativo) sia il rischio (in termini di sicurezza) del modello.

Ciò significa che Agent ID può integrarsi in modo naturale con Entra ID, Microsoft Graph, i registri di audit, le autorizzazioni delle app e i flussi amministrativi esistenti. Ma significa anche che ogni funzionalità ereditata, ogni presupposto nascosto e ogni vecchio problema di ambito tornano ad essere rilevanti in un nuovo contesto.

Le identità degli agenti introducono una nuova superficie di attacco e dovremmo aspettarci che emergano nuovi percorsi di attacco man mano che le organizzazioni iniziano ad adottarle. Alcuni deriveranno probabilmente da modelli con autorizzazioni eccessive. Alcuni da confini dei ruoli poco chiari. Alcuni da autorizzazioni ereditate che i responsabili della sicurezza non hanno ancora individuato correttamente. Alcuni da utenti-agente che interagiscono con interfacce originariamente progettate per utenti umani. Alcuni dall’accesso condizionale e dal comportamento dei token, che necessitano ancora di test pratici più approfonditi. E alcuni, come sempre, da quei punti banali che nessuno ha preso in considerazione perché il portale e la documentazione li facevano sembrare innocui.

L’importante è non considerare gli agenti come qualcosa di magico o di separato da ciò che già conosciamo, perché sono identità.

E le identità si autenticano, ottengono l’autorizzazione, eseguono azioni e lasciano tracce dietro di sé. Il solito ciclo AAA ora indossa una maschera a forma di IA.

Quindi, se c'è un insegnamento pratico da trarre da questa immersione, è proprio questo.

Non fermarti all'etichetta del portale o alla tabella della documentazione. Segui il modello a oggetti. Segui l'ereditarietà. Segui il token. Segui le autorizzazioni. Segui le azioni dei ruoli. Segui i registri di audit e di accesso. Il vero comportamento della piattaforma di solito si rivela da qualche parte tra ciò che descrive lo schema, ciò che promette la documentazione e ciò che il runtime consente effettivamente.

Man mano che l’Agent ID continua a evolversi, le questioni più spinose non saranno solo di natura tecnica. Saranno questioni di fiducia: quanto accesso siamo disposti a concedere a queste identità, con quanta chiarezza riusciamo a vedere cosa stanno facendo e in che misura la piattaforma è in grado di far rispettare i limiti che le circondano una volta che iniziano a operare su larga scala.

Perché gli agenti non sono semplicemente codice che gira silenziosamente in background. Sono codice dotato di autonomia, rivestito di identità, che dispone di autorizzazioni, prende decisioni e supera i confini per conto di qualcun altro o di qualcos’altro.

E quando il codice acquisisce autonomia, identità e affidabilità, diventa qualcosa di più di una semplice “automazione”.

Diventa una volontà delegata all’interno del sistema, che porta con sé le nostre autorizzazioni, le nostre supposizioni e, alla fine, le nostre conseguenze.


Non tirare a indovinare: esegui una scansione. In che modo Semperis può aiutarti?

Gli strumenti di Semperis offrono già la possibilità di individuare lacune nella governance, evidenziare potenziali punti di esposizione e contribuire a portare alla luce questo tipo di configurazioni errate e rischi. Si tratta di un ambito ancora in evoluzione e, qui a Semperis, stiamo già lavorando a ulteriori indicatori di esposizione e a funzionalità di rilevamento più approfondite che verranno introdotte nel corso del tempo.

Man mano che amplierete l'adozione delle identità degli agenti nei vostri sistemi di gestione delle identità, vi troverete sicuramente di fronte a nuove domande in ogni fase del processo. Contattateci in qualsiasi momento: siamo qui per aiutarvi.


Ulteriori letture


Scopri la guida