Torna al Blog

Le tue macchine hanno un'identità? Perché NIS2, DORA e ISO 27001 portano verso la workload identity

·4 min lettura
Workload identity — un agente software mostra la propria identità verificabile a un controllo di governance

In ogni azienda c'è un processo per dare un'identità alle persone: badge, account, MFA, offboarding. Quasi nessuna ha lo stesso processo per le macchine — microservizi, container, script che parlano con le API e, sempre più, gli agenti AI che agiscono in autonomia. Eppure è un controllo che ISO 27001, NIS2 e DORA, applicati con coerenza, danno per scontato.

Il problema che nessuno conta

Nelle infrastrutture moderne le identità non-umane superano quelle umane di ordini di grandezza. Sono tra le principali superfici di esposizione: API key nel codice, token a vita lunga, credenziali nei file di configurazione. Una credenziale trafugata apre le porte a un attaccante che si muove "da dentro", indisturbato.

La prima domanda di un audit serio non è quale tecnologia usi. È: quante identità non-umane hai, e chi le governa? Nella maggior parte dei casi la risposta è "non lo sappiamo". Ed è già un finding.

La risposta: dare un'identità verificabile alle macchine

Il principio è semplice: ogni macchina, servizio o agente riceve un'identità verificabile crittograficamente, emessa e rinnovata in automatico, al posto di secret statici che non scadono mai. Lo standard di riferimento è SPIFFE (un progetto della CNCF): si appoggia alla PKI che probabilmente hai già — non la sostituisce, la estende alle macchine. Il punto, per chi si occupa di governance, non è la tecnologia: è il modello. Identità a vita breve, ruotate da sole, riducono la dipendenza dai secret e rendono quasi superflua la revoca, perché il certificato scade prima di poter essere usato male.

Perché è materia di compliance, non solo di architettura

Qui sta il punto per chi deve rispondere a un auditor o a un regolatore. La workload identity non è un nuovo obbligo tecnico separato: è un modo concreto di applicare anche alle identità non-umane controlli che i framework già richiedono in materia di identità, autenticazione, controllo accessi e tracciabilità.

ISO/IEC 27001:2022. Si innesta su controlli che l'organizzazione deve già presidiare — gestione del ciclo di vita delle identità (A.5.16), informazioni di autenticazione (A.5.17), controllo accessi e diritti (A.5.15 / A.5.18) — estesi alle macchine, non solo alle persone.

NIS2 (art. 21.2). Le misure minime di gestione del rischio includono controllo dell'accesso, crittografia e autenticazione forte. La workload identity è una modalità tecnica per applicarle anche alle comunicazioni tra sistemi, non solo agli accessi umani.

DORA. Per il settore finanziario, gli RTS sul rischio ICT (Reg. delegato UE 2024/1774) richiedono identity management con identificazione univoca e autenticazione di persone e sistemi, least privilege e accountability: l'identità delle macchine è la parte che spesso resta scoperta.

La frontiera: l'identità degli agenti AI

C'è un motivo per cui questo tema esplode adesso. Gli agenti AI autonomi sono, di fatto, identità non-umane che agiscono: chiamano tool, API, altri agenti. Senza un'identità verificabile è impossibile costruire accountability e audit trail di "chi ha fatto cosa" — esattamente ciò che ISO/IEC 42001 e, per i sistemi ad alto rischio, l'AI Act (obblighi di logging) si aspettano. Prima di poter dire cosa un agente è autorizzato a fare, devi poter provare chi è.

È un terreno su cui abbiamo esperienza diretta: nelle architetture agentiche che progettiamo, ogni attore software riceve un'identità verificabile a vita breve. La governance degli agenti comincia da lì.

Non è un proiettile d'argento

Va detto con onestà: dare un'identità alle macchine introduce anche nuovi rischi. Il sistema che emette le identità diventa critico — se non è disponibile blocca i rinnovi, se è compromesso può rilasciare identità fraudolente — e va protetto come un sistema di backup o un IdP. Nel linguaggio del risk management: si mitiga un insieme rilevante di rischi (secret statici, movimento laterale, mancanza di audit trail) e si governa il rischio residuo, documentandolo e accettandolo consapevolmente. Non esiste sicurezza senza rischio residuo: esiste rischio governato.

In sintesi

L'identità delle macchine non è una scelta tecnica da delegare al team infrastrutturale: è l'applicazione, alle identità non-umane, di controlli che NIS2, DORA e ISO 27001 già richiedono — e con gli agenti AI diventa la base della stessa AI governance. La domanda da portare al prossimo risk assessment è semplice: le nostre macchine — e i nostri agenti — hanno un'identità verificabile, o le stiamo ancora autenticando con secret che non scadono mai?

Fonti

Identità delle macchine e degli agenti AI: la mappiamo sui tuoi obblighi

Tomato aiuta le PMI a tradurre i requisiti di ISO 27001, NIS2 e DORA in controlli concreti su identità non-umane e governance degli agenti AI — con un occhio ai rischi residui.

Parla con noi →