Accès distant sécurisé PLC et SCADA : architecture, VPN et conformité NIS2

· 16 minutes de lecture
16 min read
Équipe Eziwan
Équipe Eziwan
Infrastructure IoT

En 2025, plus de 78 % des pannes sur automates industriels peuvent être diagnostiquées et résolues à distance — sans déplacement technicien. Pourtant, la majorité des industriels envoient encore un technicien sur site pour des interventions de 15 à 30 minutes qui leur coûtent 800 à 2 000 € chacune. Le frein principal : la peur (légitime) d'exposer son réseau OT à Internet.

Ce guide répond à la question que posent tous les responsables automatisme et IT industriel : comment ouvrir l'accès distant à ses automates sans créer une faille dans son réseau OT ? Architecture technique, protocoles VPN, contrôle des accès, audit trail, conformité NIS2 — tout est couvert.

Pourquoi l'accès distant OT n'est pas comme l'accès IT​

Les contraintes spécifiques des réseaux OT​

Les réseaux Operational Technology (OT) ont des contraintes radicalement différentes du monde IT classique. Les ignorer, c'est soit rester sans accès distant, soit créer une faille majeure.

Protocoles hérités non sécurisés par design :

  • Modbus TCP/RTU : aucune authentification, aucun chiffrement — conçu en 1979 pour des réseaux fermés
  • S7comm (Siemens) : protocole propriétaire, port 102, vulnérable aux man-in-the-middle sans couche de chiffrement externe
  • EtherNet/IP (Rockwell) : port 44818, protocole CIP — pas de sécurité native sur les versions historiques
  • PROFINET : protocole temps-réel Siemens/Ethernet, latence critique, incompatible avec les proxies applicatifs standards

Contrainte temps-réel et disponibilité : Un automate qui pilote une ligne de production ne peut pas être redémarré pour un patch de sécurité. Les fenêtres de maintenance sont planifiées à l'avance, souvent mensuellement ou annuellement. Toute interruption non planifiée — même 30 secondes — peut avoir des conséquences physiques ou financières graves.

Équipements vieillissants en production : On trouve couramment en production des automates Siemens S5, Schneider Premium ou Allen-Bradley SLC 500 avec 15 à 25 ans d'âge. Pas de chiffrement intégré, pas d'authentification moderne — seulement du RS485 et du Modbus.

Conséquences d'une intrusion très différentes : Une intrusion dans le réseau IT compromet des données. Une intrusion dans le réseau OT peut arrêter une ligne, déclencher un défaut de sécurité, ou dans le pire des cas créer un incident physique (comme dans l'incident Ukrainian Power Grid de 2015 ou l'attaque Triton/TRISIS de 2017 contre un système de sécurité instrumenté).

Le piège le plus dangereux : le port forwarding direct​

La tentation est réelle : ouvrir le port 102 (S7) ou le port 80 (IHM web) sur le routeur du site et accéder à l'automate depuis n'importe où. Rapide, zéro configuration, et catastrophique.

En 2024, le moteur de recherche Shodan indexe en permanence plus de 45 000 automates industriels directement exposés sur Internet en France. Un automate Siemens accessible sur le port S7-comm est détecté par les scanners automatiques en moins de 48 heures. Les conséquences documentées incluent :

  • Modification de programmes automates par des acteurs malveillants
  • Arrêts de production volontaires (ransomware OT)
  • Exfiltration de savoir-faire (programmes, recettes, paramètres de production)
  • Sabotage de systèmes de sécurité instrumentée (SIL)
Ne jamais exposer de port OT directement sur Internet

Aucun automate (Siemens, Schneider, Rockwell, ABB, Omron) ne doit être accessible directement depuis Internet. Même protégé par un mot de passe, même sur un port non standard. La seule architecture sécurisée repose sur un VPN ou un système de type Zero Trust Network Access.

Les 3 architectures d'accès distant sécurisé​

Architecture 1 : VPN site-to-bureau — le standard industriel​

C'est l'architecture la plus répandue et la plus adaptée à 90 % des cas industriels. Un routeur industriel sur site maintient en permanence un tunnel VPN chiffré sortant vers un concentrateur cloud ou votre datacenter. Le technicien se connecte via un client VPN sur son poste.

