Zero Trust Architecture

Executive summary

Quando un'organizzazione collega sistemi, utenti e dispositivi attraverso reti distribuite, il presupposto tradizionale secondo cui tutto ciò che si trova "all'interno" della rete aziendale sia automaticamente sicuro diventa una vulnerabilità strutturale. Questo articolo analizza il paradigma architetturale che ribalta tale presupposto, imponendo la verifica esplicita di ogni richiesta di accesso indipendentemente dalla posizione di chi la effettua. L'analisi esamina i documenti di riferimento che hanno formalizzato questo approccio, i componenti necessari per implementarlo, dal sistema che decide se concedere o negare ogni singolo accesso alla suddivisione della rete in zone isolate sempre più piccole, e le sfide concrete che le organizzazioni affrontano nella transizione. Dall'indagine emerge che l'efficacia di questo modello dipende dalla capacità di far funzionare insieme, in modo coerente, il riconoscimento di chi richiede l'accesso, la valutazione del contesto in cui avviene la richiesta e le regole che governano i permessi, su tutti i livelli dell'infrastruttura. Le maggiori difficoltà risiedono non nella tecnologia in sé, ma nell'integrazione con sistemi preesistenti e nella gestione della crescente complessità delle regole di accesso.

Background

Il concetto di Zero Trust Architecture (ZTA) rappresenta un cambiamento paradigmatico nella sicurezza informatica: il passaggio da un modello in cui la posizione di rete determina il livello di fiducia a un modello in cui la fiducia non viene mai presupposta e ogni accesso richiede verifica esplicita. La genesi di questo paradigma è tracciabile a una critica specifica del modello perimetrale, formulata nel 2010 da John Kindervag, analista di Forrester Research, il quale coniò il termine "zero trust" per descrivere un'architettura in cui la fiducia implicita basata sulla topologia di rete viene completamente eliminata [1]. Kindervag identificò il difetto strutturale del modello tradizionale nel presupposto che il traffico interno alla rete aziendale fosse intrinsecamente sicuro, un'assunzione che, una volta violato il perimetro, concedeva agli attaccanti libertà di movimento laterale pressoché illimitata.

L'intuizione di Kindervag trovò una validazione operativa su scala globale nel progetto BeyondCorp di Google, avviato internamente dopo l'attacco Operation Aurora del 2009 e descritto pubblicamente a partire dal 2014 [2]. BeyondCorp eliminò la distinzione tra rete interna ed esterna per l'intera infrastruttura aziendale di Google, spostando i controlli di accesso dal perimetro di rete ai singoli dispositivi e utenti. Ogni richiesta di accesso a una risorsa aziendale veniva valutata sulla base dell'identità dell'utente, dello stato di sicurezza del dispositivo e del contesto della richiesta, indipendentemente dal fatto che l'utente si trovasse fisicamente in un ufficio Google o in una rete pubblica. La serie di pubblicazioni su USENIX ;login:, dall'articolo iniziale di Ward e Beyer [2] alle descrizioni dell'implementazione di Osborn et al. [3], documentò la migrazione di un'organizzazione con oltre 100.000 dipendenti verso un modello completamente privo di VPN e di fiducia implicita nella rete.

La formalizzazione istituzionale del paradigma avvenne nel 2020 con la pubblicazione del NIST Special Publication 800-207, redatto da Rose et al. [4]. Questo documento stabilì una definizione di riferimento, un modello architetturale con componenti logici espliciti e una tassonomia dei modelli di deployment. La SP 800-207 definisce zero trust come "un insieme in evoluzione di paradigmi di cybersecurity che spostano le difese da perimetri statici basati sulla rete a una focalizzazione su utenti, asset e risorse" [4]. L'importanza normativa del documento crebbe ulteriormente nel maggio 2021, quando l'Executive Order 14028 del Presidente degli Stati Uniti impose a tutte le agenzie federali di sviluppare piani di implementazione per architetture zero trust [5], seguito nel gennaio 2022 dal memorandum M-22-09 che stabilì obiettivi specifici da raggiungere entro la fine dell'anno fiscale 2024 [6].

