Sécurité et maintenance

La sécurité des terminaux IoE est un enjeu critique : objets souvent exposés, données sensibles collectées et mises à jour parfois négligées. Ce chapitre couvre les mesures de sécurité essentielles et les bonnes pratiques de maintenance.

Objectifs

À la fin de ce chapitre, vous serez capable de :

Comprendre l'importance des mises à jour (firmware, logiciel).
Identifier les principales mesures de sécurité applicables aux terminaux IoE.
Reconnaître les données sensibles collectées par les terminaux.
Appliquer les bonnes pratiques de sécurité et de maintenance.
Sécuriser les communications Device–Edge–Cloud.
Configurer l'authentification et les droits d'accès sur un broker MQTT.

Firmware, système et application

Définitions

Composant	Description	Exemple
Firmware	Programme embarqué bas niveau, contrôle le matériel	Code sur un ESP32, BIOS d'une gateway
Système d'exploitation	Logiciel de base gérant les ressources matérielles	Linux embarqué, RTOS, Raspberry Pi OS
Application embarquée	Programme applicatif fonctionnant sur le terminal	Script Python de mesure, agent MQTT

ESP32 — terminal IoE de référence

L'ESP32 est un microcontrôleur (puce électronique programmable) très répandu dans l'IoE. Fabriqué par Espressif, il intègre Wi-Fi et Bluetooth, coûte quelques francs, et exécute un firmware personnalisé. On le retrouve dans des capteurs de température, détecteurs de mouvement, systèmes domotiques, etc. Dans ce cours, il représente le cas typique du terminal IoE de terrain.

Pourquoi mettre à jour ?

Raison	Explication
Sécurité	Correction de vulnérabilités connues
Stabilité	Résolution de bugs et amélioration des performances
Compatibilité	Maintien de la compatibilité avec les plateformes et protocoles

WARNING

Un firmware obsolète est l'une des failles de sécurité les plus fréquentes en IoE. Les mises à jour doivent être planifiées et documentées.

Mise à jour sécurisée du firmware

Il existe deux méthodes principales pour mettre à jour un terminal IoE :

Méthode	Description	Avantages	Risques
Manuelle (USB / série)	Connexion physique, flash direct	Contrôle total	Non scalable, erreur humaine
OTA (Over-The-Air)	Mise à jour via le réseau	Scalable, automatisable	Firmware malveillant si non vérifié

Avantages de l'OTA

Avantage	Explication
Scalabilité	Des centaines de terminaux mis à jour simultanément, sans déplacement physique
Réactivité sécurité	Correction d'une vulnérabilité déployée en quelques minutes sur tout le parc
Réduction des coûts	Pas de technicien sur site pour chaque mise à jour
Disponibilité maintenue	Mise à jour planifiable hors heures de pointe, redémarrage automatique
Traçabilité	Version de firmware connue à tout moment pour chaque terminal

Cas concret

Un ESP32 déployé dans 50 salles de classe peut recevoir une correction de sécurité critique en une seule opération depuis le serveur, sans qu'aucun élève ni technicien n'intervienne sur les appareils.

OTA et intégrité du firmware

Une mise à jour OTA sans vérification est dangereuse : un attaquant qui compromet le serveur de mise à jour peut pousser un firmware malveillant sur tous les terminaux.

Les bonnes pratiques :

Signature numérique — le fabricant signe le firmware avec sa clé privée ; le terminal vérifie la signature avant de flasher
Vérification de l'intégrité — checksum SHA-256 du fichier firmware comparé à la valeur fournie par le serveur
Partition de rollback — l'ESP32 supporte deux partitions OTA ; si le nouveau firmware échoue au démarrage, retour automatique à l'ancienne version
Canal sécurisé — téléchargement exclusivement via HTTPS (jamais HTTP)

Flux OTA sécurisé :
Serveur ──HTTPS──▶ Terminal
         [firmware + signature]
                   │
                   ▼
           Vérif. signature (clé publique embarquée)
                   │
           OK ─────▶ Flash partition OTA_1
           NOK ────▶ Rejet, alerte, pas de flash

WARNING

Sans vérification de signature, n'importe qui ayant accès au canal de mise à jour peut flasher un firmware arbitraire sur le terminal. C'est une attaque de la chaîne d'approvisionnement (supply chain attack).

Risques de sécurité

Faiblesses courantes

Risque	Description
Firmware obsolète	Vulnérabilités non corrigées, exploitables à distance
Mots de passe par défaut	Accès non autorisé trivial (ex. admin/admin)
Absence de chiffrement	Données transmises en clair, interceptables
Terminal exposé inutilement	Ports ouverts, accès depuis Internet sans nécessité
Absence de segmentation	Un terminal compromis peut accéder à tout le réseau

