DMZ (informatique)

Une DMZ (de l'anglais Demilitarized Zone, zone démilitarisée en français) est un sous-réseau physique ou logique interposé entre un réseau interne privé et un réseau non fiable, généralement Internet. Elle héberge les services devant être accessibles depuis l'extérieur — serveurs web, messagerie, DNS — tout en les isolant du réseau local de l'organisation. En cas de compromission d'un équipement placé en DMZ, l'attaquant ne peut pas directement atteindre le réseau interne, ce qui limite la propagation d'une cyberattaque. La DMZ constitue l'un des dispositifs fondamentaux de la cybersécurité réseau depuis les années 1990.

Origine et terminologie

Le terme demilitarized zone est emprunté au vocabulaire militaire, où il désigne une zone tampon entre deux forces opposées dans laquelle les activités militaires sont interdites ou limitées. En informatique, la notion apparaît dans les années 1990 avec la généralisation des connexions Internet dans les entreprises et la nécessité d'exposer des services publics tout en protégeant les systèmes internes. Le sigle DMZ s'est imposé dans la documentation technique des constructeurs de pare-feux (Cisco, Check Point, Palo Alto Networks) et dans les référentiels de sécurité dès le milieu des années 1990. Le terme screened subnet est parfois utilisé comme synonyme dans la littérature anglo-saxonne.

Architecture

Principe général

Une DMZ repose sur le cloisonnement : elle constitue un troisième segment réseau, distinct du réseau interne (LAN) et d'Internet. Les flux entrants depuis Internet vers les serveurs de la DMZ sont autorisés de façon sélective sur des ports et protocoles précis, tandis que les communications entre la DMZ et le réseau interne sont strictement filtrées. Cette séparation réduit la surface d'attaque en empêchant un hôte compromis en DMZ d'établir librement des connexions vers les ressources internes.

DMZ à pare-feu unique (three-legged firewall)

Dans l'architecture la plus simple, un seul pare-feu possède trois interfaces réseau : une vers Internet, une vers le réseau interne et une vers la DMZ. Cette topologie est économique mais introduit un point de défaillance unique : si le pare-feu est compromis ou mal configuré, l'ensemble du cloisonnement disparaît. Elle reste courante dans les petites et moyennes entreprises à contraintes budgétaires réduites.

DMZ à double pare-feu

L'architecture recommandée pour les environnements sensibles utilise deux pare-feux distincts. Le premier (outer firewall ou border firewall) sépare Internet de la DMZ ; le second (inner firewall) sépare la DMZ du réseau interne. Idéalement, les deux équipements proviennent de constructeurs différents, de sorte qu'une vulnérabilité logicielle propre à l'un n'affecte pas l'autre. Cette topologie est préconisée par la norme ISO/IEC 27001 et par les guides techniques de l'ANSSI (Agence nationale de la sécurité des systèmes d'information).

DMZ multiples

Les organisations de grande taille peuvent déployer plusieurs DMZ fonctionnellement séparées : une DMZ publique pour les serveurs web et DNS, une DMZ partenaire pour les échanges B2B via des protocoles applicatifs métier, une DMZ de gestion pour les équipements d'administration réseau. Ce modèle s'appuie fréquemment sur des réseaux locaux virtuels (VLAN) pour segmenter les sous-réseaux sans multiplier le matériel physique.

Composants typiques

Les équipements hébergés en DMZ sont ceux qui nécessitent une accessibilité depuis l'extérieur tout en devant rester isolés du réseau interne :

• Serveurs web et applicatifs : sites publics, portails clients, API REST exposées sur les ports HTTP (80) et HTTPS (443).
• Serveurs de messagerie (MTA) : les agents de transfert de courrier (Mail Transfer Agent) reçoivent le courrier entrant sur le port 25 (SMTP). Le relais vers les serveurs de messagerie internes s'effectue ensuite depuis la DMZ vers le LAN.
• Serveurs DNS publics : résolution des noms de domaine de l'organisation pour les requêtes provenant d'Internet (port 53 UDP/TCP). Le serveur DNS interne (split DNS) reste distinct et non accessible depuis l'extérieur.
• Serveurs mandataires inverses (reverse proxies) : intermédiaires qui reçoivent les requêtes clients et les retransmettent vers les serveurs applicatifs en interne, masquant la topologie réelle du réseau.
• Hôtes bastions : points d'entrée sécurisés pour l'administration à distance (SSH sur port 22, RDP sur port 3389), configurés avec un durcissement système renforcé et soumis à une journalisation exhaustive.
• Serveurs FTP/SFTP : transferts de fichiers avec des partenaires ou des clients externes, sur les ports 21 (FTP) ou 22 (SFTP).

Règles de filtrage et flux autorisés

Le filtrage en DMZ s'articule autour de trois axes de trafic :

1. Internet → DMZ : flux entrants autorisés uniquement sur les ports et protocoles nécessaires aux services exposés (443, 25, 53, etc.). Toute connexion non explicitement listée est bloquée par défaut (règle deny all).
2. DMZ → Internet : flux sortants strictement limités. Les serveurs de la DMZ n'ont généralement pas besoin d'initier des connexions vers Internet ; les autoriser ouvre un canal de communication exploitable par des logiciels malveillants pour des communications de commande et contrôle (C2).
3. DMZ → Réseau interne : flux restreints aux communications strictement nécessaires — par exemple, le serveur web en DMZ interroge une base de données en interne sur le port 5432 (PostgreSQL) ou 3306 (MySQL). Toute connexion non explicitement requise est bloquée.

Le principe du moindre privilège s'applique à chaque règle : seuls les ports, protocoles et adresses sources/destinations indispensables sont autorisés.

Relations avec d'autres architectures de sécurité

VPN et accès distant

Un réseau privé virtuel (VPN) complète la DMZ pour les accès des collaborateurs en mobilité. Les concentrateurs VPN sont fréquemment placés en DMZ : ils terminent les tunnels chiffrés depuis Internet et n'établissent vers le réseau interne que les flux de données métier validés. L'authentification multifacteur est systématiquement recommandée sur les points d'entrée VPN hébergés en DMZ afin de contrecarrer les attaques par credential stuffing.

Infrastructure TLS et gestion des identités

Les certificats numériques utilisés par les serveurs de la DMZ s'inscrivent dans une infrastructure à clés publiques (PKI). Le protocole TLS chiffre les communications entre les clients Internet et les serveurs exposés, garantissant la confidentialité et l'intégrité des échanges. La gestion des comptes de service et des accès aux ressources internes depuis la DMZ relève de la gestion des identités et des accès (IAM).

SIEM, SOC et supervision

Les équipements de la DMZ génèrent des journaux (logs) de connexion riches en signaux de détection : tentatives de connexion sur des ports fermés, scans de ports, requêtes malformées. Ces journaux sont collectés et analysés par un SIEM (Security Information and Event Management), qui corrèle les événements pour détecter les tentatives d'intrusion et les comportements anormaux. Le SOC exploite ces alertes pour déclencher une réponse aux incidents en temps réel.

Zero Trust et évolution du modèle DMZ

Le modèle Zero Trust remet en question la frontière réseau traditionnelle sur laquelle repose la DMZ. Dans cette approche, aucun réseau n'est considéré fiable par nature — y compris le réseau interne — et chaque accès est conditionné à une vérification d'identité et de contexte. Le Zero Trust Network Access (ZTNA) et la microsegmentation permettent de contrôler les flux à la granularité de l'application ou de la charge de travail, réduisant la pertinence d'une DMZ unique comme seule ligne de défense. Toutefois, la DMZ reste pertinente dans les architectures hybrides et dans les environnements où la migration vers Zero Trust est partielle ou en cours.

DMZ dans les environnements cloud et hybrides

L'adoption du cloud computing a modifié les modalités de déploiement des DMZ. Dans un modèle IaaS (Infrastructure as a Service), la DMZ est reproduite sous forme de sous-réseaux dédiés et de groupes de sécurité réseau. Les principaux fournisseurs de cloud public (AWS, Azure, GCP) proposent des concepts équivalents : sous-réseaux publics et privés, listes de contrôle d'accès réseau (ACL), groupes de sécurité à état (stateful security groups). Dans un environnement hybride (on-premises + cloud), la DMZ peut être étendue via des liaisons dédiées (AWS Direct Connect, Azure ExpressRoute) ou via un VPN site-à-site.

La conteneurisation (Docker, Kubernetes) introduit des mécanismes analogues : les charges de travail exposées vers Internet sont isolées dans des espaces de noms (namespaces) dédiés, et les politiques réseau Kubernetes (NetworkPolicy) jouent un rôle fonctionnellement proche des règles de filtrage de la DMZ classique.

Audit et conformité

La mise en place et le maintien d'une DMZ correctement configurée constituent une exigence ou une bonne pratique dans plusieurs référentiels :

• ISO/IEC 27001 : l'annexe A, contrôle A.13.1.3, impose la séparation des réseaux et recommande des zones de cloisonnement pour les services exposés vers des réseaux non fiables.
• Directive NIS2 : l'article 21 impose des mesures de sécurité des réseaux et des systèmes d'information, dont la segmentation, pour les entités essentielles et importantes relevant du périmètre de la directive.
• PCI DSS (Payment Card Industry Data Security Standard) version 4.0 : l'exigence 1.3 impose l'isolation des systèmes de la zone de paiement du réseau public, notamment via une DMZ documentée et auditée annuellement.
• Conformité RGPD : la protection des données à caractère personnel implique des mesures techniques adaptées au sens de l'article 32 du règlement ; une DMZ correctement configurée contribue à démontrer la mise en œuvre de ces mesures.

Les tests d'intrusion et les audits de cybersécurité intègrent systématiquement l'évaluation de la DMZ : vérification des règles de filtrage, recherche de vulnérabilités sur les services exposés, test de l'isolation DMZ-LAN. Les équipes red team cherchent notamment à pivoter depuis un hôte compromis en DMZ vers le réseau interne, ce qui constitue le scénario d'attaque de référence pour valider l'efficacité du cloisonnement.

Avantages et limites

Avantages	Limites
Cloisonnement des services exposés vis-à-vis du réseau interne	Ne protège pas contre les attaques applicatives sur les services hébergés en DMZ
Réduction de la surface d'attaque accessible depuis Internet	Complexité de configuration et risque de règles trop permissives
Confinement en cas de compromission d'un serveur exposé	Point de défaillance unique dans l'architecture à pare-feu unique
Facilite la conformité aux référentiels (ISO 27001, PCI DSS, NIS2)	Efficacité réduite face aux menaces internes et aux mouvements latéraux
Supervision centralisée des flux entrants et sortants	Inadaptée seule à un modèle cloud-native ou Zero Trust pur

Voir aussi

• Pare-feu
• Réseau informatique
• VPN (réseau privé virtuel)
• Modèle Zero Trust
• Zero Trust Network Access
• Microsegmentation réseau
• SIEM (informatique)
• SOC (Security Operations Center)
• Test d'intrusion
• Audit de cybersécurité
• ISO/IEC 27001
• Directive NIS2
• Cybersécurité
• Infrastructure à clés publiques
• Protocole TLS