IEC 62443 et MQTT : sécuriser la messagerie industrielle avec zones et conduits

Concevoir une architecture IEC 62443 MQTT, c'est placer un flux de données MQTT dans le modèle de zones et de conduits que les équipes de sécurité industrielle utilisent déjà. Ce guide fait correspondre les principaux concepts de l'IEC 62443 à une architecture typique composée d'automates, de passerelles edge et d'un broker cloud, afin que vous puissiez présenter votre conception dans le langage qu'attendent vos auditeurs de sécurité OT. Il s'agit d'un guide d'ingénierie, pas d'un conseil juridique ou de certification : la conformité s'évalue pour votre système et votre organisation, elle n'est pas conférée par un produit isolé.

Une brève introduction à l'IEC 62443

L'IEC 62443 est une série de normes consacrées à la sécurité des systèmes d'automatisation et de contrôle industriels (IACS). Elle s'adresse à plusieurs publics : les propriétaires d'actifs qui exploitent des usines, les intégrateurs système qui construisent des solutions et les fournisseurs de produits qui fabriquent des composants. Quelques concepts comptent particulièrement pour la conception de la messagerie :

• Zones : des groupes d'actifs partageant des exigences de sécurité communes, comme une cellule d'automates ou un réseau informatique d'entreprise.
• Conduits : les chemins de communication entre zones, avec leurs propres exigences de sécurité.
• Exigences fondamentales (FR) : sept catégories qui structurent les exigences techniques : contrôle de l'identification et de l'authentification, contrôle d'utilisation, intégrité du système, confidentialité des données, flux de données restreint, réponse rapide aux événements et disponibilité des ressources.
• Niveaux de sécurité (SL) : des objectifs de SL 1 à SL 4 qui décrivent la capacité de l'attaquant auquel la zone ou le conduit doit résister, de l'usage abusif occasionnel aux attaques sophistiquées et bien dotées en moyens.
• Appréciation des risques : le processus (décrit dans la partie 3-2) qui détermine les zones, les conduits et les niveaux de sécurité cibles.

Plusieurs parties concernent les projets MQTT. La partie 3-3 liste les exigences de sécurité du système, la partie 4-2 couvre les exigences relatives aux composants et la partie 2-1 traite du programme de sécurité du propriétaire d'actifs.

Pourquoi MQTT s'intègre au modèle zones et conduits

MQTT possède une propriété qu'apprécient les architectes sécurité : les clients se connectent toujours vers l'extérieur, en direction du broker. Une passerelle d'automate publie vers un broker ; rien n'a besoin de se connecter en entrée vers l'usine. Le chemin de communication est donc facile à décrire comme un conduit unique avec une direction, un protocole et un port définis.

Comparez avec les protocoles d'interrogation (polling), où un système central pénètre dans le réseau de l'usine pour lire des valeurs. Chaque interrogation est un flux entrant qu'il faut autoriser à travers les pare-feu. Avec MQTT, l'usine est à l'initiative et le pare-feu peut rester fermé en entrée.

Faire correspondre une architecture MQTT aux zones et conduits

Une architecture MQTT industrielle typique comporte quatre zones :

Et trois conduits :

1. Conduit contrôle-edge : accès en lecture seule, via un protocole industriel, de la passerelle aux automates.
2. Conduit edge-broker : MQTT sur TLS sur le port 8883, sortant uniquement, de la passerelle ou de la DMZ vers le broker.
3. Conduit broker-consommateurs : MQTT sur TLS des applications d'analytique et des tableaux de bord vers le broker.

Les niveaux de sécurité cibles du tableau ne sont volontairement pas figés. Ils découlent de votre appréciation des risques, et une même architecture peut relever du SL 2 dans une usine et du SL 3 dans une autre.

Documenter chaque conduit

Pour chaque conduit, consignez : les extrémités, le sens d'établissement de la connexion, le protocole et le port, la méthode d'authentification, le chiffrement, les topics ou données autorisés et ce qui se passe en cas de défaillance. Les auditeurs demanderont précisément ces détails.

Appliquer les exigences fondamentales à MQTT

Les commandes méritent leur propre analyse

Faire sortir de la télémétrie d'une usine représente un certain niveau de risque. Faire entrer des commandes dans une usine en représente un autre. De nombreuses organisations maintiennent le conduit cloud strictement en lecture seule et gèrent les écritures localement. Si vous avez besoin de consignes à distance, séparez-les : topics différents, identifiants différents, validation sur la passerelle et limites sur les valeurs que la passerelle transmettra à l'automate. La zone de contrôle ne doit jamais exécuter des payloads bruts provenant d'un broker.

La place d'un broker MQTT managé

Dans ce modèle, le broker cloud constitue une zone et la liaison edge-broker un conduit. Un broker MQTT managé ne rend pas votre système conforme à l'IEC 62443, et vous devriez vous méfier de tout fournisseur qui le laisse entendre. Ce qu'il peut faire, c'est fournir des contrôles que vous référencez dans votre propre évaluation.

ConnectMQ fournit les contrôles suivants, qui peuvent étayer une telle évaluation :