Caractéristiques clés :

  • Aucun port entrant sur le réseau du site — le firewall site bloque tout trafic entrant
  • Le tunnel VPN est établi de l'intérieur vers l'extérieur (connexion sortante du Gateway)
  • Tous les protocoles OT transitent dans le tunnel chiffré : S7comm, Modbus TCP, EtherNet/IP, PROFINET (Layer 2)
  • Le technicien voit l'automate comme s'il était en local sur le LAN du site
  • TIA Portal, Unity Pro, Studio 5000, FactoryTalk — compatibles sans modification

Mise en place : 20 minutes côté site (installation Gateway), 5 minutes côté technicien (client OpenVPN ou WireGuard).

Architecture 2 : Jump server / bastion OT​

Pour les environnements avec des politiques de sécurité strictes (industrie chimique, nucléaire, eau) ou des équipes d'intervenants multiples (prestataires, intégrateurs, constructeurs machines), un serveur bastion renforce l'isolation.

Le bastion ne fait que relayer les connexions explicitement autorisées. Il logge tout trafic, refuse tout par défaut, et ne donne accès qu'aux équipements de la liste blanche définie pour chaque technicien.

Recommandé pour : OIV, EE (NIS2), sites sous certification ISO 27001, industries à risque (chimie, pharmaceutique, énergie).

Architecture 3 : Zero Trust Network Access (ZTNA)​

Pour les grandes flottes (50+ sites) avec des équipes multiples et des partenaires extérieurs (constructeurs machines OEM, intégrateurs, sous-traitants), le modèle Zero Trust s'impose. Le principe : ne jamais faire confiance, toujours vérifier.

Chaque accès est évalué sur la base de :

  • Identité : qui se connecte ? (MFA obligatoire, LDAP/SSO compatible)
  • Contexte : depuis quel appareil ? Depuis quelle heure ? Depuis quelle localisation ?
  • Droit minimal : accès uniquement aux équipements de la mission, rien de plus
  • Traçabilité : chaque commande, chaque flux est audité et peut être rejoué
CritèreVPN classiqueBastionZTNA
Complexité déploiementFaibleMoyenneÉlevée
Granularité des droitsRéseau/VLANÉquipementVariable/session
Audit et traçabilitéConnexions VPNCommandes SSHToutes actions
Scalabilité (100+ sites)MoyenneBonneExcellente
Adapté NIS2 OIVOui (bien configuré)OuiOui (natif)
Coût d'infrastructureFaibleMoyenÉlevé

Guide pratique : accès distant à un automate Siemens S7-1200​

Prérequis​

  • Gateway Eziwan installé sur le réseau du site (sous-réseau 192.168.1.0/24)
  • Automate S7-1200 à l'adresse 192.168.1.10 (confirmer via TIA Portal en local)
  • Compte technicien créé sur la plateforme Eziwan
  • TIA Portal v17 ou supérieur installé sur le PC du technicien
  • Client OpenVPN ou WireGuard installé

Étape 1 — Vérifier la topologie réseau du site​

Depuis le dashboard Eziwan → Site → Configuration réseau :

# Depuis l'interface CLI du Gateway (SSH local ou console)
eziwan route list
# Résultat attendu :
# 192.168.1.0/24 via eth0 (LAN) → announced via VPN tunnel
# 0.0.0.0/0 via lte0 (WAN) → default route LTE

eziwan connectivity test 192.168.1.10
# Résultat attendu :
# Ping 192.168.1.10 OK (4ms)
# Port 102 (S7) : OPEN

Étape 2 — Créer un accès technicien sur la plateforme​

Dashboard Eziwan → Accès → Techniciens → Nouvel accès :

  1. Saisir l'email du technicien (invitation automatique)
  2. Sélectionner le(s) site(s) autorisés : Site-Lyon-Usine-A
  3. Définir la plage horaire : Lun-Ven 7h-19h
  4. Sélectionner les équipements accessibles (optionnel) : 192.168.1.10 uniquement
  5. Date d'expiration de l'accès (recommandé pour les prestataires)
  6. Générer le profil VPN — OpenVPN .ovpn ou WireGuard .conf

