KNX Secure renforce la protection des communications KNX, mais il ne sécurise pas à lui seul tout le bâtiment. Une installation professionnelle dépend aussi du réseau IP, des accès distants, des comptes administrateurs, des sauvegardes et des passerelles. Ainsi, KNX Secure doit s’intégrer dans une architecture de cybersécurité plus large.
1. Comprendre les deux couches : Data Secure et IP Secure
KNX Data Secure
Data Secure protège les échanges entre équipements KNX compatibles en ajoutant des mécanismes destinés à empêcher la lecture, la modification ou la réutilisation non autorisée de certains télégrammes.
KNX IP Secure
IP Secure protège les communications KNX transportées sur Ethernet, par exemple entre routeurs ou interfaces KNX/IP compatibles.
Ces deux mécanismes répondent donc à des niveaux différents. Dans certains projets, ils fonctionnent ensemble ; cependant, ils ne remplacent ni la sécurité du réseau ni la gestion des comptes.
La documentation officielle KNX distingue bien KNX IP Secure, qui protège les communications KNX sur le média IP, et KNX Data Secure, qui protège les échanges entre appareils au niveau applicatif sur les médias KNX compatibles. Elle décrit également les protections contre la relecture, la manipulation et l’observation non autorisée des télégrammes. Référence : KNX Association — Security overview.
2. Commencer par réduire les surfaces d’exposition
Une interface KNX/IP ou un serveur de visualisation n’a aucune raison d’être accessible depuis tous les réseaux du bâtiment. D’abord, l’équipe doit identifier les systèmes qui ont réellement besoin de communiquer. Ensuite, elle limite les flux.
Par conséquent, VLAN et firewall deviennent des éléments importants de la sécurité globale. Voir notre guide sur les VLAN.
3. Protéger l’accès distant sans exposer directement le système
Une simple redirection de port vers un serveur ou une interface technique augmente inutilement la surface d’exposition. À la place, le projet peut utiliser un VPN, une solution sécurisée du fabricant ou un autre mécanisme adapté.
Par ailleurs, l’administrateur doit pouvoir retirer rapidement l’accès d’un prestataire. Ainsi, la maintenance distante devient une procédure contrôlée plutôt qu’un accès permanent oublié.
4. Traiter comptes, ETS et clés comme des actifs critiques
Les comptes partagés compliquent la traçabilité. D’abord, l’équipe doit privilégier des comptes individuels lorsque la plateforme le permet. Ensuite, elle attribue les droits selon les rôles et retire les accès devenus inutiles.
Le projet ETS constitue également un actif majeur. Dans un projet Secure, les informations de sécurité associées deviennent particulièrement importantes pour la maintenance et les extensions futures.
Par conséquent, le client doit recevoir le projet, les sauvegardes et une méthode de conservation adaptée.
5. Gérer la coexistence Secure / non Secure avec transparence
Une rénovation peut combiner des appareils Secure et des équipements plus anciens. Cependant, cette coexistence crée un niveau de protection hétérogène.
D’abord, l’intégrateur doit identifier quelles fonctions bénéficient réellement des mécanismes Secure. Ensuite, il documente les segments qui restent non Secure.
Ainsi, le projet ne donne pas l’impression que tout le bâtiment possède le même niveau de protection alors que ce n’est pas le cas.
6. Adapter l’architecture au type de bâtiment
Villa
Les fonctions KNX peuvent rester locales tandis qu’un serveur de visualisation offre un accès distant protégé. Le propriétaire et l’intégrateur utilisent des comptes distincts, puis le client reçoit ETS et sauvegardes.
Hôtel ou tertiaire
Plusieurs systèmes peuvent communiquer : KNX, GTB, GRMS, CVC, contrôle d’accès et réseau informatique. Par conséquent, les responsabilités doivent être réparties entre intégrateur, IT, exploitant et BET.
Notre article sur la cybersécurité d’un hôtel connecté illustre cette logique multi-systèmes.
7. Maintenir la sécurité pendant tout le cycle de vie
Une installation KNX reste en service pendant de nombreuses années. D’abord, l’exploitant doit donc revoir périodiquement les comptes et les accès distants. Ensuite, il applique les mises à jour pertinentes après analyse de leur impact.
De plus, toute modification importante doit entraîner une nouvelle sauvegarde et, si nécessaire, une mise à jour du DOE.
Ainsi, la sécurité reste un processus continu plutôt qu’un état figé au jour de la livraison.
8. Recetter la sécurité et les modes dégradés
La réception doit vérifier les fonctions normales mais aussi les accès refusés et certains scénarios de panne. Par exemple, l’équipe teste les fonctions Secure configurées, le comportement lors d’une coupure réseau et l’accès distant autorisé.
Ensuite, elle contrôle la présence du projet ETS, des sauvegardes et de la documentation. Ainsi, la recette valide l’architecture de sécurité autant que l’automatisation.
Checklist KNX Secure
- D’abord, identifiez les fonctions et flux à protéger.
- Ensuite, distinguez Data Secure et IP Secure.
- Par ailleurs, segmentez le réseau technique et limitez les flux.
- De plus, protégez les accès distants sans exposition directe.
- Puis, gérez les comptes, ETS et informations de sécurité.
- Aussi, documentez les éventuelles zones non Secure.
- Enfin, recetez les accès, sauvegardes et modes dégradés.
Conclusion
Pour conclure, KNX Secure constitue une brique importante d’une architecture KNX professionnelle. La sécurité réelle dépend toutefois de l’ensemble du système : bus, réseau IP, accès distant, serveurs, comptes, sauvegardes et procédures.