Configurare la sicurezza delle identità agente con Zero Trust Assessment

Gli agenti di intelligenza artificiale acquisiscono i token di accesso per le risorse dell'organizzazione in ogni interazione, tra cui posta, file, API line-of-business e agenti downstream. A differenza degli utenti interattivi, gli agenti in genere non presentano gli stessi segnali di accesso, ad esempio l'autenticazione a più fattori utente, lo stato del dispositivo gestito o il contesto della posizione. La protezione del piano di controllo di intelligenza artificiale è quindi essenziale per il percorso di Zero Trust.

I problemi dell'agente vengono comunemente visualizzati in tre aree:

  • Autenticazione e incongruenza delle policy: le policy progettate per gli utenti potrebbero non rilevare schemi di token specifici degli agenti e modelli di esecuzione.
  • Accesso con autorizzazioni eccessive: gli agenti spesso accumulano autorizzazioni API estese in Microsoft Graph e nelle API personalizzate, aumentando la portata di un eventuale impatto.
  • Gap relativi al ciclo di vita e alla responsabilità: le identità degli agenti orfani, i proprietari o gli sponsor mancanti e le credenziali non aggiornati creano rischi permanenti.

Le raccomandazioni e i controlli Zero Trust che fanno parte di questo pilastro contribuiscono a ridurre il rischio di accesso non autorizzato all'IA. I temi includono l'applicazione dell'autenticazione Entra sugli endpoint dell'agente, l'applicazione dei criteri di accesso condizionale alle identità degli agenti, l'assegnazione dei controlli di governance del ciclo di vita e la garanzia che i ruoli amministrativi di intelligenza artificiale abbiano entità responsabili.

Zero Trust raccomandazioni sulla sicurezza per l'intelligenza artificiale

Richiedere Microsoft Entra ID'autenticazione per interagire con gli agenti

Un endpoint di un agente che non richiede l'autenticazione utente di Microsoft Entra costituisce una superficie accessibile senza autenticazione, ma raggiungibile, all'interno dell'ecosistema di IA del tenant. Un attaccante potrebbe individuare questo endpoint scoprendo URL pubblici degli agenti, utilizzando collegamenti di Copilot Studio trapelati o enumerando gli endpoint dei progetti Foundry. L'attore può quindi interagire con l'agente senza presentare un'identità e usare le concessioni esistenti dell'agente per accedere ai dati di base, agli strumenti connessi e alle API downstream.

Le chiamate che non raggiungono Microsoft Entra non possono essere valutate dai criteri di accesso condizionale, non hanno alcun rischio di accesso da calcolare e non possono associare i record di controllo a un utente specifico. La mancanza di queste informazioni rende difficile indagare e correggere. Il comportamento in fase di esecuzione che impone l'autenticazione utente di Microsoft Entra risiede all'interno dell'host di ciascun agente (Copilot Studio, Microsoft 365 Copilot, Microsoft Foundry, codice personalizzato o piattaforme non Microsoft) e pertanto non è direttamente osservabile dalla directory. Ciò che è osservabile è la traccia lasciata nei log di accesso di Microsoft Entra ogni volta che un agente e i relativi chiamanti passano effettivamente tramite Microsoft Entra.

Questo controllo esamina gli ultimi 30 giorni di attività di accesso per ogni identità dell'agente e classifica l'agente in base all'evidenza più forte trovata: un accesso non interattivo dell'agente in cui l'oggetto è un utente reale è il segnale positivo più forte. Anche un accesso interattivo di un utente al blueprint dell'agente costituisce un'evidenza positiva del fatto che gli utenti accedono all'agente tramite Microsoft Entra. L'assenza di uno dei due segnali durante il periodo di osservazione significa che la piattaforma non può confermare che l'agente applichi l'autenticazione utente di Microsoft Entra e un responsabile designato deve verificare direttamente la configurazione host dell'agente.

Azione di correzione

I criteri di accesso condizionale coprono sia le identità degli agenti che gli account utente degli agenti

