Du déballage au Zero Trust en 4 heures : à quoi ressemble réellement un déploiement

Ce que requiert réellement un déploiement Zero-Trust en OT

Quel que soit le fournisseur ou l'architecture choisi, déployer le Zero Trust sur un réseau OT exige quatre choses, dans cet ordre :

1. Découverte des équipements — Un inventaire complet de chaque équipement sur le réseau est nécessaire : PLCs, HMIs, commutateurs, historiens, postes de travail d'ingénierie, et les flux de communication entre eux. On ne peut pas rédiger des politiques d'accès pour des équipements dont on ignore l'existence.

2. Définition des zones — Regrouper les équipements en zones logiques selon leur fonction, leur criticité et leurs besoins de communication. Le modèle zones-et-conduits de l'IEC-62443 est le cadre de référence. Les zones définissent ce qui doit communiquer avec quoi ; tout le reste est refusé par défaut.

3. Création des politiques — Définir les règles d'accès entre les zones : quels protocoles sont autorisés, quels équipements disposent d'un accès inter-zones, et ce qui constitue une violation. Ces politiques doivent refléter les flux de trafic opérationnel réels, et non des schémas réseau théoriques.

4. Application — Appliquer les politiques au trafic en production. Bloquer les flux non autorisés, journaliser les violations et surveiller les faux positifs. C'est là que s'arrêtent les solutions de surveillance seule et que commence la segmentation.

Ces quatre étapes sont identiques que vous utilisiez une pile Claroty/pare-feu, un déploiement Cisco ISE, un fabric Fortinet ou un appliance Access Gate. La méthodologie ne change pas. Ce qui change, c'est la durée de chaque étape et le nombre de produits impliqués.

Ce que représente ce calendrier avec les outils traditionnels

Avec une approche multi-fournisseurs traditionnelle, les quatre étapes ci-dessus correspondent à des cycles d'approvisionnement distincts, des déploiements distincts et des efforts d'intégration distincts :

Le goulot d'étranglement n'est pas une phase en particulier — ce sont les transitions entre les phases. Chaque passage implique un fournisseur différent, un produit différent et souvent une équipe différente. La plateforme de surveillance identifie les flux de trafic, mais ces flux doivent être traduits manuellement en règles de pare-feu. Les règles de pare-feu doivent être testées face au trafic de production. Chaque point d'intégration est un retard potentiel.

Durant ces 4 à 8 mois, le réseau reste non segmenté. La découverte est en cours, mais l'application ne l'est pas.

Ce n'est pas une critique d'un produit spécifique. Claroty, Nozomi et Dragos sont de solides plateformes de surveillance. Le calendrier est une conséquence de l'architecture — des produits distincts pour des fonctions distinctes exigent un travail d'intégration entre eux.

Comment l'Access Gate compresse ce délai à 4 heures

Lorsque la surveillance, la création de politiques et l'application sont intégrées dans un seul appliance, les quatre phases de déploiement s'enchaînent au lieu d'attendre des cycles d'approvisionnement et d'intégration séparés. Voici ce que cela donne en pratique, sur la base d'installations en production, dont le déploiement de référence documenté dans le cadre du partenariat Thales.

Heure 0-1 : Installation physique et configuration initiale

Ce qui se passe :

• Déballage de l'appliance Access Gate
• Montage en rack dans l'armoire réseau (format 1U, rack 19" standard)
• Connexion du port de surveillance à un port SPAN/miroir d'un commutateur (cela donne à l'appliance une visibilité passive sur le trafic réseau)
• Connexion du port de gestion à un VLAN de gestion ou directement à un ordinateur portable
• Mise sous tension

Ce que voit l'opérateur :

L'appliance démarre en moins de 3 minutes. Une console web est accessible à l'adresse IP de gestion. L'assistant de configuration initiale guide à travers les étapes suivantes :

1. Définir les identifiants administrateur
2. Configurer les interfaces réseau (IP de gestion, interface de surveillance)
3. Définir le fuseau horaire et la source NTP (ou l'heure manuelle en mode air-gapped)
4. Nommer le site

Aucun agent à installer. Aucun compte cloud à créer. Aucun serveur de licences à contacter. L'appliance valide sa licence localement.

À la fin de l'heure 1 : L'appliance est physiquement installée, alimentée, connectée au réseau et accessible via sa console de gestion.

Heure 1-2 : Découverte du réseau

Ce qui se passe :

• Activation de la découverte passive sur l'interface de surveillance
• L'appliance écoute tout le trafic sur le port SPAN
• Les équipements sont identifiés par adresse MAC, adresse IP, nom d'hôte (si disponible) et empreinte de protocole
• Les flux de communication entre équipements sont cartographiés automatiquement

Ce que voit l'opérateur :

L'inventaire des actifs se remplit en temps réel. En 15 à 30 minutes, l'appliance a identifié la plupart des équipements actifs sur le réseau. Le tableau de bord affiche :

• La liste des équipements avec IP, MAC, fabricant (depuis la base de données OUI) et protocoles détectés
• Une carte réseau montrant quels équipements communiquent avec quels autres
• La répartition des protocoles — quel pourcentage du trafic est Modbus TCP, EtherNet/IP, OPC UA, HTTP, etc.
• Le trafic non reconnu ou anormal signalé pour examen

Remarque : Certains équipements ne communiquent que sur de longs intervalles d'interrogation (par exemple, sauvegardes quotidiennes de l'historien, vérifications hebdomadaires de firmware). L'appliance poursuit la découverte en arrière-plan et ajoute les équipements nouvellement détectés à l'inventaire au fil des jours suivants.

