Zero Trust e VPN nel 2026: come integrare ZTNA, microperimetro e accesso contestuale

Perché Zero Trust, se abbiamo già la VPN

VPN classica: a cosa serve ancora

Diciamolo chiaramente: la VPN aziendale non è sparita. Per decenni ha garantito l'accesso remoto, cifrando tutto e offrendo una configurazione semplice e comprensibile — l’utente si collega, entra nella rete, lavora. Semplice ed efficace. Ma è davvero così semplice? Quando il perimetro era unico e in ufficio, la VPN bastava. Nel 2026 invece abbiamo cloud, SaaS, data center ibridi, appaltatori e dispositivi BYOD. Senza contare team distribuiti e mobilità intensa. In questo scenario il classico accesso full tunnel dà troppo: offre visibilità di rete superflua e apre la strada a risorse non necessarie. Piace molto più agli attaccanti che a noi.

Tuttavia, non possiamo sbarazzarci della VPN. Funziona ancora benissimo come livello di trasporto affidabile, soprattutto dove il traffico deve seguire percorsi prevedibili: filiali–data center, centro dati–centro dati, canali di backup, integrazioni ad alto carico. Un altro motivo: dispositivi e servizi che supportano solo VPN, come IPsec tra gateway di rete o applicazioni legacy senza moduli di accesso moderni. Certo, amiamo WireGuard e TLS 1.3 sopra QUIC, ma il mondo reale è ibrido.

La buona notizia: VPN e Zero Trust non si escludono. La VPN smette di essere la "chiave universale" e diventa parte del processo di accesso. Non più "connettiti e vai ovunque", ma "connettiti, fornisci contesto e ottieni accesso limitato alle app specifiche". Questa è l’evoluzione: meno magia, più controllo e buon senso.

Principi di Zero Trust così come sono

Zero Trust non significa diffidare delle persone, ma delle sessioni e dell’ambiente. La regola è semplice: non fidarti mai di default, verifica sempre, limita l’accesso al minimo necessario nel momento preciso. Non è uno slogan, ma un insieme di pratiche. In pratica significa che noi:

• Verifichiamo costantemente l’identità di utente e servizio, non solo all’accesso.
• Consideriamo il contesto: dispositivo, geolocalizzazione, punteggio di rischio, ora del giorno, sensibilità della risorsa.
• Applichiamo microsegmentazione e microperimetri — la risorsa la vedono solo chi ne ha bisogno.
• Cifriamo tutto, tracciamo tutto, automatizziamo la risposta alle anomalie.

A volte sembra che Zero Trust sia una lunga lista di prodotti. Non è così. È un insieme di processi e policy di accesso, implementati con tecnologie: da directory e IdP a proxy applicativi, token e certificati a breve durata. Quando smettiamo di confondere mezzi e obiettivi, la strategia si fa chiara e i progetti realizzabili.

ZTNA, evoluzione dell’accesso remoto

ZTNA — Zero Trust Network Access — rappresenta lo spostamento da «accesso alla rete» ad «accesso all’applicazione». L’utente non vede subnet né porte. Vede un catalogo di app, ognuna col proprio gateway L7, le sue policy e verifiche. La connessione è più simile a consegnare una chiave elettronica a una porta, non la mappa di tutto l’edificio. Nel 2026 ZTNA convive come parte di piattaforme SSE/SASE o come contorno indipendente con agenti e connettori leggeri per segmenti privati. La VPN in questo schema è il mero canale protetto tra agente, punto di presenza e app. E qui avviene l’armonia: il caro vecchio tunnel funziona, ma le regole di accesso le decide Zero Trust, non gli IP.

Ruolo della VPN nell'architettura Zero Trust nel 2026

VPN come livello di trasporto, non come pass d’ingresso

La svolta: la VPN non è più "pass d’ingresso" alla rete aziendale. Con Zero Trust è uno strato di trasporto — sicuro, ottimizzato, gestito. Serve un tunnel? WireGuard o IPsec fanno il loro lavoro. Serve il percorso internet con latenza minima? Si aggiunge il routing tramite PoP SSE. Importante non è il cosa, ma il come: sopra il tunnel viaggia la richiesta verso un’app specifica, ulteriormente verificata dal piano di controllo. L’utente non ha una mappa di rete: ha una sessione su un servizio. Questo ricorda un service mesh, ma per utenti umani e integrazioni esterne.

