Segmentation OT/IT : isoler GTB/KNX-IP/GRMS/CCTV du SI bureautique (exemples de règles firewall)

Illustration générée par IA — visuel conceptuel.

Dans un hôtel (ou un site tertiaire), les systèmes « bâtiment » (GTB/BMS, KNX‑IP, GRMS, vidéosurveillance…) cohabitent de plus en plus avec le SI bureautique et l’accès Internet sur un socle IP convergé. Sans séparation claire, un incident côté IT (poste compromis, mouvement latéral, mauvaise configuration) peut impacter l’OT, et inversement un équipement OT trop exposé peut devenir un point d’entrée.

Une segmentation OT/IT utile vise un objectif très concret : définir des flux minimaux (principe allow‑list) entre zones, puis les traduire en règles firewall compréhensibles, traçables et recettables. Pour replacer la segmentation dans une architecture globale d’établissement, voir aussi l’architecture réseau IP d’un hôtel.

Pourquoi la segmentation OT/IT est devenue incontournable en hospitality

En hôtellerie, la convergence IP apporte de la valeur (supervision, services numériques, exploitation), mais elle crée aussi des dépendances :

• Des équipements OT pilotent des fonctions physiques (CVC, éclairage, accès, alarmes techniques). Une exposition ou une propagation non maîtrisée n’a pas les mêmes conséquences qu’un incident sur un poste bureautique.
• Les cycles de vie et les pratiques de mise à jour diffèrent entre IT et OT. Certains contrôleurs, passerelles ou caméras restent en place longtemps et ne suivent pas toujours les mêmes rythmes de patching.
• Les interfaces inter‑systèmes se multiplient (PMS↔GRMS, GTB↔compteurs, CCTV↔postes opérateurs), et ce sont souvent ces « conduits » qui ouvrent trop large si l’architecture n’est pas cadrée.

Si vous cherchez d’abord une mise à plat « réseau » (segmentation, ports, trunks, SSID), notre guide VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ? pose les bases. Ici, on va un cran plus loin : quels flux autoriser, entre quels rôles, et comment le recetter.

Le principe qui marche : zones et conduits (penser flux avant ports)

Une méthode robuste consiste à raisonner en zones (groupes cohérents d’équipements) et en conduits (communications autorisées entre zones), dans l’esprit « zones & conduits » souvent associé aux approches OT (ex. ISA/IEC 62443). L’intérêt opérationnel est simple : on ne discute pas d’abord « numéros de VLAN », mais qui doit parler à qui, et pour quoi, puis on ouvre le strict nécessaire.

Dans un hôtel, on retrouve généralement les zones suivantes (à adapter au périmètre réel) :

• Zone IT (bureautique) : postes, imprimantes, back‑office, Internet.
• Zone OT “bâtiment” : GTB/BMS, passerelles d’intégration, contrôleurs CVC, interfaces KNX‑IP.
• Zone OT “chambres / GRMS” : contrôleurs de chambre, serveur GRMS, passerelles associées.
• Zone CCTV : caméras, NVR/VMS, postes opérateurs (si dédiés).
• Zone Administration / supervision : postes d’admin, outils de maintenance, supervision réseau/OT.
• Zone DMZ OT/IT (recommandée) : zone tampon pour les intégrations nécessaires (API, bastion, accès distant, relais), afin d’éviter les ouvertures directes IT↔OT.

Cette logique rejoint la notion clé rappelée dans notre dossier Cybersécurité d’un hôtel connecté : segmenter, puis contrôler les échanges.

Deux architectures de segmentation fréquentes (et efficaces) en hôtels et bâtiments tertiaires

Architecture A — Segmentation inter‑VLAN + firewall central (site unique)

Quand l’utiliser : établissement de taille moyenne, IT/OT sur un même site, intégrations limitées ou simples.

Principe : le firewall est le point de passage inter‑zones. L’OT est lui-même découpé en sous‑zones (GTB/KNX, GRMS, CCTV, admin). On garde une politique simple : deny par défaut entre zones, allow‑list sur les flux utiles.

