Sécurité MQTT : bonnes pratiques et checklist concrète

MQTT a été conçu pour des réseaux contraints, pas pour des réseaux hostiles. Par défaut, de nombreux brokers acceptent des clients anonymes sur le port 1883 et transmettent tout en clair. Ce n’est pas un défaut du protocole — MQTT offre tous les mécanismes nécessaires — mais la sécurité est quelque chose que vous devez activer vous-même. Ce guide passe en revue chaque couche et se termine par une checklist utilisable lors de vos audits.

Contre quoi vous vous protégez

• L’écoute clandestine — la lecture des identifiants et des payloads sur le réseau.
• L’usurpation d’identité — un client malveillant qui se connecte en se faisant passer pour l’un de vos appareils ou services.
• La publication non autorisée — quelqu’un qui envoie unlock sur home/door/cmd.
• La fuite de données — un client qui s’abonne à # et lit tout.
• Le déni de service — des avalanches de connexions ou de messages qui épuisent le broker.

1. Chiffrez tout avec TLS

TLS protège les identifiants et les payloads en transit et permet aux clients de vérifier qu’ils parlent bien au vrai broker. Utilisez le port 8883 pour MQTT sur TLS et wss:// pour les navigateurs ; désactivez ou filtrez par pare-feu le listener 1883 en clair partout en dehors d’un réseau local de confiance. Plus de détails dans les ports MQTT expliqués et MQTT sur WebSockets.

• Exigez TLS 1.2 ou une version plus récente.
• Vérifiez toujours le certificat du serveur côté client. Les options comme --insecure, setInsecure() ou rejectUnauthorized: false sont réservées au débogage local.
• Planifiez le renouvellement des certificats — un certificat expiré met tous les appareils hors ligne d’un coup.

mosquitto_sub -h broker.example.com -p 8883 --cafile ca.crt \
  -u sensor-01 -P 'secret' -t 'devices/sensor-01/#' -v

2. Authentifiez chaque client

Désactivez l’accès anonyme. Choisissez ensuite une méthode d’authentification adaptée à chaque type de client :

Ne partagez jamais un même identifiant sur toute une flotte : si un appareil est compromis, vous voulez révoquer un seul identifiant, pas reflasher tous les appareils. Stockez les mots de passe hachés sur le broker — les utilisateurs de Mosquitto peuvent suivre le guide d’authentification Mosquitto, et le générateur de mosquitto.conf produit une configuration sécurisée avec TLS et fichiers de mots de passe.

3. Autorisez les topics avec des ACL

L’authentification répond à qui êtes-vous ; l’autorisation répond à qu’avez-vous le droit de faire. Sans ACL, n’importe quel client authentifié peut lire et écrire sur tous les topics. Appliquez le principe du moindre privilège : chaque client n’obtient un accès en lecture ou en écriture qu’aux topics dont il a besoin.

# backend service: read all telemetry, send commands
user backend
topic read devices/+/telemetry
topic write devices/+/cmd

# every device: only its own topics (%u = username)
pattern write devices/%u/telemetry
pattern read devices/%u/cmd

Les règles pattern qui substituent le nom d’utilisateur ou le client ID passent bien mieux à l’échelle qu’une règle par appareil. Vérifiez vos filtres avec le testeur de topics ; les jokers (wildcards) MQTT sont détaillés dans topics et jokers.

4. Contrôlez les client IDs

Un client qui se connecte avec un client ID déjà utilisé éjecte la connexion d’origine du broker. Un attaquant qui connaît vos IDs peut s’en servir pour déconnecter des appareils, et un doublon accidentel provoque des boucles de reconnexion sans fin. Liez les client IDs aux identifiants lorsque votre broker le permet (par exemple, en exigeant que le client ID soit égal au nom d’utilisateur ou au common name du certificat), et évitez les IDs prévisibles sur des brokers partagés. Le générateur de client ID vous aide à en créer des uniques.

5. Concevez vos topics en pensant sécurité

• Placez l’ID de l’appareil ou du tenant à une position fixe pour que les patterns d’ACL puissent le cibler.
• Séparez la télémétrie (écrite par l’appareil) des commandes (lues par l’appareil) dans des sous-arbres distincts.
• N’incluez ni secrets ni données personnelles dans les noms de topics — ils apparaissent dans les logs et les outils de supervision.
• Méfiez-vous des messages retenus (retained) sur les topics de commande : un unlock retenu se déclenche à nouveau à la reconnexion.

6. Chiffrez ou signez les payloads sensibles

TLS protège chaque saut, mais le broker voit les payloads en clair. Si l’opérateur du broker ou d’autres services connectés ne doivent pas lire les données, chiffrez les payloads de bout en bout (par exemple en AES-GCM avec des clés gérées en dehors de MQTT), ou au minimum signez les commandes pour que les appareils puissent rejeter les commandes falsifiées. Validez chaque payload entrant sur l’appareil : imposez des limites de taille, vérifiez les types et ignorez les commandes inconnues.

7. Fixez des limites et des quotas de débit

Plafonnez la taille maximale des paquets, le nombre de messages en vol et en file d’attente par client, le rythme de connexion et le nombre d’abonnements. MQTT 5 permet au broker d’annoncer aux clients des limites comme la taille maximale de paquet et le receive maximum. Les limites de débit empêchent un appareil bogué pris dans une boucle de publication de faire tomber tout le monde — utilisez le calculateur de taille de paquet pour fixer des plafonds de taille réalistes.

8. Protégez les identifiants sur les appareils et dans les applications

Les identifiants des appareils finissent en mémoire flash, et ceux du navigateur dans des bundles JavaScript lisibles par n’importe qui. Partez du principe qu’ils peuvent être extraits : donnez à chaque client l’ACL la plus restreinte possible, provisionnez des identifiants propres à chaque appareil en fabrication ou au premier démarrage plutôt que d’intégrer un secret unique dans le firmware, et utilisez le chiffrement de la flash ou un secure element lorsque le matériel le permet. Pour les applications web et mobiles, délivrez des identifiants de courte durée depuis votre backend au lieu d’embarquer un mot de passe permanent.

9. Supervisez et journalisez

• Journalisez les connexions, déconnexions et échecs d’authentification, et déclenchez des alertes en cas de pic.
• Surveillez les clients qui s’abonnent de façon inattendue à # ou $SYS/#.
• Suivez le nombre de connexions et le débit de messages par client pour repérer les appareils compromis ou défaillants.
• Maintenez le broker et les bibliothèques clientes à jour.

Checklist de sécurité MQTT

Lorsqu’un client verrouillé ne parvient pas à se connecter, le reason code du CONNACK vous indique s’il s’agit d’un problème d’identifiants ou d’autorisation — consultez la référence des reason codes MQTT.

Questions fréquentes