Le Zero Trust est omniprésent : dans les présentations commerciales, dans les appels d'offres, dans les recommandations des autorités et dans les stratégies proposées par les cabinets de conseil. Ne rien tenir pour acquis, vérifier en permanence : le principe est solide et a fait ses preuves en informatique de gestion. Sa transposition telle quelle à un réseau industriel est en revanche une source de difficultés.

La raison tient à une différence de nature : ce qui protège des serveurs de fichiers peut arrêter une ligne de production.

Zero Trust en IT : pourquoi ça marche

En informatique de gestion, le modèle repose sur des principes clairs :

  • chaque utilisateur et chaque équipement est authentifié avant d'accéder à une ressource
  • les droits sont limités au strict nécessaire
  • chaque session est vérifiée en continu et non seulement à l'ouverture
  • la microsegmentation isole chaque charge de travail
  • les règles sont centralisées et appliquées dynamiquement

Ce modèle fonctionne parce que les systèmes ont été conçus pour l'accueillir. Les postes acceptent l'authentification renforcée, les applications tolèrent la latence d'une vérification supplémentaire, les serveurs se redémarrent sans conséquence physique, et un blocage temporaire se traduit par quelques secondes d'attente.

En environnement industriel, aucune de ces conditions n'est réunie.

La réalité OT que les consultants IT ignorent

Zero Trust en IT
Réalité en OT
Authentification multifacteur sur chaque accès, par mot de passe et code à usage unique.
Un opérateur ganté, devant un pupitre tactile en zone classée, ne peut pas saisir un code à usage unique. L'authentification renforcée retarde alors l'accès au moment précis où il est requis.
Microsegmentation avec filtrage entre chaque charge de travail, chaque flux étant inspecté.
Les automates échangent en temps réel avec des contraintes de latence de l'ordre de la milliseconde. Un équipement qui ajoute quelques millisecondes peut provoquer une mise en sécurité sur un procédé continu.
Vérification continue de chaque session, avec des jetons qui expirent et se renouvellent.
Un automate communique en permanence avec un variateur de vitesse. Interrompre cet échange, même brièvement, pour revérifier une identité revient à arrêter le moteur, puis la ligne.
Règles centralisées appliquées dynamiquement par un contrôleur qui décide en temps réel des accès.
Si ce contrôleur devient indisponible, des postes bureautiques perdent temporairement leurs accès. En production, le blocage d'un échange entre automates se traduit par un arrêt physique.
Mises à jour régulières des agents de sécurité, déployées automatiquement.
Automates et pupitres n'acceptent généralement aucun agent supplémentaire. En installer un peut faire perdre le bénéfice de la garantie et introduire des comportements imprévus.
Interdiction par défaut : tout est bloqué sauf ce qui est explicitement autorisé.
Une interdiction par défaut mal paramétrée peut bloquer une commande d'arrêt d'urgence. Pour les fonctions de sécurité, le comportement attendu en cas de défaillance est l'inverse de celui que prescrit le modèle.

Le mécanisme à comprendre : le risque ne vient pas de la sécurité elle-même mais de la latence et du comportement en cas de défaillance. Un équipement de filtrage inséré sur une liaison temps réel introduit un délai supplémentaire. Sur un procédé continu, ce délai peut suffire à déclencher des alarmes en cascade puis une mise en sécurité automatique, avec un arrêt de production de plusieurs jours à la clé. La mesure de sécurité devient alors elle-même la cause de l'indisponibilité qu'elle devait prévenir.

Pourquoi la CIA devient AIC en OT

En sécurité informatique, l'ordre de priorité place la confidentialité en tête, suivie de l'intégrité puis de la disponibilité. En environnement industriel, cet ordre s'inverse : la disponibilité vient d'abord.

Cette inversion n'est pas une préférence mais une contrainte. Une installation qui ne produit pas génère une perte à chaque minute. Un système instrumenté de sécurité qui ne fonctionne pas met des personnes en danger. Des vannes qui ne s'ouvrent pas produisent des conséquences physiques immédiates.

Or le modèle Zero Trust accepte, par construction, de sacrifier de la disponibilité au profit de la confidentialité et de l'intégrité. Ce compromis est raisonnable pour une messagerie indisponible trente secondes. Il ne l'est pas pour une commande d'arrêt d'urgence retardée d'autant.

