ZTNA on-premises per applicazioni private

Lo ZTNA on-premises consiste in un’implementazione dell’architettura “ zero trust network access ” in cui il punto di applicazione delle politiche per le applicazioni private opera su un’infrastruttura situata all’interno dei data center e delle filiali dell’organizzazione stessa. Gli utenti e i sistemi vengono autenticati e autorizzati per ciascuna applicazione, come in qualsiasi soluzione ZTNA, ma il traffico tra gli utenti in loco e le applicazioni in loco non deve necessariamente passare attraverso il cloud del fornitore e tornare indietro.

Il presente articolo fa parte della guida alla sicurezza del cloud ibrido.

Come funziona lo ZTNA

ZTNA verifica l’identità, il dispositivo e il contesto di ciascun utente, per poi collegarlo a una singola applicazione anziché a una rete.

L’architettura “zero trust” del NIST, SP 800-207, separa il punto di decisione relativo alle politiche (che stabilisce se un soggetto possa accedere a una risorsa) dal punto di applicazione delle politiche (che abilita, monitora e interrompe la connessione). I prodotti ZTNA implementano tale modello per le applicazioni private:

1. Un utente o un sistema richiede l'accesso a un'applicazione.
2. La richiesta giunge a un punto di elaborazione, solitamente un gateway, un broker o un proxy.
3. La politica valuta l’identità, il gruppo, lo stato di sicurezza del dispositivo, la posizione, il rischio e l’applicazione specifica richiesta.
4. Se consentito, il punto di applicazione collega il soggetto esclusivamente a tale applicazione. Il resto della rete rimane invisibile.
5. La sessione è monitorata e può essere interrotta qualora le condizioni dovessero cambiare.

La guida pratica SP 1800-35 del NIST , intitolata “Implementing a Zero Trust Architecture”(Implementazione di un’architettura Zero Trust) e pubblicata nel giugno 2025, documenta 19 esempi di implementazione realizzati con 24 fornitori in ambienti sia on-premise che cloud, e costituisce un utile riferimento per comprendere come tali componenti si integrino tra loro nella pratica.

ZTNA gestito tramite cloud vs. ZTNA on-premises

La differenza sta nel luogo in cui avviene l’applicazione delle misure di sicurezza: nel cloud del fornitore per ogni sessione, oppure sui gateway del cliente stesso per le sessioni locali.

In un tipico modello mediato dal cloud, una macchina virtuale di connessione leggera viene eseguita accanto all’applicazione e apre un tunnel in uscita verso il gateway del fornitore, pertanto non sono necessarie porte in entrata sul firewall. Skyhigh Private Access funziona in questo modo per l’accesso remoto: il traffico client viene gestito presso il punto di presenza SSE e instradato tramite tunnel TLS verso i connettori distribuiti nello stesso data center, cloud privato o cloud pubblico dell’applicazione.

Lo ZTNA on-premises introduce un percorso di applicazione locale, in modo che gli utenti e i sistemi all’interno della rete possano beneficiare dello stesso controllo per singola applicazione senza dover uscire dall’edificio.

Perché l’applicazione delle norme a livello locale è importante

L'applicazione a livello locale evita il fenomeno dell'hairpinning, raggiunge il traffico interno e quello degli agenti di intelligenza artificiale e continua a funzionare anche in caso di interruzioni del servizio cloud.

Hairpinning. L’inoltro del traffico di un utente in ufficio verso un broker cloud e poi di nuovo verso un server situato in fondo al corridoio comporta un aumento della latenza e una maggiore dipendenza da Internet, senza alcun vantaggio in termini di sicurezza.

Traffico interno. Gran parte del traffico che il modello Zero Trust dovrebbe regolare non attraversa mai il perimetro di Internet: sessioni amministrative, chiamate da applicazione ad applicazione, accessi tecnici alle infrastrutture OT. Un’applicazione della politica limitata al cloud non ne tiene conto.

