Une DMZ MQTT est la zone réseau par laquelle les données d'usine quittent le réseau des technologies opérationnelles (OT) pour rejoindre les systèmes cloud et d'entreprise, sans laisser quoi que ce soit venant de l'extérieur y revenir. Dans ce guide, vous verrez pourquoi MQTT convient si bien à une DMZ, les trois schémas de placement qui fonctionnent en pratique, les règles de pare-feu exactes à demander, et une configuration de bridge opérationnelle qui transmet les données OT vers un broker cloud via TLS.
Pourquoi MQTT convient à une DMZ industrielle
La plupart des architectures de sécurité industrielle suivent une variante du modèle Purdue ou des zones et conduits de l'IEC 62443. Les niveaux 0 à 2 regroupent capteurs, automates et IHM, le niveau 3 les opérations du site comme le SCADA et les historiens, et entre le niveau 3 et le réseau d'entreprise (niveau 4 et au-delà) se trouve une DMZ industrielle, souvent appelée niveau 3.5. La règle de la DMZ est simple : aucun trafic ne la traverse directement. Chaque flux se termine dans la DMZ et un nouveau flux repart de là.
Les protocoles d'intégration classiques s'accommodent mal de cette règle. Les protocoles par interrogation comme OPC DA, Modbus TCP ou une interface de requête d'historien attendent du consommateur qu'il ouvre une connexion vers le producteur. Cela signifie une connexion entrante dans le réseau OT, précisément ce que l'équipe sécurité veut éviter.
MQTT inverse le sens. Chaque participant est un client qui se connecte vers un broker. Une passerelle côté OT ouvre une connexion TCP sortante, s'authentifie et publie. Les consommateurs côté IT ou cloud se connectent eux aussi vers le broker et s'abonnent. Personne n'a jamais besoin d'ouvrir un port en écoute dans l'atelier. Une fois que vous avez compris le rôle d'un broker MQTT comme point de rencontre de ces connexions sortantes, il devient beaucoup plus simple de raisonner sur la conception de la DMZ.
Trois schémas de placement pour une DMZ MQTT
Il n'existe pas de conception unique correcte. Le bon schéma dépend de la sévérité de votre politique de zones et du nombre de sites.
| Schéma | Emplacement du broker | Flux depuis l'OT | Idéal pour |
|---|---|---|---|
| A. Sortant direct | Uniquement dans le cloud | La passerelle OT se connecte en sortie, à travers le pare-feu, au broker cloud | Petits sites, projets pilotes, sites sans DMZ formelle |
| B. Broker bridge en DMZ | Broker local dans la DMZ, relié au cloud par un bridge | La passerelle OT se connecte au broker de la DMZ ; celui-ci se connecte en sortie au cloud | Sites appliquant strictement la règle « aucun flux ne traverse la DMZ » |
| C. Passerelle en DMZ | Logiciel de passerelle dans la DMZ, broker cloud | La passerelle OT ou le serveur OPC UA est lu par une passerelle en DMZ, qui publie vers le cloud | Usines où rien ne peut être installé aux niveaux 2 ou 3 |
Schéma A : connexions sortantes uniquement vers un broker cloud
La passerelle se trouve au niveau 3 et ouvre une connexion TLS sur le port 8883 directement vers un broker MQTT cloud. Le pare-feu autorise une seule destination sortante et un seul port. Le trafic de retour ne circule que sur cette session établie. Ce schéma se déploie rapidement et est parfaitement acceptable pour de nombreuses usines, mais il laisse techniquement une session traverser la DMZ, ce que certaines politiques interdisent.
Schéma B : un broker bridge dans la DMZ
Un petit broker comme Mosquitto tourne sur un hôte durci dans la DMZ. Les passerelles OT s'y connectent depuis le bas, et le broker de la DMZ ouvre sa propre connexion bridge sortante vers le cloud. Deux sessions distinctes, deux jeux d'identifiants distincts, et l'hôte de la DMZ est la seule machine à dialoguer avec internet. Si la liaison cloud tombe, le bridge met en file les messages QoS 1 localement, ce qui se combine naturellement avec le store-and-forward MQTT sur les passerelles.
Schéma C : une passerelle de protocole dans la DMZ
Parfois, rien de nouveau ne peut être installé dans la zone OT. Dans ce cas, une passerelle dans la DMZ lit une interface existante, par exemple un serveur OPC UA exposé à la DMZ par une règle étroite, et publie en MQTT vers le haut. C'est le schéma le moins élégant, puisque la DMZ initie désormais une connexion vers l'OT, mais il garde le cloud totalement isolé de l'usine. Notre guide de la passerelle edge IIoT explique comment choisir cette passerelle.
Règles de pare-feu pour une DMZ MQTT
Quel que soit le schéma choisi, rédigez les règles avant la demande de changement. Les équipes pare-feu approuvent plus vite des règles précises que des règles vagues.
| Règle | Source | Destination | Port | Sens |
|---|---|---|---|---|
| 1 | Passerelle OT (niveau 3) | Broker de la DMZ | TCP 8883 (ou 1883 au sein d'un segment de confiance) | OT vers DMZ |
| 2 | Broker de la DMZ | Nom d'hôte du broker cloud | TCP 8883 | DMZ vers internet |
| 3 | Consommateurs IT | Nom d'hôte du broker cloud | TCP 8883 ou 8084 (WSS) | Entreprise vers internet |
| 4 | Tout | Zone OT | Tout | Refus |
| 5 | Internet | Broker de la DMZ | Tout | Refus |
Quelques remarques pratiques :
- Utilisez le nom d'hôte du broker, pas une adresse IP, dans la règle sortante, ou un objet FQDN si votre pare-feu le permet. Les IP cloud peuvent changer.
- Autorisez la résolution DNS pour l'hôte de la DMZ, soit vers un résolveur interne, soit vers un serveur amont précis.
- Tenez le port 1883 en clair totalement à l'écart d'internet. Utilisez le 8883 avec TLS pour tout ce qui quitte le site.
- Si un proxy d'inspection TLS se trouve sur le chemin, excluez le nom d'hôte du broker. L'inspection casse la validation des certificats et les sessions MQTT longue durée.
- Les timeouts d'inactivité comptent. Certains pare-feux coupent les sessions TCP inactives au bout de quelques minutes : réglez le keepalive MQTT en dessous du timeout d'inactivité du pare-feu, par exemple 60 secondes.
Exemple : un bridge Mosquitto de la DMZ vers un broker cloud
La configuration suivante met en œuvre le schéma B. Le broker de la DMZ n'écoute que sur son interface tournée vers l'OT et transmet par bridge certains topics vers un broker ConnectMQ via TLS. Remplacez les identifiants par le nom d'utilisateur, le mot de passe et le client ID générés dans le portail.
# /etc/mosquitto/conf.d/dmz.conf
# Écouter uniquement sur l'interface tournée vers la zone OT
listener 8883 10.20.0.5
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/dmz-broker.crt
keyfile /etc/mosquitto/certs/dmz-broker.key
allow_anonymous false
password_file /etc/mosquitto/passwd
# Bridge sortant vers le broker cloud
connection connectmq-cloud
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
bridge_capath /etc/ssl/certs
bridge_insecure false
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
try_private false
keepalive_interval 60
restart_timeout 10 120
# Ne transmettre que la télémétrie de l'usine, uniquement vers le haut
topic factory1/# out 1 "" connectmq/
La ligne topic est l'endroit où la politique de la DMZ est appliquée de façon logicielle : out signifie que les messages ne circulent que du broker de la DMZ vers le cloud, jamais dans l'autre sens. Un topic local factory1/line1/cnc1/telemetry arrive dans le cloud sous la forme connectmq/factory1/line1/cnc1/telemetry. Utilisez try_private false car l'extrémité distante n'est pas une autre instance Mosquitto, et gardez bridge_insecure false afin que le certificat Let's Encrypt du point de connexion cloud soit validé avec le magasin de certificats du système.
Testez le chemin depuis l'hôte de la DMZ avant d'impliquer la moindre donnée d'automate :
# Sur l'hôte de la DMZ : publier un message de test local
mosquitto_pub -h 10.20.0.5 -p 8883 --cafile /etc/mosquitto/certs/ca.crt \
-u gateway01 -P 'local-secret' -i dmz-test-01 \
-t factory1/test/hello -m '{"status":"ok"}' -q 1
# Depuis toute machine ayant accès au broker cloud : vérifier l'arrivée
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-reader \
-t 'connectmq/factory1/#' -v
Notez que ConnectMQ lie les client ID aux identifiants émis : le second client a donc besoin de son propre jeu d'identifiants issu du portail plutôt que d'un ID inventé. Pour des essais avant d'avoir des identifiants, vous pouvez pointer le bridge vers le serveur MQTT public gratuit sur le port 1883 avec un préfixe unique comme connectmq/demo/<random-id>/, mais n'envoyez jamais de vraies données d'usine vers une zone publique.
Les commandes doivent-elles redescendre ?
Faire remonter la télémétrie est la partie facile. La question la plus délicate est de savoir si quelque chose doit redescendre : changements de consigne, téléchargements de recettes, acquittements. Pour un premier déploiement, la bonne réponse par défaut est non. Gardez le bridge en out uniquement et laissez les opérateurs modifier les consignes via l'IHM ou le SCADA existants.
Si vous avez besoin d'une voie descendante, concevez-la explicitement :
- Reliez en
inun seul topic de commande étroit, par exempleconnectmq/factory1/line1/cmd/+, jamais un joker couvrant toute l'arborescence. - Faites valider chaque commande par une passerelle au niveau 3, à l'aide d'une liste blanche de variables et de plages de valeurs, avant toute écriture dans l'automate.
- Exigez un topic de réponse et des données de corrélation (une fonctionnalité de MQTT 5) pour que chaque commande produise un acquittement journalisé.
- Laissez l'automate responsable des verrouillages de sécurité. Une commande cloud doit demander un changement, pas contourner la logique.
Erreurs courantes dans une DMZ MQTT
Exploiter le broker de la DMZ avec un accès anonyme. La DMZ reste une zone partagée. Exigez des noms d'utilisateur et des mots de passe, et idéalement des certificats clients, sur l'écouteur tourné vers l'OT.
Relier # dans les deux sens. C'est le moyen le plus rapide de transformer une DMZ soigneusement conçue en réseau plat au niveau applicatif. Ne reliez que les sous-arborescences nécessaires, et uniquement dans le sens nécessaire.
Oublier la session. Avec cleansession false, le côté cloud conserve les abonnements du bridge et les messages QoS 1 en file pendant les courtes coupures. Avec une session propre (clean session), tout ce qui est publié pendant une fenêtre de reconnexion peut être perdu.
Ignorer les limites côté broker. Une rafale de données historiques après une coupure peut dépasser les quotas par client. Limitez le débit du rejeu sur la passerelle et lisez les codes de raison renvoyés par le broker.
La place d'un broker MQTT managé
Dans les schémas A comme B, le point de connexion cloud est un composant que vous devriez sinon construire, exposer, mettre à jour et superviser vous-même. Utiliser un broker MQTT managé sort cette surface exposée à internet de votre datacenter. ConnectMQ fournit TLS sur le 8883, une isolation multi-tenant, une protection contre les inondations de messages et le blocage d'IP après des échecs de connexion répétés : votre DMZ n'a besoin que d'une règle sortante. Pour les organisations qui veulent le broker dans leur propre compte cloud, une option BYOC gérée pour votre compte est également proposée.
Pour une vision d'ensemble de la place de la DMZ aux côtés des passerelles, de Sparkplug B et d'un Unified Namespace, consultez notre guide complet de l'IoT industriel avec MQTT. Si vos sites se connectent via des réseaux mobiles plutôt que via un pare-feu d'usine, lisez aussi l'article sur MQTT sur réseau cellulaire.
Démarrer avec ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Vous obtenez en quelques minutes un nom d'utilisateur, un mot de passe et un client ID générés, soit tout ce qu'il faut pour pointer un bridge de DMZ vers le cloud et voir arriver vos topics d'usine dans l'explorateur de topics en direct. Lorsque l'offre gratuite ne suffit plus, les offres Serverless (Paid), Dedicated et BYOC vous permettent de monter en charge sans repenser la DMZ.
Questions fréquentes
MQTT nécessite-t-il des ports entrants dans le pare-feu vers le réseau OT ?
Non. Chaque participant MQTT est un client qui se connecte vers un broker : le réseau OT n'a besoin que d'une règle sortante vers le broker de la DMZ ou le broker cloud. Rien sur internet n'initie de connexion vers l'usine.
Faut-il utiliser le port 1883 ou 8883 pour une DMZ MQTT ?
Utilisez le 8883 avec TLS pour toute connexion qui quitte le site ou franchit une frontière de zone. Le 1883 en clair n'est acceptable qu'au sein d'un même segment de confiance, et même là, TLS est recommandé.
Ai-je besoin d'un broker dans la DMZ ?
Pas toujours. Une connexion sortante directe d'une passerelle de niveau 3 vers un broker cloud est souvent acceptable. Un broker bridge en DMZ est le meilleur choix lorsque votre politique interdit à toute session de traverser la DMZ ou que vous voulez une mise en tampon locale.
Les applications cloud peuvent-elles renvoyer des commandes aux automates à travers la DMZ ?
Oui, mais uniquement via un topic de commande étroit, explicitement relié par le bridge, et une passerelle qui valide chaque commande avant d'écrire dans l'automate. Beaucoup d'usines commencent par une télémétrie uniquement montante et ajoutent la voie descendante plus tard.
