La ricerca di Unit 42 sulle identità cloud mette in luce i limiti della sicurezza basata sui permessi

Unit 42 ha analizzato oltre 40.000 identità cloud, rivelando un conflitto che le sole revisioni dei permessi non possono risolvere. La ricerca di Unit 42 sulle identità cloud sostiene che i team di sicurezza debbano comprendere ciò che un’identità fa realmente, non soltanto ciò che può fare.

Pubblicata il 14 settembre 2026, la ricerca mappa l’attività di 125 ambienti cloud nel corso di un periodo di osservazione di due mesi. Il suo modello raggruppa le identità in base alle operazioni registrate in AWS CloudTrail. Questi gruppi corrispondono a ruoli riconoscibili, inclusi amministratori, agenti di backup, strumenti di sicurezza, utenti DevOps e sistemi di continuous delivery.

Il confronto centrale è tra l’inferenza del ruolo comportamentale e le etichette statiche delle identità. Un nome affidabile, una policy nota o una credenziale legittima possono rimanere invariati dopo che un attaccante ha modificato lo scopo dell’identità. Unit 42 propone di trasformare il comportamento osservato in contesto di ruolo, per poi usare gli scostamenti da quel contesto al fine di migliorare il rilevamento automatico.

Unit 42 ha mappato le identità in base alle azioni, non ai nomi

La ricerca cambia l’analisi delle identità trattando l’attività API come prova del ruolo operativo di un’identità.

La ricerca sulle identità comportamentali parte da un problema pratico. Gli ambienti cloud oggi includono dipendenti, applicazioni, pipeline di deployment, prodotti di sicurezza e agenti autonomi. I loro nomi e i permessi assegnati spesso rivelano poco sulla loro funzione attuale.

Un’identità chiamata “backup” potrebbe legittimamente leggere ogni notte un solo bucket di storage. La stessa identità potrebbe in seguito enumerare utenti, ispezionare policy o creare risorse di calcolo. Queste azioni sarebbero rilevanti anche se il suo nome e i suoi permessi restassero invariati.

Unit 42 ha rappresentato ogni identità tramite le operazioni AWS invocate nel periodo dello studio. I ricercatori hanno poi confrontato questi profili comportamentali tra gli ambienti partecipanti. Combinazioni simili di operazioni hanno aggregato le identità in gruppi distinti.

La mappa risultante comprendeva 30 grandi cluster che rappresentavano circa 20.000 identità. I ricercatori hanno associato tali cluster a funzioni ricorrenti quali amministrazione, automazione dell’infrastruttura, networking, sicurezza, backup, FinOps e servizi dati.

Il cluster amministrativo ha fornito l’esempio più chiaro. Conteneva circa 5.000 identità distribuite in oltre 100 progetti cloud. Circa il 94 percento delle sue identità ha generato eventi ConsoleLogin, rispetto a meno dell’1 percento negli altri cluster.

Circa il 60 percento ha inoltre invocato operazioni associate alla normale attività della console, incluse GetCostAndUsage e GetCostForecast. Queste operazioni hanno contribuito a distinguere gli amministratori interattivi dalle identità macchina che utilizzano un insieme più ristretto di API.

Questa evidenza è importante perché nessun singolo evento stabilisce l’intento. ConsoleLogin indica un accesso interattivo, ma non dimostra che l’utente sia un amministratore. Le richieste di gestione dei costi potrebbero verificarsi automaticamente al caricamento della console.

Unit 42 ha combinato quattro forme di analisi per evitare di basarsi su un unico segnale conveniente. Ha esaminato la frequenza delle operazioni, le operazioni distintive, gli attributi delle identità e i modelli di denominazione ricorrenti all’interno di ciascun cluster.

Un modello di denominazione è stato particolarmente rivelatore. AWS IAM Identity Center crea un prefisso riconoscibile quando AdministratorAccess viene assegnato tramite il suo set standard di permessi. Il prefisso compariva frequentemente nel cluster amministrativo, supportando l’interpretazione comportamentale.

I nomi erano prove di supporto, non il fondamento del modello. Questa distinzione impedisce al metodo di limitarsi a riscoprire etichette già associate alle identità. Rende inoltre l’approccio più utile quando i nomi sono vaghi, obsoleti o intenzionalmente ingannevoli.

