Exposer les données d’un automate par une API : architecture sûre

La demande arrive souvent en ces termes : « Il nous faudrait une API sur l’automate. » Le service qualité veut suivre les températures en continu, la maintenance veut les compteurs d’heures, la direction veut un tableau de bord. Un intégrateur pressé propose la solution la plus courte : ouvrir le port Modbus de l’automate au réseau de l’entreprise et laisser une application l’interroger. C’est précisément ce qu’il ne faut pas faire. Une API pour automates se conçoit comme une architecture en couches, dont l’automate n’est que la source lointaine.

Pourquoi on ne branche pas une API sur l’automate

Un automate programmable est conçu pour exécuter un programme de commande de façon prévisible, cycle après cycle. Il n’est pas un serveur. Trois raisons interdisent de l’exposer directement.

La première tient aux protocoles. Beaucoup de protocoles industriels répandus, comme Modbus TCP, ont été conçus à une époque où les réseaux d’atelier étaient isolés. Ils ne prévoient ni authentification ni chiffrement : quiconque atteint l’automate sur le réseau peut lire ses registres, et souvent y écrire. Une API qui l’interroge directement hérite de cette faiblesse, et l’étend à tout le réseau d’entreprise.

La deuxième tient à la charge. Des requêtes fréquentes, venant de plusieurs applications, consomment des ressources de communication de l’automate. Sur les modèles anciens, elles peuvent ralentir les échanges avec la supervision, voire perturber le fonctionnement de la machine.

La troisième tient à la surface d’attaque. Des moteurs de recherche spécialisés recensent en permanence les équipements industriels accessibles depuis internet, et les retours d’expérience publiés par les autorités de cybersécurité montrent que les attaquants les trouvent. Un automate joignable depuis le réseau bureautique est à quelques étapes d’un automate joignable depuis l’extérieur.

L’architecture en couches

La série de normes IEC 62443, référence internationale de la cybersécurité des systèmes industriels, organise un site en zones regroupant des équipements de même niveau de sécurité, reliées par des conduits dont les flux sont contrôlés. Appliqué à l’exposition des données, ce principe donne une architecture en quatre couches.

Dans la zone de contrôle, les automates et la supervision restent inchangés. On n’y installe rien de nouveau qui ne soit indispensable.

Le collecteur, au plus près de l’atelier, lit les variables utiles, par OPC UA lorsque l’automate le propose, ou par son protocole natif sinon. Il ne lit qu’une liste fermée de variables, définie dans un dictionnaire des signaux, et son compte n’a aucun droit d’écriture.

La zone tampon héberge ce qui doit être partagé : l’historien qui conserve les séries temporelles, un courtier de messages qui diffuse les événements, et l’API publiée. Les flux de l’atelier vers cette zone sont initiés depuis l’atelier ; aucune connexion entrante n’est ouverte vers la zone de contrôle.

Le système d’information n’accède qu’à l’API, à travers un second pare-feu. Une compromission de ce côté n’offre pas de chemin direct vers les machines.

Lire sans pouvoir écrire

La lecture seule ne doit pas reposer sur une seule protection. Elle se garantit à plusieurs niveaux, de sorte qu’une erreur de configuration à l’un d’eux ne suffise pas à ouvrir l’écriture : compte de lecture côté automate ou serveur OPC UA, absence de fonctions d’écriture dans le collecteur, règles de pare-feu n’autorisant que les flux sortants, et, pour les installations les plus sensibles, diode de données garantissant physiquement le sens unique.

Choisir les protocoles de chaque couche

Chaque couche a son protocole naturel, et la combinaison compte davantage que le choix d’un protocole unique.

OPC UA est bien adapté à la collecte. Il décrit les données avec leur type, leur unité et leur statut de qualité, et il intègre des mécanismes de sécurité : authentification par certificats, signature et chiffrement des échanges. Encore faut-il les activer ; de nombreux serveurs sont livrés avec des modes de sécurité permissifs par défaut.