Données sensibles collectées

Les terminaux IoE collectent souvent des données à caractère personnel ou sensible :

Type de données	Exemples	Sensibilité
Localisation	GPS, triangulation Wi-Fi	Élevée
Image / vidéo	Caméras de surveillance	Très élevée
Audio / voix	Assistants vocaux, interphones	Très élevée
Présence	Détecteurs de mouvement	Moyenne à élevée
Habitudes	Horaires, fréquences d'utilisation	Moyenne
Données médicales	Rythme cardiaque, activité physique	Très élevée

Architecture de sécurité Device–Edge–Cloud

Vue d'ensemble

Un système IoE en production comporte trois zones de sécurité distinctes :

Chaque liaison a ses propres exigences de sécurité :

Liaison	Protocole	Authentification recommandée
Device → Edge (broker local)	MQTTS (port 8883)	Certificat client X.509 ou login/mot de passe + TLS
Edge → Cloud	HTTPS ou AMQP over TLS	Clé API + TLS mutuel (mTLS)
Admin → Edge	SSH ou HTTPS	Clé SSH, authentification forte

TLS mutuel (mTLS)

Le TLS standard vérifie uniquement l'identité du serveur (le client fait confiance au serveur).

Le TLS mutuel ajoute la vérification de l'identité du client (le serveur vérifie aussi qui se connecte) :

TLS standard :   Client ──────────────▶ Serveur
                 « Je vous fais confiance » ✓

TLS mutuel :     Client ◀────────────▶ Serveur
                 « Je vous fais confiance » ✓
                 « Je vous fais confiance aussi » ✓

En IoE, c'est essentiel : un ESP32 doit refuser de se connecter à un broker non reconnu (broker malveillant ou attaque man-in-the-middle).

Authentification et autorisation MQTT

Les deux concepts

Concept	Question	Mécanisme
Authentification	Qui êtes-vous ?	Login/mot de passe, certificat client
Autorisation	Qu'avez-vous le droit de faire ?	ACL (Access Control List) par topic

Méthodes d'authentification

Méthode simple supportée nativement par MQTT. Le broker Mosquitto utilise un fichier de mots de passe hashés.

bash

# Créer un fichier de mots de passe (première fois)
mosquitto_passwd -c /etc/mosquitto/passwd sensor01

# Ajouter un utilisateur supplémentaire
mosquitto_passwd /etc/mosquitto/passwd backend_app

Configuration Mosquitto (mosquitto.conf) :

ini

listener 8883
cafile   /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/broker.crt
keyfile  /etc/mosquitto/certs/broker.key

allow_anonymous false
password_file /etc/mosquitto/passwd

WARNING

Sans allow_anonymous false, n'importe qui peut se connecter sans s'identifier. Toujours désactiver l'accès anonyme en production.

2. Certificats clients X.509

Chaque terminal possède son propre certificat signé par une autorité de certification (CA) interne. Plus sécurisé que login/mot de passe car la clé privée ne transite jamais sur le réseau.

ini

# mosquitto.conf — TLS mutuel
require_certificate true
use_identity_as_username true

Le CN (Common Name) du certificat devient le nom d'utilisateur, utilisable dans les ACL.

Autorisation par ACL (Access Control List)

Les ACL définissent quels utilisateurs peuvent publier ou s'abonner à quels topics.

Exemple de fichier ACL (/etc/mosquitto/acl) :

ini

# Le capteur sensor01 publie uniquement sur son topic
user sensor01
topic write batiment/etage1/temp
topic write batiment/etage1/humidity

# Le capteur sensor02 publie sur ses propres topics
user sensor02
topic write batiment/etage2/temp

# L'application backend lit tous les topics bâtiment
user backend_app
topic read batiment/#

# Le tableau de bord peut lire et écrire (pour les commandes)
user dashboard
topic readwrite batiment/#
topic readwrite cmd/#

Activation dans mosquitto.conf :

ini

acl_file /etc/mosquitto/acl

Wildcard dans les topics MQTT

Wildcard	Portée	Exemple
`+`	Un seul niveau	`batiment/+/temp` → tous les étages
`#`	Tous les niveaux suivants	`batiment/#` → tout ce qui commence par `batiment/`

INFO

Un terminal compromis qui publie sur un topic non autorisé reçoit un PUBACK avec code d'erreur (MQTT 5) ou la connexion est coupée (MQTT 3.1.1). Les ACL sont la dernière ligne de défense si les credentials sont volés.

Synthèse : niveaux de sécurité MQTT

Niveau	Configuration	Sécurité
0 — Aucune	`allow_anonymous true`, port 1883	Aucune — à éviter absolument
1 — Login/MDP	`password_file` + TLS serveur	Basique — acceptable en dev/lab
2 — Login/MDP + ACL	`password_file` + `acl_file` + TLS	Correct — acceptable en production interne
3 — Certificats + ACL	mTLS + `acl_file`	Recommandé pour production IoE

