Sécurité OT MQTT : protéger les usines qui envoient leurs données vers le cloud

La sécurité OT MQTT consiste à faire sortir les données d'une usine sans créer de nouvelle porte d'entrée. Ce guide présente les modèles réseau qui fonctionnent, comme les connexions sortantes uniquement, les passerelles en DMZ et la segmentation, ainsi que la gestion des identifiants et la surveillance des données d'usine envoyées vers un broker cloud. À la fin, vous disposerez d'une architecture de référence et d'une checklist à discuter avec vos équipes OT et IT.

Pourquoi les réseaux OT exigent une approche différente

Les réseaux de technologie opérationnelle (OT) pilotent des équipements qui déplacent, chauffent, mélangent et découpent. Ils diffèrent de l'informatique de bureau d'une manière qui façonne chaque décision de sécurité :

• La disponibilité passe avant tout. Un contrôle de sécurité qui arrête la production est souvent considéré comme un risque plus grand que la menace qu'il traite.
• Des cycles de vie longs. Les automates et les IHM restent en service pendant de nombreuses années, souvent avec un firmware impossible à mettre à jour rapidement.
• Des protocoles hérités. Modbus, les anciennes versions de Profinet et de nombreux protocoles série n'ont aucune authentification.
• Des conséquences physiques. Une commande falsifiée peut endommager un équipement ou blesser des personnes, et pas seulement faire fuiter des données.

MQTT est bien adapté à cet environnement, car il inverse le sens habituel du trafic. Au lieu qu'une application cloud pénètre dans l'usine pour interroger les machines, une passerelle située dans l'usine pousse les données vers l'extérieur. Bien mis en œuvre, cela signifie aucune règle de pare-feu entrante vers le réseau OT.

Le principe central : des connexions sortantes uniquement

Chaque client MQTT ouvre une connexion TCP vers le broker, jamais l'inverse. Une passerelle d'usine qui publie vers un broker cloud n'a donc besoin que d'une seule règle de pare-feu : TCP sortant vers le nom d'hôte du broker sur le port 8883.

Sortant uniquement ne signifie pas sans risque. La passerelle entretient toujours une session TCP avec le monde extérieur, et si elle s'abonne à des topics de commande, des données peuvent revenir vers l'intérieur. La question de conception devient : qu'accepte la passerelle, et comment le valide-t-elle ?

Architecture de référence

Une conception en couches qui convient à la plupart des usines, inspirée des niveaux du modèle Purdue :

1. Niveaux 0–1 : appareils de terrain et automates. Aucune route vers Internet. Uniquement des protocoles industriels.
2. Niveau 2 : réseau de supervision. IHM et SCADA. Toujours aucune route vers Internet.
3. Niveau 3/3.5 : DMZ industrielle. La passerelle edge se trouve ici. Elle lit le niveau 2 (par exemple via OPC UA ou Modbus TCP) à travers un pare-feu qui n'autorise que ces flux précis.
4. Niveaux 4–5 : entreprise et cloud. La passerelle publie vers le broker MQTT cloud via TLS. Les tableaux de bord, l'analytique, les historiens et un éventuel jumeau numérique de l'usine s'abonnent depuis ce niveau.

Passerelle unique ou broker en DMZ ?

Deux variantes courantes fonctionnent bien :

• La passerelle publie directement vers le broker cloud. L'option la plus simple : une seule connexion sortante, avec store-and-forward sur la passerelle en cas de coupure.
• Un broker local en DMZ fait le pont vers le cloud. Les machines ou les passerelles publient vers un broker situé dans la DMZ, et un unique client de bridge ou de relais transmet certains topics vers l'extérieur. Cela ajoute un tampon local et un point unique pour inspecter et filtrer le trafic, au prix d'un système de plus à mettre à jour et à surveiller.

Dans les deux cas, l'atelier ne communique jamais directement avec Internet. Pour comprendre comment un broker achemine les données, consultez ce que fait un broker MQTT.

Les règles de segmentation qui comptent

Rédigez les règles de pare-feu de sorte que chacune ait une raison que vous pouvez expliquer :

# Pare-feu OT (entre le niveau 2 et la DMZ)
ALLOW  gateway-01  -> plc-line1:4840/tcp   (OPC UA read)
ALLOW  gateway-01  -> plc-line2:502/tcp    (Modbus TCP read)
DENY   any         -> any                   (default)

# Pare-feu périmétrique (DMZ vers Internet)
ALLOW  gateway-01  -> YOUR_BROKER_HOST:8883/tcp   (MQTT over TLS)
ALLOW  gateway-01  -> ntp-server:123/udp          (time sync for TLS)
DENY   any         -> any                          (default)
DENY   internet    -> DMZ                          (no inbound)

Gardez ces points à l'esprit :

• Préférez des noms d'hôte avec filtrage sortant sur un proxy ou un pare-feu de nouvelle génération lorsque les adresses IP du broker peuvent changer.
• N'autorisez que le port 8883. MQTT en clair sur le 1883 ne doit jamais sortir de l'usine.
• L'exactitude de l'heure compte : la validation des certificats TLS échoue sur les passerelles dont l'horloge est fausse.
• Journalisez les connexions refusées côté OT ; des tentatives sortantes inattendues sont un signal d'alerte précoce.

Gestion des identifiants pour les passerelles

Les passerelles d'usine fonctionnent souvent sans surveillance pendant des années ; les identifiants doivent donc être gérés avec soin dès le premier jour.

