SEW Connectivity Service

Översikt

SEW Connectivity Service bygger på SDA Glue, applikationen för gateways, tillgänglig för Linux- och Windows-värdar. Tjänsten drivs av SoftEther VPN, som stöder OpenVPN på Windows-klienter och upprättar en säker TCP-tunnel mellan ett nätverksgränssnitt i gatewayen och SEW:s molntjänster, såsom IDEaaS, Backup och Deployment-VM:ar. Den kombinerar även operativsystemets inbyggda brandväggar, Linux iptables och Windows Filtering Platform (WFP), med en NAT-tabell för att koppla leverantörsspecifik programvara, såsom Siemens TIA Portal och Rockwell Studio 500, direkt till enheten i tillverkningens styrskikt.

Nyckelpunkter

Hanteringen av industriella tillgångar med SEW drivs av en omfattande och säker industriell anslutningslösning som överbryggar klyftan mellan tillverkningsmiljöer och molnbaserade tjänster. Genom att utnyttja beprövad teknik och implementera robusta säkerhetsåtgärder levererar tjänsten anslutning på företagsnivå, skräddarsydd specifikt för industriell automation och styrsystem.

Säkerhet på industriell nivå: Integrationen med AWS IoT Core ger säkra TLS-anslutningar med finkorniga åtkomstpolicyer. Detta följer bästa praxis för säkerhet inom industriell IoT och gör det möjligt för administratörer att begränsa åtkomsten baserat på enhetsegenskaper och kontext.

Beprövad VPN-grund: Tjänsten använder SoftEther VPN, som erbjuder AES 256-bitars och RSA 4096-bitars kryptering med hög genomströmningsprestanda och låg minnes- och CPU-användning. Detta säkerställer att data under överföring förblir skyddade mot avlyssning och obehörig åtkomst, vilket är idealiskt för industriella tillämpningar där säkerhet och prestanda är kritiska.

Zero-Trust-nätverksåtkomst: Tjänsten eliminerar behovet av traditionella statiska VPN genom att upprätta anslutningar på begäran. Denna punkt-till-punkt-arkitektur säkerställer att användare endast kan komma åt specifikt godkända enheter, inte hela nätverkssegment, vilket avsevärt minskar attackytan.

Fabriksvänlig design: Alla anslutningar initieras utåt av noden själv — en Gateway eller en arbetsstation — och accepteras aldrig inkommande, vilket innebär att inga inkommande brandväggsregler någonsin krävs. Denna design respekterar befintliga industriella säkerhetsarkitekturer samtidigt som den erbjuder säker fjärråtkomst.

Arkitektur

Deltagarna i ett virtuellt nätverk kallas noder och är huvudkomponenterna i Connectivity Service. Varje anslutning byggs upp av interaktionen mellan en kedja av noder, där varje nod har en specifik roll.

Enheter: industriella tillgångar som vanligtvis finns i tillverkningens säkra nätverk och som kan nås via sin IP-adress, t.ex. PLC:er, HMI:er och robotar. Enheter deklareras i SEW Console för varje Tenant och användaråtkomst hanteras via rollbaserad åtkomstkontroll. Anslutning kräver att varje enhet är kopplad till minst en nätverksgateway.

Gateways: nätverksvärdar med säker åtkomst till Internet och till de enheter som hanteras i SEW Console. De är vanligtvis IPC:er, VM:ar, containrar och till och med Raspberry Pi-enheter, placerade i en brandväggszon som kräver specifika regler för att komma åt SEW-molnresurser, såsom Tenant Servers. Varje Gateway kör SDA Glue, som är en OS-tjänst som lyssnar efter anslutningsförfrågningar och tillhandahåller telemetridata.

Arbetsstationer: En kunds egen PC, som används för att komma åt enheter via en Gateway på målplatsen. En arbetsstation kör samma SDA Glue-programvara som en Gateway och konfigureras identiskt på nätverksnivå; den enda skillnaden är rollen — en arbetsstation initierar alltid utåt mot en Gateway och vidarebefordrar aldrig trafik till andra enheter.

