Identità non umane: proteggere segreti, token e service account

Identità non umane (NHI, Non-Human Identities) è il termine con cui la sicurezza informatica indica oggi una delle superfici d’attacco in più rapida crescita: gli account macchina, le chiavi e i segreti che permettono a software, servizi e automazioni di autenticarsi e operare senza un essere umano alla tastiera. Per anni la sicurezza delle identità si è concentrata sulle persone, con password, autenticazione a più fattori e gestione degli accessi; nel frattempo, però, il numero delle identità non umane è cresciuto a dismisura, spesso senza controllo, diventando il punto debole da cui passano sempre più violazioni.

Che cosa sono le identità non umane

Con identità non umane si intende l’insieme delle credenziali e degli account associati non a persone ma a entità tecniche: i service account che fanno girare i processi, le chiavi API che collegano due applicazioni, i token OAuth che autorizzano l’accesso a un servizio cloud, i certificati che identificano un server, i secret che proteggono le connessioni ai database, fino alle identità dei carichi di lavoro (workload) in container e funzioni serverless. A questi si aggiungono, nell’ultimo anno, le identità assegnate agli agenti di intelligenza artificiale, che agiscono in autonomia con strumenti e permessi propri.

La differenza con le identità umane non è solo numerica. Un dipendente viene assunto e cessa con processi noti, ha un volto, cambia la password, supera una verifica MFA (Multi-Factor Authentication, autenticazione a più fattori). Una identità macchina, invece, nasce spesso in modo informale durante lo sviluppo, riceve permessi ampi per comodità, non ha un proprietario chiaro e tende a sopravvivere a lungo, anche quando il progetto che l’ha creata è stato dismesso. È un’identità silenziosa, che nessuno spegne.

Perché sono esplose e quanto pesano

La spinta è arrivata dalla combinazione di cloud, microservizi, automazione e DevOps: ogni integrazione, ogni pipeline CI/CD, ogni connettore aggiunge nuove credenziali macchina. Le stime sul rapporto tra identità non umane e identità umane variano molto a seconda della metodologia, ed è bene presentarle come ordini di grandezza più che come numeri esatti: secondo la ricerca di Orca Security il rapporto medio è di circa 50 a 1, mentre il report di Entro Labs per la prima metà del 2025 lo colloca a 144 a 1, in crescita dai 92 a 1 dell’anno precedente; in organizzazioni fortemente automatizzate si arriva a citare punte di 500 a 1. Al di là della cifra specifica, il messaggio è univoco: le macchine che si autenticano sono ormai molte decine di volte più numerose delle persone, e crescono ogni anno a doppia cifra.

L’arrivo dell’intelligenza artificiale generativa ha accelerato ulteriormente il fenomeno, moltiplicando integrazioni e chiamate tra servizi. Questo cambia la scala del problema: difendere qualche migliaio di account umani è un conto, governare centinaia di migliaia di credenziali macchina effimere è un’altra disciplina.

I rischi principali: l’OWASP NHI Top 10

Per dare ordine a questo dominio, nel 2025 OWASP (Open Worldwide Application Security Project) ha pubblicato la Non-Human Identities Top 10, una classifica dei rischi più critici legati alle identità macchina. Al primo e al secondo posto figurano l’improper offboarding, cioè la mancata disattivazione delle credenziali quando un servizio o un dipendente che le aveva create non c’è più, e il secret leakage, la fuga di segreti hardcoded nel codice o nei file di configurazione. Più in basso nella classifica compaiono altri problemi molto concreti da tenere d’occhio: le identità con privilegi eccessivi (overprivileged NHI, al quinto posto), che violano il principio del minimo privilegio, e i long-lived secrets (al settimo), le credenziali a vita lunga che non vengono mai ruotate e restano valide per anni.

Sono esattamente le caratteristiche che rendono le identità non umane appetibili per un attaccante: una chiave API dimenticata in un repository, con permessi ampi e senza scadenza, è un passe-partout silenzioso che non fa scattare i controlli pensati per gli utenti umani, come la verifica MFA o l’analisi dei comportamenti di login anomali.

Non è teoria. Nell’agosto 2025 l’incidente noto come Salesloft-Drift lo ha mostrato su larga scala: sfruttando token OAuth sottratti al connettore tra Drift e Salesforce, gli attaccanti (tracciati come UNC6395) hanno avuto accesso ai dati di oltre 700 organizzazioni, tra cui nomi noti della stessa industria della sicurezza, scavalcando l’autenticazione a più fattori per la semplice ragione che un token valido non la richiede. È il ritratto perfetto del rischio legato alle identità non umane: nessuna password rubata, nessun login sospetto, solo una credenziale macchina legittima finita nelle mani sbagliate.

La classifica OWASP non si ferma ai segreti: comprende anche l’autenticazione debole o assente tra servizi, le identità di terze parti introdotte da integrazioni e plugin esterni (un fornitore compromesso può diventare la porta d’ingresso verso i sistemi del cliente) e, nella voce dedicata all’uso umano delle NHI (Human Use of NHI), la scarsa tracciabilità e responsabilità delle azioni compiute tramite un’identità macchina, che rende difficile ricostruire cosa sia accaduto dopo un incidente. Letta nel suo insieme, la lista descrive un dominio in cui mancano proprio le pratiche di igiene che diamo per scontate sul versante umano: scadenze, revisioni periodiche, registri degli accessi.

Il problema dei segreti: i numeri del 2026

