Conception d’applications HMI/SCADA axée sur la cybersécurité – des principes qui réduisent le risque dès la phase de conception

La sécurité d’une application HMI/SCADA se joue bien avant le choix des mécanismes de protection. La capacité du système à résister à une erreur, à un usage abusif et à une modification non maîtrisée de l’état du procédé dépend avant tout des hypothèses retenues dès la conception : répartition des rôles, limites de confiance, périmètre des fonctions accessibles depuis l’interface, ainsi que mode d’organisation du service et de l’accès à distance. Si ces questions sont reléguées au second plan, l’application finit par pérenniser le risque au lieu de le réduire. C’est pourquoi une conception du HMI/SCADA orientée cybersécurité doit être menée comme une véritable tâche d’ingénierie : il faut d’abord déterminer quelles opérations sont critiques, quelles peuvent en être les conséquences et qui doit réellement pouvoir les exécuter, puis seulement concevoir les écrans, les alarmes et le confort d’utilisation.

La cybersécurité commence dès la conception

Dans les systèmes HMI/SCADA, la cybersécurité n’est pas une couche ajoutée à une visualisation déjà finalisée. Elle résulte de décisions prises en amont : architecture de l’application, modèle d’habilitations, mode de communication avec le contrôle-commande et hypothèses retenues pour le service. C’est particulièrement important, car l’application HMI/SCADA constitue à la fois le point de contact entre l’humain, le procédé et l’infrastructure. Une erreur de conception ne se limite donc pas à un risque informatique. Elle peut aussi affecter la réaction de l’opérateur, la sécurité fonctionnelle, le risque opérationnel et la continuité de la production.

Du point de vue du projet, la question essentielle n’est donc pas de savoir quelle protection ajouter à la fin, mais quelles décisions prises dès le départ réduiront la surface d’attaque. Les problèmes les plus importants ne proviennent généralement pas de l’absence d’un mécanisme isolé, mais d’un excès de confiance intégré à l’application. En pratique, cela se traduit par des comptes utilisateurs partagés, un accès de service large et permanent, l’absence de séparation des rôles entre l’opérateur, la maintenance et l’intégrateur, ainsi qu’une communication trop libre entre la couche opérateur et le contrôle-commande. Lors de la mise en service, ces solutions paraissent pratiques, car elles accélèrent les travaux et facilitent le diagnostic. Par la suite, elles deviennent une caractéristique durable de l’environnement et augmentent le risque d’abus, d’erreur ou de modification non maîtrisée de l’état du procédé.

C’est pourquoi, avant de concevoir les écrans, il convient de définir non seulement ce que l’utilisateur doit voir, mais surtout où se situent les limites de confiance, quelles opérations sont critiques et à quels endroits l’interface peut devenir un vecteur d’erreur ou de contournement des procédures. Cet ordre de travail structure les décisions ultérieures : le HMI doit-il être uniquement une couche de visualisation, ou aussi un espace de configuration, de diagnostic et de modification des recettes ; les fonctions de service doivent-elles être actives en permanence, ou seulement après une activation volontaire ; l’opérateur doit-il avoir accès uniquement à la conduite du procédé, ou également à des opérations modifiant les paramètres et l’historique des données.

Le coût concret des négligences n’apparaît généralement qu’une fois l’application déjà liée aux recettes, aux alarmes, au reporting, à l’archivage et aux procédures de maintenance. À ce stade, même une correction apparemment simple, comme la séparation des comptes, la modification du circuit de validation d’une opération critique ou la limitation de l’accès à distance à un usage ponctuel, cesse d’être un simple changement d’écrans. Elle impose une refonte de la logique, une nouvelle vérification du traitement des alarmes, une clarification des responsabilités et, souvent, des changements organisationnels dans l’usine.