Quando un'organizzazione implementa agenti di intelligenza artificiale, questi agenti acquisiscono token di accesso per accedere alle risorse organizzative a ogni interazione, ma senza una sessione utente interattiva né segnali relativi a dispositivo, posizione o MFA che l'Accesso condizionale classico usa per prendere decisioni di fiducia per gli utenti umani. Microsoft Entra Agent ID introduce due tipi di identità distinti:

  • Un'identità agente: un account di identità in Microsoft Entra ID che fornisce funzionalità di identificazione e autenticazione univoche per gli agenti di intelligenza artificiale.
  • Un account utente di un agente: un account opzionale che corrisponde in rapporto 1:1 all'identità di un agente quando l'agente deve accedere a sistemi che richiedono un oggetto utente.

L'accesso condizionale considera entrambi gli oggetti Identity dell'agente come tipi di entità separati. Pertanto, un criterio destinato alle identità dell'agente non può essere destinato all'account utente di un agente e viceversa. Un tenant che abilita i workload degli agenti senza almeno un criterio di Accesso Condizionale che imponga il blocco se non approvato non dispone di alcun meccanismo di applicazione per l'accesso autonomo all'IA. Ogni richiesta di token da un'identità agente o dall'account utente dell'agente è consentita per impostazione predefinita. Gli aggressori cercano di sfruttare questo tipo di modalità di guasto quando compromettono l’identità di un singolo agente o l’account utente dell’agente sottostante e si spostano lateralmente tra le risorse a cui tale identità può accedere.

Azione di correzione

L'accesso condizionale basato sul rischio blocca le identità degli agenti rischiosi