• IT ↔ Firewall ↔ OT‑GTB/KNX
• IT ↔ Firewall ↔ OT‑GRMS
• IT ↔ Firewall ↔ CCTV
• Admin ↔ Firewall ↔ toutes zones (mais uniquement via règles explicites)

Architecture B — DMZ OT/IT (la plus confortable dès qu’il y a des intégrations et du support)

Quand l’utiliser : hôtel avec de multiples intégrations (PMS/GRMS/GTB, plateformes cloud, support distant), ou site tertiaire où IT et mainteneurs OT doivent coexister proprement.

Principe : on évite l’accumulation d’exceptions IT→OT en forçant les échanges « transverses » vers une DMZ. La DMZ héberge typiquement :

• un bastion / jump server (poste d’administration contrôlé),
• des connecteurs d’intégration (API/middleware, selon les solutions),
• éventuellement un proxy de mises à jour (si le projet le justifie),
• des services d’authentification/traçabilité, selon la gouvernance IT.

Cette approche simplifie la gouvernance des accès (comptes, journaux, révocation) et réduit le risque de « ports ouverts pour dépanner » qui restent actifs. Sur l’accès distant, voir aussi KNX IP, routage, interfaces et exposition Internet.

Matrice de flux minimaux (allow‑list) : exemples concrets par système

Important : une matrice de flux n’est pas une liste universelle de ports. Elle doit être adaptée aux fabricants (GTB, GRMS, VMS, passerelles), au mode d’exploitation et aux options activées. L’objectif est d’identifier les flux socles, puis de compléter avec les flux spécifiques documentés par les éditeurs retenus.

GTB/BMS : cadrer les échanges de supervision (ex. BACnet/IP)

BACnet/IP est très courant en GTB. Pour démarrer une matrice, un repère utile est le port 47808 (0xBAC0) associé au service bacnet dans le registre IANA.

Point cybersécurité (à ne pas simplifier) : le registre IANA associe ce port à bacnet en TCP et UDP, mais cela ne doit pas être interprété comme “ouvrir les deux”. Côté BACnet/IP, le point de départ opérationnel est généralement UDP 47808 (valeur par défaut fréquemment utilisée, et potentiellement configurable selon les équipements). La décision d’ouvrir autre chose doit donc être justifiée par la documentation fabricant et validée en recette, pas “au cas où”.

À valider au projet : la découverte, les mécanismes multi‑sous‑réseaux (selon topologie) et les éventuels composants intermédiaires. L’idée reste la même : OT‑GTB ne parle pas “librement” au LAN IT, et la supervision doit être positionnée dans la zone prévue.

KNX‑IP : séparer la maintenance (ETS) du reste, et éviter l’exposition

Pour KNXnet/IP, un repère important pour les règles firewall est le port UDP 3671, associé à KNXnet/IP (valeur par défaut usuelle). Sur le plan cybersécurité, l’erreur classique est de rendre une interface KNX‑IP « joignable partout » (voire exposée via NAT/port‑forward). Pour la logique globale (réduction d’exposition, accès distant, comptes), voir KNX Secure : comment sécuriser une installation domotique professionnelle ?.

Exemple de flux minimal (à adapter à votre topologie KNX) :

Si le projet active des mécanismes de sécurité KNX (Data Secure / IP Secure), cela renforce la protection des communications KNX, mais ne remplace pas la segmentation, la gouvernance d’accès et la recette des flux. La stratégie reste donc : qui a le droit de parler à KNX‑IP, et par quel chemin.

GRMS : privilégier un point d’intégration unique (et contrôlé) vers l’IT

Le GRMS se situe au carrefour OT/IT : d’un côté des contrôleurs de chambre et des automatismes, de l’autre des interfaces vers le PMS, des outils d’exploitation, parfois des services applicatifs. Plutôt que d’ouvrir « le réseau chambres » vers le SI, une approche robuste consiste à :

