SDA Connectivity Service

Überblick

Der SDA Connectivity Service basiert auf SDA Glue, der Anwendung für Gateways, die für Linux- und Windows-Hosts verfügbar ist. Der Dienst nutzt SoftEther VPN, das auf Windows-Clients OpenVPN unterstützt, und baut einen sicheren TCP-Tunnel zwischen einer Netzwerkschnittstelle im Gateway und den SDA Cloud-Diensten wie IDEaaS, Backup- und Deployment-VMs auf. 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 Fertigung zu verbinden.

Wesentliche Punkte

Die Verwaltung industrieller Assets mit SDA stützt sich auf eine umfassende, sichere Konnektivitätslösung für die Industrie, die die Lücke zwischen Fertigungsumgebungen und cloudbasierten Diensten schließt. Durch den Einsatz bewährter Technologien und robuster Sicherheitsmaßnahmen bietet der Dienst Konnektivität auf Unternehmensniveau, die speziell auf industrielle Automatisierungs- und Steuerungssysteme zugeschnitten ist.

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

Bewährte VPN-Grundlage: Der Dienst nutzt SoftEther VPN mit AES-256-Bit- und RSA-4096-Bit-Verschlüsselung, hohem Durchsatz sowie geringem Speicher- und CPU-Bedarf. So bleiben übertragene Daten vor Mitlesen und unbefugtem Zugriff geschützt – ideal für industrielle Anwendungen, bei denen Sicherheit und Performance entscheidend sind.

Zero-Trust-Netzwerkzugriff: Der Dienst macht klassische statische VPNs überflüssig, indem Verbindungen bedarfsgesteuert aufgebaut werden. Diese Punkt-zu-Punkt-Architektur stellt sicher, dass Benutzer ausschließlich auf ausdrücklich freigegebene Geräte zugreifen können und nicht auf ganze Netzwerksegmente – die Angriffsfläche wird dadurch erheblich reduziert.

Fabriktaugliches Design: Alle Verbindungen werden vom Knoten selbst – einem Gateway oder einer Workstation – nach außen initiiert und niemals eingehend angenommen. Eingehende Firewall-Regeln sind daher zu keinem Zeitpunkt erforderlich. Dieses Design respektiert bestehende industrielle Sicherheitsarchitekturen und ermöglicht zugleich sicheren Fernzugriff.

Architektur

Die Teilnehmer eines virtuellen Netzwerks werden als Nodes bezeichnet und bilden die Hauptkomponenten des Connectivity Service. Jede Verbindung entsteht aus dem Zusammenspiel einer Kette von Nodes, von denen jeder eine bestimmte Rolle übernimmt.

Devices: Industrielle Assets, die sich in der Regel im gesicherten Fertigungsnetz befinden und über ihre IP-Adresse erreichbar sind, z. B. SPSen, HMIs und Roboter. Devices werden in der SDA Console je Tenant angelegt; der Benutzerzugriff wird über die rollenbasierte Zugriffskontrolle gesteuert. 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 SDA Console verwalteten Devices. Dabei handelt es sich meist um IPCs, VMs, Container oder auch Raspberry Pis, die in einer Firewall-Zone liegen, welche spezifische Regeln für den Zugriff auf SDA Cloud-Ressourcen wie Tenant Server erfordert. Auf jedem Gateway läuft SDA Glue – ein Betriebssystemdienst, der auf Verbindungsanfragen lauscht und Telemetriedaten bereitstellt.

Workstations: Ein kundeneigener PC, über den Geräte mittels eines Gateway am Zielstandort erreicht werden. Auf einer Workstation läuft dieselbe SDA-Glue-Software wie auf einem Gateway und sie wird auf Netzwerkebene identisch eingerichtet; der einzige Unterschied ist die Rolle: Eine Workstation initiiert stets nach außen zu einem Gateway und leitet Datenverkehr niemals an weitere Geräte weiter.

