SEW Connectivity Service

Überblick

Der SEW Connectivity Service basiert auf dem SDA Glue, der Anwendung für Gateways, die für Linux- und Windows-Hosts verfügbar ist. Der Service wird durch SoftEther VPN betrieben, das OpenVPN auf Windows-Clients unterstützt und einen sicheren TCP-Tunnel zwischen einer Netzwerkschnittstelle im Gateway und den SEW Cloud Services wie IDEaaS, Backup und Deployment-VMs herstellt. Zusätzlich kombiniert er die betriebssystemeigenen Firewalls, Linux iptables und die Windows Filtering Platform (WFP), mit einer NAT-Tabelle, um herstellerspezifische Software wie Siemens TIA Portal und Rockwell Studio 500 direkt mit dem Gerät in der Steuerungsebene der Produktion zu verbinden.

Kernpunkte

Die Verwaltung industrieller Anlagen mit SEW wird durch eine umfassende und sichere industrielle Konnektivitätslösung ermöglicht, die die Lücke zwischen Produktionsumgebungen und cloudbasierten Services schließt. Durch die Nutzung bewährter Technologien und die Umsetzung robuster Sicherheitsmaßnahmen bietet der Service Konnektivität auf Enterprise-Niveau, die speziell auf industrielle Automatisierungs- und Steuerungssysteme zugeschnitten ist.

Sicherheit auf Industrieniveau: Die Integration mit AWS IoT Core bietet sichere TLS-Verbindungen mit feingranularen Zugriffskontrollrichtlinien. Dies entspricht den Best Practices für industrielle IoT-Sicherheit und erlaubt es Administratoren, den Zugriff auf Basis von Geräteeigenschaften und Kontext einzuschränken.

Bewährte VPN-Grundlage: Der Service nutzt SoftEther VPN, das AES-256-Bit- und RSA-4096-Bit-Verschlüsselung mit hoher Durchsatzleistung sowie geringem Speicher- und CPU-Verbrauch bietet. So bleiben die übertragenen Daten vor Abhören und unbefugtem Zugriff geschützt – ideal für industrielle Anwendungen, in denen Sicherheit und Performance entscheidend sind.

Zero-Trust-Netzwerkzugriff: Der Service macht traditionelle statische VPNs überflüssig, indem Verbindungen bedarfsgerecht aufgebaut werden. Diese Punkt-zu-Punkt-Architektur stellt sicher, dass Benutzer ausschließlich auf explizit autorisierte Geräte zugreifen können und nicht auf ganze Netzwerksegmente, wodurch die Angriffsfläche erheblich reduziert wird.

Fabrikfreundliches Design: Alle Verbindungen werden vom Knoten selbst – einem Gateway oder einer Workstation – nach außen initiiert und niemals eingehend angenommen, sodass keinerlei eingehende Firewall-Regeln erforderlich sind. Dieses Design respektiert bestehende industrielle Sicherheitsarchitekturen und stellt gleichzeitig sichere Fernzugriffsmöglichkeiten bereit.

Architektur

Die Teilnehmer in einem virtuellen Netzwerk werden als Nodes bezeichnet und sind die Hauptkomponenten des Connectivity Service. Jede Verbindung entsteht aus dem Zusammenspiel einer Kette von Nodes, von denen jeder eine bestimmte Rolle einnimmt.

Devices: Industrielle Anlagen, die sich üblicherweise im gesicherten Produktionsnetzwerk befinden und über ihre IP-Adresse erreichbar sind, z. B. PLCs, HMIs und Roboter. Devices werden in der SEW Console für jeden Tenant deklariert und der Benutzerzugriff wird über Role-Based Access Control verwaltet. Für die Konnektivität muss jedes Device mit mindestens einem Netzwerk-Gateway verknüpft sein.