La convergenza tra ricerca accademica, implementazione industriale e mandato normativo ha trasformato zero trust da concetto architetturale a framework operativo. Una systematic literature review pubblicata nel 2025 sul Journal of Network and Systems Management, che ha analizzato un decennio di pubblicazioni (2016–2025) utilizzando il framework PRISMA, conferma questa transizione documentando l'applicazione del paradigma in domini che spaziano dal cloud computing all'Internet of Things, dalla sanità alle infrastrutture industriali [7]. L'analisi che segue esamina i principi fondativi, i componenti architetturali e le sfide implementative che emergono da questo corpus di ricerca e pratica.

Principi fondativi e modello logico NIST

I sette princìpi del NIST SP 800-207

Il NIST SP 800-207 articola il paradigma zero trust attorno a sette princìpi (tenets) che ne definiscono i requisiti architetturali [4]. Il primo principio stabilisce che tutte le sorgenti di dati e i servizi computazionali sono considerati risorse: non solo i server e i database, ma anche i dispositivi degli utenti, i servizi SaaS e le funzioni serverless. Il secondo principio prescrive che tutte le comunicazioni siano protette indipendentemente dalla posizione di rete, il traffico interno alla rete aziendale non gode di alcun privilegio rispetto al traffico proveniente dall'esterno. Il terzo principio impone che l'accesso a ciascuna risorsa sia concesso su base individuale per singola sessione, eliminando l'accesso persistente basato su credenziali a lungo termine.

Il quarto principio introduce il concetto di accesso dinamico: l'autorizzazione è determinata da policy che considerano l'identità del richiedente, lo stato di sicurezza del dispositivo, il comportamento storico e fattori ambientali come l'orario e la geolocalizzazione. Il quinto principio richiede il monitoraggio continuo dell'integrità e della postura di sicurezza di tutti gli asset posseduti e associati all'organizzazione. Il sesto principio stabilisce che autenticazione e autorizzazione sono funzioni discrete, eseguite dinamicamente e applicate rigorosamente prima di ogni concessione di accesso. Il settimo principio impone la raccolta del maggior numero possibile di informazioni sullo stato corrente degli asset, dell'infrastruttura di rete e delle comunicazioni, per alimentare il miglioramento continuo della postura di sicurezza.

Questi princìpi non prescrivono tecnologie specifiche, ma vincoli architetturali. La distinzione è fondamentale: un'implementazione zero trust può utilizzare tecnologie eterogenee purché rispetti i vincoli strutturali definiti dai sette princìpi. Questa astrazione consente al framework di rimanere tecnologicamente agnostico e di adattarsi a infrastrutture con livelli di maturità differenti.

Componenti logici: Policy Engine, Policy Administrator, Policy Enforcement Point

Il modello architetturale del NIST identifica tre componenti logici centrali che costituiscono il nucleo decisionale di un'architettura zero trust [4]. Il Policy Engine (PE) è il componente responsabile della decisione finale di concedere o negare l'accesso a una risorsa. Il PE riceve input da molteplici fonti informative, il sistema di gestione delle identità, i log comportamentali, i sistemi di threat intelligence, i dati di compliance, e li valuta contro un insieme di policy definite dall'organizzazione. L'output del PE è una decisione binaria (concedere o negare) accompagnata da eventuali condizioni (livello di accesso, durata della sessione, restrizioni applicative).

Il Policy Administrator (PA) è il componente che esegue la decisione del PE, stabilendo o terminando il canale di comunicazione tra il soggetto richiedente e la risorsa. Il PA genera i token di autenticazione, le credenziali di sessione o i parametri di configurazione necessari per stabilire il canale e li comunica ai componenti rilevanti. Il PA è inoltre responsabile di istruire il Policy Enforcement Point affinché applichi la decisione. Il Policy Enforcement Point (PEP) è il componente che abilita, monitora e termina la connessione tra il soggetto e la risorsa. Concettualmente, il PEP è suddiviso in due elementi: il lato client, che intercetta la richiesta del soggetto, e il lato risorsa, che controlla l'accesso alla risorsa stessa.

