MQTT est-il sécurisé ? Le protocole lui-même ne fournit que les points d'ancrage de la sécurité, un champ nom d'utilisateur et mot de passe et la possibilité de fonctionner sur TLS ; il est exactement aussi sûr que le déploiement qui l'entoure. Cet article explique ce que MQTT protège et ne protège pas, quelles menaces frappent réellement les systèmes en production, les idées reçues qui posent problème et les couches qui transforment une installation MQTT en installation sécurisée.
Ce que MQTT fournit en lui-même
MQTT a été conçu comme un protocole de messagerie léger, et sa spécification laisse délibérément l'essentiel de la sécurité à d'autres couches. D'emblée, vous disposez :
- D'un champ nom d'utilisateur et mot de passe dans le paquet CONNECT, envoyé sous forme d'octets bruts.
- Des points d'ancrage de l'authentification étendue MQTT 5 (une méthode d'authentification et des paquets AUTH) pour les schémas défi-réponse implémentés par le broker.
- De reason codes qui permettent au broker de signaler « identifiants incorrects » ou « non autorisé ».
- De l'indépendance vis-à-vis du transport, si bien que MQTT peut fonctionner sur TLS ou sur des WebSockets sécurisés.
Ce que le protocole ne fournit pas à lui seul :
- Aucun chiffrement. Sans TLS, chaque topic, payload et mot de passe est lisible sur le réseau.
- Aucun modèle d'autorisation. Savoir quel client peut utiliser quel topic relève du broker.
- Aucune intégrité ni signature du payload. Un message ne porte aucune preuve de son auteur, au-delà de la connexion par laquelle il est arrivé.
- Aucune limitation de débit ni protection contre les abus. C'est une fonctionnalité du broker.
La spécification OASIS MQTT comporte même un chapitre sécurité qui présente ces points comme des responsabilités d'implémentation. La réponse honnête à la question « MQTT est-il sécurisé ? » est donc : MQTT peut être sécurisé, et la sécurité est une propriété du broker, des clients et de la conception du réseau.
Les menaces qui comptent vraiment
| Menace | Comment elle survient | Protection principale |
|---|---|---|
| Écoute clandestine | Trafic sur le port 1883 capturé sur le Wi-Fi, chez le FAI ou sur le réseau cloud | TLS sur 8883 / 8084 |
| Vol d'identifiants en transit | Mot de passe lu dans un CONNECT non chiffré | TLS avec vérification du certificat |
| Brokers ouverts | Broker exposé sur Internet avec accès anonyme | Authentification, aucun accès anonyme en production |
| Extraction d'identifiants depuis les appareils | Mot de passe codé en dur dans le firmware ou stocké en clair en flash | Identifiants par appareil, stockage chiffré |
| Usurpation d'identité | Un attaquant se connecte avec un client ID volé ou partagé | Client IDs liés aux identifiants |
| Accès inter-tenants | Isolation faible sur un broker partagé | Isolation des tenants |
| Commandes malveillantes | N'importe qui peut publier sur un topic de commande | Autorisation, validation des commandes sur l'appareil |
| Déni de service | Floods de connexions ou de messages, connexions par force brute | Quotas, protection contre le flooding, blocage d'IP |
Les scans de brokers exposés trouvent régulièrement des systèmes sur le port 1883 avec accès anonyme, qui laissent fuiter des données de capteurs et acceptent parfois des commandes. Il s'agit de défauts de configuration, pas de vulnérabilités du protocole, ce qui explique pourquoi l'essentiel du vrai travail est opérationnel. Consultez les brokers MQTT exposés pour savoir comment ils sont découverts et refermés.
Idées reçues courantes sur la sécurité MQTT
« MQTT n'est pas sûr parce qu'il envoie les mots de passe en clair. »
Il les envoie en clair au sein de la couche MQTT, exactement comme le fait l'authentification HTTP Basic. Sur TLS, toute la connexion est chiffrée, y compris le paquet CONNECT. Le problème, c'est de faire fonctionner MQTT sans TLS, pas MQTT lui-même.
« Le port 1883 suffit à l'intérieur de notre réseau. »
Les réseaux internes se font compromettre, le Wi-Fi se fait écouter et les redirections de port « temporaires » deviennent permanentes. Considérez tout réseau comme non fiable et utilisez TLS partout où c'est possible. Réservez le 1883 en clair aux données de test publiques que vous accepteriez de voir n'importe où, comme le trafic de démonstration du serveur MQTT public gratuit.
« Un client ID long et aléatoire est un secret. »
Les client IDs apparaissent dans les journaux, les tableaux de bord et les chemins de topics. Ils identifient un client ; ils ne l'authentifient pas. La sécurité vient de l'identifiant auquel le client ID est lié.
« TLS sécurise les payloads de bout en bout. »
TLS protège chaque segment entre un client et le broker. Le broker voit le payload en clair. Si vous avez besoin d'une confidentialité de bout en bout entre l'appareil et l'application, ajoutez par-dessus un chiffrement du payload MQTT.
« Personne ne prendrait la peine d'attaquer mes capteurs. »
Les scanners automatisés se moquent de ce que mesurent vos capteurs. Ils cherchent des ports ouverts et des identifiants par défaut, et un broker exposé peut servir de point d'appui ou de relais gratuit.
Les couches qui rendent MQTT sécurisé
- Chiffrement du transport. TLS 1.2 ou plus récent sur le port 8883, ou WebSockets sécurisés sur 8084 pour les navigateurs, avec la vérification du certificat activée dans chaque client.
- Authentification. Aucun accès anonyme aux données de production. Des identifiants uniques par appareil et par service.
- Liaison d'identité. Des client IDs liés aux identifiants pour qu'un client ne puisse pas en usurper un autre.
- Isolation et autorisation. Des tenants et environnements séparés ; restreignez les topics lorsque votre broker le permet, et concevez des arborescences de topics où l'identité et la direction sont visibles. Le guide sur les ACL MQTT couvre les deux approches.
- Protection contre les abus. Quotas de connexions et de messages, protection contre le flooding et blocage des tentatives de connexion par force brute.
- Durcissement des appareils. Stockage chiffré des identifiants, Secure Boot, ports de débogage désactivés, mises à jour firmware signées.
- Exploitation. Rotation des identifiants, surveillance de l'état des connexions et des anomalies, et un plan pour révoquer un appareil compromis.
Comment un broker MQTT managé comble les lacunes
Plusieurs de ces couches se situent côté broker, et ce sont précisément celles que les déploiements auto-hébergés ratent le plus souvent : les certificats expirent, l'accès anonyme reste activé après un test, un fichier de mots de passe est partagé par tous les appareils. Un broker MQTT managé prend ces responsabilités en charge.
Voici comment ConnectMQ correspond aux couches ci-dessus :
| Couche | ConnectMQ |
|---|---|
| Chiffrement du transport | TLS sur 8883 et WebSocket sécurisé sur 8084 (chemin /mqtt) avec un certificat Let's Encrypt |
| Authentification | Nom d'utilisateur et mot de passe générés par jeu d'identifiants du broker |
| Liaison d'identité | Client IDs liés aux identifiants émis |
| Isolation | Isolation multi-tenant entre clients ; offre Dedicated pour un cluster isolé ; BYOC dans votre propre compte cloud |
| Protection contre les abus | Quotas par offre, protection contre le flooding, blocage d'IP après des échecs de connexion répétés |
| Visibilité | Tableau de bord, explorateur de topics en direct et $SYS/broker/connection/{clientId}/state pour l'état de connexion de chaque client |
ConnectMQ n'applique pas d'ACL par topic ; sa frontière de sécurité est donc le tenant et le broker : si deux groupes de clients ne doivent pas voir les données l'un de l'autre, donnez-leur des brokers distincts, et gardez les utilisateurs non fiables derrière votre propre backend au lieu de leur confier des identifiants du broker. Le durcissement des appareils et la rotation des identifiants restent de votre responsabilité, comme avec n'importe quel broker ; les guides sécuriser les identifiants MQTT sur les appareils et bonnes pratiques de sécurité MQTT les traitent.
Autoévaluation rapide
Répondez à ces questions sur votre déploiement actuel :
- Un client de production se connecte-t-il sur le port 1883 ?
- Un client désactive-t-il la vérification du certificat ?
- Deux appareils ou plus partagent-ils un même identifiant ?
- Un identifiant est-il codé en dur dans une image firmware ou un dépôt public ?
- Pouvez-vous révoquer un seul appareil en quelques minutes sans affecter les autres ?
- Remarqueriez-vous qu'un appareil se connecte depuis un endroit inattendu ou publie à dix fois son rythme normal ?
Un « oui » à l'une des quatre premières questions ou un « non » à l'une des deux dernières indique par où commencer.
Démarrer avec ConnectMQ
Bénéficiez dès le premier jour de TLS, de l'authentification, de la liaison d'identité, de l'isolation des tenants et de la protection contre les abus avec un broker MQTT cloud managé pour vous. Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire, et connectez votre premier appareil sur le port 8883 en quelques minutes.
Questions fréquentes
MQTT est-il sécurisé sans TLS ?
Non. Sans TLS, les noms d'utilisateur, mots de passe, topics et payloads peuvent être lus par quiconque est en mesure de capturer le trafic. Utilisez le port 8883 ou des WebSockets sécurisés pour tout ce qui dépasse les données de test publiques.
MQTT est-il plus ou moins sûr que HTTP ?
Ils sont comparables. Tous deux reposent sur TLS pour le chiffrement et sur le serveur pour l'authentification et l'autorisation ; aucun n'est sûr en clair.
MQTT 5 améliore-t-il la sécurité ?
MQTT 5 ajoute l'authentification étendue, la réauthentification et des reason codes plus riches, qui facilitent la construction et le débogage de conceptions sécurisées. Il n'ajoute pas de chiffrement à lui seul.
Un broker MQTT public est-il sûr à utiliser ?
Pour l'apprentissage et les démonstrations avec des données non sensibles, oui. Les brokers publics sont lisibles par tout le monde ; les données de production ont donc leur place sur un broker privé avec identifiants et TLS.
