SDA Connectivity Service

Panoramica

L'SDA Connectivity Service si basa su SDA Glue, l'applicazione per i Gateway, disponibile per host Linux e Windows. Il servizio è basato su SoftEther VPN, che supporta OpenVPN sui client Windows, stabilendo un tunnel TCP sicuro tra un'interfaccia di rete nel Gateway e i servizi cloud SDA, 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 al dispositivo nel livello di controllo della produzione.

Punti chiave

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

Sicurezza di livello industriale: l'integrazione con AWS IoT Core fornisce connessioni TLS sicure con politiche 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.

Base VPN consolidata: il servizio utilizza SoftEther VPN, che fornisce crittografia AES a 256 bit e RSA a 4096 bit con prestazioni di throughput elevate e un basso utilizzo 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.

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

Progettazione compatibile con la fabbrica: tutte le connessioni vengono avviate verso l'esterno dal nodo stesso — un Gateway o una Workstation — e mai accettate in ingresso, pertanto non sono mai necessarie regole firewall in ingresso. Questa progettazione rispetta le architetture di sicurezza industriali esistenti offrendo al contempo 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 situati nella rete sicura di produzione, accessibili tramite il loro indirizzo IP, ad es. PLC, HMI e robot. I Devices vengono dichiarati nella SDA 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 Devices gestiti nella SDA Console. Si tratta generalmente di IPC, VM, container e persino Raspberry Pi, situati in una zona firewall che richiede regole specifiche per accedere alle risorse SDA Cloud, come i Tenant Server. Ogni Gateway esegue SDA Glue, che è un servizio del sistema operativo in ascolto delle richieste di connessione e che fornisce dati di telemetria.

Workstations: un PC del cliente, utilizzato per accedere ai dispositivi tramite un Gateway nel 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 traffico verso altri dispositivi.

Tenant Servers: bastion host in esecuzione in un ambiente SDA Cloud sicuro, dedicati a ogni Tenant, che collegano l'interfaccia di rete del Gateway con una VM di servizio SDA o con un altro Gateway. Questi Server garantiscono le politiche di filtraggio necessarie per assicurare esclusivamente connessioni Point-to-Point, ad esempio da IDEaaS a un PLC specifico e non ad altri dispositivi non desiderati nella stessa rete del Gateway. Autenticano inoltre l'accesso dai Gateway in base a una politica di rotazione delle credenziali per ogni connessione.

Service VMs: eseguono le applicazioni necessarie ai Servizi SDA, come IDEaaS, Backup e Deployment Pipelines. Queste VM si affidano al Connectivity Service per accedere ai Devices a livello di rete, tramite il loro indirizzo IP, aspetto essenziale per le applicazioni industriali.

Cloud

Invece di utilizzare VPN statiche tradizionali, l'SDA Connectivity Service stabilisce connessioni verso gli asset industriali su richiesta; tali richieste vengono inoltrate a una catena di Nodi che operano insieme per fornire accesso di rete Point-to-Point tra i Servizi SDA e i Devices.

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

Questa architettura consente agli utenti di interagire con gli asset in fabbrica da qualsiasi luogo dotato di Internet, da qualsiasi computer, dipendendo unicamente dal browser.

Rete

Il Gateway è un dispositivo edge collocato tra un livello di controllo della produzione e Internet, che fornisce ai servizi SDA un accesso controllato agli asset definiti nella Console. È pertanto molto importante consolidare un'architettura che colleghi in modo sicuro l'SDA 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 vengono integrati nella piattaforma SDA. In questo caso, un firewall controlla rigorosamente le connessioni in uscita dal Gateway verso Internet.

Il Gateway ha accesso alla subnet in cui si trova, ma un firewall può essere predisposto 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 predisporrà 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ò inoltre esistere una Network Address Translation (NAT) nel percorso a valle verso i PLC. Ciò richiede però 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'IP configurato esplicitamente nel progetto.

In questo caso, ogni PLC nell'unità produttiva deve avere un indirizzo IP univoco, altrimenti possono verificarsi collisioni. Inoltre, in base all'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 SDA.

Software

SDA Glue è un'applicazione che viene eseguita come servizio del sistema operativo, garantendo l'elevata 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 l'elevazione dei privilegi come utente di sistema.

Gli aggiornamenti automatici sono abilitati per impostazione predefinita. Il servizio Glue leggerà l'ultima versione stabile 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 sarà costantemente in ascolto delle richieste provenienti dall'SDA Cloud e pubblicherà dati di telemetria, come lo stato dei Devices associati al Gateway. L'autenticazione IoT è protetta da un ID breve e da una password monouso recuperabile dalla SDA 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 differenti 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 SDA su repository.eu1.sdaconsole.io durante l'installazione di Glue.

Per ogni connessione, Glue utilizza il SoftEther Client 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 ai dispositivi di fabbrica, esaminiamo un esempio concreto con indirizzi IP specifici che illustrano il flusso completo.

Consideriamo 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. Nell'SDA 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.

Creazione del 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 denominata 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 cifrato 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 indicare al sistema come instradare il traffico tra questi due mondi.

Creazione delle route

Il Gateway aggiunge una regola di routing che crea il collegamento 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 fondamentale: 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 routing da solo 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 contempo 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 in vigore, quando un pacchetto arriva 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 comunicare direttamente con il Gateway stesso — un indirizzo noto e affidabile nella sua rete locale. Quando il Device invia la sua risposta a 10.0.0.2, il Gateway esegue la traduzione inversa, riportando l'indirizzo di destinazione a 100.112.20.3 affinché il pacchetto raggiunga la Service VM attraverso il tunnel VPN.

Attraverso 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 appare essere il Gateway nella sua rete locale all'indirizzo 10.0.0.2. Nel frattempo, la Service VM ottiene 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 in esecuzione nella rete locale della fabbrica stessa.

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 SDA 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 il client Windows e la configurazione di connessione identici descritti sopra — stesso driver TAP di OpenVPN, stesso indirizzamento delle interfacce basato su WinNAT. L'unica differenza è la regola firewall WFP assegnata per connessione dalla policy del backend: la connessione di una Workstation riceve sempre una regola solo in uscita limitata all'IP del dispositivo di destinazione specifico attraverso l'interfaccia del tunnel SDA, mentre un Gateway può ricevere in aggiunta una regola di inoltro per collegare il traffico verso i dispositivi situati a valle. Una Workstation non apre pertanto 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

L'SDA 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 fornita da AWS IoT Core, il servizio garantisce l'affidabilità e la sicurezza richieste dalle operazioni industriali, offrendo al contempo 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 favoriscono l'efficienza operativa, la collaborazione remota e il processo decisionale basato sui dati. Per le organizzazioni che desiderano collegare in modo sicuro i propri asset industriali ai servizi cloud senza compromettere la sicurezza di rete o l'affidabilità operativa, l'SDA Connectivity Service fornisce una soluzione completa e pronta per la produzione.