Tenant Servers: bastionvärdar som körs i en säker SEW-molnmiljö, dedikerade för varje Tenant, som kopplar gatewayens nätverksgränssnitt till en SEW Service VM eller till en annan Gateway. Dessa servrar garanterar de nödvändiga filtreringspolicyerna för att säkerställa endast punkt-till-punkt-anslutning, t.ex. från IDEaaS till en specifik PLC och inte till andra oönskade enheter i samma nätverk som gatewayen. De autentiserar även åtkomsten från gateways baserat på en policy för rotation av inloggningsuppgifter vid varje anslutning.

Service VMs: kör de applikationer som behövs av SEW-tjänster, såsom IDEaaS, Backup och Deployment Pipelines. Dessa VM:ar förlitar sig på Connectivity Service för att komma åt enheter på nätverksnivå, via deras IP-adress, vilket är avgörande för industriella tillämpningar.

Moln

I stället för att använda traditionella statiska VPN upprättar SEW Connectivity Service anslutningar till industriella tillgångar på begäran. Förfrågningarna vidarebefordras till en kedja av noder som samverkar för att tillhandahålla punkt-till-punkt-nätverksåtkomst mellan SEW-tjänster och enheter.

För tillverkningsnätverket initieras alla anslutningar från gatewayen, vilket inte kräver några regler för inkommande anslutningar i fabriken. För att uppnå detta lyssnar noderna kontinuerligt på en IoT-meddelandeförmedlare efter inkommande förfrågningar, vilken drivs av AWS IoT Core.

Denna arkitektur gör det möjligt för användare att interagera med tillgångar i fabriken från vilken plats som helst med Internet, från vilken dator som helst, endast beroende av en webbläsare.

Nätverk

Gatewayen är en edge-enhet som placeras mellan ett tillverkningsstyrskikt och Internet, och som ger SEW-tjänster kontrollerad åtkomst till tillgångar som definierats i konsolen. Därför är det mycket viktigt att konsolidera en arkitektur som säkert kopplar SEW-molnet till den lokala infrastrukturen. Vi rekommenderar en av de två föreslagna konfigurationerna för gatewayen, enligt följande.

Gateway i LAN

Detta är den vanligaste metoden, där vi placerar gatewayen intill de PLC:er som ansluts till SEW-plattformen. Här styr en brandvägg strikt utgående trafik från gatewayen till Internet.

Gatewayen har åtkomst till det subnät där den är placerad, men en brandvägg kan tillhandahållas i nätverkets router som ett åtkomstkontrollskikt (ACL). Det är också vanligt att använda en gateway-enhet med två nätverksgränssnitt: ett som pekar mot DMZ och ett privat i styrskiktet. Denna arkitektur tillåter upprepade IP-zoner, t.ex. båda med subnätet 10.0.0.0/24.

Gateway i DMZ

Denna metod används ofta när gatewayen körs i en dedikerad virtuell maskin, någonstans i serverinfrastrukturen. IT-teamet tillhandahåller särskilda rutter mellan VM:en och mål-PLC:erna i styrskiktet, och brandväggar existerar sannolikt både mot Internet och mot OT.

risk

En nätverksadressöversättning (NAT) kan också förekomma nedströms mot PLC:erna. Detta kräver dock uppmärksamhet: viss leverantörsspecifik PLC-programvara kan vara inkompatibel med att adressera PLC:n via ett IP-alias, då den kan kräva åtkomst till den IP-adress som uttryckligen är konfigurerad i projektet.

I detta fall måste varje PLC i tillverkningsenheten ha en unik IP-adress, annars kan kollisioner uppstå. Beroende på nätverksinfrastrukturen kan dessutom Layer 2-åtkomst från gateways till PLC inte fungera, vilket är en kommande funktion för integrationen av industriella realtidsnätverk i SEW-tjänsterna.

Programvara

SDA Glue är en applikation som körs som en OS-tjänst och säkerställer hög tillgänglighet för gatewayen med automatisk start och omstart vid fel. För att upprätta nätverkstunnlarna genom att hantera nätverksresurser som gränssnitt, rutter och brandväggsregler krävs upphöjda rättigheter som systemanvändare.

