La DMZ arrive sans définition attachée. Une ligne dans une checklist de revue de sécurité, une phrase dans le document de durcissement d'un fournisseur, une exigence dans une offre d'emploi posée à côté de TLS et du moindre privilège.
Vous cherchez et vous tombez sur le schéma d'un pare-feu avec trois câbles réseau. L'un part vers internet, un autre vers une rangée de serveurs, le troisième vers un LAN de bureau. Ce que vous administrez, c'est un seul serveur loué avec une seule IP publique et aucune interface réseau de rechange.
La première image est une véritable architecture DMZ. Sur un seul serveur, vous pouvez reproduire une partie de son objectif de sécurité : limiter ce qu'internet peut atteindre. Ce que vous ne pouvez pas reproduire sur cet hôte, c'est la frontière réseau distincte qui fait qu'une DMZ est une DMZ.
La version courte
- Une DMZ sépare les services que des inconnus doivent atteindre du reste de ce que vous faites tourner.
- Le sujet n'a jamais été le câblage : il s'agissait de faire en sorte qu'une compromission du côté public s'arrête là.
- Vous pouvez configurer un pare-feu sans pour autant avoir une DMZ.
- Un serveur unique avec une seule IP publique peut réduire l'exposition à l'aide d'un reverse proxy, de règles de pare-feu locales et d'écoutes privées ou sur la boucle locale, mais il ne crée pas pour autant un segment DMZ distinct.
- Cette version partage un noyau avec ce qu'elle protège : comptez-la comme une exposition réduite, pas comme une isolation.
Ce que cet article n'aborde pas
Le périmètre ici est le modèle mental, et trois sujets voisins sont délibérément laissés de côté.
- Pas de mode opératoire. Il n'y a ni configuration de reverse proxy, ni syntaxe de règles de pare-feu, ni recommandation sur l'outil à installer.
- Pas de configuration de box grand public. L'option « DMZ host » d'un routeur domestique désigne tout autre chose.
- Pas de verdict sur le zero trust. Savoir si le périmètre réseau reste le bon contrôle principal est un vrai débat, et il n'est pas tranché ici.
Qu'est-ce qu'une DMZ, et à quoi sert-elle ?
Une DMZ, ou zone démilitarisée, est un segment de réseau situé entre l'internet non fiable et un réseau interne. Elle héberge les services qui doivent être joignables publiquement, comme les serveurs web et les serveurs de messagerie. Tout le reste demeure derrière une seconde frontière, si bien qu'atteindre le service public ne revient pas à atteindre le reste.
L'entrée du glossaire de Mozilla consacrée à la DMZ en résume la moitié opérante en une seule proposition : elle n'expose que certains points d'accès définis, tout en refusant l'accès au réseau interne depuis l'extérieur. C'est là tout l'objectif de conception, énoncé sans référence à un quelconque équipement.
Les types de services qui y résident classiquement découlent de cet objectif. Serveurs web, serveurs de messagerie, serveurs FTP, serveurs VoIP : des choses auxquelles des inconnus sont censés pouvoir se connecter. Les annuaires, les bases de données, les partages de fichiers, les applications internes et les interfaces d'administration ne figurent pas sur cette liste, parce que personne de l'extérieur n'est censé les atteindre.
Retenez la propriété plutôt que l'image. Trois interfaces réseau sont une manière de créer une frontière de confiance distincte. Les conceptions cloud et mono-serveur peuvent appliquer le même principe de contrôle de l'exposition autrement, mais seules celles dotées d'une zone périmétrique distincte reproduisent la DMZ elle-même.
Comment fonctionne la DMZ classique à trois interfaces ?
La DMZ classique se construit de deux façons. Une conception à pare-feu unique dote un seul pare-feu de trois interfaces, une vers internet, une vers la DMZ, une vers le réseau interne. Une conception à double pare-feu place la DMZ entre deux pare-feux distincts. Les deux appliquent la même règle. Internet atteint la DMZ. Internet n'atteint jamais le réseau interne.
Le modèle à pare-feu unique (trois pattes)
Un pare-feu, trois interfaces réseau. La première fait face à internet. La deuxième fait face à la DMZ, où vivent les services publics. La troisième fait face au réseau interne. Le pare-feu autorise le trafic entrant depuis internet vers des ports précis de la DMZ, autorise un trafic étroit de la DMZ vers l'interne quand une application l'exige, et refuse tout le reste.
Le nom de cette forme est le pare-feu à trois pattes. Chaque paquet qui traverse les zones passe par un seul appareil, ce qui fait de ce pare-feu un point de défaillance unique pour le trafic inter-zones. S'il tombe, la connectivité et l'application des politiques sont affectées selon le mode de défaillance du pare-feu et la redondance que vous avez mise en place.
J'ai passé une décennie à faire tourner les opérations réseau d'un FAI, et ce qui surprenait les gens à propos d'une interface DMZ, c'était à quel point elle n'avait rien de remarquable. Un port ethernet ordinaire, avec une étiquette de confiance différente attachée dans la configuration du pare-feu. L'architecture n'était pas dans le cuivre. Elle était dans le jeu de règles, et dans le fait que quelqu'un avait réfléchi soigneusement à la direction autorisée pour chaque flux.
Le modèle à double pare-feu (dos à dos)
Deux pare-feux en série, avec la DMZ entre les deux. Le pare-feu externe laisse passer le trafic internet vers la DMZ et rien au-delà. Le pare-feu interne n'autorise que le trafic précis dont une application a besoin, de la DMZ vers l'interne. Un attaquant qui atteint la DMZ doit encore franchir la frontière de politique du pare-feu interne avant d'atteindre le réseau interne.
Deux pare-feux vous donnent deux frontières de politique appliquées séparément, mais ils ajoutent aussi de la configuration, des correctifs et de la complexité opérationnelle. Une panne ou une compromission de la frontière externe ne supprime pas automatiquement l'interne, même si la protection dépend encore de la façon dont les deux pare-feux sont configurés et gérés.
Une DMZ, est-ce la même chose qu'un pare-feu ?
Non. Une DMZ est un réseau périmétrique ou un segment de réseau distinct. Un pare-feu est un dispositif de contrôle courant, utilisé pour réguler le trafic entre cette zone, internet et le réseau interne. Vous pouvez configurer des règles de pare-feu sur un réseau à plat sans créer de DMZ : la distinction est donc architecturale, et pas seulement affaire de configuration.
La confusion se comprend. Le pare-feu est l'objet auquel on se connecte, la chose qui a un fichier de configuration, un fournisseur et un contrat de support : il récolte donc le nom de ce qu'il produit. Personne ne se connecte jamais à un segment.
La conséquence se manifeste au pire moment possible. Supposez que votre serveur web public soit compromis, car il finira par l'être. Sur un réseau à plat, l'attaquant dispose désormais d'un point d'appui sur une machine qui peut déjà parler à votre base de données, à votre serveur de fichiers et à vos interfaces d'administration, et se déplacer entre elles revient simplement à utiliser un accès déjà autorisé. Ce déplacement latéral s'appelle le mouvement latéral, et c'est exactement ce que la seconde frontière existe pour arrêter. La DMZ n'empêche pas le serveur web d'être compromis. Elle empêche un serveur web compromis de devenir un accès à tout le reste.
Une précision, tant que le terme est sous les yeux : le réglage « DMZ host » d'un routeur domestique ou de petite entreprise est une autre fonctionnalité. Il redirige le trafic entrant non sollicité vers un seul appareil interne, exposant cet appareil directement à internet ; il ne crée pas un réseau DMZ distinct et protégé.
Comment appliquer les principes de la DMZ sur un seul serveur ?
Un serveur unique doté d'une seule IP publique peut reproduire une partie de l'objectif de contrôle de l'exposition d'une DMZ, sans en reproduire la séparation réseau. Un reverse proxy peut devenir le seul point d'entrée public, des règles de pare-feu entrantes en refus par défaut peuvent bloquer le reste, et les services internes peuvent écouter sur la boucle locale ou sur une interface privée plutôt que sur l'adresse publique.
Commencez par la contrainte que cette section suppose : un VPS, une interface publique, et aucun boîtier pare-feu séparé ni sous-réseau DMZ sous votre contrôle. Dans ce montage, vous ne pouvez pas reproduire la topologie classique à trois pattes sur le même hôte. Les règles de pare-feu locales, le choix d'écoute des services et un reverse proxy peuvent encore réduire l'exposition, mais ils ne créent pas la même frontière d'isolation.
Un reverse proxy peut occuper l'interface publique sur les ports 80 et 443 et devenir le seul point d'entrée applicatif pour le trafic web. Cela réduit la surface d'attaque publique, mais ce n'est pas l'équivalent d'une interface DMZ distincte, car le proxy partage toujours l'hôte avec les services situés derrière lui.
Les règles de pare-feu entrantes de l'hôte autorisent ces deux ports et rejettent le reste. Tous les autres services de la machine peuvent tourner et écouter, mais rien depuis l'extérieur ne peut initier une connexion vers eux. Cela approche la politique « seuls les ports voulus sont joignables » sur un seul hôte ; cela ne crée pas de frontière séparée avec le réseau interne.
Les serveurs applicatifs, les bases de données et les panneaux d'administration ne devraient pas écouter sur l'adresse publique. Quand le proxy tourne sur le même hôte, ils peuvent écouter sur la boucle locale ; quand il tourne ailleurs sur le réseau privé, ils peuvent écouter sur une adresse privée. Dans les deux cas, aucun processus n'écoute pour ces services sur l'interface publique, si bien qu'ouvrir une règle entrante sur cette seule interface ne les expose pas.
L'accès d'administration appartient au côté interne, pas au côté DMZ. Garder SSH et les interfaces de gestion hors du chemin public, derrière un VPN ou un réseau privé, empêche toute connexion directe vers eux depuis l'internet public.
Comment les concepts de DMZ se transposent-ils sur les sous-réseaux VPC et les groupes de sécurité ?
Le modèle classique se transpose assez fidèlement sur les primitives réseau du cloud, mais la correspondance n'est pas exacte. Un segment DMZ devient un sous-réseau public. Le réseau interne devient un sous-réseau privé sans route vers une passerelle internet. Le jeu de règles du pare-feu se répartit entre les groupes de sécurité, associés aux interfaces réseau des ressources, et les listes de contrôle d'accès réseau, attachées aux sous-réseaux.
| Élément classique | Équivalent cloud | Ce qu'il applique |
|---|---|---|
| Segment DMZ | Sous-réseau public | Fournit une route vers internet ; une ressource a aussi besoin d'une adresse publique et de règles de sécurité qui autorisent le trafic |
| Segment de réseau interne | Sous-réseau privé | Pas de route directe vers la passerelle internet, si bien qu'internet ne peut pas initier de connexions directes par ce chemin |
| Interface de pare-feu entre zones | Table de routage + rattachement à une passerelle internet | Où le trafic peut être routé ; l'adressage public et les contrôles de sécurité déterminent encore si une ressource est joignable |
| Jeu de règles de pare-feu (par zone) | Listes de contrôle d'accès réseau | Règles d'autorisation et de refus sans état, évaluées en bordure du sous-réseau |
| Jeu de règles de pare-feu (par hôte) | Groupes de sécurité | Règles d'autorisation à état, appliquées aux interfaces réseau des ressources associées |
| Service exposé au public dans la DMZ | Répartiteur de charge ou instance proxy dans le sous-réseau public | Le point d'entrée unique par lequel le trafic doit passer |
Les fournisseurs cloud emploient eux-mêmes ce vocabulaire, ce qui prouve assez bien que le terme reste d'actualité. Le blog réseau d'AWS décrit une architecture DMZ sur Amazon VPC qui isole les services exposés au public des réseaux internes, bâtie sur VPC Block Public Access, un contrôle au niveau de la Région lancé en novembre 2024.
Les sous-réseaux sont la partie porteuse de cette transposition. Un sous-réseau public est public parce que sa table de routage pointe vers une passerelle internet. Comme les tables de routage décident où voyagent les paquets, la disposition des sous-réseaux façonne votre exposition avant toute règle individuelle.
La transposition est imparfaite sur un point précis. Une interface de pare-feu appliquait une frontière pour tout un segment ; un groupe de sécurité, lui, est associé à l'interface réseau d'une ressource. Deux machines d'un même sous-réseau privé peuvent porter des groupes de sécurité complètement différents, si bien que l'application des règles se joue à une granularité plus fine qu'une interface physique n'y est jamais parvenue. C'est en général un progrès. Cela signifie aussi que le nom d'un sous-réseau vous en dit moins sur ce qui est joignable qu'un schéma réseau ne le faisait autrefois.
Là où la version mono-serveur montre ses limites
Sur un seul hôte, le processus exposé au public et les services internes partagent un noyau et une machine. Des segments distincts obligent un attaquant à franchir une frontière réseau qu'un pare-feu inspecte ; un hôte unique, non. Le schéma mono-serveur réduit l'exposition. Il ne reproduit pas la séparation.
Si le reverse proxy est compromis d'une manière qui donne à l'attaquant l'exécution de code, ce code tourne déjà sur la machine où tourne votre base de données. L'écoute sur la boucle locale n'aide en rien à ce moment-là, puisque la boucle locale est joignable depuis l'hôte. L'isolation par conteneurs ou par utilisateurs peut relever l'effort nécessaire, mais des conteneurs sur le même hôte partagent toujours le noyau de cet hôte. Dans le modèle classique, l'étape suivante de l'attaquant était un paquet sur un câble que quelque chose inspectait. Ici, c'est une socket locale.
La conséquence pratique est un seuil, pas un verdict. Quand ce qui se trouve derrière le proxy vaut plus que l'effort d'une seconde machine, prenez une seconde machine et un réseau privé entre les deux. Rien dans cet article n'est à réapprendre pour cela, car rien de tout cela n'a jamais porté sur le matériel.
Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.
Voir les plans LinuxLe périmètre n'est plus le seul endroit où une politique de sécurité peut s'appliquer. L'architecture zero trust supprime la confiance implicite fondée sur l'emplacement réseau, tandis qu'une connectivité privée bâtie avec WireGuard ou Tailscale peut réduire l'exposition publique. Aucune de ces approches ne remplace automatiquement la segmentation ou l'autorisation. Ma position sur la question la plus étroite est nette. Comme modèle mental, triez ce qui est joignable et ce qui ne l'est pas, et sachez quelle frontière contient une compromission. Cette question survit à toutes les architectures citées plus haut, et c'est pourquoi elle mérite encore une réponse.
Foire aux questions
Une DMZ, est-ce la même chose qu'un VPN ?
Non. Ils résolvent des problèmes différents. Une DMZ contrôle ce que des inconnus non fiables peuvent atteindre, en exposant un petit ensemble de services et rien d'autre. Un VPN donne à des personnes de confiance venues de l'extérieur un chemin privé vers l'intérieur, en les authentifiant sur un réseau qu'elles n'atteindraient pas autrement. Beaucoup de réseaux font tourner les deux, et aucun ne remplace l'autre.
Une DMZ est-elle sûre ?
Une DMZ ne rend pas sûr un service exposé. Elle limite ce qu'atteint la compromission de ce service. Le service exposé au public reste exposé au public, reste offert à tout internet, et a toujours besoin de correctifs, de supervision et de durcissement pour son propre compte. La DMZ décide de ce qui se passe après sa chute, pas de savoir s'il tombera.
Ai-je besoin d'une DMZ si je n'ai qu'un seul serveur ?
Pas au sens classique, et de toute façon vous ne pourriez pas en construire une sur un hôte unique. La topologie à trois interfaces exige des segments réseau distincts, et un serveur avec une seule IP publique n'en a aucun. Ce que vous pouvez faire, c'est contrôler l'exposition : faire d'un reverse proxy le seul point d'entrée public, refuser par défaut le reste des ports entrants, et faire écouter les services internes sur la boucle locale ou une adresse privée. Cela réduit ce qu'internet peut atteindre, sans isoler le service public du reste de l'hôte. Quand ce qui se trouve derrière le proxy vaut plus que le coût d'une seconde machine, prenez deux machines et un réseau privé entre elles.
Pourquoi appelle-t-on cela une zone démilitarisée ?
Le terme est emprunté au sens militaire d'une zone tampon entre deux forces opposées, où ni l'une ni l'autre n'exerce un contrôle complet. L'usage réseau conserve la métaphore : la DMZ n'appartient entièrement ni à l'extérieur non fiable, ni à l'intérieur de confiance.
Discussion
Commentaires
Connectez-vous pour participer à la discussion.