SDA Connectivity Service

Przegląd

SDA Connectivity Service opiera się na SDA Glue — aplikacji dla Gateway'ów, dostępnej dla hostów Linux i Windows. Usługa wykorzystuje SoftEther VPN, który obsługuje OpenVPN na klientach Windows, ustanawiając bezpieczny tunel TCP między interfejsem sieciowym w Gateway'u a usługami chmurowymi SDA, takimi jak IDEaaS, Backup oraz maszyny wirtualne wdrożeniowe. Łączy również natywne zapory systemów operacyjnych, Linux iptables oraz Windows Filtering Platform (WFP), z tablicą NAT, aby połączyć oprogramowanie specyficzne dla producentów, takie jak Siemens TIA Portal i Rockwell Studio 500, bezpośrednio z urządzeniem w warstwie sterowania produkcją.

Kluczowe informacje

Zarządzanie zasobami przemysłowymi za pomocą SDA opiera się na kompleksowym i bezpiecznym rozwiązaniu łączności przemysłowej, które wypełnia lukę między środowiskami produkcyjnymi a usługami chmurowymi. Wykorzystując sprawdzone technologie i wdrażając solidne mechanizmy bezpieczeństwa, usługa zapewnia łączność klasy korporacyjnej, dostosowaną specjalnie do systemów automatyki i sterowania przemysłowego.

Bezpieczeństwo klasy przemysłowej: Integracja z AWS IoT Core zapewnia bezpieczne połączenia TLS z precyzyjnymi zasadami kontroli dostępu. Podejście to jest zgodne z najlepszymi praktykami bezpieczeństwa przemysłowego IoT, pozwalając administratorom ograniczać dostęp na podstawie właściwości urządzenia i kontekstu.

Sprawdzona podstawa VPN: Usługa korzysta z SoftEther VPN, który zapewnia szyfrowanie AES 256-bit i RSA 4096-bit przy wysokiej przepustowości oraz niskim zużyciu pamięci i CPU, gwarantując, że dane w tranzycie pozostają zabezpieczone przed podsłuchem i nieuprawnionym dostępem — idealne dla zastosowań przemysłowych, w których bezpieczeństwo i wydajność są krytyczne.

Dostęp sieciowy w modelu zero-trust: Usługa eliminuje potrzebę stosowania tradycyjnych, statycznych połączeń VPN, ustanawiając połączenia na żądanie. Ta architektura Point-to-Point zapewnia, że użytkownicy mogą uzyskać dostęp wyłącznie do wyraźnie autoryzowanych urządzeń, a nie do całych segmentów sieci, co znacząco zmniejsza powierzchnię ataku.

Projekt przyjazny dla fabryki: Wszystkie połączenia są inicjowane na zewnątrz przez sam węzeł — Gateway lub Workstation — i nigdy nie są przyjmowane jako połączenia wejściowe, dzięki czemu nigdy nie są wymagane reguły zapory dla ruchu wejściowego. Taki projekt respektuje istniejące architektury bezpieczeństwa przemysłowego, jednocześnie zapewniając możliwości bezpiecznego dostępu zdalnego.

Architektura

Uczestnicy sieci wirtualnej nazywani są węzłami (Nodes) i stanowią główne komponenty Connectivity Service. Każde połączenie jest budowane z interakcji łańcucha węzłów, z których każdy pełni określoną rolę.

Devices: zasoby przemysłowe zwykle znajdujące się w bezpiecznej sieci produkcyjnej, do których można uzyskać dostęp przez ich adres IP, np. PLC, panele HMI i roboty. Devices są deklarowane w SDA Console dla każdego Tenanta, a dostęp użytkowników jest zarządzany za pomocą kontroli dostępu opartej na rolach (Role-Based Access Control). Łączność wymaga, aby każde Device było powiązane z co najmniej jednym sieciowym Gateway'em.

Gateways: hosty sieciowe z bezpiecznym dostępem do Internetu oraz do urządzeń zarządzanych w SDA Console. Zwykle są to IPC, maszyny wirtualne, kontenery, a nawet Raspberry Pi, umieszczone w strefie zapory wymagającej określonych reguł dostępu do zasobów SDA Cloud, takich jak Tenant Servers. Każdy Gateway uruchamia SDA Glue, czyli usługę systemu operacyjnego nasłuchującą żądań połączeń i dostarczającą dane telemetryczne.

Workstations: własny komputer klienta, używany do dostępu do urządzeń poprzez Gateway w docelowej lokalizacji. Workstation uruchamia to samo oprogramowanie SDA Glue co Gateway i jest konfigurowana identycznie na poziomie sieci; jedyną różnicą jest rola — Workstation zawsze inicjuje połączenie na zewnątrz w kierunku Gateway'a i nigdy nie przekazuje ruchu dalej do innych urządzeń.

