La network segmentation OT è uno dei temi più citati quando si parla di sicurezza degli ambienti industriali, ma anche uno dei meno compresi nella pratica quotidiana di fabbrica. Tutti concordano sul fatto che “segmentare la rete” riduca i rischi, ma tra celle, linee, zone, VLAN e micro segmentazione il confine tra una protezione efficace e un’architettura inutilmente complessa è spesso sottile.
In un contesto in cui la convergenza IT/OT espone impianti e macchine a minacce sempre più simili a quelle del mondo IT, dividere correttamente la rete non serve a blindare tutto, ma a limitare l’impatto di ciò che inevitabilmente accade.
È su questo approccio pragmatico che ci muoviamo, grazie alla partnership con Secomea, supportando le aziende nella progettazione di architetture OT segmentate e nell’accesso remoto sicuro agli impianti, senza compromettere operatività e continuità produttiva.
Perché la network segmentation OT è diventata indispensabile nella cybersecurity OT
La network segmentation OT fa la differenza tra un problema circoscritto e un fermo esteso.
Il motivo è semplice: quando un hacker riesce a entrare (da IT verso OT, da un accesso remoto troppo permissivo, o da un endpoint di reparto), l’obiettivo non è quasi mai restare fermo su un solo dispositivo. Quello che fa davvero danno è il movimento laterale, cioè la capacità di spostarsi da un asset all’altro finché non trova il punto più critico (HMI, engineering workstation, server di supervisione, ecc.). Una segmentazione della rete fatta bene serve proprio a spezzare questo percorso, creando “barriere” e regole chiare tra parti diverse dell’impianto.
Nell’OT, però, la segmentazione non può essere copiata pari pari dal mondo IT. In produzione non segmenti solo per “funzione informatica”, ma per impatto operativo: una cella robotizzata, una linea di confezionamento e un’utility (aria compressa, HVAC, energia) hanno rischi e priorità diverse. E soprattutto hanno esigenze di comunicazione diverse: alcuni flussi sono essenziali e non negoziabili, altri esistono solo perché “si è sempre fatto così”. Qui entra in gioco una logica molto concreta: dividere in zone coerenti (celle/linee/reparti/servizi) e poi controllare i collegamenti tra zone con policy granulari, invece di lasciare passaggi “aperti” che trasformano l’intera rete OT in un unico grande dominio di propagazione.
Un altro equivoco comune è pensare che basti creare delle VLAN e chiamarla “segmentazione”. In realtà la security OT non è fatta dalle etichette di rete, ma da ciò che permetti o neghi tra i segmenti: quali protocolli possono passare, da quali sorgenti a quali destinazioni, con quali identità e con quale tracciamento. Se non governi il traffico tra segmenti, hai solo disegnato confini sulla carta.
Infine, c’è un tema di priorità: molte aziende saltano subito alla microsegmentazione sperando sia la scorciatoia “più sicura”, ma senza visibilità sui flussi reali finiscono per creare eccezioni su eccezioni (e il risultato è più fragile, non più robusto).
Nella pratica, la segmentazione OT efficace nasce in modo progressivo: si parte dal contenere i rischi maggiori (zone ben scelte e conduits essenziali), e solo dopo si aumenta il livello di granularità dove serve davvero.
Segmentazione della rete: il principio “zone & conduits” per fabbriche reali
Quando si parla di segmentazione della rete in ambito industriale, l’errore più comune è partire “dall’alto” (core switch, VLAN, subnet) invece che partire dal processo produttivo. In OT, infatti, la segmentazione funziona solo se riflette come lavora davvero la fabbrica: quali macchine fanno parte della stessa cella, quali asset devono comunicare con la supervisione, quali servizi sono condivisi tra linee diverse e, soprattutto, quali comunicazioni sono necessarie e quali sono solo “comodità” stratificate nel tempo.
Il modello più utile per ragionare in modo concreto è quello a zone (insiemi omogenei) e conduits (i collegamenti controllati tra zone).
Tradotto: prima decidi cosa deve stare insieme; poi decidi quali flussi possono attraversare i confini. È qui che la security OT smette di essere un’idea astratta e diventa una scelta progettuale misurabile: se un hacker entra in un punto, quanto lontano può arrivare prima di essere bloccato?
Come definire le zone: celle, linee, reparti, utility e servizi condivisi
Una “zona” OT non è per forza un reparto fisico: è un insieme di asset che condividono rischio, funzione e necessità di comunicazione. In pratica, molte fabbriche finiscono per usare 4–6 categorie di zone ricorrenti (poi adattate caso per caso):
- Zona cella: robot, PLC della cella, I/O remoti, safety controller (se presente), HMI locali. È l’unità più “naturale” perché spesso ha confini tecnici chiari e un impatto operativo specifico.
- Zona linea: più celle coordinate, con supervisione di linea (HMI di linea, gateway, eventuali server locali di ricetta/parametri). Qui di solito i flussi aumentano e serve più disciplina.
- Zona supervisione / SCADA: sistemi di supervisione, historian, server applicativi OT, console operative. È una zona critica perché concentra visibilità e controllo.
- Zona engineering: workstation di programmazione, strumenti di manutenzione, repository di progetti PLC, tool vendor. Spesso è la zona “più pericolosa” se non governata, perché ha privilegi elevati.
- Zona DMZ OT: punto di interscambio controllato tra OT e IT (reporting, MES/ERP, accesso remoto, jump host). È il posto in cui “si decidono” i confini in modo consapevole.
- Zona utility / infrastrutture di stabilimento: energia, HVAC, trattamento acqua, aria compressa, building management. A volte sono tecnicamente OT, ma con priorità e profili di rischio diversi dalla linea.
Un criterio pratico per non sbagliare è chiedersi: se questa parte si fermasse o venisse alterata, quali conseguenze avrei (sicurezza fisica, qualità, downtime, scarti, impianto)?
Se le conseguenze sono simili, probabilmente è una buona candidata per stare nella stessa zona. Se sono molto diverse, conviene separare.
Come definire i conduits: quali flussi servono davvero e quali vanno negati di default
Il “conduit” è il collegamento tra due zone, ma non va inteso come “cavo” o “trunk”: è un insieme di regole. Qui la cybersecurity OT diventa operativa, perché decidi chi parla con chi, come e perché.
Un modo semplice (e molto efficace) per progettare i conduits senza impazzire è questo:
- Mappa i flussi minimi vitali
-
- I sistemi di supervisione devono poter comunicare con i PLC solo per la lettura degli stati e, dove strettamente necessario, per la scrittura dei comandi.
- Le HMI dialogano con i PLC esclusivamente per garantire l’operatività locale della linea o della cella.
- Gli historian accedono alle sorgenti dati principalmente in modalità di sola lettura, evitando qualsiasi interazione non indispensabile.
- I sistemi MES comunicano con l’ambiente OT limitandosi ai servizi realmente necessari, preferibilmente attraverso una DMZ OT che ne controlli e tracci gli scambi.
- Trasforma i flussi in regole “allowlist”
In OT funziona meglio autorizzare solo ciò che serve (protocollo/porta, sorgente, destinazione), invece di bloccare “quasi tutto” e poi lasciare eccezioni indefinite. - Riduci i percorsi trasversali
Una regola d’oro: una cella non dovrebbe poter parlare liberamente con un’altra cella di un’altra linea “solo perché è sulla stessa rete”. - Metti i servizi condivisi dove hanno senso
DNS/NTP/patch server o repository non dovrebbero diventare “ponti” involontari tra zone. Se sono condivisi, vanno collocati in una zona dedicata e raggiunti con regole molto specifiche. - Traccia e rendi verificabile
Un conduit ben progettato non è “set and forget”: deve essere monitorabile. Se improvvisamente compaiono nuovi flussi, è un segnale (errore di configurazione, nuova esigenza reale, o attività sospetta).
Microsegmentazione in OT: quando serve davvero?
La microsegmentazione è spesso presentata come “il livello successivo” della segmentazione della rete: invece di separare solo per zone (cella/linea/reparto), arrivi a definire regole molto granulari tra singoli asset o gruppi ristretti (ad esempio: quel PLC parla solo con quell’HMI e con nient’altro). In teoria è il paradiso della cybersecurity OT: riduce al minimo le superfici di contatto e rende molto più difficile per un hacker muoversi lateralmente.
Nella pratica, però, la microsegmentazione in OT funziona solo se rispetta una regola non negoziabile: non deve diventare un freno operativo. Se la progetti “a tavolino” senza conoscere i flussi reali, il risultato tipico è una rete piena di eccezioni urgenti (“sblocca questa porta che la linea è ferma”), con policy sempre meno coerenti. E quando le eccezioni si accumulano, la security OT si indebolisce invece di rafforzarsi.
Differenza pratica tra segmentazione “a zone” e microsegmentazione “per asset”
Per decidere con lucidità, è utile distinguere obiettivo e granularità:
- Segmentazione a zone (zone & conduits)
Obiettivo: contenere l’impatto e impedire che un problema in una parte si propaghi ovunque.
Granularità: “questa linea parla con SCADA solo in questi modi”, “questa cella non parla con le altre celle”, “l’engineering passa solo da un punto controllato”. - Microsegmentazione (per asset o micro-gruppi)
Obiettivo: ridurre al minimo anche i movimenti interni alla zona, limitando i percorsi possibili anche dentro una singola linea o cella.
Granularità: “questa HMI parla solo con questi PLC”, “questo server OT parla solo con questi servizi”, “questo gateway non può iniziare nuove connessioni verso l’esterno”.
In altre parole: la segmentazione a zone ti dà subito un grande beneficio “strutturale”; la microsegmentazione ti dà un beneficio “di precisione”, ma richiede più maturità, visibilità e manutenzione continua.
Quando la microsegmentazione ha davvero senso in OT?
Ci sono alcuni casi in cui la microsegmentazione è particolarmente efficace (e spesso vale l’investimento):
- Asset ad alto impatto: HMI/SCADA, engineering workstation, server di ricette/parametri, historian, sistemi che se compromessi possono alterare setpoint o causare fermi. Qui restringere “chi può parlare con chi” è puro valore.
- Linee con molte interdipendenze: dove un singolo segmento “troppo largo” crea percorsi laterali facili. Microsegmentare alcuni snodi (gateway, server locali, HMI di linea) riduce i rischi senza dover micro-segmentare tutto.
- Accesso remoto e manutenzione: se ci sono vendor o manutentori che devono connettersi, è spesso più sensato microsegmentare i punti di ingresso e i sistemi raggiungibili, invece di lasciare accessi “a zona intera”.
- Ambienti con asset legacy e protocolli fragili: non sempre puoi “patchare”; allora compensi con controllo dei flussi e isolamento più spinto dove serve.
Quando è overkill (e rischia di peggiorare le cose)?
- Quando manca una mappa dei flussi reali: se non sai cosa comunica davvero, microsegmentare significa indovinare. E in OT “indovinare” si paga con downtime.
- Quando la governance non è pronta: la microsegmentazione è un sistema vivo. Se non hai ownership chiara (IT/OT/produzione), processo di change e revisione periodica, le regole diventano rapidamente incoerenti.
- Quando provi a microsegmentare tutto subito: è la ricetta per l’effetto opposto. Meglio ottenere un’ottima segmentazione della rete “a zone” e poi microsegmentare solo i punti critici.
Un criterio pratico (molto utile) per decidere è chiedersi questo: se un hacker compromettesse questo dispositivo, quante cose potrebbe raggiungere e quanto danno potrebbe fare prima di essere fermato?
Se la risposta è “molte”, la microsegmentazione è una leva concreta. Se la risposta è “poche e già contenute dalla zona”, probabilmente non serve complicare.
Security OT by design: regole minime che devono esistere tra una zona e l’altra
Una buona segmentazione della rete non è (solo) una questione di “dove metto i confini”, ma di quali regole applico tra i confini. In OT questo punto è cruciale: puoi avere zone disegnate benissimo, ma se tra una zona e l’altra passa “di tutto”, la rete resta di fatto piatta. La security OT si misura quindi in modo molto concreto: quante comunicazioni sono davvero necessarie per far funzionare produzione e manutenzione, e quante invece esistono solo perché nessuno le ha mai messe in discussione.
Ecco le regole minime che, nella pratica, rendono la segmentazione efficace e sostenibile nel tempo (senza bloccare l’operatività).
- Approccio allowlist tra zone
Tra due zone dovresti autorizzare solo ciò che serve: sorgente, destinazione, protocollo e porta. È il modo più rapido per ridurre il “rumore” e impedire percorsi laterali indesiderati. In ottica di cybersecurity OT, è anche la differenza tra un incidente circoscritto e uno che attraversa reparti e linee. - Un punto di interscambio controllato tra IT e OT (DMZ OT)
Se IT e OT devono parlarsi (per MES, report, qualità, manutenzione, ecc.), la regola d’oro è evitare collegamenti diretti “a ragnatela”. La DMZ OT serve proprio a questo: concentrare e governare gli scambi, con servizi intermedi (ad esempio proxy, jump, server di integrazione) e policy chiare. Così non trasformi ogni eccezione in un buco permanente. - Accesso remoto “a percorso obbligato”, non libero in rete
Il pattern più sano è: accesso remoto verso un punto controllato (jump/bastion), autenticazione forte, sessioni tracciate, e da lì solo verso gli asset autorizzati. È qui che spesso la microsegmentazione può avere un ruolo mirato: non per microsegmentare tutto, ma per limitare con precisione cosa può raggiungere chi entra per manutenzione. - Identità e privilegi coerenti con le zone
Un errore tipico è trattare tutti gli utenti tecnici come “super-user” ovunque. In un modello a zone, anche i privilegi dovrebbero essere zonizzati: chi deve operare su una linea non dovrebbe avere visibilità o controllo sulla linea accanto “per comodità”. Questo riduce molto il rischio che una singola credenziale apra troppe porte. - Logging e rilevamento pensati per l’OT
Segmentare senza osservare è come mettere porte senza serratura. Servono almeno: registrazione dei cambi di policy, tracciamento delle sessioni remote, alert quando compaiono nuovi flussi tra zone (specie se non previsti). Non è solo “monitoraggio”: è controllo continuo della segmentazione, perché le reti OT cambiano sempre (nuovi macchinari, nuove ricette, nuovi fornitori). - Gestione delle eccezioni con una regola semplice: ogni eccezione ha un motivo e una scadenza
La segmentazione si rovina quasi sempre così: “apriamo questa porta al volo” e nessuno la richiude più. Un processo minimo (ticket + motivazione + owner + data di revisione) mantiene la security OT compatibile con la realtà della produzione, senza perdere il controllo.
Se metti in fila queste regole, la segmentazione della rete smette di essere un progetto “di architettura” e diventa un sistema operativo quotidiano: le zone sono stabili, i collegamenti sono pochi e giustificati, e ogni cambiamento lascia traccia.
Gli 8 errori tipici nella segmentazione della rete OT (che peggiorano la sicurezza o fermano la produzione)
La segmentazione della rete in OT fallisce raramente per mancanza di “tecnologia”: più spesso fallisce per scelte progettuali frettolose o per compromessi non governati. E la conseguenza è doppia: o la segmentazione resta solo sulla carta (quindi la cybersecurity OT non migliora davvero), oppure diventa così rigida da creare attriti continui con produzione e manutenzione.
Gli errori più frequenti sono questi:
- Confondere VLAN con segmentazione reale
Le VLAN separano a livello logico, ma se non esistono policy rigorose tra i segmenti (chi può parlare con chi, su quali protocolli), la rete resta “piatta” dal punto di vista della sicurezza. È un classico caso di “sembra segmentata, ma non lo è”. - Creare zone troppo grandi (o troppo generiche)
“Zona produzione” è un contenitore enorme: se ci finisce dentro di tutto (celle, linee, SCADA, engineering), hai vanificato il principio di contenimento. Una buona security OT nasce da zone coerenti per impatto e funzione, non da macro-gruppi comodi. - Microsegmentazione troppo presto, senza visibilità sui flussi
Spingersi subito sulla microsegmentazione senza conoscere traffico e dipendenze porta a blocchi imprevisti e a una pioggia di eccezioni d’emergenza. Il risultato tipico è una regola non gestita: più eccezioni = meno controllo = meno sicurezza. - Eccezioni “temporanee” che diventano permanenti
In OT succede spesso: “apriamo questa porta che dobbiamo far ripartire la linea”. Se non c’è un minimo processo (motivazione, owner, scadenza e revisione), col tempo le eccezioni ricostruiscono di fatto una rete piatta. È uno dei modi più comuni in cui la segmentazione si degrada. - Permettere percorsi laterali non necessari tra celle/linee
Collegamenti “trasversali” tra linee diverse o tra celle che non dovrebbero parlarsi sono autostrade per il movimento laterale. Se l’obiettivo è contenere, ogni collegamento tra zone va giustificato: se non serve al processo, è un rischio. - Accesso remoto troppo ampio (o non tracciato)
Se manutentori o fornitori entrano e possono “vedere tutta la rete” (o muoversi liberamente), la segmentazione perde senso. L’accesso remoto deve essere a percorso obbligato, con autorizzazioni limitate, e sessioni tracciate: è una misura concreta di security OT, non burocrazia. - Mettere servizi condivisi in mezzo alle zone senza proteggerli
DNS/NTP, server di file, repository, strumenti di gestione: se diventano ponti tra segmenti, amplificano il rischio. I servizi condivisi devono stare in una zona dedicata e raggiungibile solo con regole specifiche. - Assumere che “una volta fatto, è finito”
Le reti OT cambiano: nuove macchine, nuove integrazioni, nuove esigenze di report o qualità. Se la segmentazione non viene rivista periodicamente (anche solo controllando nuovi flussi e nuove eccezioni), col tempo perde efficacia. La cybersecurity OT qui è disciplina operativa, non un progetto one-shot.
Se eviti questi errori, ottieni due risultati insieme: una segmentazione che regge anche quando la fabbrica cambia, e una security OT che non vive di “regole perfette” ma di controlli chiari, verificabili e mantenibili.
Roadmap in 5 step per passare dalla teoria alla segmentazione OT operativa
Rendere operativa la network segmentation OT non significa rifare la rete da zero o fermare la produzione per settimane. Nella maggior parte dei casi, funziona molto meglio un percorso progressivo, che aumenta il livello di security OT passo dopo passo, partendo dai rischi reali e non da modelli teorici.
- Visibilità prima di tutto
Prima di segmentare, devi sapere cosa esiste e come comunica: asset OT, protocolli, flussi tra celle, linee, supervisione e IT. Senza questa base, ogni scelta di segmentazione della rete è un’ipotesi. - Definizione delle zone a maggior impatto
Parti dalle aree più critiche (linee principali, SCADA, engineering, utility) e crea zone coerenti per funzione e rischio. Anche una segmentazione “grossolana ma corretta” riduce subito le superfici di propagazione. - Controllo dei collegamenti essenziali (conduits)
Trasforma i flussi necessari in regole chiare e verificabili. Tutto ciò che non è esplicitamente necessario resta fuori. È qui che la cybersecurity OT inizia davvero a fare la differenza. - Raffinamento mirato con microsegmentazione
Solo dopo, e solo dove serve, aumenta la granularità: proteggi gli asset più sensibili, limita l’accesso remoto, riduci i percorsi interni più rischiosi. La microsegmentazione diventa così uno strumento di precisione, non un peso operativo. - Governance e miglioramento continuo
Ogni eccezione deve avere un motivo e una revisione. Ogni nuovo flusso va capito. La segmentazione non è statica: evolve insieme alla fabbrica, senza perdere coerenza.
Questo approccio permette di migliorare concretamente la security OT senza compromettere continuità produttiva e manutenzione.
Se vuoi capire come applicarlo nel tuo contesto industriale, Innovio, anche grazie alla partnership con Secomea, supporta le aziende nella progettazione e messa in sicurezza di architetture OT segmentate e accessi remoti controllati. Contattaci per una valutazione mirata.