La ricerca non annuncia una violazione o una vulnerabilità appena osservata. Presenta un modello di rilevamento costruito su telemetria operativa reale. Il suo valore informativo deriva dal rendere più scalabili e spiegabili la classificazione delle identità cloud.

La maggior parte degli inventari delle identità risponde a chi possiede una credenziale e quali azioni consente la sua policy. Unit 42 aggiunge una terza domanda: quale ruolo funzionale rivela l’attività dell’identità? Questo livello aggiuntivo crea la tensione che guida l’intero studio.

I permessi statici lasciano aperta la domanda più importante

Un permesso indica ai difensori ciò che è possibile, mentre il comportamento rivela quali capacità un’identità sta esercitando ora.

Le policy di gestione delle identità e degli accessi rimangono essenziali. Determinano se un principal può leggere un segreto, avviare un’istanza, modificare il logging o assumere un altro ruolo. Il principio del privilegio minimo riduce il danno potenziale di una credenziale compromessa.

Tuttavia, l’analisi delle policy non può descrivere completamente la realtà operativa. Le organizzazioni concedono spesso accessi ampi per evitare di bloccare deployment o interventi d’emergenza. I vecchi ruoli accumulano inoltre permessi man mano che progetti, team e responsabilità cambiano.

Alcune identità con privilegi eccessivi operano innocuamente per anni. Altre diventano preziosi punti di ingresso dopo il furto delle credenziali. Il documento dei permessi appare rischioso in entrambi i casi, ma non può mostrare quale identità abbia iniziato ad agire al di fuori della propria funzione consolidata.

Il contesto comportamentale fornisce questa distinzione mancante. Un processo di backup che accede ripetutamente a una destinazione protetta crea una baseline ristretta. L’enumerazione delle risorse, la ricognizione delle identità o modifiche amministrative rappresenterebbero uno scostamento significativo da tale baseline.

La stessa chiamata API può comportare un rischio diverso in un altro contesto. ListBuckets potrebbe essere previsto per un prodotto di inventario della sicurezza. Meriterebbe maggiore attenzione se provenisse da un workload che storicamente ha scritto log applicativi in un solo bucket.

Ecco perché la ricerca di Unit 42 sulle identità cloud mette sotto pressione i programmi di sicurezza basati solo sulla postura. La gestione della postura di sicurezza cloud identifica permessi eccessivi e problemi di configurazione. Non spiega automaticamente se le azioni osservate corrispondano al vero compito dell’identità.

Gli attaccanti traggono vantaggio da questa lacuna. Possono utilizzare credenziali esistenti, policy ereditate e nomi di risorse dall’aspetto innocuo. La loro attività appare quindi sotto un’identità che i team di sicurezza già riconoscono.

Il mascheramento non richiede di cambiare il nome dell’account. A un attaccante basta eseguire operazioni dannose attraverso un’identità che i difensori considerano affidabile. Gli inventari statici possono conservare tale fiducia anche dopo che il comportamento è cambiato.

AWS applica già l’analisi comportamentale nel proprio servizio gestito di rilevamento delle minacce. Secondo la sua documentazione sul rilevamento delle anomalie, GuardDuty crea profili dei campi degli eventi CloudTrail per identificare attività anomale o non autorizzate.

GuardDuty considera inoltre fattori quali l’identità richiedente, l’API e la posizione. I suoi rilevamenti possono identificare attività associate all’accesso alle credenziali, alla ricognizione, alla persistenza, all’escalation dei privilegi, all’esfiltrazione e all’impatto.

Questa capacità esistente convalida la direzione più ampia, ma non elimina il contributo di Unit 42. I rilevamenti gestiti presentano generalmente risultati dopo che i modelli e le regole di un provider hanno identificato attività sospette. I clienti hanno una visibilità limitata sulla baseline esatta o sul processo di classificazione.

Unit 42 si concentra sull’assegnazione di un ruolo funzionale che i difensori possano comprendere e riutilizzare. Il modello chiede se un’identità si comporti come un amministratore, un sistema di deployment, uno scanner o un servizio di backup. Tale ruolo può arricchire i rilevamenti successivi.

La distinzione modifica anche il triage. Una chiamata API sconosciuta non è automaticamente dannosa, e una chiamata API comune non è automaticamente innocua. Gli analisti devono confrontare l’azione con la funzione prevista dell’identità.