Tenant Servers: hosty bastionowe działające w bezpiecznym środowisku SDA Cloud, dedykowane dla każdego Tenanta, które łączą interfejs sieciowy Gateway'a z maszyną wirtualną usługi SDA lub z innym Gateway'em. Serwery te gwarantują wymagane polityki filtrowania, zapewniające wyłącznie połączenie Point-to-Point, np. z IDEaaS do konkretnego PLC, a nie do innych, niepożądanych urządzeń w tej samej sieci co Gateway. Uwierzytelniają one również dostęp z Gateway'ów na podstawie polityki rotacji danych uwierzytelniających dla każdego połączenia.

Service VMs: uruchamiają aplikacje potrzebne usługom SDA, takie jak IDEaaS, Backup i potoki wdrożeniowe. Te maszyny wirtualne wykorzystują Connectivity Service do dostępu do urządzeń w warstwie sieciowej, poprzez ich adres IP, co jest niezbędne dla zastosowań przemysłowych.

Chmura

Zamiast korzystać z tradycyjnych, statycznych połączeń VPN, SDA Connectivity Service ustanawia połączenia z zasobami przemysłowymi na żądanie; żądania te są przekazywane do łańcucha węzłów, które współpracują, zapewniając dostęp sieciowy Point-to-Point między usługami SDA a urządzeniami.

W przypadku sieci produkcyjnej wszystkie połączenia są inicjowane z Gateway'a, co nie wymaga żadnych reguł dla połączeń wejściowych w fabryce. Aby to osiągnąć, węzły nieustannie nasłuchują przychodzących żądań na brokerze wiadomości IoT, opartym na AWS IoT Core.

Architektura ta umożliwia użytkownikom interakcję z zasobami w fabryce z dowolnego miejsca z dostępem do Internetu, z dowolnego komputera, korzystając jedynie z przeglądarki.

Sieć

Gateway to urządzenie brzegowe znajdujące się między warstwą sterowania produkcją a Internetem, które zapewnia usługom SDA kontrolowany dostęp do zasobów zdefiniowanych w Console. Dlatego bardzo ważne jest ustalenie architektury, która bezpiecznie łączy SDA Cloud z lokalną infrastrukturą. Zalecamy jedną z dwóch proponowanych konfiguracji Gateway'a, opisanych poniżej.

Gateway w LAN

To najczęstsze podejście, w którym umieszczamy Gateway obok PLC podłączonych do platformy SDA. W tym przypadku zapora ściśle kontroluje ruch wychodzący z Gateway'a do Internetu.

Gateway ma dostęp do podsieci, w której się znajduje, jednak w routerze sieci można udostępnić zaporę jako warstwę kontroli dostępu (Access Control Layer, ACL). Powszechne jest również stosowanie urządzenia Gateway z dwoma interfejsami sieciowymi: jednym skierowanym do DMZ i prywatnym w warstwie sterowania. Architektura ta umożliwia powtarzające się strefy IP, np. obie z podsiecią 10.0.0.0/24.

Gateway w DMZ

Podejście to jest często stosowane, gdy Gateway działa na dedykowanej maszynie wirtualnej, gdzieś w infrastrukturze serwerowej. Zespół IT zapewni specjalne trasy między maszyną wirtualną a docelowymi PLC w warstwie sterowania, a zapory będą prawdopodobnie istnieć zarówno na dostępie do Internetu, jak i do OT.

ważne

Translacja adresów sieciowych (NAT) może również występować w kierunku PLC. Wymaga to jednak uwagi: niektóre oprogramowanie specyficzne dla producentów PLC może nie być zgodne z adresowaniem PLC przez alias IP — może wymagać dostępu do adresu IP jawnie skonfigurowanego w projekcie.

W tym przypadku każdy PLC w jednostce produkcyjnej musi mieć unikalny adres IP, w przeciwnym razie mogą wystąpić kolizje. Ponadto, w zależności od infrastruktury sieciowej, dostęp warstwy 2 z Gateway'ów do PLC może nie działać, co jest nadchodzącą funkcją związaną z integracją przemysłowych sieci czasu rzeczywistego w usługach SDA.

Oprogramowanie

SDA Glue to aplikacja działająca jako usługa systemu operacyjnego, zapewniająca wysoką dostępność Gateway'a dzięki automatycznemu uruchamianiu i restartowi w przypadku błędów. Aby ustanawiać tunele sieciowe poprzez zarządzanie zasobami sieciowymi, takimi jak interfejsy, trasy i reguły zapory, wymaga podwyższonych uprawnień jako użytkownik systemowy.

