Commencer par le threat model
MQTT est souvent deploye sur des reseaux faibles et des appareils accessibles physiquement. L’ecoute, le vol de credentials et les clients malveillants sont des risques reels.
Une bonne securite commence par un modele de menace : qui peut acceder au reseau, quelles donnees sont sensibles, et que se passe-t-il en cas de compromission.
TLS partout
TLS doit etre la norme pour toute connexion MQTT. Il protege les credentials et les donnees en transit.
Utilisez des versions modernes de TLS et planifiez la rotation des certificats. Pour les devices contraints, anticipez la gestion des certs.
Choix d’authentification
Le couple login/mot de passe est souvent trop faible. Les certificats client ou des tokens courts sont plus solides.
Lie l’identite a la provision. Evitez les credentials partages entre plusieurs devices.
ACL par topic et moindre privilege
Les ACL doivent limiter la publication et la souscription. Un device ne doit pas pouvoir acceder a des topics d’un autre site.
Une hierarchie de topics claire simplifie ces regles. Un design confus rend les ACL ingérables.
Durcissement du broker
Bloquez l’anonyme, imposez des limites de connexions, surveillez les anomalies. Beaucoup d’attaques sont visibles si l’on regarde.
Separez brokers publics et internes. Si un bridge public est necessaire, isolez-le.
Audit et observabilite
Loggez les echec d’auth, les subscriptions suspectes et les taux de publish anormaux. Ces signaux revele des erreurs ou attaques.
La securite est continue. Mettez des alertes et revoyez-les regulierement.
Securite et produit
Les controles doivent rester utilisables. Si la provision est trop complexe, l’equipe contournera.
Documentez securite et topics au meme endroit pour eviter les zones d’ombre.