Zero Trust: cosa significa davvero e come iniziare ad applicarlo

Un dipendente apre un allegato, digita le proprie credenziali su una pagina che sembra quella dell'azienda e in pochi minuti l'attaccante ha un accesso valido alla VPN. Da lì raggiunge i server di file, apre due cartelle condivise, trova un documento con le password dei servizi e si muove nel resto della rete. Nessuna regola del firewall è stata violata: il traffico era lecito, l'utente era autenticato, la connessione arrivava da un indirizzo interno.

Questo è lo scenario che Zero Trust prova a intercettare, ed è anche il motivo per cui il termine è sulla bocca di tutti e applicato in pochi posti. La definizione non è ambigua. È l'implementazione che spesso riguarda un'altra cosa.

Il fraintendimento da cui partire

Nella pratica "fare Zero Trust" viene tradotto in tre mosse: sostituire la VPN con un accesso remoto più moderno, aggiungere un secondo fattore di autenticazione, comprare un prodotto che ha "zero trust" sulla confezione. Sono tutti passi utili. Nessuno dei tre, da solo, sposta il modello da "fidarsi di chi è dentro la rete" a "verificare ogni richiesta, ogni volta".

La domanda che cambia non è da dove arrivi, ma cosa stai chiedendo, con quale dispositivo, per quale dato e in quali condizioni. È una domanda che nessun apparato di rete sa rispondere da solo, perché la risposta sta in più sistemi contemporaneamente.

Le fonti che contano

Il riferimento internazionale è il NIST SP 800-207 Zero Trust Architecture, pubblicato nell'agosto 2020. La sua definizione è la parte più citata e vale la pena leggerla senza scorciatoie: Zero Trust è un insieme di paradigmi che spostano le difese dal perimetro di rete statico verso utenti, asset e risorse; nessuna fiducia implicita viene concessa in base alla posizione in rete o alla proprietà dell'asset. Autenticazione e autorizzazione di soggetto e dispositivo sono funzioni distinte, eseguite prima che la sessione verso una risorsa venga stabilita.

Tre anni dopo, nel settembre 2023, NIST ha aggiunto il SP 800-207A per le applicazioni cloud-native e multi-cloud: qui il baricentro si sposta dalle identità delle persone alle identità delle applicazioni e dei servizi, con API gateway, sidecar proxy e infrastrutture di identità del servizio come SPIFFE. È il documento da leggere se il vostro perimetro è un cluster Kubernetes e non una sede.

Sul versante operativo, il CISA Zero Trust Maturity Model v2.0 organizza il percorso in cinque pilastri e tre capacità trasversali, e per ogni pilastro descrive quattro stadi: traditional, initial, advanced, optimal. Nasce per le agenzie federali statunitensi e CISA stesso lo presenta come una delle molte roadmap possibili. Va usato come griglia di valutazione, non come obbligo contrattuale.

Per capire come i vendor traducono il modello in prodotti, la documentazione di Microsoft Learn riassume tre principi divulgativi — verifica esplicita, privilegio minimo, assumi la compromissione — utili per spiegare il tema a un comitato direttivo, non sufficienti come specifica tecnica.

I sette principi di NIST, tradotti in pratica

Il documento NIST elenca sette assunzioni di base. Rileggerle con la conseguenza pratica accanto chiarisce perché il lavoro è più grosso di quanto sembri.

1. Ogni fonte di dati e ogni servizio di calcolo è una risorsa. L'inventario non è più quello dei server: dentro ci sono SaaS, repository, bucket, database gestiti, API interne.
2. Ogni comunicazione va protetta indipendentemente dalla posizione di rete. Il TLS anche tra segmenti interni non è un lusso; "siamo in VLAN" non è un controllo.
3. L'accesso a una singola risorsa è concesso per sessione. Un token emesso alle nove del mattino non deve valere fino a sera se nel frattempo il dispositivo smette di essere conforme.
4. La decisione si basa su policy dinamiche, che considerano identità del client, stato del dispositivo, applicazione richiesta, comportamento e contesto ambientale.
5. L'azienda misura in modo continuo integrità e postura di tutti gli asset, compresi quelli che non amministra direttamente.
6. Autenticazione e autorizzazione precedono ogni accesso, sempre, anche per chi arriva dalla rete interna.
7. Tutti i segnali raccolti servono a migliorare la postura: log, telemetria, traffico diventano input del ciclo decisionale.

Molti progetti si fermano al punto 4, comprando un motore di policy, senza aver fatto il punto 1 e il punto 5. Il risultato è un motore che decide su dati inesistenti: regole statiche con un nome nuovo.

L'architettura in tre componenti

NIST descrive l'architettura logica con tre funzioni che è utile saper nominare in una riunione.

Policy Engine: prende la decisione, confrontando la richiesta con le policy e con i segnali disponibili. Policy Administrator: esegue la decisione, emette o revoca il token e istruisce il punto di applicazione. Policy Enforcement Point: è il punto fisico o virtuale dove il traffico viene consentito o bloccato, che sia un proxy, un gateway o un agente sul dispositivo.

I primi due formano il piano di controllo, il terzo il piano dei dati. La frase da tenere a mente è semplice: senza un punto di applicazione la policy resta un documento, e senza segnali veri il punto di applicazione applica regole statiche.

I cinque pilastri letti come checklist

Il modello CISA divide il lavoro in identità, dispositivi, reti, applicazioni e workload, dati. Le tre capacità trasversali — visibilità e analytics, automazione e orchestrazione, governance — attraversano tutti i pilastri.

