Sicurezza informatica e sistemi automatizzati 'zero-trust': proteggere le reti OT industriali

Il modello "zero trust" applicato alle reti OT industriali consiste nel non considerare affidabile alcun accesso per impostazione predefinita, anche se proviene da un tecnico, da un fornitore di servizi, da una postazione interna o da una rete già collegata al sito. Ogni connessione a un PLC, a un sistema SCADA, a un’interfaccia uomo-macchina (HMI) o a un gateway industriale deve essere autenticata, autorizzata, limitata, registrata e revocabile. Per gli ambienti Siemens, Schneider, Rockwell o multiconstruttore, questo approccio riduce l’esposizione dei PLC senza ostacolare le esigenze di manutenzione e supervisione.

Il problema

Il modello di sicurezza tradizionale si basa spesso su un perimetro: un firewall protegge l’ingresso, dopodiché le apparecchiature situate all’interno della rete sono considerate relativamente affidabili. Nelle reti OT industriali, questa logica è fragile. I controllori logici non possono sempre essere aggiornati rapidamente, alcuni protocolli industriali non integrano un’autenticazione forte nativa, le postazioni di ingegneria sono critiche e il tradizionale «air gap» è spesso scomparso con il monitoraggio remoto, la manutenzione a distanza, l’IIoT e gli scambi con il cloud.

I rischi più frequenti sono ben noti alle squadre sul campo.

• Una VPN generica condivisa può esporre eccessivamente la rete OT qualora un account, una postazione o un file di configurazione venisse compromesso.

• I protocolli industriali come Modbus/TCP, EtherNet/IP o alcune applicazioni PROFINET possono trasmettere comandi o dati senza un livello di crittografia applicativa sufficiente, a seconda delle configurazioni.

• Gli accessi dei fornitori rimangono talvolta aperti in modo permanente, senza finestre di manutenzione, senza restrizioni precise e senza revisioni periodiche.

• Le reti OT a livello di rete consentono ad apparecchiature di importanza secondaria di comunicare con controllori di produzione o server SCADA sensibili.

• I vecchi controllori e le vecchie interfacce uomo-macchina (HMI) possono dipendere da versioni software fisse, il che richiede di compensare tale limitazione ricorrendo alla rete, alla segmentazione e al monitoraggio.

• I registri di accesso sono incompleti: diventa difficile sapere quale utente si sia collegato, quando, da dove e a quale dispositivo.

• Su alcune apparecchiature industriali sono ancora presenti password predefinite o condivise, in particolare quando l’inventario e le procedure di modifica non sono gestiti in modo adeguato.

• I dati relativi alla produzione, alle ricette, ai parametri di processo e allo stato delle macchine possono circolare tra le diverse aree senza un controllo adeguato.

• I requisiti NIS2 e i principi della norma IEC 62443 sottolineano la necessità di documentare, limitare, tracciare e verificare gli accessi ai sistemi industriali.

Il modello "zero trust" non consiste nel bloccare l’OT. Consiste nell’eliminare gli accessi impliciti e sostituirli con diritti espliciti, contestualizzati e verificabili.

Perché il modello Zero Trust è adatto alle reti OT

Nel settore IT, il modello "zero trust" è spesso associato all’identità dell’utente, alla postazione di lavoro e alle applicazioni SaaS. Nel settore OT, deve essere adattato ai vincoli industriali: disponibilità, sicurezza, cicli lunghi, protocolli storici, apparecchiature difficili da aggiornare e interventi da parte di fornitori di servizi.

L’idea centrale rimane la stessa: non dare mai per scontato che un utente o un’apparecchiatura sia affidabile solo perché si trova “nella rete giusta”.

Principio "zero trust"	Applicazione OT concreta	Esempio
Verifica esplicita	Autenticazione di ogni accesso remoto	Account nominativo e MFA per un tecnico
Privilegio minimo	Limitare alle apparecchiature necessarie	Accesso a una CPU Siemens, non all’intera VLAN
Segmentazione	Isolare le zone e i condotti	Linea 1 separata dalla linea 2
Monitoraggio continuo	Registrazione e segnalazione	Connessione del fornitore al di fuori dell’orario previsto
Revoca rapida	Revoca immediata di un diritto	Disattivazione di un certificato compromesso
Resilienza	Mantenimento del funzionamento locale	Il PLC rimane controllabile in loco

