DMZ industrielle pour protéger le réseau de production

DMZ industrielle pour protéger le réseau de production

Une DMZ (Demilitarized Zone, zone démilitarisée) industrielle n’est pas un réseau intermédiaire décoratif entre l’informatique de gestion et l’atelier. C’est la frontière qui empêche un compromis du système d’information d’entreprise de devenir une commande envoyée à la production. Le compromis central est brutal : on gagne une réduction massive du mouvement latéral, on paie par des flux plus contraints, des relais à exploiter et des exceptions qui doivent cesser d’être invisibles.

Explication de la marmotte

Une usine a besoin d’échanger des informations avec ses bureaux, mais laisser tout le monde entrer partout finit mal. La zone démilitarisée ressemble au sas d’un bâtiment sensible : elle permet les échanges nécessaires tout en évitant qu’une personne ayant accès aux bureaux arrive directement près des machines.

→ Lire l’explication complète de la marmotte

Modèle de zones entre informatique et production

La séparation doit suivre les niveaux fonctionnels du modèle Purdue, pas l’organigramme ni les sous-réseaux historiques. La zone entreprise héberge messagerie, annuaires, postes bureautiques et applications métier. La zone de production regroupe les systèmes de supervision, les serveurs d’ingénierie, les automates programmables et les équipements de terrain. Entre les deux, la DMZ industrielle porte exclusivement des services relais.

Un automate programmable industriel, ou PLC (Programmable Logic Controller), ne doit jamais accepter une session initiée depuis le réseau d’entreprise. Cette règle vaut aussi lorsqu’un équipement prétend parler Transport Layer Security, ou TLS. Le chiffrement protège un flux contre l’écoute et l’altération sur le trajet, il ne transforme pas un protocole de commande en interface d’administration acceptable depuis le réseau bureautique. Ouvrir le port 443 vers la production au nom du chiffrement, c’est fermer la porte à double tour et remettre la clé sous le paillasson, mais dans un format JSON.

La DMZ doit être encadrée par deux politiques de filtrage indépendantes : une politique entre entreprise et DMZ, une autre entre DMZ et production. Un unique pare-feu avec trois interfaces réduit le nombre de boîtiers, pas la confiance implicite. Une erreur de règle, un accès d’administration compromis ou un défaut du moteur de filtrage peut alors franchir les deux frontières. Deux plans de contrôle distincts, deux jeux de règles et deux chemins d’administration limitent ce défaut commun.

Le sens des flux compte autant que leur liste. La règle de base est la suivante :

• la production initie les échanges nécessaires vers un relais de DMZ ;
• l’entreprise consulte ou récupère des données depuis ce relais ;
• aucun flux initié depuis l’entreprise ne joint directement une adresse de production ;
• les flux d’administration passent par un bastion placé en DMZ, jamais par un poste bureautique ;
• les sauvegardes traversent des relais dédiés, avec dépôt et restauration contrôlés.

Une architecture de segmentation et filtrage réseau générale reste nécessaire, mais le réseau industriel ajoute une contrainte : la disponibilité et la déterminisme opérationnel priment souvent sur la correction immédiate. Une règle qui bloque une commande légitime au mauvais moment peut arrêter une ligne. Cela ne justifie pas le réseau plat. Cela oblige à valider chaque flux contre le procédé réel, puis à traiter le changement comme un changement de sécurité et d’exploitation.

Services de DMZ industrielle et flux autorisés

Un serveur d’historisation peut répliquer les données de procédé vers une copie située en DMZ. Les applications d’entreprise consultent cette copie, pas l’historien de production. Le protocole de transfert doit être choisi selon le produit, mais la propriété à vérifier reste constante : aucune requête issue de l’entreprise ne doit être retransmise de façon transparente au système de supervision industriel.

Les mises à jour constituent le piège classique. Un dépôt de correctifs en DMZ reçoit les paquets depuis l’entreprise, les analyse, puis les expose à la production selon une fenêtre validée. Un miroir de paquets n’est pas un scanner magique : analyser un exécutable avec un antivirus ne prouve ni sa compatibilité avec l’automate, ni son innocuité pour une station d’ingénierie. La validation inclut signature éditeur, empreinte cryptographique, compatibilité matérielle et procédure de retour arrière.

L’accès distant des mainteneurs doit terminer sur un bastion, ou jump host, en DMZ. Le bastion applique une authentification multifacteur, enregistre les sessions et n’autorise que les protocoles explicitement requis vers les actifs industriels. L’authentification multifacteur, ou MFA (Multi-Factor Authentication), combine des preuves indépendantes d’identité, par exemple un secret et une clé matérielle. Elle réduit l’impact d’un mot de passe volé ; elle ne rend pas acceptable un compte partagé entre équipes de maintenance.

Les transferts de fichiers doivent suivre un modèle dépôt puis retrait. Un serveur de transfert en DMZ reçoit le fichier, le place en quarantaine, journalise l’émetteur, vérifie taille, type, signature et empreinte, puis le publie dans un espace distinct accessible depuis la production. Un partage de fichiers monté simultanément depuis les deux zones rétablit un pont permanent. Il mérite le nom de tunnel, pas celui de DMZ.

