VPN industriel vs TeamViewer : pourquoi les outils grand public ne suffisent pas en environnement OT
La question revient régulièrement lors des projets d'accès distant industriel : "Pourquoi ne pas simplement utiliser TeamViewer ? C'est ce qu'on fait déjà pour le support informatique."
La réponse courte : les réseaux OT ne sont pas des réseaux IT. Les automates qui y tournent pilotent des machines physiques — une commande erronée ou une intrusion peut avoir des conséquences industrielles, voire humaines. Les outils grand public ont été conçus pour un contexte radicalement différent.
Cet article va au-delà de la réponse courte. Il explique le modèle de menace réel, détaille ce que la norme IEC 62443 exige, et présente les critères techniques pour évaluer une solution d'accès distant industriel.
1. Le modèle de Purdue et les niveaux de confiance OT
Pour comprendre pourquoi les accès distants OT sont différents, il faut connaître le modèle de Purdue (Purdue Enterprise Reference Architecture), référence internationale pour la segmentation des réseaux industriels.
Niveau 5 : Réseau d'entreprise (ERP, email, bureautique)
─────────────────────────────────────────────
Niveau 4 : Réseau IT de site (serveurs, SGBD, Active Directory)
─────────────────────────────────────────────
Niveau 3 : Réseau supervision (SCADA, MES, historiens)
─────────────────────────────────────────────
Niveau 2 : Réseau contrôle (IHM, ingénierie)
─────────────────────────────────────────────
Niveau 1 : Réseau terrain (automates, variateurs, capteurs)
─────────────────────────────────────────────
Niveau 0 : Process physique (capteurs, actionneurs, moteurs)
L'accès distant industriel concerne typiquement les niveaux 1 et 2 — les automates et les outils d'ingénierie. Ces niveaux ne doivent jamais être directement accessibles depuis les niveaux supérieurs sans contrôle, et encore moins depuis Internet.
La segmentation entre les niveaux est la première ligne de défense. L'accès distant, par définition, traverse cette segmentation — d'où les exigences de sécurité renforcées.
2. Les risques réels d'un accès non maîtrisé sur réseau OT
Ce qui est exposé sur un réseau OT industriel
Un réseau OT typique héberge :
- Des automates programmables (S7, M340, CompactLogix) qui pilotent les machines
- Des variateurs de fréquence contrôlant les moteurs
- Des IHM industrielles permettant la supervision et le paramétrage
- Des systèmes SCADA supervisant l'ensemble du process
- Des instruments de mesure (capteurs de pression, de température, de débit)
Ces équipements ont été conçus pour la fiabilité dans des environnements isolés, pas pour résister à des attaques réseau. Le protocole Modbus ne prévoit aucune authentification. S7Comm (Siemens) n'avait historiquement aucun chiffrement. Profinet, EtherNet/IP — la majorité des protocoles industriels supposent un réseau de confiance.
Anatomie d'une attaque sur accès distant OT mal sécurisé
Voici comment se déroule typiquement une compromission d'un accès distant industriel non sécurisé :
Phase 1 — Reconnaissance (automatique, passive) : Un scanner automatique (Shodan, Censys, ou un script personnalisé) identifie l'IP publique de l'usine et découvre un port ouvert (VPN classique sur UDP 1194, port Modbus 502, port S7Comm 102). Cette phase ne génère aucun log suspect et dure quelques secondes.
Phase 2 — Exploitation de l'accès : Si le VPN n'est protégé que par un mot de passe faible (ou si les credentials ont été volés par phishing), l'attaquant entre. S'il s'agit d'un port Modbus directement exposé, il peut lire et écrire sans aucune authentification.
Phase 3 — Reconnaissance interne : Depuis l'accès obtenu, l'attaquant cartographie le réseau OT : quels automates sont accessibles, quelles variables sont lisibles, quelles zones process sont pilotées.
Phase 4 — Action malveillante : Les actions peuvent être immédiates (arrêt de production, modification de paramètres) ou discrètes (modification progressive de setpoints pour dégrader la qualité produit sans déclencher d'alarme).
Les attaques les plus dangereuses ne sont pas les plus spectaculaires. Une modification de ±5 % d'une consigne de dosage dans une installation chimique ou pharmaceutique peut rester indétectable pendant des jours, avec des conséquences sur la qualité du produit fini potentiellement catastrophiques.
Incidents documentés
L'ANSSI et le CISA (Cybersecurity and Infrastructure Security Agency, États-Unis) documentent régulièrement des incidents sur des accès distants industriels mal sécurisés :
- TeamViewer sur poste de supervision eau (Floride, 2021) : un attaquant a modifié les niveaux de traitement chimique via TeamViewer installé sur le SCADA d'une station de traitement d'eau potable. L'attaque a été détectée par l'opérateur en direct, mais aurait pu passer inaperçue.
- VPN sans MFA dans le secteur énergie : plusieurs incidents documentés où des credentials VPN volés ont permis l'accès à des réseaux électriques régionaux en Europe.
- Port forwarding Modbus : des chercheurs en sécurité ont régulièrement démontré la capacité à modifier des paramètres d'automates industriels accessibles directement depuis Internet.
3. Ports ouverts vs tunnel sortant : la différence fondamentale
Architecture "port entrant exposé"
[Internet] ──→ [Pare-feu usine : port ouvert] ──→ [Réseau OT] ──→ [Automate]
Ce modèle expose un point d'entrée sur Internet. Que ce soit un port VPN (UDP 1194 pour OpenVPN, UDP 500/4500 pour IPsec) ou un port applicatif (502, 102, 443), ce port est scruté en permanence.
Cycle de vie d'un port exposé :
- Ouverture du port → référencement par Shodan dans les 24-48h
- Premières tentatives de scan → quelques jours après l'exposition
- Tentatives d'exploitation automatisée → dès qu'une signature connue est identifiée
- Exploitation ciblée → si l'installation est identifiée comme critique ou intéressante
Architecture "tunnel sortant uniquement"
[Réseau OT] ──→ [Gateway : connexion sortante] ──→ [Cloud] ←── [Opérateur]
Ce qui change fondamentalement :
- La connexion est initiée de l'intérieur — exactement comme un navigateur web
- Du point de vue du pare-feu de l'usine : trafic HTTPS sortant vers une IP connue
- Aucun port entrant à ouvrir, aucune règle de pare-feu à modifier
- Aucun port exposé = aucune surface d'attaque réseau côté usine
Si l'infrastructure cloud Eziwan était compromise (scénario hypothétique), un attaquant ne pourrait pas rebondir vers le réseau de l'usine — la connexion est unidirectionnelle du point de vue de l'initiation.
Pourquoi TeamViewer n'est pas "aussi sécurisé" que OpenVPN
TeamViewer utilise bien un relay cloud (pas de connexion directe de l'attaquant à l'usine), mais les problèmes structurels sont différents :
| Problème | Explication |
|---|---|
| Infrastructure tierce | Les sessions passent par des serveurs TeamViewer. Si TeamViewer est compromis (comme en 2016), vos sessions le sont aussi. |
| Traçabilité dépendante de l'abonnement | Les journaux complets ne sont disponibles que sur les abonnements premium. En version gratuite, pas de log exportable. |
| Modèle d'authentification inadapté | Un code à 9 chiffres échangé par email n'est pas une authentification forte. |
| Pas d'isolation OT | TeamViewer donne accès au poste Windows qui l'exécute — et depuis ce poste, potentiellement au réseau OT entier. |
4. Ce que disent IEC 62443 et l'ANSSI
IEC 62443 — la norme de référence
La norme IEC 62443 définit les exigences de cybersécurité pour les systèmes industriels. Pour l'accès distant, le Security Level 2 (SL2) — niveau recommandé pour la majorité des installations industrielles — exige :
SR 1.1 — Identification et authentification humaine : Tout utilisateur accédant au système doit être individuellement identifié et authentifié. Les comptes partagés (un seul compte "maintenance" pour toute l'équipe) sont explicitement exclus.
SR 1.7 — Authenticité renforcée (Enhancement SL2) : L'authentification à deux facteurs (MFA) est requise pour les accès distants au niveau SL2. Un mot de passe seul n'est pas suffisant.
SR 2.6 — Accès via des réseaux non fiables : Tout accès depuis Internet vers le réseau OT doit être chiffré, authentifié, et journalisé. Cette exigence est la traduction normative du tunnel sortant + MFA + logs d'audit.
SR 6.2 — Surveillance en continu : Les accès distants doivent être journalisés en permanence — qui s'est connecté, quand, depuis quelle adresse, pendant combien de temps.
Recommandations ANSSI
L'ANSSI publie des guides spécifiques aux systèmes industriels. Ses cinq principes pour l'accès distant industriel :
- Cloisonnement : les accès distants ne doivent pas traverser directement le réseau OT — passer par une DMZ industrielle
- Authentification forte : MFA obligatoire pour tout accès distant à des équipements de niveau 1 ou 2
- Chiffrement : toutes les communications distantes doivent être chiffrées avec des algorithmes récents
- Journalisation : logs complets, exportables, horodatés, conservés au minimum 3 mois
- Moindre privilège : chaque technicien n'accède qu'aux équipements de son périmètre
L'ANSSI publie ces recommandations dans son guide "Maîtrise du risque numérique lié aux systèmes industriels", téléchargeable gratuitement sur ssi.gouv.fr. Sa lecture est recommandée à tout responsable de maintenance industrielle.
5. OpenVPN vs IPSec vs L2TP en contexte industriel
Tous les VPN ne se valent pas pour des gateways embarquées sur CPU ARM avec contraintes de reconnexion et de mémoire.
Analyse comparative détaillée
| Critère | OpenVPN | IPSec (IKEv2) | L2TP / PPTP |
|---|---|---|---|
| Transport | UDP ou TCP 443 | UDP 500/4500 (ESP/IKE) | UDP 1701 / TCP 1723 |
| Traversée pare-feu / NAT | Excellente (TCP 443 passe partout) | Moyenne (NAT-T requis) | Variable |
| Reconnexion après coupure 4G | Rapide (persist-tun, ~2-5 s) | Excellente (MOBIKE, quasi transparente) | Lente (15-60 s) |
| Primitives crypto | TLS, AES-256-GCM | AES-256, SHA-2 (IKEv2) | Faible (PPTP/MS-CHAPv2 déconseillé) |
| Authentification | Certificat X.509 par client | PSK ou certificats X.509 | Identifiant / mot de passe |
| Charge CPU (ARM Cortex-A) | Modérée | Faible (accélération matérielle possible) | Faible |
| Maturité / certifications | Largement audité, adoption massive | Certifié FIPS 140-2 | Ancien (PPTP à éviter) |
OpenVPN : le choix par défaut d'Eziwan pour les gateways embarquées
Le point clé pour l'industriel : la traversée des pare-feux et la reconnexion après coupure 4G. OpenVPN encapsule le tunnel dans TLS sur le port TCP 443 — le même que le HTTPS — ce qui lui permet de passer là où d'autres protocoles sont bloqués (pare-feu d'opérateur, proxy d'entreprise). Combiné à persist-tun, le tunnel se rétablit en quelques secondes après une bascule Dual SIM, sans renégociation complète.
Chaque technicien dispose de son propre certificat X.509, révocable individuellement depuis le dashboard cloud — une exigence forte pour la traçabilité NIS2.
IPSec (IKEv2) pour les environnements qui l'exigent
IPSec reste le standard en entreprise et dans les environnements industriels régulés qui imposent des protocoles certifiés FIPS 140-2. Son mécanisme MOBIKE gère le changement d'adresse IP de façon quasi transparente — particulièrement adapté au failover Dual SIM. La configuration est plus complexe (PKI, certificats X.509, SA policies), mais l'interopérabilité avec les équipements réseau existants est maximale. Le Eziwan Gateway supporte également L2TP, PPTP et GRE pour les cas d'interopérabilité hérités.
6. Comment Eziwan implémente le zéro-port-exposé
L'architecture Eziwan applique les principes précédents de manière systématique :
Architecture de connexion
- La gateway en usine initie la connexion OpenVPN vers l'infrastructure cloud Eziwan sur UDP 1194
- La connexion est authentifiée par certificats X.509 générés lors du provisioning
- Aucun port entrant n'est ouvert sur le réseau de l'usine
- L'accès opérateur passe par le cloud Eziwan, avec MFA intégré (TOTP ou push notification)
- Chaque session est journalisée : utilisateur, horodatage, durée, actions réalisées
Processus de migration depuis TeamViewer
Si vous utilisez actuellement TeamViewer sur des postes de supervision industriels, voici un processus de migration progressif :
Phase 1 — Déploiement parallèle (semaines 1-4) :
- Installer les gateways Eziwan sur 5 à 10 sites pilotes
- Laisser TeamViewer actif en parallèle pendant la phase de validation
- Former les équipes à l'utilisation du client VPN Eziwan et du tableau de bord
Phase 2 — Basculement progressif (semaines 5-8) :
- Désactiver TeamViewer sur les sites pilotes après validation
- Déployer sur les sites restants par vagues de 10-20 sites
- Vérifier que les journaux d'audit Eziwan couvrent les besoins des équipes
Phase 3 — Désinstallation et nettoyage (semaine 9+) :
- Désinstaller TeamViewer de tous les postes de supervision
- Révoquer les licences TeamViewer
- Archiver les anciens journaux TeamViewer si nécessaire pour conformité
Checklist de validation post-déploiement
Après le déploiement d'Eziwan, vérifier les points suivants :
- Aucun port TCP/UDP entrant ouvert sur le pare-feu de l'usine (scan depuis Internet)
- MFA activé pour tous les comptes d'accès distant
- Comptes nominatifs créés pour chaque technicien (pas de compte partagé)
- Droits d'accès vérifiés par périmètre (technicien X ne voit que ses sites)
- Test d'une alerte SMS/email pour valider le canal de notification
- Export des journaux d'audit testés (pour audit futur)
- Procédure de révocation d'accès documentée et testée
Tableau comparatif final
| Critère | TeamViewer / AnyDesk | VPN classique (site-to-site) | Eziwan |
|---|---|---|---|
| Ports entrants exposés | Non (relay cloud tiers) | Oui | Non |
| Traçabilité des sessions | Partielle (abonnement) | Dépend de l'équipement | Complète + export |
| Conformité IEC 62443 SL2 | ✗ | Partielle | ✓ |
| Conformité recommandations ANSSI | ✗ | Partielle | ✓ |
| Authentification MFA intégrée | Optionnelle | Optionnelle | Intégrée |
| Intervention réseau sur site | Non | Oui | Non |
| Isolation OT complète | ✗ | Partielle | ✓ |
| Journaux d'audit exportables | Abonnement premium | Selon équipement | Standard |
| Reconnexion après coupure 4G | 30–60 s | 5–30 s | < 2 s (OpenVPN) |
| Déploiement sans compétence réseau | Oui | Non | Oui (ZTP) |
Pour une mise en œuvre concrète sur automate Siemens S7, lire Comment connecter un S7 à distance sans ouvrir de port. Pour les exigences IEC 62443 dans le détail, voir IEC 62443 et accès distant industriel.
FAQ — VPN industriel vs TeamViewer
TeamViewer n'est-il pas suffisant si l'on n'accède qu'à un poste de supervision, pas directement à l'automate ?
Pas nécessairement. Le poste de supervision a généralement accès au réseau de niveau 1 (automates) via le logiciel SCADA. Une compromission du poste — que ce soit via TeamViewer ou via une autre faille — donne indirectement accès aux automates. L'isolation OT doit être pensée en termes de réseau, pas d'application.
WireGuard est-il une alternative viable à OpenVPN pour les gateways industrielles ?
WireGuard offre des performances supérieures et une codebase plus petite (mieux auditée), mais il présente une contrainte : il fonctionne uniquement en UDP, sans option TCP. Dans les réseaux où UDP est filtré (certains opérateurs mobiles, proxys d'entreprise), WireGuard peut échouer là où OpenVPN sur TCP 443 passerait. Pour les gateways 4G industrielles avec des connexions potentiellement capricieuses, OpenVPN reste le choix le plus universel.
Peut-on utiliser une solution VPN IPsec existante de l'entreprise plutôt qu'Eziwan ?
Oui, si la solution existante répond aux critères IEC 62443 SL2 (comptes nominatifs, MFA, journaux exportables, moindre privilège). Le problème récurrent des VPN site-to-site d'entreprise appliqués à l'OT est l'absence de granularité : le VPN donne accès à tout un segment réseau plutôt qu'à un équipement spécifique. Eziwan peut compléter une solution VPN d'entreprise en ajoutant la granularité et les journaux d'audit.
L'ANSSI liste-t-elle des solutions d'accès distant approuvées pour l'OT ?
L'ANSSI ne publie pas de liste de solutions "approuvées" mais des critères d'évaluation. Pour les OIV et OSE, des prestataires qualifiés PRIS (Prestataires de Réponse aux Incidents de Sécurité) peuvent effectuer une évaluation formelle. Les critères ANSSI sont cohérents avec les exigences IEC 62443 SL2 décrites dans cet article.
Combien de temps faut-il pour migrer de TeamViewer à une solution VPN industrielle ?
Sur un parc de moins de 20 sites, la migration peut se faire en 2 à 4 semaines : déploiement parallèle, formation des équipes, basculement progressif. Le point critique est la formation des techniciens au client VPN — prévoir 1 à 2 heures par personne. Le processus est détaillé dans la section 6 de cet article.
Votre organisation utilise actuellement TeamViewer ou un accès VPN classique sur un réseau OT ?
Télécharger le livre blanc cybersécurité OT →
Le document détaille l'architecture cible recommandée, la démarche de migration depuis un accès existant, et les critères d'évaluation d'une solution conforme IEC 62443.
