A-t-il fallu remplacer les automates et IHM existants ?

Non. Les automates et IHM hérités sont restés inchangés — l'évaluation passive et le zonage selon le modèle de Purdue ont été conçus précisément pour des équipements incapables d'exécuter des agents modernes ou de supporter un scan actif. Tout le changement s'est fait au niveau réseau, avec des pare-feu, des bastions et des diodes de données assurant l'isolation sans toucher aux terminaux.

Comment les prestataires conservent-ils un accès distant sans les anciens routeurs VPN ?

Chaque connexion prestataire a été redirigée vers un bastion unique audité et une DMZ dédiée, avec des identifiants limités dans le temps et journalisés à chaque session, au lieu de routeurs laissés branchés en permanence. Les prestataires conservent l'accès nécessaire au support et aux mises à jour de firmware, mais chaque session est désormais visible, limitée dans le temps et révocable.

Quel était le plus grand risque pendant la bascule, et comment a-t-il été géré ?

Le plus grand risque était un arrêt de ligne imprévu pendant les changements de segmentation, un arrêt même court représentant un vrai risque de chiffre d'affaires et de pénalités. Chaque changement a été séquencé dans des fenêtres de maintenance planifiées avec un plan de retour arrière testé, et des captures Wireshark avant et après chaque bascule ont confirmé l'absence de latence ou de perte de paquets inattendue sur le trafic de commande.

Le pipeline de télémétrie de maintenance prédictive crée-t-il un nouveau chemin vers le plan de commande ?

Non — c'était la contrainte centrale que la conception devait respecter. La télémétrie remonte vers Azure IoT Hub via des diodes de données et des ruptures de protocole physiquement ou logiquement à sens unique, permettant aux données d'analyse de sortir de l'environnement OT sans jamais ouvrir de chemin entrant correspondant.

Retour aux études de cas

Industrie et fabricationRéseau et cloudPare-feu nouvelle génération

Edge industriel et sécurité OT

Segmenter des réseaux d'usine historiquement plats en zones défendables, tout en livrant la télémétrie de maintenance prédictive attendue par les équipes métier — sans jamais ouvrir de chemin entre le réseau bureautique et les automates de production.

Disponibilité de production préservée avec des frontières OT/IT plus claires

Client

Confidentiel — fabrication discrète

Secteur

Industrie et fabrication

Calendrier

6 mois

Technologies

6+ outils

Le défi

!Le réseau de l'usine s'était construit de façon organique sur près de vingt ans, si bien qu'IHM, automates (PLC), historiens et ordinateurs portables d'entreprise cohabitaient sur le même VLAN plat, sans contrôle d'accès réel entre eux. Un simple poste bureautique compromis pouvait en théorie atteindre directement les contrôleurs de ligne.

!Plusieurs fournisseurs d'équipements exigeaient un accès distant à leurs skids et cellules pour le support et les mises à jour de firmware, mais chacun se connectait différemment — certains via des routeurs VPN grand public laissés branchés en permanence, d'autres via des outils de bureau à distance installés à la volée par les techniciens de ligne.

!Les équipes d'exploitation voulaient des analyses de maintenance prédictive et souhaitaient faire remonter la télémétrie des automates et capteurs vers un historien cloud, mais la sécurité n'avait aucun moyen de garantir qu'ouvrir ce flux n'ouvrirait pas aussi une voie de retour vers le plan de commande.

!Les automates et IHM hérités présents sur le terrain ne pouvaient ni exécuter d'agents de sécurité modernes, ni être patchés selon un cycle normal, ni tolérer un scan de vulnérabilités actif, un paquet perdu ou un pic de latence induit par un scan risquant d'arrêter une ligne de production.

!L'IT usine et la sécurité corporate n'avaient jamais partagé de vision commune de ce à quoi ressemblait un trafic OT normal, si bien qu'aucune base de référence n'existait pour détecter les anomalies, et toute proposition de supervision risquait de noyer l'exploitation sous les faux positifs.

!Les audits d'assurance et de clients posaient des questions de plus en plus précises sur la segmentation réseau, la détection d'incidents et le contrôle des accès prestataires, et le client ne disposait d'aucune architecture documentée ni preuve à présenter aux auditeurs, hormis des schémas informels.

!La direction de l'usine restait légitimement réticente à tout changement sur le réseau de production, car même un arrêt imprévu de courte durée sur une ligne représentait un vrai risque de chiffre d'affaires et de pénalités contractuelles, ce qui transformait chaque changement proposé en négociation.

!Il n'existait aucune journalisation ni alerte centralisée pour les événements liés à l'OT, si bien que les incidents sur le terrain étaient généralement découverts parce qu'un opérateur remarquait quelque chose d'anormal sur une IHM plutôt que par une télémétrie de sécurité.

