Quels conseils pour le déploiement de clients web et mobile en supervision ?

L’exploitation répartie ou déportée d’une supervision peut se faire sur la base de postes « client lourd » (les logiciels sont installés sur les machines des utilisateurs), ou au travers de « client léger » (les logiciels sont disponibles sur une machine serveur tournant sous Windows Server et accessibles depuis des sessions bureau à distance ou RDS) ou encore au travers de navigateurs web, communément appelés « client web ». Ces accès web permettent un usage nomade au travers de l’utilisation de terminaux mobiles, mais sont aussi très intéressants pour des usages fixes en lieu et place des clients lourds comme on le verra au paragraphe suivant.

Il est courant de trouver des déploiements combinant plusieurs de ces solutions pour des raisons liées à l’histoire du site, aux architectures des réseaux, aux contraintes sur les droits d’accès, à l’administration des infrastructures et du parc informatique, etc. A l’extrême, certains éditeurs récents de SCADA ne proposent que des accès web. Dans la gestion du bâtiment, il est même usuel de disposer d’IHM uniquement sur la base des pages web embarquées dans les automates.

Le web jouit en général d’une image de facilité de déploiement de prix compétitif, mais quelle que soit la technologie d’accès aux informations, web ou pas web, il faudra de toute façon installer des logiciels pour la communication avec les automatismes (serveur d’acquisition), l’archivage des données et l’exploitation (le projet de supervision avec ses synoptiques). Dans le cas de clients web et mobile, un serveur web devra aussi être mis en place et administré. Il devra fonctionner sur une machine serveur (OS serveur) dans le cas des applications avec un nombre d’utilisateurs supérieur à dix. Mais est-ce réellement si simple de déployer des supervisions avec accès web ? Comme toute technologie, elle implique à minima le respect de quelques bonnes pratiques. Dans ce premier article nous passons en revue les avantages du web en supervision et les implications techniques de son déploiement. Deux exemples d’architecture de déploiement seront analysés dans un second article (voir l’article).

L’accès client web permet l’utilisation d’une machine banalisée ; la puissance de calcul est déportée et une simple connexion internet/intranet de qualité est nécessaire (disponibilité, débit stable et suffisant). Cette même machine bureautique permet par ailleurs très souvent d’accéder à un portefeuille d’applications facilitant le quotidien de l’opérateur.

Le déploiement est facilité puisqu’il n’y a aucune installation de logiciels sur le terminal client web et l’administration est réduite à celle du serveur web. La sécurité informatique est aussi concentrée sur une seule machine (celle sur laquelle est installé le serveur web). Néanmoins, on ne s’affranchit pas de l’installation et de l’administration de la ou des machines pour la communication avec les automatismes, l’archivage des données et l’hébergement du projet de supervision (l’ensemble des synoptiques).

L’avantage économique que l’on associe aux clients web dépendra du nombre d’utilisateurs de la supervision, du nombre d’installations à superviser (un ou plusieurs réseaux ou sites industriels), de la nature des accès (accès depuis le réseau industriel, accès depuis le réseau bureautique ou accès distants via une fibre brune ou depuis Internet) et des ressources informatiques disponibles sur le site. En effet, pour toutes ces raisons, le déploiement d’accès web et mobile nécessite une segmentation et une gestion des réseaux plus ou moins élaborées.

Evidemment, le déploiement de client web apporte en premier lieu la mobilité et puis l’adaptabilité au multi support (taille d’écran variable, form factor tablette et laptop) et répond aux attentes d’usage des utilisateurs. Pour le spécialiste en automatisme, le déploiement d’un serveur web implique des connaissances informatiques particulières, la collaboration avec l’équipe IT pour gérer les interconnexions avec les réseaux extérieurs au réseau industriel, et si l’on veut le faire dans les règles de l’art, prendre en compte les exigences de cyber sécurité qui sont de plus en plus élevées. N’oublions pas que la cyber sécurité ne concerne pas que les seuls acteurs de l’internet.

Le protocole http cède progressivement la place au protocole https. Celui-ci apporte la sécurité des transmissions en permettant de chiffrer les échanges entre le serveur web et le client web. Basé sur l’utilisation d’un certificat de sécurité, https permet également à l’utilisateur de vérifier l’identité du serveur et ainsi de savoir s’il peut lui faire confiance : en https, le navigateur vérifie le certificat présenté par le serveur web et ne donnera pas accès aux pages web si le certificat n’est pas valide. L’objectif est d’une part de s’assurer de la légitimité du serveur web et d’autre part de prévenir une interception des échanges entre le client web et le serveur web. L’interception des échanges à craindre entre un client web et le serveur web est du type « L’attaque de l’homme du milieu (HDM) » ou « man-in-the-middle attack (MITM) ». Son objectif est d’intercepter les communications entre le client et le serveur sans que ni l’un ni l’autre ne puisse se douter que le canal d’échange ait été compromis.

