Service de connectivité SEW

Vue d'ensemble

Le service de connectivité SEW s'appuie sur SDA Glue, l'application destinée aux Gateways, disponible pour les hôtes Linux et Windows. Le service est propulsé par SoftEther VPN, qui prend en charge OpenVPN sur les clients Windows, établissant un tunnel TCP sécurisé entre une interface réseau de la Gateway et les services cloud SEW, tels que IDEaaS, les VM de sauvegarde et de déploiement. Il combine également les pare-feu natifs du système d'exploitation, iptables sous Linux et Windows Filtering Platform (WFP), avec une table NAT afin de relier directement les logiciels spécifiques aux fournisseurs, comme Siemens TIA Portal et Rockwell Studio 500, à l'appareil situé dans la couche de contrôle de production.

Points clés

La gestion des actifs industriels avec SEW repose sur une solution de connectivité industrielle complète et sécurisée qui comble l'écart entre les environnements de production et les services cloud. En s'appuyant sur des technologies éprouvées et en mettant en œuvre des mesures de sécurité robustes, le service offre une connectivité de niveau entreprise spécialement conçue pour les systèmes d'automatisation et de contrôle industriels.

Sécurité de niveau industriel : l'intégration avec AWS IoT Core fournit des connexions TLS sécurisées assorties de politiques de contrôle d'accès à granularité fine. Cette approche respecte les meilleures pratiques de sécurité de l'IoT industriel, permettant aux administrateurs de restreindre l'accès en fonction des propriétés et du contexte des appareils.

Une base VPN éprouvée : le service utilise SoftEther VPN, qui offre un chiffrement AES 256 bits et RSA 4096 bits avec un débit élevé et une faible consommation de mémoire et de CPU, garantissant que les données en transit restent protégées contre l'écoute clandestine et les accès non autorisés — idéal pour les applications industrielles où la sécurité et la performance sont critiques.

Accès réseau Zero-Trust : le service élimine le besoin de VPN statiques traditionnels en établissant les connexions à la demande. Cette architecture point à point garantit que les utilisateurs ne peuvent accéder qu'aux appareils spécifiquement autorisés, et non à des segments réseau entiers, réduisant considérablement la surface d'attaque.

Une conception adaptée à l'usine : toutes les connexions sont initiées vers l'extérieur par le nœud lui-même — une Gateway ou une Workstation — et jamais acceptées en entrée, de sorte qu'aucune règle de pare-feu entrante n'est requise. Cette conception respecte les architectures de sécurité industrielles existantes tout en offrant des capacités d'accès distant sécurisé.

Architecture

Les pairs d'un réseau virtuel sont appelés Nodes ; ils constituent les composants principaux du service de connectivité. Chaque connexion est construite à partir de l'interaction d'une chaîne de Nodes, chacun ayant un rôle spécifique.

Devices : actifs industriels généralement situés dans le réseau de production sécurisé, accessibles par leur adresse IP, p. ex. des PLC, des IHM et des robots. Les Devices sont déclarés dans la SEW Console pour chaque Tenant et l'accès des utilisateurs est géré par contrôle d'accès basé sur les rôles. La connectivité exige que chaque Device soit associé à au moins une Gateway réseau.

Gateways : hôtes réseau disposant d'un accès sécurisé à Internet et aux Devices gérés dans la SEW Console. Il s'agit généralement d'IPC, de VM, de conteneurs et même de Raspberry Pi, situés dans une zone de pare-feu nécessitant des règles spécifiques pour accéder aux ressources du SEW Cloud, comme les Tenant Servers. Chaque Gateway exécute SDA Glue, un service du système d'exploitation qui écoute les demandes de connexion et fournit des données de télémétrie.

Workstations : un PC appartenant au client, utilisé pour accéder aux appareils via une Gateway sur le site cible. Une Workstation exécute le même logiciel SDA Glue qu'une Gateway et est configurée de manière identique au niveau réseau ; la seule différence réside dans le rôle — une Workstation initie toujours la connexion vers l'extérieur en direction d'une Gateway et ne relaie jamais le trafic vers d'autres appareils.