MQTT, protocole léger fondé sur la publication et l’abonnement, convient à la diffusion d’événements vers de nombreux consommateurs. Il doit être utilisé avec chiffrement et authentification des clients. La spécification Sparkplug, portée par la fondation Eclipse, ajoute une structure commune aux messages industriels, ce qui évite à chaque projet de réinventer la sienne.

Une API web documentée, décrite par exemple avec la spécification OpenAPI, est la forme la plus simple à consommer pour les applications métier et les équipes informatiques. Elle sert les données historisées et l’état courant, sans jamais relayer une requête jusqu’à l’automate.

Sécuriser l’API elle-même

L’API publiée dans la zone tampon est une API d’entreprise comme une autre, et doit être traitée comme telle. Le Top 10 de la sécurité des API publié par l’OWASP en donne les principaux risques : contrôles d’accès insuffisants objet par objet, authentification faible, absence de limitation du nombre de requêtes, exposition excessive de données.

Concrètement : chaque application cliente s’authentifie avec ses propres identifiants, renouvelés régulièrement ; ses droits sont limités aux machines et aux variables dont elle a besoin ; le nombre de requêtes est plafonné ; chaque appel est journalisé ; l’API est versionnée, pour que l’évolution d’un format ne casse pas silencieusement un tableau de bord. Ces mesures sont banales en informatique de gestion. Elles sont encore trop rarement appliquées aux données industrielles, considérées à tort comme peu sensibles.

Elles ne le sont pas : les données de production révèlent des cadences, des volumes, des recettes et des défaillances qui intéressent les concurrents autant que les attaquants.

Avant la mise en service

• Le dictionnaire des signaux exposés est écrit, validé par l’automaticien et par le responsable de production.
• Aucune connexion entrante n’est ouverte vers la zone de contrôle ; les règles de pare-feu ont été relues par une seconde personne.
• La lecture seule est garantie à au moins deux niveaux indépendants.
• Les modes de sécurité d’OPC UA et le chiffrement de MQTT sont activés, avec des certificats gérés et datés.
• L’API impose une authentification par application, des droits limités, des quotas et une journalisation.
• Une panne de la zone tampon a été simulée : la production continue sans être affectée.
• Les responsabilités sont réparties : qui surveille, qui met à jour, qui décide d’ajouter une variable.

Cette architecture prolonge celle que nous décrivons dans notre dossier de référence sur les automates et le système d’information, et notre article sur le raccordement des machines anciennes traite le cas des équipements sans connectivité native. Notre expertise industrie et automates accompagne sa conception et sa mise en service, avec les automaticiens du site.

Questions fréquentes

Peut-on interroger directement un automate depuis une application métier ?

Techniquement oui, mais c'est déconseillé. Beaucoup de protocoles industriels n'authentifient pas les requêtes et permettent l'écriture aussi facilement que la lecture. Les requêtes répétées peuvent aussi perturber le cycle de l'automate. Il est plus sûr de passer par un collecteur en lecture seule et une zone tampon.

OPC UA ou MQTT : lequel choisir ?

Les deux sont complémentaires. OPC UA décrit finement les données et intègre des mécanismes de sécurité ; il convient bien à la collecte au plus près des machines. MQTT, léger et fondé sur la publication d'événements, convient bien à la diffusion vers de nombreux consommateurs. Beaucoup d'architectures combinent OPC UA en collecte et MQTT ou une API web en diffusion.

Faut-il une diode de données ?

Pour les installations les plus sensibles (énergie, eau, sites classés), une diode, qui garantit physiquement un flux à sens unique, apporte une assurance que la configuration d'un pare-feu ne donne pas. Pour une usine classique, des règles de filtrage strictes, des flux initiés depuis l'atelier et une surveillance régulière suffisent souvent, selon l'analyse de risque.

Peut-on aussi envoyer des consignes à l'automate par l'API ?

Seulement par un chemin distinct, conçu à part, avec authentification forte, validation des valeurs, bornes contrôlées par le programme de l'automate lui-même et journalisation complète. L'écriture change la nature du risque : elle doit faire l'objet d'une analyse spécifique, jamais d'une simple option activée sur l'API de lecture.