Les flux de temps exigent une attention particulière. Le Network Time Protocol, ou NTP, est souvent traité comme un détail jusqu’au premier incident où les journaux deviennent inutilisables. La DMZ doit relayer le temps vers la production depuis des sources approuvées. Une source de temps publique directement joignable depuis les automates est une commodité qui devient une dépendance externe, avec toute la poésie d’une horloge d’usine pilotée par Internet.

Exemple de filtrage entre DMZ et supervision

L’exemple suivant utilise nftables sur un pare-feu Linux placé entre une DMZ et un réseau de supervision. Il illustre une politique restrictive : le collecteur de DMZ reçoit uniquement un flux de télémétrie initié par le serveur d’historisation, tandis que le bastion accède à une station d’ingénierie par Remote Desktop Protocol, ou RDP, sur un port strictement défini.

table inet ot_filter {
  chain forward {
    type filter hook forward priority filter; policy drop;

    # Autoriser le retour des flux établis, sans ouvrir de nouveaux chemins.
    ct state established,related accept

    # Historien industriel vers collecteur de DMZ, protocole documenté.
    ip saddr 10.40.20.15 ip daddr 10.40.10.30 tcp dport 4840 ct state new accept

    # Bastion de DMZ vers station d'ingénierie, accès journalisé et limité.
    ip saddr 10.40.10.20 ip daddr 10.40.20.40 tcp dport 3389 ct state new accept

    # Journaliser les refus sans saturer la collecte lors d'un scan.
    limit rate 10/minute log prefix "OT-DMZ-DROP: " level warning drop
  }
}

Le port 4840 correspond fréquemment à OPC UA (Open Platform Communications Unified Architecture), mais le numéro de port ne suffit jamais à qualifier un flux. Il faut vérifier le rôle exact, le sens d’initiation, l’identité des pairs, les certificats utilisés et le comportement en perte de liaison. Certains produits reconnectent agressivement, d’autres conservent des sessions mortes, d’autres encore redémarrent avec une configuration par défaut qui aurait mérité une carrière dans le théâtre absurde.

Les règles doivent être gérées comme du code : dépôt versionné, revue séparée par exploitation et sécurité, tests sur maquette représentative, procédure de repli. Le contrôle d’accès réseau, ou NAC (Network Access Control), peut compléter cette frontière en empêchant un équipement non reconnu de rejoindre un segment. Il ne remplace pas la DMZ : un équipement autorisé mais compromis reste autorisé, ce qui est précisément le problème.

Surface d’attaque et échecs prévisibles

La DMZ réduit le mouvement latéral, elle n’empêche pas un attaquant d’utiliser un relais autorisé. Un serveur de transfert vulnérable, un bastion compromis ou un collecteur d’historisation exposé deviennent des points d’appui. Les contre-mesures sont concrètes : durcissement des systèmes, suppression des services inutiles, correctifs selon fenêtre validée, authentification forte, segmentation locale, journalisation exportée et sauvegardes hors ligne.

Les protocoles industriels anciens posent un problème structurel : beaucoup ne chiffrent pas, n’authentifient pas leurs commandes ou reposent sur une confiance réseau totale. Les encapsuler dans un tunnel ne corrige pas leur modèle de sécurité. Il faut limiter leurs interlocuteurs au niveau IP, filtrer les commandes quand un pare-feu industriel le permet, et empêcher toute exposition hors de la zone prévue. Le sujet recoupe les principes de l’architecture cyber : compenser une absence de contrôle applicatif par plusieurs contrôles de frontière, sans prétendre l’effacer.

La supervision passive est préférable à l’inspection active sur les segments critiques. Un capteur passif reçoit une copie du trafic via un port miroir ou un TAP (Test Access Point), point d’accès de test. Un scanner actif peut provoquer une indisponibilité, remplir des journaux limités ou faire tomber une pile réseau qui n’avait jamais rencontré un paquet un peu curieux. Les équipements industriels ont parfois une relation philosophique avec les paquets inattendus : ils préfèrent ne plus répondre.

La DMZ ne garantit pas la sûreté de fonctionnement. Elle ne détecte pas une logique automate malveillante déjà chargée, ne valide pas la cohérence d’une consigne physique et ne remplace pas les mécanismes de sécurité instrumentés. Elle ne résout pas non plus le risque interne d’un opérateur légitime abusant d’un accès autorisé. Ces protections viennent de la gestion des identités, du contrôle des changements, de la validation métier et de la surveillance du procédé.

Exploitation, identités et reprise de la DMZ

Chaque compte de bastion doit être nominatif, temporaire quand l’intervention est externe, et séparé des comptes bureautiques. Les comptes d’administration partagés empêchent l’attribution et rendent une révocation globale inévitable après incident. Une identité fédérée peut être utilisée si la dépendance à l’annuaire est maîtrisée : une coupure du fournisseur d’identité ne doit pas interdire une action de sécurité urgente sur un site isolé.