flowchart TB
    subgraph "Control Plane"
        PE[Policy Engine]
        PA[Policy Administrator]
        CDI[(Fonti informative)]
    end

    subgraph "Data Plane"
        PEP_C[PEP — Lato soggetto]
        PEP_R[PEP — Lato risorsa]
        RES[(Risorsa enterprise)]
    end

    S([Soggetto]) --> PEP_C
    PEP_C -->|Richiesta di accesso| PA
    PA -->|Query| PE
    PE <-->|Input decisionale| CDI
    PE -->|Decisione grant/deny| PA
    PA -->|Configura sessione| PEP_C
    PA -->|Configura sessione| PEP_R
    PEP_C <-->|Canale dati autenticato| PEP_R
    PEP_R --> RES

    CDI --- ID[Identity Store]
    CDI --- TI[Threat Intelligence]
    CDI --- SIEM[SIEM / Log]
    CDI --- COMP[Compliance Data]

La separazione tra control plane (PE + PA) e data plane (PEP) è un principio architetturale critico. Il canale di controllo, attraverso cui fluiscono le decisioni di accesso, deve essere separato e protetto rispetto al canale dati attraverso cui fluisce il traffico applicativo. Una compromissione del data plane non deve poter influenzare le decisioni del control plane; reciprocamente, un malfunzionamento del control plane deve risultare in un fallimento sicuro (fail-closed), negando gli accessi anziché concederli in modo indiscriminato.

Il trust algorithm e le fonti informative

Il meccanismo attraverso cui il Policy Engine formula le proprie decisioni è denominato trust algorithm. Il NIST descrive due varianti architetturali principali [4]. Nella variante basata su criteri (criteria-based), il PE valuta ogni richiesta contro un insieme predefinito di condizioni: se tutte le condizioni sono soddisfatte, l'accesso viene concesso. Nella variante basata su score, il PE calcola un punteggio di fiducia aggregando indicatori ponderati, livello di autenticazione, postura del dispositivo, rischio della risorsa, contesto comportamentale, e confronta il risultato con una soglia configurabile. La seconda variante offre maggiore flessibilità ma introduce il problema della calibrazione: soglie troppo alte producono falsi negativi (accessi legittimi bloccati), soglie troppo basse producono falsi positivi (accessi illegittimi concessi).

Le fonti informative che alimentano il trust algorithm includono: il sistema CDM (Continuous Diagnostics and Mitigation), che fornisce dati aggiornati sulla postura degli asset; i sistemi di compliance, che verificano il rispetto delle policy organizzative; i feed di threat intelligence, che segnalano indicatori di compromissione noti; i log di attività di rete e di sistema, che consentono l'analisi comportamentale; i sistemi di data access policy, che definiscono le regole di accesso granulari per ciascuna risorsa. L'efficacia del trust algorithm è direttamente proporzionale alla qualità, alla completezza e alla tempestività di queste fonti.

Modelli di deployment e varianti architetturali

Deployment basato su device agent e gateway

Il NIST SP 800-207 identifica tre modelli di deployment principali per l'implementazione del PEP [4]. Il primo modello utilizza un agente software installato sul dispositivo del soggetto (device agent) che comunica direttamente con un gateway posizionato davanti alla risorsa. L'agente sul dispositivo raccoglie informazioni sulla postura del device (stato degli aggiornamenti, conformità alle policy, presenza di malware) e le inoltra al PA insieme alla richiesta di accesso. Il gateway verifica la decisione del PE e stabilisce un canale crittografato verso la risorsa. Questo modello offre il massimo controllo sulla postura del dispositivo, ma richiede che l'organizzazione possa installare e gestire agenti su tutti i dispositivi, un requisito che diventa problematico in scenari BYOD (Bring Your Own Device) o con contractor che utilizzano dispositivi personali.

Deployment basato su enclave gateway

