ZTNA: il modello Zero Trust per l’accesso remoto sicuro alle applicazioni aziendali
Data: 12 Novembre 2026Quante applicazioni aziendali vede una persona collegata da casa con la VPN? Spesso tutte quelle della rete, anche se per il suo lavoro ne usa due.
Con il lavoro ibrido il modello di sicurezza perimetrale mostra un limite importante: chi entra nel tunnel entra nella rete, e un account compromesso o un dispositivo non aggiornato diventano il punto di partenza per muoversi tra i sistemi. Il modello Zero Trust ribalta la logica, e ZTNA, Zero Trust Network Access, la applica all’accesso alle applicazioni.
In questo articolo scoprirai cos’è lo ZTNA e come si colloca nella Zero Trust Architecture, come funziona la separazione tra controllo e dati, perché conviene sostituire la VPN, quali modalità di implementazione esistono, con agente o senza, e come introdurlo senza bloccare l’operatività.
ZTNA cos’è: il significato del modello di sicurezza Zero Trust
Lo ZTNA, Zero Trust Network Access, è un modello di sicurezza che concede a un utente l’accesso a una singola applicazione, e mai all’intera rete, dopo aver verificato identità, dispositivo e contesto della richiesta.
Si basa sul concetto di Software-Defined Perimeter, un perimetro definito dal software attorno a ogni applicazione, e sul principio “never trust, always verify”: nessuna richiesta è considerata affidabile per il solo fatto di arrivare dalla rete interna o da un utente già autenticato.
Lo ZTNA crea attorno all’applicazione un confine logico basato sull’identità e sul contesto della richiesta. Un componente di intermediazione verifica le condizioni di accesso e consente la connessione esclusivamente agli utenti e ai dispositivi autorizzati. Le applicazioni non risultano direttamente raggiungibili dai soggetti privi delle necessarie autorizzazioni.
Il significato di Zero Trust si regge su tre pilastri:
- verificare esplicitamente ogni richiesta di accesso, in base a identità, dispositivo e contesto;
- concedere il privilegio minimo, cioè solo l’accesso necessario a quella attività;
- presupporre la violazione, progettando i controlli come se un attaccante fosse già nella rete.
Capita di leggere “framework ZTNA”, ma il termine è improprio. Lo ZTNA è la modalità con cui si realizza il punto della strategia Zero Trust che riguarda l’accesso alle applicazioni, e si implementa con tecnologie e servizi di architettura diversa.
Il principale riferimento metodologico è la Zero Trust Architecture descritta nella pubblicazione SP 800-207, che definisce principi e componenti logici per l’applicazione del modello Zero Trust.
ZTNA, Zero Trust Architecture e SASE: come si collegano
La Zero Trust Architecture (ZTA) è il piano di sicurezza di un’organizzazione costruito sui principi Zero Trust, e copre utenti, dati, carichi di lavoro e rete.
Lo ZTNA ne realizza la parte sull’accesso degli utenti alle applicazioni, mentre la microsegmentazione governa il traffico tra i carichi di lavoro.
SASE, Secure Access Service Edge, è invece un’architettura che porta in cloud servizi di rete e di sicurezza.
Lo ZTNA ne è una componente di sicurezza, insieme a secure web gateway, CASB e firewall erogato come servizio, mentre la parte di rete è affidata all’SD-WAN.
Un’azienda può adottare lo ZTNA da sola, come primo passo, e arrivare a SASE quando decide di riorganizzare insieme rete e sicurezza.
Come funziona l’architettura ZTNA: la separazione tra controllo e dati
L’architettura ZTNA separa due piani.
Il Control Plane gestisce identità e policy: riceve la richiesta, la valuta e decide se autorizzarla.
Il Data Plane è il canale cifrato che collega direttamente l’utente all’applicazione e viene aperto solo dopo l’approvazione del primo.
Nella terminologia del NIST sono il punto di decisione, o policy decision point, e il punto di applicazione, o policy enforcement point, che apre, monitora e chiude la connessione.
Prima di concedere l’accesso, il Control Plane analizza in tempo reale una serie di fattori di contesto:
- identità dell’utente, verificata con autenticazione a più fattori (MFA)
- postura del dispositivo, cioè aggiornamenti installati, cifratura del disco e protezione dell’endpoint attiva
- ruolo e gruppo di appartenenza, che definiscono le applicazioni a cui l’utente ha diritto
- posizione geografica e orario della richiesta
- livello di rischio della sessione, per esempio un accesso insolito rispetto alle abitudini dell’utente
Se tutti i requisiti sono soddisfatti si apre la connessione verso quella sola applicazione, valida per la sessione. Se il contesto cambia mentre la sessione è attiva, l’accesso viene rivalutato e può essere interrotto.
Perché sostituire le VPN con lo ZTNA: tabella comparativa e vantaggi
La VPN tradizionale estende la rete aziendale al dispositivo remoto. Superata l’autenticazione l’utente entra in un’ampia porzione della rete, e se le sue credenziali vengono compromesse l’attaccante può compiere movimenti laterali verso altri sistemi.
Il NIST segnala che un utente remoto non dovrebbe passare dalla rete aziendale per raggiungere servizi ospitati in cloud pubblico: un passaggio inutile, che aggiunge latenza e rischio.
Lo ZTNA riduce la superficie di attacco perché rende le applicazioni invisibili all’esterno e le espone solo a chi ha superato la verifica. Il confronto sui parametri che contano:
| Parametro | VPN Legacy | ZTNA |
|---|---|---|
| Ambito di accesso | L’intera rete o un’ampia sottorete | La singola applicazione |
| Verifica del dispositivo | Spesso assente o limitata al momento della connessione | Postura valutata a ogni sessione |
| Movimento laterale | Possibile dopo una compromissione | Limitato dalla policy per applicazione |
| Visibilità delle applicazioni | Visibili a chi è dentro la rete | Nascoste ai non autorizzati |
| Gestione dei permessi | Per rete, con regole spesso statiche | Per identità e contesto, con regole dinamiche |
In molti progetti VPN e ZTNA convivono per un periodo. Le applicazioni passano al nuovo modello a gruppi, e la VPN si ritira quando non serve più a nessun sistema.
Agent-based e Agentless: le diverse modalità di implementazione
Per gestire sia i dispositivi aziendali sia quelli personali o di terze parti, lo ZTNA offre due modalità.
Nell’approccio agent-based un software agent è installato sull’endpoint: verifica la postura del dispositivo e instrada il traffico verso le applicazioni autorizzate.
È la scelta naturale per i dispositivi gestiti dall’azienda, e i client esistono per i principali sistemi operativi: Windows, macOS, Linux, iOS e Android, con una copertura che varia da prodotto a prodotto.
Nell’approccio agentless l’utente raggiunge le applicazioni da un portale web, con il solo browser. Si adatta al BYOD, ai consulenti e ai fornitori, che non possono o non devono installare software sul proprio dispositivo, con due limiti: copre in genere le applicazioni web e permette una verifica meno profonda della postura del dispositivo.
Sul mercato si parla anche di ZTNA 1.0 e ZTNA 2.0.
Nella prima generazione la verifica avviene al momento dell’accesso e, superata, la sessione è considerata affidabile fino alla chiusura.
Nella seconda l’ispezione dei dati continua per tutta la sessione, e la decisione di accesso viene rivalutata se cambiano postura o comportamento.
Si tratta di etichette commerciali e non standard, ma che indicano un criterio di valutazione utile: la sessione va ispezionata in modo continuo, non solo autenticata all’ingresso.
Come introdurre lo ZTNA senza bloccare l’operatività
Il progetto riesce quando parte dalle applicazioni e non dallo strumento. I passaggi che funzionano di più:
- mappare le applicazioni e chi le usa davvero, per definire il livello minimo di accesso di ogni ruolo
- rafforzare l’identità, con una directory unica e l’autenticazione a più fattori
- stabilire i requisiti che un dispositivo deve rispettare per accedere, compresi quelli personali, tema che trattiamo nella nostra guida al BYOD
- partire da un perimetro pilota, per esempio gli accessi dei fornitori o un gruppo di utenti remoti
- misurare l’adozione e ritirare gradualmente la VPN sulle applicazioni già migrate
Abilitare l’accesso remoto sicuro: l’approccio di WeAreProject
L’introduzione dello ZTNA richiede il coordinamento tra gestione delle identità, sicurezza degli endpoint, connettività, applicazioni e processi operativi. La sola adozione di una tecnologia non è sufficiente se non è accompagnata da una corretta definizione delle policy di accesso e da un percorso graduale di migrazione.
Il progetto dovrebbe partire dalla mappatura delle applicazioni, degli utenti e dei dispositivi, per poi definire i criteri di autorizzazione e individuare un perimetro pilota. La progressiva estensione del modello consente di verificare l’impatto sull’operatività e di ridurre gradualmente il ricorso agli accessi VPN tradizionali.
Come possiamo supportarti
Attraverso attività di advisory e assessment, supportiamo le organizzazioni nella mappatura delle risorse, nella definizione delle policy di accesso e nella progettazione di un percorso graduale verso un modello Zero Trust.
Accompagniamo più di 7.500 organizzazioni con oltre 800 professionisti, e per il monitoraggio continuo puoi contare sul nostro Cyber SOC H24.
Domande frequenti su ZTNA
Qual è la differenza principale tra ZTNA e VPN?
La VPN collega il dispositivo alla rete aziendale, lo ZTNA collega l’utente alla singola applicazione dopo la verifica di identità, dispositivo e contesto. Cambia l’ambito di accesso: ampio nella VPN, circoscritto nello ZTNA.
Su quali dispositivi può essere utilizzato lo ZTNA?
Le soluzioni ZTNA possono supportare dispositivi desktop e mobili, gestiti o non gestiti. La compatibilità con i diversi sistemi operativi, la disponibilità di un agente e la profondità dei controlli sulla postura variano in base all’implementazione. Prima dell’adozione è quindi necessario verificare la copertura rispetto ai dispositivi aziendali, personali e di terze parti effettivamente utilizzati.
Lo ZTNA protegge l’azienda dagli attacchi informatici interni?
In parte. Limita il danno di un account compromesso o di un utente interno con privilegi eccessivi, perché ognuno raggiunge solo le applicazioni autorizzate e la sessione può essere interrotta. Non impedisce invece azioni illecite dentro un’applicazione a cui l’utente ha diritto di accedere: servono anche monitoraggio, gestione dei privilegi e protezione dei dati.