• maintenir chambres & terrain dans une zone OT‑GRMS dédiée,
• positionner le serveur GRMS / middleware comme seul point d’intégration vers l’IT (idéalement via DMZ),
• n’autoriser que les flux applicatifs nécessaires (et documentés) entre PMS et GRMS.

Pour cadrer les responsabilités (qui échange quoi) côté hôtel, voir PMS, GRMS, GTB, serrures et contrôle d’accès : qui échange quoi dans un hôtel ?.

CCTV : isoler les caméras, contrôler l’ingestion, limiter la gestion

En vidéosurveillance, le découpage qui évite beaucoup de dérives est : caméras (edge) ↔ NVR/VMS (collecte/stockage) ↔ postes opérateurs (consultation). On évite de rendre les caméras « administrables » depuis le LAN bureautique.

Un repère utile côté streaming : dans la spécification ONVIF Streaming, RTSP utilise TCP et le port TCP par défaut est 554.

Point de cadrage essentiel (pour éviter le “copier‑coller” de règles incomplètes) : 554/TCP correspond au contrôle RTSP (session, SETUP, PLAY, etc.). Ensuite, selon le mode de transport retenu par la caméra et le VMS (RTP sur UDP vs RTP interleavé dans la session RTSP/TCP), le média peut nécessiter des ports supplémentaires (souvent UDP) négociés lors du SETUP (notamment via les paramètres de ports RTP/RTCP). Conclusion opérationnelle : documenter au projet le mode retenu (RTP/UDP vs interleavé TCP) et, si UDP est retenu, documenter/recetter la plage de ports média à autoriser — puis n’ouvrir ces flux que entre VMS↔caméras (allow‑list IP + journalisation).

Point de vigilance (à placer au moment où l’on parle ports) : 554/TCP est un défaut, pas une garantie universelle. Selon les marques, le durcissement appliqué (désactivation RTSP, RTSP sur un autre port, activation d’HTTPS, profils ONVIF, événements, audio, découverte, etc.) et l’architecture VMS, les flux nécessaires peuvent changer. On n’ouvre donc que ce qui est documenté par le constructeur/éditeur et recetté.

Pour replacer la segmentation dans une conception vidéo complète (réseau, stockage, exploitation), voir Vidéosurveillance IP : comment concevoir un système réellement efficace ?.

Exemple de politique firewall « lisible » (à adapter, mais structurante)

Un bon objectif projet est de produire une politique qui reste compréhensible dans un DOE, et maintenable lors d’une évolution (ajout de caméras, extension GTB, nouveau prestataire). Un exemple de structure :

• Règle 0 : deny par défaut entre zones (inter‑VLAN / inter‑VRF / inter‑segments).
• Règles OT :
  • Autoriser uniquement les flux de supervision/maintenance nécessaires (ex. supervision GTB→BACnet, bastion→KNX‑IP), et documenter chaque ouverture.
  • Empêcher tout accès « large » depuis le LAN IT vers les contrôleurs OT.
• Règles CCTV :
  • NVR/VMS → caméras : ouvrir l’ingestion/streaming requis (ex. RTSP 554 par défaut), puis compléter au projet selon le mode RTP (UDP vs interleavé TCP) recetté ;
  • Postes opérateurs → VMS : préférer une consultation via la plateforme VMS (et non en direct sur les caméras) ;
  • Administration caméras : limiter à une zone OT‑Admin dédiée.
• DMZ (si présente) : toutes les intégrations transverses passent par la DMZ (connecteurs, bastion, accès distant), avec journalisation.
• Accès distant : privilégier VPN + bastion, éviter les redirections de ports « de confort ». Le sujet est détaillé dans notre guide KNX IP et exposition Internet.

Ce qui accélère vraiment les projets : livrables, recette et responsabilités

Livrable n°1 : matrice de flux (par zones, pas par VLAN)

La matrice doit préciser, pour chaque flux : source/destination, protocole, port (si applicable), sens, justification, et test de recette associé. C’est le document qui évite les « ouvertures au fil de l’eau » en fin de chantier.