Quando un'organizzazione abilita gli agenti di intelligenza artificiale in Microsoft Entra, le identità degli agenti possono ottenere token di accesso per accedere alle risorse dell'organizzazione senza una sessione utente interattiva e senza i segnali relativi a dispositivo, posizione o MFA che l'Accesso condizionale classico usa per prendere decisioni di attendibilità per gli utenti umani. Microsoft Entra ID Protection per gli agenti valuta continuamente il comportamento di ogni agente e genera un livello di rischio basato su segnali come:

  • Accesso non familiare alle risorse (l'agente raggiunge al di fuori dei modelli stabiliti)
  • Picchi di accessi (riutilizzo dei token o abuso dell'automazione)
  • Scansione di accessi non riusciti (un attaccante che enumera le risorse con le credenziali dell'agente)
  • Accessi da parte di utenti rischiosi durante l'autenticazione delegata (un utente malintenzionato che sfrutta un account utente compromesso)
  • Compromissione confermata dall'amministratore (un amministratore della sicurezza contrassegna manualmente l'agente come compromesso)

Senza un criterio di accesso condizionale che tiene conto del livello di rischio e blocca l'emissione di token, la piattaforma può semplicemente limitarsi a registrare che un'entità è ad alto rischio, continuando però a emettere proprio i token di cui l'attaccante ha bisogno. I log dicono "compromesso" mentre la risorsa dice ancora "sì". È necessario un criterio di accesso condizionale basato sul rischio che blocca le identità degli agenti ad alto rischio per colmare questo divario tra il rilevamento e l'imposizione.

Azione di correzione

Sono presenti attributi di sicurezza personalizzati per le identità dell'agente

Gli attributi di sicurezza personalizzati sono il meccanismo principale per l'accesso condizionale per distinguere le identità dell'agente su larga scala. Senza di essi, i criteri di accesso condizionale possono essere destinati solo a tutte le identità degli agenti, ai singoli agenti in base all'ID oggetto o agli agenti raggruppati in base al progetto. Man mano che aumenta la flotta di agenti, questi meccanismi non possono essere ridimensionati. Gli attributi di sicurezza personalizzati consentono di filtrare gli agenti in base al reparto, allo stato di approvazione, al livello di riservatezza o a qualsiasi classificazione definita dall'organizzazione. Ad esempio, un set di attributi chiamato AgentAttributes con un AgentApprovalStatus attributo (valori come New, , In_ReviewHR_ApprovedFinance_Approved) IT_Approvedabilita i criteri di accesso condizionale basati su attributi che corrispondono agli agenti alle risorse in base alla classificazione.

Quando le identità degli agenti non dispongono di attributi di sicurezza personalizzati, l'organizzazione non può applicare in modo affidabile criteri di accesso condizionale basati su attributi. Un'identità agente appena sottoposta a provisioning o non classificata riceve gli stessi controlli di accesso di un'identità agente completamente verificata, perché non vi sono metadati che consentano di distinguerle. Un attore malevolo che compromette o registra l'identità di un agente non autorizzato ottiene l'accesso senza essere soggetto all'applicazione dei criteri basati sulla classificazione. L'assegnazione di attributi di sicurezza personalizzati chiude questo divario assicurando che ogni identità dell'agente contenga metadati di classificazione leggibili dal computer che possono essere utilizzati dall'accesso condizionale e dalle query di controllo.

I criteri destinati a tutte le identità degli agenti senza filtri degli attributi possono comunque fornire protezione di base, ma non possono distinguere tra agenti approvati e non approvati. L'implementazione di controlli basati su attributi richiede:

  • Definizione di una tassonomia degli attributi
  • Coordinamento con i proprietari delle applicazioni
  • Definizione di un processo operativo per contrassegnare i nuovi agenti durante il provisioning

Azione di correzione

La governance delle identità per gli sponsor dell'identità agente è configurata

Microsoft Entra Agent ID richiede che ogni identità agente e ogni modello di identità agente abbiano almeno un responsabile. Uno sponsor è un utente umano o un gruppo supportato che mantiene la responsabilità aziendale per il ciclo di vita dell'agente, ad esempio decidere quando l'agente non è più necessario, approvare le estensioni alla scadenza dell'accesso e autorizzare la sospensione durante gli eventi imprevisti. Uno sponsor è diverso da un proprietario, che designa gli utenti umani responsabili delle operazioni tecniche e della risposta agli eventi imprevisti.

La sponsorship è il punto di accesso alla governance delle identità:

  • I flussi di lavoro del ciclo di vita possono instradare le notifiche di abbandono dello sponsor ai manager
  • Le escalation di scadenza del pacchetto di accesso vengono inviate allo sponsor
  • Gli approvatori di Entitlement Management si basano sul rapporto con lo sponsor per confermare il permanere dell'accesso.

Senza uno sponsor assegnato, le identità degli agenti non possono essere regolate correttamente. Un'identità di un agente che esiste senza uno sponsor è invisibile alla governance. Senza un pacchetto di accesso destinato alle identità degli agenti, ogni autorizzazione ricevuta da un agente deve essere concessa direttamente, tramite appRoleAssignment, oauth2PermissionGrant, l'appartenenza a gruppi o l'assegnazione a un ruolo della directory, il che non rientra nel ciclo di controllo della gestione delle autorizzazioni. Le concessioni dirette non hanno scadenza predefinita, nessun ciclo di approvazione e nessuna pianificazione delle verifiche di accesso. Senza un workflow del ciclo di vita che includa attività relative allo sponsor dell'agente, la relazione con lo sponsor resta un record di directory statico, senza alcuna automazione quando uno sponsor cambia ruolo o lascia l'organizzazione. Un attore di minaccia che compromette un agente non governativo, tramite il furto di credenziali, la compromissione del progetto o una richiesta di pacchetto di accesso dannoso che non esiste alcuna pipeline di governance per intercettare, opera su un'identità le cui autorizzazioni non sono mai state esaminate. Questo controllo verifica anche che almeno un criterio di assegnazione dei pacchetti di accesso si applichi a tutte le identità agente della directory.

Azione di correzione

Le identità degli agenti e le entità di progetto hanno assegnato proprietari tecnici e non rimangono agenti disabilitati nella directory

Microsoft Entra Agent ID ha introdotto due tipi di identità: identità dell'agente e entità servizio blueprint dell'identità dell'agente. Questi oggetti di identità derivano da entità servizio e quindi presentano gli stessi requisiti e le stesse procedure consigliate relative alla proprietà, alla gestione del ciclo di vita e alla pulizia, come qualsiasi entità servizio. Le entità di sicurezza del modello costituiscono l'interfaccia di provisioning da cui vengono create le identità degli agenti e possono contenere autorizzazioni che si propagano agli agenti figli. La presenza di un proprietario designato per questi oggetti consente di eseguire due importanti aree di gestione delle identità degli agenti:

  • I rischi sono contenuti e indagati da una parte responsabile
  • Gli oggetti disabilitati non introducono privilegi inattivi

La relazione dei proprietari in ogni oggetto identità agente designa gli utenti umani responsabili delle operazioni tecniche e della risposta agli eventi imprevisti, distinti dalla relazione tra sponsor che supporta la responsabilità aziendale per le decisioni relative al ciclo di vita e all'accesso. Pertanto, quando ID Protection contrassegna l'identità di un agente come rischiosa o emergono modelli anomali di accesso alle risorse, il team delle operazioni di sicurezza può inoltrare il caso a un responsabile per il contenimento e l'indagine. Se non è stato designato alcun proprietario, un attore di minaccia che compromette un agente o un'entità di progetto senza proprietario (tramite furto di credenziali, sfruttamento del progetto o consenso delegato dannoso) opera su un'entità senza alcun essere umano designato per il contenimento immediato. Questo problema può estendere il tempo di attesa da minuti al successivo ciclo di controllo della directory manuale.

Quando un’identità agente o il relativo modello viene disabilitato, non può ottenere nuovi token e quindi non può accedere alle risorse. L'oggetto esiste ancora nella directory, quindi le assegnazioni di ruolo dell'app, le appartenenze ai gruppi e le concessioni di autorizzazione OAuth2 vengono mantenute. Se un errore amministrativo o un attore malevolo con accesso in scrittura alla directory riattiva l'oggetto, tutte le autorizzazioni vengono ripristinate senza necessità di una nuova approvazione. Se un principal del blueprint disabilitato viene riattivato, viene anche ripristinata l'interfaccia di provisioning per le identità di tutti gli agenti figlio. La combinazione di oggetti senza proprietario e oggetti disabilitati non aggiornati crea un modello di accumulo di privilegi permanenti che la proprietà e la pulizia appropriate sono progettate per evitare.

Azione di correzione

I ruoli amministrativi di IA hanno identità assegnate

La superficie del piano di controllo di intelligenza artificiale include Microsoft 365, Microsoft Power Platform, Microsoft SharePoint e ogni livello dello stack di Microsoft Security. Microsoft Entra ID è il piano di controllo delle identità per questa intera superficie e gli ambiti amministrativi gestiscono le identità degli agenti, le impostazioni di amministrazione Microsoft 365 Copilot, l'accesso condizionale per l'intelligenza artificiale, gli ambienti Copilot Studio, le origini di base dell'intelligenza artificiale, i segnali di postura di intelligenza artificiale e il rilevamento e la risposta dell'intelligenza artificiale. Se non esiste un ruolo umano assegnato a un ruolo amministrativo che gestisce queste funzionalità di intelligenza artificiale, non esiste alcun operatore responsabile per tale sezione della superficie di intelligenza artificiale. Questo divario può significare:

  • Le identità dell'agente non vengono monitorate o esaminate
  • Scostamento delle impostazioni amministrative
  • I rilevamenti specifici dell'intelligenza artificiale non hanno alcun proprietario per analizzare o modificare
  • I criteri di controllo di rete per l'IA non vengono modificati man mano che l'ambiente di intelligenza artificiale si evolve
  • Le escalation relative all'IA non hanno un referente designato

Gli attori delle minacce sfruttano questo gap puntando direttamente al piano di controllo di intelligenza artificiale. Sfruttano il divario tra l'esistenza di un ruolo nella directory e il fatto che qualcuno lo controlli effettivamente. Garantire che ogni ruolo di amministratore dell'IA abbia almeno un'identità assegnata rappresenta il livello minimo di governance organizzativa per l'amministrazione dell'IA. Questo controllo valuta solo le assegnazioni di ruolo nella directory Microsoft Entra. Un ruolo visualizzato come non assegnato significa che nessuna entità di Microsoft Entra viene assegnata al ruolo della directory corrispondente, quindi gli amministratori nativi del carico di lavoro potrebbero ancora esistere al di fuori di Microsoft Entra e non sono esterni a questa valutazione. L'amministrazione dell'IA di altre piattaforme, ad esempio i gruppi di ruoli di Microsoft Purview o i ruoli personalizzati di Microsoft Defender, deve essere esaminata separatamente.

Azione di correzione

  • Last updated on