Agenti di intelligenza artificiale e account di servizio. Gli agenti autonomi e gli account di servizio possono disporre di diritti di accesso a livello utente e trasferire dati tra sistemi interni alla velocità delle macchine. Skyhigh sostiene che il controllo di tali flussi debba avvenire all’interno della rete da cui ha origine il traffico (Skyhigh Security).

Continuità. In caso di interruzione del servizio cloud del fornitore o della connessione a Internet, le sessioni locali proseguono in base alle politiche applicate a livello locale. Verifichi con il proprio fornitore la durata consentita della disconnessione e il comportamento dei controlli di conformità e di identità.

Sovranità. Il traffico delle applicazioni locali può rimanere all’interno dell’infrastruttura del cliente. È possibile registrare dove vengono elaborate e archiviate le decisioni relative alle politiche, i controlli di identità e i metadati delle sessioni. Qualora una sessione Skyhigh richieda una protezione dei dati applicata nel cloud, i contenuti pertinenti vengono inoltrati al cloud Skyhigh per essere sottoposti a ispezione in base alla stessa politica.

Controlli d’identità

Lo ZTNA on-premises dovrebbe applicare lo stesso rigore in materia di identità previsto per l'accesso remoto:

• Autenticazione tramite il provider di identità aziendale con autenticazione a più fattori (MFA) resistente al phishing
• Stato del dispositivo: stato di gestione, versione del sistema operativo, crittografia del disco, protezione degli endpoint
• Gruppo e ruolo, associati ai diritti specifici per ciascuna applicazione
• Contesto: posizione, ora, punteggio di rischio derivante dall’analisi comportamentale
• Carico di lavoro e identità dell’agente per l’accesso non umano
• Valutazione continua, con interruzione della sessione in caso di variazioni della postura o dei fattori di rischio

Una lacuna comune consiste nell’esentare gli utenti in sede dai controlli sullo stato di sicurezza dei dispositivi. Il fatto di trovarsi sulla rete LAN aziendale non costituisce di per sé uno stato di sicurezza.

Posizionamento dei connettori e dei gateway

Posizionate i gateway in prossimità delle applicazioni che proteggono, in gruppi ridondanti, con una segmentazione attorno ad essi.

• Posizionate i gateway in prossimità delle applicazioni che proteggono, sullo stesso segmento o su uno adiacente, in modo che l’applicazione protetta sia raggiungibile solo attraverso il gateway.
• Effettuare l'implementazione in gruppi per garantire capacità e disponibilità, e associare le applicazioni ai gruppi anziché a singoli gateway.
• Mantenete la connettività esclusivamente in uscita per i percorsi gestiti dal cloud, in modo che le applicazioni non siano esposte a connessioni in entrata.
• Si ricorra alla segmentazione della rete gestita dal cliente per impedire che un gateway compromesso raggiunga sistemi non correlati.
• Pianificare le filiali. Stabilire se ciascuna filiale dovrà disporre di un gateway locale o collegarsi a uno regionale.

Percorsi di accesso locali

Un modello ZTNA ibrido richiede tre percorsi di accesso distinti, tutti regolati da un’unica politica:

1. Da utente in loco ad applicazione in loco: gateway locale, senza passaggio attraverso il cloud.
2. Da utente remoto all’applicazione in loco: da broker cloud a connettore locale o gateway.
3. Da un'applicazione in locale a un'applicazione ospitata nel cloud: gateway locale o broker cloud collegato a un connettore nell'ambiente cloud.

Tutte e tre dovrebbero utilizzare un’unica definizione di politica, in modo che i diritti di un utente non varino a seconda della posizione.

Un esempio di architettura “zero trust” per il cloud ibrido

Un'architettura ibrida Zero Trust combina l'applicazione delle politiche a livello locale e nel cloud all'interno di un unico livello di identità e politiche, come illustra questo esempio.

Si consideri una società di servizi finanziari dotata di un data center presso la sede centrale, 40 filiali, un ambiente IaaS e una forza lavoro in remoto.