Notre solution

Réalisation d'une évaluation réseau passive via des captures sur ports miroir et la découverte adaptée à l'OT de Claroty, afin de bâtir un inventaire d'actifs fiable et une cartographie du trafic sans toucher à un seul équipement, établissant une vérité de terrain avant toute conception.

Conception de zones et conduits alignés sur le modèle de Purdue, regroupant cellules et lignes par criticité et fonction, avec des conduits explicitement autorisés entre zones plutôt qu'un réseau plat implicitement fiable.

Déploiement de pare-feu industriels Palo Alto Networks aux frontières des zones et entre cellules de production pour une inspection est-ouest, remplaçant les routeurs VPN prestataires informels par un schéma unique de bastion audité et une DMZ prestataires dédiée avec identifiants limités dans le temps.

Construction d'un chemin de télémétrie à sens majoritairement unique entre capteurs OT, historiens et Azure IoT Hub, à l'aide de diodes de données et de ruptures de protocole lorsque les équipements le permettaient, pour que les données d'analyse sortent sans ouvrir de chemin retour correspondant.

Mise en place de tableaux de bord Grafana alimentés par le nouveau pipeline de télémétrie, donnant à l'exploitation et à la sécurité une même vue en direct des schémas de trafic de l'usine, ce qui a permis aux deux équipes de définir ensemble la normalité avant de traiter les écarts comme des alertes.

Utilisation d'Ansible pour coder et versionner les jeux de règles de pare-feu et les configurations des bastions, remplaçant des changements manuels non documentés par un processus reproductible et auditable que l'IT usine pouvait valider avant chaque fenêtre de déploiement.

Séquencement de chaque changement dans des fenêtres de maintenance planifiées avec un plan de retour arrière testé à chaque étape, et utilisation de captures Wireshark pendant et après chaque bascule pour confirmer l'absence de latence ou de perte de paquets inattendue sur le trafic de commande.

Organisation d'exercices de crise avec les directions usine et IT simulant une compromission d'identifiants prestataire et une tentative de mouvement latéral de type rançongiciel, ce qui a révélé des lacunes dans le playbook de réponse à incident et créé des réflexes partagés avant la mise en production.

Impact mesurable

Segmentation

12 zones, 100 % des chemins inter-zones surveillés

Les cellules de production critiques sont regroupées en 12 zones alignées sur le modèle de Purdue, isolées derrière des conduits explicitement autorisés au lieu d'un réseau plat, avec chaque chemin inter-zones surveillé.

Accès distant prestataires

100 % des sessions prestataires médiées, zéro routeur VPN permanent

Toute connectivité prestataire passe désormais par un bastion unique et une DMZ, avec des identifiants limités dans le temps et journalisés, remplaçant le parc précédent de routeurs VPN improvisés laissés branchés en permanence.

Pipeline de télémétrie

100 % à sens unique via diodes de données

Les données de maintenance prédictive atteignent l'historien cloud via des conduits protégés par diodes, sans aucun chemin entrant correspondant vers le plan de commande.

Visibilité partagée

Délai de tri des anomalies réduit d'environ 60 %

Exploitation et sécurité travaillent désormais depuis la même vue Grafana du trafic OT normal, réduisant le délai de tri des anomalies terrain de plusieurs heures à moins de 30 minutes dans la plupart des cas.

Disponibilité de production

Zéro arrêt imprévu sur 6 mois

Chaque bascule a été séquencée dans des fenêtres de maintenance avec des retours arrière testés, sans qu'aucun changement ne provoque d'arrêt de ligne imprévu sur les 6 mois de la mission.

Conformité et audits

Dossier d'architecture complet livré en moins de 2 semaines

Le client peut désormais présenter aux auditeurs et assureurs un modèle de segmentation défendable et schématisé, appuyé par des preuves journalisées, assemblé en moins de 2 semaines contre des descriptions informelles auparavant.

Réponse à incident

2 exercices de crise, lacunes du playbook comblées

Deux exercices de crise simulant une compromission d'identifiants prestataire et un mouvement latéral ont produit un playbook OT actualisé, sur lequel les directions usine et IT se sont toutes deux entraînées.

“Il nous fallait moderniser sans parier la ligne. La conception a respecté les contraintes OT à chaque étape et nous a quand même menés vers une architecture défendable, que nous pouvons montrer à un auditeur sans trembler. Les exercices de crise, à eux seuls, ont changé la façon dont l'usine et l'IT communiquent pendant un incident.”
D
Directeur IT usine
Directeur IT fabrication (NDA)

Stack technologique

Palo Alto NetworksClarotyAzure IoT HubGrafanaAnsibleWireshark (évaluations)