Automatyczne aktualizacje są domyślnie włączone. Usługa Glue odczyta najnowszą stabilną wersję z repository.eu1.sdacosole.io i zastosuje aktualizację, gdy nie będzie aktywnych połączeń. Mechanizm aktualizacji pobiera nowy plik binarny aplikacji, zastępuje nim stary i restartuje usługę.

AWS IoT Core zostanie połączony podczas logowania, przy użyciu punktu końcowego iot.eu1.sdaconsole.io. Po połączeniu usługa Glue będzie nieustannie nasłuchiwać żądań z SDA Cloud i publikować dane telemetryczne, takie jak status urządzeń powiązanych z Gateway'em. Uwierzytelnianie IoT jest chronione krótkim identyfikatorem i jednorazowym hasłem, które można uzyskać z SDA Console. Połączenie z IoT jest również zabezpieczone kluczem tajnym w pliku binarnym aplikacji. Połączenie z IoT można skonfigurować tak, aby było ustanawiane przez MQTT SSL lub WebSocket Secure, w obu przypadkach na porcie 443.

Mechanizmy sieciowe różnią się dla systemów Linux i Windows. Dlatego zostały opisane oddzielnie.

Linux

SDA Glue w systemie Linux korzysta z klienta SoftEther VPN Client, który jest oprogramowaniem open-source (Apache License 2.0), instalowanym z serwera lustrzanego SDA na repository.eu1.sdaconsole.io podczas instalacji Glue.

Dla każdego połączenia Glue używa klienta SoftEther do utworzenia interfejsu sieciowego NIC i połączenia go z Tenant Server. Wykorzystuje również narzędzia IP systemu Linux do przypisania adresu IP do tego interfejsu oraz utworzenia niezbędnych tras między Service VM a docelowym urządzeniem.

Wewnętrzne reguły zapory i translacja NAT są tworzone w iptables, co nie pozwala na przychodzące pakiety sieciowe do Gateway'a, a wyłącznie na przekazywanie pakietów do docelowego urządzenia.

📚 Zarządzanie zasobami Linux w połączeniach

Aby zrozumieć, jak Gateway w systemie Linux łączy usługi chmurowe z urządzeniami fabrycznymi, przejdźmy przez konkretny przykład z określonymi adresami IP, ilustrujący cały przepływ.

Rozważmy sieć fabryczną, w której docelowe urządzenie (np. PLC) ma lokalny adres IP 10.0.0.5, a Gateway znajduje się w tej samej sieci z adresem IP 10.0.0.2. W SDA Cloud maszyna Service VM musi połączyć się z tym urządzeniem i otrzyma adres VPN 100.112.20.3, natomiast interfejs VPN Gateway'a otrzyma 100.112.10.6.

Ustanawianie tunelu

Gdy nadejdzie żądanie połączenia, zarówno Gateway, jak i Service VM przystępują do działania. Gateway tworzy nowy wirtualny interfejs sieciowy o nazwie vpn_iface i przypisuje mu adres 100.112.10.6. Jednocześnie Service VM w chmurze tworzy własny interfejs VPN z adresem IP 100.112.20.3. Następnie oba punkty końcowe łączą się z Tenant Server, ustanawiając między sobą bezpieczny, szyfrowany tunel.

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

W tym momencie tunel istnieje, ale pakiety nadal nie wiedzą, gdzie mają być kierowane. Gateway musi nauczyć system, jak trasować ruch między tymi dwoma światami.

Budowanie tras

Gateway dodaje regułę trasowania, która tworzy połączenie między siecią VPN a halą produkcyjną:

ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface

Trasa ta przekazuje systemowi kluczową informację: gdy urządzenie o adresie 10.0.0.5 wysyła pakiety odpowiedzi, powinny one być przekazywane przez vpn_iface, aby dotarły do Service VM pod adresem 100.112.20.3. Bez tej trasy Gateway nie wiedziałby, jak odsyłać odpowiedzi urządzenia z powrotem do chmury.

Jednak samo trasowanie nie wystarczy. Zapora Gateway'a domyślnie nadal blokowałaby ten ruch. Aby umożliwić połączenie, Gateway musi jawnie zezwolić na dwukierunkowe przekazywanie pakietów między maszyną wirtualną a urządzeniem:

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

Reguły te otwierają kontrolowaną ścieżkę, pozwalając pakietom przepływać od Service VM do urządzenia i z powrotem, przy jednoczesnym zachowaniu poziomu bezpieczeństwa Gateway'a dla całego pozostałego ruchu. Warto też zauważyć, że Glue używa własnych łańcuchów w iptables, aby nie powodować konfliktów z innymi regułami.

Translacja NAT