Tenant Servers : hôtes bastion exécutés dans un environnement SEW Cloud sécurisé, dédiés à chaque Tenant, qui relient l'interface réseau de la Gateway à une VM de service SEW ou à une autre Gateway. Ces serveurs garantissent les politiques de filtrage nécessaires pour n'assurer qu'une connexion point à point, par exemple depuis IDEaaS vers un PLC spécifique et non vers d'autres appareils non souhaités présents sur le même réseau que la Gateway. Ils authentifient également l'accès depuis les Gateways sur la base d'une politique de rotation des identifiants pour chaque connexion.

Service VMs : exécutent les applications nécessaires aux services SEW, comme IDEaaS, les sauvegardes et les pipelines de déploiement. Ces VM s'appuient sur le service de connectivité pour accéder aux Devices au niveau de la couche réseau, par leur adresse IP, ce qui est essentiel pour les applications industrielles.

Cloud

Au lieu d'utiliser des VPN statiques traditionnels, le service de connectivité SEW établit les connexions vers les actifs industriels sur demande, ces demandes étant transmises à une chaîne de Nodes qui coopèrent pour fournir un accès réseau point à point entre les services SEW et les Devices.

Pour le réseau de production, toutes les connexions sont initiées depuis la Gateway, ce qui n'exige aucune règle de connexion entrante dans l'usine. Pour ce faire, les Nodes écoutent en permanence les demandes entrantes sur un courtier de messages IoT, propulsé par AWS IoT Core.

Cette architecture permet aux utilisateurs d'interagir avec les actifs de l'usine depuis n'importe quel endroit disposant d'un accès Internet, depuis n'importe quel ordinateur, en ne dépendant que d'un navigateur.

Réseau

La Gateway est un équipement edge situé entre une couche de contrôle de production et Internet, qui fournit aux services SEW un accès contrôlé aux actifs définis dans la Console. Il est donc très important de consolider une architecture qui relie de manière sécurisée le SEW Cloud à l'infrastructure locale. Nous recommandons l'une des deux configurations proposées ci-après pour la Gateway.

Gateway en LAN

C'est l'approche la plus courante, dans laquelle la Gateway est placée à proximité des PLC intégrés à la plateforme SEW. Ici, un pare-feu contrôle strictement les flux sortants de la Gateway vers Internet.

La Gateway a accès au sous-réseau dans lequel elle se trouve, mais un pare-feu peut être provisionné dans le routeur du réseau en tant que couche de contrôle d'accès (ACL). Il est également courant d'utiliser une Gateway dotée de deux interfaces réseau : l'une pointant vers la DMZ et une interface privée dans la couche de contrôle. Cette architecture autorise des zones IP répétées, p. ex. les deux avec le sous-réseau 10.0.0.0/24.

Gateway en DMZ

Cette approche est très utilisée lorsque les Gateways s'exécutent dans une machine virtuelle dédiée, quelque part dans l'infrastructure serveur. L'équipe informatique fournira des routes spécifiques entre la VM et les PLC cibles dans la couche de contrôle, et des pare-feu existeront probablement à la fois pour les accès à Internet et à l'OT.

danger

Une traduction d'adresses réseau (NAT) peut également exister en descendant vers les PLC. Cela requiert toutefois de l'attention : certains logiciels spécifiques aux fournisseurs de PLC peuvent ne pas être compatibles avec l'adressage du PLC par un alias IP ; ils peuvent exiger l'accès à l'adresse IP explicitement configurée dans le projet.

Dans ce cas, chaque PLC de l'unité de production doit disposer d'une adresse IP unique, sinon des collisions peuvent survenir. De plus, selon l'infrastructure réseau, l'accès de niveau 2 (Layer 2) des Gateways aux PLC peut ne pas fonctionner ; il s'agit d'une fonctionnalité à venir pour l'intégration des réseaux industriels temps réel dans les services SEW.

Logiciel

SDA Glue est une application qui s'exécute en tant que service du système d'exploitation, garantissant une haute disponibilité de la Gateway grâce au démarrage automatique et au redémarrage en cas d'erreur. Afin d'établir les tunnels réseau en gérant des ressources réseau telles que les interfaces, les routes et les règles de pare-feu, elle nécessite une élévation de privilèges en tant qu'utilisateur système.

