DMZ : définition, architecture et bonnes pratiques en 2026

Une DMZ (demilitarized zone, ou zone démilitarisée) est un segment réseau intermédiaire, isolé à la fois d'Internet et du réseau interne, dans lequel une organisation place les services qui doivent être joignables depuis l'extérieur : site web, relais de messagerie, reverse proxy, passerelle VPN ou serveur DNS public. Son principe est simple : si l'un de ces serveurs exposés est compromis, l'attaquant reste enfermé dans une zone dont les flux vers le système d'information interne sont strictement filtrés par un pare-feu. En 2026, alors que les équipements de bordure concentrent une part croissante des intrusions, la DMZ reste une brique de base de la défense en profondeur, à condition d'être conçue avec une matrice de flux rigoureuse, supervisée et régulièrement auditée. Pour la mise en œuvre concrète sur un pare-feu open source, notre guide d'installation et de configuration d'OPNsense détaille la création des interfaces et des règles. Ce dossier explique la définition, les architectures de référence, la DMZ industrielle, les pièges courants et la manière de détecter une compromission.

Qu'est-ce qu'une DMZ ? Définition et origine du terme

Le terme vient du vocabulaire militaire : une zone démilitarisée désigne une bande de territoire tampon entre deux parties, où aucune force armée n'est autorisée. Transposée à l'informatique dans les années 1990, l'image décrit un espace intermédiaire entre le monde hostile, Internet, et le territoire de confiance, le réseau interne. Les anglophones qui cherchent « dmz meaning » ou « define dmz » tombent sur la même idée : une zone tampon contrôlée.

Concrètement, une DMZ informatique est une interface ou un VLAN dédié sur le pare-feu périmétrique, avec son propre plan d'adressage. Les serveurs qui y résident reçoivent des connexions entrantes depuis Internet, mais leurs échanges avec le réseau interne passent par des règles explicites. Le pare-feu applique ainsi trois politiques distinctes : Internet vers DMZ, DMZ vers interne, et interne vers DMZ, chacune avec sa propre logique.

Ce que la DMZ n'est pas

Une DMZ n'est pas un réseau « ouvert » ni une zone sans filtrage, contrairement à ce que laisse croire l'option homonyme des box grand public. Elle ne remplace pas non plus le durcissement des serveurs : un système vulnérable reste exploitable, la zone limite seulement ce que l'attaquant peut atteindre ensuite. Enfin, ce n'est pas un simple VLAN : sans règles de filtrage entre segments, un VLAN isole le trafic de diffusion, pas les flux applicatifs.

DMZ et défense en profondeur

La défense en profondeur consiste à superposer des barrières indépendantes pour qu'une défaillance unique ne suffise pas à compromettre l'ensemble. La zone démilitarisée en est l'illustration réseau : premier filtrage côté Internet, durcissement du serveur exposé, second filtrage vers l'interne, puis contrôle d'accès applicatif. Chaque couche ralentit l'attaquant et produit des traces exploitables par l'équipe de détection, ce qui augmente les chances d'interrompre une intrusion avant l'atteinte des données critiques.

Pourquoi la zone démilitarisée reste indispensable en 2026

Les services exposés constituent la porte d'entrée la plus directe vers un système d'information. Le référentiel MITRE ATT&CK décrit cette voie sous la technique T1190, l'exploitation d'applications exposées publiquement, et cite parmi les mesures d'atténuation la segmentation des serveurs exposés dans une DMZ ou sur une infrastructure d'hébergement séparée. La même fiche recommande de restreindre les flux sortants de ces serveurs pour gêner le pilotage d'une machine compromise.

Ces chiffres montrent qu'il faut raisonner en « présomption de compromission » pour tout ce qui est exposé. Un correctif publié ne protège rien tant qu'il n'est pas déployé, et la fenêtre entre divulgation et exploitation se compte souvent en jours. Pendant cette période, la DMZ est ce qui empêche une vulnérabilité sur un portail web ou un relais de messagerie de se transformer immédiatement en accès au cœur du réseau.