Tenant Server: Bastion-Hosts, die in einer gesicherten SDA Cloud-Umgebung betrieben werden, für jeden Tenant dediziert sind und die Netzwerkschnittstelle des Gateway mit einer SDA Service VM oder einem weiteren Gateway verbinden. Diese Server gewährleisten die erforderlichen Filterrichtlinien, sodass ausschließlich Punkt-zu-Punkt-Verbindungen möglich sind – etwa von IDEaaS zu einer bestimmten SPS und nicht zu anderen, unerwünschten Geräten im selben Netzwerk wie das Gateway. Zudem authentifizieren sie den Zugriff der Gateways auf Grundlage einer Richtlinie zur Rotation der Zugangsdaten für jede Verbindung.

Service VMs: Führen die Anwendungen aus, die von SDA-Diensten benötigt werden, etwa IDEaaS, Backup- und Deployment-Pipelines. Diese VMs greifen über den Connectivity Service auf der Netzwerkebene per IP-Adresse auf Devices zu – was für industrielle Anwendungen unerlässlich ist.

Cloud

Statt klassischer statischer VPNs baut der SDA Connectivity Service Verbindungen zu industriellen Assets bedarfsgesteuert auf. Die Anfragen werden an eine Kette von Nodes weitergeleitet, die gemeinsam den Punkt-zu-Punkt-Netzwerkzugriff zwischen SDA-Diensten und Devices herstellen.

Für das Fertigungsnetz gilt: Alle Verbindungen werden vom Gateway aus initiiert, sodass in der Fabrik keine Regeln für eingehende Verbindungen erforderlich sind. Dazu lauschen die Nodes fortlaufend an einem IoT-Message-Broker auf eingehende Anfragen; dieser basiert auf AWS IoT Core.

Diese Architektur ermöglicht es Benutzern, von jedem Ort mit Internetzugang und von jedem Computer aus – allein über den Browser – mit Assets in der Fabrik zu arbeiten.

Netzwerk

Das Gateway ist ein Edge-Gerät zwischen der Steuerungsebene der Fertigung und dem Internet, das den SDA-Diensten kontrollierten Zugriff auf die in der Console definierten Assets ermöglicht. Daher ist es besonders wichtig, eine Architektur zu etablieren, die die SDA Cloud sicher mit der lokalen Infrastruktur verbindet. Wir empfehlen eine der beiden folgenden Varianten für das Gateway.

Gateway im LAN

Dies ist der gängigste Ansatz: Das Gateway wird direkt neben den SPSen platziert, die in die SDA-Plattform eingebunden sind. Eine Firewall kontrolliert dabei streng den ausgehenden Verkehr vom Gateway ins Internet.

Das Gateway hat Zugriff auf das Subnetz, in dem es sich befindet; im Router des Netzwerks kann jedoch eine Firewall als Access Control Layer (ACL) eingerichtet sein. Üblich ist auch der Einsatz eines Gateway-Geräts mit zwei Netzwerkschnittstellen: eine zur DMZ und eine private in der Steuerungsebene. Diese Architektur erlaubt sich wiederholende IP-Bereiche, z. B. beidseitig das Subnetz 10.0.0.0/24.

Gateway in der DMZ

Dieser Ansatz kommt häufig zum Einsatz, wenn das Gateway auf einer dedizierten virtuellen Maschine irgendwo in der Serverinfrastruktur betrieben wird. Das IT-Team richtet dabei spezielle Routen zwischen der VM und den Ziel-SPSen in der Steuerungsebene ein; sowohl zum Internet als auch zur OT hin existieren vermutlich Firewalls.

gefahr

In Richtung der SPSen kann zusätzlich eine Network Address Translation (NAT) vorhanden sein. Das erfordert jedoch Aufmerksamkeit: Manche herstellerspezifische SPS-Software kommt mit der Adressierung der SPS über einen IP-Alias nicht zurecht und benötigt möglicherweise den Zugriff auf genau die IP-Adresse, die im Projekt konfiguriert ist.

In diesem Fall muss jede SPS in der Fertigungseinheit eine eindeutige IP-Adresse besitzen, andernfalls kann es zu Kollisionen kommen. Je nach Netzwerkinfrastruktur funktioniert zudem der Layer-2-Zugriff von Gateways auf SPSen möglicherweise nicht – hierfür ist die Integration echtzeitfähiger Industrienetzwerke in die SDA-Dienste als künftige Funktion vorgesehen.