Les mises à jour automatiques sont activées par défaut. Le service Glue lit la dernière version stable depuis repository.eu1.sdacosole.io et applique la mise à jour dès qu'il n'y a plus de connexion active. Le mécanisme de mise à jour télécharge le nouveau binaire de l'application, remplace l'ancien et redémarre le service.

AWS IoT Core est connecté lors de la connexion (login), en utilisant le point de terminaison iot.eu1.sdaconsole.io. Une fois connecté, le service Glue écoute en permanence les demandes provenant du SEW Cloud et publie des données de télémétrie, comme l'état des Devices associés à la Gateway. L'authentification IoT est protégée par un identifiant court et un mot de passe à usage unique pouvant être récupéré depuis la SEW Console. La connexion à IoT est également sécurisée par une clé secrète intégrée au binaire de l'application. La connexion à IoT peut être configurée pour être établie via MQTT SSL ou WebSocket Secure, tous deux sur le port 443.

Les mécanismes réseau diffèrent entre Linux et Windows. Ils sont donc décrits séparément.

Linux

Sous Linux, SDA Glue s'appuie sur le client SoftEther VPN, qui est open source (licence Apache 2.0), installé depuis le miroir SEW sur repository.eu1.sdaconsole.io lors de l'installation de Glue.

Pour chaque connexion, Glue utilise le client SoftEther pour créer une interface réseau NIC et la connecter au Tenant Server. Il utilise également les outils IP de Linux pour attribuer une adresse IP à cette interface et créer les routes nécessaires entre la Service VM et le Device cible.

Les règles de pare-feu internes et la traduction NAT sont créées dans iptables, qui n'autorise pas les paquets réseau entrants vers la Gateway, mais uniquement le transfert des paquets vers le Device cible.

📚 Gestion des ressources Linux dans les connexions

Pour comprendre comment la Gateway Linux relie les services cloud aux appareils de l'usine, examinons un exemple concret avec des adresses IP spécifiques illustrant le flux complet.

Considérons un réseau d'usine où un Device cible (tel qu'un PLC) possède l'adresse IP locale 10.0.0.5 et où la Gateway se trouve sur le même réseau avec l'IP 10.0.0.2. Dans le SEW Cloud, une Service VM doit se connecter à ce Device et recevra l'IP VPN 100.112.20.3, tandis que l'interface VPN de la Gateway recevra 100.112.10.6.

Établissement du tunnel

Lorsqu'une demande de connexion arrive, la Gateway et la Service VM entrent en action. La Gateway crée une nouvelle interface réseau virtuelle nommée vpn_iface et lui attribue l'adresse 100.112.10.6. Simultanément, la Service VM dans le cloud crée sa propre interface VPN avec l'IP 100.112.20.3. Les deux extrémités se connectent ensuite au Tenant Server, établissant entre elles un tunnel chiffré sécurisé.

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

À ce stade, le tunnel existe, mais les paquets ne savent toujours pas où aller. La Gateway doit apprendre au système comment router le trafic entre ces deux mondes.

Construction des routes

La Gateway ajoute une règle de routage qui crée la liaison entre le réseau VPN et l'atelier de production :

ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface

Cette route fournit au système une information cruciale : lorsque le Device à l'adresse 10.0.0.5 envoie des paquets de réponse, ceux-ci doivent être transférés via vpn_iface pour atteindre la Service VM à l'adresse 100.112.20.3. Sans cette route, la Gateway ne saurait pas comment renvoyer les réponses du Device vers le cloud.

Mais le routage seul ne suffit pas. Le pare-feu de la Gateway bloquerait toujours ce trafic par défaut. Pour activer la connexion, la Gateway doit explicitement autoriser le transfert bidirectionnel des paquets entre la VM et le Device :

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

Ces règles ouvrent un chemin contrôlé, permettant aux paquets de circuler de la Service VM vers le Device et inversement, tout en maintenant la posture de sécurité de la Gateway pour tout le reste du trafic. Notez également que Glue utilise ses propres chaînes dans iptables, afin de ne pas créer de conflits avec les autres règles.