Questo esercita pressione sui fornitori di sicurezza cloud, sui team interni di rilevamento e sulle piattaforme di governance delle identità. Ciascuno deve collegare i dati sulle autorizzazioni con l’attività in esecuzione. Un prodotto che espone soltanto un lato lascia agli analisti il compito di ricostruire manualmente l’altro.

La pressione aumenta con la moltiplicazione delle identità non umane. Workload, sistemi CI/CD, account di servizio, strumenti di automazione e agenti AI possono agire continuamente. Il loro volume comportamentale rende impraticabile la classificazione manuale.

La risposta di Unit 42 non consiste nello scartare i permessi. Consiste nel combinare le capacità consentite con le operazioni osservate. Le due prospettive rispondono a domande differenti e diventano più utili quando vengono valutate insieme.

Come funziona il clustering delle identità cloud di Unit 42

Unit 42 utilizza il clustering non supervisionato per scoprire ruoli comportamentali, quindi sintetizza queste scoperte in classificatori più semplici.

La prima fase parte dai log di audit cloud. AWS CloudTrail registra gli eventi generati da utenti, ruoli e servizi, inclusa l’identità e l’API coinvolte. AWS descrive questi campi nel proprio riferimento agli eventi CloudTrail.

Unit 42 converte ogni identità in un vettore booleano. Ogni posizione rappresenta un’operazione disponibile, mentre true o false registra se l’identità ha invocato tale operazione durante la finestra di osservazione.

Ciò produce un dataset complesso. Secondo la ricerca, AWS espone oltre 15.000 possibili operazioni in circa 240 servizi. La maggior parte delle identità ne invoca soltanto un piccolo sottoinsieme, creando vettori grandi e perlopiù vuoti.

La pipeline utilizza Uniform Manifold Approximation and Projection, o UMAP, per ridurre questi vettori. UMAP converte osservazioni ad alta dimensionalità in rappresentazioni più piccole, cercando al contempo di preservare una struttura di vicinato significativa.

I ricercatori hanno utilizzato la similarità del coseno come misura di distanza. Questa misura confronta la direzione di due vettori anziché la loro grandezza assoluta. Enfatizza le operazioni condivise dalle identità invece di favorire l’identità che ha generato più attività.

Un passaggio di UMAP ha creato rappresentazioni dense contenenti 32 valori continui. Un passaggio separato ha proiettato le identità in due dimensioni per la visualizzazione. Questi due output servono a scopi diversi e non dovrebbero essere trattati come intercambiabili.

La rappresentazione densa passa quindi a HDBSCAN, un metodo di clustering che identifica regioni ad alta densità di punti. A differenza degli algoritmi che richiedono un numero fisso di gruppi, HDBSCAN può scoprire cluster e contrassegnare i punti insoliti come rumore.

Entrambi i metodi hanno solide basi nella ricerca. L’originale articolo su UMAP descrive la tecnica di riduzione della dimensionalità, mentre l’articolo su HDBSCAN tratta il clustering gerarchico basato sulla densità.

Una volta che le identità ricevono assegnazioni ai cluster, gli analisti devono comunque interpretare ciascun gruppo. Un identificatore di cluster non arriva con un’etichetta che dica “amministratore” o “servizio di backup”. La ricerca applica pertanto più test per inferirne il ruolo.

La frequenza delle operazioni mostra quali API compaiono in tutto un cluster. Un metodo di punteggio basato sulle classi identifica operazioni che si verificano frequentemente all’interno di un gruppo ma rimangono poco comuni altrove. Questo separa le API semplicemente popolari dai segnali realmente distintivi.

La mappatura degli attributi aggiunge un’altra prospettiva. I ricercatori possono evidenziare identità che utilizzano servizi specifici, invocano operazioni determinate o contengono stringhe ricorrenti. Attributi concentrati forniscono evidenza a sostegno di un’etichetta funzionale proposta.

Infine, il substring mining identifica frammenti ricorrenti nei nomi delle identità. Questo può rivelare convenzioni create dai sistemi di deployment o dai prodotti di gestione delle identità. È più sicuro che dichiarare un ruolo basandosi esclusivamente sul nome di una singola identità.

Nel loro insieme, questi metodi trasformano un pattern visivo in una categoria comportamentale interpretabile. L'interpretazione resta un giudizio analitico, ma si fonda su diverse forme di evidenza.

L'approccio di clustering delle identità cloud di Unit 42 non è quindi un decodificatore magico delle identità. È una pipeline strutturata per individuare pattern operativi ricorrenti. L'analisi umana continua a collegare tali pattern a funzioni organizzative reali.

