Uno switch Ethernet gestito in una rete SCADA o DCS è più di un moltiplicatore di porte. Controlla i percorsi del traffico, espone informazioni diagnostiche e può limitare o amplificare l’effetto di un errore di configurazione.

L’obiettivo ingegneristico non è utilizzare il massimo numero di funzionalità. È garantire comunicazioni prevedibili, accesso alla gestione limitato e prove sufficienti per diagnosticare i guasti senza disturbare il processo.

Un’architettura a livelli separa il controllo sul campo, i sistemi di supervisione, le operazioni del sito e lo scambio di dati aziendali.

Iniziare dal traffico e dalle conseguenze

Documentare ogni controller, HMI, historian, workstation di engineering, gateway e percorso di accesso remoto prima di modificare le impostazioni dello switch. Registrare i protocolli richiesti, i peer, le frequenze di aggiornamento, il comportamento multicast e le aspettative di ripristino.

Questo inventario trasforma la segmentazione in una decisione ingegneristica. Una VLAN da sola non costituisce un confine di sicurezza, a meno che le regole di routing e firewall non impongano i percorsi di comunicazione previsti.

La norma NIST SP 800-82 Rev. 3 descrive la sicurezza OT nel contesto di prestazioni, affidabilità e sicurezza. Anche le linee guida CISA sottolineano la segmentazione e lo scambio controllato di dati tra i sistemi critici e i servizi aziendali.

Separare la gestione dal traffico di processo

Collocare le interfacce di gestione degli switch in una rete di gestione dedicata. Consentire l’accesso solo dagli host di amministrazione autorizzati, attraverso firewall o liste di controllo degli accessi definiti.

Disabilitare i servizi di gestione inutilizzati. Preferire SSH e HTTPS quando lo switch li supporta. Evitare Telnet e HTTP non cifrato, perché le credenziali e le sessioni potrebbero essere esposte.

Cambiare le credenziali predefinite, utilizzare account nominativi e applicare autorizzazioni basate sui ruoli. L’autenticazione centralizzata può migliorare la tracciabilità, ma lo stabilimento ha anche bisogno di un metodo di ripristino documentato quando il servizio di autenticazione non è disponibile.

Proteggere l’accesso locale

L’accesso tramite console rimane prezioso durante la messa in servizio e in caso di guasto della rete. L’accesso fisico deve quindi essere controllato e le credenziali locali non devono essere condivise con leggerezza.

Una configurazione salvata non deve contenere password dimostrative o impostazioni predefinite del fornitore. Conservare le credenziali di ripristino secondo la procedura di accesso approvata dal sito.

Utilizzare una segmentazione coerente con le operazioni

Raggruppare i dispositivi in base alla funzione, alle conseguenze e alle esigenze di comunicazione. Tra gli esempi rientrano le celle dei controller, i sistemi di protezione, i server di supervisione, le apparecchiature legate alla sicurezza e gli accessi per la manutenzione.

Non creare una VLAN di stabilimento piatta semplicemente perché tutti i dispositivi utilizzano Ethernet industriale. In questo modo, una workstation compromessa o una tempesta di broadcast potrebbe raggiungere apparecchiature che non hanno mai avuto bisogno di comunicare direttamente.

Una VLAN di gestione dovrebbe essere raggiungibile solo attraverso percorsi di amministrazione approvati.

Quando sono presenti protocolli multicast, verificare lo snooping IGMP, il posizionamento del querier e il comportamento della ridondanza. Un’architettura multicast errata può sovraccaricare le porte o interrompere l’I/O anche quando i test unicast ordinari hanno esito positivo.

Le interfacce e l’hardware gateway pertinenti possono essere esaminati nella collezione Comunicazione e networking. Le piattaforme di controllo sono raggruppate in Sistemi PLC e PAC.

Progettare la ridondanza come un sistema

I collegamenti ridondanti richiedono un protocollo documentato e un tempo di convergenza verificato. Aggiungere cavi paralleli senza protezione dai loop può creare una tempesta di broadcast invece di aumentare la resilienza.

Verificare se la rete utilizza Rapid Spanning Tree, un protocollo ad anello del fornitore, il Media Redundancy Protocol o un altro metodo. Confermare la compatibilità tra tutti gli switch partecipanti.

Testare il guasto di un cavo, la perdita di alimentazione di uno switch, il ripristino di una porta bloccata e il ripristino del servizio. Registrare la perdita di pacchetti e il comportamento dei controller, non solo il tempo di convergenza dichiarato dallo switch.

La registrazione degli eventi e la sincronizzazione temporale favoriscono la diagnosi

Quando possibile, inviare gli eventi dello switch a un sistema di logging protetto. Tra gli eventi utili rientrano le variazioni di collegamento, i tentativi di autenticazione falliti, le modifiche alla configurazione, le transizioni della topologia e gli allarmi di alimentazione.

Un’ora coerente è essenziale. Senza orologi sincronizzati, un operatore non può correlare in modo affidabile una transizione dello switch con i guasti dei PLC, gli allarmi HMI o gli eventi del firewall.

SNMP deve essere configurato con attenzione. Limitare le stazioni di gestione e utilizzare, quando supportate, versioni autenticate e cifrate. Evitare di esporre ampi privilegi di scrittura.

Mettere in servizio le modifiche senza creare rischi nascosti

Eseguire il backup della configurazione in esecuzione prima di iniziare i lavori. Registrare il modello dello switch, il firmware, la configurazione attiva, le porte collegate e il metodo di rollback.

Applicare le modifiche durante una finestra approvata. Convalidare le comunicazioni di processo, la trasmissione degli allarmi, gli aggiornamenti dell’historian, la ridondanza, l’accesso remoto e la sincronizzazione temporale dopo ogni passaggio importante.

Gli aggiornamenti del firmware richiedono la stessa disciplina delle modifiche ai controller. Esaminare gli avvisi del fornitore, testare in laboratorio la versione prevista e confermare la disponibilità di un’immagine di ripristino.

Opinione dell’autore: gli switch gestiti creano valore quando la loro configurazione è comprensibile e ripristinabile. Un’architettura complessa senza responsabilità definite, backup e comportamento in caso di guasto verificato è più difficile da gestire di una rete più semplice e documentata.