Actuellement, les navigateurs web émettent des alertes lorsque la connexion est en http, voire de plus en plus bloquent l’accès en première instance de connexion au site.

Pour se rendre compte de l’importance stratégique du https, rappelons que Google ne référencera bientôt plus les sites web qui ne seront pas en https et les navigateurs bloqueront définitivement l’accès aux pages web délivrées en http. Par conséquent, les navigateurs ne fonctionneront bientôt plus qu’en https qui deviendra le standard unique. Cette évolution du monde du web imposera donc l’utilisation du protocole https pour le déploiement de clients web de supervision que ces clients soient connectés directement via le réseau industriel, ou connectés au réseau bureautique ou encore depuis un réseau extérieur au site (que ce soit via internet ou un VPN).

Déployer des clients web en https implique donc de mettre en place un certificat de sécurité afin de permettre au client web l’accès au serveur web au travers d’une connexion sécurisée. Trois cas sont à envisager selon l’accès et le besoin de confiance associée :

• L’utilisateur du superviseur est unique, c’est une même machine qui héberge le serveur d’acquisition, le superviseur et le client web. De façon pratique, ce cas est certainement réduit aux phases de développement ou pour réaliser des tests sur une machine isolée. On peut utiliser un certificat auto-signé. En quelque sorte, on n’engage sa confiance qu’avec soi-même car c’est l’utilisateur lui-même qui émet le certificat.
• Les clients web sont sur le même réseau industriel que le serveur web et maintenus par une seule et même équipe. La confiance est donc établie. On peut à la limite utiliser un certificat auto-signé, mais il est préférable d’utiliser un certificat émis par le contrôleur de domaine. Cela assure la confiance entre les clients web utilisés par plusieurs personnes différentes et le serveur web au sein d’un parc informatique administré de manière homogène sur un domaine. Les services IT ont généralement l’habitude d’émettre ce type de certificat.
• Les clients web sont sur des réseaux extérieurs au réseau industriel (un réseau bureautique, un autre réseau industriel, Internet,…). On pourra utiliser un certificat émis par le contrôleur de domaine, mais il est préférable de privilégier un certificat émis par un tiers de confiance, comme pour le certificat de votre site web d’entreprise, en particulier si des accès par des tiers depuis un réseau à l’extérieur du site ou depuis une machine non-administrée par les équipes du site sont prévus.