Questo approccio risulta particolarmente utile quando diversi soggetti operano sugli stessi sistemi: team interni di manutenzione, tecnici di automazione, costruttori di macchinari, integratori, fornitori di sistemi SCADA, operatori di telecomunicazioni e subappaltatori.

Architettura zero trust per controllori logici programmabili (PLC) e sistemi SCADA

Un’architettura OT "zero trust" si basa su zone, canali e un punto di controllo tra gli utenti remoti e le apparecchiature industriali. Il gateway non deve essere un semplice tunnel trasparente: deve applicare regole di accesso, registrare le sessioni e consentire una revoca rapida.

La rete OT mantiene le sue funzioni locali. I controllori logici, le interfacce uomo-macchina (HMI) e il sistema SCADA continuano a funzionare in loco, ma gli accessi esterni vengono filtrati, tracciati e limitati a una specifica esigenza.

Il nostro approccio

Eziwan adotta un approccio "zero trust" per le reti OT, combinando identità, tunnel sicuri, regole per dispositivo, segmentazione, finestre temporali, monitoraggio e registri di audit. L’obiettivo è sostituire gli accessi permanenti e condivisi con accessi nominativi, limitati, monitorabili e revocabili.

• Identificazione tramite accesso: ogni tecnico o fornitore di servizi dispone delle proprie credenziali, dei propri certificati o dei propri diritti di accesso, senza account VPN condivisi.

• Principio del privilegio minimo: ogni utente ha accesso solo alle risorse necessarie allo svolgimento delle proprie mansioni.

• Finestre temporali: gli accessi dei fornitori possono scadere automaticamente al termine del periodo di manutenzione autorizzato.

• Microsegmentazione della rete: i siti, le linee o le zone OT sono isolati per impostazione predefinita, con regole esplicite tra i diversi perimetri.

• Registri di audit in tempo reale: vengono registrati gli accessi, i tentativi di accesso negati, la durata delle sessioni, le risorse utilizzate e gli eventi di sicurezza.

• Rilevamento delle anomalie: avvisi relativi a connessioni al di fuori degli orari previsti, tentativi non autorizzati o comportamenti insoliti.

• Isolamento rapido: un utente, una regola o un’apparecchiatura possono essere isolati senza doversi recare sul posto, qualora l’architettura lo consenta.

• Gestione delle password OT: inventario delle apparecchiature sensibili, individuazione dei punti di accesso vulnerabili e flusso di lavoro per un aggiornamento controllato.

• Crittografia dei flussi remoti: i protocolli OT non crittografati possono essere incapsulati in un tunnel sicuro tra l’utente autorizzato e il punto di accesso industriale.

• Procedure di risposta agli incidenti: modelli di contenimento, revoca, registrazione e ripristino per ridurre l’improvvisazione in situazioni di crisi.

Questo approccio si integra con un gateway Eziwan, il monitoraggio tramite il cloud Eziwan e le architetture di connettività industriale.

Funzionalità principali

VPN personalizzata per utente

Ogni tecnico e fornitore di servizi deve disporre di un proprio accesso. Un certificato, una configurazione o un account nominativo consentono di sapere chi si connette e di revocare l’accesso a un utente senza influire sugli altri.

Il vantaggio è immediato: se un accesso viene compromesso, può essere disattivato singolarmente. Gli altri tecnici mantengono i propri diritti e l’indagine può basarsi su un’identità chiara.

Controllo degli accessi basato sui ruoli per l’OT

Il RBAC, ovvero il controllo degli accessi basato sui ruoli, deve essere adattato alle realtà industriali. Un operatore, un tecnico di automazione interno, un integratore Siemens, un fornitore di servizi Schneider o un tecnico dell’assistenza Rockwell non necessitano tutti dello stesso ambito di accesso.

