Pourquoi ZTNA dans l'OT n'est pas comme en IT : Décrypter le périmètre réseau pour les environnements industriels

Zero Trust Network Access (ZTNA) est devenu un acronyme incontournable en sécurité IT, servant à la fois de mot à la mode et d'architecture pratique guidant d'innombrables déploiements dans le monde entier. Cependant, une tendance inquiétante a émergé dans le contexte des Technologies Opérationnelles (OT) : de nombreuses organisations et fournisseurs tentent de transférer les plans ZTNA d'origine IT dans des environnements auxquels ils ne conviennent fondamentalement pas. Cet article explore les défis spécifiques liés à l'application de ZTNA dans les domaines OT, illustre pourquoi « simplement faire comme en IT » entraîne des lacunes dangereuses, et souligne les différences architecturales et opérationnelles nuancées nécessaires pour une véritable sécurité OT.

ZTNA : Un Contexte Technique Bref

ZTNA est apparu en réponse à l'insuffisance de la sécurité traditionnelle basée sur le périmètre réseau à l'ère de l'informatique en nuage, des forces de travail mobiles et des acteurs menaçants avancés. Le principe fondamental : « Ne jamais faire confiance, toujours vérifier. » Dans ZTNA, la localisation du réseau ne confère pas de confiance. Au lieu de cela, l'authentification, l'autorisation, l'accès au moindre privilège et la vérification continue sont requis chaque fois qu'une entité souhaite accéder à une autre.

Dans l'IT, les solutions ZTNA sont généralement mises en place via des courtiers (par exemple, une passerelle cloud ou un appareil sur site) qui authentifient les utilisateurs et les appareils, intégrant souvent des services d'annuaire et des fournisseurs d'identité pour accorder l'accès aux actifs IT protégés.

L'Habitat Original de ZTNA : Le Domaine IT

Les premiers déploiements à grande échelle de ZTNA ont eu lieu dans des environnements IT d'entreprise standard — pensez aux travailleurs du savoir accédant à des bases de données ou des systèmes CRM depuis divers appareils et emplacements. Les appareils sont relativement homogènes et modernes. Les applications utilisent généralement des protocoles standard (HTTP(S), RDP, SSH, etc.) et peuvent s'intégrer nativement avec des solutions d'identité (comme SAML, OAuth). La tradition évolutive de l'IT consistant à remplacer l'infrastructure tous les cinq ans a encore accéléré l'adoption.

Qu'est-ce qui rend l'OT distinct ?

La Technologie Opérationnelle (OT) — terme générique pour les dispositifs et réseaux industriels contrôlant tout, des robots de fabrication aux sous-stations de puissance — pose des réalités que ZTNA-pour-IT ne traite tout simplement pas. Les environnements OT sont conçus pour la sécurité, le déterminisme et la longévité. De nombreux actifs n'ont jamais été conçus avec une quelconque sécurité moderne à distance ou même locale à l'esprit.

• Longévité : Les PLC, RTU, capteurs, et actionneurs peuvent fonctionner pendant des décennies (pas 3-5 ans).

• Hétérogénéité : Une seule usine peut contenir des actifs de dizaines de fournisseurs, avec des protocoles propriétaires et anciens, et aucun mécanisme d'identité intégré.

• Exploitation Déterministe : La prévisibilité est primordiale — les comportements émergents de composants réseau non testés peuvent provoquer des pannes ou des défaillances de sécurité.

• Séparation de l'IT : Les écarts d'air, réseaux propriétaires, et l'intolérance de la boucle de contrôle pour la latence en millisecondes sont de véritables, voire critiques, contraintes.

Architectures Réseau : Un ADN Différent

Dans l'IT, un courtier ZTNA est typiquement interposé entre les utilisateurs (clients) et les services (applications ou points de terminaison). Tout accès est canalisé à travers des points d'application de politique, souvent gérés en nuage, qui comprennent l'identité de l'utilisateur et la posture de sécurité de l'appareil.

Dans l'OT, la notion d'« application » n'est pas si claire : le trafic de protocole de contrôle s'étend sur plusieurs couches (domaine, contrôle, supervision), utilisant souvent des protocoles personnalisés ou anciens. Les machines peuvent « communiquer » entre elles en peer-to-peer, et non via une passerelle d'application bien délimitée et authentifiée par l'utilisateur. Le concept de « courtier » ZTNA devient donc flou, voire inapplicable sans ré-architecture significative. En outre, le rayon d'action d'un point d'application mal placé dans un réseau OT pourrait induire des temps d'arrêt ou des instabilités de processus.

Note Historique : Du Modèle Purdue à ZTNA

Depuis la fin des années 1990, les réseaux OT ont été organisés selon des variantes du modèle Purdue Enterprise Reference Architecture. Cela stratifie l'environnement en niveaux (du business corporatif au niveau 5 jusqu'aux dispositifs de terrain au niveau 0), séparés — idéalement — par des pare-feu ou des diodes de données. Déplacer le contrôle du trafic latéral vers le bas de la pile (vers les niveaux L2 et L1) n'est pas trivial et peut même être infaisable lorsque les protocoles OT manquent d'identificateurs de session, rendant l'application de politiques granulaires pratiquement impossible pour les actifs hérités.

Collaboration IT/OT : Au-delà des Conflits de Territoire