Così si elimina il rischio principale: il movimento laterale. Se il tunnel non mostra tutta la rete, l’exploit non ha dove andare. Si scontra col microperimetro che lascia passare solo traffico autorizzato e verificato. Riduciamo così il raggio d’azione delle intrusioni e abbattiamo i costi degli incidenti. E il bello è che questa funzione VPN è compatibile con la rete esistente. Non serve stravolgere ciò che funziona. Riutilizziamo la “muscolatura” e aggiorniamo il “sistema nervoso” dell’accesso.

Cifratura, performance e resilienza: TLS 1.3, QUIC, crittografia ibrida

Nel 2026 la cifratura è ingegneria, non un opzione. Lo standard minimo è TLS 1.3. Sempre più tunnel girano su QUIC, che si comporta meglio su Internet reale: meno latenza all’avvio, funziona bene anche su canali instabili, resistente alla perdita di pacchetti. Molti vendor offrono modalità "UDP-first" e raffinati fallback TCP. In più, schemi ibridi con algoritmi post-quantistici. Chi guarda al futuro adotta handshake ibridi: curve ellittiche + Kyber per lo scambio chiavi. Non è moda ma pragmatismo: chiudiamo il rischio “registrato ora, decryptato dopo”.

Le performance non sono un’astrazione. Nel 2026 oltre il 60% delle aziende ritiene che la latenza nell’accesso alle app private sia un problema di business. Serve una soluzione globale: PoP vicino all’utente, routing intelligente, compressione e trasmissione solo del traffico necessario. Qui la VPN come trasporto pesa ancora di più: è fondamentale che il tunnel mantenga velocità e integrità MTU, mentre tutta la logica accessi e contestualizzazione gira sopra.

Integrazioni profonde: da IdP a EDR

Zero Trust si basa sulle connessioni. La VPN come trasporto diventa pratica solo quando integrata con: IdP e MFA per autenticazioni primarie e multifattore, EDR per valutare la postura dei device, MDM per compliance, SIEM per correlare eventi, e policy ABAC. L’agente che apre il tunnel raccoglie telemetria su processi, patch e attività sospette. Il piano di controllo vede tutto e decide: dare accesso, richiedere un fattore aggiuntivo, o chiudere la sessione. Sulla carta sembra complesso, ma è una "cliccata" in una piattaforma moderna. La sfida è impostare i segnali giusti senza perdersi nel rumore.

Microperimetro e microsegmentazione: protezione mirata

Cosa è il microperimetro nella pratica

Il microperimetro non è una nuova recinzione attorno al data center. È un confine piccolo, quasi tascabile, intorno a ogni applicazione, API o anche singolo metodo. Immagina una stanza d’ufficio con una serratura e un permesso diverso per ogni porta. Prima avevamo una porta principale per tutto l’edificio; ora serrature e permessi su ogni porta, e persino sulle scrivanie. Tecnologicamente si implementa con proxy e broker a livello applicativo, che accettano traffico solo da agenti verificati e token a breve durata. Qualsiasi tentativo di aggirare è bloccato di default. Così non contiamo più sulla "vicinanza di rete" come fattore di fiducia. La prossimità non significa accesso.

Microperimetro non vuol dire regole firewall infinite scritte a mano. Nel 2026 descriviamo le policy con astrazioni: app, ruolo, sensibilità, contesto. Poi il sistema genera token, namespace, account di servizio, regole di comunicazione tra servizi. È più comodo e sicuro. Gli errori diminuiscono, i cambiamenti sono più veloci e trasparenti.

Segmenti orientati a rete e a identità

La microsegmentazione è di due tipi, ideali se combinate. La segmentazione di rete taglia l’accesso tra workload tramite subnet e tag a livello di ipervisore o cloud. La logica è semplice: se la subnet degli analisti non deve parlare con quella CRM, blocchiamo tutto il traffico est-ovest e permettiamo solo i flussi necessari. La segmentazione identitaria invece assegna l’accesso non a IP o porta, ma a chi sei: ruolo, gruppo, attributi o segnali posturali device. La policy ideale sembra una frase viva: «Il ruolo Analista del gruppo DWH può connettersi a Reports del registro Prod durante l’orario lavorativo se il dispositivo è conforme e la richiesta arriva da Paesi a basso rischio».