En pratique, le point de départ le plus pertinent consiste à établir une cartographie de travail des rôles utilisateurs et de leurs droits sur les opérations critiques, une liste des fonctions entraînant une modification de l’état du procédé, de la configuration ou des recettes, ainsi qu’un inventaire des connexions externes couvrant le service, le reporting, les systèmes de niveau supérieur et l’accès à distance. Ce n’est qu’à partir de là qu’il devient possible de concevoir de manière cohérente l’architecture des zones et des liaisons, puis de préparer l’analyse de risque ultérieure. Cette approche est conforme à la fois aux pratiques d’ingénierie et aux exigences de clarification des responsabilités, de séparation des fonctions et de maîtrise des communications dans les environnements industriels.

Où le coût et le risque augmentent réellement

Dans une application HMI/SCADA, le coût et le risque les plus élevés ne résultent pas uniquement du fait que des systèmes sont interconnectés, mais des conséquences sur le procédé et sur l’organisation qu’entraînent les différentes fonctions de l’application. Les points les plus sensibles sont ceux qui permettent de modifier rapidement des consignes, d’introduire un contournement, de neutraliser une alarme, de changer une recette ou d’exécuter une commande manuelle sans disposer de l’ensemble du contexte technologique. Si la conception autorise de telles opérations depuis un écran de production en mode routinier, le risque augmente, car une seule décision utilisateur ou une seule session compromise peut modifier directement l’état du procédé.

Cela signifie que le catalogue des opérations critiques doit être considéré comme un élément de l’architecture de sécurité, et non comme une simple question d’ergonomie de l’interface. Le même principe s’applique à l’imputabilité des actions. Les identifiants partagés, les comptes communs à toute une équipe, l’absence de séparation des droits de lecture, de commande, de configuration et d’administration, ainsi qu’une journalisation trop limitée des événements, font qu’après un incident il devient difficile d’établir de manière fiable s’il s’agit d’une erreur, d’un contournement de procédure, d’un usage abusif d’un accès de service ou d’une action non autorisée. Le problème ne se limite pas à la seule recherche des causes. Sans trace fiable des actions utilisateur, il est également impossible d’évaluer l’efficacité des procédures, de gérer les droits d’accès de façon pertinente ou de justifier des décisions d’exploitation face à un audit interne, à des exigences client ou à des politiques de sécurité en vigueur. En pratique, il s’agit ici de l’imputabilité des actions et de la traçabilité, et pas seulement de l’enregistrement des événements.

Une autre erreur de conception particulièrement coûteuse consiste à transférer vers l’environnement de production des écrans de service et de diagnostic très complets, initialement préparés pour la mise en service ou pour l’assistance de l’intégrateur. Ces vues donnent souvent un large accès aux variables internes, au forçage d’états, à l’effacement de verrouillages et à la modification de paramètres, alors qu’en exploitation normale elles ne sont utiles qu’à titre occasionnel. Si elles ne sont pas soumises à des restrictions supplémentaires, elles deviennent le chemin le plus court vers une intervention sur le procédé en dehors du parcours opérateur habituel. Une approche raisonnable consiste à séparer le diagnostic nécessaire à la maintenance des fonctions permettant d’intervenir sur la logique de fonctionnement, et à décider séparément si le diagnostic du constructeur de la machine doit être accessible localement, à distance ou uniquement sous conditions, après activation volontaire et avec enregistrement complet de la session.

Il faut adopter la même approche pour l’intégration avec les bases de données, le reporting, l’assistance à distance et les systèmes bureautiques. Chacune de ces connexions améliore le confort d’utilisation, mais augmente en même temps le nombre de dépendances susceptibles de devenir une voie d’entrée, une source de perturbations ou une cause de perte de lisibilité des responsabilités. Une défaillance d’un service intermédiaire, une mauvaise synchronisation de l’heure, un échange de données non maîtrisé avec le système de niveau supérieur ou un canal de service laissé ouvert peuvent affecter non seulement la disponibilité des rapports, mais aussi les décisions prises par l’opérateur.

Dès la phase de conception, il est donc utile de mesurer non seulement la disponibilité des écrans, mais aussi des indicateurs plus simples et plus utiles : le nombre d’opérations critiques possibles depuis le HMI de production, le nombre de connexions externes actives, le nombre de comptes à privilèges et l’étendue des événements couverts par la piste d’audit. Ce type de revue structure ensuite la journalisation des événements, le contrôle des modifications de paramètres et les règles d’accès à distance.