Ce qui marche réellement en OT : le « Conditional Trust »

Faut-il pour autant écarter ces principes en environnement industriel ? Non, mais leur mise en œuvre doit être repensée. L'approche que nous recommandons repose sur une confiance conditionnelle, articulée en cinq points.

1. Segmentation par zones et conduits. Plutôt qu'une microsegmentation par charge de travail, adoptez le modèle de l'IEC 62443 : des équipements regroupés par criticité et par fonction, des flux inter-zones passant par des conduits contrôlés. La granularité est moindre, mais elle reste compatible avec les contraintes temps réel.

2. Authentification adaptée au contexte. Pas d'authentification renforcée sur les pupitres en zone de production, mais un contrôle d'accès physique strict à l'entrée de la zone, complété par une identification simple sur le poste. L'authentification renforcée est réservée aux accès distants et aux stations d'ingénierie situées hors zone.

3. Vérification des flux plutôt que des sessions. Au lieu de contrôler en permanence l'identité de chaque équipement, vérifiez que les échanges correspondent au comportement attendu. Un automate qui émet soudainement vers une destination inconnue est bloqué ; un automate qui dialogue normalement avec son variateur n'est pas interrompu.

4. Détection passive des anomalies. Une surveillance qui écoute le trafic sans l'intercepter détecte les anomalies de protocole, les communications non prévues et les modifications de micrologiciel, sans introduire de latence ni interrompre un flux.

5. Comportement sûr en cas de défaillance. Les systèmes instrumentés de sécurité et les circuits d'arrêt d'urgence doivent rester opérationnels même si le dispositif de contrôle des règles tombe. Ce point s'oppose frontalement à l'interdiction par défaut et n'est pas négociable.

Le bon réflexe : avant de déployer une mesure sur un réseau industriel, posez la question de son comportement en cas de défaillance. Si la réponse est un arrêt de production ou un risque pour les personnes, la mesure doit être reprise, quelle que soit sa pertinence par ailleurs.

Le piège du vendeur de solutions IT

Le marché compte de nombreux fournisseurs venus de l'informatique de gestion qui abordent l'industrie avec le même catalogue. L'argument est constant : la solution serait identique, adaptée au contexte industriel. L'adaptation se limite parfois à la présentation.

Quelques signaux permettent de s'en assurer :

  • l'interlocuteur ne distingue pas les variantes des protocoles industriels employés sur votre site
  • la solution suppose l'installation d'agents sur les automates
  • la notion de latence n'apparaît pas dans la documentation technique
  • le comportement en cas de défaillance n'est pas documenté
  • les références clients ne comportent aucun environnement industriel réel
  • la démonstration est proposée sur le réseau bureautique, les résultats étant supposés transposables

Le cadre réglementaire marocain

La loi 05-20 exige des mesures adaptées au contexte, et la DGSSI se réfère de plus en plus à l'IEC 62443 pour les environnements industriels. Cette norme n'emploie pas le terme Zero Trust : elle raisonne en zones, en conduits, en niveaux de sécurité et en défense en profondeur.

Un opérateur qui déploierait une architecture conçue pour l'informatique de gestion sur son réseau industriel, et qui subirait un arrêt de production de ce fait, ne se trouverait pas dans une meilleure position qu'un opérateur resté inactif. La conformité s'apprécie à l'adéquation des mesures, non à leur notoriété.

La voie pragmatique

Le Zero Trust n'est pas une mauvaise idée en environnement industriel ; c'est sa transposition littérale qui pose problème. Les principes de fond, ne pas accorder de confiance implicite, vérifier les accès, limiter les privilèges et segmenter, conservent toute leur validité. Leur mise en œuvre demande en revanche une connaissance des contraintes de production dont ne disposent pas la plupart des intervenants issus de l'informatique de gestion.

Une question suffit généralement à le vérifier auprès d'un prestataire : quel est le comportement de la solution en cas de défaillance, et quel en est l'effet sur la production ? Une réponse hésitante sur ce point en dit plus long que l'ensemble de la présentation qui précède.