VPN industriale vs TeamViewer: perché gli strumenti destinati al grande pubblico non sono sufficienti in un ambiente OT
Quando si parla di progetti di accesso remoto in ambito industriale, questa domanda ricorre spesso: "Perché non usare semplicemente TeamViewer? È quello che facciamo già per l'assistenza informatica."
La risposta in breve: le reti OT non sono reti IT. I controllori che vi operano gestiscono macchinari fisici: un comando errato o un’intrusione possono avere conseguenze a livello industriale, se non addirittura umane. Gli strumenti destinati al grande pubblico sono stati progettati per un contesto radicalmente diverso.
Questo articolo va oltre una semplice risposta sintetica. Spiega il modello di minaccia reale, illustra in dettaglio i requisiti della norma IEC 62443 e presenta i criteri tecnici per valutare una soluzione di accesso remoto industriale.
1. Il modello di Purdue e i livelli di affidabilità OT
Per capire perché gli accessi remoti OT sono diversi, è necessario conoscere il modello Purdue (Purdue Enterprise Reference Architecture), punto di riferimento internazionale per la segmentazione delle reti industriali.
Niveau 5 : Réseau d'entreprise (ERP, email, bureautique)
─────────────────────────────────────────────
Niveau 4 : Réseau IT de site (serveurs, SGBD, Active Directory)
─────────────────────────────────────────────
Niveau 3 : Réseau supervision (SCADA, MES, historiens)
─────────────────────────────────────────────
Niveau 2 : Réseau contrôle (IHM, ingénierie)
─────────────────────────────────────────────
Niveau 1 : Réseau terrain (automates, variateurs, capteurs)
─────────────────────────────────────────────
Niveau 0 : Process physique (capteurs, actionneurs, moteurs)
L'accesso remoto industriale riguarda tipicamente i livelli 1 e 2 — i controllori logici programmabili (PLC) e gli strumenti di ingegneria. Questi livelli non devono mai essere accessibili direttamente dai livelli superiori senza controllo, e tanto meno da Internet.
La segmentazione tra i livelli costituisce la prima linea di difesa. L'accesso remoto, per definizione, attraversa tale segmentazione: da qui derivano i requisiti di sicurezza più rigorosi.
2. I rischi effettivi di un accesso non controllato alla rete OT
Cosa viene trasmesso su una rete OT industriale
Una rete OT tipica ospita:
- PLC (S7, M340, CompactLogix) che controllano i macchinari
- Variatori di frequenza che controllano i motori
- Interfacce uomo-macchina industriali che consentono la supervisione e la configurazione
- Sistemi SCADA che supervisionano l'intero processo
- Strumenti di misura (sensori di pressione, temperatura, portata)
Queste apparecchiature sono state progettate per garantire l'affidabilità in ambienti isolati, non per resistere agli attacchi di rete. Il protocollo Modbus non prevede alcuna autenticazione. S7Comm (Siemens) storicamente non disponeva di alcuna crittografia. Profinet, EtherNet/IP — la maggior parte dei protocolli industriali presuppone una rete affidabile.
Analisi di un attacco a un accesso remoto OT non adeguatamente protetto
Ecco come si svolge in genere un attacco a un accesso remoto industriale non protetto:
Fase 1 — Ricognizione (automatica, passiva): Uno scanner automatico (Shodan, Censys o uno script personalizzato) identifica l'IP pubblico dello stabilimento e rileva una porta aperta (VPN classica su UDP 1194, porta Modbus 502, porta S7Comm 102). Questa fase non genera alcun log sospetto e dura pochi secondi.
Fase 2 — Sfruttamento dell'accesso: Se la VPN è protetta solo da una password debole (o se le credenziali sono state rubate tramite phishing), l'autore dell'attacco riesce ad accedere. Se si tratta di una porta Modbus direttamente esposta, può leggere e scrivere senza alcuna autenticazione.
Fase 3 — Ricognizione interna: Una volta ottenuto l'accesso, l'autore dell'attacco effettua una mappatura della rete OT: quali controllori sono accessibili, quali variabili sono leggibili, quali aree di processo vengono controllate.
Fase 4 — Azione dolosa: Le azioni possono essere immediate (interruzione della produzione, modifica dei parametri) o discrete (modifica graduale dei setpoint per compromettere la qualità del prodotto senza far scattare alcun allarme).
Gli attacchi più pericolosi non sono quelli più spettacolari. Una variazione del ±5% di un valore di riferimento di dosaggio in un impianto chimico o farmaceutico può passare inosservata per giorni, con conseguenze potenzialmente catastrofiche sulla qualità del prodotto finito.
Incidenti documentati
L'ANSSI e il CISA (Cybersecurity and Infrastructure Security Agency, Stati Uniti) segnalano regolarmente incidenti relativi ad accessi remoti industriali non adeguatamente protetti:
- TeamViewer su una postazione di supervisione idrica (Florida, 2021): un hacker ha modificato i livelli di trattamento chimico tramite TeamViewer installato sul sistema SCADA di un impianto di trattamento dell'acqua potabile. L'attacco è stato rilevato dall'operatore in tempo reale, ma avrebbe potuto passare inosservato.
- VPN senza MFA nel settore energetico: sono stati documentati diversi incidenti in cui credenziali VPN rubate hanno consentito l’accesso a reti elettriche regionali in Europa.
- Port forwarding Modbus: i ricercatori nel campo della sicurezza hanno dimostrato più volte la possibilità di modificare i parametri dei controllori logici programmabili (PLC) accessibili direttamente da Internet.
3. Porte aperte vs tunnel in uscita: la differenza fondamentale
Architettura "porta di ingresso esposta"
[Internet] ──→ [Pare-feu usine : port ouvert] ──→ [Réseau OT] ──→ [Automate]
Questo modello espone un punto di accesso a Internet. Che si tratti di una porta VPN (UDP 1194 per OpenVPN, UDP 500/4500 per IPsec) o di una porta applicativa (502, 102, 443), tale porta viene monitorata costantemente.
Ciclo di vita di una porta esposta:
- Apertura della porta → indicizzazione da parte di Shodan entro 24-48 ore
- Primi tentativi di scansione → pochi giorni dopo l'esposizione
- Tentativi di sfruttamento automatizzato → non appena viene identificata una firma nota
- Sfruttamento mirato → se l'installazione viene identificata come critica o interessante
Architettura "solo tunnel in uscita"
[Réseau OT] ──→ [Gateway : connexion sortante] ──→ [Cloud] ←── [Opérateur]
Cosa cambia sostanzialmente:
- La connessione viene avviata dall'interno — esattamente come un browser web
- Dal punto di vista del firewall dello stabilimento: traffico HTTPS in uscita verso un indirizzo IP noto
- Nessuna porta in entrata da aprire, nessuna regola del firewall da modificare
- Nessuna porta esposta = nessuna superficie di attacco di rete dal lato dello stabilimento
Se l'infrastruttura cloud di Eziwan venisse compromessa (scenario ipotetico), un malintenzionato non potrebbe propagare l'attacco alla rete dello stabilimento: la connessione è unidirezionale dal punto di vista dell'avvio.
Perché TeamViewer non è “così sicuro” come OpenVPN
TeamViewer utilizza effettivamente un relay cloud (non c'è una connessione diretta tra l'autore dell'attacco e lo stabilimento), ma i problemi strutturali sono diversi:
| Problema | Spiegazione |
|---|---|
| Infrastruttura di terze parti | Le sessioni passano attraverso i server di TeamViewer. Se TeamViewer viene compromesso (come nel 2016), lo sono anche le vostre sessioni. |
| Tracciabilità dipendente dall’abbonamento | I log completi sono disponibili solo con gli abbonamenti premium. Nella versione gratuita, non è possibile esportare i log. |
| Modello di autenticazione inadeguato | Un codice a 9 cifre scambiato via e-mail non costituisce un’autenticazione forte. |
| Nessun isolamento OT | TeamViewer consente l’accesso al computer Windows su cui è in esecuzione — e, da quel computer, potenzialmente all’intera rete OT. |
4. Cosa dicono la norma IEC 62443 e l'ANSSI
IEC 62443 — la norma di riferimento
La norma IEC 62443 definisce i requisiti di sicurezza informatica per i sistemi industriali. Per l'accesso remoto, il Security Level 2 (SL2) — livello raccomandato per la maggior parte degli impianti industriali — richiede:
SR 1.1 — Identificazione e autenticazione umana: Ogni utente che accede al sistema deve essere identificato e autenticato individualmente. Gli account condivisi (un unico account "manutenzione" per l'intero team) sono espressamente esclusi.
SR 1.7 — Autenticazione rafforzata (Enhancement SL2): Per gli accessi remoti a livello SL2 è richiesta l'autenticazione a due fattori (MFA). La sola password non è sufficiente.
SR 2.6 — Accesso tramite reti non affidabili: Qualsiasi accesso da Internet alla rete OT deve essere crittografato, autenticato e registrato. Questo requisito costituisce la traduzione normativa della combinazione “tunnel in uscita + MFA + registri di audit”.
SR 6.2 — Monitoraggio continuo: Gli accessi remoti devono essere registrati in modo continuativo: chi si è collegato, quando, da quale indirizzo e per quanto tempo.
Raccomandazioni dell'ANSSI
L'ANSSI pubblica guide specifiche per i sistemi industriali. I suoi cinque principi per l'accesso remoto industriale:
- Segregazione: gli accessi remoti non devono attraversare direttamente la rete OT, ma devono passare attraverso una DMZ industriale
- Autenticazione forte: MFA obbligatoria per qualsiasi accesso remoto alle apparecchiature di livello 1 o 2
- Crittografia: tutte le comunicazioni remote devono essere crittografate con algoritmi recenti
- Registrazione: log completi, esportabili, con data e ora, conservati per almeno 3 mesi
- Privilegio minimo: ogni tecnico accede solo alle apparecchiature di propria competenza
L'ANSSI pubblica queste raccomandazioni nella sua guida "Gestione del rischio digitale legato ai sistemi industriali", scaricabile gratuitamente dal sito ssi.gouv.fr. Se ne consiglia la lettura a tutti i responsabili della manutenzione industriale.
5. OpenVPN, IPSec e L2TP in ambito industriale
Non tutte le VPN sono uguali quando si tratta di gateway integrati su CPU ARM con limitazioni relative alla riconnessione e alla memoria.
Analisi comparativa dettagliata
| Criterio | OpenVPN | IPSec (IKEv2) | L2TP / PPTP |
|---|---|---|---|
| Trasporto | UDP o TCP 443 | UDP 500/4500 (ESP/IKE) | UDP 1701 / TCP 1723 |
| Superamento firewall / NAT | Eccellente (TCP 443 passa ovunque) | Media (NAT-T richiesto) | Variabile |
| Riconnessione dopo interruzione 4G | Rapida (persist-tun, ~2-5 s) | Eccellente (MOBIKE, quasi trasparente) | Lenta (15-60 s) |
| Primitive crittografiche | TLS, AES-256-GCM | AES-256, SHA-2 (IKEv2) | Scarsa (PPTP/MS-CHAPv2 sconsigliato) |
| Autenticazione | Certificato X.509 per client | PSK o certificati X.509 | Nome utente / password |
| Carico CPU (ARM Cortex-A) | Moderato | Basso (possibile accelerazione hardware) | Basso |
| Maturità / certificazioni | Ampiamente verificato, adozione su larga scala | Certificato FIPS 140-2 | Obsoleto (PPTP da evitare) |
OpenVPN: la scelta predefinita di Eziwan per i gateway integrati
Il punto chiave per l'azienda: il superamento dei firewall e la riconnessione dopo un'interruzione del 4G. OpenVPN incapsula il tunnel in TLS sulla porta TCP 443 — la stessa utilizzata da HTTPS — consentendogli così di passare laddove altri protocolli vengono bloccati (firewall dell'operatore, proxy aziendale). In combinazione con persist-tun, il tunnel si ristabilisce in pochi secondi dopo un cambio di SIM, senza necessità di una rinegoziazione completa.
Ogni tecnico dispone di un proprio certificato X.509, revocabile individualmente dalla dashboard cloud — un requisito fondamentale per la tracciabilità prevista dalla direttiva NIS2.
IPSec (IKEv2) per gli ambienti che lo richiedono
IPSec rimane lo standard nelle aziende e negli ambienti industriali regolamentati che impongono protocolli certificati FIPS 140-2. Il suo meccanismo MOBIKE gestisce il cambio di indirizzo IP in modo quasi trasparente — particolarmente adatto al failover Dual SIM. La configurazione è più complessa (PKI, certificati X.509, politiche SA), ma l’interoperabilità con le apparecchiature di rete esistenti è massima. L’Eziwan Gateway supporta inoltre L2TP, PPTP e GRE per i casi di interoperabilità con sistemi legacy.
6. Come Eziwan attua la politica “zero porte esposte”
L'architettura Eziwan applica i principi sopra indicati in modo sistematico:
Architettura di connessione
- Il gateway dello stabilimento avvia la connessione OpenVPN verso l'infrastruttura cloud Eziwan sulla porta UDP 1194
- La connessione viene autenticata tramite certificati X.509 generati durante il provisioning
- Nessuna porta in entrata è aperta sulla rete dello stabilimento
- L'accesso dell'operatore passa attraverso il cloud Eziwan, con autenticazione multifattoriale (MFA) integrata (TOTP o notifica push)
- Ogni sessione viene registrata: utente, data e ora, durata, azioni eseguite
Procedura di migrazione da TeamViewer
Se attualmente utilizzate TeamViewer su postazioni di supervisione industriali, ecco una procedura di migrazione graduale:
Fase 1 — Implementazione parallela (settimane 1-4):
- Installare i gateway Eziwan in 5-10 siti pilota
- Lasciare TeamViewer attivo in parallelo durante la fase di validazione
- Formare i team all'uso del client VPN Eziwan e della dashboard
Fase 2 — Transizione graduale (settimane 5-8):
- Disattivare TeamViewer nelle sedi pilota dopo la convalida
- Implementare nelle restanti sedi in gruppi di 10-20 sedi
- Verificare che i registri di audit di Eziwan soddisfino le esigenze dei team
Fase 3 — Disinstallazione e pulizia (settimana 9+):
- Disinstallare TeamViewer da tutte le postazioni di supervisione
- Revocare le licenze TeamViewer
- Archiviare i vecchi registri di TeamViewer, se necessario ai fini della conformità
Lista di controllo per la verifica post-implementazione
Dopo l'implementazione di Eziwan, verificare i seguenti punti:
- Nessuna porta TCP/UDP in entrata aperta sul firewall dello stabilimento (scansione da Internet)
- MFA attivato per tutti gli account di accesso remoto
- Account nominativi creati per ogni tecnico (nessun account condiviso)
- Diritti di accesso verificati per area di competenza (il tecnico X vede solo i propri siti)
- Test di un avviso via SMS/e-mail per verificare il canale di notifica
- Esportazione dei log di audit testati (per futuri audit)
- Procedura di revoca dell’accesso documentata e testata
Tabella comparativa finale
| Criterio | TeamViewer / AnyDesk | VPN classica (site-to-site) | Eziwan |
|---|---|---|---|
| Porte in entrata esposte | No (relay cloud di terze parti) | Sì | No |
| Tracciabilità delle sessioni | Parziale (abbonamento) | Dipende dall'apparecchiatura | Completa + esportazione |
| Conformità IEC 62443 SL2 | ✗ | Parziale | ✓ |
| Conformità alle raccomandazioni ANSSI | ✗ | Parziale | ✓ |
| Autenticazione MFA integrata | Opzionale | Opzionale | Integrata |
| Intervento di rete in loco | No | Sì | No |
| Isolamento OT completo | ✗ | Parziale | ✓ |
| Log di audit esportabili | Abbonamento premium | A seconda dell'apparecchiatura | Standard |
| Riconnessione dopo interruzione 4G | 30–60 s | 5–30 s | < 2 s (OpenVPN) |
| Implementazione senza competenze di rete | Sì | No | Sì (ZTP) |
Per un'implementazione pratica su un controllore Siemens S7, consultare Come collegare un S7 da remoto senza aprire alcuna porta. Per i requisiti della norma IEC 62443 in dettaglio, consultare IEC 62443 e accesso remoto industriale.
Domande frequenti — VPN industriale vs TeamViewer
TeamViewer non è sufficiente se si accede solo a una postazione di supervisione e non direttamente al PLC?
Non necessariamente. La postazione di supervisione ha generalmente accesso alla rete di livello 1 (controllori) tramite il software SCADA. Una compromissione della postazione — sia tramite TeamViewer che tramite un'altra vulnerabilità — consente indirettamente l'accesso ai controllori. L'isolamento OT deve essere concepito in termini di rete, non di applicazione.
WireGuard è una valida alternativa a OpenVPN per i gateway industriali?
WireGuard offre prestazioni superiori e un codice sorgente più snello (e meglio verificato), ma presenta un limite: funziona solo su UDP, senza l’opzione TCP. Nelle reti in cui il protocollo UDP è filtrato (alcuni operatori di telefonia mobile, proxy aziendali), WireGuard potrebbe non funzionare laddove OpenVPN su TCP 443 funzionerebbe. Per i gateway 4G industriali con connessioni potenzialmente instabili, OpenVPN rimane la scelta più universale.
È possibile utilizzare una soluzione VPN IPsec già in uso in azienda invece di Eziwan?
Sì, se la soluzione esistente soddisfa i criteri della norma IEC 62443 SL2 (account nominativi, autenticazione a più fattori, registri esportabili, principio del privilegio minimo). Il problema ricorrente delle VPN site-to-site aziendali applicate al settore OT è la mancanza di granularità: la VPN consente l’accesso a un intero segmento di rete anziché a un’apparecchiatura specifica. Eziwan può integrare una soluzione VPN aziendale aggiungendo granularità e registri di audit.
L'ANSSI elenca soluzioni di accesso remoto approvate per l'OT?
L'ANSSI non pubblica un elenco di soluzioni "approvate", ma criteri di valutazione. Per gli OIV e gli OSE, i fornitori qualificati PRIS (Fornitori di servizi di risposta agli incidenti di sicurezza) possono effettuare una valutazione formale. I criteri dell'ANSSI sono coerenti con i requisiti della norma IEC 62443 SL2 descritti in questo articolo.
Quanto tempo occorre per passare da TeamViewer a una soluzione VPN industriale?
Con un parco di meno di 20 siti, la migrazione può avvenire in 2-4 settimane: implementazione parallela, formazione dei team, passaggio graduale. Il punto critico è la formazione dei tecnici sul client VPN: prevedere da 1 a 2 ore a persona. Il processo è descritto in dettaglio nella sezione 6 di questo articolo.
La vostra organizzazione utilizza attualmente TeamViewer o un accesso VPN tradizionale su una rete OT?
Scarica il white paper sulla sicurezza informatica OT →
Il documento illustra in dettaglio l'architettura di destinazione raccomandata, la procedura di migrazione da un sistema di accesso esistente e i criteri di valutazione di una soluzione conforme alla norma IEC 62443.