Traduction NAT

Le Device dans l'usine s'attend à communiquer avec des adresses IP locales — il n'a aucune connaissance du réseau cloud en 100.112.20.3 et ne saurait pas comment répondre aux paquets provenant de cette adresse. La Gateway résout ce problème en masquant les paquets de la Service VM :

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

Avec cette règle NAT en place, lorsqu'un paquet arrive de la Service VM à destination du Device, la Gateway réécrit son adresse source de 100.112.20.3 vers 10.0.0.2. Du point de vue du Device, il semble communiquer directement avec la Gateway elle-même — une adresse familière et de confiance sur son réseau local. Lorsque le Device envoie sa réponse à 10.0.0.2, la Gateway effectue la traduction inverse, en rétablissant l'adresse de destination 100.112.20.3 afin que le paquet atteigne la Service VM via le tunnel VPN.

Grâce à cette orchestration du tunnel VPN, du routage, des règles de pare-feu et de la traduction NAT, la Gateway crée une connexion point à point transparente. Le Device ne voit jamais l'infrastructure cloud — il communique simplement avec ce qui apparaît comme étant la Gateway sur son réseau local, à l'adresse 10.0.0.2. Parallèlement, la Service VM obtient un accès direct au niveau de la couche réseau au Device par son adresse IP 10.0.0.5, ce qui permet à des applications industrielles comme TIA Portal ou Studio 5000 de fonctionner comme si elles s'exécutaient sur le réseau local de l'usine.

Windows

Sous Windows, SDA Glue ne prend pas en charge l'utilisation intégrée du client SoftEther VPN ; il utilise donc le client open source OpenVPN Community (licence GPL version 2), installé depuis le miroir SEW sur repository.eu1.sdaconsole.io lors de l'installation de Glue.

Pour chaque connexion, Glue utilise le pilote TAP d'OpenVPN pour créer une interface réseau et la connecter au Tenant Server à l'aide d'une authentification par certificat. Il utilise l'API native de Windows pour attribuer une IP à l'interface et créer les routes nécessaires entre la Service VM et le Device cible.

Glue utilise également Windows Filtering Platform (WFP) pour créer des couches et des règles de pare-feu dédiées. Il dépend toutefois de WinNAT ou NetNat pour déclarer la traduction d'adresses entre la Service VM et le Device, qui peuvent ne pas être activés par défaut.

Workstation vs. Gateway : les Workstations et les Gateways utilisent le même client Windows et la même configuration de connexion décrite ci-dessus — même pilote TAP OpenVPN, même adressage d'interface basé sur WinNAT. La seule différence réside dans la règle de pare-feu WFP attribuée par connexion selon la politique du backend : la connexion d'une Workstation reçoit toujours une règle exclusivement sortante limitée à l'IP de l'appareil cible spécifique via l'interface de tunnel SEW, tandis qu'une Gateway peut recevoir en plus une règle de transfert pour relayer le trafic vers les appareils situés derrière elle. Une Workstation n'ouvre donc jamais de chemins entrants ou de transfert sur l'hôte, et aucune autre interface réseau, route ou connexion VPN existante sur ce PC n'est affectée — toutes les modifications sont confinées à l'interface virtuelle que SDA Glue crée pour son propre tunnel.

Résumé

Le service de connectivité SEW offre une solution mature, sécurisée et évolutive aux défis de la connectivité industrielle. En combinant des technologies open source éprouvées telles que SoftEther VPN avec une infrastructure cloud de niveau entreprise fournie par AWS IoT Core, le service apporte la fiabilité et la sécurité qu'exigent les opérations industrielles, tout en offrant la flexibilité et la simplicité d'utilisation attendues par les équipes d'ingénierie modernes.

L'architecture du service respecte les principes de sécurité industrielle tout en permettant les initiatives de transformation numérique qui favorisent l'efficacité opérationnelle, la collaboration à distance et la prise de décision fondée sur les données. Pour les organisations souhaitant connecter en toute sécurité leurs actifs industriels aux services cloud sans compromettre la sécurité du réseau ni la fiabilité opérationnelle, le service de connectivité SEW constitue une solution complète, prête pour la production.