Gateways: Netzwerk-Hosts mit gesichertem Zugang zum Internet und zu den in der SEW Console verwalteten Devices. Üblicherweise handelt es sich um IPCs, VMs, Container oder auch Raspberry Pis, die in einer Firewall-Zone platziert sind, welche spezifische Regeln für den Zugriff auf SEW Cloud-Ressourcen wie Tenant Server erfordert. Auf jedem Gateway läuft der SDA Glue, ein Betriebssystemdienst, der auf Verbindungsanfragen lauscht und Telemetriedaten bereitstellt.

Workstations: Ein eigener PC des Kunden, der für den Zugriff auf Geräte über ein Gateway am Zielstandort verwendet wird. Auf einer Workstation läuft dieselbe SDA Glue-Software wie auf einem Gateway und sie wird auf Netzwerkebene identisch eingerichtet; der einzige Unterschied liegt in der Rolle – eine Workstation initiiert Verbindungen immer nach außen zu einem Gateway und leitet Datenverkehr niemals weiter an andere Geräte.

Tenant Server: Bastion-Hosts, die in einer gesicherten SEW Cloud-Umgebung betrieben werden, für jeden Tenant dediziert sind und die Netzwerkschnittstelle des Gateways mit einer SEW Service-VM oder mit einem anderen Gateway verbinden. Diese Server gewährleisten die erforderlichen Filterrichtlinien, um ausschließlich Punkt-zu-Punkt-Verbindungen sicherzustellen, etwa von IDEaaS zu einer bestimmten PLC und nicht zu anderen, nicht gewünschten Geräten im selben Netzwerk wie das Gateway. Außerdem authentifizieren sie den Zugriff von Gateways anhand einer Richtlinie zur Rotation von Zugangsdaten für jede Verbindung.

Service-VMs: Sie führen die von den SEW Services benötigten Anwendungen aus, wie IDEaaS, Backup und Deployment-Pipelines. Diese VMs nutzen den Connectivity Service, um auf Netzwerkebene über die IP-Adresse auf Devices zuzugreifen, was für industrielle Anwendungen essenziell ist.

Cloud

Anstatt traditionelle statische VPNs zu verwenden, baut der SEW Connectivity Service Verbindungen zu industriellen Anlagen auf Anfrage auf. Diese Anfragen werden an eine Kette von Nodes weitergeleitet, die zusammenarbeiten, um Punkt-zu-Punkt-Netzwerkzugriff zwischen SEW Services und Devices bereitzustellen.

Für das Produktionsnetzwerk werden alle Verbindungen vom Gateway aus initiiert, sodass in der Fabrik keine Regeln für eingehende Verbindungen erforderlich sind. Dazu lauschen die Nodes permanent an einem IoT-Message-Broker auf eingehende Anfragen, der durch AWS IoT Core betrieben wird.

Diese Architektur ermöglicht es Benutzern, von jedem Ort mit Internetzugang und von jedem Computer aus – lediglich abhängig vom Browser – mit Anlagen in der Fabrik zu interagieren.

Netzwerk

Das Gateway ist ein Edge-Gerät zwischen einer Steuerungsebene der Produktion und dem Internet, das den SEW Services kontrollierten Zugriff auf die in der Console definierten Anlagen bereitstellt. Daher ist es sehr wichtig, eine Architektur zu etablieren, die die SEW Cloud sicher mit der lokalen Infrastruktur verbindet. Wir empfehlen einen der beiden im Folgenden vorgeschlagenen Aufbauten für das Gateway.

Gateway im LAN

Dies ist der häufigste Ansatz, bei dem das Gateway direkt neben den PLCs platziert wird, die auf der SEW-Plattform onboarded sind. Hier kontrolliert eine Firewall strikt die ausgehenden Verbindungen vom Gateway ins Internet.

Das Gateway hat Zugriff auf das Subnetz, in dem es sich befindet, allerdings kann im Router des Netzwerks eine Firewall als Access Control Layer (ACL) bereitgestellt werden. Ebenfalls verbreitet ist der Einsatz eines Gateway-Geräts mit zwei Netzwerkschnittstellen: eine zur DMZ und eine private in der Steuerungsebene. Diese Architektur erlaubt sich wiederholende IP-Zonen, z. B. beide mit dem Subnetz 10.0.0.0/24.

