Un’azienda può spendere milioni per segmentare la propria infrastruttura, introdurre autenticazione multifattore, monitorare gli endpoint e adottare sofisticati sistemi di Identity and Access Management. Poi basta un’eccezione concessa al fornitore “che non può aspettare”, una regola permanente inserita nella whitelist della posta elettronica o un account tecnico dimenticato per aprire esattamente il varco che l’intera architettura avrebbe dovuto chiudere.
È qui che oggi si gioca la partita della Zero Trust Architecture. Non più soltanto nel passaggio teorico da “fidarsi della rete interna” a “verificare ogni accesso”, ma nella capacità delle organizzazioni di mantenere quella disciplina mentre sistemi cloud, applicazioni SaaS, dipendenti, fornitori e nuovi agenti di intelligenza artificiale moltiplicano le identità che possono interagire con dati e infrastrutture aziendali.
IL PROBLEMA NON È ENTRARE NELLA RETE, MA COSA SI PUÒ FARE DOPO
Il principio fondamentale della Zero Trust è ormai consolidato. Nel modello definito dal National Institute of Standards and Technology, nessun utente, dispositivo o servizio deve ricevere fiducia implicita soltanto perché si trova all’interno della rete aziendale o appartiene formalmente all’organizzazione. Autenticazione e autorizzazione devono precedere l’accesso alla risorsa e il controllo deve concentrarsi sulle singole identità e sugli asset, non sul semplice perimetro di rete.
Il punto più interessante, però, emerge quando quel modello viene applicato alla realtà quotidiana. Le imprese non funzionano come laboratori isolati: devono condividere documenti con consulenti, consentire l’accesso ai fornitori, utilizzare decine di servizi cloud e garantire che un dirigente possa lavorare anche quando un sistema di sicurezza considera anomala la sua connessione. Ogni volta che la continuità operativa entra in conflitto con una policy di sicurezza nasce quindi la tentazione dell’eccezione.
Ed è proprio l’eccezione a diventare pericolosa quando smette di essere temporanea.
Una whitelist creata per permettere il passaggio delle email provenienti da un determinato servizio, per esempio, può trasformarsi in una forma di fiducia permanente. Se quell’infrastruttura viene compromessa, l’attaccante non deve necessariamente superare i sistemi difensivi dell’azienda: può sfruttare una relazione che l’organizzazione ha già deciso di considerare affidabile.
Il risultato è un paradosso. Più sofisticata diventa la sicurezza, maggiore diventa il valore delle poche aree nelle quali l’organizzazione continua a fidarsi automaticamente.
UNA CREDENZIALE RUBATA PUÒ ANCORA VALERE MIGLIAIA DI FILE
La centralità delle identità emerge chiaramente anche dagli incidenti più recenti. Microsoft ha documentato nel maggio 2026 l’attività del gruppo identificato come Storm-2949, che dopo aver ottenuto l’accesso ad account cloud compromessi ha utilizzato quelle identità per esplorare ambienti Microsoft 365, accedere a OneDrive e SharePoint e individuare documentazione interna relativa a VPN e procedure di accesso remoto.
In almeno uno dei casi analizzati, l’attore malevolo è riuscito a scaricare migliaia di file attraverso l’interfaccia web di OneDrive. L’obiettivo non era soltanto l’esfiltrazione: le informazioni raccolte potevano essere utilizzate per cercare ulteriori possibilità di movimento dalla compromissione dell’identità cloud verso gli endpoint e le reti interne.
Il caso mostra perché l’autenticazione, pur essendo fondamentale, non può coincidere con l’intera strategia Zero Trust. Se un aggressore riesce a presentarsi con credenziali valide, il sistema deve continuare a chiedersi se ciò che quell’identità sta facendo sia coerente con il suo comportamento, con il dispositivo utilizzato, con la posizione della connessione e soprattutto con i privilegi realmente necessari.
Da qui derivano concetti come least privilege, accesso just-in-time, microsegmentazione e continuous authentication. Il principio è semplice: anche dopo l’ingresso, l’identità non deve ottenere automaticamente tutto ciò che il suo account potrebbe teoricamente raggiungere.
La compromissione non può sempre essere evitata. È possibile però impedire che una singola compromissione diventi una compromissione dell’intera organizzazione.
LA ZERO TRUST STA DIVENTANDO UNA QUESTIONE DI IDENTITÀ, NON DI FIREWALL
Questo cambiamento è particolarmente evidente negli ambienti cloud-native. Il NIST, nella SP 800-207A dedicata alle applicazioni distribuite su più cloud, sottolinea come la logica Zero Trust stia progressivamente spostando i controlli dai tradizionali parametri di rete — indirizzi IP, subnet e perimetri — verso le identità di utenti, applicazioni e servizi.
È un passaggio decisivo.
In un’infrastruttura moderna possono comunicare tra loro centinaia di microservizi, API e workload distribuiti tra data center aziendali e diversi provider cloud. In questo scenario chiedersi semplicemente se una connessione provenga dall’interno o dall’esterno perde gran parte del suo significato.
Bisogna sapere chi o cosa sta chiedendo accesso, a quale risorsa, con quale autorizzazione e in quale contesto.
Google ha costruito proprio su questa logica l’esperienza di BeyondCorp, nata dall’adozione interna di un modello di sicurezza Zero Trust nel quale l’accesso ai servizi non dipende dalla tradizionale appartenenza alla rete aziendale. È uno dei segnali più chiari di una trasformazione ormai strutturale dell’architettura informatica enterprise.
Anche CISA ha organizzato il proprio Zero Trust Maturity Model intorno a cinque pilastri: Identity, Devices, Networks, Applications and Workloads e Data. Non esiste quindi un singolo prodotto capace di “installare” Zero Trust. È un modello progressivo di maturità che coinvolge tecnologie, procedure e governance.
L’EVOLUZIONE DELLA ZERO TRUST NELL’ERA DEGLI AGENTI AI
Il prossimo problema potrebbe rendere la gestione delle identità ancora più complessa.
Per decenni l’Identity and Access Management ha ruotato soprattutto attorno a una domanda relativamente semplice: quale persona deve poter accedere a quale sistema? L’automazione aveva già introdotto service account, API key e workload machine-to-machine, ma l’arrivo degli agenti AI autonomi cambia ulteriormente la scala del problema.
Un agente può consultare documenti, utilizzare API, interagire con software aziendali e completare sequenze di operazioni per conto dell’utente. Per svolgere queste attività deve però possedere qualche forma di identità digitale e, soprattutto, determinati privilegi.
Qui nasce una nuova categoria di rischio.
Se un dipendente lascia l’azienda, il suo account viene normalmente disattivato attraverso i processi HR e IAM. Ma cosa accade agli agenti creati da quel dipendente? Alle API key generate per le sue automazioni? Alle credenziali memorizzate nei workflow? Ai bot collegati a piattaforme esterne?
Senza un inventario preciso delle identità non umane, le organizzazioni rischiano di creare una popolazione crescente di identità orfane: account tecnicamente legittimi che continuano a operare anche quando nessuno ne controlla più realmente la necessità.
In una logica Zero Trust questo significa estendere il principio “never trust, always verify” anche alle macchine. L’identità digitale di un agente dovrà avere privilegi delimitati, durata controllata, tracciabilità delle operazioni e possibilità di revoca immediata.
IN EUROPA LA ZERO TRUST STA ENTRANDO ANCHE NELLA COMPLIANCE
Non esiste, nel diritto europeo, un obbligo generale che imponga a ogni impresa di adottare formalmente una “Zero Trust Architecture”. Ma i principi sui quali essa si fonda stanno progressivamente entrando nel diritto della cybersecurity.
La Direttiva NIS2 richiede alle entità essenziali e importanti interessate dalla normativa di adottare misure tecniche, operative e organizzative adeguate e proporzionate al rischio. L’articolo 21 comprende, tra le altre cose, sicurezza della supply chain, gestione delle vulnerabilità, politiche di controllo degli accessi, asset management e, quando appropriato, autenticazione multifattore o sistemi di autenticazione continua.
Il collegamento è diventato ancora più esplicito nel Regolamento di esecuzione UE 2024/2690, applicabile alle categorie di operatori individuate dalla disciplina europea. Nel testo, i principi Zero Trust vengono espressamente indicati tra le possibili pratiche di cyber hygiene insieme a segmentazione della rete, gestione delle identità, configurazione sicura dei dispositivi e aggiornamenti software.
ENISA ha poi pubblicato nel giugno 2025 linee guida tecniche per aiutare le organizzazioni interessate a tradurre questi requisiti in misure concretamente implementabili.
Per gli operatori finanziari il quadro è ancora più dettagliato. DORA, applicabile dal 2025, impone alle entità finanziarie controlli continui sui sistemi ICT e un articolato governo del rischio tecnologico. Le norme tecniche collegate richiamano esplicitamente criteri come need-to-know, need-to-use e least privilege nella gestione dei diritti di accesso.
In altre parole, Zero Trust non è soltanto una scelta architetturale. I suoi principi stanno diventando parte della lingua attraverso cui il regolatore europeo definisce una sicurezza informatica considerata adeguata.
IL RISCHIO PIÙ GRANDE È TRASFORMARE ZERO TRUST IN UNO SLOGAN
La debolezza principale del modello emerge quando le imprese confondono l’acquisto di tecnologie Zero Trust con l’adozione di una vera strategia Zero Trust.
Un’organizzazione può implementare MFA, Endpoint Detection and Response, microsegmentazione e sistemi IAM avanzati e continuare comunque ad avere privilegi amministrativi permanenti, account condivisi, eccezioni non documentate o applicazioni legacy alle quali è consentito comunicare senza controlli adeguati.
È per questo che il NIST ha recentemente trasformato la teoria in esempi operativi. Il National Cybersecurity Center of Excellence ha lavorato con 24 organizzazioni private realizzando 19 implementazioni Zero Trust, con l’obiettivo di dimostrare come combinare concretamente tecnologie commerciali diverse in scenari enterprise.
Il vero vantaggio della Zero Trust non consiste quindi nell’eliminare completamente la possibilità di un attacco. Un obiettivo simile sarebbe irrealistico.
Consiste nel ridurre ciò che accade dopo che qualcosa è andato storto.
Se una password viene sottratta, quell’identità dovrebbe raggiungere soltanto un numero limitato di risorse. Se un dispositivo viene compromesso, non dovrebbe poter attraversare liberamente la rete. Se un agente AI viene manipolato, dovrebbe avere privilegi sufficientemente circoscritti da impedire che un singolo errore si trasformi in un incidente sistemico.
Ed è probabilmente questo il punto più importante della nuova cybersecurity: la sicurezza non dipende più soltanto da quanto è difficile entrare in un sistema, ma da quanto poco può fare chi riesce comunque a entrarci.
La Zero Trust nasce dall’idea di non fidarsi automaticamente di nessuno. La sua evoluzione sta mostrando qualcosa di ancora più complesso: anche la fiducia concessa legittimamente deve avere una durata, un perimetro e una ragione precisa.
A cura degli studenti sotto la Facoltà di Giurisprudenza e Ingegneria Informatica
NOTE E RIFERIMENTI
• NIST – Zero Trust Architecture, SP 800-207
Definizione e principi fondamentali della Zero Trust Architecture. NIST SP 800-207
• NIST – Implementing a Zero Trust Architecture
Guida pratica del NCCoE con 19 implementazioni realizzate insieme a 24 partner tecnologici. NIST NCCoE Zero Trust Guide
• CISA – Zero Trust Maturity Model Version 2.0
Il modello statunitense basato sui cinque pilastri Identity, Devices, Networks, Applications and Workloads e Data. CISA Zero Trust Maturity Model
• ENISA – NIS2 Technical Implementation Guidance
Indicazioni tecniche europee per l’attuazione delle misure di cybersecurity previste dal quadro NIS2. ENISA Technical Implementation Guidance
• Unione Europea – Regolamento di esecuzione (UE) 2024/2690
Il testo richiama espressamente i principi Zero Trust tra le pratiche utilizzabili nell’ambito della cyber hygiene. EUR-Lex – Regolamento 2024/2690
• Microsoft Security – Storm-2949
Analisi del caso in cui identità cloud compromesse sono state utilizzate per accedere ed esfiltrare dati da Microsoft 365 e cercare possibilità di movimento laterale. Microsoft Security – Storm-2949