Les certificats utilisés par les collecteurs et les bastions demandent un inventaire, une date d’expiration surveillée et une procédure de renouvellement testée. La révocation d’un certificat ne ferme pas nécessairement les sessions déjà établies ; les applications doivent reconnecter et vérifier l’état de révocation, quand cette vérification est disponible. La gestion des certificats relève de la PKI et TLS, mais son application en environnement industriel doit tenir compte des fenêtres de maintenance et des équipements incapables de valider une chaîne moderne.

Les journaux des pare-feux, bastions, relais de fichiers et systèmes de supervision doivent converger vers une collecte hors de la zone de production. Prévoir des horodatages cohérents, une rétention compatible avec les enquêtes et des alertes sur les refus inhabituels, les nouvelles destinations, les échecs d’authentification et les changements de règles. Une alerte sans propriétaire ni délai de traitement reste une décoration numérique, légèrement plus coûteuse qu’un poster.

La reprise impose de sauvegarder les configurations de pare-feu, bastions, listes de certificats, règles de transfert et documentation de flux. Restaurer un pare-feu depuis une sauvegarde non vérifiée peut réintroduire des règles supprimées après un incident. Tester la restauration dans une zone isolée, comparer la configuration restaurée à la référence approuvée, puis valider les flux essentiels dans un ordre défini : supervision, accès d’urgence, collecte, transfert de fichiers, enfin services de confort.

🐝 Ce qui arrive si on s’en passe

Sans cette frontière, il ne reste qu’un seul levier d’isolement en cas d’incident : débrancher le lien entre bureautique et production, c’est-à-dire arrêter aussi les échanges légitimes dont dépend l’exploitation. Faute de point de passage unique, les flux réels ne sont jamais inventoriés, et l’ordre de remise en service après coupure devient une improvisation. Les copies de données de procédé et les dépôts de correctifs restent accessibles depuis les mêmes chemins que la production, ce qui prive d’un espace de quarantaine où un fichier douteux peut être retenu sans bloquer l’atelier. L’analyse après incident perd son observatoire naturel : sans relais intermédiaire journalisant émetteurs, empreintes et horaires, la reconstitution repose sur des équipements industriels à rétention courte, souvent incapables d’exporter quoi que ce soit d’exploitable.

🦫 Explication de la marmotte 🍫

Un réseau industriel contient des machines qui mesurent, contrôlent ou fabriquent. Le réseau des bureaux contient des postes de travail, des applications de gestion et des accès Internet. Ces deux environnements n’ont pas le même niveau de risque ni les mêmes besoins. Une zone démilitarisée est placée entre eux pour empêcher une connexion directe.

Les informations de production vont d’abord vers des serveurs installés dans cette zone intermédiaire. Les applications des bureaux consultent ces serveurs, sans contacter les machines de production. Dans l’autre sens, les fichiers de mise à jour arrivent dans la zone intermédiaire, sont contrôlés, puis deviennent disponibles pour la production selon une procédure prévue. Les personnes qui doivent administrer une machine passent aussi par un poste intermédiaire surveillé.

Deux filtres réseau séparent les trois parties. Chaque filtre n’autorise que des communications listées à l’avance, entre des machines précises et pour une raison précise. Une communication non prévue est bloquée et enregistrée.

Si un poste de bureau est infecté, l’attaquant ne peut donc pas atteindre directement les machines. Il peut encore essayer de compromettre un serveur intermédiaire ou un compte d’administration, ce qui explique l’authentification renforcée, les journaux et les mises à jour contrôlées. Si un filtre tombe en panne, les procédures d’urgence doivent maintenir la production sans ouvrir durablement tous les accès.

À lire aussi

• Faire cohabiter équipements industriels anciens et neufsRétrocompatibilité industrielle : faire cohabiter du neuf et du matériel des années 1990 sans étendre la surface d'attaque ni rendre l'exploitation impossible.
• Sécuriser une interface HMI industrielle WindowsCette page décrit comment réduire le rôle de pivot d'une interface homme-machine industrielle entre le réseau informatique et les automates.
• Sécuriser un SCADA d’eau et d’énergieSécurisation des systèmes SCADA d’eau et d’énergie face aux protocoles historiques, aux effets physiques des commandes et aux exigences de NIS2.
• Réseaux spécialisés, sobriété avancée et futurs raisonnablesRegrouper les domaines spécialisés et pistes d’évolution à connaître sans les présenter comme des certitudes : OT, industriel, quantique, participatif, blockchain et réseaux futurs.

Pages voisines

La citent

• Faire cohabiter équipements industriels anciens et neufs
• Sécuriser un SCADA d’eau et d’énergie
• Sécuriser une interface HMI industrielle Windows
• MSTP : spanning tree multiple pour réseaux industriels en anneau
• NCSC-NL et coordination cyber portuaire néerlandaise
• Pare-feu, architectures et NAT en une page
• Zero Trust pour les accès des prestataires

DMZ industrielle pour protéger le réseau de production

Elle cite

• ⇄Lien dans les deux sens :Pourquoi un automate industriel ne se patche pas
• ⇄Lien dans les deux sens :Sécuriser un SCADA aux protocoles non authentifiés
• RDP exposé sur Internet : risques, durcissement et détection

⇄ : les deux pages se citent l’une l’autre.