Cybersécurité automates zero-trust : protéger les réseaux OT industriels

Le modèle zero trust appliqué aux réseaux OT industriels consiste à ne faire confiance à aucun accès par défaut, même lorsqu’il provient d’un technicien, d’un prestataire, d’un poste interne ou d’un réseau déjà connecté au site. Chaque connexion vers un automate, un SCADA, une IHM ou une passerelle industrielle doit être authentifiée, autorisée, limitée, journalisée et révocable. Pour les environnements Siemens, Schneider, Rockwell ou multi-constructeurs, cette approche réduit l’exposition des automates sans bloquer les besoins de maintenance et de supervision.

Le problème

Le modèle de sécurité traditionnel repose souvent sur un périmètre : un firewall protège l’entrée, puis les équipements situés à l’intérieur du réseau sont considérés comme relativement fiables. Dans les réseaux OT industriels, cette logique est fragile. Les automates ne peuvent pas toujours être mis à jour rapidement, certains protocoles industriels n’intègrent pas d’authentification forte native, les postes d’ingénierie sont critiques, et l’air gap historique a souvent disparu avec la supervision à distance, la télémaintenance, l’IIoT et les échanges avec le cloud.

Les risques les plus fréquents sont connus des équipes terrain.

• Un VPN générique partagé peut exposer trop largement le réseau OT si un compte, un poste ou un fichier de configuration est compromis.

• Les protocoles industriels comme Modbus/TCP, EtherNet/IP ou certains usages PROFINET peuvent transporter des commandes ou données sans chiffrement applicatif suffisant selon les configurations.

• Les accès prestataires restent parfois ouverts en permanence, sans fenêtre de maintenance, sans restriction précise et sans revue régulière.

• Les réseaux OT plats permettent à un équipement peu critique de communiquer avec des automates de production ou des serveurs SCADA sensibles.

• Les automates et IHM anciens peuvent dépendre de versions logicielles figées, ce qui impose de compenser par le réseau, la segmentation et la surveillance.

• Les journaux d’accès sont incomplets : il devient difficile de savoir quel utilisateur s’est connecté, quand, depuis où et vers quel équipement.

• Les mots de passe par défaut ou partagés existent encore sur certains équipements industriels, notamment lorsque l’inventaire et les procédures de changement ne sont pas maîtrisés.

• Les données de production, recettes, paramètres process et états machine peuvent circuler sans contrôle suffisant entre zones.

• Les exigences NIS2 et les principes IEC 62443 renforcent la nécessité de documenter, limiter, tracer et auditer les accès aux systèmes industriels.

Le zero trust ne consiste pas à bloquer l’OT. Il consiste à supprimer les accès implicites et à les remplacer par des droits explicites, contextualisés et vérifiables.

Pourquoi le zero trust est adapté aux réseaux OT

Dans l’IT, le zero trust est souvent associé à l’identité utilisateur, au poste de travail et aux applications SaaS. En OT, il doit être adapté aux contraintes industrielles : disponibilité, sûreté, cycles longs, protocoles historiques, équipements difficiles à patcher et interventions de prestataires.

L’idée centrale reste la même : ne jamais considérer qu’un utilisateur ou un équipement est fiable uniquement parce qu’il est “dans le bon réseau”.

Principe zero trust	Application OT concrète	Exemple
Vérifier explicitement	Authentifier chaque accès distant	Compte nominatif et MFA pour un technicien
Moindre privilège	Limiter aux équipements nécessaires	Accès à une CPU Siemens, pas à tout le VLAN
Segmentation	Isoler les zones et conduits	Ligne 1 séparée de la ligne 2
Supervision continue	Journaliser et alerter	Connexion prestataire hors plage horaire
Révocation rapide	Couper un droit immédiatement	Désactivation d’un certificat compromis
Résilience	Maintenir l’exploitation locale	L’automate reste pilotable sur site

Cette approche est particulièrement utile lorsque plusieurs acteurs interviennent sur les mêmes systèmes : équipes maintenance internes, automaticiens, constructeurs de machines, intégrateurs, éditeurs SCADA, opérateurs télécom et sous-traitants.

Architecture zero trust pour automates et SCADA

Une architecture zero trust OT repose sur des zones, des conduits et un point de contrôle entre les utilisateurs distants et les équipements industriels. La gateway ne doit pas être un simple tunnel transparent : elle doit appliquer des règles d’accès, journaliser les sessions et permettre une révocation rapide.