Software

SDA Glue ist eine Anwendung, die als Betriebssystemdienst läuft und durch automatischen Start sowie Neustart im Fehlerfall die hohe Verfügbarkeit des Gateway sicherstellt. Um Netzwerktunnel aufzubauen und dabei Netzwerkressourcen wie Schnittstellen, Routen und Firewall-Regeln zu verwalten, benötigt der Dienst erhöhte Rechte als Systembenutzer.

Automatische 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 mehr bestehen. Der Aktualisierungsmechanismus lädt die neue Anwendungsbinärdatei herunter, ersetzt die alte und startet den Dienst neu.

AWS IoT Core wird beim Login über den Endpunkt iot.eu1.sdaconsole.io verbunden. Nach dem Verbindungsaufbau lauscht der Glue-Dienst fortlaufend auf Anfragen aus der SDA Cloud und veröffentlicht Telemetriedaten, etwa den Status der dem Gateway zugeordneten Devices. Die IoT-Authentifizierung ist durch eine kurze ID und ein Einmalpasswort geschützt, die in der SDA Console abgerufen werden können. Zusätzlich ist die Verbindung zu IoT durch einen geheimen Schlüssel in der Anwendungsbinärdatei abgesichert. Die IoT-Verbindung kann wahlweise über MQTT SSL oder WebSocket Secure hergestellt werden, jeweils über Port 443.

Die Netzwerkmechanismen unterscheiden sich zwischen Linux und Windows und werden daher getrennt beschrieben.

Linux

SDA Glue unter Linux nutzt den SoftEther VPN Client, der quelloffen ist (Apache License 2.0) und während der Glue-Installation aus dem SDA-Mirror unter repository.eu1.sdaconsole.io installiert wird.

Für jede Verbindung erstellt Glue über den SoftEther-Client eine NIC-Netzwerkschnittstelle und verbindet diese mit dem Tenant Server. Anschließend weist Glue der Schnittstelle mithilfe der Linux-IP-Werkzeuge eine IP-Adresse zu und legt die erforderlichen Routen zwischen der Service VM und dem Ziel-Device an.

Interne Firewall-Regeln und die NAT-Übersetzung werden in iptables angelegt. Diese lassen keine eingehenden Netzwerkpakete zum Gateway zu, sondern ausschließlich die Weiterleitung von Paketen an das Ziel-Device.

📚 Verwaltung von Linux-Ressourcen bei Verbindungen

Um zu verstehen, wie das Linux-Gateway Cloud-Dienste mit Geräten in der Fabrik verbindet, gehen wir ein konkretes Beispiel mit konkreten IP-Adressen durch, das den vollständigen Ablauf veranschaulicht.

Betrachten wir ein Fabriknetz, in dem ein Ziel-Device (etwa eine SPS) die lokale IP-Adresse 10.0.0.5 besitzt und das Gateway im selben Netzwerk unter 10.0.0.2 erreichbar ist. In der SDA Cloud muss sich eine Service VM mit diesem Device verbinden; ihr wird die VPN-IP 100.112.20.3 zugewiesen, während die VPN-Schnittstelle des Gateway 100.112.10.6 erhält.

Aufbau des Tunnels

Trifft eine Verbindungsanfrage ein, 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 so 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

Zu diesem Zeitpunkt besteht der Tunnel zwar, doch die Pakete wissen noch nicht, wohin sie geleitet werden sollen. Das Gateway muss dem System nun beibringen, wie der Datenverkehr zwischen diesen beiden Welten zu routen ist.

Anlegen der Routen

Das Gateway fügt eine Routing-Regel hinzu, die die Verbindung zwischen dem VPN-Netz 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 Device zurück in die Cloud senden soll.