Il secondo modello posiziona il PEP a livello di enclave, proteggendo non singole risorse ma insiemi di risorse raggruppate logicamente. Un gateway di enclave funge da punto di enforcement per tutte le risorse dell'enclave, riducendo il numero di componenti PEP necessari ma introducendo una granularità inferiore: una volta autorizzato l'accesso all'enclave, il soggetto può potenzialmente accedere a tutte le risorse al suo interno. Questo modello rappresenta un compromesso pragmatico per organizzazioni che non possono implementare enforcement a livello di singola risorsa, ma la sua efficacia dipende dalla dimensione e dall'omogeneità delle enclave.

Deployment basato su resource portal

Il terzo modello utilizza un portale applicativo (resource portal) come unico punto di accesso. Il soggetto si collega al portale, che agisce simultaneamente come PEP e come reverse proxy, inoltrando il traffico alla risorsa appropriata dopo aver ottenuto l'autorizzazione dal PE. Questo modello è particolarmente adatto per l'accesso ad applicazioni web e API, e costituisce il fondamento architetturale dell'approccio BeyondCorp di Google, dove l'Access Proxy funge da PEP centralizzato per tutte le applicazioni aziendali [3]. Il vantaggio principale è l'assenza di requisiti software sul dispositivo del soggetto; il limite è che il portale diventa un single point of failure e un collo di bottiglia potenziale per le prestazioni.

L'estensione cloud-native: NIST SP 800-207A

Nel settembre 2023, il NIST ha pubblicato la SP 800-207A, che estende il modello architetturale della SP 800-207 agli ambienti cloud-native basati su microservizi [8]. In un'architettura a microservizi, il concetto di "soggetto" si estende dai soli utenti umani ai workload software: un microservizio che invoca un altro microservizio è un soggetto la cui identità e autorizzazione devono essere verificate con lo stesso rigore applicato agli utenti umani. La SP 800-207A identifica tre tecnologie chiave per l'implementazione del PEP in ambienti cloud-native: gli API gateway, che fungono da punto di enforcement per il traffico nord-sud (esterno al cluster); i sidecar proxy, che implementano l'enforcement per il traffico est-ovest (tra microservizi) come componente del service mesh; e le infrastrutture di identità dei workload, in particolare il framework SPIFFE (Secure Production Identity Framework For Everyone) [9].

SPIFFE, progetto graduated della CNCF, definisce uno standard per l'assegnazione di identità crittograficamente verificabili ai workload software [9]. Ogni workload riceve uno SPIFFE ID, un URI nella forma spiffe://trust-domain/path, e un SPIFFE Verifiable Identity Document (SVID), tipicamente un certificato X.509 a breve scadenza che attesta l'identità del workload senza richiedere la distribuzione di secret statici. L'implementazione di riferimento, SPIRE (SPIFFE Runtime Environment), automatizza l'emissione e la rotazione degli SVID, consentendo l'autenticazione mutua (mTLS) tra microservizi senza gestione manuale dei certificati. Questo approccio risolve un problema fondamentale delle architetture zero trust in ambienti cloud-native: l'identità dei workload non può essere derivata dall'indirizzo IP (effimero nei container orchestrati da Kubernetes), ma deve essere attestata crittograficamente.

Micro-segmentazione e controllo del traffico est-ovest

Dal perimetro alla segmentazione granulare

La micro-segmentazione è il meccanismo architetturale che traduce il principio zero trust di accesso individuale per sessione nel dominio del traffico di rete. Mentre la segmentazione tradizionale suddivide la rete in macro-zone (DMZ, segmento server, segmento client) con firewall perimetrali che regolano il traffico tra zone, la micro-segmentazione crea confini di sicurezza attorno a singoli workload o gruppi ristretti di workload correlati [10]. Ogni flusso di comunicazione tra due entità è soggetto a una policy esplicita, anche quando le due entità risiedono nello stesso segmento fisico o logico della rete.

