SEW Connectivity Service

Panoramica

Il SEW Connectivity Service si basa su SDA Glue, l'applicazione per i Gateway, disponibile per host Linux e Windows. Il servizio è alimentato da SoftEther VPN, che supporta OpenVPN sui client Windows, stabilendo un tunnel TCP sicuro tra un'interfaccia di rete nel Gateway e i servizi cloud SEW, come IDEaaS, Backup e VM di Deployment. Combina inoltre i firewall nativi del sistema operativo, iptables di Linux e Windows Filtering Platform (WFP), con una tabella NAT per collegare software specifici del produttore, come Siemens TIA Portal e Rockwell Studio 500, direttamente con il dispositivo nel livello di controllo della produzione.

Punti chiave

La gestione degli asset industriali con SEW è alimentata da una soluzione di connettività industriale completa e sicura, che colma il divario tra gli ambienti produttivi e i servizi basati su cloud. Sfruttando tecnologie consolidate e implementando solide misure di sicurezza, il servizio offre una connettività di livello enterprise pensata specificamente per i sistemi di automazione e controllo industriale.

Sicurezza di livello industriale: l'integrazione con AWS IoT Core fornisce connessioni TLS sicure con criteri di controllo degli accessi granulari. Ciò segue le best practice di sicurezza dell'IoT industriale, consentendo agli amministratori di limitare l'accesso in base alle proprietà e al contesto del dispositivo.

Fondamento VPN consolidato: il servizio utilizza SoftEther VPN, che fornisce crittografia AES a 256 bit e RSA a 4096 bit con prestazioni di throughput elevate e basso consumo di memoria e CPU, garantendo che i dati in transito rimangano protetti da intercettazioni e accessi non autorizzati, ideale per applicazioni industriali in cui sicurezza e prestazioni sono critiche.

Accesso alla rete Zero-Trust: il servizio elimina la necessità delle tradizionali VPN statiche stabilendo le connessioni su richiesta. Questa architettura Point-to-Point garantisce che gli utenti possano accedere solo ai dispositivi specificamente autorizzati, non a interi segmenti di rete, riducendo notevolmente la superficie di attacco.

Progettazione compatibile con la fabbrica: tutte le connessioni sono avviate verso l'esterno dal nodo stesso — un Gateway o una Workstation — e mai accettate in entrata, quindi non è mai necessaria alcuna regola di firewall in ingresso. Questa progettazione rispetta le architetture di sicurezza industriali esistenti fornendo al tempo stesso funzionalità di accesso remoto sicuro.

Architettura

I peer di una rete virtuale sono chiamati Nodi e costituiscono i componenti principali del Connectivity Service. Ogni connessione è costruita dall'interazione di una catena di Nodi, ciascuno con un ruolo specifico.

Devices: asset industriali generalmente collocati nella rete di produzione protetta, accessibili tramite il loro indirizzo IP, ad es. PLC, HMI e robot. I Device sono dichiarati nella SEW Console per ogni Tenant e l'accesso degli utenti è gestito tramite Role-Based Access Control. La connettività richiede che ogni Device sia collegato ad almeno un Gateway di rete.

Gateways: host di rete con accesso sicuro a Internet e ai Device gestiti nella SEW Console. Si tratta generalmente di IPC, VM, Container e persino Raspberry Pi, collocati in una zona firewall che richiede regole specifiche per accedere alle risorse SEW Cloud, come i Tenant Server. Ogni Gateway esegue SDA Glue, un servizio del sistema operativo che rimane in ascolto delle richieste di connessione e fornisce dati di telemetria.

Workstations: un PC di proprietà del cliente, utilizzato per accedere ai dispositivi attraverso un Gateway presso il sito di destinazione. Una Workstation esegue lo stesso software SDA Glue di un Gateway ed è configurata in modo identico a livello di rete; l'unica differenza è il ruolo — una Workstation avvia sempre la connessione verso l'esterno in direzione di un Gateway e non inoltra mai il traffico verso altri dispositivi.

Tenant Servers: bastion host in esecuzione in un ambiente SEW Cloud protetto, dedicati a ogni Tenant, che collegano l'interfaccia di rete del Gateway con una Service VM SEW o con un altro Gateway. Questi Server garantiscono i criteri di filtraggio necessari per assicurare esclusivamente connessioni Point-to-Point, ad esempio da IDEaaS a un PLC specifico e non ad altri dispositivi indesiderati nella stessa rete del Gateway. Autenticano inoltre l'accesso dai Gateway in base a un criterio di rotazione delle credenziali per ogni connessione.

