SDA Connectivity Service

Overzicht

De SDA Connectivity Service maakt gebruik van de SDA Glue, de applicatie voor Gateways, beschikbaar voor Linux- en Windows-hosts. De service wordt mogelijk gemaakt door SoftEther VPN, dat OpenVPN ondersteunt op Windows-clients, en brengt een beveiligde TCP-tunnel tot stand tussen een netwerkinterface in de Gateway en de SDA-cloudservices, zoals IDEaaS, Backup en Deployment VM's. Daarnaast combineert het de native firewalls van het besturingssysteem, Linux iptables en Windows Filtering Platform (WFP), met een NAT-tabel om leveranciersspecifieke software, zoals Siemens TIA Portal en Rockwell Studio 500, direct te verbinden met het apparaat in de besturingslaag van de productieomgeving.

Belangrijkste punten

Het beheren van industriële assets met SDA wordt mogelijk gemaakt door een uitgebreide en veilige oplossing voor industriële connectiviteit die de kloof overbrugt tussen productieomgevingen en cloudgebaseerde services. Door het inzetten van bewezen technologieën en het implementeren van robuuste beveiligingsmaatregelen levert de service connectiviteit op enterpriseniveau, specifiek toegespitst op industriële automatisering en besturingssystemen.

Beveiliging op industrieel niveau: De integratie met AWS IoT Core biedt veilige TLS-verbindingen met fijnmazige beleidsregels voor toegangsbeheer. Dit volgt de best practices voor industriële IoT-beveiliging en stelt beheerders in staat de toegang te beperken op basis van apparaateigenschappen en context.

Bewezen VPN-fundament: De service gebruikt SoftEther VPN, dat AES 256-bits en RSA 4096-bits encryptie biedt met hoge doorvoerprestaties en een laag geheugen- en CPU-gebruik. Zo blijft data tijdens transport beveiligd tegen afluisteren en ongeoorloofde toegang — ideaal voor industriële toepassingen waarbij beveiliging en prestaties cruciaal zijn.

Zero-Trust Network Access: De service maakt traditionele statische VPN's overbodig door verbindingen op aanvraag tot stand te brengen. Deze Point-to-Point-architectuur zorgt ervoor dat gebruikers uitsluitend toegang hebben tot specifiek geautoriseerde apparaten, en niet tot volledige netwerksegmenten, waardoor het aanvalsoppervlak aanzienlijk wordt verkleind.

Fabrieksvriendelijk ontwerp: Alle verbindingen worden uitgaand geïnitieerd door de node zelf — een Gateway of een Workstation — en nooit inkomend geaccepteerd, waardoor er nooit inkomende firewallregels nodig zijn. Dit ontwerp respecteert bestaande industriële beveiligingsarchitecturen en biedt tegelijkertijd veilige mogelijkheden voor toegang op afstand.

Architectuur

De peers in een virtueel netwerk worden Nodes genoemd; zij zijn de belangrijkste componenten in de Connectivity Service. Elke verbinding wordt opgebouwd uit de interactie van een keten van Nodes, elk met een specifieke rol.

Devices: industriële assets die zich doorgaans in het beveiligde productienetwerk bevinden en die via hun IP-adres benaderbaar zijn, bijv. PLC's, HMI's en robots. Devices worden voor elke Tenant gedeclareerd in de SDA Console en gebruikerstoegang wordt beheerd via Role-Based Access Control. Connectiviteit vereist dat elk Device is gekoppeld aan minimaal één netwerk-Gateway.

Gateways: netwerkhosts met veilige toegang tot het internet en tot de Devices die in de SDA Console worden beheerd. Meestal zijn dit IPC's, VM's, containers en zelfs Raspberry Pi's, geplaatst in een firewallzone die specifieke regels vereist voor toegang tot de SDA-cloudresources, zoals Tenant Servers. Op elke Gateway draait de SDA Glue: een OS-service die naar verbindingsverzoeken luistert en telemetriegegevens levert.

Workstations: Een eigen pc van de klant, gebruikt om via een Gateway op de doellocatie toegang te krijgen tot apparaten. Op een Workstation draait dezelfde SDA Glue-software als op een Gateway en de netwerkinstellingen zijn identiek; het enige verschil is de rol — een Workstation initieert altijd uitgaand naar een Gateway en leidt verkeer nooit verder door naar andere apparaten.