Questo limite è anche un punto di forza. I team di sicurezza possono esaminare perché a un cluster sia stata assegnata un'etichetta. Possono verificare se le operazioni distintive corrispondono al proprio ambiente prima di usare la classificazione in produzione.

Il processo ricorda la cartografia esplorativa. L'apprendimento non supervisionato traccia la mappa senza ricevere un elenco predefinito di ruoli. Gli analisti identificano poi le regioni che corrispondono a comportamenti operativi noti.

Tuttavia, rieseguire ripetutamente l'intera pipeline di mappatura introdurrebbe costi computazionali e operativi. Potrebbe inoltre produrre identificatori di cluster variabili al cambiare di dataset e parametri. Unit 42 affronta questo problema nella fase successiva.

Il Vero Passo Avanti È il Percorso Dai Modelli a SQL

Il passaggio più importante sul piano operativo consiste nel distillare i cluster individuati in regole piccole e interpretabili, eseguibili dai sistemi dati esistenti.

Dopo aver identificato un cluster utile, Unit 42 addestra un classificatore di regressione logistica sui vettori booleani delle operazioni originali. La regressione logistica calcola in che modo le singole caratteristiche modificano la probabilità che un'osservazione appartenga a una classe scelta.

Un team potrebbe addestrare un classificatore per il comportamento degli amministratori e un altro per gli strumenti di sicurezza. Le nuove identità verrebbero quindi valutate rispetto ai modelli pertinenti senza ricostruire l'intera mappa comportamentale.

Unit 42 applica inoltre la regolarizzazione L1. Questa penalità spinge verso zero i coefficienti delle caratteristiche poco utili. Le operazioni rimanenti formano un insieme molto più ridotto di indicatori positivi e negativi.

Questa sparsità è importante per le operazioni di sicurezza. Un modello con migliaia di caratteristiche interagenti sarebbe difficile da ispezionare, spiegare o riprodurre. Un classificatore basato su alcune decine di operazioni ponderate è molto più facile da rendere operativo.

Gli analisti possono vedere quali chiamate API avvicinano un'identità alla classificazione di amministratore. Possono anche vedere quali operazioni la allontanano. Questa visibilità supporta la revisione prima che la logica influisca sugli avvisi.

I ricercatori affermano che questa logica ponderata può essere espressa tramite query SQL standard. La maggior parte delle organizzazioni di sicurezza centralizza già i log cloud in data warehouse, security data lake o piattaforme di analisi. SQL riduce la barriera al deployment.

Questo non significa che l'intero flusso di lavoro di machine learning scompaia. La fase di clustering originale continua a individuare gruppi significativi e a fornire etichette di addestramento. Il classificatore leggero è un'approssimazione locale di quell'analisi precedente.

La distinzione protegge l'articolo da una conclusione fuorviante. Unit 42 non ha ridotto ogni problema di sicurezza cloud a un'istruzione SQL. Ha mostrato come un confine di classificazione appreso possa diventare una logica di query trasparente.

Questo design propone un compromesso pratico tra machine learning su misura e regole rigide scritte manualmente. I rilevamenti interamente manuali dipendono dalla capacità degli analisti di prevedere in anticipo le combinazioni rilevanti. I modelli complessi possono essere costosi e difficili da spiegare.

Il clustering comportamentale scopre pattern candidati dai dati osservati. I classificatori sparsi preservano poi i pattern selezionati in un formato ispezionabile. I team di rilevamento ottengono contesto riutilizzabile senza mantenere continuamente la pipeline esplorativa.

Si consideri l'esempio del servizio di backup. Un classificatore potrebbe riconoscere operazioni associate a normali attività di backup e assegnare un ruolo funzionale. La logica di rilevamento può quindi trattare la discovery amministrativa o le modifiche alle policy come comportamenti in conflitto con quel ruolo.

L'avviso è più solido perché descrive una discrepanza, non soltanto un evento raro. “L'identità di backup ha eseguito un comportamento da amministratore” offre a un analista più contesto di “rilevata API insolita”. Collega la baseline dell'attore all'azione sospetta.

Lo stesso approccio potrebbe supportare i sistemi CI/CD. Le identità di deployment spesso eseguono operazioni infrastrutturali ricorrenti su servizi prevedibili. L'abuso delle credenziali potrebbe introdurre attività sulla console, discovery estesa o accesso a dati non correlati.

