SDA Connectivity Service

Översikt

SDA 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 Gateway:en och SDA: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, som Siemens TIA Portal och Rockwell Studio 500, direkt till enheten i tillverkningens styrlager.

Nyckelpunkter

Hantering av industriella tillgångar med SDA drivs av en heltäckande 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 av företagsklass, skräddarsydd specifikt för industriell automation och styrsystem.

Säkerhet av industriklass: Integrationen med AWS IoT Core ger säkra TLS-anslutningar med finkorniga åtkomstpolicyer. Detta följer bästa praxis för industriell IoT-säkerhet och gör det möjligt för administratörer att begränsa åtkomst 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, vilket säkerställer att data under överföring förblir skyddad mot avlyssning och obehörig åtkomst – 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 vid behov. Denna punkt-till-punkt-arkitektur säkerställer att användare endast kan komma åt specifikt auktoriserade enheter, inte hela nätverkssegment, vilket avsevärt minskar angreppsytan.

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

Arkitektur

Motparterna i ett virtuellt nätverk kallas noder och utgör huvudkomponenterna i Connectivity Service. Varje anslutning byggs upp av samspelet mellan en kedja av noder, där var och en har en specifik roll.

Devices: industriella tillgångar som vanligtvis finns i det säkra tillverkningsnätverket och som kan nås via sin IP-adress, t.ex. PLC:er, HMI:er och robotar. Enheter deklareras i SDA Console för varje Tenant och användaråtkomst hanteras genom rollbaserad åtkomstkontroll. Anslutning kräver att varje Device är kopplad till minst en nätverks-Gateway.

Gateways: nätverksvärdar med säker åtkomst till internet och till de Devices som hanteras i SDA 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 nå SDA Cloud-resurser, 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.

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

Tenant Servers: bastionvärdar som körs i en säker SDA Cloud-miljö, dedikerade för varje Tenant, som överbryggar Gateway:ens nätverksgränssnitt med en SDA Service VM eller med en annan Gateway. Dessa servrar garanterar de nödvändiga filtreringspolicyerna för att säkerställa endast punkt-till-punkt-anslutning, som från IDEaaS till en specifik PLC och inte till andra oönskade enheter i samma nätverk som Gateway:en. 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 SDA-tjänster, såsom IDEaaS, Backup och Deployment Pipelines. Dessa VM:ar förlitar sig på Connectivity Service för att nå Devices på nätverkslagret, 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 SDA Connectivity Service anslutningar till industriella tillgångar på begäran, där förfrågningarna vidarebefordras till en kedja av noder som samverkar för att tillhandahålla punkt-till-punkt-nätverksåtkomst mellan SDA-tjänster och Devices.

För tillverkningsnätverket initieras alla anslutningar från Gateway:en, 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, med enbart en webbläsare.

Nätverk

Gateway:en är en edge-enhet som sitter mellan ett tillverkningsstyrlager och internet, och som ger SDA-tjänster kontrollerad åtkomst till tillgångar definierade i Console. Därför är det mycket viktigt att befästa en arkitektur som säkert överbryggar SDA Cloud med den lokala infrastrukturen. Vi rekommenderar en av de två föreslagna konfigurationerna för Gateway:en, enligt nedan.

Gateway i LAN

Detta är det vanligaste tillvägagångssättet, där vi placerar Gateway:en bredvid de PLC:er som ansluts till SDA-plattformen. Här kontrollerar en brandvägg strikt utgående trafik från Gateway:en till internet.

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

Gateway i DMZ

Detta tillvägagångssätt används ofta när Gateway:en 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 styrlagret, och brandväggar finns sannolikt både för åtkomst till internet och till OT.

risk

En Network Address Translation (NAT) kan också finnas när trafiken går nedströms till PLC:erna. Detta kräver dock uppmärksamhet: viss leverantörsspecifik PLC-programvara kanske inte är kompatibel med att adressera PLC:n via ett IP-alias, utan kan kräva åtkomst till den IP som är explicit 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 kanske dessutom Layer 2-åtkomst från Gateways till PLC inte fungerar, vilket är en kommande funktion för integrationen av realtidsindustrinätverk i SDA-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 Gateway:en med automatisk uppstart och omstart vid fel. För att kunna upprätta nätverkstunnlar genom att hantera nätverksresurser som gränssnitt, rutter och brandväggsregler krävs förhö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 ner 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 SDA Cloud och publicerar telemetridata, såsom statusen för de Devices som är associerade med Gateway:en. IoT-autentiseringen skyddas av ett kort ID och ett engångslösenord som kan hämtas från SDA Console. Anslutningen till IoT säkras ä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 åt 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), installerad från SDA:s spegel på repository.eu1.sdaconsole.io under Glue-installationen.

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

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

