Zero Trust spiegato semplice: ZTNA invece del VPN classico
Zero Trust non significa che non ci si fidi più di nessuno. Significa che l’accesso non viene più concesso in modo generico solo perché un utente si trova nella rete interna, nel VPN o in una posizione nota. Ogni accesso viene controllato consapevolmente: chi accede? Da quale dispositivo? A quale applicazione? In quali condizioni?
Zero Trust Network Access, o ZTNA, è una realizzazione concreta di questa idea per remote access e applicazioni private. Invece di aprire un’intera rete tramite VPN, un utente riceve accesso solo alle applicazioni o risorse previste per il suo ruolo.
Questo articolo spiega le basi in modo volutamente neutrale rispetto ai vendor. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access e altre soluzioni applicano principi simili in modi diversi. La prima decisione non è quindi il prodotto, ma il modello di accesso.
Inquadrare Zero Trust e ZTNA
Zero Trust è un’architettura di sicurezza. ZTNA è un percorso tecnico di accesso all’interno di questa architettura.
Zero Trust è un principio
Le reti classiche lavorano spesso con un presupposto implicito: dentro è più affidabile che fuori. Oggi questo presupposto è pericoloso. Gli utenti lavorano in mobilità, le applicazioni risiedono in SaaS, data center e cloud, i dispositivi cambiano continuamente posizione e credenziali compromesse sono uno scenario realistico.
Zero Trust sposta il focus dai confini di rete a identità, dispositivo, applicazione, dati e contesto. NIST descrive Zero Trust come un’architettura che riduce la fiducia implicita e valuta l’accesso per ogni richiesta. In pratica, un login riuscito da solo non basta più.
ZTNA è accesso a risorse concrete
ZTNA sostituisce accessi di rete ampi con accesso basato su risorse. Un utente non vede automaticamente un’intera subnet, ma solo le applicazioni per cui una policy corrisponde.
Risorse ZTNA tipiche sono:
- applicazioni web interne,
- portali amministrativi,
- accessi RDP o SSH tramite percorsi controllati,
- singole applicazioni TCP,
- accessi sviluppo, supporto o partner,
- applicazioni SaaS con controllo di accesso aggiuntivo.
In questo modo il remote access diventa più granulare. Un account compromesso non dovrebbe poter raggiungere subito tutta la rete interna.
Perché ZTNA è diverso da VPN
VPN non è automaticamente sbagliato. Molti ambienti hanno ancora bisogno di site-to-site VPN, admin VPN, protocolli speciali o accessi di emergenza. La differenza sta nel modello di fiducia.
VPN spesso apre una rete
Un remote access VPN classico collega un dispositivo a una rete interna. Routing, regole firewall, DNS e segmentazione decidono poi cosa è raggiungibile. Se l’ambiente è costruito bene, può funzionare. In pratica, le reti VPN sono spesso troppo ampie, cresciute storicamente o difficili da verificare.
Rischi tipici:
- Gli utenti ricevono accesso a più sistemi del necessario.
- Vecchi gruppi VPN restano attivi.
- Split tunnel, DNS e rotte non sono chiari.
- Malware su un client VPN può raggiungere target interni.
- Accessi admin usano lo stesso tunnel degli accessi utente.
ZTNA controlla più vicino all’applicazione
ZTNA decide per applicazione o risorsa. Una policy può considerare gruppo utente, MFA, dispositivo, posizione, rischio, stato client e altre condizioni. Solo quando le condizioni corrispondono viene consentito l’accesso esattamente a quella risorsa.
Questo riduce la superficie di attacco, ma non sostituisce una progettazione applicativa sicura. Un’applicazione insicura resta insicura anche dietro ZTNA. ZTNA controlla l’accesso, non automaticamente l’applicazione stessa.
Componenti di un buon ambiente Zero Trust
Zero Trust è debole se viene introdotto solo come nuovo strumento di accesso. Il valore nasce quando più componenti funzionano insieme.
Identità e MFA
L’identità è il punto di ingresso più importante. Utenti, gruppi, ruoli e account esterni devono essere mantenuti in modo pulito. MFA dovrebbe essere obbligatorio per accessi critici. Negli ambienti Microsoft, Microsoft Entra ID è spesso la fonte identità centrale; in altri ambienti, altri Identity Provider possono svolgere lo stesso ruolo.
Anche l’offboarding è importante. Quando un utente lascia l’azienda, l’accesso deve sparire non solo in una singola applicazione, ma nell’identità centrale e in tutte le policy rilevanti.
Dispositivo e contesto
ZTNA diventa più forte quando viene valutato non solo l’utente, ma anche il dispositivo. A seconda della soluzione, sistema operativo, stato dispositivo, certificato, stato EDR, stato di gestione, posizione o rischio possono influenzare la decisione.
Questo è particolarmente rilevante per:
- dispositivi privati,
- fornitori esterni,
- accessi admin privilegiati,
- accesso a sistemi finance, HR o produzione,
- dispositivi senza stato di protezione attuale.
Gateway, connector o servizio cloud
ZTNA richiede un percorso dati tra utente e applicazione. A seconda del provider esistono gateway, connector, tunnel o cloud PoP. Questa parte decide dove entra il traffico, chi gestisce il percorso dati e quali regole DNS, certificati e firewall sono necessarie.
Cloudflare lavora spesso con Cloudflare Tunnel e Access Policies. Sophos ZTNA usa Sophos Central, ZTNA Gateways e policy di risorse. L’architettura è diversa, ma la domanda di base resta uguale: come arriva un utente in modo controllato all’applicazione senza aprire tutta la rete?
Policy, logging e operation
Una policy ZTNA deve restare comprensibile anche in seguito. Per questo nomi, gruppi, condizioni ed eccezioni dovrebbero essere documentati. Il logging è obbligatorio, perché altrimenti non si vede se una policy è troppo ampia, se utenti vengono bloccati o se un accesso viene usato con frequenza inattesa.
Quando ZTNA ha senso
ZTNA è particolarmente adatto quando singole applicazioni devono essere raggiungibili in modo controllato. Non è un fine in sé e non è un sostituto automatico di ogni connessione.
Buoni casi d’uso
ZTNA di solito ha senso per:
- applicazioni web interne per collaboratori,
- accessi partner o fornitori,
- portali admin che non devono essere pubblici,
- RDP o SSH tramite percorsi controllati,
- applicazioni con gruppi utenti chiari,
- ambienti in cui l’accesso VPN è diventato troppo ampio,
- sostituzione graduale di vecchi modelli remote access.
Soprattutto per fornitori esterni, ZTNA è spesso più comodo di VPN. Non bisogna aprire un’intera rete, ma si può pubblicare una singola applicazione con una policy chiara.
Dove VPN resta adatto
VPN resta utile quando devono essere collegate reti intere, quando protocolli speciali non funzionano correttamente tramite ZTNA o quando serve un accesso di emergenza indipendente da servizi cloud. Collegamenti site-to-site, alcuni ambienti OT, applicazioni legacy e scenari admin complessi possono ancora richiedere VPN.
La domanda giusta quindi non è: “VPN o ZTNA?” Meglio chiedere: “Quale risorsa richiede quale percorso di accesso?”
Valutare i provider in modo neutrale
Le soluzioni ZTNA differiscono molto. Alcune sono molto buone per applicazioni browser-based, altre per accessi con client, altre come parte di una piattaforma SSE o SASE più ampia.
Criteri importanti di scelta
Prima della scelta del prodotto, chiarire:
- Quali applicazioni devono essere raggiungibili?
- Serve accesso browser-based, client o entrambi?
- Quale Identity Provider è già stabilito?
- I dispositivi devono essere controllati in base alla posture?
- Dove passa il percorso dati: sede propria, cloud del provider o entrambi?
- Come funzionano logs, export SIEM e audit?
- Esistono processi di emergenza e break-glass chiari?
- Quanto bene si integra la soluzione con firewall, EDR, MDM e DNS esistenti?
Cloudflare è spesso forte quando Access, Tunnel, DNS, web security e infrastruttura edge globale devono lavorare insieme. Sophos ZTNA si adatta spesso bene ad ambienti che usano già molto Sophos Central, Sophos Endpoint o Sophos Firewall. Non è una questione di fede, ma di architettura.
Non ogni Zero Trust è automaticamente migliore
Uno ZTNA mantenuto male è solo un rischio più moderno. Se i gruppi sono troppo ampi, vecchie eccezioni restano, nessuno legge i log o il controllo dispositivi esiste solo sulla carta, non nasce un ambiente Zero Trust forte.
Introdurre in ordine sensato
Una buona introduzione non inizia con il clic nel prodotto, ma con una piccola applicazione ben compresa.
- Inventariare applicazioni e ordinarle per rischio.
- Pulire gruppi utente e ruoli esterni.
- Stabilizzare Identity Provider e MFA.
- Scegliere un’applicazione pilota importante ma gestibile.
- Pianificare percorso dati, DNS, certificato e logging.
- Testare la policy con un piccolo gruppo utenti.
- Verificare log, raccogliere casi supporto e migliorare l’esperienza utente.
- Migrare altre applicazioni passo dopo passo.
- Ridurre accessi VPN solo quando ZTNA funziona in operation.
Per ambienti Sophos specifici, Configurare Sophos ZTNA: panoramica e sequenza è il passo successivo. Se il tema concreto è il gateway, aiuta Pianificare e creare Sophos ZTNA Gateway.
Errori tipici
Trattare ZTNA come semplice sostituto VPN
Se viene sostituito solo il tunnel, ma gruppi, applicazioni, dispositivi e log restano invariati, il guadagno di sicurezza è limitato. ZTNA dovrebbe essere pianificato per risorsa.
Migrare troppe applicazioni insieme
Un rollout big-bang grande è rischioso. Meglio un pilota con una vera applicazione, criteri di successo chiari e un percorso di fallback pulito.
Dimenticare l’accesso di emergenza
Identity Provider, DNS, servizio cloud o gateway possono fallire. Per gli admin serve un accesso break-glass documentato, fortemente protetto, usato raramente e verificato regolarmente.
Non gestire i log
ZTNA senza logging è difficile da supportare. Dovrebbe essere visibile quale utente accede a quale risorsa, quale policy si applica, perché un accesso è stato bloccato e se emergono pattern insoliti.
Checklist operativa
- Documentare applicazioni e owner.
- Mantenere i gruppi utenti piccoli e comprensibili.
- Imporre MFA per accessi critici.
- Usare attivamente il controllo dispositivi se la soluzione lo supporta bene.
- Verificare regolarmente le policy rispetto all’uso reale.
- Inviare log a SIEM o logging centrale se l’accesso è critico.
- Documentare e testare accesso break-glass.
- Rimuovere vecchi permessi VPN dopo migrazione riuscita.
- Dare agli accessi fornitori una data di scadenza o review.