Le réseau OT conserve ses fonctions locales. Les automates, IHM et SCADA continuent de fonctionner sur site, mais les accès externes sont filtrés, tracés et limités à un besoin précis.

Notre approche

Eziwan implémente une approche zero trust pour les réseaux OT en combinant identité, tunnels sécurisés, règles par équipement, segmentation, fenêtres temporelles, supervision et logs d’audit. L’objectif est de remplacer les accès permanents et partagés par des accès nominaux, limités, observables et révocables.

• Identité par accès : chaque technicien ou prestataire dispose de ses propres identifiants, certificats ou droits d’accès, sans compte VPN partagé.

• Accès au moindre privilège : chaque utilisateur accède uniquement aux équipements nécessaires à sa mission.

• Fenêtres temporelles : les accès prestataires peuvent expirer automatiquement après la période de maintenance autorisée.

• Micro-segmentation réseau : les sites, lignes ou zones OT sont isolés par défaut, avec des règles explicites entre périmètres.

• Logs d’audit en temps réel : les connexions, refus, durées de session, ressources atteintes et événements de sécurité sont enregistrés.

• Détection d’anomalies : alertes sur les connexions hors plage horaire, tentatives non autorisées ou comportements inhabituels.

• Isolation rapide : un utilisateur, une règle ou un équipement peut être isolé sans déplacement terrain lorsque l’architecture le permet.

• Gestion des mots de passe OT : inventaire des équipements sensibles, identification des accès faibles et workflow de mise à jour contrôlée.

• Chiffrement des flux distants : les protocoles OT non chiffrés peuvent être encapsulés dans un tunnel sécurisé entre l’utilisateur autorisé et le point d’accès industriel.

• Procédures de réponse à incident : modèles de confinement, révocation, journalisation et reprise pour réduire l’improvisation en situation de crise.

Cette approche s’intègre avec une gateway Eziwan, la supervision via le cloud Eziwan et les architectures de connectivité industrielle.

Fonctionnalités clés

VPN individualisé par utilisateur

Chaque technicien et prestataire doit disposer de son propre accès. Un certificat, une configuration ou un compte nominatif permet de savoir qui se connecte et de révoquer un utilisateur sans impacter les autres.

Le bénéfice est immédiat : si un accès est compromis, il peut être désactivé individuellement. Les autres techniciens conservent leurs droits, et l’enquête peut s’appuyer sur une identité claire.

Contrôle d’accès basé sur le rôle pour l’OT

Le RBAC, ou contrôle d’accès basé sur les rôles, doit être adapté aux réalités industrielles. Un opérateur, un automaticien interne, un intégrateur Siemens, un prestataire Schneider ou un support Rockwell n’ont pas besoin du même périmètre.

Exemples de rôles possibles :

• Opérateur : consultation d’états ou accès à une interface limitée.

• Technicien maintenance : diagnostic et supervision d’une zone.

• Automaticien : accès aux automates et outils d’ingénierie autorisés.

• Prestataire constructeur : accès temporaire aux machines de sa responsabilité.

• Administrateur OT : gestion des règles, utilisateurs et audits.

Le rôle ne doit pas ouvrir un réseau entier par confort. Il doit décrire un besoin réel : site, zone, équipement, protocole, durée et niveau d’action.

Fenêtres de maintenance temporaires

Les accès permanents sont l’un des points faibles des réseaux OT. Une fenêtre temporelle permet d’autoriser un prestataire pour quatre heures, une journée ou une période planifiée, puis de fermer automatiquement l’accès.

Ce mécanisme réduit les oublis de révocation. Il donne aussi une preuve claire : la connexion était autorisée dans un créneau précis, pour une intervention identifiée.

Micro-segmentation réseau OT

La micro-segmentation consiste à découper le réseau en périmètres plus petits et plus maîtrisables. Elle limite la propagation d’un incident et réduit les chemins inutiles vers les équipements critiques.

Le technicien du site A ne doit pas pouvoir atteindre le site B simplement parce qu’il est connecté au même concentrateur VPN. La segmentation doit être appliquée dans le réseau, pas seulement dans une application.

Logs d’audit pour conformité NIS2 et IEC 62443

Les logs sont indispensables pour démontrer la maîtrise des accès. Ils servent à l’exploitation, à l’audit, à l’analyse d’incident et à la conformité interne.