Les équipements de sécurité eux-mêmes sont devenus des cibles privilégiées. Notre analyse sur les VPN, pare-feux et ADC ciblés par les groupes APT explique pourquoi ces équipements de périmètre sont devenus des cibles prioritaires. Une passerelle VPN placée dans un segment dédié, dont les flux vers l'interne sont filtrés et journalisés, limite les dégâts si son système est compromis par une faille encore non corrigée.

Architecture DMZ : les trois topologies de référence

Il n'existe pas une seule architecture DMZ, mais trois grands modèles qui diffèrent par le nombre de pare-feu et le degré d'indépendance entre barrières. Le choix dépend du niveau de risque, du budget, des compétences disponibles et des exigences réglementaires. Les recommandations de l'ANSSI relatives à l'interconnexion d'un SI à Internet, publiées en juin 2020, consacrent une section au concept de zone démilitarisée et détaillent plusieurs architectures, en alertant sur les risques de mutualisation.

Pare-feu unique à trois interfaces

Le modèle le plus répandu dans les PME repose sur un seul pare-feu doté de trois interfaces : WAN vers Internet, LAN vers le réseau interne et une troisième interface pour la DMZ. Toutes les politiques sont centralisées sur un équipement, ce qui simplifie l'administration et réduit les coûts. Le revers est évident : ce pare-feu devient un point unique de défaillance, et sa compromission ouvre tous les segments à la fois.

Double pare-feu en série

L'architecture à double pare-feu place un pare-feu externe entre Internet et la DMZ, puis un pare-feu interne entre la DMZ et le réseau de l'entreprise. Pour atteindre l'interne, un attaquant doit franchir deux équipements distincts. Lorsqu'ils proviennent de deux éditeurs différents, une vulnérabilité unique ne suffit plus, mais la charge d'exploitation double : deux consoles, deux cycles de correctifs, deux politiques à maintenir cohérentes.

DMZ multiples ou segmentées

Les organisations plus matures créent plusieurs DMZ selon la nature des services : une zone pour les serveurs web publics, une pour la messagerie, une pour les accès distants, une autre pour les échanges avec les partenaires. Cette segmentation limite les mouvements latéraux au sein même de la zone exposée : un serveur web compromis ne peut plus atteindre le relais SMTP voisin. Elle demande toutefois une matrice de flux plus détaillée et une documentation à jour.

Quels services placer dans une DMZ, et lesquels jamais

La règle de décision est la suivante : un service va en DMZ s'il doit accepter des connexions initiées depuis un réseau moins fiable que le réseau interne. Tout ce qui n'a pas besoin d'être joignable de l'extérieur reste à l'intérieur. Cette question doit être posée service par service, car beaucoup d'exposition inutile vient de serveurs placés en zone démilitarisée « par commodité » lors d'un projet pressé.

Les services qui ont leur place dans une DMZ sont principalement les suivants :

• les reverse proxies et pare-feu applicatifs web qui terminent les connexions HTTPS avant de relayer vers les applications internes ;
• les relais de messagerie SMTP entrants et sortants, qui filtrent le courrier avant de le transmettre au serveur interne ;
• les serveurs DNS faisant autorité pour les zones publiques, séparés des résolveurs internes ;
• les passerelles d'accès distant, VPN ou bastions d'accès pour les prestataires ;
• les serveurs d'échange de fichiers avec les partenaires, en mode dépôt plutôt qu'en accès direct.

À l'inverse, certains composants ne doivent jamais résider dans la zone exposée. Les contrôleurs de domaine Active Directory, les bases de données métier, les serveurs de fichiers internes et les consoles d'administration de la sécurité restent dans des zones de confiance. Le serveur web en DMZ interroge la base interne par un flux unique, documenté et chiffré, plutôt que d'héberger lui-même les données sensibles.

Le cas du reverse proxy

Le reverse proxy est souvent la meilleure façon de réduire la surface exposée d'une DMZ. Seul ce composant reçoit les connexions Internet, termine le chiffrement TLS, applique des contrôles et relaie vers les applications internes. Les solutions auto-hébergées modernes, présentées dans notre guide sur Pangolin, reverse proxy et tunnel self-hosted, permettent même d'exposer un service sans ouvrir de port entrant vers le réseau interne.