1. Une identité par passerelle. Si une passerelle est compromise, révoquez-la sans toucher aux autres.
2. Des identités distinctes pour des rôles distincts. Un publieur de télémétrie et un récepteur de commandes ne doivent pas partager d'identifiants.
3. Stockez les secrets hors du code source, dans un fichier de configuration protégé ou dans le magasin de secrets du système d'exploitation, lisible uniquement par le compte de service de la passerelle.
4. Effectuez une rotation planifiée et événementielle, par exemple lors de changements de personnel ou d'une compromission suspectée. Le guide sur la rotation des identifiants MQTT présente une approche limitant les interruptions.
5. Ne réutilisez jamais les identifiants de l'usine sur des brokers de test. N'utilisez le serveur MQTT public gratuit qu'avec des client IDs jetables et des données fictives : il est réservé aux tests et aux prototypes.

Sur ConnectMQ, chaque broker reçoit des identifiants générés, et les client IDs sont liés à ces identifiants ; un client ID divulgué ne peut donc pas, à lui seul, servir à se connecter. Les échecs de connexion répétés entraînent un blocage d'IP, ce qui limite les tentatives de devinette de mot de passe contre les comptes de vos passerelles.

Gérer les commandes en toute sécurité

Si le cas d'usage exige des consignes à distance ou des changements de recette, traitez le chemin de commande comme un conduit distinct à risque plus élevé :

• Utilisez des topics de commande dédiés et une identité d'abonné distincte.
• Validez chaque commande sur la passerelle au regard d'une liste autorisée : quelle variable, quelle plage, quelles unités.
• Exigez un topic de réponse ou d'acquittement, pour que les opérateurs voient ce qui s'est réellement passé. Les response topics de MQTT 5 sont utiles ici.
• Conservez une possibilité de reprise en main locale et assurez-vous que les équipements se mettent en position de sécurité si le broker est injoignable.
• Ne transmettez jamais de payloads bruts à un automate.

De nombreuses usines décident que le chemin cloud reste en lecture seule et que les écritures ne passent que par les IHM locales. C'est un choix légitime et courant.

Surveillance et disponibilité

En OT, la sécurité inclut la disponibilité. Anticipez ces situations :

• Panne du broker ou d'Internet : la passerelle met les données en tampon localement et les renvoie avec un backoff au retour de la connexion. L'expiration des messages empêche que des données périmées soient rejouées des heures plus tard.
• Défaillance de la passerelle : abonnez-vous à $SYS/broker/connection/{clientId}/state sur ConnectMQ ou utilisez un last will pour que les tableaux de bord affichent la passerelle comme hors ligne.
• Trafic inhabituel : une passerelle qui publie soudain à dix fois son débit normal, ou qui se connecte depuis une nouvelle adresse IP, mérite une investigation.
• Limites de quota : le reason code MQTT 5 0x97 vous indique qu'un quota de l'offre a été dépassé, ce qui permet de le distinguer d'un problème réseau.

Le tableau de bord du portail ConnectMQ, la vue des appareils par niveau ISA-95 et les règles d'alerte sur seuils aident les équipes d'exploitation à suivre tout cela sans développer d'outils sur mesure.

Checklist de sécurité OT pour MQTT

1. Aucune règle de pare-feu entrante vers le réseau OT pour MQTT.
2. La passerelle se trouve dans une DMZ et lit les automates via des règles étroitement délimitées.
3. Seul TLS sur le port 8883 sort du site, avec validation du certificat serveur et une heure exacte.
4. Une identité unique et révocable par passerelle et par rôle.
5. Les chemins de commande sont séparés, validés et à sécurité intégrée, ou totalement absents.
6. Les passerelles mettent les données en tampon pendant les coupures et se reconnectent avec un backoff.
7. L'état de connexion des passerelles et les débits de messages sont surveillés.
8. Les responsabilités entre l'usine, l'IT et le fournisseur du broker sont documentées.

Pour l'aspect normatif du même sujet, lisez IEC 62443 et MQTT. Le guide l'IoT industriel avec MQTT traite de la modélisation des données, et les bonnes pratiques de sécurité MQTT couvrent le durcissement général des clients.

Connectez votre usine à ConnectMQ en toute sécurité

Vous pouvez tester cette conception sur une seule passerelle en un après-midi. Créez un broker privé sur l'offre gratuite Serverless sur app.connectmq.com (sans carte bancaire), ouvrez une règle sortante pour le port 8883 et publiez votre premier topic ISA-95 via TLS. Lorsque la production exige de l'isolation, un broker MQTT managé en déploiement Dedicated ou BYOC conserve la même configuration client.

Questions fréquentes

MQTT exige-t-il d'ouvrir des ports entrants vers l'usine ?

Non. Les clients MQTT se connectent vers l'extérieur, au broker ; une passerelle d'usine n'a donc besoin que d'une règle sortante vers le port 8883. Les commandes éventuelles reviennent par cette même connexion.

Les automates doivent-ils se connecter directement à un broker cloud ?

En général, non. Maintenir les automates sur un réseau isolé et placer une passerelle edge dans une DMZ limite l'exposition et vous permet de contrôler précisément ce qui sort de l'usine.

Faut-il un VPN pour MQTT entre l'usine et le cloud ?

Généralement pas. MQTT sur TLS avec validation du certificat serveur et des identifiants clients robustes fournit un canal chiffré et authentifié sans VPN.

Que deviennent les données lorsque la connexion Internet tombe ?

Une passerelle bien conçue met les données en tampon localement et les renvoie après s'être reconnectée avec un backoff. L'expiration des messages permet d'écarter les valeurs devenues inutiles.