Trop souvent, les initiatives ZTNA sont menées uniquement par des équipes IT dont les priorités (confidentialité, activation du cloud, centrage sur l'utilisateur) ne sont pas en phase avec les impératifs OT (disponibilité, intégrité, latence déterministe, sécurité). Dans la plupart des projets réussis, une équipe interdisciplinaire est formée, cartographiant où les principes ZTNA sont réalisables et où des contrôles compensatoires (comme des pare-feu à fonction fixe stricte ou des proxys de couche d'application) doivent intervenir.

Un écart récurrent : les produits ZTNA dirigés par l'IT s'attendent à ce que l'identité de l'actif soit affirmée par le point de terminaison (certificats de machine, vérifications de posture de l'appareil, etc.). Pourtant, de nombreux actifs OT ne peuvent être patchés pour participer à de tels cadres ou ne possèdent même pas de capacités de calcul suffisantes pour l'installation d'agents. L'identité doit donc être déduite — par adresse MAC, port, localisation du réseau ou autres signaux faibles — élevant le niveau pour une mise en œuvre sécurisée.

Déploiement de Connectivité Sécurisée : Architecture, Tests, Vérifications de Réalité

Alors que ZTNA IT peut être déployé en logiciel vers le cloud ou le point de terminaison avec une perturbation limitée, les déploiements OT nécessitent une évaluation des risques minutieuse et une validation par étapes. Les considérations critiques incluent :

• Latence et Gigue : De nombreux courtiers ZTNA (surtout ceux s'appuyant sur des détours cloud ou une inspection lourde) introduisent une latence variable, ce qui peut être catastrophique pour les protocoles industriels sensibles au temps.

• Non-Soutien des Protocoles : De nombreux protocoles industriels (Modbus, DNP3, Profinet) ne sont pas pris en charge nativement pour l'inspection approfondie des paquets ou l'affirmation d'identité dans la plupart des solutions ZTNA.

• Principes de Sûreté : Dans l'OT, l'état par défaut en cas de défaillance du courtier/processus doit être sûr pour le processus physique (arrêter, non pas laisser passer, ne pas inviter à une interaction utilisateur).

• Contrôle des Changements : Beaucoup d'usines ont des fenêtres de maintenance mensuelles ou même trimestrielles. Pousser une mise à jour d'agent, imposer une nouvelle logique d'inspection, ou modifier la topologie peut déclencher des défauts inattendus.

Exemple : Tenter d'appliquer uniquement des sessions initiées par l'utilisateur (comme ZTNA l'exige) perturbe le trafic M2M (machine à machine) de l'usine qui fonctionne de manière autonome et constante. Redessiner rétroactivement tout le trafic de contrôle de l'usine pour « appeler » via un courtier peut être plus dangereux (et coûteux) que le risque que vous cherchez à réduire.

Où ZTNA dans l'OT Fonctionne Effectivement

Cela ne veut pas dire que ZTNA n'a aucun rôle dans l'OT. Il brille dans les scénarios suivants :

• Accès à Distance : L'accès des techniciens et des fournisseurs peut être strictement contrôlé, fournissant un point de contrôle/audit unique et réduisant les étendues de VPN.

• Ségrégation Sélective des Actifs : Lorsque les actifs sont modernes, soutiennent une identité et communications sécurisées, et sont déjà « IT-friendly » (serveurs Windows, IHM, bases de données historiennes).

• DMZs à Haute Sécurité : Entre le Niveau 3/Niveau 4, le courtage des connexions à l'IT d'entreprise depuis l'OT de l'usine bénéficie de l'application de la logique ZTNA — bien que ce soit souvent des exceptions isolées, pas le principal schéma.

Même là où c'est possible, ZTNA doit être traité comme un composant d'un modèle de sécurité à plusieurs couches — non pas une panacée, mais un outil ciblé.

Étapes Pratiques pour l'Adoption de ZTNA Industriel

1. Inventaire des Actifs : Connaître chaque actif, protocole, flux de données attendu, propriété, et profil de risque avant de rédiger les plans ZTNA.

2. Cartographie des Protocoles et de l'Identité : Comprendre quelle identité de dispositif est réalisable. Éviter les solutions « agent ou rien ».

3. Engager les Équipes d'Exploitation : Tester dans des environnements de laboratoire. Valider tout changement pouvant affecter la latence, la compatibilité des protocoles, ou l'exploitation déterministe.

4. Contrôles Compensatoires : Là où ZTNA n'est pas viable, renforcer les pare-feu, déployer des proxies sensibles aux protocoles, ou renforcer les capacités de surveillance.

5. Examen Continu : Revisiter régulièrement votre architecture. Avec la mise à niveau des actifs, l'applicabilité de ZTNA s'étend — ne pas architecturer pour demain au détriment de la sécurité d'aujourd'hui.

Conclusion

Emprunter à l'aveuglette la doctrine de sécurité IT pour les environnements OT est une invitation à des déploiements fragiles, dangereux et finalement peu sûrs. ZTNA peut apporter une réelle valeur ajoutée comme garde-fou pour l'accès à distance et l'intégration OT/IT moderne, mais seulement en respectant les contraintes uniques et les réalités opérationnelles des environnements industriels. La collaboration entre l'IT, l'OT, et l'ingénierie réseau — guidée par des approches pragmatiques, et non dogmatiques — reste essentielle.

Résumé : ZTNA dans l'OT n'est pas une simple case à cocher logicielle, mais un effort architectural minutieux et souvent partiel nécessitant une rigueur interdisciplinaire, une adoption progressive et une compréhension nuancée du risque industriel.