Le technicien reçoit un email avec son fichier de configuration chiffré et les instructions d'installation.

Étape 3 — Installation du client VPN (technicien)​

Windows (recommandé : OpenVPN GUI) :

# Installation via winget
winget install OpenVPN.OpenVPN

# Importer le profil (glisser-déposer dans la zone notification OpenVPN)
# ou en ligne de commande :
openvpn --config "C:\eziwan\site-lyon.ovpn" --daemon

Linux :

sudo apt install openvpn network-manager-openvpn-gnome
# Importer le profil via NetworkManager
sudo nmcli connection import type openvpn file /home/user/site-lyon.ovpn
sudo nmcli connection up site-lyon

macOS (Tunnelblick) :

# Installer Tunnelblick (tunnelblick.net)
# Double-cliquer sur le fichier .ovpn → importation automatique

Étape 4 — Connexion à l'automate​

Une fois le VPN actif, TIA Portal détecte l'automate comme s'il était sur le réseau local :

TIA Portal → Online → Accessible devices
→ 192.168.1.10 — Siemens S7-1200 CPU 1212C DC/DC/DC
→ Firmware: V4.5
→ Connexion S7comm (port 102) établie
→ Latence tunnel : 18 ms (acceptable pour TIA Portal)

Ce qui se passe techniquement :

Latence totale typique : 15 à 35 ms sur 4G LTE — largement suffisant pour TIA Portal, qui fonctionne correctement jusqu'à 100 ms.

Compatibilité par logiciel de programmation automate​

LogicielConstructeurProtocoleCompatible VPN EziwanNotes
TIA Portal v17+SiemensS7comm / PROFINET✅ NatifLatence < 50 ms requise
Unity Pro / EcoStruxureSchneiderMODBUS TCP / UNI-TE✅ NatifM340, M580, Premium
Studio 5000 / FactoryTalkRockwellEtherNet/IP / CIP✅ NatifControlLogix, CompactLogix
Sysmac StudioOmronEtherNet/IP / FINS✅ NatifNX, NJ séries
GX WorksMitsubishiMELSEC✅ NatifQ, FX5 séries
CODESYSMulti-fabricantsMODBUS TCP / OPC-UA✅ NatifRuntime CODESYS
Step 7 ClassicSiemens (legacy)S7comm✅ CompatibleS7-300/400, protocole S7 v1
TIA Portal et latence réseau