I prodotti di sicurezza rappresentano un'altra categoria utile. Enumerano regolarmente le risorse e ispezionano la configurazione. Senza il contesto del ruolo, tali azioni possono assomigliare alla ricognizione di un attaccante e generare rumore evitabile.

La classificazione funzionale può quindi ridurre due diversi errori. Può abbassare i falsi positivi quando un accesso ampio corrisponde a uno scanner noto. Può aumentare il sospetto quando un'automazione a scopo ristretto inizia a comportarsi come un amministratore.

È qui che l'inferenza del ruolo comportamentale compete più direttamente con l'etichettatura statica. Un nome come “security-scanner” chiede agli analisti di fidarsi della configurazione. Un pattern osservato fornisce loro evidenza che l'identità continua a svolgere quella funzione.

Il metodo integra anche l'analisi delle autorizzazioni. Uno scanner di sicurezza potrebbe comportarsi normalmente pur mantenendo privilegi eccessivi. Gli strumenti di posture management dovrebbero comunque segnalare questa esposizione, anche quando i rilevamenti a runtime non individuano nulla di sospetto.

Al contrario, un'identità con autorizzazioni strettamente limitate può comunque comportarsi in modo inatteso entro l'ambito consentito. Il monitoraggio comportamentale dovrebbe segnalare tale cambiamento, anche quando una revisione delle policy non riscontra violazioni.

Il modello crea quindi un ulteriore livello dati anziché un controllo sostitutivo. Le autorizzazioni definiscono i confini. Il clustering deduce i ruoli. La logica di rilevamento identifica gli scostamenti che meritano indagine.

Unit 42 afferma che la metodologia può estendersi oltre AWS CloudTrail ad altri cloud provider, Kubernetes e servizi software. L'estensione è plausibile perché anche questi sistemi producono eventi di audit collegati alle identità.

Tuttavia, la portabilità richiede una nuova validazione. Azure, Google Cloud, Kubernetes e le piattaforme SaaS espongono vocabolari di eventi e strutture delle identità differenti. Un classificatore addestrato sulle operazioni AWS non può semplicemente essere trasferito senza modifiche.

Cosa la Ricerca Non Dimostra Ancora

Il dataset dimostra cluster comportamentali coerenti, ma non stabilisce un'accuratezza di rilevamento universale tra organizzazioni, provider o carichi di lavoro in evoluzione.

Unit 42 riporta una scala significativa, con oltre 40.000 identità e 125 ambienti. Questa ampiezza supporta l'affermazione che ruoli comportamentali ricorrenti compaiono in molteplici infrastrutture cloud. Non risponde però a tutte le domande relative alla produzione.

La pubblicazione non fornisce un benchmark completo con precision, recall, tassi di falsi positivi e prestazioni per tutti i ruoli identificati. Afferma che la regressione logistica può identificare accuratamente cluster selezionati, ma i lettori pubblici non possono riprodurre in modo indipendente ogni risultato.

Lo studio si concentra inoltre su una finestra di osservazione di due mesi. Questo periodo cattura operazioni ricorrenti, ma alcune identità legittime agiscono soltanto durante test trimestrali di ripristino, migrazioni o risposta agli incidenti. Baseline brevi possono classificare erroneamente attività rare ma autorizzate.

I vettori booleani introducono un ulteriore compromesso. Conservano l'informazione sull'avvenimento di un'operazione, ma omettono la frequenza con cui si è verificata. Un'identità che chiama un'API una volta appare identica, per quella caratteristica, a una che la chiama migliaia di volte.

Questa semplificazione aiuta a controllare la dimensionalità e favorisce l'interpretabilità. Può anche eliminare segnali di volume che distinguono il lavoro ordinario dall'abuso. Frequenza, tempistica, geografia, parametri delle richieste e destinazioni delle risorse possono tutti essere rilevanti durante un'indagine.

Il concept drift presenta un ulteriore problema. Il comportamento funzionale cambia quando i team adottano nuovi servizi, modificano pipeline o migrano architetture. Un classificatore addestrato sulle operazioni di ieri può trattare come sospette modifiche legittime al deployment.

Anche gli attaccanti possono adattarsi. Se comprendono il ruolo comportamentale atteso, possono scegliere operazioni che somigliano alla sua normale attività. La classificazione comportamentale aumenta il costo della simulazione, ma non elimina l'evasione.