Entrambi i tipi sono importanti. La segmentazione di rete protegge da attacchi grossolani senza modificare le app. Quella identitaria dà flessibilità, riducendo la necessità di ACL infinite. Insieme costruiscono “doppi muri” difficili da penetrare per gli attaccanti e facili da gestire grazie ad automazione e template centralizzati.

Pattern d’adozione: dal jump host al proxy applicativo

Storicamente usavamo jump host: un server dove ci si connette via SSH o RDP e da lì si accede ai sistemi. In Zero Trust è un retaggio: crea un solo punto per il rischio. Oggi si preferisce un broker applicativo. L’utente non vede affatto la rete. Clicca l’app nel catalogo, l’agente stabilisce mTLS col broker vicino, il piano di controllo emette un token a breve durata e il broker connette silenziosamente al servizio. Sembra magia, ma è lavoro normale per proxy e connettori in modalità private link. In più, applichiamo politiche DLP e filtro contenuti al flusso, senza dipendere da TCP o HTTP.

Accesso contestuale: chi sei, da dove, con cosa

Identità e autenticazione continua

La verifica statica all’accesso non basta più. Viviamo in validazione continua: ogni N minuti, al cambio di rete, posizione o livello rischio — rivalutazione e talvolta MFA in-sessione. Buona pratica 2026: FIDO2 e passkey come secondo fattore di default, obbligatorio negli ambienti critici. Perché? Il phishing non si ferma, e password o codici OTP continuano a trapelare. Zero Trust ama la crittografia forte senza password e il legame fattore–dispositivo. L’utente può brontolare, ma se il secondo fattore scatta solo se serve, tutti sono soddisfatti. E la sessione è breve: token durano minuti, non ore. Senza rigida scadenza, la sicurezza diventa solo speranza.

Postura dispositivo: EDR, MDM e segnali di compliance

Il contesto non è solo "chi", ma anche "con cosa". Il device non è solo hardware ma un insieme di indicatori: versione OS, cifratura disco, antivirus attivo, EDR, schermo bloccato, root o jailbreak assenti, patch recenti su kernel e browser. L’agente ZTNA legge questi segnali direttamente o via integrazione con MDM/EDR. La policy può essere: «Se EDR degradata, niente accesso a CRM e finanza; altrimenti sola lettura». Sì, diventiamo più severi, ma è protezione, non burocrazia. Un dispositivo compromesso è un invito al disastro. La postura cambia, la policy reagisce. No approvazioni manuali lente — automatismo e regole chiare.

Punteggio di rischio e policy dinamiche

Nel 2026 tutti parlano di “rischio” e “AI in sicurezza”. Senza il hype: il risk scoring pesa segnali come posizione anomala, dispositivo nuovo, ore di attività insolite, app inusuali. Sommiamo segnali e otteniamo un punteggio. Sotto soglia, si procede come al solito. Sopra, si richiede factor aggiuntivo, si restringono permessi e si intensifica il monitoraggio. Utile associare rischio a sensibilità risorsa. Mille anomalie su wiki sono rumore; un’anomalia nei pagamenti è un campanello rosso. Progettiamo policy chiare per auditor e tecnici: se X e Y allora Z. Inoltre, logghiamo la motivazione delle decisioni. Così indagini e correzioni sono più rapide.

Come combinare la VPN tradizionale con ZTNA senza dolori

Avvio parallelo: "procediamo e modifichiamo"

Metodo meno stressante: lanciare ZTNA fianco a fianco con la VPN attuale. Prima si scelgono 2-3 app con utenti noti ed effetti misurabili, es. CRM interno, dashboard, pannello marketing. Si installano connettori vicino alle app, si configura agente e catalogo, si attivano policy minime. Si fa lavorare un gruppo pilota 2-4 settimane, si raccolgono feedback e si aggiustano dettagli. Poi si scala per cluster: impiegati d’ufficio, analisti, sviluppatori, appaltatori. Ogni passo aumenta il traffico su ZTNA e alleggerisce la VPN vecchia. Alla fine la VPN rimane per casi specifici: accesso terminal, connettività L3 tra reti, ripristino di emergenza. Niente scossoni.