Service VMs: eseguono le applicazioni necessarie ai servizi SEW, come IDEaaS, Backup e pipeline di Deployment. Queste VM si affidano al Connectivity Service per accedere ai Device a livello di rete, tramite il loro indirizzo IP, elemento essenziale per le applicazioni industriali.

Cloud

Anziché utilizzare le tradizionali VPN statiche, il SEW Connectivity Service stabilisce connessioni verso gli asset industriali su richiesta; tali richieste vengono inoltrate a una catena di Nodi che operano insieme per fornire un accesso di rete Point-to-Point tra i servizi SEW e i Device.

Per la rete di produzione, tutte le connessioni sono avviate dal Gateway, senza richiedere regole di connessione in ingresso nella fabbrica. Per ottenere questo risultato, i Nodi sono costantemente in ascolto su un broker di messaggi IoT per le richieste in arrivo, alimentato da AWS IoT Core.

Questa architettura consente agli utenti di interagire con gli asset in fabbrica da qualsiasi luogo con accesso a Internet e da qualsiasi computer, con il solo requisito di un browser.

Rete

Il Gateway è un dispositivo edge posizionato tra un livello di controllo della produzione e Internet, che fornisce ai servizi SEW un accesso controllato agli asset definiti nella Console. È pertanto molto importante consolidare un'architettura che colleghi in modo sicuro il SEW Cloud con l'infrastruttura locale. Raccomandiamo una delle due configurazioni proposte per il Gateway, come segue.

Gateway in LAN

Questo è l'approccio più comune, in cui il Gateway viene collocato accanto ai PLC che sono integrati nella piattaforma SEW. In questo caso, un firewall controlla in modo rigoroso le connessioni in uscita dal Gateway verso Internet.

Il Gateway ha accesso alla subnet in cui si trova, ma è possibile predisporre un firewall nel router della rete come Access Control Layer (ACL). È inoltre comune utilizzare un dispositivo Gateway con due interfacce di rete: una rivolta verso la DMZ e una privata nel livello di controllo. Questa architettura consente zone IP ripetute, ad es. entrambe con la subnet 10.0.0.0/24.

Gateway in DMZ

Questo approccio è molto utilizzato quando il Gateway viene eseguito in una macchina virtuale dedicata, all'interno dell'infrastruttura server. Il team IT fornirà route speciali tra la VM e i PLC di destinazione nel livello di controllo e probabilmente esisteranno firewall sia sull'accesso a Internet sia su quello verso l'OT.

pericolo

Può esistere anche una Network Address Translation (NAT) nel percorso a valle verso i PLC. Tuttavia, ciò richiede attenzione: alcuni software specifici dei produttori di PLC potrebbero non essere compatibili con l'indirizzamento del PLC tramite un alias IP, in quanto potrebbero richiedere l'accesso all'indirizzo IP configurato esplicitamente nel progetto.

In questo caso, ogni PLC nell'unità produttiva deve avere un indirizzo IP univoco, altrimenti possono verificarsi collisioni. Inoltre, a seconda dell'infrastruttura di rete, l'accesso a livello 2 dai Gateway ai PLC potrebbe non funzionare: si tratta di una funzionalità in arrivo per l'integrazione delle reti industriali in tempo reale nei servizi SEW.

Software

SDA Glue è un'applicazione che viene eseguita come servizio del sistema operativo, garantendo l'alta disponibilità del Gateway con avvio e riavvio automatici in caso di errori. Per stabilire i tunnel di rete gestendo risorse di rete come interfacce, route e regole firewall, richiede privilegi elevati come utente di sistema.

Gli aggiornamenti automatici sono abilitati per impostazione predefinita. Il servizio Glue leggerà la versione stabile più recente da repository.eu1.sdacosole.io e applicherà l'aggiornamento quando non vi sono connessioni attive. Il meccanismo di aggiornamento scarica il nuovo binario dell'applicazione, lo sostituisce a quello precedente e riavvia il servizio.