L'importanza della micro-segmentazione nel contesto zero trust è documentata dal fatto che la CISA la identifica come uno dei componenti chiave della propria guida implementativa, pubblicando nel 2025 un documento specifico dedicato alla micro-segmentazione all'interno delle architetture zero trust [10]. Il documento sottolinea come la micro-segmentazione affronti direttamente il problema del lateral movement, la capacità di un attaccante che ha ottenuto un punto d'ingresso iniziale di muoversi lateralmente attraverso la rete fino a raggiungere asset di valore. In un'architettura micro-segmentata, la compromissione di un singolo workload non concede accesso automatico agli altri workload, anche se questi risiedono sullo stesso host fisico.

Approcci implementativi e trade-off

Esistono tre approcci principali per l'implementazione della micro-segmentazione, ciascuno con caratteristiche distinte. L'approccio network-based opera a livello di infrastruttura, utilizzando Software-Defined Networking (SDN) per creare overlay network con policy distribuite. Soluzioni come VMware NSX implementano la micro-segmentazione attraverso firewall distribuiti integrati nell'hypervisor, applicando regole a livello di interfaccia di rete virtuale di ciascuna VM. Il vantaggio è la trasparenza per i workload, che non richiedono modifiche; il limite è la dipendenza dallo stack di virtualizzazione specifico.

L'approccio host-based installa agenti su ciascun workload che controllano il traffico a livello di sistema operativo, utilizzando il kernel firewall nativo (iptables/nftables su Linux, Windows Filtering Platform su Windows). Questo approccio è agnostico rispetto all'infrastruttura sottostante e può operare in ambienti eterogenei, on-premises, multi-cloud, container, ma introduce complessità nella distribuzione e nell'aggiornamento degli agenti e un potenziale overhead prestazionale. L'approccio application-layer utilizza proxy applicativi, tipicamente i sidecar proxy di un service mesh come Istio o Linkerd, per controllare il traffico a livello di singola chiamata API. Questo approccio offre la granularità massima, consentendo policy basate su metodo HTTP, path, header e contenuto della richiesta, ma aggiunge latenza (ogni chiamata transita attraverso il proxy) e complessità architetturale.

La scelta tra questi approcci non è mutuamente esclusiva: le implementazioni più mature combinano micro-segmentazione network-based per il traffico tra zone e micro-segmentazione application-layer per il traffico tra microservizi all'interno della stessa zona, ottenendo una difesa stratificata coerente con il principio della defense in depth.

Il problema della complessità delle policy

Il limite operativo più significativo della micro-segmentazione è la complessità delle policy. In un ambiente con $n$ workload, il numero di potenziali relazioni di comunicazione cresce come $O(n^2)$. Per un data center con 500 microservizi, ciò implica potenzialmente 250.000 regole da definire, mantenere e verificare. Wool ha dimostrato già nel 2004 che le configurazioni di firewall tradizionali, con numeri di regole di ordini di grandezza inferiori, presentano errori sistematici che compromettono la sicurezza effettiva [11]. La micro-segmentazione amplifica questo problema esponenzialmente.

Le strategie per mitigare la policy explosion includono il policy discovery automatizzato, in cui strumenti di osservazione del traffico generano policy che riflettono i pattern di comunicazione legittimi osservati, e la classificazione identity-based, in cui le policy sono definite in termini di etichette applicative, ruoli o identità dei servizi anziché di coppie indirizzo IP-porta. Quest'ultimo approccio riduce drasticamente il numero di regole, una singola policy "il servizio di pagamento può comunicare con il servizio di ordini sulla porta 8443" sostituisce centinaia di regole IP-based che dovrebbero essere aggiornate a ogni rischedulazione dei container.

Verifica continua e adattamento dinamico

Oltre l'autenticazione puntuale: continuous verification

Uno dei principi più distintivi dell'architettura zero trust rispetto ai modelli di sicurezza tradizionali è la verifica continua. Nel modello perimetrale classico, l'autenticazione è un evento puntuale: una volta superato il checkpoint iniziale, l'utente o il dispositivo opera in regime di fiducia fino alla scadenza della sessione. In un'architettura zero trust, la verifica non è un evento ma un processo continuo: il trust algorithm rivaluta il livello di fiducia a intervalli regolari o al verificarsi di eventi significativi, un cambio di rete, un'anomalia comportamentale, un aggiornamento del feed di threat intelligence [4].

