Configurer les flux MQTT

Sécurisez MQTT sur un réseau OT avec Access Gate, refus par défaut sur le port 1883, enclaves à portée d'identité, contrôle au niveau des topics et TLS pour un broker livré sans authentification ni chiffrement.

MQTT est un protocole publish/subscribe léger utilisé dans les environnements IoT et OT pour la télémétrie et les commandes : les clients publient des messages sur les "topics" d’un "broker", et d'autres clients s'abonnent à ces topics.

Sa simplicité et son efficacité constituent aussi son problème de sécurité. Un broker par défaut fonctionne souvent sans authentification, sans chiffrement et sans contrôle d'accès aux topics : tout ce qui peut l'atteindre peut lire chaque topic ou publier une commande malveillante sur un topic de contrôle. Access Gate place l'identité, les contrôles d'accès et le chiffrement devant le broker afin que seuls les clients autorisés échangent des messages MQTT.

Ce que vous obtenez

Refus par défaut sur le port 1883. Rien n'atteint le port MQTT du broker sans qu'une règle ACL explicite l'autorise. Cela seul supprime l'exposition « tout hôte du réseau peut se connecter et publier ».
Accès restreint par identité. Les flux MQTT sont généralement de machine à machine, un "publisher" qui pousse de la télémétrie et un "broker" qui la redistribue. Les autorisations sont définies entre assets, de sorte que seul le client autorisé atteint le broker, et rien d'autre.
TLS pour un protocole qui n'en dispose pas. MQTT sur le port 1883 est en clair. La passerelle enveloppe la session dans TLS entre le client et elle-même, puis transfère au broker via le segment protégé : le trafic est chiffré en transit et le périphérique client n'a besoin d'aucune modification cryptographique côté broker.

Pourquoi le broker par défaut est exposé

Dans cet exemple, le broker est Eclipse Mosquitto 2.0.18 sous Linux, avec une configuration de lab minimale :

# /etc/mosquitto/conf.d/lab.conf
listener 1883 0.0.0.0   # MQTT on the standard port 1883, bound to all interfaces
allow_anonymous true    # no authentication: any client can connect, publish, and subscribe

Laissé tel quel, ce broker présente plusieurs risques :

Aucune authentification. Avec allow_anonymous true, n'importe qui sur le réseau peut se connecter, publier et s'abonner sans nom d'utilisateur ni mot de passe.
Aucun TLS. Le trafic sur le port 1883 est en clair : les identifiants et la télémétrie sont interceptables, et la session peut être altérée en transit (MITM).
Aucune ACL de topic. Tout client peut s'abonner à tout, ou publier sur un topic de contrôle, par exemple pour usurper le point de consigne d’un PLC.
Injection et rejeu de messages. Des commandes falsifiées ou rejouées vers des actionneurs ont un impact physique dans les environnements OT.
Déni de service. L'inondation de messages retenus et l'épuisement des connexions peuvent mettre le broker hors service.
Exposition du broker. Avec le port 1883 lié à 0.0.0.0, le broker est accessible hors segment dès que le réseau n'est pas strictement isolé.

Configuration

Enregistrez le broker en tant qu'asset et définissez son protocole sur MQTT.
Enregistrement du broker MQTT en tant qu'asset
Ajoutez le broker à une enclave (voir Protéger un asset avec des enclaves), puis ajoutez une règle allow pour le protocole mqtt limitée au client spécifique qui doit l'atteindre. Cela enveloppe une enclave autour des flux MQTT.
Une enclave délimitée autour des flux MQTT

À ce stade, le broker n'est plus grand ouvert : la passerelle applique l'identité du client et les règles de contrôle d'accès sur le flux.

Exemple concret : sécurisation d'un flux client vers broker

Les images ci-dessous tracent un message publié depuis un client vers le broker via Access Gate. L'enclave est configurée de sorte que seul les clients définis puissent atteindre le broker, rien d'autre sur le réseau ne le peut.

Premier niveau de sécurité : ajout de l'authentification et du contrôle d'accès

Depuis le client, nous publions un message sur le topic. La passerelle laisse passer le client autorisé, et le broker le reçoit.

Deuxième niveau de sécurité : ajout du chiffrement TLS

Accédez à l'enclave, et modifiez les permissions en sélectionnant TLS et installez le certificat sur le périphérique client. La passerelle maintient désormais un tunnel TLS entre le client et le broker, de sorte que le même flux transite chiffré.

Publication d'un message chiffré vers le broker

Comment la session chiffrée est établie

Il est utile de voir la publication chiffrée comme trois couches, établies dans l'ordre :

Socket (TCP). Le client ouvre une connexion TCP vers la passerelle sur le port 1883. Il s'agit simplement d'un canal d'octets fiable : il transporte ce qu'on y place.
TLS. Juste après l'ouverture du socket, une négociation TLS s'exécute à l'intérieur. Le proxy présente sa chaîne de certificats, le client la vérifie par rapport à son propre certificat (celui d'Access Gate ici) et contrôle que le nom d'hôte correspond au SAN du certificat (mqtt-broker.bluelab.secure). Les deux parties dérivent ensuite des clés, et tout ce qui suit est chiffré.
Message (MQTT). Ce n'est qu'une fois TLS établi que MQTT s'exécute via le canal chiffré : CONNECT, le broker répond CONNACK (0) (accepté), puis PUBLISH votre charge utile sur le topic plant/line1/cmd, puis DISCONNECT. Un code de sortie 0 signifie que les trois couches ont abouti.

TCP est donc le canal, TLS est l'enveloppe chiffrée autour du canal, et MQTT est la conversation réelle transportée à l'intérieur de l'enveloppe. Le rôle du proxy est de refuser tout ce qui n'est pas encapsulé dans l’enveloppe TLS.

Notes et points d'attention

Ne pas interrompre le flux. Avant d'appliquer les règles, observez le trafic MQTT réel afin d'identifier les clients qui publient ou s'abonnent légitimement.
Les topics sont la vraie surface d'attaque. L'accessibilité est le premier contrôle, mais les dommages en MQTT se produisent au niveau du topic. Limitez les autorisations aux clients spécifiques qui possèdent un topic de contrôle afin qu'un capteur compromis ne puisse pas y publier.
Stocker le certificat. Conservez le certificat client dans le gestionnaire de certificats du périphérique plutôt que de passer --cafile à chaque commande, afin que le flux chiffré soit le chemin par défaut.
Autres protocoles OT. Le même modèle (refus par défaut, restreint par identité, enveloppé dans TLS) s'applique aux autres protocoles industriels du réseau. MQTT est un point de départ courant, pas le seul.

Récapitulatif

Vous avez enregistré le broker en tant qu'asset MQTT, enveloppé une enclave autour des flux MQTT avec une règle de refus par défaut limitée au client autorisé, et activé TLS pour qu'un protocole en clair transite chiffré sans modifier le broker. Le client s'authentifie et chiffre vis-à-vis de la passerelle, qui applique la politique et transfère au broker via le segment protégé.

Utilisez cette approche pour verrouiller un broker MQTT livré sans authentification, sans chiffrement et sans contrôle d'accès aux topics, où l'accessibilité équivaut à l'autorisation et où une seule publication frauduleuse peut agir sur un processus physique.