Un log utile doit contenir au minimum :

• Identité de l’utilisateur.

• Organisation ou rôle associé.

• Heure de début et de fin de session.

• Adresse IP source et destination OT.

• Équipement ou zone atteinte.

• Règle d’accès appliquée.

• Tentatives refusées.

• Modification de droits ou révocation.

• Événements de connexion inhabituels.

Il faut rester précis sur la portée : une gateway réseau peut journaliser les connexions, flux et règles appliquées. La traçabilité détaillée des modifications internes à un automate dépend aussi des outils d’ingénierie, des journaux de l’équipement et des procédures de changement.

Alertes en temps réel sur les anomalies

Le zero trust n’est pas seulement un contrôle à l’entrée. Il doit produire des signaux lorsque quelque chose s’écarte du comportement attendu.

Exemples d’alertes pertinentes :

• Connexion hors plage horaire.

• Tentative d’accès à un automate non autorisé.

• Échec répété d’authentification.

• Connexion depuis une origine inhabituelle.

• Volume de trafic anormal vers une zone OT.

• Utilisation d’un compte prestataire hors intervention planifiée.

• Changement de règle critique.

Ces alertes peuvent être transmises par email, webhook, supervision, SIEM ou outil de ticketing selon l’organisation.

Isolation d’urgence

Lorsqu’un comportement suspect est détecté, l’équipe doit pouvoir agir vite. L’isolation d’urgence peut consister à désactiver un compte, retirer un certificat, couper une règle d’accès, isoler une gateway ou bloquer un flux vers une zone donnée.

L’objectif n’est pas de couper l’usine au premier doute. Il s’agit de disposer d’actions graduées, documentées et réversibles.

Intégration SIEM et SOAR

Les événements Eziwan peuvent alimenter un SIEM ou une supervision de sécurité afin d’être corrélés avec d’autres signaux : annuaire, EDR, firewall, logs Windows, événements SCADA, alertes réseau ou tickets d’intervention.

Cette intégration aide le SOC à distinguer une intervention normale d’un comportement suspect. Elle permet aussi de déclencher des playbooks SOAR lorsque l’organisation les utilise : enrichissement d’alerte, notification, ouverture de ticket, révocation d’accès ou demande de validation.

Exemple de politique d’accès zero trust OT

Une politique zero trust doit être lisible par les équipes OT et IT. Elle doit éviter les règles implicites et décrire clairement les droits.

profils:
  automaticien_interne:
    authentification:
      mfa: obligatoire
      compte: nominatif
    ressources:
      - site: usine_nord
        zone: ligne_1
        equipements:
          - automate_s7_1500
          - ihm_ligne_1
        protocoles:
          - tia_portal
          - https
    horaires:
      autorise: heures_ouvrées
    journalisation: obligatoire

  prestataire_machine:
    authentification:
      mfa: obligatoire
      certificat: individuel
    ressources:
      - site: usine_nord
        zone: cellule_robotisee
        equipements:
          - plc_compactlogix
          - ihm_panelview
    fenetre_maintenance:
      debut: "2026-06-25T08:00:00+02:00"
      fin: "2026-06-25T12:00:00+02:00"
    journalisation: obligatoire
    expiration: automatique

Cette formalisation évite les accès trop larges. Elle facilite aussi l’audit, car chaque droit est rattaché à une justification opérationnelle.

Protocoles industriels : limites et mesures compensatoires

Le zero trust OT doit tenir compte des protocoles réellement utilisés. Certains protocoles industriels ont été conçus pour des réseaux fermés, avec peu ou pas de mécanismes natifs d’authentification et de chiffrement. D’autres disposent de variantes ou configurations plus sécurisées, mais elles ne sont pas toujours disponibles sur les équipements existants.

Protocole ou usage	Risque courant	Mesure compensatoire
Modbus/TCP	Commandes possibles si accès réseau autorisé	Filtrage par IP, tunnel chiffré, segmentation
EtherNet/IP	Découverte et accès larges selon topologie	Chemins explicites, règles par équipement
PROFINET	Sensible à la topologie et aux flux locaux	Isolation de zone, accès ingénierie contrôlé
OPC UA	Sécurité dépendante des certificats et politiques	Certificats, chiffrement, gestion des comptes
Interfaces web IHM	Mots de passe faibles ou anciens	MFA en amont, filtrage, changement contrôlé
RDP ou VNC	Cible fréquente si exposé	Pas d’exposition Internet, accès via gateway