AWS IoT Core verrà connesso durante il login, utilizzando l'endpoint iot.eu1.sdaconsole.io. Una volta connesso, il servizio Glue rimarrà costantemente in ascolto delle richieste dal SEW Cloud e pubblicherà dati di telemetria, come lo stato dei Device associati al Gateway. L'autenticazione IoT è protetta da un ID breve e da una password monouso che possono essere recuperati dalla SEW Console. La connessione a IoT è inoltre protetta da una chiave segreta contenuta nel binario dell'applicazione. La connessione a IoT può essere configurata per essere stabilita tramite MQTT SSL o WebSocket Secure, entrambi sulla porta 443.

I meccanismi di rete sono diversi per Linux e Windows. Pertanto vengono descritti separatamente.

Linux

SDA Glue su Linux si basa sul SoftEther VPN Client, che è open-source (Apache License 2.0), installato dal mirror SEW su repository.eu1.sdaconsole.io durante l'installazione di Glue.

Per ogni connessione, Glue utilizza il client SoftEther per creare un'interfaccia di rete NIC e collegarla al Tenant Server. Utilizza inoltre gli strumenti IP di Linux per assegnare un indirizzo IP a tale interfaccia e creare le route necessarie tra la Service VM e il Device di destinazione.

Le regole firewall interne e la traduzione NAT vengono create in iptables, che non consente pacchetti di rete in ingresso verso il Gateway, ma solo l'inoltro dei pacchetti verso il Device di destinazione.

📚 Gestione delle risorse Linux nelle connessioni

Per comprendere come il Gateway Linux collega i servizi cloud con i dispositivi di fabbrica, esaminiamo un esempio concreto con indirizzi IP specifici che illustrano l'intero flusso.

Si consideri una rete di fabbrica in cui un Device di destinazione (come un PLC) ha l'indirizzo IP locale 10.0.0.5 e il Gateway si trova sulla stessa rete con IP 10.0.0.2. Nel SEW Cloud, una Service VM deve connettersi a questo Device e le verrà assegnato l'IP VPN 100.112.20.3, mentre l'interfaccia VPN del Gateway riceverà 100.112.10.6.

Stabilire il tunnel

Quando arriva una richiesta di connessione, sia il Gateway sia la Service VM entrano in azione. Il Gateway crea una nuova interfaccia di rete virtuale chiamata vpn_iface e le assegna l'indirizzo 100.112.10.6. Contemporaneamente, la Service VM nel cloud crea la propria interfaccia VPN con l'IP 100.112.20.3. Entrambi gli endpoint si connettono quindi al Tenant Server, stabilendo tra loro un tunnel crittografato sicuro.

Factory Side:              Cloud Side:
Gateway                    Service VM
├─ Local: 10.0.0.2        ├─ VPN: 100.112.20.3
└─ VPN: 100.112.10.6      └─ Target: 10.0.0.5 (via Gateway)
Device
└─ Local: 10.0.0.5

A questo punto il tunnel esiste, ma i pacchetti non sanno ancora dove andare. Il Gateway deve insegnare al sistema come instradare il traffico tra questi due mondi.

Creazione delle route

Il Gateway aggiunge una regola di routing che crea la connessione tra la rete VPN e il reparto produttivo:

ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface

Questa route comunica al sistema un'informazione cruciale: quando il Device all'indirizzo 10.0.0.5 invia pacchetti di risposta, questi devono essere inoltrati attraverso vpn_iface per raggiungere la Service VM su 100.112.20.3. Senza questa route, il Gateway non saprebbe come rinviare le risposte del Device al cloud.

Ma il solo routing non è sufficiente. Il firewall del Gateway bloccherebbe comunque questo traffico per impostazione predefinita. Per abilitare la connessione, il Gateway deve consentire esplicitamente l'inoltro bidirezionale dei pacchetti tra la VM e il Device:

iptables -A GLUE_FORWARD -s 100.112.20.3 -d 10.0.0.5 -j ACCEPT
iptables -A GLUE_FORWARD -s 10.0.0.5 -d 100.112.20.3 -j ACCEPT

Queste regole aprono un percorso controllato, consentendo ai pacchetti di fluire dalla Service VM al Device e viceversa, mantenendo al tempo stesso la postura di sicurezza del Gateway per tutto il resto del traffico. Si noti inoltre che Glue utilizza le proprie catene in iptables, per non causare conflitti con le altre regole.

Traduzione NAT