📚 Hantering av Linux-resurser i anslutningar

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

Tänk dig ett fabriksnätverk där en mål-Device (till exempel en PLC) har den lokala IP-adressen 10.0.0.5 och Gateway:en finns i samma nätverk med IP 10.0.0.2. I SDA Cloud behöver en Service VM ansluta till denna Device och tilldelas VPN-IP:n 100.112.20.3, medan Gateway:ens VPN-gränssnitt får 100.112.10.6.

Upprätta tunneln

När en anslutningsförfrågan anländer träder både Gateway:en och Service VM:en i aktion. Gateway:en 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. Gateway:en måste lära systemet hur trafik ska dirigeras mellan dessa två världar.

Bygga rutterna

Gateway:en lägger till en dirigeringsregel 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 förmedlar en avgörande information till systemet: när Device:n på 10.0.0.5 skickar svarspaket ska de vidarebefordras genom vpn_iface för att nå Service VM på 100.112.20.3. Utan denna rutt skulle Gateway:en inte veta hur Device:ns svar ska skickas tillbaka till molnet.

Men dirigering ensam räcker inte. Gateway:ens brandvägg skulle fortfarande blockera denna trafik som standard. För att möjliggöra anslutningen måste Gateway:en explicit tillåta dubbelriktad paketvidarebefordran mellan VM:en och Device:n:

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 låter paket flöda från Service VM till Device:n och tillbaka igen, samtidigt som Gateway:ens säkerhetsnivå upprätthålls för all annan trafik. Observera också att Glue använder sina egna kedjor i iptables, för att inte orsaka konflikter med övriga regler.

NAT-översättning

Device:n i fabriken förväntar sig att kommunicera med lokala IP-adresser — den känner inte till molnnätverket på 100.112.20.3 och skulle inte veta hur den ska svara på paket från den adressen. Gateway:en 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 Gateway:en om källadressen från 100.112.20.3 till 10.0.0.2 när ett paket anländer från Service VM med Device:n som destination. Ur Device:ns perspektiv verkar den kommunicera direkt med själva Gateway:en — en välbekant, betrodd adress i dess lokala nätverk. När Device:n skickar sitt svar till 10.0.0.2 utför Gateway:en den omvända översättningen och ändrar destinationsadressen tillbaka till 100.112.20.3 så att paketet når Service VM genom VPN-tunneln.

Genom detta samspel av VPN-tunnling, dirigering, brandväggsregler och NAT-översättning skapar Gateway:en en transparent punkt-till-punkt-anslutning. Device:n ser aldrig molninfrastrukturen — den kommunicerar helt enkelt med det som framstår som Gateway:en i dess lokala nätverk på 10.0.0.2. Samtidigt får Service VM direkt åtkomst på nätverkslagret till Device:n 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 självt.

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 SDA:s spegel på repository.eu1.sdaconsole.io under Glue-installationen.

För varje anslutning använder Glue OpenVPN TAP-drivrutinen 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ål-Device.

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 Device, vilket kanske inte är aktiverat som standard.

Workstation kontra Gateway: Workstations och Gateways använder den identiska Windows-klient och anslutningskonfiguration 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-policy: en Workstations anslutning får alltid en regel enbart för utgående trafik, avgränsad till den specifika målenhetens IP över SDA-tunnelgränssnittet, medan en Gateway dessutom kan få en vidarebefordringsregel för att slussa trafik vidare till enheter bakom den. En Workstation öppnar därför aldrig inkommande eller vidarebefordrande vägar på värden, och inget annat nätverksgränssnitt, rutt eller befintlig VPN-anslutning på den datorn påverkas — alla ändringar begränsas till det virtuella gränssnitt som SDA Glue skapar för sin egen tunnel.

Sammanfattning

SDA Connectivity Service levererar en mogen, säker och skalbar lösning på industriella anslutningsutmaningar. Genom att kombinera beprövad teknik med öppen källkod som SoftEther VPN med molninfrastruktur av företagsklass från AWS IoT Core ger tjänsten den tillförlitlighet och säkerhet som industriell verksamhet kräver, samtidigt som den erbjuder 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 SDA Connectivity Service en heltäckande, produktionsklar lösning.