Esempi di possibili ruoli:

• Operatore: consultazione di report o accesso a un’interfaccia con funzionalità limitate.

• Tecnico di manutenzione: diagnosi e supervisione di un’area.

• Tecnico di automazione: accesso ai controllori logici programmabili (PLC) e agli strumenti di ingegneria autorizzati.

• Appaltatore edile: accesso temporaneo alle macchine di cui è responsabile.

• Amministratore OT: gestione delle regole, degli utenti e degli audit.

Il ruolo non deve prevedere l’apertura di un’intera rete per mere comodità. Deve descrivere un’esigenza reale: sito, area, attrezzatura, protocollo, durata e livello di intervento.

Finestre di manutenzione temporanee

Gli accessi permanenti rappresentano uno dei punti deboli delle reti OT. Una finestra temporale consente di autorizzare un fornitore di servizi per quattro ore, un giorno o un periodo prestabilito, per poi chiudere automaticamente l’accesso.

Questo meccanismo riduce il rischio di dimenticare di revocare l’autorizzazione. Inoltre, fornisce una prova chiara: la connessione era autorizzata in un intervallo di tempo specifico, per un intervento identificato.

Microsegmentazione della rete OT

La microsegmentazione consiste nel suddividere la rete in aree più piccole e più gestibili. Limita la diffusione di un incidente e riduce i percorsi superflui verso le apparecchiature critiche.

Il tecnico della sede A non deve poter accedere alla sede B solo perché è connesso allo stesso concentratore VPN. La segmentazione deve essere applicata nella rete, non solo in un’applicazione.

Registri di audit per la conformità alle norme NIS2 e IEC 62443

I log sono indispensabili per dimostrare il controllo degli accessi. Servono per la gestione operativa, l’audit, l’analisi degli incidenti e la conformità interna.

Un log utile deve contenere almeno:

• Identità dell’utente.

• Organizzazione o ruolo correlato.

• Ora di inizio e di fine della sessione.

• Indirizzo IP di origine e di destinazione OT.

• Apparecchiatura o zona interessata.

• Regola di accesso applicata.

• Tentativi respinti.

• Modifica dei diritti o revoca.

• Eventi di connessione insoliti.

È necessario essere precisi riguardo alla portata: un gateway di rete può registrare le connessioni, i flussi e le regole applicate. La tracciabilità dettagliata delle modifiche interne a un controllore dipende anche dagli strumenti di ingegneria, dai registri dell’apparecchiatura e dalle procedure di modifica.

Avvisi in tempo reale sulle anomalie

Il modello "zero trust" non è solo un controllo all’ingresso. Deve generare segnali quando qualcosa si discosta dal comportamento previsto.

Esempi di avvisi pertinenti:

• Accesso fuori orario.

• Tentativo di accesso non autorizzato a un PLC.

• Ripetuti tentativi falliti di autenticazione.

• Connessione da una fonte insolita.

• Volume di traffico anomalo verso una zona OT.

• Utilizzo di un conto fornitore al di fuori di un intervento programmato.

• Modifica di una regola fondamentale.

Questi avvisi possono essere inviati tramite e-mail, webhook, sistema di monitoraggio, SIEM o strumento di gestione dei ticket, a seconda dell’organizzazione.

Isolamento d’emergenza

Quando viene rilevato un comportamento sospetto, il team deve essere in grado di agire rapidamente. L’isolamento di emergenza può consistere nel disattivare un account, revocare un certificato, disattivare una regola di accesso, isolare un gateway o bloccare un flusso verso una determinata area.

L’obiettivo non è quello di chiudere lo stabilimento al primo dubbio. Si tratta piuttosto di disporre di misure graduali, documentate e reversibili.

Integrazione SIEM e SOAR

Gli eventi Eziwan possono essere inviati a un sistema SIEM o a un sistema di monitoraggio della sicurezza per essere correlati con altri segnali: directory, EDR, firewall, log di Windows, eventi SCADA, avvisi di rete o ticket di intervento.