Livrable n°2 : plan d’adressage et nomenclature maintenable

Sans nomenclature (VLAN/SSID/DHCP/réservations), une segmentation devient difficile à exploiter et à dépanner. Pour structurer ce livrable côté bâtiment, voir Plan d’adressage IP & nomenclature : méthode orientée exploitation.

Livrable n°3 : recette des flux (autoriser ce qu’il faut, bloquer le reste)

Une règle firewall n’a de valeur que si elle est testée :

• Tests “positifs” : chaque flux autorisé doit fonctionner dans les conditions prévues (supervision GTB, ingestion CCTV, maintenance KNX/GRMS).
• Tests “négatifs” : vérifier explicitement que les flux interdits restent bloqués (ex. poste IT → caméras, Wi‑Fi invités → interfaces d’admin OT, etc.).
• Modes dégradés : ce qui doit continuer localement si une interface IT tombe (principe clé en bâtiment). Sur ce point, notre dossier Cybersécurité d’un hôtel connecté rappelle l’importance de limiter les dépendances inutiles.

Points de vigilance (à ne pas “deviner”)

• GRMS et intégrations PMS : ports et protocoles dépendent fortement des éditeurs. La matrice doit être construite à partir des documentations des solutions retenues (et recettée).
• ONVIF / gestion caméra : au‑delà du streaming RTSP, les fonctions d’événements, découverte, administration web et analytics varient selon marques et configurations.
• GTB multi‑sous‑réseaux : certaines architectures BACnet/GTB peuvent exiger des composants ou flux additionnels (à cadrer dans le design, pas en urgence en fin de chantier).

Conclusion : la bonne segmentation OT/IT, c’est une matrice de flux minimaliste

En hospitality, une segmentation OT/IT efficace n’est pas un empilement de VLAN : c’est une architecture de zones, une matrice de flux minimaux (allow‑list) et des règles firewall qui restent exploitables. Les repères de ports et de flux « socles » (BACnet, KNXnet/IP, RTSP) permettent de démarrer vite, mais le vrai gain projet vient de la méthode : responsabilités claires, DMZ quand nécessaire, et recette systématique des conduits.

Si vous préparez un projet hôtelier (neuf ou rénovation), Domocasa intervient en interface IT/technique pour cadrer l’architecture, la matrice de flux et la recette. Vous pouvez commencer par relire notre guide sur l’architecture réseau IP d’un hôtel puis structurer un cahier de flux par lots (GRMS, CCTV, GTB) avant consultation.

Références (sources externes)

• IANA — Service Name and Transport Protocol Port Number Registry (service bacnet, port 47808) : https://www.iana.org/assignments/service-names-port-numbers?search=47808
• BACnet.org — Building Wide‑Area Networks With BACnet (BACnet/IP sur UDP, port UDP 47808 par défaut, configurable) : https://bacnet.org/wp-content/uploads/sites/4/2022/06/Building-Wide-Area-Networks-With-BACnet-Part-2.pdf
• KNX Association — rappel du port par défaut KNXnet/IP (UDP 3671) et mise en garde contre le port‑forwarding Internet : https://www.knx.org/news/your-knx-installation-exposed-securing-ip-side
• ONVIF — Streaming Specification (RTSP/TCP, port par défaut 554) : https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec-v241.pdf
• RFC Editor — RFC 2326 (RTSP) : exemples de négociation de ports RTP/RTCP via le header Transport (client_port / server_port) et transport RTP/RTSP (UDP vs interleaving TCP) : https://www.rfc-editor.org/rfc/rfc2326.html
• ISA — ISA/IEC 62443 series (cadre « zones & conduits ») : https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
• ISA — ISA‑62443‑3‑2 (preview) : zones & conduits / analyse de risque par zone et conduit : https://www.isa.org/getmedia/661c718f-8e64-446d-acf9-2c6286db1b33/isa-62443-3-2-preview.pdf