Modalità tunnel: full tunnel, split e per-app

Preferiamo soluzioni semplici, ma serve flessibilità. Dove servono regole rigide e audit completo, manteniamo full tunnel. Per SaaS e media serve split. Per app critiche portiamo la connessione su canale per-app via broker ZTNA. Tutti e tre i metodi convivono su un dispositivo, gestiti da policy. Per esempio, traffico ERP passa solo via broker con controlli extra; posta aziendale via cloud SWG; siti pubblici diretti. La policy decide, l’utente non deve capire tutto. Fondamentale che sia documentato e trasparente in console di sicurezza.

Compatibilità inversa e "ponti temporanei"

Ci sarà sempre qualche app vecchia che non supporta proxy o agenti moderni. Non è un problema. Costruiamo un ponte temporaneo: manteniamo VPN per quel segmento e blocchiamo l’accesso via ZTNA con regole rigide. Aggiungiamo policy network per traffico est–ovest per evitare vulnerabilità. Parallelamente pianifichiamo modernizzazione: container, proxy sidecar, OIDC. Quando l’app è pronta, la spostiamo su catalogo ZTNA e chiudiamo il percorso vecchio. La cosa importante è non forzare rotture, ma avanzare per passi, senza lasciare spazio al caos.

Architetture: SDP, SSE, SASE e gestione centrale

SDP vs SSE e SASE: differenze

Software-Defined Perimeter (SDP) è un concetto dove l'accesso a un'app è nascosto fino all’autenticazione e il perimetro è programmabile. SSE — Security Service Edge — si concentra sui servizi cloud di sicurezza: SWG, CASB, ZTNA, FWaaS. SASE unisce SSE con funzionalità di rete: SD-WAN, ottimizzazione e routing globale via PoP. In pratica la scelta dipende da scala e maturità. Per accessi privati mirati e protezione SaaS, SSE è sufficiente. Per decine di filiali e data center ibridi, SASE migliora performance e gestione. Se si preferisce modularità con rete perfetta, SDP puro con funzioni minime può bastare. La VPN si integra in tutti gli scenari, ma in SASE è più strettamente legata a SD-WAN e si sposta dinamicamente per ottimizzare i percorsi.

Piano di controllo e piano dati: dove collocarli

Il piano di controllo è il cervello, prende decisioni di accesso. Il piano dati è il muscolo, trasporta il traffico. Nel 2026 la maggior parte sposta il piano di controllo nel cloud del provider, per scalare e essere vicino all’utente. Ci sono settori con regolamentazioni che richiedono controllo locale; in questi casi si sceglie un modello ibrido: controllo distribuito con parte critica on-premise. Il piano dati è flessibile: PoP in cloud, nodi privati in data center, connettori vicino alle app. Importante curare latenza: il controllo deve decidere rapidamente e cache locale evita cadute di accesso in caso di momentanei disservizi.

Criteri di scelta nel 2026

Su cosa valutiamo una piattaforma? Copertura PoP nelle tue sedi, maturità agente, facilità di gestione policy, integrazione con IdP, EDR, SIEM, supporto alla crittografia ibrida, gestione aggiornamenti client. Fondamentale trasparenza del billing e limiti. Poi scenari offline e accesso di backup per amministratori. Meglio scegliere non lo stack più trendy, ma quello che la tua squadra sa gestire. Verifica che il vendor supporti roadmap 18-24 mesi: ZTNA evolve rapidamente e restare su vecchie versioni è un rischio.

Guida pratica all’implementazione: dall’idea alla policy

Roadmap di 90 giorni