Questa integrazione aiuta il SOC a distinguere un intervento normale da un comportamento sospetto. Consente inoltre di attivare i playbook SOAR qualora l’organizzazione ne faccia uso: arricchimento degli avvisi, notifica, apertura di un ticket, revoca dell’accesso o richiesta di convalida.

Esempio di politica di accesso zero trust OT

Una politica "zero trust" deve essere comprensibile per i team OT e IT. Deve evitare regole implicite e descrivere chiaramente i diritti.

profils:
  automaticien_interne:
    authentification:
      mfa: obligatoire
      compte: nominatif
    ressources:
      - site: usine_nord
        zone: ligne_1
        equipements:
          - automate_s7_1500
          - ihm_ligne_1
        protocoles:
          - tia_portal
          - https
    horaires:
      autorise: heures_ouvrées
    journalisation: obligatoire

  prestataire_machine:
    authentification:
      mfa: obligatoire
      certificat: individuel
    ressources:
      - site: usine_nord
        zone: cellule_robotisee
        equipements:
          - plc_compactlogix
          - ihm_panelview
    fenetre_maintenance:
      debut: "2026-06-25T08:00:00+02:00"
      fin: "2026-06-25T12:00:00+02:00"
    journalisation: obligatoire
    expiration: automatique

Questa formalizzazione evita che i diritti di accesso siano troppo ampi. Inoltre, facilita la verifica, poiché ogni diritto è collegato a una giustificazione operativa.

Protocolli industriali: limiti e misure compensative

L’approccio "zero trust" per l’OT deve tenere conto dei protocolli effettivamente utilizzati. Alcuni protocolli industriali sono stati progettati per reti chiuse, con pochi o nessun meccanismo nativo di autenticazione e crittografia. Altri dispongono di varianti o configurazioni più sicure, ma queste non sono sempre disponibili sulle apparecchiature esistenti.

Protocollo o prassi	Rischio comune	Misura correttiva
Modbus/TCP	Comandi possibili se l’accesso alla rete è autorizzato	Filtraggio per IP, tunnel crittografato, segmentazione
EtherNet/IP	Individuazione e accesso estesi a seconda della topologia	Percorsi espliciti, regole per dispositivo
PROFINET	Sensibile alla topologia e ai flussi locali	Isolamento di zona, accesso di ingegneria controllato
OPC UA	Sicurezza dipendente da certificati e politiche	Certificati, crittografia, gestione degli account
Interfacce web HMI	Password deboli o obsolete	Autenticazione a più fattori (MFA) a monte, filtraggio, modifica controllata
RDP o VNC	Bersaglio frequente se esposto	Nessuna esposizione a Internet, accesso tramite gateway

Quando un controllore non può essere sottoposto direttamente al processo di hardening, è necessario rafforzare le misure di sicurezza che lo circondano: segmentazione, filtraggio, identità, supervisione, inventario e procedure di modifica.

Zero Trust, NIS2 e IEC 62443

NIS2 e IEC 62443 non sono sinonimi di "zero trust", ma i loro requisiti convergono su diversi punti: gestione del rischio, controllo degli accessi, segmentazione, registrazione degli eventi, gestione degli incidenti, continuità operativa e governance.

Un’architettura OT "zero trust" può contribuire al raggiungimento di questi obiettivi.

Requisito	Adozione di un approccio "zero trust" per l’OT
Gestione degli accessi	Account nominativi, MFA, revoca
Privilegio minimo	Diritti limitati per dispositivo e durata
Segmentazione	Zone OT isolate, canali controllati
Tracciabilità	Log di connessione, accessi negati e modifiche
Gestione dei fornitori	Accessi temporanei e verificabili per i fornitori
Risposta agli incidenti	Isolamento rapido, prove e procedure
Continuità	Accesso controllato senza esposizione diretta

La conformità non può essere dichiarata solo sulla base di uno strumento. Dipende dall’architettura complessiva, dalle procedure, dalle prove operative e dalla governance. Eziwan fornisce elementi tecnici utili per tradurre in pratica tali requisiti.

Ciclo di una connessione zero trust