• TLS sur le port 8883 et WebSockets sécurisés sur le 8084, avec un certificat Let's Encrypt (FR3, FR4).
• Authentification par identifiants générés, avec des client IDs liés à ces identifiants (FR1).
• Isolation multi-tenant, ou cluster isolé avec les offres Dedicated, ou déploiement dans votre propre compte cloud avec BYOC (FR5).
• Quotas par offre avec le reason code MQTT 5 0x97, protection contre le flooding et blocage d'IP après des échecs de connexion répétés (FR6, FR7).
• Visibilité de l'état des connexions via $SYS/broker/connection/{clientId}/state, ainsi que des tableaux de bord dans le portail et des règles d'alerte sur seuils (FR6).

ConnectMQ ne propose pas d'ACL par topic ; utilisez donc des brokers ou des identifiants distincts par zone de confiance lorsqu'une séparation au niveau des topics est requise, et appliquez le filtrage des commandes sur votre passerelle edge. Consignez ces responsabilités dans votre matrice de responsabilité partagée. Le guide du broker MQTT cloud compare les modèles partagé, dédié et BYOC, ce qui compte souvent pour la conception des zones.

Exemple : une passerelle edge qui publie vers la zone du broker

C'est sur la passerelle que se concentre l'essentiel du travail de sécurité. Une passerelle Python minimale qui lit des valeurs en local et les publie via TLS pourrait ressembler à ceci :

import json
import time
import paho.mqtt.client as mqtt

BROKER = "YOUR_BROKER_HOST"  # depuis le portail ConnectMQ
TOPIC = "connectmq/plant1/production/line1/press1/telemetry"

def read_plc_values():
    # Remplacer par votre lecture OPC UA ou Modbus ; la passerelle ne fait que lire.
    return {"pressure_bar": 182.4, "cycle_count": 50123, "state": "RUNNING"}

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()  # vérifier le certificat du broker avec les CA du système
client.reconnect_delay_set(min_delay=2, max_delay=300)

client.connect(BROKER, 8883, keepalive=60)
client.loop_start()

while True:
    payload = read_plc_values()
    payload["ts"] = int(time.time())
    client.publish(TOPIC, json.dumps(payload), qos=1)
    time.sleep(10)

Remarquez ce qui est absent : aucun port entrant sur la passerelle, aucun abonnement à des topics de commande, aucun identifiant partagé avec d'autres passerelles. Le topic suit une hiérarchie de type ISA-95, ce qui rend aussi vos frontières de zones visibles dans le modèle de données. Le guide l'IoT industriel avec MQTT explique cette structure plus en détail.

Checklist d'audit pour une conception IEC 62443 MQTT

1. Une appréciation des risques définit les zones, les conduits et les niveaux de sécurité cibles des flux MQTT.
2. Chaque connexion MQTT franchissant une frontière de zone utilise TLS et vérifie le certificat du serveur.
3. Toutes les connexions sont initiées depuis l'usine vers l'extérieur ; aucun port entrant vers la zone de contrôle.
4. Chaque passerelle et chaque application disposent d'identifiants uniques et révocables.
5. Les chemins de commande sont séparés de la télémétrie et validés sur la passerelle.
6. Les passerelles mettent les données en mémoire tampon lorsque le conduit est coupé et se rétablissent sans provoquer de flood.
7. L'état des connexions, les échecs de connexion et les débits anormaux sont surveillés, avec une réponse définie.
8. Les responsabilités partagées avec le fournisseur du broker sont documentées.

Pour le volet réseau de cette checklist, lisez la sécurité MQTT pour les réseaux OT, et pour le volet identité, l'article sur le zero trust pour la messagerie IoT.

Construisez votre conduit de données industrielles sur ConnectMQ

Vous pouvez prototyper le conduit edge-broker dès aujourd'hui. Le serveur MQTT public gratuit suffit pour valider des payloads simulés, mais il est réservé aux tests et ne doit jamais recevoir de données d'usine. Créez un broker privé sur l'offre gratuite Serverless sur app.connectmq.com (sans carte bancaire), connectez une passerelle via TLS et regardez les topics ISA-95 apparaître dans la vue des appareils du portail. Lorsque la conception exige de l'isolation, un broker MQTT managé en déploiement Dedicated ou BYOC conserve la même configuration client. Les bonnes pratiques de sécurité MQTT plus générales s'appliquent tout du long.

Questions fréquentes

MQTT est-il autorisé par l'IEC 62443 ?

L'IEC 62443 n'interdit ni n'impose de protocoles spécifiques. Elle exige que les communications entre zones respectent les exigences de sécurité de leur conduit, ce que MQTT sur TLS avec une authentification forte peut satisfaire.

Un broker MQTT cloud peut-il être certifié IEC 62443 pour mon usine ?

La certification s'applique à des produits, processus ou systèmes précis, au regard de parties précises de la norme. La conformité de votre système global est évaluée pour votre usine ; un fournisseur de broker ne peut que fournir des contrôles que vous référencez dans cette évaluation.

Les commandes doivent-elles circuler du cloud vers l'usine ?

Seulement si l'appréciation des risques le permet. De nombreux sites gardent le conduit cloud en lecture seule, et ceux qui autorisent les commandes les séparent, les valident sur la passerelle et limitent ce qui peut être modifié.

Faut-il un broker local dans la DMZ ?

Pas toujours. Un broker en DMZ ajoute une mise en mémoire tampon et un point d'inspection, tandis qu'une passerelle publiant directement vers un broker cloud via TLS est plus simple. L'appréciation des risques et le niveau de sécurité cible tranchent.