Lorsqu’un automate ne peut pas être durci directement, la sécurité doit être renforcée autour de lui : segmentation, filtrage, identité, supervision, inventaire et procédures de changement.

Zero trust, NIS2 et IEC 62443

NIS2 et IEC 62443 ne sont pas des synonymes du zero trust, mais leurs exigences convergent sur plusieurs points : gestion du risque, contrôle des accès, segmentation, journalisation, gestion des incidents, continuité et gouvernance.

Une architecture zero trust OT peut contribuer à ces objectifs.

Exigence	Apport d’une approche zero trust OT
Gestion des accès	Comptes nominatifs, MFA, révocation
Moindre privilège	Droits limités par équipement et durée
Segmentation	Zones OT isolées, conduits contrôlés
Traçabilité	Logs de connexion, refus et changements
Gestion fournisseurs	Accès prestataires temporaires et auditables
Réponse à incident	Isolation rapide, preuves et procédures
Continuité	Accès contrôlé sans exposition directe

La conformité ne peut pas être déclarée uniquement grâce à un outil. Elle dépend de l’architecture complète, des procédures, des preuves d’exploitation et de la gouvernance. Eziwan apporte des briques techniques utiles pour rendre ces exigences concrètes.

Cycle d’une connexion zero trust

Une connexion zero trust vers un équipement OT suit une séquence explicite : demande, authentification, vérification du contexte, autorisation, journalisation, accès limité, surveillance et fermeture.

Cette séquence rend l’accès explicable et vérifiable. Elle évite le modèle où un VPN ouvert donne accès à tout un réseau sans contexte.

Gestion des mots de passe OT

Les mots de passe par défaut, partagés ou jamais renouvelés restent un problème courant dans les environnements industriels. Le changement doit toutefois être planifié avec prudence : certains équipements sont anciens, certains comptes sont utilisés par des applications, et une modification non testée peut provoquer une interruption.

Une démarche réaliste comprend :

• Inventaire des équipements avec authentification locale.

• Identification des comptes par défaut ou partagés.

• Classification par criticité.

• Test de changement sur un équipement non critique ou en fenêtre de maintenance.

• Documentation des dépendances applicatives.

• Stockage sécurisé des secrets.

• Suppression des comptes inutiles.

• Revue périodique des accès prestataires.

Le zero trust réduit la dépendance aux mots de passe locaux en plaçant un contrôle fort en amont, mais il ne dispense pas de traiter les comptes faibles sur les équipements eux-mêmes.

Réponse à incident OT

En cas de suspicion de compromission, les équipes doivent savoir quoi faire avant la crise. Le plan de réponse à incident OT doit être simple, opérationnel et adapté aux contraintes de production.

Les premières actions doivent préserver la sécurité des personnes et la continuité locale. Dans l’OT, isoler un équipement ne signifie pas toujours l’arrêter. Il faut distinguer la coupure d’un accès distant, l’isolement réseau, le passage en mode local et l’arrêt de production.

Bonnes pratiques de déploiement

Un projet zero trust OT doit être progressif. Il est préférable de commencer par les accès les plus exposés, puis d’étendre la segmentation et les règles.

• Cartographier les sites, zones, automates, IHM, SCADA, postes d’ingénierie et accès existants.

• Identifier les prestataires et constructeurs qui disposent d’un accès distant.

• Supprimer les comptes partagés dès que possible.

• Mettre en place des comptes nominatifs et une authentification forte.

• Définir les zones OT et les conduits autorisés.

• Limiter les règles par équipement, protocole et durée.

• Journaliser les accès et refus.

• Tester les outils métiers réels : TIA Portal, Control Expert, Studio 5000, OPC UA, interfaces web.

• Mettre en place des alertes actionnables.

• Documenter les procédures de révocation et d’urgence.

• Revoir les droits régulièrement.

Cette trajectoire permet d’améliorer rapidement la sécurité sans imposer une refonte brutale du réseau industriel.

Erreurs fréquentes à éviter

Confondre VPN et zero trust

Un VPN chiffre un tunnel, mais il ne garantit pas le moindre privilège. Si le VPN donne accès à tout le réseau OT, il ne résout pas le problème de fond. Le zero trust impose des règles précises par utilisateur, équipement, protocole et contexte.

Segmenter uniquement sur le papier