La gestion des alarmes doit faire l’objet d’un traitement spécifique. Dans ce domaine, une impression de complétude masque souvent une absence réelle de maîtrise. Des alarmes mal conçues et un historique des événements inadapté ne se contentent pas de surcharger l’opérateur : ils lui font aussi perdre la capacité de distinguer les signaux critiques du bruit technique. Si une alarme peut être facilement neutralisée sans justification, acquittée sans lien avec sa cause ou noyée dans une masse de messages de diagnostic, l’application cesse de soutenir la sécurité du procédé. Les priorités d’alarme doivent donc découler des conséquences réelles pour les personnes, la machine et la qualité de production, tout en restant liées aux règles d’enregistrement des acquittements, des contournements et des changements de réglage. C’est précisément à ce moment-là que l’analyse de risque cesse d’être un document formel et commence à façonner l’interface.

Comment concevoir pour limiter les effets de l’erreur et des abus

Le point de départ est simple : une application HMI/SCADA ne peut pas partir du principe que chaque utilisateur agit toujours correctement et dans le bon contexte de procédé. La conception doit commencer par la séparation des fonctions, et non par le dessin des écrans. L’équipe doit d’abord définir ce que l’opérateur doit uniquement voir, ce qu’il peut acquitter, ce qu’il est autorisé à modifier dans le cours normal du travail, et quelles actions doivent être basculées en mode service, soumises à une autorisation supplémentaire ou totalement isolées dans un outil ou un poste distinct.

Cette décision structure toute l’architecture des accès : les rôles, le périmètre des droits, la manière de consigner les actions et les conditions de l’assistance à distance. En pratique, une matrice des rôles fondée sur les responsabilités réelles fonctionne bien, en distinguant l’opérateur, le chef d’équipe, la maintenance, le technologue, l’intégrateur et l’administrateur. Ce n’est pas une formalité. Si les fonctions de service restent sur le même écran et sous le même compte que la conduite du procédé, l’application crée elle-même une voie vers l’erreur, le contournement de procédure ou l’abus de privilèges.

Un bon HMI/SCADA limite la possibilité d’exécuter par inadvertance une opération dangereuse, sans pour autant ralentir inutilement les tâches de routine. Cela exige un contexte de travail clair : l’utilisateur doit voir sur quel équipement il intervient, dans quel état se trouve le procédé, s’il agit localement ou à distance, et si le système est en mode automatique, manuel ou service. Les confirmations doivent être proportionnées au risque, et non identiques pour toutes les actions. Là où les conséquences d’une erreur sont réversibles et limitées, une autorisation simple suffit généralement. Les opérations critiques exigent un contrôle supplémentaire : une seconde confirmation, une nouvelle authentification, une dépendance à l’état du procédé ou un passage physique vers une interface dédiée.

Les verrouillages conditionnels sont également essentiels. Si l’application autorise une modification de consigne, le forçage d’un signal ou le passage en mode manuel indépendamment de l’état de l’installation, le risque est déplacé de la conception vers l’opérateur. C’est précisément là que l’on voit qu’une conception correcte de l’interface ne relève pas uniquement du confort d’utilisation, mais aussi de la limitation des conséquences d’une erreur grâce à des barrières intégrées. Dans de nombreux cas, cette logique se rapproche de celle du Poka-Yoke sur les lignes de production.

La conception d’un accès par couches doit aussi couvrir la manière dont les droits sont utilisés dans le temps. Les comptes individuels sont indispensables partout où l’on attend une traçabilité des actions. Un compte partagé supprime la possibilité d’établir qui a réellement pris la décision. Le principe du moindre privilège signifie que l’utilisateur ne dispose que des fonctions nécessaires à son travail courant, et que l’élévation des droits n’intervient que temporairement et dans des conditions maîtrisées. Cela concerne en particulier la maintenance, l’intégrateur et l’assistance à distance du fabricant. Un accès de service permanent et ouvert n’est pratique qu’en apparence, car il supprime la frontière naturelle de confiance entre l’exploitation et le service. Un modèle plus sûr consiste en un accès activé à la demande, limité dans le temps, attribué à une personne précise et consigné dans l’historique des événements. Cette approche s’inscrit bien dans le principe du moindre privilège et la segmentation des accès.