L'approccio dipende da telemetria affidabile. Copertura CloudTrail mancante, logging disabilitato, conservazione incoerente o raccolta cross-account incompleta distorceranno i vettori delle identità. Un modello pulito non può recuperare eventi che non sono mai stati registrati.

Anche i confini delle identità possono diventare ambigui. Ruoli assunti, sessioni federate, credenziali dei workload e percorsi di automazione condivisi potrebbero far confluire più attori in un unico principal apparente. L'inferenza dei ruoli è precisa solo quanto gli identificatori nei log sorgente.

I dati cross-organizzazione aggiungono un'altra incertezza. Il comportamento condiviso può rivelare pattern di settore stabili, ma ogni azienda configura gli account in modo diverso. Operazioni fortemente associate agli amministratori in un'infrastruttura potrebbero verificarsi automaticamente altrove.

Il cluster amministrativo illustra questo rischio. ConsoleLogin è altamente distintivo nel dataset riportato. Tuttavia, richieste automatiche alla console, architetture di accesso federato e modifiche all'interfaccia del provider possono alterare le operazioni che accompagnano una sessione interattiva.

Persino l'espressione “ruolo funzionale” può implicare più certezza di quanta l'evidenza supporti. Un cluster descrive una somiglianza comportamentale durante un periodo di osservazione. Non prova proprietà organizzativa, autorizzazione o finalità aziendale.

I team di sicurezza dovrebbero pertanto trattare i ruoli assegnati come metadati contestuali. Dovrebbero combinarli con dati sulle autorizzazioni, ambito delle risorse, indicatori di rete, segnali di autenticazione e threat intelligence. Nessuna singola dimensione stabilisce l'intento malevolo.

Anche il contesto commerciale merita attenzione. Unit 42 è l'organizzazione di threat research di Palo Alto Networks e la pubblicazione collega la metodologia a Cortex Cloud e a prodotti correlati. Le sue conclusioni tecniche restano preziose, ma le affermazioni sui prodotti richiedono una validazione da parte dei clienti.

Le organizzazioni dovrebbero chiedersi se le classificazioni restano stabili tra account e nel tempo. Dovrebbero misurare la qualità degli avvisi prima di consentire che le discrepanze di ruolo attivino il contenimento automatico. Una risposta errata potrebbe interrompere backup, deployment o monitoraggio della sicurezza.

La valutazione in dry run offre un percorso di adozione più sicuro. I team possono calcolare i ruoli dedotti, confrontarli con la proprietà nota degli asset e osservare gli scostamenti senza modificare l'accesso in produzione. Gli analisti possono poi affinare soglie ed eccezioni.

Il test migliore non è stabilire se la visualizzazione appaia convincente. È verificare se il contesto del ruolo riduce i tempi delle indagini preservando rilevamenti significativi. Questo risultato richiede evidenze operative oltre la pubblicazione della ricerca.

Tre Segnali Mostreranno se il Rilevamento dell'Identità Comportamentale Regge

Il prossimo test consiste nel verificare se l'inferenza dei ruoli comportamentali resti accurata, portabile e utile dopo aver lasciato l'ambiente di ricerca.

Il primo segnale è una performance di rilevamento misurabile. Unit 42 o i clienti devono pubblicare risultati di precision, recall e falsi positivi per diversi ruoli. La sola classificazione degli amministratori non può stabilire le prestazioni per agenti di backup, sistemi di deployment o agenti autonomi.

I risultati dovrebbero includere ambienti non osservati, anziché identità campionate dalla stessa popolazione organizzativa. Prestazioni solide in infrastrutture esterne supporterebbero l'affermazione che i pattern funzionali si generalizzano. Calo marcati rivelerebbero ipotesi specifiche dell'ambiente.

Il secondo segnale è la validazione cross-platform. I ricercatori affermano che la metodologia può estendersi a Kubernetes, applicazioni SaaS e altri cloud provider. Un'implementazione documentata al di fuori di AWS metterebbe alla prova questa affermazione.

La portabilità dovrebbe significare più che elaborare un diverso formato di log. Il metodo deve individuare ruoli riconoscibili, produrre classificatori stabili e migliorare le decisioni reali di rilevamento. Altrimenti, le convenzioni delle API AWS potrebbero svolgere più lavoro del framework generale.

Il terzo segnale è l'adozione operativa attraverso flussi di rilevamento trasparenti. I team di sicurezza dovrebbero cercare integrazioni che espongano, all'interno di un avviso, il ruolo inferito, le operazioni che contribuiscono, il livello di confidenza e i comportamenti in conflitto.