Il Device in fabbrica si aspetta di comunicare con indirizzi IP locali: non ha alcuna conoscenza della rete cloud su 100.112.20.3 e non saprebbe come rispondere ai pacchetti provenienti da tale indirizzo. Il Gateway risolve questo problema mascherando i pacchetti della Service VM:

iptables -t nat -A GLUE_POSTROUTING -s 100.112.20.3 -d 10.0.0.5 -j MASQUERADE

Con questa regola NAT attiva, quando arriva un pacchetto dalla Service VM destinato al Device, il Gateway riscrive il suo indirizzo di origine da 100.112.20.3 a 10.0.0.2. Dal punto di vista del Device, sembra che stia comunicando direttamente con il Gateway stesso — un indirizzo familiare e affidabile nella sua rete locale. Quando il Device invia la risposta a 10.0.0.2, il Gateway esegue la traduzione inversa, riportando l'indirizzo di destinazione a 100.112.20.3 in modo che il pacchetto raggiunga la Service VM attraverso il tunnel VPN.

Grazie a questa orchestrazione di tunneling VPN, routing, regole firewall e traduzione NAT, il Gateway crea una connessione point-to-point trasparente. Il Device non vede mai l'infrastruttura cloud: comunica semplicemente con ciò che sembra essere il Gateway sulla sua rete locale all'indirizzo 10.0.0.2. Al tempo stesso, la Service VM ottiene l'accesso diretto a livello di rete al Device tramite il suo indirizzo IP 10.0.0.5, consentendo ad applicazioni industriali come TIA Portal o Studio 5000 di funzionare come se fossero eseguite direttamente sulla rete locale di fabbrica.

Windows

SDA Glue su Windows non supporta l'utilizzo integrato del SoftEther VPN Client, pertanto utilizza l'OpenVPN Community Open-Source Client (licenza GPL versione 2), installato dal mirror SEW su repository.eu1.sdaconsole.io durante l'installazione di Glue.

Per ogni connessione, Glue utilizza il driver TAP di OpenVPN per creare un'interfaccia di rete e collegarla al Tenant Server tramite autenticazione basata su certificati. Utilizza le API native di Windows per assegnare un IP all'interfaccia e creare le route necessarie tra la Service VM e il Device di destinazione.

Glue utilizza inoltre Windows Filtering Platform (WFP) per creare livelli e regole firewall dedicati. Tuttavia, dipende da WinNAT o NetNat per dichiarare la traduzione degli indirizzi tra la Service VM e il Device, che potrebbe non essere abilitata per impostazione predefinita.

Workstation vs. Gateway: le Workstation e i Gateway utilizzano lo stesso client Windows e la stessa configurazione di connessione descritti sopra — lo stesso driver TAP di OpenVPN, lo stesso indirizzamento dell'interfaccia basato su WinNAT. L'unica differenza è la regola firewall WFP assegnata per ogni connessione dalla policy di backend: la connessione di una Workstation riceve sempre una regola di solo traffico in uscita limitata all'IP del dispositivo di destinazione specifico attraverso l'interfaccia del tunnel SEW, mentre un Gateway può ricevere in aggiunta una regola di inoltro per instradare il traffico verso i dispositivi a esso sottostanti. Una Workstation non apre quindi mai percorsi in ingresso o di inoltro sull'host, e nessun'altra interfaccia di rete, route o connessione VPN esistente su quel PC viene interessata — tutte le modifiche sono limitate all'interfaccia virtuale che SDA Glue crea per il proprio tunnel.

Riepilogo

Il SEW Connectivity Service offre una soluzione matura, sicura e scalabile per le sfide della connettività industriale. Combinando tecnologie open-source consolidate come SoftEther VPN con un'infrastruttura cloud di livello enterprise basata su AWS IoT Core, il servizio fornisce l'affidabilità e la sicurezza richieste dalle operazioni industriali, offrendo al tempo stesso la flessibilità e la facilità d'uso che i moderni team di progettazione si aspettano.

L'architettura del servizio rispetta i principi di sicurezza industriale, abilitando al contempo le iniziative di trasformazione digitale che promuovono l'efficienza operativa, la collaborazione remota e il processo decisionale basato sui dati. Per le organizzazioni che desiderano connettere in modo sicuro i propri asset industriali ai servizi cloud senza compromettere la sicurezza di rete o l'affidabilità operativa, il SEW Connectivity Service offre una soluzione completa e pronta per la produzione.