Giorni 1-15: inventario di applicazioni, utenti e rischi. Identifichiamo servizi critici, appaltatori, admin. Costruiamo mappa dipendenze e segmentazione preliminare. Giorni 16-30: scegliamo piattaforma, configuriamo IdP base e MFA, definiamo telemetria minima device. Giorni 31-45: lanciamo pilota su 2-3 app, scriviamo prime policy — semplice: chi, quando e da dove. Raccogliamo metriche di latenza e accessi riusciti. Giorni 46-60: estendiamo al 20-30% utenti, attiviamo DLP per risorse sensibili. Giorni 61-75: spostiamo servizi “selvaggi” su catalogo ZTNA, togliamo appaltatori dalla VPN condivisa, formiamo supporto. Giorni 76-90: stabilizzazione finale, definizione SLO, attivazione modalità emergenza per admin, audit log, lancio standard ciclo vita policy.

Misuriamo: tempo medio di connessione, percentuale ri-autenticazioni, quota blocchi per rischio, numero ticket supporto. Se i grafici sono regolari e prevedibili, sei sulla strada giusta. Altrimenti individua i colli di bottiglia: agente, PoP, policy.

ABAC e policy espressa

La policy di accesso Zero Trust è un linguaggio di decisione. Attributi soggetto: ruolo, dipartimento, geografia, livello fiducia. Attributi oggetto: tipo app, sensibilità, ambiente (Prod, Dev), ownership. Attributi ambiente: fuso orario, reputazione IP, postura device, punteggio rischio. Li esprimiamo in forma dichiarativa: «Allow if subject.role in Finance and device.posture = Compliant and app.tier = Sensitive and risk.score < Medium». Niente fanatismi. Più corta è la regola, più facile verificarla. Nel 2026 editor visuali e template policy sono popolari. Si parte da un modello "Appaltatore a strumento interno" e si personalizzano un paio di campi. Facile e ripetibile.

Set tecnologico minimo

Per partire ti serve: IdP con supporto OIDC/SAML, MFA con FIDO2, agente ZTNA, connettori per segmenti privati, logging su SIEM, integrazione EDR o almeno verifica basica device. Extra utili: SWG per traffico web, CASB per SaaS, DLP per dati sensibili, secret manager, gestione certificati per mTLS tra componenti. E ovviamente VPN come trasporto quando servito. Non tentare di avere tutto subito. Meglio piccole vittorie che un progetto grandioso sempre "in corso".

Sicurezza, visibilità e compliance

Log, telemetria e investigazione

Se non vedi, non controlli. Nel Zero Trust logghiamo non solo "chi ha acceduto" ma anche "perché il sistema ha permesso o negato". Conserviamo contesto: postura device, fattore autenticazione, percorso, PoP, sensibilità app, punteggio rischio. Questi dati non devono languire. Costruiamo dashboard: chi incontra più rischi, policy più bloccanti, dove ci sono ritardi. Dopo un mese avrai mappe dei colli di bottiglia e lista di miglioramenti. E sì, i log devono essere normalizzati e con schemi stabili. L’analista vuole capire un evento in 10 secondi, non saltare tra cinque sistemi.

DLP, SWG e CASB attorno a ZTNA

L’accesso contestuale non è solo entrare e uscire, ma gestire i dati lungo il percorso. SWG filtra il traffico web, CASB monitora il SaaS, DLP evita la fuga di dati sensibili come passaporti o numeri di carte su email o chat. Combinato con ZTNA possiamo applicare regole solo quando l’utente lavora con contenuti delicati. Nel fintech vietiamo copia da app interne, ma consentiamo download solo su dispositivi aziendali con etichettatura. Nell’industria blocchiamo l’export di progetti fuori dalla rete aziendale. Dettagli cambiano, ma il principio è uno: le regole vicino ai dati, non al perimetro.

Post-quantum e regolatori

Nessuno vuole essere l’ultimo. Nel 2026 i regolatori menzionano prudenzialmente la crittografia ibrida nei settori critici. Non significa stravolgere tutto domani, ma è la direzione. Buona prassi: abilitare accordi ibridi per canali interni tra PoP e broker e per sessioni admin. Poi un piano di inventario crittografia con algoritmi, proprietari e revisioni. Se l’audit chiede rischi quantistici, fornisci risposte concrete con diagrammi e checklist, non solo futuro.

Economia e gestione: non solo licenze

TCO e ROI reali