Matrice des flux : la règle d'or du filtrage DMZ

La matrice de flux est le document qui liste chaque communication autorisée : source, destination, protocole, port, justification métier et propriétaire. C'est la référence à partir de laquelle les règles du pare-feu sont écrites et auditées. Sans elle, une politique de filtrage dérive inévitablement : des règles temporaires deviennent permanentes et plus personne ne sait pourquoi un port est ouvert.

Le principe structurant est directionnel. Internet peut initier des connexions vers la DMZ sur les seuls ports publiés. Le réseau interne peut initier des connexions vers la DMZ pour l'administration et les flux applicatifs. En revanche, aucune connexion ne doit être initiée depuis la DMZ vers le réseau interne, sauf exception documentée, limitée à une destination et un port précis, et revue périodiquement.

Limiter les flux sortants

Les flux sortants de la DMZ vers Internet sont le second angle mort. Un serveur web n'a généralement besoin que de résoudre des noms via un résolveur contrôlé et de récupérer ses mises à jour depuis un dépôt identifié. Bloquer le reste empêche un attaquant de télécharger ses outils ou d'établir un canal de commande. Le référentiel MITRE ATT&CK recommande explicitement cette restriction pour les serveurs exposés publiquement.

Exemple de politique sur un pare-feu Linux

L'exemple suivant illustre, avec nftables, une politique minimale pour un pare-feu à trois interfaces. Il s'agit d'un squelette pédagogique à adapter : les noms d'interfaces, adresses et ports sont fictifs. Sur une appliance comme OPNsense, la même logique se traduit par des règles par interface dans l'interface web, avec une politique par défaut de refus.

table inet filtre {
  # Fichier /etc/nftables.conf, squelette de politique DMZ (valeurs fictives)
  # wan0 = Internet, dmz0 = 192.0.2.0/24, lan0 = 10.10.0.0/16, adm0 = administration
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    # Internet -> reverse proxy en DMZ : HTTPS uniquement
    iifname "wan0" oifname "dmz0" ip daddr 192.0.2.10 tcp dport 443 accept
    # Reverse proxy -> application interne : un seul flux documenté
    iifname "dmz0" oifname "lan0" ip saddr 192.0.2.10 ip daddr 10.10.5.20 tcp dport 8443 accept
    # Administration de la DMZ depuis le réseau dédié uniquement
    iifname "adm0" oifname "dmz0" tcp dport 22 accept
    # DMZ -> Internet : uniquement le dépôt de mises à jour via proxy sortant
    iifname "dmz0" oifname "wan0" ip daddr 198.51.100.50 tcp dport 3128 accept
    # Tout le reste est refusé et journalisé
    log prefix "DMZ-DROP " counter drop
  }
}

Trois éléments de cet exemple méritent d'être généralisés. La politique par défaut est le refus. Le flux de la DMZ vers l'interne est unique, nominatif et justifiable. Enfin, les paquets refusés sont journalisés, ce qui fournit à l'équipe de détection un signal précieux : un serveur exposé qui tente soudain de joindre de nombreuses adresses internes est un indicateur fort de compromission.

Durcir les serveurs exposés de la zone démilitarisée

La DMZ limite les conséquences d'une compromission, mais elle ne l'empêche pas. Chaque serveur exposé doit donc être durci comme s'il était seul face à Internet. Cela commence par une installation minimale : uniquement les paquets nécessaires au service, aucun outil de compilation, aucun interpréteur superflu. Moins il y a de composants, moins il y a de vulnérabilités à corriger et d'outils réutilisables par un attaquant.

La gestion des correctifs doit être prioritaire pour ces machines. Les vulnérabilités activement exploitées sur des services exposés imposent un délai de déploiement très court, parfois de quelques jours. Un inventaire précis des versions, un abonnement aux bulletins des éditeurs et une procédure de mise à jour d'urgence testée à l'avance sont des prérequis, pas des options, pour tout ce qui réside en DMZ.