Dans le même esprit, il faut déterminer si les fonctions de service doivent être accessibles depuis l’IHM de production ou uniquement depuis un poste séparé, et s’il convient d’autoriser les supports amovibles ainsi que l’import ou l’export local de données depuis le pupitre opérateur. Ces décisions ne sont pas secondaires. C’est d’elles que dépend le fait que la maintenabilité du système soit assurée de manière maîtrisée ou au moyen de contournements ponctuels.

Du point de vue d’un incident ou d’un litige d’exploitation, l’interface seule ne suffit pas. L’application doit laisser des éléments permettant de reconstituer le cheminement des décisions. L’historique des événements, les journaux système et l’enregistrement des modifications doivent ensemble répondre non seulement à la question de savoir ce qui s’est passé, mais aussi qui a effectué l’opération, quand, depuis quel emplacement et dans quel état du procédé. Le périmètre minimal des événements qu’il est généralement pertinent d’enregistrer comprend la connexion, la modification des droits, la modification des paramètres, le passage en mode manuel, l’acquittement d’une alarme ainsi que l’import de configuration. Le lien entre l’enregistrement et le contexte technologique est essentiel, car une simple information sur une modification, sans l’état de l’installation, peut s’avérer inutilisable.

Un bon exemple, typique de nombreux déploiements, est le suivant : la modification d’un seuil d’alarme par un technologue peut être autorisée, mais uniquement après passage dans le mode prévu, avec enregistrement de l’utilisateur, du poste, de l’heure, de l’ancienne et de la nouvelle valeur, ainsi qu’avec confirmation que l’installation n’était pas dans un état critique. Une telle trace est importante à la fois pour la sécurité et pour la gestion des changements dans les applications industrielles.

La dernière couche concerne la maintenabilité sans contournement des protections. Si une mise à jour, une restauration de configuration ou un diagnostic exigent la désactivation du contrôle d’accès, l’utilisation d’un mot de passe partagé ou un fonctionnement sans trace d’audit, le problème vient de la conception et non de la discipline du personnel. L’application doit prévoir un déroulement de changement : demande, évaluation d’impact, test, déploiement, confirmation et plan de retour arrière. Elle doit aussi séparer l’environnement d’exploitation de l’environnement de service au moins sur le plan logique et, lorsque cela se justifie, également sur les plans organisationnel et technique. Les sauvegardes de configuration doivent pouvoir être réalisées et restaurées de manière maîtrisée, sans export ponctuel « au cas où » depuis le pupitre. Cette approche est cohérente avec le principe du moindre privilège en OT ainsi qu’avec les exigences relatives au contrôle d’accès, à la traçabilité des actions et à la gestion des changements, étant entendu que leur portée doit toujours être rapportée à l’architecture du système et à la répartition des responsabilités retenue.

Pratique de mise en œuvre et référence aux exigences

Ce qui apporte le plus, ce n’est pas l’ajout de mécanismes de protection supplémentaires en fin de projet, mais une revue structurée de l’application avant la réception ou la modernisation. C’est à ce moment-là qu’il est encore possible de corriger à coût relativement limité le mode de fonctionnement du système, au lieu d’habiller plus tard des hypothèses erronées par des procédures supplémentaires. Une telle revue devrait être menée par une équipe mixte : conception, maintenance, exploitation, automaticien et personnes responsables de la sécurité.

L’objet de l’évaluation n’est pas uniquement la configuration technique, mais aussi le fait de savoir si l’application sépare réellement les rôles, protège les opérations critiques, limite l’accès à distance aux cas justifiés, assure une gestion claire des alarmes, conserve l’historique des modifications et permet d’exécuter les sauvegardes ainsi que les procédures d’urgence sans contourner les protections. C’est précisément de cette revue que devraient découler la liste pour le FAT/SAT ainsi que les exigences inscrites dans la réception, le plan de service et la documentation de fin de réalisation.