Quanto costa Zero Trust? Risposta sbagliata: «subscription + integrazione». Corretta: TCO. Licenze, agenti, tempo IT e IAM, traffico PoP, storage log, formazione supporto, rischi progetto. Risparmio: meno downtime, incidenti e investigazioni, meno magia amministratori, accesso più rapido per appaltatori. Studi seri dicono: spostare il 60% delle app private su ZTNA riduce i movimenti laterali del 70-80% e dimezza i tempi di indagine. Su due anni fanno una differenza tangibile, non solo parole.

Performance e esperienza utente

L’utente non è astratto. Se l’accesso è lento, cerca soluzioni alternative. Anticipiamo: scegliamo PoP vicini, attiviamo QUIC, ottimizziamo DNS, facciamo pre-autenticazione per caricare subito il catalogo. Comunichiamo messaggi chiari: non “Errore 403” ma “Aggiorna agente o attiva cifratura disco”. Sembra banale, ma risolve metà dei ticket. E testiamo sempre su dispositivi reali, non solo in laboratorio. A volte un vecchio driver VPN è più frustrante di un trimestre di roadmap.

Risorse, processi e SLO

Zero Trust non decolla senza persone. Serve un owner policy in business, che definisca chi ha accesso a cosa. Serve un engineer che conosca rete, IdP e log. Serve processo cambi policy: richiesta, valutazione, test, deploy, rollback. Introduciamo SLO: disponibilità broker, % accessi riusciti, tempo medio connessione, ripetizioni MFA. Se metriche sono pubbliche in IT spariscono litigi. Rimangono solo numeri. Come si dice, “ciò che misuriamo, miglioriamo”.

Analisi casi: dove VPN e Zero Trust funzionano meglio insieme

Fintech: accesso al core dove ogni secondo conta

Banca con 10 mila dipendenti. Prima: due grandi concentratori VPN, picchi di lunedì, lamentano latenza e problemi con appaltatori. Nuovo schema: broker ZTNA in due cloud, agenti su laptop aziendali, FIDO2 rigoroso. VPN rimane per integrazioni backend partner e connettività L3 data center. L’utente vede catalogo con 25 app. Accesso al core pagamenti solo da device aziendali, postura “compliant”, orario lavorativo, rischio sopra la media blocca con alert SOC. Risultato: latenza media scesa del 35%, zero movimenti laterali in sei mesi, tempo accesso appaltatori da tre giorni a quattro ore. Piccolo dettaglio, grande sollievo business.

Produzione e OT: dove non si può sbagliare né aspettare

Stabilimento con IT e OT. Eredità complessa: SCADA, Windows vecchi, canali lenti a siti remoti. Spostamento totale a architettura “alla moda” non è realistico. Soluzione ibrida: IT usa ZTNA per app di supporto ufficio, ERP e pannelli ingegneristici. OT mantiene site-to-site VPN con filtro stretto e whitelist comandi. Accesso a controllori sensibili solo tramite jump proxy ZTNA con registrazione sessione e approvazione finestre manutenzione. Rischi calati, produzione che gira. A volte conviene stringere i rubinetti, non cambiare tutto il sistema.

Online retail: molti SaaS, appaltatori e picchi

Grande e-commerce vive di picchi. Black Friday, traffico alle stelle. VPN vecchia alternava canale vuoto a sovraccarico. Passaggio a SSE con PoP globali, ZTNA per servizi privati, CASB e SWG per tutto il web. Appaltatori hanno accesso a solo due app con token temporanei e device controllato su standard base. Risultato: traffico assorbe picchi senza intervento rete, licenze trasparenti. Se spendi, investi solo su PoP vicino a clienti e team, non su enormi box in headquarter.

Errori comuni e come evitarli

Trappole e falsi miti

Primo errore: aspettarsi che ZTNA faccia inventario al posto tuo. Aiuta, ma non sa cosa nascondi. Secondo: policy “tutto in uno”. Non funziona così. Moduliamo. Terzo: ignorare esperienza utente. Catalogo lento equivale a sconfitta prima di partire. Quarto: dimenticare accesso emergenza. Se IdP cade, gli admin devono entrare con canali alternativi, altrimenti sei prigioniero della sicurezza. Quinto: attivare subito tutte le funzioni. Meglio una a una, ma fatte bene.