Comptes, secrets et annuaire

Une erreur fréquente consiste à joindre les serveurs de la DMZ au domaine Active Directory interne. Cette jonction impose d'ouvrir de nombreux ports vers les contrôleurs de domaine et transforme une compromission locale en porte d'entrée vers l'annuaire. Préférez des comptes locaux gérés par un coffre-fort de secrets, ou un annuaire dédié à la DMZ, sans relation d'approbation avec la forêt de production.

Administration hors bande

L'administration des serveurs exposés doit passer par un réseau dédié, joignable uniquement depuis des postes d'administration durcis ou un bastion. Les interfaces SSH, RDP ou les consoles web de gestion ne doivent jamais être accessibles depuis Internet ni depuis le réseau bureautique. Cette séparation empêche qu'un poste utilisateur compromis par hameçonnage serve de tremplin pour reconfigurer un serveur de la zone démilitarisée.

DMZ industrielle : séparer IT et OT

Dans les environnements industriels, la notion d'industrial DMZ désigne une zone tampon entre le réseau informatique de gestion (IT) et le réseau de technologies opérationnelles (OT), qui pilote automates, supervision SCADA et équipements physiques. Dans le modèle de référence Purdue, elle est souvent appelée niveau 3.5. Son objectif est qu'aucune communication directe ne relie la bureautique aux systèmes de contrôle industriels.

Le guide NIST SP 800-82 Rev. 3, consacré à la sécurité des technologies opérationnelles, publié en septembre 2023, décrit les topologies OT typiques et les contre-mesures associées, dont la segmentation entre IT et OT. Le NIST a ouvert à l'automne 2026 la consultation publique sur un projet de révision 4, ce qui invite les exploitants à suivre l'évolution de ces recommandations.

Ce que l'on place dans une DMZ IT/OT

La DMZ industrielle héberge les composants qui doivent échanger avec les deux mondes : réplique de l'historien de production consultée par les équipes de gestion, serveur de correctifs et d'antivirus relais, bastion d'accès pour la télémaintenance des intégrateurs, serveur d'échange de fichiers contrôlés. Les flux se terminent dans cette zone : l'IT interroge la réplique, l'OT pousse ses données vers elle, sans traversée directe.

Les priorités diffèrent de l'informatique classique. En OT, la disponibilité et la sûreté des personnes passent avant la confidentialité, et un redémarrage imprévu peut arrêter une ligne de production. C'est pourquoi la segmentation par DMZ, qui protège sans imposer de modifications sur les automates eux-mêmes, est une mesure compensatoire privilégiée. Notre dossier sur l'architecture de sécurité OT/IT convergente et la segmentation approfondit ce modèle.

Retour terrain : Cas typique rencontré en mission — sur un site industriel, la revue du pare-feu IT/OT révèle des flux directs entre postes bureautiques et automates, ouverts pour une mise en service puis jamais refermés. Un poste hameçonné atteint alors le procédé sans traverser la DMZ. Je recommande d'identifier les usages avec les automaticiens, de les basculer vers le bastion ou la réplique d'historien, puis de fermer chaque règle hors production.

DMZ, cloud et Zero Trust : ce qui change

Le passage au cloud ne fait pas disparaître le concept de DMZ, il en change la forme. Dans un environnement IaaS, la zone démilitarisée devient un sous-réseau public dans un réseau virtuel, protégé par des groupes de sécurité, des listes de contrôle réseau et souvent un pare-feu virtuel. Les services exposés y résident, tandis que les bases de données et les traitements métier sont placés dans des sous-réseaux privés sans adresse publique.

Le modèle Zero Trust remet en cause l'idée d'un réseau interne « de confiance », mais il ne rend pas la segmentation obsolète. Il ajoute une vérification d'identité et de posture à chaque accès, là où la DMZ classique raisonnait surtout en adresses et en ports. En pratique, les architectures de 2026 combinent les deux : des zones réseau cloisonnées et des contrôles d'accès applicatifs fondés sur l'identité de l'utilisateur et de l'équipement.