Urządzenie w fabryce oczekuje komunikacji z lokalnymi adresami IP — nie ma wiedzy o sieci chmurowej pod adresem 100.112.20.3 i nie wiedziałoby, jak odpowiedzieć na pakiety z tego adresu. Gateway rozwiązuje ten problem, maskując pakiety Service VM:

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

Przy tej regule NAT, gdy nadejdzie pakiet z Service VM przeznaczony dla urządzenia, Gateway przepisuje jego adres źródłowy z 100.112.20.3 na 10.0.0.2. Z perspektywy urządzenia wygląda to tak, jakby komunikowało się bezpośrednio z samym Gateway'em — znanym, zaufanym adresem w jego sieci lokalnej. Gdy urządzenie wysyła odpowiedź na adres 10.0.0.2, Gateway wykonuje translację odwrotną, zmieniając adres docelowy z powrotem na 100.112.20.3, aby pakiet dotarł do Service VM przez tunel VPN.

Dzięki tej orkiestracji tunelowania VPN, trasowania, reguł zapory i translacji NAT Gateway tworzy przejrzyste połączenie punkt-punkt. Urządzenie nigdy nie widzi infrastruktury chmurowej — po prostu komunikuje się z czymś, co wydaje się być Gateway'em w jego sieci lokalnej pod adresem 10.0.0.2. Jednocześnie Service VM uzyskuje bezpośredni dostęp w warstwie sieciowej do urządzenia poprzez jego adres IP 10.0.0.5, umożliwiając aplikacjom przemysłowym, takim jak TIA Portal czy Studio 5000, działanie tak, jakby były uruchomione w lokalnej sieci fabrycznej.

Windows

SDA Glue w systemie Windows nie obsługuje wbudowanego użycia SoftEther VPN Client, dlatego korzysta z OpenVPN Community Open-Source Client (licencja GPL wersja 2), instalowanego z serwera lustrzanego SDA na repository.eu1.sdaconsole.io podczas instalacji Glue.

Dla każdego połączenia Glue używa sterownika OpenVPN TAP do utworzenia interfejsu sieciowego i połączenia go z Tenant Server przy użyciu uwierzytelniania opartego na certyfikatach. Wykorzystuje natywne API systemu Windows do przypisania adresu IP do interfejsu oraz utworzenia niezbędnych tras między Service VM a docelowym urządzeniem.

Glue używa również Windows Filtering Platform (WFP) do tworzenia dedykowanych warstw i reguł zapory. Zależy jednak od WinNAT lub NetNat, aby zadeklarować translację adresów między Service VM a urządzeniem, co może nie być domyślnie włączone.

Workstation a Gateway: Workstations i Gateways używają identycznego klienta Windows i opisanej powyżej konfiguracji połączenia — tego samego sterownika OpenVPN TAP i tego samego adresowania interfejsu opartego na WinNAT. Jedyną różnicą jest reguła zapory WFP przypisywana dla każdego połączenia przez politykę backendu: połączenie Workstation zawsze otrzymuje regułę wyłącznie dla ruchu wychodzącego, ograniczoną do konkretnego adresu IP urządzenia docelowego przez interfejs tunelu SDA, natomiast Gateway może dodatkowo otrzymać regułę przekazywania, aby przekazywać ruch dalej do urządzeń znajdujących się za nim. Workstation nigdy zatem nie otwiera ścieżek dla ruchu wejściowego ani przekazywanego na hoście, a żaden inny interfejs sieciowy, trasa czy istniejące połączenie VPN na tym komputerze nie jest modyfikowane — wszystkie zmiany są ograniczone do wirtualnego interfejsu, który SDA Glue tworzy dla własnego tunelu.

Podsumowanie

SDA Connectivity Service dostarcza dojrzałe, bezpieczne i skalowalne rozwiązanie wyzwań związanych z łącznością przemysłową. Łącząc sprawdzone technologie open-source, takie jak SoftEther VPN, z infrastrukturą chmurową klasy korporacyjnej AWS IoT Core, usługa zapewnia niezawodność i bezpieczeństwo wymagane przez operacje przemysłowe, oferując jednocześnie elastyczność i łatwość użycia, jakich oczekują nowoczesne zespoły inżynierskie.

Architektura usługi respektuje zasady bezpieczeństwa przemysłowego, jednocześnie umożliwiając inicjatywy transformacji cyfrowej, które napędzają efektywność operacyjną, zdalną współpracę i podejmowanie decyzji na podstawie danych. Dla organizacji poszukujących bezpiecznego połączenia swoich zasobów przemysłowych z usługami chmurowymi bez naruszania bezpieczeństwa sieci ani niezawodności operacyjnej, SDA Connectivity Service stanowi kompleksowe rozwiązanie gotowe do produkcyjnego zastosowania.