À la fin de l'heure 2 : L'opérateur dispose d'une vue complète de ce qui est présent sur le réseau, de ce qui communique avec quoi, et des protocoles utilisés. C'est l'inventaire des actifs que la plupart des organisations mettent des semaines à construire manuellement.

Heure 2-3 : Création des politiques et définition des zones

Ce qui se passe :

• Définition des zones réseau sur la base de la topologie découverte (par exemple, « Zone PLC », « Zone HMI », « Postes de travail d'ingénierie », « DMZ IT »)
• Affectation des équipements aux zones — par glisser-déposer dans la console ou affectation automatique par sous-réseau
• Définition des règles d'accès entre les zones :
  • Quelles zones peuvent communiquer avec quelles autres
  • Quels protocoles sont autorisés par paire de zones
  • Quels équipements disposent d'un accès inter-zones (par exemple, l'historien qui lit depuis la zone PLC)
• Configuration de la segmentation par overlay — l'appliance crée des segments réseau logiques sans nécessiter de modifications physiques du réseau

Ce que voit l'opérateur :

L'éditeur de politiques présente les flux de communication découverts comme référence. L'opérateur décide quels flux sont légitimes et doivent être autorisés, et lesquels doivent être bloqués. Pour un réseau de 50 équipements, cela implique généralement :

• 4 à 8 définitions de zones
• 10 à 20 règles d'accès inter-zones
• 5 à 10 exceptions spécifiques à des équipements

L'appliance suggère des politiques basées sur les flux de trafic observés. L'opérateur examine et approuve. Il ne s'agit pas d'une politique auto-générée fonctionnant sans supervision — l'opérateur prend chaque décision, mais l'appliance fait le gros du travail en identifiant ce qui doit être décidé.

À la fin de l'heure 3 : Les définitions de zones et les politiques d'accès sont configurées. L'appliance sait quel trafic doit exister sur le réseau et lequel ne le doit pas.

Heure 3-4 : Application et vérification

Ce qui se passe :

• Passage du mode surveillance au mode application
• L'appliance commence à appliquer activement les politiques définies
• Les flux de trafic légitimes s'écoulent sans interruption
• Le trafic inter-zones non autorisé est bloqué et journalisé
• L'opérateur surveille le tableau de bord pour détecter les faux positifs — trafic légitime incorrectement bloqué

Ce que voit l'opérateur :

Le tableau de bord d'application affiche :

• Flux autorisés — trafic correspondant à une règle de politique, s'écoulant normalement
• Flux bloqués — trafic violant une règle de politique, abandonné avec une entrée de journal
• Alertes — faux positifs potentiels signalés pour examen par l'opérateur

En pratique, les 30 premières minutes d'application nécessitent une surveillance active. L'opérateur surveille les flux bloqués qui devraient être autorisés et ajoute des exceptions au besoin. Après ce réglage initial, l'application fonctionne de manière autonome.

À la fin de l'heure 4 : Le réseau est segmenté, les politiques d'accès sont appliquées et la piste d'audit est en cours. Le Zero Trust est opérationnel.

Ce qui se passe après l'heure 4

Le déploiement n'est pas la fin. Voici à quoi ressemble l'exploitation continue :

Jour 2

• Examiner les journaux de la nuit pour tout trafic bloqué qui n'aurait pas dû l'être (équipements avec des schémas de communication peu fréquents)
• Ajouter 1 à 3 exceptions de politique supplémentaires sur la base de l'activité nocturne
• Vérifier que tous les processus de production se sont déroulés normalement lors du premier changement d'équipe

Semaine 1

• La découverte a désormais capturé plus de 99 % des équipements, y compris ceux avec de longs intervalles d'interrogation
• Examiner l'inventaire complet des actifs et signaler tout équipement inconnu ou non autorisé
• Affiner les limites des zones si la découverte a révélé des schémas de communication inattendus
• Générer un rapport de conformité pour vérifier la correspondance des contrôles avec le cadre cible (CMMC, NIS2, IEC-62443)

Mois 1

• Le système est en exploitation stable
• Examiner les journaux d'audit mensuels et les exporter pour la documentation de conformité
• Tester la politique face à un scénario simulé de mouvement latéral
• Documenter le déploiement pour l'auditeur de conformité
• Charge de gestion continue : 2 à 4 heures par semaine pour un réseau de 50 équipements

La méthodologie, en résumé

Que le déploiement prenne 4 heures ou 4 mois, la méthodologie sous-jacente est la même :

1. Découvrir tout ce qui est sur le réseau
2. Définir les zones selon la fonction et le risque
3. Créer les politiques sur la base du trafic observé
4. Appliquer et ajuster

L'approche traditionnelle étale ces étapes sur des mois parce que chacune implique un produit différent et un effort d'intégration différent. Un appliance intégré les enchaîne parce qu'il n'y a pas de transitions.

La différence de rapidité est architecturale, pas magique. Si votre déploiement nécessite une inspection approfondie des protocoles, une orchestration multi-sites ou une intégration avec une pile SIEM/SOAR existante, le calendrier sera plus long quel que soit le produit choisi. Le calendrier de 4 heures s'applique aux déploiements sur site unique où l'objectif est la surveillance et l'application avec un seul appliance.

Pour les organisations disposant de plusieurs sites, consultez la façon dont ce même modèle de déploiement s'adapte dans notre guide sur la sécurité OT multi-sites sur plus de 50 sites. Pour une comparaison de l'approche de segmentation par overlay face aux VLANs traditionnels, lisez overlay networking vs VLANs pour la segmentation OT. Si vous disposez d'une armoire réseau, d'un port SPAN et d'un après-midi, votre réseau OT peut être segmenté et sécurisé avant la fin de la journée.

Pour plus de ressources Zero Trust OT, des guides d'architecture et des comparaisons, visitez le hub Zero Trust pour les réseaux OT.