Microsegmentation et DMZ

La microsegmentation pousse la logique de la DMZ jusqu'au niveau de chaque charge de travail : chaque serveur ou conteneur reçoit sa propre politique de flux. Elle est particulièrement utile dans les centres de données virtualisés, où le trafic est-ouest entre serveurs dépasse largement le trafic entrant. Elle complète la zone démilitarisée périmétrique sans la remplacer, car les services exposés restent les plus attaqués.

Concevoir une DMZ pas à pas

Un projet de zone démilitarisée réussi suit une démarche ordonnée plutôt qu'une succession de règles ajoutées au besoin. L'objectif est d'aboutir à une architecture dont chaque flux est justifié, testé et supervisé. Les étapes ci-dessous valent pour une création comme pour la remise à plat d'une DMZ existante, qu'elle repose sur un pare-feu physique, une appliance virtuelle ou un réseau cloud.

Choisir et administrer le pare-feu de la DMZ

Selon le guide NIST SP 800-41 Rev. 1 sur les pare-feu et leurs politiques, un pare-feu contrôle les flux entre réseaux dont les postures de sécurité diffèrent, ce qui correspond exactement au rôle attendu en bordure de zone exposée.

Celui qui porte la DMZ doit gérer plusieurs interfaces ou VLAN, appliquer des règles avec état, journaliser finement et, idéalement, offrir une prévention d'intrusion. Les solutions open source comme OPNsense ou pfSense couvrent ces besoins pour la plupart des PME ; notre comparatif OPNsense vs pfSense 2026 aide à choisir selon le rythme de mises à jour, l'ergonomie et l'écosystème de plugins.

Le pare-feu est lui-même un équipement exposé. Son interface d'administration ne doit être joignable que depuis le réseau d'administration, jamais depuis le WAN. Ses mises à jour doivent suivre le même rythme prioritaire que les serveurs de la DMZ. Dans son guide sur l'interconnexion à Internet, l'ANSSI range parmi les cas à proscrire la mutualisation du filtrage entre zones sur un même équipement virtualisé, car elle réduit l'indépendance des barrières.

Configurer les journaux dès le départ

La journalisation n'est pas une étape finale : elle se configure en même temps que les règles. Chaque règle de refus importante doit produire un journal, et ces journaux doivent être exportés vers un collecteur central horodaté, hors de portée d'un attaquant qui prendrait le contrôle du pare-feu. Sans cette précaution, la reconstitution d'une intrusion devient très difficile, faute de traces fiables.

Détecter une compromission dans la DMZ

Un serveur exposé finira tôt ou tard par être visé, et la question devient alors la vitesse de détection. La fiche T1190 du référentiel MITRE ATT&CK sur l'exploitation d'applications exposées décrit une chaîne de signaux à corréler : requêtes anormales sur le service public, pic d'erreurs serveur, processus du service web qui lance un interpréteur de commandes, puis connexion sortante inhabituelle depuis l'hôte.

Plusieurs signaux simples à mettre en place couvrent une grande partie des scénarios :

1. les refus de connexion du pare-feu depuis la DMZ vers le réseau interne, qui ne devraient jamais apparaître en fonctionnement normal ;
2. les nouvelles destinations sortantes vers Internet depuis un serveur exposé, comparées à une liste de référence ;
3. la création de processus enfants inattendus par le serveur web ou le relais de messagerie ;
4. l'apparition de fichiers exécutables ou de scripts dans les répertoires publiés ;
5. les modifications de configuration ou les redémarrages non planifiés des équipements de bordure.

Ces détections reposent sur une base de comportement normal. C'est là que la matrice de flux prend toute sa valeur : un serveur dont les communications légitimes sont documentées produit un profil réseau stable, et toute déviation devient visible. Une DMZ sans supervision n'offre qu'une protection passive, qui retarde l'attaquant sans prévenir personne de sa présence.