TIA Portal est sensible à la latence sur les séances de débogage en ligne. Au-delà de 80 ms, le comportement peut devenir erratique (timeouts de connexion, lenteur d'affichage des blocs en ligne). La 4G LTE donne généralement 15–35 ms, ce qui est confortable. La 3G (si encore disponible) avec 80–150 ms peut poser problème.

Accès distant à une IHM et un SCADA​

IHM Siemens WinCC / KTP (via VPN)​

L'IHM est sur le réseau local du site (ex : 192.168.1.20). Avec le VPN actif :

  • WinCC Runtime : accessible directement via l'adresse IP locale
  • Simatic HMI : protocole S7comm, même comportement que l'automate
  • Panneau KTP : accessible via TIA Portal en ligne

SCADA Wonderware AVEVA (reverse proxy HTTPS)​

Pour les systèmes SCADA avec interface web (Wonderware, Ignition, WinCC OA), Eziwan peut configurer un reverse proxy sécurisé sans nécessiter de VPN côté utilisateur :

# Configuration reverse proxy sur Gateway Eziwan
proxy_rules:
  - name: scada-lyon
    description: "SCADA Wonderware System Platform — Usine Lyon A"
    internal: http://192.168.1.100:80
    external: https://scada-lyon.eziwan.com
    tls: true                   # HTTPS avec certificat Let's Encrypt auto-renouvelé
    auth: eziwan_sso            # SSO Eziwan avec MFA obligatoire
    allowed_users:
      - superviseur@entreprise.fr
      - technicien-maintenant@entreprise.fr
    session_timeout: 30m        # Déconnexion après inactivité
    audit_log: true             # Toutes les actions loggées

L'utilisateur accède à https://scada-lyon.eziwan.com depuis son navigateur, s'authentifie via SSO + MFA, et arrive sur l'interface SCADA — sans client VPN, depuis n'importe quel appareil.

Ignition (Inductive Automation)​

Ignition dispose d'une passerelle web native. Avec Eziwan :

Ignition Gateway (192.168.1.50:8088)
→ Accès via reverse proxy Eziwan avec HTTPS + MFA
→ Ou accès direct via VPN (port 8088 local)
→ Ou via Ignition Cloud (si licence Ignition Cloud incluse)

Les 7 règles d'or de la sécurité accès distant OT​

1. Aucun port entrant exposé sur le site​

Règle absolue. Le Gateway Eziwan bloque tous les ports entrants par défaut. La seule connexion autorisée est sortante (tunnel VPN vers le cloud). Même le port SSH de gestion du Gateway est désactivé côté WAN.

2. MFA systématique sur tous les accès​

Aucun accès à une connexion VPN, au portail Eziwan, ou à un accès SCADA sans second facteur d'authentification. Support : TOTP (Google Authenticator, Authy), clé physique FIDO2 (YubiKey), SMS (à éviter).

3. Accès à durée limitée pour les prestataires​

Un intégrateur qui intervient sur votre ligne d'embouteillage pendant 2 jours n'a pas besoin d'un accès permanent. Créez un accès avec date d'expiration et plage horaire. L'accès est révoqué automatiquement.

4. Un accès par personne, pas de credentials partagés​

Un seul compte VPN partagé par toute l'équipe = aucune traçabilité. Chaque technicien (interne ou externe) doit avoir son propre compte nominatif. En cas d'incident, vous saurez exactement qui était connecté et quand.

5. Journalisation complète et rétention 12 mois minimum​

Toute connexion VPN, toute modification de configuration, tout accès à un équipement doit être loggé avec : horodatage, identité, adresse IP source, durée de session. Rétention minimum 12 mois (NIS2 impose 3 ans pour les OIV).

6. Segmentation OT/IT stricte​

Les automates (réseau OT) ne doivent pas être sur le même VLAN que les serveurs IT. Le Gateway Eziwan peut gérer plusieurs interfaces LAN avec des règles de firewall inter-VLAN strictes. L'accès du réseau IT vers le réseau OT passe par une DMZ contrôlée.

7. Révocation immédiate des accès en cas de départ​

Protocole de départ : révocation du compte le jour du départ, désactivation immédiate du certificat VPN, audit des sessions des 30 derniers jours. À documenter dans votre procédure RH.

Conformité NIS2 et IEC 62443​

Ce que NIS2 impose pour l'accès distant​

La directive NIS2 (applicable en France depuis octobre 2024 via transposition) impose aux entités essentielles et importantes des mesures spécifiques sur l'accès distant :

Exigence NIS2ArticleSolution Eziwan
Authentification forte (MFA)Art. 21 §2bMFA TOTP/FIDO2 sur tous les accès
Chiffrement des communicationsArt. 21 §2hOpenVPN AES-256-GCM ou WireGuard ChaCha20
Journalisation des accèsArt. 21 §2jLogs complets, exportables, rétention configurable
Gestion des accès tiersArt. 21 §2iAccès temporaires, nominatifs, révocables
Notification d'incidentArt. 23Alertes automatiques sur accès anormaux
Gestion des vulnérabilitésArt. 21 §2eFirmware Gateway mis à jour automatiquement

Mapping IEC 62443​

La norme IEC 62443 définit des Security Levels (SL) pour les systèmes de contrôle industriels. L'architecture Eziwan couvre :

Security LevelExigences couvertes par Eziwan
SL 1 — Protection contre les attaques non intentionnellesAuthentification de base, pare-feu, logs
SL 2 — Protection contre les attaques intentionnelles simplesMFA, chiffrement, audit trail, segmentation
SL 3 — Protection contre des attaques sophistiquéesZTNA, ségrégation réseau avancée, détection d'anomalies
Export de conformité

La plateforme Eziwan génère un rapport de conformité NIS2 téléchargeable (PDF) incluant : inventaire des accès, journaux des 12 derniers mois, configuration de sécurité. Utilisable directement pour vos audits ANSSI ou auditeurs tiers.

Troubleshooting : problèmes fréquents​

TIA Portal ne voit pas l'automate via VPN​

Causes possibles :

  1. La route vers le sous-réseau du site n'est pas poussée par le VPN → vérifier la configuration de l'interface tunnel (eziwan route list sur le Gateway)
  2. Le pare-feu Windows bloque S7comm sur le réseau "Public" → changer le profil réseau VPN en "Privé"
  3. Timeout S7comm < latence tunnel → dans TIA Portal, augmenter le timeout de connexion à 5 000 ms (Paramètres → PG/PC Interface)

Latence trop élevée pour TIA Portal (> 80 ms)​

Vérifications :

# Test ping depuis le PC technicien vers l'automate (VPN actif)
ping 192.168.1.10 -n 20

# Si latence > 80 ms, vérifier :
# 1. Qualité signal 4G sur le site (RSRP > -100 dBm recommandé)
eziwan modem signal

# 2. Localisation du concentrateur VPN (choisir Europe/France)
# 3. Congestion réseau côté technicien (tester depuis un autre réseau)

Connexion VPN établie mais automate inaccessible​

# Vérifier la route depuis le Gateway
eziwan route test 192.168.1.10
# Si timeout : vérifier le câble Ethernet Gateway ↔ switch du site

# Vérifier que l'automate répond en local
eziwan ping 192.168.1.10 --source lan
# Si timeout : vérifier configuration IP automate et état physique

Questions fréquentes​

Combien de techniciens peuvent se connecter simultanément ? Il n'y a pas de limite sur le nombre de connexions VPN simultanées dans les offres Eziwan standard. Sur un même site, 2 techniciens peuvent travailler simultanément sur des automates différents. La bande passante 4G (20–50 Mbps typiques) est partagée entre toutes les connexions actives.

Est-il possible d'utiliser notre VPN d'entreprise existant à la place d'Eziwan ? Oui, si votre VPN d'entreprise peut s'interfacer avec un routeur qui établit un tunnel IPSec standard. Le Gateway Eziwan supporte IPSec/IKEv2 comme tunnel alternatif. Cependant, la perte d'audit trail, de gestion des droits granulaire et de ZTP est significative pour les flottes multi-sites.

Peut-on enregistrer les séances de maintenance à distance (vidéo) ? L'enregistrement de séance (screen recording) est disponible dans l'offre Eziwan Enterprise via l'intégration avec des outils de PAM (Privileged Access Management) comme CyberArk ou Teleport. Ce n'est pas natif dans l'offre standard.

L'accès distant fonctionne-t-il pour des automates sur des protocoles non-IP (Profibus, HART) ? Pour Profibus : nécessite une passerelle Profibus → Modbus TCP ou Profibus → Ethernet sur le site. Ce type de passerelle (ex: Anybus X-gateway) est ensuite accessible via le tunnel VPN. Pour HART : les transmetteurs HART sont généralement accessibles via leur interface locale Modbus ou via un multiplexeur HART.

Comment gérer un technicien prestataire qui change d'entreprise ? La révocation est immédiate depuis le portail Eziwan : compte désactivé, certificat VPN révoqué, accès coupé dans la seconde. Le technicien ne peut plus se connecter même s'il conserve son fichier de configuration VPN (le certificat révoqué est refusé par le concentrateur).

L'accès distant interfère-t-il avec le fonctionnement de l'automate ? Non — le Gateway Eziwan est un équipement réseau passant. Il ne s'interfère pas avec le bus de terrain ou les communications automate-IHM. L'automate ne "voit" pas la connexion distant : il reçoit des requêtes Modbus ou S7comm comme s'il était interrogé depuis le réseau local.

Pour aller plus loin​

L'accès distant sécurisé à vos automates n'est plus un luxe en 2025 — c'est une nécessité opérationnelle (réduction des coûts d'intervention) et réglementaire (NIS2). Avec la bonne architecture, vous divisez par 3 à 5 vos coûts de maintenance terrain en renforçant simultanément la sécurité de votre réseau OT.

Besoin d'un audit de votre architecture d'accès distant actuelle ? Planifiez une démo technique — notre équipe réalise un diagnostic complet de votre sécurité OT en 45 minutes.

Ressources complémentaires​