• Identità: un unico provider di identità con autenticazione a più fattori (MFA); stato di sicurezza dei dispositivi tramite la gestione degli endpoint.
• Sede centrale: i gateway ZTNA locali fungono da interfaccia per le interfacce amministrative del sistema bancario centrale e per gli strumenti interni. Il personale in sede si collega direttamente tramite il gateway locale.
• Filiali: i gateway delle filiali controllano l’accesso ai sistemi delle filiali e inoltrano le richieste ai gateway della sede centrale per le applicazioni centrali.
• IaaS: i connettori nell’ambiente cloud fungono da interfaccia per i carichi di lavoro; gli utenti remoti e in loco vi accedono tramite il broker appropriato.
• Personale in remoto: i punti di presenza nel cloud consentono l’accesso sia al data center che alle applicazioni IaaS.
• Agenti di IA: le identità di servizio per gli assistenti di IA interni ricevono autorizzazioni specifiche per ciascuna applicazione e vengono applicate a livello locale.
• Politica: un unico insieme di regole disciplina tutti i percorsi, gestito da un’unica console.

In caso di interruzione della connessione Internet, il personale della sede centrale e delle filiali continua a lavorare utilizzando le applicazioni locali, e l’applicazione delle norme a livello locale prosegue per tutta la durata del periodo di disconnessione previsto.

Requisiti di implementazione da valutare

Valutate le soluzioni ZTNA on-premises alla luce di tali requisiti prima di stilare l’elenco dei fornitori preselezionati.

• Esecuzione locale per gli utenti in loco senza hairpinning nel cloud
• Stessa politica e stessi diritti per i percorsi locali e remoti
• Applicazione delle norme relative alla configurazione dei dispositivi per gli utenti in sede
• Supporto per identità non umane e agenti di intelligenza artificiale
• Protocolli supportati: Web, SSH, RDP, database e TCP/UDP legacy
• Alta disponibilità e gruppi di connettori
• Comportamento previsto nel caso in cui il cloud del fornitore o il provider di identità risulti irraggiungibile
• Registrazione della posizione e integrazione SIEM
• Integrazione con il gateway web e il sistema DLP, in modo che le sessioni delle applicazioni private siano protette dal punto di vista dei dati

Software per l'architettura "zero trust" per il cloud ibrido

Lo ZTNA costituisce una componente di un’architettura ibrida zero trust.

Funziona in sinergia con i provider di identità, la gestione degli endpoint, i gateway web, i CASB, i sistemi DLP e la segmentazione. Valutate lo ZTNA come parte integrante della piattaforma che garantirà l’applicazione del resto della vostra politica di sicurezza, non come sostituto autonomo della VPN. Consultate l’articolo “Soluzioni di sicurezza per il cloud ibrido: come confrontare i fornitori”.

In che modo Skyhigh fornisce la soluzione ZTNA on-premises

Skyhigh fornisce una soluzione ZTNA on-premise tramite gateway locali nell’Hybrid SSE Mesh, insieme all’ Private Access, gestito tramite cloud.

In Skyhigh Hybrid SSE Mesh, lo ZTNA locale viene eseguito sui gateway on-premise e delle filiali dell’organizzazione, su un’infrastruttura di sua proprietà e modificabile sotto il suo controllo, anziché su un nodo locale gestito dal fornitore, estendendo l’applicazione del modello zero trust agli utenti interni, alle risorse e agli agenti di intelligenza artificiale. Skyhigh Private Access continua a gestire l’accesso remoto attraverso i punti di presenza Skyhigh, ed entrambi sono gestiti da un’unica console e da un unico motore di policy insieme a SWG, CASB e DLP.

Fonti

1. NIST. SP 800-207: Architettura Zero Trust (agosto 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST NCCoE. SP 1800-35: Implementazione di un’architettura Zero Trust (giugno 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
3. CISA. Modello di maturità Zero Trust, versione 2.0. https://www.cisa.gov/zero-trust-maturity-model
4. Skyhigh Security. “Come funziona Skyhigh Private Access .” https://success.skyhighsecurity.com/docs/how-skyhigh-private-access-works
5. Skyhigh Security. “Modernizzazione dell’ Secure Web Gateway Symantec Edge con Skyhigh Hybrid SSE Mesh” (15 luglio 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html