Dallo smart working all’assistenza tecnica da remoto, l’accesso alle risorse aziendali non può più basarsi sul semplice tunnel cifrato di una VPN tradizionale, che rischia di esporre l'intera rete IT e OT a rischi invisibili. Il passaggio allo ZTNA (Zero Trust Network Access) supera la fiducia implicita del perimetro, autorizzando dipendenti e fornitori esterni unicamente alle singole applicazioni necessarie e blindando così la continuità produttiva della fabbrica.
Quando la VPN non basta più
L’accesso remoto è diventato una componente strutturale dell’operatività aziendale. Dipendenti che lavorano fuori sede, tecnici, consulenti informatici e fornitori di macchinari devono poter raggiungere applicazioni, sistemi e informazioni senza trovarsi fisicamente all’interno dello stabilimento.
La VPN (Virtual Private Network) ha rappresentato a lungo uno degli strumenti principali per soddisfare questa esigenza. Attraverso un tunnel cifrato, consente di collegare un dispositivo remoto alla rete aziendale o a specifiche risorse interne, secondo le regole configurate. È una tecnologia ancora utile, ma la sua efficacia dipende dall’architettura di rete, dalle autorizzazioni concesse e dai controlli applicati alle connessioni.
Il punto critico emerge quando l’accesso alla VPN diventa, di fatto, una porta d’ingresso verso un insieme di sistemi più ampio di quello necessario. Se un account viene compromesso o il dispositivo utilizzato per la connessione è infetto, una configurazione permissiva può consentire a un attaccante di raggiungere ulteriori risorse e tentare di estendere la compromissione.
In ambito industriale, questa esposizione assume una rilevanza particolare. In funzione dell’architettura e dei collegamenti autorizzati, una connessione compromessa può offrire un punto di partenza per raggiungere server, sistemi di supervisione o infrastrutture utilizzate per la manutenzione degli impianti. Le conseguenze possono coinvolgere non soltanto la riservatezza delle informazioni, ma anche la disponibilità dei sistemi e la continuità produttiva.
È in questo scenario che assume rilevanza lo Zero Trust Network Access (ZTNA): un modello di gestione degli accessi che sposta il controllo dalla semplice appartenenza alla rete alla verifica delle condizioni con cui un utente o un dispositivo richiede una determinata risorsa.
L’obiettivo non è sostituire automaticamente ogni VPN, ma valutare dove un modello basato sull’accesso selettivo alle applicazioni possa ridurre l’esposizione dell’organizzazione e rendere più controllabili le connessioni di dipendenti e soggetti esterni.
Che cos'è lo ZTNA e come cambia il modello di accesso
Lo Zero Trust Network Access è un modello di accesso remoto basato sui principi Zero Trust, che consente di autorizzare utenti e dispositivi a raggiungere specifiche risorse aziendali sulla base di regole definite dall’organizzazione.
Il presupposto è che la posizione all’interno della rete e la sola autenticazione iniziale non siano sufficienti a giustificare l’accesso. Ogni richiesta deve essere valutata in relazione all’identità, alle autorizzazioni e alle condizioni previste dalle policy.
Il riferimento architetturale è il documento NIST SP 800-207, Zero Trust Architecture, che pone al centro della sicurezza le singole risorse, superando il principio della fiducia implicita associata alla collocazione di un dispositivo nella rete interna. Si tratta di un riferimento tecnico per la progettazione delle architetture di sicurezza, non di un obbligo normativo generale applicabile a tutte le imprese.
La differenza rispetto a un modello di accesso tradizionale riguarda soprattutto il rapporto tra connessione e autorizzazione. Una VPN può stabilire un collegamento cifrato con la rete aziendale, mentre lo ZTNA è generalmente progettato per consentire l’accesso alle sole applicazioni o risorse autorizzate, senza rendere automaticamente raggiungibili gli altri sistemi interni.
Dalla rete accessibile alle risorse autorizzate
Si immagini un’azienda manifatturiera che utilizza un ERP, un sistema MES per la gestione della produzione, un archivio documentale e un server per la manutenzione delle macchine.
Con un accesso remoto configurato in modo esteso, un dipendente potrebbe entrare in una subnet interna e raggiungere diversi servizi, anche quando per il proprio lavoro gli serve soltanto l’ERP.
Con un’architettura ZTNA opportunamente progettata, lo stesso dipendente può essere autorizzato a utilizzare l’ERP senza ottenere automaticamente accesso al MES o ai sistemi di amministrazione.
Il vantaggio non è soltanto la riduzione del numero di sistemi visibili dall’esterno. È la possibilità di limitare le relazioni di accesso che possono essere sfruttate durante un incidente.
Per progettare correttamente queste restrizioni, l’impresa deve conoscere le dipendenze tra le applicazioni. Un sistema gestionale potrebbe richiedere comunicazioni verso un database, un servizio di autenticazione o un server di licenze. Bloccare indiscriminatamente tali dipendenze potrebbe interrompere il servizio anche se l’accesso remoto risultasse più restrittivo.
ZTNA vs VPN aziendale: le differenze da valutare
La differenza tra ZTNA e VPN aziendale non consiste semplicemente nel fatto che uno sia più moderno dell’altra. Occorre confrontare il modello di autorizzazione, il perimetro raggiungibile, i controlli applicati ai dispositivi e la capacità di osservare e revocare gli accessi.
| Criterio | VPN aziendale tradizionale | ZTNA |
|---|---|---|
| Finalità | Creare un tunnel protetto verso la rete o risorse definite | Autorizzare l'accesso a risorse specifiche secondo policy |
| Perimetro di accesso | Può essere esteso alla rete oppure limitato a subnet e sistemi definiti | Generalmente orientato alle singole applicazioni o risorse |
| Identità | Può integrare MFA e sistemi centralizzati di identità | Integra l'identità nella decisione di accesso alla risorsa |
| Stato del dispositivo | Può essere verificato mediante controlli aggiuntivi | Può concorrere direttamente alla valutazione della policy |
| Movimento laterale | Dipende da segmentazione, routing e regole di rete | Può ridurre le opportunità di movimento limitando le risorse esposte |
| Applicazioni non autorizzate | Possono risultare raggiungibili se la rete e le regole lo consentono | Dovrebbero restare inaccessibili se non previste dalle policy |
| Accesso dei fornitori | Richiede profili, regole di rete e controlli specifici | Può consentire autorizzazioni mirate per applicazione e identità |
| Migrazione | Può essere già integrata con l'infrastruttura esistente | Può richiedere connettori, integrazioni e revisione delle policy |
Non è corretto concludere che tutte le VPN concedano necessariamente accesso all’intera rete aziendale. È possibile configurarle con restrizioni rigorose, autenticazione multifattore, segmentazione e controlli sugli endpoint.
Il punto critico è un altro: una VPN configurata per offrire ampia connettività interna può rendere raggiungibili più sistemi di quelli strettamente necessari all’attività dell’utente. Se le autorizzazioni applicative e le barriere tra segmenti non sono sufficienti, la compromissione di un endpoint può trasformarsi in un punto di partenza per ulteriori attività malevole.
La guida congiunta pubblicata nel giugno 2024 da CISA e altre autorità di cybersecurity, dedicata agli approcci moderni alla sicurezza degli accessi di rete, invita le organizzazioni a valutare i rischi delle architetture VPN tradizionali e delle configurazioni di accesso remoto, considerando approcci come Zero Trust, Secure Service Edge e Secure Access Service Edge. Il documento è disponibile nella pubblicazione ufficiale di CISA.
La scelta, pertanto, non dovrebbe essere guidata dalla contrapposizione tra una tecnologia intrinsecamente sicura e una intrinsecamente insicura. Dovrebbe partire dalla verifica di quanto sia circoscritto, controllabile e monitorabile l’accesso effettivamente concesso.
Dall'accesso iniziale al movimento laterale
Per comprendere il contributo dello ZTNA alla sicurezza, è utile distinguere tre aspetti:
- Autenticazione: verifica chi sta cercando di accedere.
- Autorizzazione: stabilisce a quali risorse e operazioni quell’identità può accedere.
- Raggiungibilità tecnica: determina quali sistemi sono effettivamente contattabili attraverso la connessione.
Un utente può essere autenticato correttamente ma disporre di privilegi eccessivi. Allo stesso modo, un account autorizzato a utilizzare una sola applicazione potrebbe trovarsi in un segmento di rete dal quale sono raggiungibili altri sistemi, se l’architettura non applica ulteriori restrizioni.
Si consideri una PMI manifatturiera che consente ai dipendenti di collegarsi alla VPN per raggiungere il gestionale, i file condivisi e alcuni strumenti interni. Se un attaccante riesce a utilizzare le credenziali di un dipendente e a superare gli eventuali controlli aggiuntivi, potrebbe tentare di accedere alla VPN.
La portata dell’incidente dipenderà da numerose condizioni: presenza di MFA resistente al phishing, protezione dell’endpoint, autorizzazioni dell’account, configurazione della VPN, segmentazione e monitoraggio.
Se la connessione garantisce un accesso esteso e l’account dispone di privilegi elevati, l’attaccante può tentare di individuare altri host, sfruttare servizi raggiungibili o cercare sistemi di maggiore valore. Questo processo è definito lateral movement, ovvero movimento laterale: l’avanzamento da un sistema inizialmente compromesso verso altre risorse dell’ambiente.
Non si tratta di un esito automatico della compromissione di una VPN. La possibilità di propagazione aumenta quando la connettività è ampia, i privilegi sono eccessivi e i sistemi interni non sono adeguatamente isolati.
La cifratura della VPN protegge il traffico durante il transito, ma non determina quali privilegi debba avere un utente né garantisce che il dispositivo sia sicuro. Autenticazione, autorizzazione e cifratura svolgono funzioni differenti e complementari.
I principi dello ZTNA: identità, contesto e minimo privilegio
Lo Zero Trust Network Access non si limita a introdurre un secondo fattore di autenticazione o a sostituire il client VPN con un altro software. La sua efficacia dipende dalle regole con cui l’accesso viene concesso, mantenuto e revocato.
1. Verificare l'identità dell'utente
L’identità costituisce il primo elemento della decisione di accesso. L’organizzazione deve poter associare ogni connessione a un’identità individuale, verificata e coerente con il ruolo ricoperto.
L’integrazione con un sistema di Identity and Access Management (IAM) o con un servizio di identità centralizzato consente di collegare le policy di accesso agli account aziendali, ai gruppi e ai processi di gestione del personale.
L’autenticazione multifattore (MFA) aggiunge ulteriori elementi di verifica rispetto alla sola password. Dove possibile, è opportuno privilegiare metodi resistenti al phishing e proteggere con requisiti più rigorosi gli account amministrativi.
La verifica dell’identità, tuttavia, non deve essere interpretata come una garanzia assoluta. Un account legittimo può essere compromesso, una sessione può essere sottratta e un dispositivo regolarmente registrato può essere infettato.
L’identità è dunque una componente della valutazione, non un’autorizzazione permanente e incondizionata.
2. Valutare lo stato del dispositivo
Un secondo elemento riguarda il dispositivo dal quale viene effettuata la richiesta.
A seconda delle capacità della piattaforma, le policy ZTNA possono considerare informazioni come:
- presenza di aggiornamenti di sicurezza richiesti;
- attivazione e stato delle protezioni endpoint;
- conformità alle configurazioni aziendali;
- appartenenza del dispositivo all’organizzazione o sua registrazione;
- presenza di segnali di compromissione;
- livello di gestione e affidabilità del dispositivo.
Questi controlli sono spesso indicati come device posture assessment.
Il loro valore è concreto: un dipendente potrebbe autenticarsi correttamente da un computer personale non aggiornato o da un dispositivo sul quale siano stati disattivati i controlli di sicurezza. In funzione delle policy, il sistema può negare l’accesso, richiedere ulteriori verifiche oppure consentire soltanto risorse a rischio inferiore.
Non tutte le piattaforme rilevano gli stessi segnali. Prima dell’adozione occorre verificare quali informazioni siano disponibili, con quale frequenza vengano aggiornate e quali azioni possano essere eseguite quando un dispositivo non rispetta i requisiti.
3. Considerare il contesto della richiesta
L’accesso può essere valutato anche in funzione del contesto: risorsa richiesta, fascia oraria, localizzazione approssimativa, comportamento osservato, livello di rischio e altri segnali disponibili.
Un tecnico che si collega durante una finestra di manutenzione autorizzata per raggiungere uno specifico ambiente può avere un profilo di rischio differente rispetto allo stesso account che tenta di accedere a sistemi amministrativi in orari insoliti.
Il contesto non deve però essere interpretato come una semplice lista di condizioni geografiche o temporali. Un accesso da una sede abituale non è necessariamente legittimo; una connessione da una nuova località non è automaticamente malevola.
Le informazioni devono essere valutate insieme all’identità, al dispositivo, alle autorizzazioni e alla sensibilità della risorsa.
4. Applicare il principio del minimo privilegio
Il principio del least privilege stabilisce che utenti, dispositivi e processi debbano disporre soltanto delle autorizzazioni necessarie a svolgere le attività assegnate.
Per gli accessi remoti significa evitare di concedere a un dipendente, a un amministratore o a un fornitore più possibilità di connessione di quelle richieste dal suo incarico.
Un consulente che deve intervenire su un applicativo di gestione della manutenzione non dovrebbe ricevere automaticamente accesso ai file HR, ai sistemi finanziari o alle interfacce di amministrazione dell’infrastruttura.
Il minimo privilegio riguarda sia le applicazioni accessibili sia le operazioni consentite all’interno di ciascuna applicazione. Quando il sistema lo permette, è opportuno differenziare l’accesso in lettura, l’esecuzione di attività ordinarie e le funzioni amministrative.
Le autorizzazioni devono inoltre avere una durata coerente con la necessità operativa. Gli accessi temporanei, soprattutto quelli concessi a soggetti esterni, devono essere revocati al termine dell’intervento.
5. Rivalutare le condizioni e revocare l'accesso
L’espressione autenticazione continua basata su contesto viene talvolta utilizzata per descrivere un modello in cui l’affidabilità della sessione è sottoposta a verifiche ripetute.
È importante essere precisi: non tutti i prodotti ZTNA rieseguono continuamente l’autenticazione dell’utente, né tutte le piattaforme valutano in tempo reale ogni possibile segnale. In molte implementazioni vengono rivalutati determinati attributi o eventi, mentre la frequenza e le modalità di verifica dipendono dal prodotto e dalle policy.
L’obiettivo è evitare che un’autorizzazione iniziale rimanga valida senza limiti anche quando cambiano le condizioni che l’avevano giustificata.
Se un dispositivo viene dichiarato non conforme, un account viene disabilitato o un’attività sospetta supera una soglia di rischio, la piattaforma dovrebbe consentire, secondo le sue capacità, di interrompere la sessione, richiedere una nuova verifica o revocare l’accesso.
Per ottenere questo risultato occorre integrare la gestione degli accessi con i processi di monitoraggio, risposta agli incidenti e amministrazione delle identità. La tecnologia da sola non sostituisce la definizione delle responsabilità operative.
ZTNA per le PMI manifatturiere: proteggere gli accessi senza isolare la produzione
Nelle imprese manifatturiere, la gestione degli accessi remoti presenta caratteristiche specifiche. Le infrastrutture IT e OT convivono e devono scambiare informazioni, ma rispondono a esigenze differenti in termini di disponibilità, sicurezza e continuità operativa.
A queste complessità si aggiunge la presenza di soggetti esterni che necessitano di collegarsi ai sistemi aziendali: fornitori di macchinari, manutentori, integratori, specialisti di automazione e partner tecnologici.
In questi casi, concedere un accesso remoto ampio e permanente può esporre l’organizzazione a rischi non necessari. Al contrario, un modello basato su autorizzazioni circoscritte permette di definire con maggiore precisione:
- quali sistemi possono essere raggiunti da ciascun fornitore;
- quali applicazioni sono accessibili in funzione dell’intervento richiesto;
- quali utenti possono effettuare determinate operazioni;
- per quanto tempo l’accesso deve rimanere attivo;
- quali eventi devono essere registrati e monitorati.
Un esempio concreto riguarda il manutentore che deve collegarsi da remoto a un’applicazione utilizzata per la diagnostica di un macchinario. L’esigenza operativa non richiede necessariamente l’accesso all’intera rete aziendale, ma soltanto alla risorsa interessata dall’intervento.
Un modello ZTNA può consentire di circoscrivere la connessione a tale applicazione, applicando le policy previste e mantenendo il controllo sull’accesso.
La sua adozione negli ambienti OT, tuttavia, richiede particolare attenzione. Non tutti i sistemi industriali supportano direttamente gli stessi meccanismi di autenticazione e controllo utilizzati negli ambienti IT. È quindi necessario valutare architettura, compatibilità tecnologica, modalità di accesso e impatti sui processi produttivi.
La priorità resta proteggere gli accessi senza introdurre discontinuità nei processi industriali.
Come pianificare la sostituzione della VPN tradizionale
La sostituzione VPN tradizionale non dovrebbe essere affrontata come una migrazione tecnologica da completare in un’unica fase. In una PMI manifatturiera, un passaggio graduale consente di verificare le dipendenze applicative, individuare i casi non compatibili e ridurre il rischio di interruzioni.
Un progetto di adozione dovrebbe articolarsi nelle seguenti fasi.
Fase 1. Mappare utenti, dispositivi e risorse
Prima di definire le policy è necessario censire gli accessi remoti esistenti. L’analisi dovrebbe comprendere dipendenti, amministratori, consulenti, fornitori, dispositivi aziendali e personali, applicazioni raggiungibili e segmenti di rete autorizzati.
Per ogni profilo occorre comprendere quali attività siano realmente necessarie, quali privilegi siano assegnati e se esistano account condivisi o autorizzazioni rimaste attive oltre il periodo previsto.
La mappatura deve includere anche i percorsi indiretti: un utente può accedere a un server tramite una workstation intermedia, un portale di assistenza o uno strumento di amministrazione remota. Limitarsi all’elenco dei profili VPN rischia di lasciare fuori una parte significativa delle connessioni effettive.
Fase 2. Classificare le applicazioni per criticità e compatibilità
Non tutte le risorse devono essere migrate con la stessa priorità.
Le applicazioni web aziendali, i portali e alcuni servizi gestionali possono rappresentare candidati relativamente semplici. Le applicazioni legacy, i protocolli non web, i sistemi con dipendenze di rete articolate e le risorse OT richiedono invece verifiche specifiche.
La classificazione dovrebbe considerare:
- criticità per il business e per la produzione;
- sensibilità dei dati trattati;
- privilegi richiesti per l’accesso;
- compatibilità tecnica con la piattaforma ZTNA;
- dipendenze da DNS, directory, database e servizi infrastrutturali;
- impatto di un’eventuale indisponibilità;
- modalità di gestione e supporto del fornitore.
Questa analisi permette di individuare un perimetro iniziale sostenibile e di evitare migrazioni basate esclusivamente sulla facilità tecnica.
Fase 3. Definire le policy di accesso
Le policy devono tradurre i ruoli aziendali e le esigenze operative in regole verificabili.
Per ogni risorsa è opportuno specificare chi può accedervi, da quali dispositivi, con quali requisiti di autenticazione, in quali condizioni e con quali privilegi. Gli accessi privilegiati e quelli dei fornitori dovrebbero essere gestiti con requisiti più rigorosi rispetto ai profili ordinari, in funzione del rischio.
Una policy troppo permissiva vanifica parte del beneficio dello ZTNA. Una policy eccessivamente restrittiva, invece, può ostacolare le attività e spingere gli utenti a cercare canali non autorizzati.
Per questo è utile coinvolgere i referenti applicativi, IT, OT e operations nella definizione dei requisiti, documentando le eccezioni e verificandole periodicamente.
Fase 4. Avviare un progetto pilota
Prima di estendere il modello all’intera organizzazione, un progetto pilota permette di verificare l’effettivo funzionamento delle policy prima di estenderle a tutta l’organizzazione.
È preferibile selezionare un gruppo limitato di utenti e applicazioni ben conosciute, con un impatto operativo controllabile. Il pilota dovrebbe includere prove di accesso autorizzato, tentativi di accesso non consentito, revoca dei privilegi, indisponibilità dei servizi di supporto e gestione dei dispositivi non conformi.
Quando possibile, le verifiche devono essere condotte anche in condizioni realistiche di utilizzo, includendo le attività svolte da remoto e le esigenze dei fornitori.
Il risultato non va misurato soltanto dal numero di connessioni riuscite. È necessario valutare se le restrizioni funzionino come previsto, se i log siano sufficienti per ricostruire le attività e se gli utenti riescano a lavorare senza ricorrere a eccezioni permanenti.
Fase 5. Migrare per priorità e mantenere controllate le eccezioni
Dopo il pilota, la migrazione può procedere per gruppi di applicazioni e categorie di utenti.
Le VPN possono essere mantenute temporaneamente per i casi che richiedono connettività di rete, purché siano protette e governate secondo il rischio. L’obiettivo non è eliminare la VPN a prescindere, ma ridurre gli accessi ampi e non necessari, sostituendoli dove possibile con meccanismi più granulari.
Ogni eccezione dovrebbe avere un responsabile, una motivazione, un perimetro e una data di revisione. In caso contrario, la coesistenza tra vecchia e nuova architettura rischia di diventare permanente senza una governance chiara.
Come valutare una piattaforma ZTNA: i criteri da non trascurare
La scelta di una piattaforma ZTNA dovrebbe partire dai requisiti di sicurezza e operativi, non dalla sola disponibilità di funzionalità commercialmente definite come Zero Trust.
Le differenze tra prodotti possono riguardare il modello di pubblicazione delle applicazioni, le modalità di integrazione con l’identità aziendale, i controlli sui dispositivi, la gestione delle sessioni e la visibilità sulle attività degli utenti.
Per una PMI manifatturiera, è utile verificare almeno i seguenti aspetti.
| Criterio | Che cosa verificare |
|---|---|
| Identità e autenticazione | Integrazione con il sistema di identità, MFA, gestione dei privilegi e disattivazione degli account |
| Controllo degli endpoint | Verifica dello stato dei dispositivi e possibilità di negare o limitare l'accesso in caso di non conformità |
| Granularità delle policy | Capacità di autorizzare singole applicazioni, gruppi di risorse e profili differenti |
| Accessi privilegiati | Separazione degli account amministrativi, gestione delle sessioni e possibilità di introdurre controlli aggiuntivi |
| Accessi di terze parti | Autorizzazioni temporanee, identificazione individuale, revoca e tracciamento |
| Monitoraggio | Log sufficienti per analizzare accessi, anomalie, tentativi negati e modifiche alle policy |
| Compatibilità IT/OT | Supporto delle applicazioni effettivamente utilizzate e verifica delle dipendenze di rete |
| Continuità del servizio | Gestione delle indisponibilità, dipendenze infrastrutturali e procedure di emergenza |
| Amministrazione | Facilità di aggiornamento delle policy, revisione dei privilegi e gestione delle eccezioni |
| Costi complessivi | Licenze, infrastruttura, integrazioni, migrazione, formazione e gestione continuativa |
Un altro elemento da valutare è la visibilità che la piattaforma offre sulle connessioni. I log devono essere sufficienti a ricostruire chi ha effettuato un accesso, a quale risorsa, quando e secondo quale autorizzazione, nei limiti delle informazioni raccolte dal prodotto. L’integrazione con i sistemi di monitoraggio e gestione degli eventi di sicurezza può migliorare la capacità di correlare gli accessi con altre attività sospette.
Occorre inoltre distinguere il controllo dell’accesso dalla protezione dell’applicazione. Lo ZTNA non elimina le vulnerabilità del software, non sostituisce la protezione degli endpoint e non garantisce che un utente autorizzato compia esclusivamente operazioni legittime. Per questo deve essere inserito in un insieme di controlli che comprenda aggiornamenti, gestione delle vulnerabilità, backup, monitoraggio e risposta agli incidenti.
- Considerare lo ZTNA una protezione completa
L’adozione di una piattaforma non rende automaticamente sicure le identità, le applicazioni e le reti interne. Se un account possiede privilegi eccessivi o un’applicazione è vulnerabile, il rischio rimane.
La piattaforma deve essere accompagnata da una revisione delle autorizzazioni, dalla protezione dei dispositivi e da controlli coerenti sulle risorse esposte.
- Limitarsi ad aggiungere MFA alla VPN
L’autenticazione multifattore è una misura importante, ma non risolve il problema della raggiungibilità interna eccessiva. Un utente può superare correttamente l’autenticazione e disporre comunque di un accesso più ampio del necessario.
MFA, segmentazione e autorizzazioni granulari rispondono a esigenze differenti e devono essere considerate complementari.
- Trasferire le vecchie autorizzazioni nel nuovo sistema
Una migrazione che riproduce automaticamente tutti i privilegi esistenti rischia di conservare le debolezze del modello precedente. Il passaggio allo ZTNA rappresenta un’opportunità per riesaminare i profili, eliminare gli accessi inutilizzati e assegnare autorizzazioni coerenti con le attività effettive.
- Trascurare gli accessi dei fornitori
Gli account di terze parti possono rimanere attivi anche dopo la conclusione dei contratti o degli interventi. La mancanza di scadenze e di responsabilità definite riduce il controllo sulle connessioni.
Gli accessi esterni dovrebbero essere individuali, autorizzati per una finalità precisa e revocati quando non più necessari.
- Ignorare i vincoli degli ambienti industriali
Applicare regole senza verificare i flussi di comunicazione può interrompere servizi necessari alla produzione o alla manutenzione. In ambito OT, le policy devono essere testate con il coinvolgimento dei responsabili degli impianti e tenendo conto dei requisiti di disponibilità e sicurezza.
La progettazione deve evitare sia un accesso eccessivamente permissivo sia restrizioni introdotte senza un’adeguata analisi delle dipendenze.
ZTNA e gestione continuativa della sicurezza
L’adozione dello ZTNA rappresenta un’evoluzione nella protezione degli accessi alle risorse aziendali, ma la sua efficacia dipende anche dalla capacità di mantenerne nel tempo la corretta configurazione e applicazione.
La gestione non può limitarsi alla fase di implementazione: richiede attività periodiche di verifica e aggiornamento, tra cui:
- Revisione di account e privilegi, per garantire che le autorizzazioni siano sempre coerenti con ruoli e responsabilità.
- Controllo degli accessi di terze parti, con particolare attenzione alle connessioni temporanee e ai permessi concessi a fornitori e manutentori.
- Aggiornamento delle policy, in funzione dell’evoluzione dell’infrastruttura, delle applicazioni e delle esigenze operative.
- Monitoraggio degli eventi e analisi delle anomalie, per individuare tentativi di accesso sospetti o comportamenti non coerenti con le autorizzazioni assegnate.
- Verifica della revoca degli accessi, soprattutto in caso di cessazione del rapporto di lavoro, conclusione di un intervento o modifica delle responsabilità.
- Verifica delle procedure di emergenza e ripristino, per accertare che siano disponibili modalità di intervento compatibili con i requisiti di sicurezza e continuità operativa.
- Riesame delle interdipendenze IT/OT, per valutare gli effetti delle policy di accesso sui sistemi industriali e sui processi produttivi.
Queste attività consentono di intercettare progressivamente autorizzazioni non più necessarie, eccezioni non adeguatamente governate e modalità di accesso che possono diventare critiche a seguito di modifiche organizzative o infrastrutturali.
Per le imprese che non dispongono internamente di tutte le competenze necessarie, il supporto di un partner MSP/MSSP può contribuire alla gestione operativa dell’infrastruttura, al monitoraggio degli eventi e al miglioramento dei controlli. È tuttavia fondamentale definire con chiarezza l’ambito dei servizi, le responsabilità e le modalità di integrazione con i processi e le funzioni aziendali.
Lo ZTNA, quindi, non è una tecnologia da implementare una tantum, ma una componente di un modello di gestione degli accessi che deve evolvere insieme all’organizzazione e rimanere coerente con il suo profilo di rischio.
Conclusione: il controllo dell'accesso conta più del semplice collegamento
Per le imprese manifatturiere, evolvere dalla VPN tradizionale verso lo Zero Trust Network Access significa ripensare il modo in cui dipendenti, amministratori e fornitori raggiungono le risorse aziendali.
Una connessione cifrata e un’autenticazione corretta restano requisiti importanti, ma non sono sufficienti se, una volta collegato, un utente può raggiungere sistemi estranei alle proprie attività. La combinazione di identità verificata, valutazione del contesto, minimo privilegio e segmentazione consente di circoscrivere meglio gli accessi e contenere le possibili conseguenze di una compromissione.
Negli ambienti industriali, l’applicazione di questi principi richiede un’attenzione specifica alle interdipendenze tra sistemi IT e OT, alla compatibilità con le tecnologie presenti e alla continuità dei processi produttivi. La protezione degli accessi deve infatti essere efficace senza ostacolare le attività di produzione, manutenzione e assistenza tecnica.
La valutazione non dovrebbe quindi limitarsi a individuare quale tecnologia possa sostituire la VPN, ma partire da un’analisi concreta delle modalità di accesso esistenti: quali risorse può raggiungere ciascun utente remoto, per quali esigenze operative e con quali criteri vengono riesaminate o revocate le autorizzazioni?
È da questa analisi che può prendere forma un progetto ZTNA sostenibile, integrato nell’architettura IT/OT e inserito in un processo continuativo di gestione della sicurezza.
Domande frequenti su Zero Trust Network Access e VPN
Domande frequenti su ZTNA, VPN aziendale e sicurezza degli accessi remoti
1. Che cos'è lo Zero Trust Network Access (ZTNA) e come funziona?
Lo Zero Trust Network Access (ZTNA) è un modello di sicurezza informatica che controlla gli accessi alle applicazioni e alle risorse aziendali verificando l’identità dell’utente, l’affidabilità del dispositivo e il contesto della connessione.
Si basa sul principio Never Trust, Always Verify (mai fidarsi, verificare sempre): nessun utente o dispositivo viene considerato automaticamente affidabile. Ogni richiesta di accesso viene valutata in base alle policy di sicurezza definite e autorizzata soltanto per le risorse necessarie allo svolgimento delle attività. In questo modo, l’accesso alla rete non comporta automaticamente la possibilità di raggiungere tutti i sistemi aziendali.
2. Qual è la differenza tra ZTNA e VPN aziendale?
La principale differenza tra ZTNA e VPN aziendale riguarda il livello di accesso concesso alle risorse della rete: la VPN crea una connessione protetta verso la rete aziendale, mentre lo ZTNA autorizza l’accesso alle singole applicazioni e risorse in base a specifiche policy.
La VPN (Virtual Private Network) stabilisce un collegamento cifrato tra il dispositivo remoto e la rete aziendale, consentendo di raggiungere le risorse previste dalla configurazione. Lo ZTNA adotta invece un modello di accesso selettivo, basato su identità, dispositivo e contesto della richiesta. La differenza non riguarda quindi soltanto la protezione della connessione, ma soprattutto il modo in cui vengono definite e applicate le autorizzazioni.
3. Lo ZTNA sostituisce la VPN tradizionale?
No, lo ZTNA non sostituisce necessariamente la VPN in tutti gli scenari. Può rappresentare un’alternativa per specifiche esigenze di accesso remoto, come il collegamento dei dipendenti alle applicazioni aziendali o l’accesso di fornitori e manutentori a risorse circoscritte.
In altri contesti, le due tecnologie possono coesistere all’interno di un’architettura ibrida. La scelta dipende dalle caratteristiche dell’infrastruttura, dalle applicazioni utilizzate, dai requisiti di connettività e dalle esigenze operative. Nelle imprese manifatturiere è particolarmente importante valutare le dipendenze tra sistemi IT e OT prima di pianificare una migrazione.
4. In che modo lo ZTNA riduce la superficie di attacco aziendale?
Lo ZTNA contribuisce a ridurre la superficie di attacco aziendale limitando l’accesso alle sole applicazioni e risorse autorizzate, senza concedere all’utente una visibilità più ampia sulla rete non necessaria alle sue attività.
Questo approccio riduce le possibilità che un account compromesso o un dispositivo non adeguatamente protetto possano essere utilizzati per raggiungere altri sistemi aziendali. L’efficacia dipende dalla corretta configurazione delle policy di accesso e dalla loro integrazione con ulteriori controlli di sicurezza, come autenticazione multifattore, protezione degli endpoint e monitoraggio degli eventi.
5. Lo ZTNA può essere utilizzato anche negli ambienti industriali OT?
Sì, lo ZTNA può contribuire a proteggere gli accessi remoti agli ambienti OT (Operational Technology), consentendo di circoscrivere le connessioni alle applicazioni e ai sistemi industriali effettivamente necessari.
Può risultare utile, ad esempio, nella gestione degli accessi di manutentori, integratori e fornitori tecnologici che devono collegarsi da remoto per attività di assistenza o diagnostica. L’implementazione richiede tuttavia un’analisi preventiva della compatibilità con i sistemi industriali, delle interdipendenze tra IT e OT e degli eventuali impatti sulla continuità produttiva.
6. Lo ZTNA impedisce il movimento laterale di un attaccante?
No, lo ZTNA non impedisce in assoluto il movimento laterale, ma può limitarne le opportunità riducendo il numero di risorse raggiungibili attraverso un singolo accesso compromesso.
Il movimento laterale (lateral movement) si verifica quando un attaccante, dopo aver ottenuto un primo accesso, tenta di spostarsi verso altri sistemi e risorse della rete. Applicando il principio del minimo privilegio e limitando le autorizzazioni alle sole applicazioni necessarie, lo ZTNA contribuisce a contenere questo rischio.
Per una protezione efficace è comunque necessario integrare il controllo degli accessi con la gestione delle vulnerabilità, la segmentazione della rete, la protezione degli endpoint e il monitoraggio continuativo degli eventi di sicurezza.
7. Perché affidarsi a un MSP/MSSP per gestire la sicurezza degli accessi remoti?
Affidarsi a un MSP/MSSP (Managed Service Provider / Managed Security Service Provider) consente alle imprese di avvalersi di competenze specialistiche per la gestione delle infrastrutture IT e OT, il monitoraggio degli eventi e il miglioramento dei controlli di sicurezza.
Nel percorso di adozione dello ZTNA, un partner qualificato può supportare l’analisi dell’architettura esistente, la definizione delle policy, la gestione delle autorizzazioni e il controllo continuativo degli accessi. Per le PMI manifatturiere è importante che queste attività tengano conto delle specificità degli ambienti industriali e dei requisiti di continuità operativa.
AESSE Soluzioni Informatiche affianca le imprese manifatturiere nella protezione e nella gestione della sicurezza delle infrastrutture IT e OT attraverso servizi di cybersecurity gestita.
Chi accede alla tua rete? E a quali risorse?
Rafforza il controllo degli accessi e la protezione della tua infrastruttura con i servizi di cybersecurity gestita Sicurezza Pro 3.