Routing allein genügt jedoch nicht. Die Firewall des Gateway würde diesen Datenverkehr standardmäßig weiterhin blockieren. Damit die Verbindung zustande kommt, muss das Gateway die bidirektionale Paketweiterleitung zwischen VM und Device ausdrücklich zulassen:

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 wieder zurück fließen können, während die Sicherheitslage des Gateway für sämtlichen übrigen Datenverkehr erhalten bleibt. Beachten Sie außerdem, dass Glue eigene Ketten 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 kennt das Cloud-Netz unter 100.112.20.3 nicht 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 von der Service VM eintreffenden Paket, das für das Device bestimmt ist, die Quelladresse von 100.112.20.3 auf 10.0.0.2 um. Aus Sicht des Device kommuniziert es damit scheinbar direkt mit dem Gateway selbst – einer vertrauten Adresse in seinem lokalen Netzwerk. Sendet das Device seine Antwort an 10.0.0.2, nimmt das Gateway die umgekehrte Übersetzung vor und ändert die Zieladresse zurück auf 100.112.20.3, sodass das Paket über den VPN-Tunnel die Service VM erreicht.

Durch dieses Zusammenspiel aus VPN-Tunneling, Routing, Firewall-Regeln und NAT-Übersetzung schafft das Gateway eine transparente Punkt-zu-Punkt-Verbindung. Das Device sieht die Cloud-Infrastruktur zu keinem Zeitpunkt – es kommuniziert scheinbar lediglich mit dem Gateway in seinem lokalen Netzwerk unter 10.0.0.2. Die Service VM wiederum erhält direkten Zugriff auf der Netzwerkebene auf das Device über dessen IP-Adresse 10.0.0.5, sodass industrielle Anwendungen wie TIA Portal oder Studio 5000 so arbeiten können, als liefen sie unmittelbar im lokalen Fabriknetz.

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 SDA-Mirror unter repository.eu1.sdaconsole.io installiert wird.

Für jede Verbindung erstellt Glue über den OpenVPN-TAP-Treiber eine Netzwerkschnittstelle und verbindet diese mittels zertifikatsbasierter Authentifizierung mit dem Tenant Server. Über die native Windows-API weist Glue der Schnittstelle eine IP-Adresse zu und legt die erforderlichen Routen zwischen der Service VM und dem Ziel-Device an.

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

Workstation vs. Gateway: Workstations und Gateways nutzen den identischen Windows-Client und denselben oben beschriebenen Verbindungsaufbau – denselben OpenVPN-TAP-Treiber und dieselbe WinNAT-basierte Adressierung der Schnittstelle. Der einzige Unterschied liegt in der WFP-Firewall-Regel, die je Verbindung durch die Backend-Richtlinie vergeben wird: Die Verbindung einer Workstation erhält stets eine ausschließlich ausgehende Regel, die auf die IP des jeweiligen Zielgeräts über die SDA-Tunnelschnittstelle begrenzt ist, während ein Gateway zusätzlich eine Weiterleitungsregel erhalten kann, um Datenverkehr an dahinterliegende Geräte weiterzureichen. Eine Workstation öffnet somit niemals eingehende oder weiterleitende Pfade auf dem Host; ebenso wenig sind andere Netzwerkschnittstellen, Routen oder bestehende VPN-Verbindungen auf diesem PC betroffen – alle Änderungen bleiben auf die virtuelle Schnittstelle beschränkt, die SDA Glue für den eigenen Tunnel anlegt.

Zusammenfassung

Der SDA 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 Unternehmensniveau aus AWS IoT Core liefert der Dienst die Zuverlässigkeit und Sicherheit, die industrielle Abläufe erfordern, und bietet zugleich die Flexibilität und Benutzerfreundlichkeit, die moderne Engineering-Teams erwarten.

Die Architektur des Dienstes respektiert industrielle Sicherheitsprinzipien und ermöglicht zugleich jene Initiativen der digitalen Transformation, die betriebliche Effizienz, ortsunabhängige Zusammenarbeit und datengestützte Entscheidungen vorantreiben. Für Organisationen, die ihre industriellen Assets sicher mit Cloud-Diensten verbinden möchten, ohne Abstriche bei Netzwerksicherheit oder Betriebszuverlässigkeit zu machen, bietet der SDA Connectivity Service eine umfassende, produktionsreife Lösung.