La continuous verification si articola su tre dimensioni. La prima è la verifica dell'identità: non solo l'autenticazione iniziale (tipicamente multi-fattore), ma la rivalutazione periodica della validità delle credenziali e la rilevazione di anomalie nel pattern di autenticazione. La seconda è la verifica della postura del dispositivo: il monitoraggio continuo dello stato di sicurezza del dispositivo, aggiornamenti del sistema operativo, stato dell'antivirus, conformità alle configurazioni richieste, integrità del software, attraverso sistemi di Continuous Diagnostics and Mitigation (CDM). La terza è la verifica comportamentale: l'analisi dei pattern di accesso e di utilizzo rispetto a un modello di comportamento normale (baseline), con la generazione di alert o la revoca degli accessi in caso di deviazioni significative.

Il ruolo del SIEM e dell'analisi comportamentale

L'implementazione della continuous verification richiede un'infrastruttura di raccolta e analisi dei dati in grado di operare in near-real-time. I sistemi SIEM (Security Information and Event Management) costituiscono il substrato tecnologico per questa capacità, aggregando eventi da fonti eterogenee, log di autenticazione, traffico di rete, attività endpoint, eventi applicativi, e correlando questi eventi per identificare pattern indicativi di compromissione. L'evoluzione dei SIEM verso piattaforme di Security Orchestration, Automation and Response (SOAR) aggiunge la capacità di tradurre automaticamente le rilevazioni in azioni correttive: la revoca di un token di accesso, l'isolamento di un endpoint, l'innalzamento del livello di autenticazione richiesto.

L'analisi comportamentale (User and Entity Behavior Analytics, UEBA) rappresenta il livello più sofisticato della continuous verification. I sistemi UEBA costruiscono profili comportamentali per ciascuna entità (utente, dispositivo, servizio) e rilevano deviazioni statisticamente significative rispetto alla baseline. In un contesto zero trust, la UEBA alimenta direttamente il trust algorithm del Policy Engine: un accesso tecnicamente autorizzato ma comportamentalmente anomalo (ad esempio, un utente che accede a un volume di dati insolitamente elevato, o un servizio che comunica con un endpoint mai contattato in precedenza) può determinare una riduzione del trust score e un'azione correttiva proporzionata.

Il modello di maturità CISA e l'adozione organizzativa

Struttura del Zero Trust Maturity Model

Il CISA Zero Trust Maturity Model (ZTMM), pubblicato nella versione 2.0 nell'aprile 2023, fornisce un framework di riferimento per guidare le organizzazioni nella transizione verso architetture zero trust [12]. Il modello è stato sviluppato in risposta all'Executive Order 14028 e al memorandum M-22-09, che impongono alle agenzie federali statunitensi l'adozione di architetture zero trust [5, 6]. Sebbene nato nel contesto federale, il ZTMM ha assunto rilevanza più ampia come framework di valutazione della maturità zero trust applicabile anche in contesto enterprise.

Il ZTMM si articola attorno a cinque pilastri, Identity, Devices, Networks, Applications and Workloads, Data, e tre capacità trasversali, Visibility and Analytics, Automation and Orchestration, Governance. Per ciascun pilastro, il modello definisce quattro livelli di maturità: Traditional (il punto di partenza, con controlli perimetrali e fiducia implicita), Initial (primi elementi di automazione e visibilità), Advanced (policy dinamiche e integrazione tra pilastri) e Optimal (piena automazione, verifica continua e risposta in near-real-time) [12]. La progressione non è lineare né uniforme: un'organizzazione può trovarsi a livelli di maturità differenti per pilastri diversi, e il modello riconosce esplicitamente che il raggiungimento del livello Optimal su tutti i pilastri è un obiettivo a lungo termine.

Software-Defined Perimeter come modello implementativo