Automatiska uppdateringar är aktiverade som standard. Glue-tjänsten läser den senaste stabila versionen från repository.eu1.sdacosole.io och tillämpar uppdateringen när det inte finns några aktiva anslutningar. Uppdateringsmekanismen laddar ned den nya applikationsbinären, ersätter den gamla och startar om tjänsten.

AWS IoT Core ansluts vid inloggning, vilket använder slutpunkten iot.eu1.sdaconsole.io. När anslutningen är upprättad lyssnar Glue-tjänsten kontinuerligt efter förfrågningar från SEW-molnet och publicerar telemetridata, såsom status för de enheter som är associerade med gatewayen. IoT-autentiseringen skyddas av ett kort ID och ett engångslösenord som kan hämtas från SEW Console. Anslutningen till IoT skyddas även av en hemlig nyckel i applikationsbinären. Anslutningen till IoT kan konfigureras att upprättas via MQTT SSL eller WebSocket Secure, båda på port 443.

Nätverksmekanismerna skiljer sig mellan Linux och Windows. Därför beskrivs de separat.

Linux

SDA Glue på Linux förlitar sig på SoftEther VPN Client, som är öppen källkod (Apache License 2.0) och installeras från SEW:s spegel på repository.eu1.sdaconsole.io under Glue-installationen.

För varje anslutning använder Glue SoftEther-klienten för att skapa ett NIC-nätverksgränssnitt och ansluta det till Tenant Server. Den använder också Linux IP-verktyg för att tilldela en IP-adress till gränssnittet och skapa de nödvändiga rutterna mellan Service VM och målenheten.

Interna brandväggsregler och NAT-översättning skapas i iptables, vilket inte tillåter inkommande nätverkspaket till gatewayen, utan endast vidarebefordran av paket till målenheten.

📚 Hantering av Linux-resurser i anslutningar

För att förstå hur Linux-gatewayen kopplar molntjänster till fabriksenheter går vi igenom ett konkret exempel med specifika IP-adresser som illustrerar hela flödet.

Betrakta ett fabriksnätverk där en målenhet (såsom en PLC) har den lokala IP-adressen 10.0.0.5 och gatewayen finns i samma nätverk med IP 10.0.0.2. I SEW-molnet behöver en Service VM ansluta till denna enhet och tilldelas VPN-IP:n 100.112.20.3, medan gatewayens VPN-gränssnitt får 100.112.10.6.

Upprättande av tunneln

När en anslutningsförfrågan inkommer aktiveras både gatewayen och Service VM:en. Gatewayen skapar ett nytt virtuellt nätverksgränssnitt kallat vpn_iface och tilldelar det adressen 100.112.10.6. Samtidigt skapar Service VM:en i molnet sitt eget VPN-gränssnitt med IP:n 100.112.20.3. Båda slutpunkterna ansluter sedan till Tenant Server och upprättar en säker krypterad tunnel mellan sig.

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

Vid denna punkt finns tunneln, men paketen vet fortfarande inte vart de ska. Gatewayen behöver lära systemet hur trafik ska routas mellan dessa två världar.

Uppbyggnad av rutterna

Gatewayen lägger till en routingregel som skapar kopplingen mellan VPN-nätverket och fabriksgolvet:

ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface

Denna rutt ger systemet en avgörande information: när enheten på 10.0.0.5 skickar svarspaket ska de vidarebefordras via vpn_iface för att nå Service VM:en på 100.112.20.3. Utan denna rutt skulle gatewayen inte veta hur enhetens svar ska skickas tillbaka till molnet.

Men routing i sig räcker inte. Gatewayens brandvägg skulle fortfarande blockera denna trafik som standard. För att möjliggöra anslutningen måste gatewayen uttryckligen tillåta tvåvägs paketvidarebefordran mellan VM:en och enheten:

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

Dessa regler öppnar en kontrollerad väg som tillåter paket att flöda från Service VM:en till enheten och tillbaka, samtidigt som gatewayens säkerhetsnivå bibehålls för all annan trafik. Observera även att Glue använder sina egna kedjor i iptables, för att inte orsaka konflikter med de övriga reglerna.

NAT-översättning

