L'accesso remoto agli impianti industriali non e una novita. Da anni i vendor, i system integrator, i manutentori e i reparti interni si collegano a PLC, HMI, SCADA e reti OT da remoto. Il problema non e se farlo o meno: e come viene fatto nella pratica. E nella pratica, su moltissimi impianti, la situazione e molto lontana da quella che qualsiasi guida di sicurezza raccomanderebbe.
Il punto non e la tecnologia in se. VPN, jump host, piattaforme di teleassistenza, connessioni dirette: ogni strumento puo essere usato bene o male. Il problema reale e la mancanza di architettura, cioe l'assenza di regole chiare su chi si collega, come, quando, con quali permessi, con quale tracciabilita e con quale possibilita di intervento in caso di incidente.
Perche l'accesso remoto e un tema critico in OT
In IT, l'accesso remoto e un'operazione quotidiana gestita con strumenti consolidati: VPN aziendali, identity provider, MFA, policy di gruppo. In OT la situazione e diversa per almeno tre ragioni strutturali.
La prima e che i sistemi raggiungibili da remoto — PLC, HMI, SCADA, engineering station — controllano processi fisici. Una modifica errata o un accesso non autorizzato puo provocare un fermo linea, un guasto, un pericolo per la sicurezza delle persone. Non si tratta di dati: si tratta di attuatori, motori, valvole, sequenze operative.
La seconda e che in OT convivono sistemi con cicli di vita molto lunghi. E frequente trovare PLC con firmware di dieci o quindici anni fa, HMI su Windows non piu supportato, switch industriali senza funzionalita di autenticazione. L'accesso remoto deve fare i conti con questi vincoli, non ignorarli.
La terza e che l'accesso remoto in OT coinvolge spesso soggetti esterni: vendor di macchine, integratori, manutentori specializzati, fornitori di software. Ognuno con il proprio tool di collegamento, le proprie credenziali, le proprie abitudini. Coordinare tutto questo senza una struttura chiara e il modo piu rapido per perdere il controllo.
Gli errori piu frequenti: quello che si vede sugli impianti
Chi lavora su impianti esistenti riconosce subito questi pattern. Non sono eccezioni: sono la norma in molti stabilimenti, soprattutto dove l'accesso remoto e cresciuto in modo incrementale senza un progetto complessivo.
VPN sempre attiva verso la rete OT
La VPN viene configurata durante il commissioning o per un intervento di manutenzione. Funziona, il problema viene risolto, e la VPN resta li. Nessuno la disattiva, nessuno la rivede. A volte il tunnel e site-to-site, a volte e un client installato su un PC del fornitore. In entrambi i casi, la connessione permanente trasforma un accesso temporaneo in un canale aperto 24 ore su 24 verso la rete di impianto.
Il rischio non e solo l'accesso diretto: e che il PC del fornitore, collegato alla propria rete aziendale e a Internet, diventa un ponte tra il mondo esterno e la rete OT. Se quel PC viene compromesso, l'attaccante ha un percorso diretto verso il cuore dell'impianto.
Credenziali condivise e senza scadenza
Un classico: l'account VPN o l'utenza di accesso al pannello HMI e una sola per tutto il team del fornitore. Magari la password e stata impostata cinque anni fa, comunicata via email, mai cambiata. Chi ha lavorato sull'impianto e poi cambiato azienda conserva ancora le credenziali.
Senza utenze nominali, non c'e modo di sapere chi ha fatto cosa. Senza scadenza, non c'e modo di revocare un accesso che non serve piu. Senza MFA, basta la password per entrare.
Tool di teleassistenza installati direttamente sui dispositivi
Alcuni vendor installano il proprio software di teleassistenza direttamente sull'HMI, sull'IPC o sulla engineering station. TeamViewer, AnyDesk, software proprietari del costruttore di macchina: ognuno con la propria logica, il proprio canale, le proprie credenziali. Il risultato e che la rete OT ha piu punti di ingresso di quanti il responsabile di stabilimento immagini, ognuno gestito in modo indipendente.
In alcuni casi questi software bypassano completamente il firewall di confine, perche usano connessioni in uscita verso server cloud del vendor. Formalmente non c'e nessuna "porta aperta" nel firewall, ma il canale esiste lo stesso.
Nessun logging e nessuna tracciabilita
Anche quando l'accesso remoto e tecnicamente funzionante, spesso manca qualsiasi forma di registrazione. Non si sa chi si e collegato, quando, per quanto tempo, cosa ha fatto. Se un PLC viene modificato durante una sessione remota e il giorno dopo la linea ha un comportamento anomalo, ricostruire la catena causale diventa molto difficile senza log.
Accesso diretto al livello di campo senza segmentazione
L'errore forse piu grave: l'utente remoto atterra direttamente nella rete dove risiedono PLC, drive, I/O remoti, senza passare per alcun punto di controllo intermedio. Nessun jump host, nessuna DMZ, nessuna restrizione sui protocolli raggiungibili. Da remoto si puo fare tutto cio che si potrebbe fare fisicamente davanti al quadro.
L'architettura di riferimento: principi prima dei prodotti
Prima di scegliere un prodotto o una piattaforma, servono principi architetturali chiari. L'accesso remoto sicuro in OT non si ottiene aggiungendo un tool, ma progettando un percorso controllato tra l'esterno e i sistemi di impianto.
Separazione netta tra rete OT e punto di accesso remoto
L'utente remoto non deve mai atterrare direttamente nella rete OT. Deve passare attraverso una zona intermedia — una DMZ industriale o un segmento dedicato — dove risiedono i servizi di accesso: jump host, terminal server, gateway di teleassistenza. Da li, l'accesso verso i dispositivi OT avviene in modo controllato, limitato e tracciabile.
Questo principio e alla base di ogni architettura di riferimento seria, da IEC 62443 a NIST SP 800-82. Non e un'invenzione recente, ma nella pratica resta poco applicato.
Jump host o bastion host come punto di transito obbligato
Il jump host e una macchina (fisica o virtuale) posizionata nella DMZ industriale, attraverso la quale l'operatore remoto deve passare per raggiungere i sistemi OT. Sul jump host si concentrano i controlli: autenticazione, MFA, logging delle sessioni, restrizione dei protocolli e delle destinazioni raggiungibili, timeout di inattivita.
Il vantaggio e doppio. Da un lato, il jump host diventa l'unico punto di ingresso verso la rete OT, semplificando la difesa. Dall'altro, consente di registrare e controllare tutto cio che passa, senza dover installare agent o software aggiuntivi su ogni dispositivo OT — cosa che in molti casi non e nemmeno possibile.
Un jump host efficace per l'accesso remoto OT dovrebbe prevedere almeno: autenticazione forte (MFA), sessioni con timeout, logging degli accessi e delle attivita, restrizione delle destinazioni raggiungibili (non tutta la rete OT), aggiornamento regolare del sistema operativo, backup della configurazione. Se possibile, registrazione video o testuale delle sessioni per audit e troubleshooting.
Autenticazione forte e utenze nominali
Ogni persona che accede da remoto deve avere un'utenza personale. Niente account condivisi, niente "user: vendor / password: vendor2020". L'autenticazione deve prevedere almeno due fattori (MFA): qualcosa che l'utente conosce e qualcosa che possiede. Le soluzioni oggi sono numerose e compatibili anche con ambienti non cloud: token hardware, app OTP, certificati client.
Le utenze devono avere una scadenza. Se un manutentore finisce il contratto o cambia azienda, l'accesso deve essere revocato. Se un vendor ha bisogno di un intervento una volta l'anno, l'account deve essere attivato per la durata della sessione e poi disabilitato.
Approvazione e attivazione su richiesta
L'accesso remoto non dovrebbe essere "sempre disponibile". Il modello piu sicuro prevede che l'operatore remoto richieda l'accesso, e che qualcuno lato impianto — un operatore, un responsabile, un sistema automatico con policy — lo approvi e lo attivi per un tempo definito. A sessione conclusa, l'accesso si chiude.
Questo approccio richiede un minimo di organizzazione, ma elimina il problema piu grave: il canale aperto e dimenticato. In ambienti critici, l'accesso su richiesta e una delle misure piu efficaci e meno costose da implementare.
Restrizione dei protocolli e delle destinazioni
L'utente remoto non deve poter raggiungere qualsiasi cosa nella rete OT. Se il manutentore deve collegarsi a un HMI specifico, il percorso deve essere limitato a quell'HMI, con i protocolli strettamente necessari. Non deve poter fare port scan, non deve poter raggiungere PLC su altre linee, non deve poter navigare verso l'historian o il server SCADA se non e previsto dal suo ruolo.
Le regole di filtraggio si impostano sul firewall tra DMZ e rete OT, oppure sul jump host stesso se ha funzionalita di restrizione granulare. Il principio e semplice: minimo privilegio, massima visibilita.
Logging e tracciabilita delle sessioni
Ogni sessione remota deve essere registrata: chi, quando, da dove, verso quale destinazione, per quanto tempo. Se possibile, anche cosa e stato fatto durante la sessione. Alcuni jump host e piattaforme di teleassistenza offrono registrazione video o testuale delle sessioni: e una funzionalita utile sia per audit sia per troubleshooting post-intervento.
I log devono essere conservati in un sistema separato dalla rete OT, protetto da manomissioni, con retention adeguata. In caso di incidente, i log delle sessioni remote sono spesso l'unica fonte per ricostruire la sequenza degli eventi.
Le piattaforme di teleassistenza industriale: cosa valutare
Esistono piattaforme specifiche per la teleassistenza industriale, progettate per ambienti OT. Alcuni vendor di automazione offrono le proprie soluzioni integrate; esistono anche prodotti indipendenti. Non e compito di questo articolo raccomandare un prodotto specifico, ma ci sono criteri di valutazione che vale la pena considerare.
Nessuna piattaforma risolve il problema da sola. Se mancano le regole organizzative — chi puo collegarsi, quando, con quale approvazione, con quali limiti — il tool resta uno strumento tecnico senza governo.
Il caso dei vendor di macchina: un problema organizzativo prima che tecnico
Una delle situazioni piu complesse nella pratica riguarda i costruttori di macchina (OEM). Il vendor fornisce la macchina, la mette in servizio, e poi ha bisogno di accesso remoto per assistenza, aggiornamenti, diagnostica. Fin qui tutto ragionevole.
Il problema nasce quando ogni vendor pretende il proprio canale di accesso, con il proprio software, le proprie credenziali, la propria logica. In uno stabilimento con dieci macchine di cinque vendor diversi, si possono trovare cinque soluzioni di teleassistenza diverse, ognuna con le proprie regole, i propri rischi e la propria opacita.
La soluzione non e vietare l'accesso remoto ai vendor — sarebbe impraticabile e controproducente — ma definire regole chiare:
- L'accesso remoto dei vendor deve passare attraverso l'infrastruttura dello stabilimento, non attraverso canali paralleli non governabili.
- Le credenziali devono essere nominali, gestite dallo stabilimento, con scadenza.
- Ogni sessione deve essere approvata e tracciata.
- I protocolli e le destinazioni raggiungibili devono essere limitati a cio che serve per l'intervento specifico.
- I contratti di manutenzione devono prevedere clausole minime su sicurezza degli accessi, responsabilita e gestione delle credenziali.
Nella realta, imporre queste regole richiede tempo, negoziazione e spesso un cambio di mentalita sia lato stabilimento sia lato vendor. Ma e un passaggio necessario, soprattutto alla luce dei requisiti NIS2 sulla sicurezza della supply chain.
Accesso remoto e IEC 62443: cosa dice lo standard
Lo standard IEC 62443, riferimento principale per la cybersecurity industriale, affronta l'accesso remoto in modo esplicito. In particolare:
- IEC 62443-3-3 (System security requirements) include requisiti su identificazione e autenticazione degli utenti remoti, controllo degli accessi, audit trail e gestione delle sessioni.
- IEC 62443-2-1 (Security management system) richiede policy e procedure per la gestione degli accessi remoti, inclusi fornitori e manutentori.
- Il concetto di zone e conduit (IEC 62443-3-2) implica che ogni flusso di comunicazione remota attraversi un conduit definito, con requisiti di sicurezza coerenti con il livello di rischio della zona di destinazione.
Lo standard non prescrive un prodotto o una tecnologia, ma stabilisce principi e livelli di sicurezza (Security Level, SL) che guidano la scelta architetturale. Per la maggior parte degli impianti, raggiungere SL 2 sugli accessi remoti — cioe protezione contro attacchi intenzionali con mezzi limitati — richiede gia un salto significativo rispetto alla situazione tipica.
NIST SP 800-82 Rev. 3: indicazioni pratiche
Il NIST SP 800-82 Rev. 3, guida di riferimento per la sicurezza OT, dedica attenzione specifica agli accessi remoti nel contesto dei sistemi di controllo industriale. Tra le indicazioni rilevanti:
- L'accesso remoto deve passare attraverso punti di ingresso controllati e monitorati, non direttamente verso i dispositivi di campo.
- Le connessioni VPN devono terminare in una DMZ, non nella rete di controllo.
- L'autenticazione multifattore e raccomandata per tutti gli accessi remoti ai sistemi OT.
- Le sessioni remote devono essere limitate nel tempo e registrate.
- Gli accessi dei vendor devono essere gestiti con lo stesso rigore degli accessi interni, se non maggiore.
Sono indicazioni che ricalcano i principi gia descritti. Il valore del documento NIST sta nella sistematicita e nel fatto che fornisce un linguaggio comune tra chi gestisce l'impianto, chi lo progetta e chi deve verificarne la sicurezza.
Cosa cambia con la NIS2
La direttiva NIS2 non parla specificamente di "accesso remoto", ma diversi requisiti la toccano direttamente:
- Gestione degli accessi: la direttiva richiede misure di controllo degli accessi proporzionate al rischio, inclusa l'autenticazione multifattore dove appropriato.
- Sicurezza della supply chain: i fornitori con accesso remoto ai sistemi critici rientrano pienamente nel perimetro della supply chain security.
- Gestione degli incidenti: senza tracciabilita degli accessi remoti, ricostruire un incidente e dimostrare la propria capacita di risposta diventa molto difficile.
- Continuita operativa: un accesso remoto compromesso che provoca un fermo impianto e un evento che la NIS2 richiede di saper gestire, notificare e documentare.
Per chi rientra nel perimetro NIS2, gli accessi remoti non governati rappresentano una vulnerabilita evidente e documentabile. Non e un rischio teorico: e una delle prime cose che un auditor o un assessment tecnico va a verificare.
Percorso di adeguamento: da dove partire nella pratica
Mettere ordine sugli accessi remoti di un impianto non si fa in un giorno. Ci sono vincoli contrattuali con i vendor, abitudini consolidate, sistemi legacy che non supportano MFA, fermate di produzione che non si possono programmare liberamente. Ma si puo partire con un percorso graduale e realistico.
Fase 1 — Mappatura dello stato attuale
Prima di cambiare qualsiasi cosa, serve sapere cosa c'e. Questo significa:
- elencare tutti i canali di accesso remoto attivi: VPN, tool di teleassistenza, connessioni cloud dei vendor, modem, router 4G/5G;
- per ogni canale, documentare chi lo usa, con quali credenziali, verso quali destinazioni, con quale frequenza;
- verificare quali canali sono permanenti e quali attivabili su richiesta;
- identificare i canali che bypassano il firewall di confine.
Questa fase spesso rivela sorprese. Canali dimenticati, VPN configurate anni prima e mai dismesse, software di teleassistenza installati durante un commissioning e rimasti attivi. E il punto di partenza indispensabile.
Fase 2 — Definizione delle regole
Sulla base della mappatura, si definiscono le regole minime:
- quali canali sono ammessi e quali devono essere dismessi o consolidati;
- quale deve essere il percorso standard: VPN verso DMZ, poi jump host, poi destinazione OT;
- chi approva e attiva le sessioni;
- quali credenziali sono accettabili (nominali, con scadenza, con MFA);
- quali protocolli e destinazioni sono consentiti per ogni ruolo.
Fase 3 — Implementazione progressiva
L'implementazione raramente e un big bang. Si parte dai canali piu critici o piu esposti, si consolidano i punti di ingresso, si introduce il jump host, si attiva il logging. I vendor vengono informati e coinvolti gradualmente. Le eccezioni temporanee vengono documentate e gestite con misure compensative.
Un errore frequente e voler fare tutto subito e poi bloccarsi alle prime resistenze organizzative. Meglio un percorso in tre-sei mesi con risultati concreti che un progetto ambizioso che resta sulla carta.
Fase 4 — Verifica e mantenimento
Le regole sugli accessi remoti non sono un progetto una tantum. Vanno riviste periodicamente: nuovi vendor, nuovi impianti, cambi di personale, aggiornamenti dei tool. Una review semestrale o annuale degli accessi attivi, delle credenziali e dei log e il minimo per mantenere il controllo nel tempo.
1. Nessun accesso remoto diretto alla rete OT senza passare da DMZ o jump host
2. Utenze nominali con scadenza e MFA per ogni operatore remoto
3. Sessioni attivabili su richiesta e approvazione, non permanenti
4. Restrizione delle destinazioni e dei protocolli per ruolo
5. Logging completo di ogni sessione remota, conservato fuori dalla rete OT
6. Inventario aggiornato di tutti i canali di accesso remoto attivi
7. Clausole contrattuali minime per i vendor con accesso remoto
8. Review periodica degli accessi, delle credenziali e dei log
Errori da evitare nel percorso di adeguamento
"Ogni vendor usa il suo tool, non possiamo farci niente"
"La VPN e attiva da anni, non la tocchiamo"
"Il firewall blocca le porte in ingresso, quindi siamo protetti"
"L'MFA in OT non si puo fare"
"I log ci sono, da qualche parte"
Punto di ingresso unico e governato per tutti gli accessi remoti
Sessioni attivate su richiesta con approvazione e timeout
Verifica dei canali in uscita e dei software di teleassistenza installati
MFA sul jump host, non necessariamente su ogni singolo dispositivo OT
Log centralizzati, protetti e con retention definita
Il nostro punto di vista
L'accesso remoto e uno dei punti dove la distanza tra "come dovrebbe essere" e "come e nella realta" e piu ampia. Molti impianti funzionano con accessi remoti improvvisati da anni, e il fatto che non ci siano stati incidenti gravi non significa che l'architettura sia solida. Significa che non e ancora stata messa alla prova.
Mettere ordine sugli accessi remoti non richiede necessariamente investimenti enormi. Richiede prima di tutto una decisione: sapere chi si collega, controllare come lo fa, poter intervenire se qualcosa va storto. Il resto e implementazione.
Vuoi verificare lo stato degli accessi remoti sul tuo impianto?
Contattaci per una mappatura tecnica — analizziamo i canali attivi, le credenziali, la segmentazione e ti aiutiamo a definire un percorso di adeguamento concreto e sostenibile.