Les scénarios réels montrent l'importance de ce suivi. Notre analyse sur les pare-feu compromis utilisés comme accès initial avant un rançongiciel montre comment une appliance de bordure détournée peut ouvrir la voie à un rançongiciel. Entre l'intrusion initiale et le chiffrement, une alerte sur des flux anormaux constitue souvent la meilleure occasion d'intervenir.

Erreurs fréquentes et checklist d'audit d'une DMZ

Les audits d'architecture révèlent régulièrement les mêmes défauts. Le plus courant est la règle trop large ajoutée en urgence, par exemple « DMZ vers LAN, tous ports », pour débloquer une application et jamais retirée. Viennent ensuite les serveurs de la DMZ joints au domaine interne, les interfaces d'administration exposées sur le WAN et les sorties Internet totalement ouvertes depuis la zone démilitarisée.

Une autre erreur consiste à confondre traduction d'adresses et filtrage. Une redirection de port publiée sur une box ou un routeur expose un service, mais ne crée pas de zone isolée : le serveur visé reste sur le réseau interne. De même, un serveur placé en DMZ avec un accès complet au réseau interne annule tout le bénéfice de l'architecture, puisqu'un attaquant y trouve un tremplin direct.

Voici une checklist d'audit utilisable lors d'une revue annuelle :

• la matrice de flux existe, est à jour et chaque règle du pare-feu y correspond ;
• aucune règle ne permet une connexion initiée depuis la DMZ vers l'interne sans justification écrite ;
• les sorties Internet depuis la DMZ sont limitées à des destinations identifiées ;
• les serveurs exposés ne sont pas membres du domaine de production ;
• l'administration passe exclusivement par un réseau dédié ou un bastion ;
• les journaux du pare-feu et des serveurs sont centralisés et analysés ;
• un scan externe autorisé confirme que seuls les ports publiés sont visibles.

Retour terrain : Cas typique rencontré en mission — les règles DMZ vers LAN les plus fréquentes autorisent un serveur exposé à joindre les contrôleurs de domaine en LDAP, ou une base interne sur une large plage de ports. En test d'intrusion autorisé, compromettre l'application exposée suffit alors pour interroger l'annuaire et rebondir vers l'interne. Je préconise un relais d'authentification en DMZ et des règles limitées à un hôte et un service.

Cas particulier : l'option « DMZ » des box et routeurs grand public

Les box Internet et routeurs domestiques proposent une option appelée « DMZ » ou « hôte DMZ ». Malgré son nom, elle ne crée aucune zone isolée : elle redirige vers un seul équipement du réseau local tout le trafic entrant qui ne correspond à aucune autre règle. Cet appareil se retrouve donc exposé sur tous ses ports, tout en restant sur le même réseau que les autres équipements du foyer ou du petit bureau.

Cette fonction est parfois utilisée pour une console de jeux ou un enregistreur vidéo, mais elle représente un risque élevé. Si l'équipement exposé est compromis, l'attaquant accède directement au réseau local. Une redirection de port ciblée, limitée au strict nécessaire, ou mieux un accès via VPN, est toujours préférable. Pour une petite structure, un véritable pare-feu avec une interface DMZ dédiée apporte une isolation réelle.

À lire aussi : les types de pare-feu informatique.

Questions fréquentes

Conclusion

La DMZ n'est pas un concept dépassé : c'est la traduction réseau d'un principe simple, isoler ce qui est exposé pour contenir les conséquences d'une compromission. Son efficacité tient à quelques règles strictes : aucun flux initié vers l'interne, sorties limitées, administration dédiée, serveurs durcis et journaux centralisés. Les mêmes principes s'appliquent au cloud, sous forme de sous-réseaux publics, et à l'industrie, sous forme de DMZ IT/OT.

Pour passer à la pratique, commencez par inventorier vos services exposés, rédigez la matrice de flux, puis confrontez-la aux règles réellement configurées. Notre guide complet d'installation et de configuration d'OPNsense vous accompagne pour créer l'interface DMZ et ses règles. Gardez enfin à l'esprit que les appliances de bordure elles-mêmes doivent être surveillées et mises à jour en priorité.