💻 Tecnologia

Zero Trust e accesso remoto: cosa cambia rispetto alla VPN

Il modello Zero Trust sostituisce il perimetro di rete con la verifica continua di identita e dispositivo. Come funziona in pratica e quando ha senso per una PMI.

Redazione Velix15 settembre 20267 min di lettura
💻

La VPN aziendale classica applica un modello di sicurezza perimetrale: chi supera l'autenticazione entra nella LAN e da quel momento è trattato come un client interno. Il problema è che l'autenticazione avviene una volta sola, all'inizio della sessione, e concede accesso a livello di rete — non a livello di singola applicazione.

Zero Trust ribalta il presupposto: nessun utente, dispositivo o flusso è affidabile per posizione di rete. Ogni richiesta viene valutata di nuovo, contro identità, stato del dispositivo e contesto.

Il problema del movimento laterale

Con una VPN site-to-client, un portatile compromesso che si collega da casa ottiene un IP della rete interna. Da lì può raggiungere il NAS, il gestionale, il server di backup, la centralina di videosorveglianza — tutto ciò che il firewall interno non segmenta esplicitamente. Nella maggior parte delle PMI la segmentazione interna è minima o assente.

Questo è il movimento laterale: l'attaccante non punta direttamente al dato che gli interessa, ma a un endpoint debole da cui muoversi verso l'infrastruttura. La VPN, pensata per estendere la fiducia, estende anche la superficie d'attacco.

I cinque pilastri del modello

L'architettura di riferimento NIST SP 800-207 si articola su questi principi:

  • Verifica esplicita — autenticazione e autorizzazione su ogni richiesta, non solo all'apertura della sessione
  • Privilegio minimo — accesso alla singola applicazione o risorsa, non alla subnet
  • Assume breach — progettare come se l'attaccante fosse già dentro: segmentazione, cifratura end-to-end, logging esteso
  • Postura del dispositivo — sistema operativo aggiornato, disco cifrato, antimalware attivo come condizione d'accesso
  • Contesto dinamico — geolocalizzazione, orario, comportamento anomalo entrano nella decisione

Il componente centrale è il policy engine: valuta ogni richiesta e istruisce un enforcement point (proxy, broker, agent) a consentire o negare. L'applicazione non è mai esposta direttamente su Internet.

Cosa cambia concretamente

AspettoVPN tradizionaleZero Trust
Unità di accessoSubnet / reteSingola applicazione
Momento della verificaAll'inizio della sessioneSu ogni richiesta
Esposizione serviziConcentratore VPN pubblicoNessuna porta in ingresso
Stato dispositivoNon valutatoCondizione d'accesso
Movimento lateralePossibileBloccato per costruzione
LogConnessione aperta/chiusaPer risorsa e per richiesta

Un dettaglio operativo importante: molte soluzioni Zero Trust usano connettori in uscita. L'agent installato accanto all'applicazione apre una connessione verso il broker cloud, quindi non serve alcuna porta aperta in ingresso sul firewall né un IP pubblico statico. Per chi lavora dietro CGNAT è un vantaggio concreto.

Percorso realistico per una PMI

Zero Trust non si compra come prodotto: è un'architettura che si raggiunge per passi. Un ordine sensato:

  1. Identità centralizzata con MFA. È il prerequisito. Senza un IdP unico (Entra ID, Google Workspace, Okta, Keycloak self-hosted) non c'è policy engine possibile. MFA su tutti gli account, senza eccezioni per gli amministratori
  2. Inventario di applicazioni e dati. Sapere cosa esiste, dove gira e chi deve accedervi. Questa fase è noiosa e spesso saltata, ed è il motivo principale dei progetti falliti
  3. Segmentazione di rete. VLAN separate per utenti, server, IoT, videosorveglianza, ospiti, con regole inter-VLAN esplicite. Vale anche restando su VPN
  4. Accesso applicativo per le prime risorse. Pubblica gestionale, wiki interna o pannelli di amministrazione dietro un broker ZTNA invece che via VPN. Convivenza VPN/ZTNA durante la migrazione è normale
  5. Postura dispositivo. Integra l'MDM o l'EDR come segnale nella policy: dispositivo non conforme, accesso negato o limitato
  6. Monitoraggio e revisione. Log centralizzati, alert su accessi anomali, revisione periodica dei permessi

Quando la VPN resta la scelta giusta

Zero Trust non è sempre la risposta:

  • Collegamenti site-to-site fra sedi: un tunnel IPsec o WireGuard fra due router è più semplice, più veloce e non ha senso sostituirlo
  • Protocolli non HTTP legacy: molti broker ZTNA gestiscono bene web e SSH/RDP, meno bene applicativi client-server con porte dinamiche
  • Accesso amministrativo agli apparati di rete: un jump host su VLAN di management raggiungibile via VPN resta una soluzione solida
  • Microimprese con 3-5 utenti e un solo server: il costo di gestione del modello supera il beneficio; meglio investire in MFA, backup testati e segmentazione base

Errori da evitare

  • Chiamare Zero Trust una VPN con MFA. L'MFA è un prerequisito, non il modello: se dopo l'autenticazione l'utente ha accesso a livello di rete, il modello è ancora perimetrale
  • Migrare tutto insieme. Il big bang genera blocchi operativi e ritorno alla VPN in emergenza
  • Trascurare la disponibilità del broker. Se il policy engine è irraggiungibile, nessuno lavora: valuta il comportamento in fail-open/fail-closed e la ridondanza della connettività
  • Ignorare l'accesso di fornitori e consulenti. È spesso il primo caso d'uso con il ritorno più alto: accesso a una sola applicazione, a tempo, tracciato

Il punto di partenza infrastrutturale rimane la connettività: link ridondati e latenza stabile, perché in questo modello ogni richiesta passa dal broker.

Vuoi portare Velix a casa tua?

Verifica la copertura FTTH al tuo indirizzo in 30 secondi. Gratis, senza impegno.

Verifica copertura →