Gateway in der DMZ

Dieser Ansatz wird häufig verwendet, wenn das Gateway in einer dedizierten virtuellen Maschine irgendwo in der Serverinfrastruktur betrieben wird. Das IT-Team stellt spezielle Routen zwischen der VM und den Ziel-PLCs in der Steuerungsebene bereit, und es existieren wahrscheinlich Firewalls sowohl beim Zugang zum Internet als auch zur OT.

gefahr

Beim Weg abwärts zu den PLCs kann außerdem eine Network Address Translation (NAT) vorhanden sein. Dies erfordert jedoch Aufmerksamkeit: Manche herstellerspezifische PLC-Software ist möglicherweise nicht damit kompatibel, die PLC über einen IP-Alias zu adressieren – sie erfordert unter Umständen den Zugriff auf die IP, die explizit im Projekt konfiguriert ist.

In diesem Fall muss jede PLC in der Produktionseinheit eine eindeutige IP-Adresse besitzen, andernfalls kann es zu Kollisionen kommen. Abhängig von der Netzwerkinfrastruktur funktioniert der Layer-2-Zugriff von Gateways auf PLCs möglicherweise nicht – dies ist ein kommendes Feature für die Integration von industriellen Echtzeitnetzwerken in die SEW Services.

Software

Der SDA Glue ist eine Anwendung, die als Betriebssystemdienst läuft und mit automatischem Start und Neustart im Fehlerfall eine hohe Verfügbarkeit des Gateways sicherstellt. Um die Netzwerktunnel durch die Verwaltung von Netzwerkressourcen wie Schnittstellen, Routen und Firewall-Regeln aufzubauen, benötigt er erhöhte Rechte als Systembenutzer.

Auto-Updates sind standardmäßig aktiviert. Der Glue-Dienst liest die neueste stabile Version von repository.eu1.sdacosole.io und wendet das Update an, sobald keine aktiven Verbindungen bestehen. Der Update-Mechanismus lädt die neue Anwendungs-Binary herunter, ersetzt die alte und startet den Dienst neu.

AWS IoT Core wird während der Anmeldung verbunden, wobei der Endpunkt iot.eu1.sdaconsole.io verwendet wird. Nach dem Verbindungsaufbau lauscht der Glue-Dienst permanent auf Anfragen aus der SEW Cloud und veröffentlicht Telemetriedaten, wie den Status der Devices, die mit dem Gateway verknüpft sind. Die IoT-Authentifizierung ist durch eine kurze ID und ein Einmalpasswort geschützt, das aus der SEW Console abgerufen werden kann. Die Verbindung zu IoT wird zusätzlich durch einen geheimen Schlüssel in der Anwendungs-Binary gesichert. Die Verbindung zu IoT kann so konfiguriert werden, dass sie über MQTT SSL oder WebSocket Secure erfolgt, jeweils über Port 443.

Die Netzwerkmechanismen unterscheiden sich zwischen Linux und Windows. Daher werden sie separat beschrieben.

Linux

SDA Glue unter Linux basiert auf dem SoftEther VPN Client, der Open Source ist (Apache License 2.0) und während der Glue-Installation aus dem SEW-Mirror auf repository.eu1.sdaconsole.io installiert wird.

Für jede Verbindung verwendet Glue den SoftEther Client, um eine NIC-Netzwerkschnittstelle zu erstellen und mit dem Tenant Server zu verbinden. Außerdem nutzt es die Linux-IP-Tools, um dieser Schnittstelle eine IP-Adresse zuzuweisen und die notwendigen Routen zwischen der Service-VM und dem Ziel-Device zu erstellen.

Interne Firewall-Regeln und NAT-Übersetzung werden in iptables erstellt, wodurch keine eingehenden Netzwerkpakete an das Gateway selbst zugelassen werden, sondern ausschließlich die Weiterleitung von Paketen an das Ziel-Device.