La Cloud Security Alliance ha formalizzato nel 2022 la specifica Software-Defined Perimeter (SDP) v2.0, che definisce un modello architetturale per l'implementazione dei principi zero trust a livello di rete [13]. L'architettura SDP si basa su tre componenti: un controller che funge da Policy Engine/Policy Administrator, un Initiating Host (IH) sul lato del soggetto e un Accepting Host (AH) sul lato della risorsa. Il protocollo prevede che l'IH si autentichi presso il controller prima di ricevere le informazioni necessarie per stabilire una connessione con l'AH; l'AH non accetta connessioni da host che non siano stati autorizzati dal controller. Questo modello implementa il principio di "default deny": le risorse sono invisibili e irraggiungibili fino a quando un'autorizzazione esplicita non ne consente l'accesso.

Il working group SDP della CSA è stato successivamente integrato nel più ampio Zero Trust Working Group, riflettendo la convergenza del concetto di SDP con il framework zero trust più generale [13]. Le implementazioni commerciali di Zero Trust Network Access (ZTNA), termine coniato da Gartner per descrivere soluzioni che implementano principi SDP/zero trust per l'accesso remoto, hanno progressivamente sostituito le VPN tradizionali come meccanismo di accesso alle risorse aziendali per gli utenti remoti. A differenza della VPN, che concede accesso all'intera rete una volta stabilito il tunnel, una soluzione ZTNA concede accesso esclusivamente alle risorse specifiche per cui l'utente è autorizzato, applicando il principio di least privilege a livello di singola applicazione.

Sfide implementative e problemi aperti

Integrazione con sistemi legacy

La systematic literature review di Gambo e Almulhem [7], insieme allo studio di Karangi e Jayalaxmi pubblicato su Sensors nel 2025 [14], identificano le sfide implementative più significative nell'adozione di architetture zero trust. La prima e più pervasiva è l'integrazione con sistemi legacy. Le infrastrutture enterprise esistenti includono tipicamente applicazioni monolitiche che non supportano autenticazione basata su token, protocolli proprietari che non possono transitare attraverso un PEP, e apparati di rete con funzionalità limitate di micro-segmentazione. La transizione non può avvenire come sostituzione radicale (big bang), ma richiede una strategia incrementale in cui i principi zero trust vengono applicati progressivamente, partendo dalle risorse più critiche e ad alto rischio.

Complessità operativa e skill gap

La seconda sfida è la complessità operativa. Un'architettura zero trust pienamente implementata genera un volume di decisioni di accesso, log e alert ordini di grandezza superiore rispetto a un'architettura perimetrale. Senza un adeguato livello di automazione, il carico operativo sui team di sicurezza diventa insostenibile. Il ZTMM del CISA riconosce esplicitamente questo problema, posizionando "Automation and Orchestration" come capacità trasversale necessaria a tutti i livelli di maturità [12]. A ciò si aggiunge uno skill gap significativo: la progettazione e la gestione di architetture zero trust richiedono competenze trasversali, sicurezza di rete, gestione delle identità, automazione infrastrutturale, analisi dei dati, raramente concentrate in un singolo team.

Interoperabilità e vendor lock-in

La terza sfida riguarda l'interoperabilità. In assenza di standard di interoperabilità pienamente consolidati tra le componenti zero trust di vendor diversi, le organizzazioni rischiano di costruire architetture fortemente accoppiate a un singolo ecosistema. Il Policy Engine di un vendor potrebbe non integrarsi nativamente con il PEP di un altro; le policy di micro-segmentazione definite in un ambiente cloud potrebbero non essere trasferibili a un altro. Il NIST SP 800-207 affronta questo rischio raccomandando la separazione logica tra i componenti (PE, PA, PEP) e l'uso di interfacce standardizzate [4], ma nella pratica l'integrazione multi-vendor resta complessa e costosa.

Bilanciamento tra sicurezza e usabilità

La quarta sfida è il bilanciamento tra sicurezza e usabilità. Un'architettura zero trust rigorosa che impone verifica continua, autenticazione multi-fattore frequente e accesso granulare può generare frizione nell'esperienza utente, con impatti negativi sulla produttività. Il progetto BeyondCorp di Google ha documentato questa tensione, dedicando un intero articolo al tema del mantenimento della produttività durante la migrazione [15]. La soluzione non è rilassare i controlli, ma progettare meccanismi di autenticazione il meno intrusivi possibile, autenticazione basata su rischio che intensifica la verifica solo in presenza di anomalie, single sign-on che riduce il numero di autenticazioni esplicite, autenticazione continua passiva basata su biometria comportamentale.