Cette approche déplace le centre de gravité du débat, des seules protections vers les choix de conception qui déterminent ensuite le comportement des personnes et des équipements. Si, dès la phase de conception, il n’a pas été défini qui peut modifier les paramètres des recettes, qui valide le mode service, comment l’intervention de l’intégrateur est consignée et dans quelles conditions un accès depuis l’extérieur du site est autorisé, alors, une fois le système mis en service, son fonctionnement reposera sur des exceptions et des accords verbaux.

Pour la même raison, il est utile de trancher si l’évaluation de l’application doit être menée dans le cadre de la modernisation d’une machine ou d’une ligne, ou comme une revue OT distincte. La première approche relie mieux la sécurité à la fonction du procédé, la seconde facilite l’identification des dépendances entre systèmes et la répartition des responsabilités concernant les comptes, les droits d’accès et la journalisation des actions. C’est aussi le cadre naturel pour une analyse de risque préliminaire : identification des opérations critiques, des frontières de confiance et des conséquences d’une erreur opérateur ou d’un usage abusif. En pratique, une analyse de risque dans le projet peut également s’avérer utile.

• les rôles et le mode de connexion des utilisateurs,
• les opérations critiques et les règles de confirmation associées,
• l’accès à distance et les fonctions de service,
• les alarmes, l’enregistrement des modifications et la traçabilité des actions,
• les sauvegardes, la restauration et les procédures d’urgence.

Dans une usine, de bons résultats découlent rarement du déploiement simultané de nombreux outils. En général, il est plus important d’éliminer quelques risques systémiques qui, pendant des années, ont été considérés comme pratiques. La modernisation d’une application HMI/SCADA peut commencer par la suppression des comptes partagés, la séparation des fonctions de service et des fonctions opérateur, la limitation des connexions externes à des voies contrôlées, ainsi que la mise en place d’une traçabilité des modifications de paramètres attribuée à une personne ou à un rôle précis. Une telle évolution ne doit pas nécessairement dégrader le travail de la maintenance ni celui de l’intégrateur, à condition que le mode service, les règles d’autorisation et un déroulement reproductible des modifications aient été prévus dès le départ.

En exploitation, il est ensuite préférable de mesurer non pas un niveau de sécurité abstrait, mais des indicateurs réellement utiles sur le plan opérationnel : le nombre de comptes partagés encore présents dans le système, l’étendue de l’accès à distance actif, l’exhaustivité des journaux de modifications, le temps de restauration de la configuration et le nombre d’interventions réalisées en dehors de la procédure formelle. De tels indicateurs permettent d’évaluer si le projet a réellement réduit le risque, ou s’il l’a simplement déplacé dans la pratique quotidienne.

Dans le contexte polonais et européen, il devient de plus en plus difficile de défendre une approche dans laquelle la cybersécurité HMI/SCADA relèverait exclusivement du service informatique. La responsabilité est répartie entre la conception, l’exploitation, la maintenance, les fournisseurs et les intégrateurs, et les exigences sectorielles ainsi que contractuelles ne prennent de valeur que lorsque l’organisation est capable de présenter des éléments concrets : quelles décisions de conception ont été prises, comment les droits sont attribués, quelle traçabilité des actions existe et qui contrôle les modifications. De simples références à des normes, à des politiques internes ou à des clauses contractuelles ne remplacent pas la preuve que l’application a été conçue et réceptionnée de manière à permettre une exploitation sûre.

La conclusion la plus importante est d’ordre pratique. Le moment le moins coûteux et le plus efficace pour réduire le risque reste la conception et la réception de l’application. C’est à ce stade que l’on définit au moindre coût les frontières de confiance, les rôles, les conditions d’accès, la traçabilité des actions et la manière de gérer les modifications. Si ces exigences sont traduites en critères vérifiables vis-à-vis du fournisseur et de l’intégrateur, HMI/SCADA cesse d’être une interface pratique mais excessivement confiante, pour devenir un outil d’exploitation sûre du procédé.