Lecture seule sur les automates : la segmentation OT/IT expliquée

« Je ne veux pas qu'on touche à mes automates. » C'est l'objection la plus directe qu'on entend en présentant une passerelle industrielle à un responsable de production, et c'est une objection légitime : une ligne de production à l'arrêt coûte plus cher en une heure que n'importe quel gain promis par un tableau de bord.

Deux réponses existent à cette objection. La première est commerciale : « ne vous inquiétez pas ». La seconde est technique, vérifiable, et c'est la seule qui tient la route face à un automaticien qui connaît son installation.

Ce que « lecture seule » veut dire au niveau protocole

« Lecture seule » n'est pas une case cochée dans un menu de configuration. C'est une propriété du protocole utilisé pour chaque lecture :

• En Modbus TCP, la passerelle n'envoie que des requêtes de lecture (codes fonction 01 à 04). Les codes fonction d'écriture (05, 06, 15, 16) ne sont jamais émis, quelle que soit la configuration du point.
• En OPC UA, la session ouverte par la passerelle ne fait que des appels Read, jamais Write.
• En MQTT, la passerelle s'abonne aux messages publiés par l'automate. Elle ne publie rien vers lui.

Cette contrainte n'est pas un réglage qu'on pourrait désactiver par erreur. C'est l'ensemble des opérations que l'agent sait exécuter. L'écriture de registre (« reset faults » sur un automate, par exemple) n'est simplement pas construite dans la passerelle aujourd'hui.

Pour les bus qui ne sont pas nativement parlés par la passerelle aujourd'hui (Profinet, EtherNet/IP, EtherCAT, Profibus), le principe de lecture seule ne change pas de nature : des modules matériels de conversion existent chez le fournisseur de la passerelle pour faire transiter ces bus vers elle. C'est un chantier d'intégration en cours, pas encore disponible sur toutes les configurations — à ne pas confondre avec un canal d'écriture qui contournerait la contrainte décrite ci-dessus.

Une connexion qui ne part jamais du cloud

Le deuxième principe concerne le sens de la connexion. La passerelle initie systématiquement la communication vers le cloud, jamais l'inverse. Concrètement, la passerelle appelle le cloud pour récupérer sa configuration et envoyer ses mesures. Le cloud ne peut initier aucune requête entrante vers la passerelle : aucun port n'est ouvert côté réseau OT pour recevoir une connexion.

Cette asymétrie a une conséquence directe sur les scénarios d'attaque classiques : une intrusion côté cloud ne peut pas se propager vers le réseau OT en passant par un canal que la passerelle n'a jamais ouvert.

Le modèle Purdue, ou pourquoi une DMZ existe

Le modèle de référence pour organiser ce type de séparation s'appelle la Purdue Enterprise Reference Architecture. Il découpe une infrastructure industrielle en niveaux, du terrain (capteurs et actionneurs, niveau 0) jusqu'au système d'information de l'entreprise (niveau 5), avec une zone démilitarisée (DMZ) entre les niveaux industriels et les niveaux IT.

L'idée n'est pas de rendre les deux mondes étanches (les données doivent circuler pour être utiles), mais de garantir qu'aucun flux ne traverse la frontière sans un point de passage identifié et contrôlé. Une passerelle qui ne fait que lire, et qui n'initie sa connexion que vers l'extérieur, occupe exactement ce rôle de point de passage à sens unique.

IEC 62443 : un cadre, pas un label

La norme IEC 62443 encadre la cybersécurité des systèmes d'automatisation industrielle. Sa partie 2-1 décrit ce qu'un programme de sécurité doit couvrir côté exploitant : identification des actifs, gestion des accès, segmentation réseau, surveillance.

Il faut être précis sur ce point : IEC 62443 définit un cadre de bonnes pratiques, pas une certification que Nodal aurait obtenue. Le principe de lecture seule et la segmentation en deux réseaux logiques appliquent des patterns recommandés par cette norme. Ce n'est pas la même chose qu'une certification IEC 62443-4-2 délivrée par un organisme accrédité, et aucune communication de Nodal ne doit laisser entendre le contraire.

Ce que ça change concrètement pour votre parc automate

Deux segments réseau logiques structurent l'installation : un segment OT en lecture seule, où vivent les automates, et une sortie unique vers le cloud. Le point de configuration où cette séparation se joue vraiment est simple à vérifier sur le terrain : la passerelle a-t-elle besoin d'un port entrant ouvert quelque part sur le réseau OT ? La réponse est non. Cette réponse ne dépend d'aucun paramétrage particulier : elle découle directement de la façon dont la passerelle communique.

C'est ce qu'un automaticien peut vérifier lui-même, avec un outil de surveillance réseau, plutôt que de devoir faire confiance à une promesse commerciale.

À l'échelle d'une installation complète, ce même principe de lecture seule s'applique quel que soit le nombre d'automates raccordés : chaque mesure suit le même chemin à sens unique, de l'automate jusqu'aux quatre agents qui l'exploitent ensuite.