Un semplice punteggio di rischio nasconderebbe il principale vantaggio della ricerca. Il valore deriva dalla spiegazione che una nota identità di backup ha iniziato a comportarsi come un amministratore. Gli analisti hanno bisogno di questa relazione per valutare l'urgenza e scegliere una risposta.

Le implementazioni più solide terranno traccia anche dei cambiamenti di ruolo nel tempo. Un account di deployment può legittimamente espandersi a nuovi servizi. I sistemi necessitano di programmi di riaddestramento, monitoraggio della deriva, classificatori versionati e processi di revisione per i comportamenti modificati.

I team dovrebbero evitare di trattare ogni discrepanza come un incidente. Alcune deviazioni rifletteranno manutenzione, migrazioni o nuovi rilasci di prodotto. Il segnale di ruolo dovrebbe dare priorità alle indagini, mentre altre evidenze stabiliscono se il contenimento sia giustificato.

Anche le identità umane e quelle macchina dovrebbero essere valutate separatamente. Amministratori interattivi, servizi pianificati e agenti autonomi generano attività a velocità diverse. Potrebbero richiedere finestre di osservazione e soglie differenti.

Gli agenti autonomi rendono questa questione particolarmente urgente. Un agente potrebbe eseguire sequenze variabili su molti servizi perseguendo un singolo obiettivo approvato. Le etichette statiche dei job descriveranno male questo comportamento.

Tuttavia, il comportamento variabile rende anche più difficile il clustering. Lo spazio di azione legittimo di un agente può sovrapporsi a ricognizione, modifiche di configurazione e accesso ai dati. I difensori avranno bisogno di contesto su obiettivi, approvazioni, risorse e cronologie di esecuzione.

La proposta di Unit 42 sulle identità cloud fornisce una parte di questo contesto. Crea una descrizione empirica di come un'identità si comporta tra i suoi pari. Non determina se l'obiettivo sottostante fosse autorizzato.

Per gli sviluppatori, la domanda immediata è se le identità di deployment e di servizio presentino modelli chiari e osservabili. I team dovrebbero verificare se gli eventi di audit possano essere collegati in modo coerente tra ruoli assunti e sessioni di automazione.

Gli acquirenti enterprise dovrebbero chiedere ai fornitori come vengono inferiti i ruoli funzionali. Dovrebbero inoltre richiedere evidenze che spieghino quali eventi guidano ciascuna classificazione. Il rilevamento delle anomalie “basato sull'AI” non è un'informazione sufficiente per una decisione di sicurezza ad alto impatto.

I responsabili della sicurezza dovrebbero confrontare i risultati comportamentali con le revisioni degli accessi. Un'identità che appare operativamente circoscritta ma mantiene autorizzazioni ampie rappresenta un'esposizione prevenibile. Un'identità che cambia improvvisamente ruolo rappresenta una potenziale minaccia attiva.

I knowledge worker e gli utenti di prodotti AI hanno un interesse correlato. Le applicazioni aziendali collegano sempre più spesso assistenti e agenti ai dati aziendali. Ogni connessione crea un'identità il cui comportamento effettivo può estendersi oltre una semplice etichetta utente.

I prossimi uno-tre mesi dovrebbero chiarire se Palo Alto Networks pubblicherà ulteriori validazioni, amplierà la copertura dei ruoli o esporrà più direttamente la logica nei flussi di lavoro dei clienti. Test indipendenti rafforzerebbero ulteriormente il caso.

I lettori dovrebbero seguire tre domande concrete: i classificatori funzionano su ambienti non visti, si trasferiscono oltre AWS e migliorano le decisioni degli analisti? Le risposte determineranno se le mappe comportamentali delle identità diventeranno un contesto di sicurezza ordinario.

Il giudizio centrale dello studio resta valido: i documenti sulle autorizzazioni sono necessari, ma non costituiscono un resoconto completo del rischio d'identità. I difensori necessitano anche di evidenze su ciò che credenziali, workload e agenti fanno realmente.

Esaminate il vostro inventario cloud attraverso questa lente. Quali identità dispongono di nomi e autorizzazioni, ma non di un ruolo comportamentale verificato? Le lacune nella risposta individuano dove la ricerca di Unit 42 sulle identità cloud conta maggiormente.