Tenant Servers: bastion hosts die in een beveiligde SDA-cloudomgeving draaien, toegewijd aan elke Tenant, en die de netwerkinterface van de Gateway verbinden met een SDA Service VM of met een andere Gateway. Deze Servers garanderen de vereiste filterbeleidsregels om uitsluitend Point-to-Point-verbindingen te waarborgen, bijvoorbeeld van IDEaaS naar een specifieke PLC en niet naar andere ongewenste apparaten in hetzelfde netwerk als de Gateway. Zij authenticeren tevens de toegang vanaf Gateways op basis van een rotatiebeleid voor credentials bij elke verbinding.

Service VM's: draaien de applicaties die nodig zijn voor SDA Services, zoals IDEaaS, Backup en Deployment Pipelines. Deze VM's maken gebruik van de Connectivity Service om Devices op de netwerklaag te benaderen via hun IP-adres, wat essentieel is voor industriële toepassingen.

Cloud

In plaats van traditionele statische VPN's te gebruiken, brengt de SDA Connectivity Service verbindingen naar industriële assets tot stand op aanvraag. Deze aanvragen worden doorgestuurd naar een keten van Nodes die samenwerken om Point-to-Point-netwerktoegang tussen SDA Services en Devices te bieden.

Voor het productienetwerk worden alle verbindingen vanaf de Gateway geïnitieerd, waardoor er geen inkomende verbindingsregels in de fabriek nodig zijn. Om dit te bereiken luisteren Nodes continu op een IoT message broker naar inkomende verzoeken; deze wordt mogelijk gemaakt door AWS IoT Core.

Deze architectuur stelt gebruikers in staat om vanaf elke plek met internet en vanaf elke computer met assets in de fabriek te werken, afhankelijk van uitsluitend een browser.

Netwerk

De Gateway is een edge-apparaat dat zich tussen een productiebesturingslaag en het internet bevindt en dat SDA-services gecontroleerde toegang geeft tot de assets die in de Console zijn gedefinieerd. Daarom is het erg belangrijk om een architectuur te consolideren die de SDA Cloud veilig verbindt met de lokale infrastructuur. Wij raden een van de twee onderstaande voorgestelde opstellingen voor de Gateway aan.

Gateway in LAN

Dit is de meest gebruikelijke aanpak, waarbij we de Gateway naast de PLC's plaatsen die op het SDA-platform zijn aangesloten. Hier controleert een firewall streng het uitgaande verkeer van de Gateway naar het internet.

De Gateway heeft toegang tot het subnet waarin deze zich bevindt, maar in de router van het netwerk kan een firewall worden ingericht als Access Control Layer (ACL). Het is ook gebruikelijk om een Gateway-apparaat met twee netwerkinterfaces te gebruiken: één gericht op de DMZ en een privé-interface in de besturingslaag. Deze architectuur maakt herhaalde IP-zones mogelijk, bijv. beide met het subnet 10.0.0.0/24.

Gateway in DMZ

Deze aanpak wordt veel gebruikt wanneer de Gateway in een dedicated virtuele machine draait, ergens in de serverinfrastructuur. Het IT-team zorgt voor speciale routes tussen de VM en de doel-PLC's in de besturingslaag, en er zullen waarschijnlijk firewalls bestaan voor zowel de toegang tot het internet als tot OT.

gevaar

Bij verkeer stroomafwaarts naar de PLC's kan er ook Network Address Translation (NAT) aanwezig zijn. Dit vraagt echter aandacht: sommige leveranciersspecifieke PLC-software is mogelijk niet compatibel met het adresseren van de PLC via een IP-alias; deze software vereist mogelijk toegang tot het IP-adres dat expliciet in het project is geconfigureerd.

In dit geval moet elke PLC in de productie-eenheid een uniek IP-adres hebben, anders kunnen er conflicten optreden. Afhankelijk van de netwerkinfrastructuur werkt Layer 2-toegang van Gateways naar PLC's mogelijk niet; dit is een aankomende functie voor de integratie van industriële realtimenetwerken in de SDA-services.

Software

De SDA Glue is een applicatie die als OS-service draait en zorgt voor hoge beschikbaarheid van de Gateway met geautomatiseerde start en herstart bij fouten. Om de netwerktunnels tot stand te brengen door netwerkresources zoals interfaces, routes en firewallregels te beheren, is verhoging van rechten als systeemgebruiker vereist.