Enheten i fabriken förväntar sig att kommunicera med lokala IP-adresser — den har ingen kännedom om molnnätverket på 100.112.20.3 och skulle inte veta hur den ska svara på paket från den adressen. Gatewayen löser detta genom att maskera Service VM:ens paket:

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

Med denna NAT-regel på plats skriver gatewayen om källadressen från 100.112.20.3 till 10.0.0.2 när ett paket anländer från Service VM:en med enheten som destination. Ur enhetens perspektiv verkar den kommunicera direkt med gatewayen själv — en bekant, betrodd adress i det lokala nätverket. När enheten skickar sitt svar till 10.0.0.2 utför gatewayen den omvända översättningen och ändrar destinationsadressen tillbaka till 100.112.20.3 så att paketet når Service VM:en genom VPN-tunneln.

Genom denna orkestrering av VPN-tunnling, routing, brandväggsregler och NAT-översättning skapar gatewayen en transparent punkt-till-punkt-anslutning. Enheten ser aldrig molninfrastrukturen — den kommunicerar helt enkelt med vad som framstår som gatewayen i det lokala nätverket på 10.0.0.2. Samtidigt får Service VM:en direkt åtkomst på nätverksnivå till enheten via dess IP-adress 10.0.0.5, vilket gör det möjligt för industriella applikationer som TIA Portal eller Studio 5000 att fungera som om de kördes i det lokala fabriksnätverket.

Windows

SDA Glue på Windows stöder inte inbäddad användning av SoftEther VPN Client och använder därför OpenVPN Community Open-Source Client (GPL-licens version 2), installerad från SEW:s spegel på repository.eu1.sdaconsole.io under Glue-installationen.

För varje anslutning använder Glue OpenVPN:s TAP-drivrutin för att skapa ett nätverksgränssnitt och ansluta det till Tenant Server med certifikatbaserad autentisering. Den använder Windows inbyggda API för att tilldela en IP till gränssnittet och skapa de nödvändiga rutterna mellan Service VM och målenheten.

Glue använder även Windows Filtering Platform (WFP) för att skapa dedikerade lager och brandväggsregler. Den är dock beroende av WinNAT eller NetNat för att deklarera adressöversättningen mellan Service VM och enheten, vilket kanske inte är aktiverat som standard.

Arbetsstation kontra Gateway: Arbetsstationer och gateways använder den identiska Windows-klienten och anslutningskonfigurationen som beskrivs ovan — samma OpenVPN TAP-drivrutin, samma WinNAT-baserade gränssnittsadressering. Den enda skillnaden är den WFP-brandväggsregel som tilldelas per anslutning av backend-policyn: en arbetsstations anslutning får alltid en regel som endast tillåter utgående trafik och som är begränsad till den specifika målenhetens IP via SEW-tunnelgränssnittet, medan en Gateway dessutom kan få en vidarebefordringsregel för att koppla trafik vidare till enheter bakom den. En arbetsstation öppnar därför aldrig inkommande eller vidarebefordrande vägar på värden, och inget annat nätverksgränssnitt, ingen rutt eller befintlig VPN-anslutning på den datorn påverkas — alla ändringar är begränsade till det virtuella gränssnitt som SDA Glue skapar för sin egen tunnel.

Sammanfattning

SEW Connectivity Service levererar en mogen, säker och skalbar lösning för utmaningar inom industriell anslutning. Genom att kombinera beprövad teknik med öppen källkod som SoftEther VPN med molninfrastruktur på företagsnivå från AWS IoT Core erbjuder tjänsten den tillförlitlighet och säkerhet som industriell drift kräver, samtidigt som den ger den flexibilitet och användarvänlighet som moderna ingenjörsteam förväntar sig.

Tjänstens arkitektur respekterar industriella säkerhetsprinciper samtidigt som den möjliggör de digitala transformationsinitiativ som driver operativ effektivitet, fjärrsamarbete och datadrivet beslutsfattande. För organisationer som vill ansluta sina industriella tillgångar säkert till molntjänster utan att kompromissa med nätverkssäkerhet eller driftsäkerhet erbjuder SEW Connectivity Service en omfattande, produktionsklar lösning.