Metriche e misurazione dell'efficacia

Una lacuna significativa nella letteratura e nella pratica riguarda la misurazione dell'efficacia delle implementazioni zero trust. A differenza di altre discipline della sicurezza informatica, dove metriche consolidate consentono confronti quantitativi (mean time to detect, mean time to respond, false positive rate), non esiste ancora un framework metrico standardizzato per valutare la maturità e l'efficacia di un'architettura zero trust. Il ZTMM del CISA offre una scala qualitativa (Traditional, Initial, Advanced, Optimal), ma non definisce metriche quantitative per ciascun livello [12]. Questa assenza complica la giustificazione degli investimenti e la misurazione del ritorno, rendendo difficile per le organizzazioni quantificare il miglioramento della postura di sicurezza ottenuto dalla transizione.

Riferimenti

[1] J. Kindervag, "Build Security Into Your Network's DNA: The Zero Trust Network Architecture," Forrester Research, 2010. https://www.forrester.com/report/build-security-into-your-networks-dna-the-zero-trust-network-architecture/RES57047

[2] R. Ward, B. Beyer, "BeyondCorp: A New Approach to Enterprise Security," ;login: USENIX, vol. 39, no. 6, Dec. 2014. https://research.google/pubs/beyondcorp-a-new-approach-to-enterprise-security/

[3] B. Osborn, J. McWilliams, B. Beyer, M. Saltonstall, "BeyondCorp: Design to Deployment at Google," ;login: USENIX, vol. 41, no. 1, Spring 2016. https://www.usenix.org/publications/login/spring2016/osborn

[4] S. Rose, O. Borchert, S. Mitchell, S. Connelly, "Zero Trust Architecture," NIST Special Publication 800-207, 2020. https://doi.org/10.6028/NIST.SP.800-207

[5] Executive Order 14028, "Improving the Nation's Cybersecurity," The White House, May 2021. https://www.cisa.gov/topics/cybersecurity-best-practices/executive-order-improving-nations-cybersecurity

[6] Office of Management and Budget, "M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles," January 2022. https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

[7] M. L. Gambo, A. Almulhem, "Zero Trust Architecture: A Systematic Literature Review," Journal of Network and Systems Management, vol. 34, 2025. https://link.springer.com/article/10.1007/s10922-025-09998-x

[8] S. Rose et al., "A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments," NIST Special Publication 800-207A, 2023. https://csrc.nist.gov/pubs/sp/800/207/a/final

[9] SPIFFE Project, "SPIFFE: Secure Production Identity Framework For Everyone," CNCF, 2024. https://spiffe.io/

[10] CISA, "Microsegmentation in Zero Trust — Guidance Part One," 2025. https://www.cisa.gov/sites/default/files/2025-07/ZT-Microsegmentation-Guidance-Part-One_508c.pdf

[11] A. Wool, "A Quantitative Study of Firewall Configuration Errors," IEEE Computer, vol. 37, no. 6, pp. 62–67, 2004.

[12] CISA, "Zero Trust Maturity Model, Version 2.0," April 2023. https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf

[13] Cloud Security Alliance, "Software-Defined Perimeter (SDP) Specification v2.0," March 2022. https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-zero-trust-specification-v2

[14] R. Karangi, P. Jayalaxmi, "A Systematic Literature Review on the Implementation and Challenges of Zero Trust Architecture Across Domains," Sensors, vol. 25, no. 19, 6118, 2025. https://www.mdpi.com/1424-8220/25/19/6118

[15] L. Peck, B. Beyer et al., "Migrating to BeyondCorp: Maintaining Productivity While Improving Security," ;login: USENIX, vol. 42, no. 2, Summer 2017. https://research.google/pubs/migrating-to-beyondcorp/