Automatische updates zijn standaard ingeschakeld. De Glue-service leest de nieuwste stabiele versie van repository.eu1.sdacosole.io en past de update toe zodra er geen actieve verbindingen zijn. Het updatemechanisme downloadt de nieuwe applicatiebinary, vervangt daarmee de oude en start de service opnieuw.

AWS IoT Core wordt tijdens het inloggen verbonden via het endpoint iot.eu1.sdaconsole.io. Zodra de verbinding tot stand is gebracht, luistert de Glue-service continu naar verzoeken van de SDA Cloud en publiceert telemetriegegevens, zoals de status van de Devices die aan de Gateway zijn gekoppeld. De IoT-authenticatie wordt beschermd door een korte ID en een eenmalig wachtwoord die kunnen worden opgehaald uit de SDA Console. De verbinding met IoT wordt tevens beveiligd door een secret key in de applicatiebinary. De verbinding met IoT kan worden geconfigureerd via MQTT SSL of WebSocket Secure, beide op poort 443.

De netwerkmechanismen verschillen voor Linux en Windows. Daarom worden ze afzonderlijk beschreven.

Linux

SDA Glue op Linux maakt gebruik van de SoftEther VPN Client, die open source is (Apache License 2.0) en tijdens de Glue-installatie wordt geïnstalleerd vanaf de SDA-mirror op repository.eu1.sdaconsole.io.

Voor elke verbinding gebruikt Glue de SoftEther Client om een NIC-netwerkinterface te creëren en deze met de Tenant Server te verbinden. Daarnaast gebruikt het Linux IP-tools om een IP-adres aan die interface toe te wijzen en de benodigde routes tussen de Service VM en het doel-Device aan te maken.

Interne firewallregels en NAT-translatie worden aangemaakt in iptables, dat geen inkomende netwerkpakketten naar de Gateway toestaat, maar uitsluitend het doorsturen van pakketten naar het doel-Device.

📚 Beheer van Linux-resources bij verbindingen

Om te begrijpen hoe de Linux-Gateway cloudservices verbindt met fabrieksapparaten, doorlopen we een concreet voorbeeld met specifieke IP-adressen die de volledige flow illustreren.

Neem een fabrieksnetwerk waarin een doel-Device (zoals een PLC) het lokale IP-adres 10.0.0.5 heeft en de Gateway zich in hetzelfde netwerk bevindt met IP 10.0.0.2. In de SDA Cloud moet een Service VM verbinding maken met dit Device en krijgt deze het VPN-IP 100.112.20.3 toegewezen, terwijl de VPN-interface van de Gateway 100.112.10.6 ontvangt.

De tunnel tot stand brengen

Wanneer een verbindingsverzoek binnenkomt, komen zowel de Gateway als de Service VM in actie. De Gateway creëert een nieuwe virtuele netwerkinterface met de naam vpn_iface en wijst deze het adres 100.112.10.6 toe. Gelijktijdig creëert de Service VM in de cloud zijn eigen VPN-interface met het IP 100.112.20.3. Beide endpoints maken vervolgens verbinding met de Tenant Server, waardoor een beveiligde, versleutelde tunnel tussen hen tot stand komt.

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

Op dit punt bestaat de tunnel, maar weten pakketten nog niet waar ze naartoe moeten. De Gateway moet het systeem leren hoe het verkeer tussen deze twee werelden gerouteerd moet worden.

De routes opbouwen

De Gateway voegt een routeringsregel toe die de verbinding tussen het VPN-netwerk en de fabrieksvloer tot stand brengt:

ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface

Deze route geeft het systeem cruciale informatie: wanneer het Device op 10.0.0.5 responspakketten verzendt, moeten deze via vpn_iface worden doorgestuurd om de Service VM op 100.112.20.3 te bereiken. Zonder deze route zou de Gateway niet weten hoe de antwoorden van het Device terug naar de cloud gestuurd moeten worden.

Maar routering alleen is niet genoeg. De firewall van de Gateway zou dit verkeer standaard nog steeds blokkeren. Om de verbinding mogelijk te maken, moet de Gateway expliciet bidirectioneel doorsturen van pakketten tussen de VM en het Device toestaan:

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

Deze regels openen een gecontroleerd pad, waardoor pakketten van de Service VM naar het Device en terug kunnen stromen, terwijl de beveiligingspositie van de Gateway voor al het overige verkeer behouden blijft. Merk daarnaast op dat Glue eigen chains in iptables gebruikt om conflicten met de andere regels te voorkomen.

NAT-translatie