La dimensione della fuga di segreti è fotografata dal report annuale State of Secrets Sprawl 2026 di GitGuardian, che ha rilevato 29 milioni di nuovi segreti hardcoded scoperti nel 2025, il 34% in più rispetto all’anno precedente e il più grande salto annuale mai registrato. Particolarmente preoccupante la dinamica legata all’AI: i segreti esposti collegati a servizi di intelligenza artificiale sono cresciuti dell’81% in un anno.

Ma il dato più istruttivo riguarda la rimozione: secondo lo stesso report, il 64% dei segreti validi individuati già nel 2022 non era ancora stato revocato nel 2026, spesso per mancanza di processi di remediation ripetibili. In altre parole, il problema non è solo che i segreti trapelano, ma che restano attivi a lungo dopo essere trapelati. A complicare il quadro, una quota rilevante degli incidenti, intorno al 28%, ha origine non nei repository di codice ma negli strumenti di collaborazione e produttività, dove le credenziali finiscono esposte a un pubblico più ampio e, sempre più spesso, agli stessi agenti automatici.

Un punto cieco: proprietà e ciclo di vita

Il vero ostacolo, prima ancora che tecnico, è organizzativo. A differenza di un dipendente, una identità non umana raramente ha un proprietario formale: viene creata da uno sviluppatore per far funzionare un’integrazione e poi dimenticata, senza che nessuno si assuma la responsabilità di rivederne i permessi o di disattivarla. Quando il team cambia o il progetto chiude, la credenziale resta attiva in un limbo, fuori da ogni inventario. È questo vuoto di governo che trasforma un dettaglio tecnico in un rischio sistemico: i controlli pensati per le persone, dalle revisioni periodiche degli accessi alle procedure di uscita, non sono mai stati estesi alle macchine. Colmarlo significa assegnare a ogni identità non umana un responsabile umano e un ciclo di vita definito, dalla creazione alla revoca.

Come proteggere le identità non umane

La difesa parte da un principio che vale per ogni risorsa: non si protegge ciò che non si conosce. Il primo passo è quindi la scoperta e l’inventario delle identità non umane esistenti, con il loro proprietario, i permessi e l’ultima volta che sono state usate. Su questa base si innestano le misure operative: centralizzare i segreti in un secret manager dedicato anziché lasciarli nel codice; ruotare regolarmente le credenziali ed eliminare quelle a vita lunga; applicare il minimo privilegio, restringendo i permessi allo stretto necessario; gestire l’intero ciclo di vita, con una disattivazione affidabile quando l’identità non serve più.

La direzione tecnologica più matura è la sostituzione delle chiavi statiche con credenziali effimere e con la federazione delle identità dei workload, in modo che un servizio ottenga un token a brevissima durata al momento del bisogno invece di custodire una chiave permanente. È un approccio coerente con la logica Zero Trust, in cui nessuna identità, umana o macchina, è considerata affidabile per definizione. Infine serve il monitoraggio: rilevare l’uso anomalo di un token o di un service account è spesso l’unico modo per accorgersi di una compromissione che non lascia le tracce tipiche di un attacco a un account umano. A supporto di questo disegno stanno emergendo strumenti dedicati alla gestione e al rilevamento delle identità macchina, che estendono ai service account e ai token le logiche di Privileged Access Management (PAM, gestione degli accessi privilegiati) finora riservate agli amministratori umani, e che correlano l’attività delle credenziali tra cloud e applicazioni diverse per far emergere gli usi sospetti.

Vale la pena ricordare che il rafforzamento dell’identità umana, con tecnologie come le passkey in azienda, non riduce questa esposizione: anzi, man mano che gli accessi umani diventano più solidi, gli attaccanti spostano l’attenzione proprio sull’anello più trascurato, quello delle identità non umane.

Le NHI nell’era degli agenti AI

Lo scenario è destinato a complicarsi con la diffusione degli agenti di intelligenza artificiale, che sono a tutti gli effetti identità non umane dotate di autonomia: ricevono credenziali, accedono a strumenti, prendono decisioni e ne attivano altre a catena. Ogni agente è una nuova identità da inventariare, autorizzare con il minimo privilegio e revocare quando non serve. Un segnale concreto arriva proprio dagli strumenti che collegano gli agenti ai servizi: nei file di configurazione del Model Context Protocol (MCP), lo standard emerso per connettere gli LLM a dati e applicazioni esterne, GitGuardian ha individuato 24.008 segreti unici esposti, a riprova di quanto facilmente le credenziali macchina finiscano allo scoperto quando l’automazione corre più veloce dei controlli. Le organizzazioni che oggi non hanno il controllo delle proprie credenziali macchina si troveranno, con l’AI agentica, a gestire un parco di identità ancora più vasto e dinamico, e privo di governo. Mettere ordine adesso nelle identità non umane è quindi anche il prerequisito per adottare in sicurezza la prossima ondata di automazione.

Per i responsabili della sicurezza il cambio di prospettiva è netto: l’identità non è più solo una questione di persone da autenticare, ma un perimetro fatto in larga parte di macchine, e va governata come tale. Inserire le identità non umane nell’inventario degli asset, nelle valutazioni del rischio e nei programmi di conformità, accanto agli account degli utenti, è il modo più diretto per evitare che l’anello finora invisibile diventi quello da cui parte il prossimo incidente. Non è solo buona prassi: gli obblighi di inventario degli asset e di gestione del rischio introdotti da NIS2 e, per il settore finanziario, da DORA si applicano anche a queste credenziali, che vanno quindi censite e governate alla pari delle altre risorse critiche.