Per ognuno c'è una domanda di partenza onesta:

• Identità: quanti accessi privilegiati passano ancora da una password condivisa?
• Dispositivi: quanti endpoint accedono a dati aziendali senza che nessuno ne conosca lo stato di patch?
• Reti: il traffico est-ovest è ispezionato o semplicemente instradato?
• Applicazioni: ogni API ha un'autenticazione, o qualcuna si fida della rete locale?
• Dati: esiste una classificazione, o "sensibile" è un aggettivo che ognuno interpreta a modo suo?

Le risposte negative non sono un giudizio, sono la mappa del lavoro. Il punto debole più comune è però un altro: pilastri trattati come silos. Un accesso condizionale che non sa nulla della postura del dispositivo è un pilastro identità scollegato dal resto.

Cosa Zero Trust non è

Non è un prodotto. Non esiste un'appliance che, installata, renda l'azienda zero trust. Esistono componenti che coprono funzioni diverse: gestione delle identità, broker di accesso, microsegmentazione, proxy di uscita, piattaforme di postura.

Non è togliere la VPN. La VPN come trasporto cifrato va benissimo. Il problema è usarla come certificato di fiducia: una volta collegati, si è "dentro". Si può tenerla o sostituirla, purché l'accesso alle singole applicazioni passi da una decisione per sessione.

Non è solo MFA. L'autenticazione a più fattori è necessaria e non sufficiente: le notifiche push approvate per stanchezza sono un vettore documentato da anni. Il salto di qualità sono i fattori resistenti al phishing, come le chiavi FIDO2 e le passkey legate all'origine.

Non è un progetto con una data di fine. Ha una direzione e una misura di maturità. Chi lo pianifica come "progetto 2027 con chiusura a dicembre" si troverà con un cantiere aperto e nessun criterio per dire se ha funzionato.

Le prime quattro mosse, nei primi novanta giorni

Nessuna di queste richiede un budget a sei cifre.

1. Censimento. Prendete le ultime venti richieste di accesso arrivate al team e provate a rispondere, per ognuna, a due domande: quale dato tocca, chi ne è il proprietario. Se la risposta manca, quella è la prima lacuna, prima di qualsiasi strumento.

2. Identità come perimetro. Fattori resistenti al phishing sui ruoli amministrativi e sui dati critici, eliminazione delle credenziali condivise, censimento degli account di servizio, separazione netta tra account di amministrazione e account di lavoro quotidiano.

3. Postura dei dispositivi con conseguenze. Scegliete tre criteri verificabili — disco cifrato, livello di patch, protezione endpoint attiva — e collegateci una decisione: dispositivo non conforme, accesso negato ai dati sensibili. Un avviso che nessuno legge non è un controllo.

4. Un punto di applicazione e i log. Concentrate il controllo in pochi punti di enforcement (il gateway di accesso remoto, il proxy in uscita, l'ingress del cluster) e assicuratevi che ogni decisione sia registrata con il motivo. Una decisione senza log è indifendibile in un audit.

A queste va aggiunta la parte che nessuno compra: la governance delle policy. Chi le approva, con quale procedura, come si gestisce un'eccezione e soprattutto quando l'eccezione scade. Senza questa, ogni deroga temporanea diventa permanente in tre mesi.

Come si misura

Quattro indicatori bastano per capire se il modello sta entrando nella pratica o è rimasto in slide.

• Percentuale di accessi alle risorse critiche che passano da un punto di applicazione con valutazione di contesto, non solo di credenziali.
• Percentuale di account con un fattore resistente al phishing, e quanti sono gli esclusi con un motivo scritto.
• Tempo medio per revocare un accesso dopo la segnalazione. Se si misura in giorni, l'ipotesi "assumi la compromissione" resta teorica.
• Copertura dell'inventario: quante risorse critiche hanno un proprietario e una policy dichiarata.

Sono tutti numeri che non si comprano. È il motivo per cui i progetti Zero Trust più solidi partono dal censimento e non dal preventivo.

L'anello debole: OT, fornitori e sistemi legacy

Due categorie restano fuori dai progetti e sono spesso quelle che pesano di più. La prima sono i sistemi OT e IoT, dove gli agenti non si installano: lì l'approccio è di mediazione, con gateway intermediari, monitoraggio passivo del traffico e separazione delle reti. Ne abbiamo scritto di recente a proposito della catena del freddo presa di mira in Francia e in Sicilia: controllori raggiungibili da Internet, accessi remoti dei manutentori senza secondo fattore.

La seconda categoria sono i fornitori. Un accesso remoto permanente, senza scadenza e senza registrazione delle sessioni, è un punto di applicazione mancante: la policy esiste, ma nessuno la esegue. La segmentazione di rete riduce il danno, ma da sola non sostituisce la verifica per sessione. E quando l'incidente accade, conta anche quanto rapidamente si riesce a contenere: il piano di incident response è la rete di sicurezza del modello, non il suo contrario.

Le competenze che servono

Zero Trust chiede profili che in Italia sono ancora rari: chi sa scrivere una policy di accesso condizionale, chi conosce i protocolli di identità, chi progetta segmentazione senza rompere l'operatività, chi sa leggere i log per verificare che le decisioni siano state prese davvero. Nessuna certificazione sostituisce il censimento, ma un linguaggio comune tra rete, identità e sicurezza rende i progetti più corti e meno conflittuali.

Se il team deve partire da basi solide su identità, accessi e risposta agli incidenti, nel catalogo dei corsi EC-Council trovate i percorsi dedicati alla sicurezza difensiva e offensiva, con laboratori su scenari reali.