Una connessione "zero trust" verso un dispositivo OT segue una sequenza ben definita: richiesta, autenticazione, verifica del contesto, autorizzazione, registrazione, accesso limitato, monitoraggio e chiusura.

Questa sequenza rende l’accesso comprensibile e verificabile. Evita il modello in cui una VPN aperta consente l’accesso a un’intera rete senza alcun contesto.

Gestione delle password OT

Le password predefinite, condivise o mai aggiornate rimangono un problema comune negli ambienti industriali. Il cambiamento deve tuttavia essere pianificato con cautela: alcune apparecchiature sono obsolete, alcuni account sono utilizzati dalle applicazioni e una modifica non testata può causare un’interruzione.

Un approccio realistico comprende:

• Inventario delle apparecchiature con autenticazione locale.

• Identificazione degli account predefiniti o condivisi.

• Classificazione in base alla criticità.

• Test di modifica su un’apparecchiatura non critica o durante una finestra di manutenzione.

• Documentazione delle dipendenze applicative.

• Archiviazione sicura delle informazioni riservate.

• Eliminazione degli account non necessari.

• Verifica periodica degli accessi dei fornitori di servizi.

Il modello "zero trust" riduce la dipendenza dalle password locali introducendo un controllo rigoroso a monte, ma non esime dal gestire gli account vulnerabili direttamente sui dispositivi stessi.

Risposta a un incidente OT

In caso di sospetta compromissione, i team devono sapere cosa fare prima che si verifichi la crisi. Il piano di risposta agli incidenti OT deve essere semplice, operativo e adeguato ai vincoli di produzione.

Le prime misure devono garantire la sicurezza delle persone e la continuità operativa a livello locale. Nell’OT, isolare un’apparecchiatura non significa sempre arrestarla. È necessario distinguere tra l’interruzione di un accesso remoto, l’isolamento di rete, il passaggio alla modalità locale e l’arresto della produzione.

Buone pratiche di implementazione

Un progetto OT "zero trust" deve essere implementato in modo graduale. È preferibile iniziare dagli accessi più esposti, per poi estendere la segmentazione e le regole.

• Mappare i siti, le aree, i controllori, le interfacce uomo-macchina (HMI), i sistemi SCADA, le postazioni di ingegneria e gli accessi esistenti.

• Individuare i fornitori di servizi e i costruttori che dispongono di un accesso remoto.

• Eliminare gli account condivisi il prima possibile.

• Implementare account nominativi e un sistema di autenticazione forte.

• Definire le zone OT e i condotti autorizzati.

• Limitare le regole in base all’attrezzatura, al protocollo e alla durata.

• Registrare gli accessi e i rifiuti.

• Provare gli strumenti professionali effettivi: TIA Portal, Control Expert, Studio 5000, OPC UA, interfacce web.

• Impostare avvisi che consentano di intervenire.

• Documentare le procedure di revoca e di emergenza.

• Verificare periodicamente i diritti.

Questo percorso consente di migliorare rapidamente la sicurezza senza imporre una radicale riorganizzazione della rete industriale.

Errori comuni da evitare

Confondere la VPN con il modello "zero trust"

Una VPN crittografa un tunnel, ma non garantisce alcun privilegio. Se la VPN consente l’accesso all’intera rete OT, non risolve il problema di fondo. Il modello "zero trust" impone regole precise per utente, dispositivo, protocollo e contesto.

Segmentare solo su carta

Uno schema di rete non è sufficiente. La segmentazione deve essere applicata secondo regole tecniche, testata, documentata e monitorata. È necessario verificare che un utente non autorizzato non possa accedere a un’area riservata.

Dimenticare i fornitori

I fornitori di servizi dispongono spesso di accessi sensibili, talvolta mantenuti per anni. Devono essere integrati nello stesso modello dei team interni: account nominativo, autenticazione a più fattori (MFA), finestra temporale, ambito limitato e registri.

Cercare la perfezione prima di agire

L’implementazione completa del modello "zero trust" può richiedere tempo. È meglio iniziare eliminando gli accessi condivisi, chiudendo gli accessi permanenti non necessari e registrando le connessioni critiche, piuttosto che rimandare qualsiasi azione in attesa di un’architettura ideale.