Exemple du certificat de sécurité du site d’ATYS CONCEPT (https://www.atys-concept.com)

Afin de garantir la sécurité des personnes et des moyens de production, il est absolument nécessaire de maîtriser les accès au réseau industriel et aux réseaux de terrain, « qui accède à quoi et par où ? ». Il faut éviter qu’un client web n’accède directement au réseau industriel en contrôlant strictement les flux entrants de l’extérieur vers l’intérieur.

La machine hébergeant le serveur web est la machine la plus directement exposée aux menaces pouvant passer par les réseaux depuis lesquels les clients web se connectent. Il faut faire en sorte que ce soit la seule, que le réseau industriel ne soit pas directement exposé et que l’accès au process physique soit impossible, même à travers le serveur web. L’isolation stricte n’est pas toujours possible, la segmentation des réseaux permet de mettre en place les protections nécessaires. Tout réseau autre que le réseau industriel est à considérer comme l’extérieur et de moindre niveau de sécurité. Il faut avoir à l’esprit qu’un autre réseau industriel et le réseau bureautique sont aussi à considérer comme extérieurs.

Dans la continuité des bonnes pratiques de segmentation, il est important de minimiser le nombre de machines auxquelles le serveur web accède dans le réseau industriel. En particulier, on ne veut pas que le serveur web accède aux serveurs d’acquisition parce qu’ils sont la porte d’accès aux réseaux de terrain. En général, une machine sera dédiée, côté réseau industriel et sera en charge de fournir les données au serveur web qui les relaiera aux clients web.

De façon synthétique, la segmentation passe par l’utilisation de règles de routage et de pare-feux (firewalls) et la création d’une DMZ au sein de laquelle le serveur web est installé. Une DMZ (demilitarized zone ou zone démilitarisée) est un réseau isolé à la fois du réseau industriel et des réseaux extérieurs (bureautique ou Internet) par des pare-feux. Les pare-feux permettent de contrôler les accès à la DMZ et au réseau industriel pour garantir leur sécurité. Les services à ouvrir aux accès extérieurs sont situés en DMZ, mais l’accès direct au réseau industriel depuis l’extérieur est bloqué, minimisant ainsi les risques de compromission des actifs industriels.

Dans le schéma ci-dessous donné à titre d’illustration (il existe de nombreuses variantes d’utilisation des pare-feux et routeurs pour segmenter des réseaux avec une DMZ), le serveur d’acquisition de données communique avec une machine SCADA (typiquement cliente du serveur d’acquisition) qui donne accès aux informations au serveur web, lui-même relayant les données aux clients web. Les clients web n’accèdent pas directement au réseau industriel, ni aux machines SCADA, ils n’accèdent donc pas aux équipements de terrain.

Pour accéder au serveur web depuis un navigateur, il est possible de rentrer l’adresse IP dans la barre du navigateur ou encore le nom de la machine. Cela nécessite que les utilisateurs connaissent l’adresse IP ou le nom de la machine et de les tenir informés de tout changement. Pour des raisons de confort d’utilisation, il est préférable de pouvoir taper une adresse en langage courant ; soit un nom d’hôte (host name), propre à l’organisation interne du type https://hostname, soit un nom de domaine public (une URL du type https://wwwsupervision.masociete.com). En plus du confort d’utilisation, le nom offre l’avantage de rester inchangé même en cas de changement d’adresse IP du serveur web.

Dans tous les cas, un mécanisme de résolution de noms doit être en place afin de traduire le nom en adresse IP. Dans le cas d’un nom d’hôte interne, on utilise en général la résolution de nom par Windows tandis que dans le cas d’un nom public, on doit mettre en œuvre un DNS. Le DNS est un service distribué utilisé pour traduire les noms de domaine Internet en adresse IP ; cela permet d’associer des noms en langage courant aux adresses IP.

Si l’on fait le choix du nom d’hôte sur un domaine Windows, les terminaux ne fonctionnant pas sous OS Windows ne pourront pas accéder au serveur web, puisque la résolution de nom à l’oeuvre dans ce cas ne fonctionne que depuis les clients fonctionnant sous Windows. En d’autres termes, les smartphones et tablettes Android ou IOS ne peuvent pas être utilisés avec une résolution de nom sous Windows. De manière générale, les terminaux se connectant depuis l’extérieur du site par une connexion Internet, qui ne sont donc pas sur le même domaine Windows, ne pourront pas non plus accéder à la supervision via le nom d’hôte. La résolution du nom par Windows fonctionnera très bien pour des terminaux Windows accédant à la supervision depuis le site ou via un VPN en cas d’accès distant.

On a vu qu’il est nécessaire de fonctionner en https, ce qui implique l’utilisation d’un certificat de sécurité. Que ce certificat de sécurité soit auto-signé, émis par le contrôleur de domaine Windows ou un organisme tiers, il ne sera d’aucune utilité si l’accès au serveur web se fait avec son adresse IP ou le nom de la machine, car un certificat ne peut être émis que pour un nom d’hôte ou un nom de domaine public (dans ce dernier cas, seul le certificat émis par un tiers est possible). L’utilisateur se verra notifié d’une alerte sécurité par son navigateur web s’il utilise l’adresse IP ou le nom de la machine pour accéder à la supervision. Typiquement si des accès depuis l’extérieur du site (Internet) sont prévus, on a besoin que le terminal tiers puisse faire confiance au serveur, un certificat émis par un tiers de confiance est alors nécessaire, cela implique l’utilisation d’un nom de domaine public et d’un DNS pour la résolution de nom (le tiers de confiance ne sait vérifier le nom de domaine que si celui-ci est déclaré dans un DNS public).

Les clients web apportent des avantages indéniables en facilité de déploiement pour un usage en poste fixe et répondent aux attentes des utilisateurs nomades. Cependant, il est important de garder en tête les prérequis techniques pour un déploiement tenant compte des risques cyber ; utilisation du protocole https, mise en œuvre d’un certificat de sécurité pour le serveur web, segmentation du réseau et gestion du nom de domaine. Automaticiens et informaticiens collaboreront encore un peu plus.

Dans un second article, découvrez deux exemples d’architecture, avantages, inconvénients et risques.