Mesures de sécurité

Bonnes pratiques essentielles

Changer les identifiants par défaut dès la première configuration
Utiliser des mots de passe forts (longueur, complexité, unicité)
Mettre à jour le firmware régulièrement
Chiffrer les communications (TLS/SSL, MQTT over TLS)
Segmenter le réseau (VLAN dédié aux terminaux IoE)
Limiter les accès (pare-feu, listes blanches, ACL)
Désactiver les services inutiles (ports, protocoles non utilisés)
Surveiller les terminaux (logs, alertes en cas d'anomalie)

Segmentation réseau

Placer les terminaux IoE dans un VLAN dédié permet de :

Isoler le trafic IoE du réseau bureautique
Limiter la propagation en cas de compromission
Appliquer des règles de pare-feu spécifiques

VLAN 10 — IoE    : ESP32, capteurs, actionneurs
VLAN 20 — Edge   : Gateway, broker Mosquitto
VLAN 30 — Bureau : PC, imprimantes

Pare-feu : VLAN 10 ──▶ VLAN 20 (MQTTS 8883)  ✓
           VLAN 10 ──▶ VLAN 30               ✗ bloqué
           VLAN 20 ──▶ Internet (HTTPS)      ✓

Communications chiffrées

Protocole	Version sécurisée
HTTP	HTTPS (HTTP over TLS)
MQTT	MQTTS (MQTT over TLS, port 8883)
CoAP	CoAPS (CoAP over DTLS)

Maintenance

Plan de maintenance

Un terminal IoE en production nécessite un suivi régulier :

Action	Fréquence recommandée
Vérification de la connectivité	Quotidienne (automatisée)
Contrôle de la cohérence des données	Hebdomadaire
Mise à jour firmware	Selon disponibilité (planifiée)
Revue des accès et mots de passe	Trimestrielle
Remplacement des batteries	Selon durée de vie estimée
Documentation à jour	À chaque modification

Résumé

La sécurité IoE couvre trois axes : les mises à jour firmware (OTA signé, rollback, canal HTTPS), les communications Device–Edge–Cloud (MQTTS, mTLS, segmentation VLAN) et le contrôle d'accès MQTT (authentification par login ou certificat, autorisation par ACL par topic). Ces mesures combinées limitent drastiquement la surface d'attaque d'une infrastructure IoE en production.

Scalabilité Des centaines de terminaux mis à jour simultanément, sans déplacement physique Réactivité sécurité Correction d'une vulnérabilité déployée en quelques minutes sur tout le parc Réduction des coûts Pas de technicien sur site pour chaque mise à jour Disponibilité maintenue Mise à jour planifiable hors heures de pointe, redémarrage automatique Traçabilité Version de firmware connue à tout moment pour chaque terminal

Sécurité et maintenance ​

Objectifs ​

Firmware, système et application ​

Définitions ​

Pourquoi mettre à jour ? ​

Mise à jour sécurisée du firmware ​

Avantages de l'OTA ​

OTA et intégrité du firmware ​

Risques de sécurité ​

Faiblesses courantes ​

Données sensibles collectées ​

Architecture de sécurité Device–Edge–Cloud ​

Vue d'ensemble ​

TLS mutuel (mTLS) ​

Authentification et autorisation MQTT ​

Les deux concepts ​

Méthodes d'authentification ​

1. Login / mot de passe ​

2. Certificats clients X.509 ​

Autorisation par ACL (Access Control List) ​

Wildcard dans les topics MQTT ​

Synthèse : niveaux de sécurité MQTT ​

Mesures de sécurité ​

Bonnes pratiques essentielles ​

Segmentation réseau ​

Communications chiffrées ​

Maintenance ​

Plan de maintenance ​

Résumé ​

Sécurité et maintenance

Objectifs

Firmware, système et application

Définitions

Pourquoi mettre à jour ?

Mise à jour sécurisée du firmware

Avantages de l'OTA

OTA et intégrité du firmware

Risques de sécurité

Faiblesses courantes

Données sensibles collectées

Architecture de sécurité Device–Edge–Cloud

Vue d'ensemble

TLS mutuel (mTLS)

Authentification et autorisation MQTT

Les deux concepts

Méthodes d'authentification

1. Login / mot de passe

2. Certificats clients X.509

Autorisation par ACL (Access Control List)

Wildcard dans les topics MQTT

Synthèse : niveaux de sécurité MQTT

Mesures de sécurité

Bonnes pratiques essentielles

Segmentation réseau

Communications chiffrées

Maintenance

Plan de maintenance

Résumé