Checklist prima di scalare

• Tutte app critiche hanno owner e policy definite.
• Agenti aggiornati in modo controllato, non casuale.
• PoP coprono regioni chiave, latenza misurata.
• Log normalizzati, alert chiari, senza false allarmi a valanga.
• Rollback policy testato su gruppo pilota.
• Accesso emergenza admin documentato e collaudato.

Piano rollback e modalità degradata

Ci piace sperare ma pianifichiamo errori. Se il piano controllo non risponde, le policy sono cache in periferia per N minuti. Se agente si rompe dopo update, c’è un canale "stabile" con fallback automatico. Se il PoP è sovraccarico, il routing sposta client su PoP vicino e puoi chiudere manualmente nuove sessioni sul nodo affollato. E sì, a volte estendiamo temporaneamente accesso VPN per superare picchi. Normale. Essenziale che utenti non percepiscano caos e che il team sappia cosa succede e “come spegnerlo”.

Futuro: cosa aspettarsi nel 2026-2027

Più app, meno reti

Tendenza chiara: spostiamo policy da oggetti rete ad applicazioni e dati. Tutto ciò che si può descrivere a livello di servizi e API lo descriviamo lì. VPN resta layer di trasporto e qualche backup per casi insoliti. È giusto così: meccanismi critici e collaudati non spariscono, ma svolgono il loro ruolo.

Edge, IoT e service mesh per le persone

Edge computing non è solo CDN. Il livello broker accesso si avvicina a utenti e dispositivi. Dispositivi IoT hanno microperimetri dedicati e admin usano schemi simili ad un mesh, dove la persona è identificata come servizio e la sessione segue regole identiche a quelle della comunicazione tra servizi interni. Non tracciamo più frontiere tra persone e servizi nella sicurezza: abbiamo un unico flusso di fiducia.

Automazione e policy as code

La policy diventa codice. PR, review, test, deploy, rollback. Questo riduce errori umani. L’AI aiuta ma non sostituisce: suggerisce se una nuova policy confligge con esistenti e genera blocchi a catena. La decisione però è nostra. E questo è fantastico: la macchina conta, l’uomo gestisce il rischio.

FAQ: breve e chiaro

Bisogna eliminare completamente la VPN per abbracciare Zero Trust?

No. La VPN è ottima come trasporto e backup. Serve solo togliere il suo ruolo di goto per tutta la rete e spostare app critiche su ZTNA. Gradualmente si lascia la VPN per connettività L3 o protocolli specifici.

Quanto tempo serve per passare a ZTNA?

Un pilota con 2-3 app si avvia in 4-6 settimane. La scalabilità alle principali user group richiede 3-6 mesi, a seconda di integrazioni e maturità processi. Non correre dietro a un “ideale” da zero. Meglio costante e iterativo.

Come gestire le app legacy?

Lascia ponti temporanei: accesso VPN ristretto con regole rigorose e audit. Parallelamente pianifica adattamenti: connettori, proxy, OIDC. Quando l’app è pronta, la sposti su catalogo ZTNA e chiudi il percorso vecchio.

Servono piattaforme SASE costose?

Non sempre. Se hai poche filiali e traffico verso SaaS e qualche servizio privato, bastano SSE e ZTNA. SASE si giustifica con rete globale PoP, SD-WAN e performance gestite tra filiali e data center.

Come misurare il successo?

SLO: disponibilità broker, tempo medio connessione, % accessi riusciti, MFA ripetute, incidenti movimento laterale, tempi indagine. Più NPS utenti. I numeri chiudono dibattiti e mostrano effetti reali.

E la crittografia post-quantistica?

Oggi conviene attivare schemi ibridi per canali critici: classico + Kyber. È la minima protezione contro "registrato oggi, decifrato domani". Serve piano inventario e aggiornamento crittografia, soprattutto in settori regolamentati.

Si può combinare BYOD e Zero Trust?

Sì, se ci sono policy chiare sulla postura del dispositivo, containerizzazione dei dati di lavoro e accesso limitato ad app sensibili. Su BYOD meglio concedere accesso a web app tramite broker con DLP e permessi minimi. Il bilancio tra comfort e rischio è obbligatorio.