Un schéma réseau ne suffit pas. La segmentation doit être appliquée par des règles techniques, testée, documentée et surveillée. Il faut vérifier qu’un utilisateur non autorisé ne peut pas atteindre une zone interdite.

Oublier les prestataires

Les prestataires disposent souvent d’accès sensibles, parfois maintenus pendant des années. Ils doivent être intégrés au même modèle que les équipes internes : compte nominatif, MFA, fenêtre temporelle, périmètre limité et logs.

Chercher la perfection avant d’agir

Le zero trust complet peut prendre du temps. Il vaut mieux commencer par supprimer les accès partagés, fermer les accès permanents inutiles et journaliser les connexions critiques que retarder toute action en attendant une architecture idéale.

Négliger les tests métier

Une règle trop stricte peut bloquer un outil d’ingénierie ou une supervision. Chaque règle doit être testée avec les applications réelles, dans une fenêtre maîtrisée, avec les équipes concernées.

Checklist de maturité zero trust OT

Domaine	Question	Priorité
Inventaire	Les automates, IHM, SCADA et accès distants sont-ils recensés ?	Haute
Identité	Chaque utilisateur dispose-t-il d’un compte nominatif ?	Haute
MFA	L’authentification forte est-elle activée pour l’accès distant ?	Haute
Moindre privilège	Les droits sont-ils limités aux équipements nécessaires ?	Haute
Prestataires	Les accès externes expirent-ils automatiquement ?	Haute
Segmentation	Les zones OT sont-elles isolées par défaut ?	Haute
Logs	Les connexions et refus sont-ils journalisés ?	Haute
Alertes	Les anomalies génèrent-elles des notifications exploitables ?	Moyenne
Révocation	Un accès peut-il être coupé rapidement ?	Haute
Incident	Une procédure de confinement OT existe-t-elle ?	Haute
Audit	Les preuves sont-elles exportables pour contrôle ?	Moyenne

Cette checklist donne un point de départ pragmatique pour évaluer la situation d’un site et prioriser les actions.

Comment Eziwan aide à protéger les automates industriels

Eziwan apporte un point de contrôle entre les utilisateurs distants et les réseaux OT. La solution aide à remplacer les accès implicites par des accès explicites, pilotés et tracés.

Besoin OT	Réponse Eziwan	Bénéfice
Accès distant sécurisé	Tunnels chiffrés et comptes nominatifs	Moins d’accès partagés
Moindre privilège	Règles par équipement ou zone	Réduction de la surface d’attaque
Prestataires	Fenêtres temporelles et révocation	Fin des accès permanents oubliés
Segmentation	Gateway entre zones et conduits	Isolation des périmètres critiques
Audit	Logs de session et événements	Preuves pour enquête et conformité
Incident	Désactivation rapide des accès	Confinement plus simple
Supervision	Alertes et intégration SIEM	Détection plus rapide
Continuité	Architecture contrôlée	Maintenance distante sans exposition directe

Cette approche permet aux industriels de renforcer la sécurité des automates, SCADA et équipements OT sans renoncer à la maintenance à distance.

Conclusion

La cybersécurité zero trust des automates industriels n’est pas un slogan : c’est une méthode concrète pour limiter les accès, réduire les privilèges, segmenter les réseaux, tracer les connexions et réagir plus vite en cas d’incident. Dans les réseaux OT, où les équipements ne peuvent pas toujours être patchés rapidement et où la disponibilité reste prioritaire, cette approche apporte une protection réaliste et progressive.

Eziwan aide à mettre en œuvre ce modèle avec des accès nominatifs, des tunnels sécurisés, des règles par équipement, des fenêtres de maintenance, des logs d’audit, des alertes et une isolation rapide. Pour les industriels soumis à des exigences NIS2, IEC 62443 ou à des contraintes internes de cybersécurité, c’est une façon pragmatique de transformer les principes zero trust en contrôles opérationnels sur le terrain.

Pour aller plus loin

• Cybersécurité industrielle — les fondamentaux de la sécurité OT et les bonnes pratiques terrain
• VPN classique vs accès distant industriel — pourquoi le zero trust surpasse le VPN traditionnel en milieu OT
• Accès distant industriel — implémentez un accès distant sans exposition de ports publics
• NIS2 industrie — alignez votre stratégie zero trust avec les obligations NIS2
• Cybersécurité accès distant OT — sécurisez spécifiquement les accès distants à vos réseaux OT