Sécurité IT/OT convergente avec une architecture de confiance zéro
Dernière mise à jour : 12 oct.
Un ingénieur doit consulter une alarme IHM depuis un poste administré. Le fait que ce poste soit connecté au réseau de l'entreprise ne suffit pas à décider s'il peut joindre cette machine, quelles opérations il peut effectuer ni quand son accès doit prendre fin.
Une architecture de confiance zéro soumet chaque accès à une décision explicite sur l'identité, le terminal, la ressource et la politique applicable. Dans un environnement de technologie opérationnelle (OT), cette décision doit aussi respecter les exigences de disponibilité, de fiabilité et de sûreté du procédé.
Points essentiels
La présence dans un réseau d'entreprise ou d'usine ne confère pas, à elle seule, un droit d'accès. Il faut authentifier et autoriser l'accès à une ressource déterminée [1].
La convergence IT/OT n'impose pas de connecter chaque automate à un service d'identité ou au cloud. Des limites d'accès administrées peuvent protéger les fonctions de contrôle qui doivent rester locales.
Un routeur, un pare-feu, un VPN, un bastion ou un service d'accès peut assurer une partie du contrôle. Aucun appareil ne prouve, à lui seul, qu'une architecture complète est en place.
La segmentation reste utile. Un VLAN ou une règle de pare-feu ne décide toutefois pas, à lui seul, si une personne et son terminal peuvent accéder à une ressource précise.
Commencez par inventorier utilisateurs, actifs, flux, responsables et contraintes d'exploitation. Testez les nouvelles règles par étapes avant de les étendre à la production.
Ce que change la confiance zéro
Selon le NIST, on ne doit pas accorder une confiance implicite à un utilisateur ou à un actif pour sa seule position physique ou réseau, ni parce qu'il appartient à l'organisation. Le sujet et son terminal doivent être authentifiés et autorisés avant l'établissement d'une session avec une ressource de l'entreprise [1]. La question centrale devient : « Cette demande d'accès à cette ressource est-elle autorisée ? », et non : « Le trafic vient-il d'un réseau interne ? »
Cela ne signifie pas que chaque contrôleur industriel doit exécuter un agent d'identité récent, ni que les réseaux doivent être ouverts sans limites. Beaucoup d'équipements OT ont une fonction fixe, une longue durée de service et des fenêtres de maintenance limitées. Les recommandations du NIST pour l'OT rappellent que les mesures de sécurité doivent tenir compte des exigences propres de performance, de fiabilité et de sûreté [2].
Pour un site industriel, appliquez le principe au point de contrôle que l'équipe peut réellement exploiter. Son emplacement dépend des actifs, du système de contrôle et des services d'identité et de supervision disponibles. L'expression « confiance zéro » sur une fiche produit ne suffit pas à définir cette architecture.
Capacités à vérifier à la frontière IT/OT
Les cinq domaines de capacité ci-dessous décrivent des rôles à évaluer pour le déploiement ; ce ne sont pas des fonctions garanties sur chaque routeur industriel. Avant de vous appuyer sur une désignation de produit, identifiez le composant responsable, le périmètre qu’il prend en charge et le responsable de son exploitation.
Domaine de capacité | Rôle dans le déploiement | Points à vérifier |
|---|---|---|
Décision et application des politiques | Les services d’identité et de politique déterminent les accès ; une passerelle ou un hôte adapté les applique. | Identifiez les composants de décision, d’application et de révocation, leurs entrées et leurs journaux ; un routeur, à lui seul, ne constitue pas l’architecture complète. |
Segmentation tenant compte des protocoles | Restreindre les flux industriels autorisés et, lorsque cela est pris en charge, certaines opérations. | Vérifiez les versions exactes des protocoles, la visibilité de l’inspection, les limites liées au chiffrement et les fonctions autorisées. Ne présumez pas que chaque routeur inspecte les commandes Modbus, PROFINET, DNP3 ou OPC UA. |
Surveillance des menaces et analyse | Collecter les journaux pertinents et évaluer l’activité au regard des flux approuvés, avec des composants de supervision adaptés. | Vérifiez la télémétrie, le périmètre de détection, les intégrations et les ressources d’exploitation. L’apprentissage automatique embarqué est une capacité propre à certains produits, et non une propriété générale des routeurs. |
Réponse aux incidents encadrée | Révoquer un accès ou contenir un chemin touché au moyen d’un processus d’exploitation autorisé. | Avant toute modification automatisée, validez les effets sur le processus et la sécurité, les responsabilités d’approbation, la journalisation et le retour arrière ; ne présumez ni d’une intégration SOAR ni de la sûreté d’un isolement automatique d’un automate (PLC). |
Accès distant propre à chaque ressource | Accorder à un utilisateur identifié et à un appareil géré uniquement l’accès nécessaire à une ressource et à une tâche approuvées. | Vérifiez l’authentification, l’autorisation, la durée d’accès, la journalisation de la session et le retrait des accès. Utilisez une frontière prise en charge ou un hôte d’ingénierie si un terminal OT ne peut pas exécuter un agent d’identité. |
Avant d’automatiser le confinement en modifiant une voie de communication OT, validez les effets sur la disponibilité et la sécurité du processus, désignez le responsable et testez la procédure de retour arrière.
Représenter le chemin d'accès et désigner les responsables
Avant d'acheter un produit ou de modifier les routes, tracez le chemin d'une tâche réelle. Par exemple :
ingénieur identifié sur un poste administré → identité et politique d'accès → point de contrôle supervisé → zone d'accès OT → poste d'ingénierie ou cible autorisée
Pour la tâche de maintenance concrète, appliquez le processus d'accès distant aux automates et IHM et testez le chemin applicatif de l'ingénieur à l'équipement.
Pour chaque étape, notez l'identité de la personne ou du service, l'état exigé du terminal, la ressource cible, le protocole autorisé, le responsable de l'approbation, la durée d'accès et les journaux consultables par l'exploitation. Distinguez le système qui prend la décision, celui qui l'applique et la personne qui peut révoquer l'autorisation.
Le chemin peut traverser un fournisseur d'identité, un service d'accès distant, une passerelle VPN, un pare-feu, une DMZ OT, un bastion et un poste d'ingénierie. Ce sont des rôles distincts, même si un déploiement réunit plusieurs fonctions. Dans le modèle du NIST, le moteur de politiques et l'administrateur de politiques participent à la décision, tandis que le point d'application permet, surveille et termine la connexion [1].
Gardez un périmètre étroit. Lire une alarme ne justifie pas une route générale vers tous les automates et IHM. Séparez l'accès d'ingénierie de la télémétrie ordinaire et des chemins susceptibles de modifier le procédé. Définissez aussi la conduite à tenir si le service d'identité, la passerelle ou la liaison WAN devient indisponible : le contrôle local ne doit pas dépendre d'un service d'accès distant non éprouvé.
Segmenter sans confondre segment et confiance
Les zones, pare-feu, VLAN et listes de contrôle d'accès limitent les communications entre systèmes. Ils aident à établir des frontières entre l'IT d'entreprise, la supervision OT et les réseaux de contrôle.
À eux seuls, ils ne vérifient pas l'identité de la personne et du terminal qui demandent une session, ni la pertinence de l'opération.
Pour la mise en œuvre réseau, concevez les VLAN et les échanges inter-VLAN autorisés selon les sources, destinations et services requis.
Servez-vous des contrôles réseau pour imposer les chemins définis par la politique d'accès. À chaque frontière, n'autorisez que la source, la destination, le protocole et le sens nécessaires. Conservez la configuration et les journaux afin de pouvoir expliquer pourquoi un chemin existe et qui l'a approuvé.
Si un équipement ne sait pas authentifier chaque utilisateur, un service d'accès ou un poste d'ingénierie contrôlé peut éventuellement appliquer et tracer cette décision. Vérifiez que cette médiation respecte les exigences du fabricant de l'équipement.
Évitez les exceptions générales de type « sous-réseau OT de confiance » qui donnent à tout poste connecté accès à tous les contrôleurs. N'apportez pas non plus de changement au réseau de contrôle sans fenêtre de maintenance approuvée, sauvegarde testée et responsable du retour arrière. Les recommandations OT examinent ensemble l'architecture, les protections aux frontières et les contraintes d'exploitation [2].
Déployer les politiques par étapes
Inventorier actifs et accès. Recensez contrôleurs, IHM, postes d'ingénierie, passerelles, services, utilisateurs, fournisseurs et flux existants. Signalez les équipements qu'il est impossible de modifier ou de surveiller directement.
Délimiter le procédé. Identifiez ce qui doit rester local pour le contrôle et la sûreté, les systèmes de supervision qui utilisent les données et les passages autorisés entre zones.
Attribuer la décision et l'application. Désignez qui vérifie l'identité de l'utilisateur et du terminal, qui approuve l'accès, quelle passerelle ou quel poste applique la règle et qui contrôle les journaux et révocations.
Rédiger une règle minimale. Commencez par un utilisateur ou service nommé, une ressource, le protocole nécessaire et une période définie. Documentez les restrictions et conditions de chaque type d'accès distant, puis autorisez ce type avant d'ouvrir la connexion [3]. Attribuez un responsable à chaque exception.
Tester hors production ou pendant une maintenance. Vérifiez l'accès autorisé, le blocage des autres chemins, la visibilité dans les journaux, le fonctionnement local et le retour arrière. Incluez une panne représentative de l'équipement et du service d'accès.
Étendre après examen. Comparez les flux observés à l'architecture approuvée. Supprimez les accès et identifiants inutilisés, puis refaites les essais après un changement important d'identité, de passerelle, de pare-feu, de micrologiciel ou de réseau de contrôle.
Un tableau de bord affichant moins de routes ne suffit pas à valider le projet. Les opérateurs autorisés doivent pouvoir accomplir leur tâche, les chemins non autorisés doivent être bloqués, le contrôle local doit rester conforme à sa conception et l'équipe doit pouvoir détecter une panne et rétablir le service.
Traiter séparément les autres décisions réseau
La confiance zéro ne choisit ni le protocole VPN, ni l'opérateur mobile, ni la méthode de reprise WAN. Chaque choix demande ses propres vérifications d'extrémité, de routage et de panne. Si plusieurs machines utilisent les mêmes plages IP, résolvez ce chevauchement avant d'ouvrir l'accès entre sites : un moteur de politiques ne peut pas rendre ces routes univoques. Consultez Comment connecter plusieurs PLC ayant la même IP avec NAT et VPN pour ce problème d'adressage.
Si l'accès dépend de plusieurs liaisons WAN, testez la session distante et la reprise du site lorsqu'une liaison tombe. Le comportement acceptable appartient aux responsables de l'application et de l'exploitation ; aucune redondance n'est automatiquement transparente. Le guide Basculement, répartition de charge ou agrégation pour la 5G et Starlink traite ce choix distinct.
Conclusion : rendre chaque décision d'accès explicite
La confiance zéro est une façon de décider l'accès aux ressources, pas une fonction inscrite sur un routeur ni un substitut à la conception du réseau OT. Partez d'un utilisateur, d'un terminal, d'une tâche et d'une cible. Placez le point de contrôle là où l'équipe peut le maintenir, limitez le chemin autorisé et validez l'accès comme le refus sans perturber le contrôle local.
Avant d'étendre une politique à d'autres équipements de production, faites examiner ensemble l'inventaire, les flux permis, les scénarios de panne et le retour arrière par les responsables du contrôle, de la sécurité et de l'exploitation.
Questions fréquentes
La confiance zéro signifie-t-elle qu'on ne fait confiance à rien dans le réseau ?
Non. La position réseau ou la propriété d'un équipement ne donne simplement pas une confiance implicite. Dans le modèle du NIST, le sujet et son terminal doivent être authentifiés et autorisés avant une session avec une ressource [1]. La politique définit toujours les demandes permises.
Remplace-t-elle un VPN ou un pare-feu ?
Non. Un VPN peut protéger un chemin de communication et un pare-feu peut appliquer une frontière réseau. Ils peuvent participer à l'architecture, mais ne fournissent pas automatiquement toutes les décisions relatives à l'identité, au terminal, à la ressource, aux journaux et au cycle de vie des accès.
Un VLAN ou une DMZ OT constitue-t-il une architecture de confiance zéro ?
Non. La segmentation limite la joignabilité entre systèmes. Elle n'authentifie pas, à elle seule, une personne et son terminal pour une demande concernant une ressource précise. Utilisez-la avec une politique d'accès et des procédures d'exploitation.
Un routeur industriel peut-il fournir toute l'architecture ?
Ne le supposez pas. Un routeur ou pare-feu peut appliquer une partie du chemin si son modèle, son micrologiciel, son intégration d'identité, ses règles et ses journaux répondent aux besoins. L'ensemble dépend également des services d'identité, des responsables des ressources, du cycle de vie des accès, de la supervision et de l'exploitation OT.
Faut-il installer un logiciel de confiance zéro sur chaque PLC ou IHM ?
Pas nécessairement. Certains équipements OT ne peuvent pas accueillir un agent d'identité moderne ou des mises à jour fréquentes. Définissez alors une limite d'accès contrôlée autour des ressources et vérifiez que l'intermédiaire respecte les exigences de l'équipement et du procédé.
Par où commencer dans une usine ?
Inventoriez actifs et flux, choisissez une tâche distante qui demande un accès plus strict, nommez son responsable et définissez une règle et un chemin d'application limités. Testez la tâche autorisée, le refus, la journalisation, la panne du service et le retour arrière avant d'élargir le périmètre.