📚 Linux-Ressourcenverwaltung bei Verbindungen

Um zu verstehen, wie das Linux-Gateway Cloud-Services mit Fabrikgeräten verbindet, betrachten wir ein konkretes Beispiel mit bestimmten IP-Adressen, das den gesamten Ablauf veranschaulicht.

Stellen Sie sich ein Fabriknetzwerk vor, in dem ein Ziel-Device (etwa eine PLC) die lokale IP-Adresse 10.0.0.5 besitzt und das Gateway im selben Netzwerk mit der IP 10.0.0.2 liegt. In der SEW Cloud muss eine Service-VM sich mit diesem Device verbinden und erhält die VPN-IP 100.112.20.3, während die VPN-Schnittstelle des Gateways 100.112.10.6 zugewiesen bekommt.

Aufbau des Tunnels

Wenn eine Verbindungsanfrage eintrifft, werden sowohl das Gateway als auch die Service-VM aktiv. Das Gateway erstellt eine neue virtuelle Netzwerkschnittstelle namens vpn_iface und weist ihr die Adresse 100.112.10.6 zu. Gleichzeitig erstellt die Service-VM in der Cloud ihre eigene VPN-Schnittstelle mit der IP 100.112.20.3. Beide Endpunkte verbinden sich anschließend mit dem Tenant Server und bauen damit einen sicheren verschlüsselten Tunnel zwischen sich auf.

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

An diesem Punkt existiert der Tunnel, aber die Pakete wissen noch nicht, wohin sie sollen. Das Gateway muss dem System erst beibringen, wie der Datenverkehr zwischen diesen beiden Welten geroutet wird.

Aufbau der Routen

Das Gateway fügt eine Routing-Regel hinzu, welche die Verbindung zwischen dem VPN-Netzwerk und der Fertigungsebene herstellt:

ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface

Diese Route teilt dem System eine entscheidende Information mit: Wenn das Device unter 10.0.0.5 Antwortpakete sendet, sollen diese über vpn_iface weitergeleitet werden, um die Service-VM unter 100.112.20.3 zu erreichen. Ohne diese Route wüsste das Gateway nicht, wie es die Antworten des Devices zurück in die Cloud senden soll.

Routing allein genügt jedoch nicht. Die Firewall des Gateways würde diesen Datenverkehr standardmäßig weiterhin blockieren. Um die Verbindung zu ermöglichen, muss das Gateway die bidirektionale Paketweiterleitung zwischen der VM und dem Device explizit erlauben:

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

Diese Regeln öffnen einen kontrollierten Pfad, über den Pakete von der Service-VM zum Device und zurück fließen können, während die Sicherheitslage des Gateways für allen anderen Datenverkehr erhalten bleibt. Beachten Sie außerdem, dass Glue eigene Chains in iptables verwendet, um Konflikte mit anderen Regeln zu vermeiden.

NAT-Übersetzung

Das Device in der Fabrik erwartet die Kommunikation mit lokalen IP-Adressen – es hat keine Kenntnis vom Cloud-Netzwerk unter 100.112.20.3 und wüsste nicht, wie es auf Pakete von dieser Adresse antworten soll. Das Gateway löst dies, indem es die Pakete der Service-VM maskiert:

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

Mit dieser NAT-Regel schreibt das Gateway bei einem Paket, das von der Service-VM an das Device gerichtet ist, die Quelladresse von 100.112.20.3 auf 10.0.0.2 um. Aus Sicht des Devices kommuniziert es direkt mit dem Gateway selbst – einer bekannten, vertrauenswürdigen Adresse in seinem lokalen Netzwerk. Wenn das Device seine Antwort an 10.0.0.2 sendet, führt das Gateway die umgekehrte Übersetzung durch und ändert die Zieladresse zurück auf 100.112.20.3, sodass das Paket die Service-VM über den VPN-Tunnel erreicht.

