SDA Connectivity Service

Vue d'ensemble

Le SDA Connectivity Service s'appuie sur le 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 SDA, tels que IDEaaS, les VM de Backup et de Deployment. Il combine également les pare-feux natifs des systèmes 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'équipement situé dans la couche de contrôle de la production.

Points clés

La gestion des actifs industriels avec SDA 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 basés sur le cloud. En exploitant des technologies éprouvées et en mettant en œuvre des mesures de sécurité robustes, le service offre une connectivité de niveau entreprise spécifiquement adaptée aux systèmes d'automatisation et de contrôle industriels.

Sécurité de niveau industriel : l'intégration avec AWS IoT Core assure des connexions TLS sécurisées assorties de politiques de contrôle d'accès à granularité fine. Cela 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 équipements.

Une base VPN éprouvée : le service utilise SoftEther VPN, qui fournit un chiffrement AES 256 bits et RSA 4096 bits avec des performances de débit élevées 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 équipements spécifiquement autorisés, et non à des segments réseau entiers, ce qui réduit considérablement la surface d'attaque.

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 jamais 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 principaux composants du Connectivity Service. 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 sécurisé de production, accessibles par leur adresse IP, p. ex. PLC, IHM et robots. Les Devices sont déclarés dans la SDA 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 SDA 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 qui nécessite des règles spécifiques pour accéder aux ressources du SDA Cloud, comme les Tenant Servers. Chaque Gateway exécute le 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 équipements 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 équipements.

Tenant Servers : hôtes bastion fonctionnant dans un environnement SDA Cloud sécurisé, dédiés à chaque Tenant, qui relient l'interface réseau de la Gateway à une VM de service SDA ou à une autre Gateway. Ces serveurs garantissent les politiques de filtrage requises pour assurer une connexion point à point exclusivement, par exemple depuis IDEaaS vers un PLC spécifique et non vers d'autres équipements non souhaités du même réseau que la Gateway. Ils authentifient également l'accès depuis les Gateways selon une politique de rotation des identifiants pour chaque connexion.

Service VMs : exécutent les applications nécessaires aux services SDA, comme IDEaaS, Backup et les pipelines de Deployment. Ces VM s'appuient sur le Connectivity Service 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 de recourir à des VPN statiques traditionnels, le SDA Connectivity Service établit les connexions aux actifs industriels à la demande ; ces demandes sont transmises à une chaîne de Nodes qui coopèrent pour fournir un accès réseau point à point entre les services SDA et les Devices.

Pour le réseau de production, toutes les connexions sont initiées depuis la Gateway, ce qui ne nécessite aucune règle de connexion entrante dans l'usine. Pour y parvenir, les Nodes écoutent en permanence les requêtes entrantes sur un broker 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 de périphérie situé entre une couche de contrôle de production et Internet, qui fournit aux services SDA 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 SDA Cloud à l'infrastructure locale. Nous recommandons l'une des deux configurations proposées ci-dessous pour la Gateway.

Gateway en LAN

C'est l'approche la plus courante : la Gateway est placée à proximité des PLC intégrés à la plateforme SDA. 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 : une orientée vers la DMZ et une privée dans la couche de contrôle. Cette architecture autorise des plages d'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 la Gateway s'exécute dans une machine virtuelle dédiée, quelque part dans l'infrastructure serveur. L'équipe IT fournira des routes spéciales entre la VM et les PLC cibles dans la couche de contrôle, et des pare-feux existeront probablement sur les deux accès, vers Internet et vers 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 via 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 posséder une adresse IP unique, sans quoi 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 SDA.

Logiciel

Le 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 et au redémarrage automatisés en cas d'erreur. Pour é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, il nécessite une élévation 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'aucune connexion n'est 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 requêtes provenant du SDA 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 SDA 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

SDA Glue sous Linux s'appuie sur le client SoftEther VPN, qui est open source (licence Apache 2.0), installé depuis le miroir SDA 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 équipements 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 SDA 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 connexion 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 indique au système une information cruciale : lorsque le Device situé à 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 à 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 encore ce trafic par défaut. Pour permettre la connexion, la Gateway doit explicitement autoriser le transfert bidirectionnel de 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 autre trafic. Notez également que Glue utilise ses propres chaînes dans iptables, afin de ne pas provoquer 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 à 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 en 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 tunneling 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 lui apparaît comme la Gateway sur son réseau local à 10.0.0.2. Parallèlement, la Service VM obtient un accès direct au Device au niveau de la couche réseau, par son adresse IP 10.0.0.5, permettant à 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

SDA Glue sous Windows ne prend pas en charge l'usage intégré du client SoftEther VPN ; il utilise donc le client open source OpenVPN Community (licence GPL version 2), installé depuis le miroir SDA 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, ce qui peut ne pas être activé par défaut.

Workstation vs. Gateway : les Workstations et les Gateways utilisent le client Windows et la configuration de connexion identiques décrits 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'adresse IP de l'équipement cible spécifique via l'interface du tunnel SDA, tandis qu'une Gateway peut recevoir en outre une règle de transfert permettant de relayer le trafic vers les équipements 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 se limitent à l'interface virtuelle que SDA Glue crée pour son propre tunnel.

Résumé

Le SDA Connectivity Service offre une solution mature, sécurisée et évolutive face aux défis de la connectivité industrielle. En combinant des technologies open source éprouvées comme SoftEther VPN avec une infrastructure cloud de niveau entreprise basée sur AWS IoT Core, le service fournit la fiabilité et la sécurité qu'exigent les opérations industrielles tout en offrant la flexibilité et la facilité 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 à des services cloud sans compromettre la sécurité du réseau ni la fiabilité opérationnelle, le SDA Connectivity Service constitue une solution complète et prête pour la production.