Trascurare i test di business

Una regola troppo rigida può bloccare uno strumento di ingegneria o un sistema di supervisione. Ogni regola deve essere testata con le applicazioni reali, in un contesto controllato, insieme ai team interessati.

Lista di controllo per la maturità del modello Zero Trust OT

Settore	Domanda	Priorità
Inventario	I controllori logici, le interfacce uomo-macchina (HMI), i sistemi SCADA e gli accessi remoti sono stati censiti?	Alta
Identità	Ogni utente dispone di un account nominativo?	Alta
MFA	L’autenticazione forte è attivata per l’accesso remoto?	Alta
Privilegio minimo	I diritti sono limitati alle apparecchiature necessarie?	Alta
Fornitori	Gli accessi esterni scadono automaticamente?	Alta
Segmentazione	Le zone OT sono isolate per impostazione predefinita?	Alta
Log	Le connessioni e i tentativi di accesso negati vengono registrati?	Alta
Avvisi	Le anomalie generano notifiche utilizzabili?	Media
Revoca	È possibile revocare rapidamente un accesso?	Alta
Incidente	Esiste una procedura di contenimento OT?	Alta
Audit	Le prove sono esportabili a fini di controllo?	Media

Questa checklist offre un punto di partenza concreto per valutare la situazione di un sito e stabilire le priorità d’intervento.

In che modo Eziwan contribuisce a proteggere i controllori industriali

Eziwan funge da punto di controllo tra gli utenti remoti e le reti OT. La soluzione contribuisce a sostituire gli accessi impliciti con accessi espliciti, controllati e tracciabili.

Richiesta OT	Risposta Eziwan	Vantaggio
Accesso remoto sicuro	Tunnel crittografati e account nominativi	Meno accessi condivisi
Privilegi ridotti	Regole per dispositivo o zona	Riduzione della superficie di attacco
Fornitori di servizi	Finestre temporali e revoca	Fine degli accessi permanenti dimenticati
Segmentazione	Gateway tra zone e canali	Isolamento dei perimetri critici
Audit	Log di sessione ed eventi	Prove per indagini e conformità
Incidenti	Disattivazione rapida degli accessi	Contenimento più semplice
Monitoraggio	Avvisi e integrazione SIEM	Rilevamento più rapido
Continuità	Architettura controllata	Manutenzione remota senza esposizione diretta

Questo approccio consente alle aziende del settore industriale di rafforzare la sicurezza dei controllori logici programmabili (PLC), dei sistemi SCADA e delle apparecchiature OT senza rinunciare alla manutenzione da remoto.

Conclusione

La sicurezza informatica "zero trust" dei controllori industriali non è solo uno slogan: è un metodo concreto per limitare gli accessi, ridurre i privilegi, segmentare le reti, tracciare le connessioni e reagire più rapidamente in caso di incidente. Nelle reti OT, dove non sempre è possibile applicare rapidamente le patch alle apparecchiature e dove la disponibilità rimane una priorità, questo approccio offre una protezione realistica e graduale.

Eziwan aiuta ad attuare questo modello con accessi nominativi, tunnel sicuri, regole per dispositivo, finestre di manutenzione, registri di audit, avvisi e isolamento rapido. Per le aziende industriali soggette ai requisiti NIS2, IEC 62443 o a vincoli interni di sicurezza informatica, si tratta di un modo pragmatico per trasformare i principi dello zero trust in controlli operativi sul campo.

Per approfondire

• Cybersicurezza industriale — i fondamenti della sicurezza OT e le buone pratiche sul campo
• VPN classica vs accesso remoto industriale — perché l’approccio zero trust supera la VPN tradizionale in ambito OT
• Accesso remoto industriale — implementate un accesso remoto senza esporre le porte pubbliche
• NIS2 per l’industria — allineate la vostra strategia zero trust agli obblighi NIS2
• Cybersicurezza dell’accesso remoto OT — Proteggete in modo specifico gli accessi remoti alle vostre reti OT