Durch dieses Zusammenspiel von VPN-Tunneling, Routing, Firewall-Regeln und NAT-Übersetzung erstellt das Gateway eine transparente Punkt-zu-Punkt-Verbindung. Das Device sieht die Cloud-Infrastruktur nie – es kommuniziert lediglich mit dem, was ihm als Gateway in seinem lokalen Netzwerk unter 10.0.0.2 erscheint. Gleichzeitig erhält die Service-VM direkten Zugriff auf Netzwerkebene auf das Device über dessen IP-Adresse 10.0.0.5, sodass industrielle Anwendungen wie TIA Portal oder Studio 5000 so funktionieren, als würden sie im lokalen Fabriknetzwerk selbst laufen.

Windows

SDA Glue unter Windows unterstützt die eingebettete Nutzung des SoftEther VPN Client nicht und verwendet daher den OpenVPN Community Open-Source Client (GPL-Lizenz Version 2), der während der Glue-Installation aus dem SEW-Mirror auf repository.eu1.sdaconsole.io installiert wird.

Für jede Verbindung verwendet Glue den OpenVPN TAP-Treiber, um eine Netzwerkschnittstelle zu erstellen und diese mittels zertifikatsbasierter Authentifizierung mit dem Tenant Server zu verbinden. Über die native Windows-API wird der Schnittstelle eine IP zugewiesen und die notwendigen Routen zwischen der Service-VM und dem Ziel-Device werden erstellt.

Glue nutzt außerdem die Windows Filtering Platform (WFP), um dedizierte Layer und Firewall-Regeln zu erstellen. Für die Deklaration der Adressübersetzung zwischen der Service-VM und dem Device ist es jedoch auf WinNAT oder NetNat angewiesen, was möglicherweise nicht standardmäßig aktiviert ist.

Workstation vs. Gateway: Workstations und Gateways verwenden den identischen Windows-Client und den oben beschriebenen Verbindungsaufbau – denselben OpenVPN TAP-Treiber, dieselbe WinNAT-basierte Schnittstellenadressierung. Der einzige Unterschied liegt in der WFP-Firewall-Regel, die pro Verbindung durch die Backend-Richtlinie zugewiesen wird: Die Verbindung einer Workstation erhält immer eine ausschließlich ausgehende Regel, die auf die spezifische Ziel-Geräte-IP über die SEW-Tunnelschnittstelle begrenzt ist, während ein Gateway zusätzlich eine Weiterleitungsregel erhalten kann, um Datenverkehr an dahinterliegende Geräte zu vermitteln. Eine Workstation öffnet daher niemals eingehende oder weiterleitende Pfade auf dem Host, und keine andere Netzwerkschnittstelle, Route oder bestehende VPN-Verbindung auf diesem PC wird beeinflusst – alle Änderungen bleiben auf die virtuelle Schnittstelle beschränkt, die SDA Glue für seinen eigenen Tunnel erstellt.

Zusammenfassung

Der SEW Connectivity Service bietet eine ausgereifte, sichere und skalierbare Lösung für die Herausforderungen industrieller Konnektivität. Durch die Kombination bewährter Open-Source-Technologien wie SoftEther VPN mit Cloud-Infrastruktur auf Enterprise-Niveau von AWS IoT Core liefert der Service die Zuverlässigkeit und Sicherheit, die industrielle Betriebsabläufe erfordern, und bietet gleichzeitig die Flexibilität und Benutzerfreundlichkeit, die moderne Engineering-Teams erwarten.

Die Architektur des Service respektiert industrielle Sicherheitsprinzipien und ermöglicht gleichzeitig die Initiativen zur digitalen Transformation, die betriebliche Effizienz, standortübergreifende Zusammenarbeit und datengetriebene Entscheidungsfindung vorantreiben. Für Organisationen, die ihre industriellen Anlagen sicher mit Cloud-Services verbinden möchten, ohne Kompromisse bei der Netzwerksicherheit oder der Betriebszuverlässigkeit einzugehen, bietet der SEW Connectivity Service eine umfassende, produktionsreife Lösung.