Het Device in de fabriek verwacht te communiceren met lokale IP-adressen — het heeft geen kennis van het cloudnetwerk op 100.112.20.3 en zou niet weten hoe het op pakketten van dat adres moet reageren. De Gateway lost dit op door de pakketten van de Service VM te maskeren:

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

Met deze NAT-regel herschrijft de Gateway, wanneer er een pakket van de Service VM voor het Device binnenkomt, het bronadres van 100.112.20.3 naar 10.0.0.2. Vanuit het perspectief van het Device lijkt het alsof het direct met de Gateway zelf communiceert — een bekend, vertrouwd adres in zijn lokale netwerk. Wanneer het Device zijn antwoord naar 10.0.0.2 stuurt, voert de Gateway de omgekeerde translatie uit en wijzigt het bestemmingsadres terug naar 100.112.20.3, zodat het pakket via de VPN-tunnel de Service VM bereikt.

Door deze orkestratie van VPN-tunneling, routering, firewallregels en NAT-translatie creëert de Gateway een transparante point-to-point-verbinding. Het Device ziet de cloudinfrastructuur nooit — het communiceert simpelweg met wat de Gateway in zijn lokale netwerk op 10.0.0.2 lijkt te zijn. Tegelijkertijd krijgt de Service VM directe toegang op netwerkniveau tot het Device via het IP-adres 10.0.0.5, waardoor industriële applicaties zoals TIA Portal of Studio 5000 kunnen functioneren alsof ze op het lokale fabrieksnetwerk zelf draaien.

Windows

SDA Glue op Windows ondersteunt geen ingebed gebruik van de SoftEther VPN Client en gebruikt daarom de OpenVPN Community Open-Source Client (GPL-licentie versie 2), die tijdens de Glue-installatie wordt geïnstalleerd vanaf de SDA-mirror op repository.eu1.sdaconsole.io.

Voor elke verbinding gebruikt Glue de OpenVPN TAP-driver om een netwerkinterface te creëren en deze met certificaatgebaseerde authenticatie met de Tenant Server te verbinden. Het gebruikt de native Windows-API om een IP aan de interface toe te wijzen en de benodigde routes tussen de Service VM en het doel-Device aan te maken.

Glue gebruikt ook Windows Filtering Platform (WFP) om dedicated lagen en firewallregels te creëren. Voor het declareren van de adrestranslatie tussen de Service VM en het Device is het echter afhankelijk van WinNAT of NetNat, die mogelijk niet standaard zijn ingeschakeld.

Workstation versus Gateway: Workstations en Gateways gebruiken dezelfde Windows-client en verbindingsopstelling zoals hierboven beschreven — dezelfde OpenVPN TAP-driver, dezelfde WinNAT-gebaseerde interfaceadressering. Het enige verschil is de WFP-firewallregel die per verbinding door het backendbeleid wordt toegewezen: de verbinding van een Workstation ontvangt altijd een uitsluitend uitgaande regel die beperkt is tot het specifieke doel-apparaat-IP via de SDA-tunnelinterface, terwijl een Gateway daarnaast een doorstuurregel kan ontvangen om verkeer verder te bruggen naar apparaten daarachter. Een Workstation opent daarom nooit inkomende of doorsturende paden op de host, en geen enkele andere netwerkinterface, route of bestaande VPN-verbinding op die pc wordt beïnvloed — alle wijzigingen blijven beperkt tot de virtuele interface die SDA Glue voor zijn eigen tunnel aanmaakt.

Samenvatting

De SDA Connectivity Service levert een volwassen, veilige en schaalbare oplossing voor uitdagingen op het gebied van industriële connectiviteit. Door bewezen open-sourcetechnologieën zoals SoftEther VPN te combineren met cloudinfrastructuur op enterpriseniveau van AWS IoT Core, biedt de service de betrouwbaarheid en beveiliging die industriële activiteiten vereisen, met daarbij de flexibiliteit en het gebruiksgemak die moderne engineeringteams verwachten.

De architectuur van de service respecteert industriële beveiligingsprincipes en maakt tegelijkertijd de initiatieven voor digitale transformatie mogelijk die operationele efficiëntie, samenwerking op afstand en datagestuurde besluitvorming stimuleren. Voor organisaties die hun industriële assets veilig met cloudservices willen verbinden zonder de netwerkbeveiliging of operationele betrouwbaarheid in gevaar te brengen, biedt de SDA Connectivity Service een complete, productieklare oplossing.