J'interviens souvent sur des projets où l'on doit faire communiquer des flottes de capteurs IIoT avec Azure IoT Hub via une passerelle edge MQTT. L'enjeu récurrent est de garantir la disponibilité des systèmes OT tout en respectant des contraintes de sécurité et de performance très strictes. Dans cet article, je partage une démarche pragmatique pour dimensionner et sécuriser une passerelle edge MQTT afin d'assurer la continuité opérationnelle côté OT.
Comprendre le rôle de la passerelle edge
Avant de rentrer dans les chiffres et les certificats, je rappelle toujours le rôle exact d'une passerelle edge dans l'architecture : elle fait l'interface entre les capteurs/systèmes locaux (souvent dans la zone OT) et le cloud (Azure IoT Hub). Elle assure :
- la traduction de protocoles (modbus, OPC UA, capteurs MQTT locaux) vers MQTT ou AMQP vers IoT Hub,
- l'agrégation et le pré-traitement des données (filtrage, fenêtres, compression),
- la résilience en cas de coupure réseau (store-and-forward),
- l'application de politiques de sécurité et d'authentification.
Exigences OT à prioriser
Dans les environnements industriels, la disponibilité OT prime souvent sur la transmission temps réel vers le cloud. Pour moi, les exigences à prioriser sont :
- Non-régression OT : la passerelle ne doit pas introduire de latences ou de perturbations sur le bus capteurs/contrôleurs.
- Fail-safe local : les fonctions critiques locales doivent continuer de tourner même si le lien vers Azure est coupé.
- Visibilité et diagnostics : journaux, métriques et tableaux de bord pour détecter rapidement les défaillances.
Dimensionnement : CPU, mémoire, stockage, réseau
Le dimensionnement dépend fortement du nombre de capteurs, du volume d'événements et du traitement local. Voici des repères que j'utilise comme point de départ : ce sont des recommandations pratiques testées sur plusieurs déploiements.
| Scénario | Devices / messages/s | CPU (vCPU) | Mémoire | Stockage (SSD) | Réseau |
|---|---|---|---|---|---|
| Petit | < 500 devices, < 10 msg/s | 2 vCPU | 4 GB | 32 GB | 100 Mbps |
| Moyen | 500–5 000 devices, 10–100 msg/s | 4–8 vCPU | 8–16 GB | 128 GB | 500 Mbps |
| Important | >5 000 devices, >100 msg/s | 8–16+ vCPU | 16–64 GB | 256+ GB | 1 Gbps+ |
Points pratiques :
- Préferez des CPU avec bonnes performances single-thread si votre broker MQTT local (ex. Mosquitto, EMQX) n'est pas multithreadé sur toutes les fonctions.
- La mémoire est critique pour les files en mémoire et le cache des jumeaux numériques. Surdimensionnez légèrement pour gérer les pics.
- Stockage SSD pour le journal local (store-and-forward) et pour les bases temporelles locales (InfluxDB, SQLite, RocksDB selon l'implémentation).
- Réservez une interface réseau pour OT (isolation VLAN) et une autre pour IT/cloud, avec QoS réseau définie sur les switchs pour prioriser le trafic OT.
MQTT : QoS, rétention et latence
Le choix des paramètres MQTT affecte directement la disponibilité :
- QoS 0 pour les données non critiques où la latence basse prime.
- QoS 1 pour la plupart des télémetries industrielles : bon compromis fiabilité/perf.
- QoS 2 rarement nécessaire en OT (overhead élevé).
- Messages retenus (retained) uniquement pour états (setpoints) — évitez pour flux continus.
Pour Azure IoT Hub, la passerelle doit gérer la conversion vers les protocoles supportés (HTTPS, AMQP, MQTT) et l'authentification via SAS tokens ou X.509. Je favorise X.509 pour les passerelles et TPM/HSM pour la protection de clé.
Résilience et disponibilité
Pour garantir la disponibilité OT :
- Implémentez store-and-forward local : tamponnez les messages sur disque en cas de perte du lien cloud.
- Activez redondance : au moins 2 passerelles en HA avec basculement automatique (leader/standby). Des solutions comme Azure IoT Edge supports modules redondants et patterns de failover.
- Préparez des scénarios dégradés : logique locale qui prend le relais (setpoints locaux, règles de sécurité).
- Surveillez la santé via metrics (CPU, memory, queue length, latence, last cloud ack) et alertes (Prometheus + Grafana / Azure Monitor).
Sécurisation : identité, chiffrement et périmètre
La sécurisation commence par l'identité et le périmètre :
- Hardware root of trust : préférez des dispositifs supportant TPM ou HSM pour stocker les clés (Azure DPS + X.509 + TPM). Cela réduit le risque de clé volée.
- Chiffrement TLS obligatoire sur tous les liens (capteurs ↔ passerelle et passerelle ↔ IoT Hub). Forcez TLS 1.2+ et ciphers modernes.
- Gestion des certificats : automatisez le renouvellement (ACME/Pki interne) et révocation. Azure IoT Edge facilite l'utilisation de certificats mTLS pour modules.
- Segmentation réseau : séparateur stricte entre VLAN OT et IT, ACL sur firewalls. Limitez les flux sortants uniquement vers les services Azure nécessaires.
- Principle of least privilege : chaque module/service a le minimum de droits pour fonctionner (SAS tokens avec TTL court si utilisés).
Mise à jour et maintenance
Les mises à jour sont souvent le talon d'Achille. Mes recommandations :
- Mettre en place une stratégie de mises à jour contrôlées (staging → canary → prod) et des fenêtres de maintenance définies avec l'exploitation OT.
- Utiliser Azure IoT Edge pour déployer des modules et rollback rapide si problème.
- Valider les mises à jour en environnement représentatif (réplication des charges) avant production.
Surveillance et runbook
Un runbook clair sauve des usines : qui fait quoi quand la passerelle perd le lien cloud, quand la file atteint 80% ou quand le broker local dépasse les limites de connexion. Je documente :
- procédures de basculement manuelles et automatiques,
- checklist de diagnostic (logs, métriques, ping IoT Hub, az iot commands),
- contacts et SLA internes pour escalade.
Exemples d'outils et d'architectures
Sur plusieurs déploiements, j'ai utilisé :
- Azure IoT Edge comme runtime pour isoler modules : adaptateurs MQTT, preprocessors et modules de stockage local,
- EMQX ou Mosquitto comme broker local pour gérer de forts volumes MQTT locaux,
- InfluxDB + Grafana pour stocker métriques locales/temps réel,
- TPM/HSM (Infineon, Azure Sphere) pour sécuriser les clés et les certificats,
- Azure DPS (Device Provisioning Service) + X.509 pour provisioning sûr des passerelles.
Enfin, garder le dialogue ouvert entre équipes OT, IT et cybersécurité est primordial. Les décisions de dimensionnement et de sécurité ont des impacts croisés : latence, disponibilité et maintien en condition opérationnelle. En combinant un dimensionnement adapté, des mécanismes de résilience locaux et une stratégie de sécurité robuste (TPM, TLS, segmentation, rotation des clés), on peut construire des passerelles edge MQTT qui protègent à la fois la disponibilité OT et l'intégrité des données envoyées vers Azure IoT Hub.