DMZ隔离区从概念到落地：拓扑选型、策略配置与排坑指南

前阵子帮一位做跨境电商的朋友看他新机房的拓扑草图，图上把订单服务、数据库、对外的接口网关全画在同一个网段里，我随口问了句“DMZ 放哪了”，他愣了两秒反问：“DMZ 是防火墙的一个开关吗？”这个反应其实相当典型。DMZ（隔离区，Demilitarized Zone）这个词在招聘要求、方案评审、等级保护测评里出现的频率高得离谱，但真正能把它的边界划分、策略方向、以及它到底防住了什么讲明白的人并不多。大多数人记住的是一句口诀——“对外提供服务的机器放 DMZ”，可真到了画网段、配策略、排查故障的时候，这句话几乎帮不上忙。这篇内容我想把 DMZ 从概念到落地完整拆一遍：它是什么、为什么长成那个样子、单防火墙和双防火墙怎么选、配置时哪些策略方向最容易写反、以及我自己在真实环境里踩过的几个坑。适合刚接触网络安全的运维、正在做机房改造的工程师，也适合只想知道“这东西值不值得做”的技术负责人。

1. DMZ 到底指什么：从名字到它真实所处的网络位置

1.1 一句话定位：它是内网和公网之间那块“可以被打碎”的地

先把定义摆清楚。DMZ 是夹在不可信网络（通常是互联网）和可信网络（企业内网、生产核心区）之间的一段独立网段，里面跑的是那些必须被外部访问、但又不该拥有内网完整权限的系统。典型住户包括：对外 Web 站点、反向代理、API 网关、邮件收发网关、对外 DNS、文件交换服务器、以及某些场景下的跳板/运维代理前端。

这个定义里有两个关键词特别重要：必须被外部访问和不该拥有内网完整权限。前者决定了它不能放在内网深处，否则外部进不来；后者决定了它不能和内网平起平坐，否则一旦被攻破，攻击者就顺着网线摸到核心数据库了。DMZ 存在的全部意义，就是把这两个互相矛盾的需求用一段物理或逻辑上的隔离带调和掉。

我习惯用一个类比来解释：DMZ 好比公司前台的接待室。访客可以进接待室，接待室里有沙发、有登记表、有宣传册，但访客不能从接待室直接推开那扇通往办公区的门。接待室被砸了，损失的是几件家具；办公区被砸了，损失的是全部业务数据。DMZ 就是那间接待室，而且是我特意设计成“砸了也不太心疼”的接待室。

1.2 名字借自军事术语，但网络里的“非军事区”边界更硬

DMZ 这个词本身借自军事领域里“缓冲地带”的概念，指双方约定不驻扎武装力量的中间区域。网络世界借用了这个意象，但落地的边界比隐喻要硬得多——军事缓冲带靠的是双方默契，网络隔离区靠的是防火墙上的策略，是配置层面的强制约束，没有默契可言。

这里有个很多人会混淆的点：DMZ 不是一个产品，也不是防火墙的一个功能按钮。你在某品牌防火墙的管理界面上看到的“DMZ 口”，本质上是把一个物理接口划到了一个安全级别较低的区域，真正的隔离效果来自你在这三个区域之间写的策略规则。换句话说，把网线插到标着 DMZ 的接口上，什么都不会自动发生；如果策略写的是 any-any 全通，那这个 DMZ 就是个摆设，甚至比不放 DMZ 更危险，因为它会给你一种虚假的安全感。

我在评审方案时见过不止一次这种情况：拓扑图画得很漂亮，三个区域清清楚楚，一问策略，对方说“先全通跑起来，后面再收”。这个“后面”通常就是永远。安全边界这种东西，一旦以全通状态上线，后续收窄的阻力会大得惊人——业务方会说“之前一直能通”，运维会说“动了怕出问题”，最后就烂在那里了。

1.3 三个区域、两个边界：把访问关系想清楚比记口诀有用

与其死记“对外服务放 DMZ”，不如把访问关系画成一张关系表。任何一套 DMZ 设计，实质上都是在回答下面这张表里每一格“通还是不通、通什么端口、从哪个源到哪个目的”：

这张表的核心是每一格默认都是拒绝。我见过太多环境把注意力全放在第一行（公网到 DMZ），把下面四行全放通，结果 DMZ 成了一台“带公网 IP 的内网机器”——攻击者拿下它之后，往内网的操作和一台内网机器没有任何区别，DMZ 白白建了。

真正难的不是理解这张表，而是在业务压力下坚持这张表。业务方经常提“我们的应用服务器要连内网 Redis”“要连内网的统一认证服务”，每一条都合理，每一条都在侵蚀隔离。我的处理办法是逐条评估：能改成由内网主动拉取的，就改成拉取；必须由 DMZ 主动发起的，收敛到单个 IP 加单个端口，并且单独记一条台账。妥协可以有，但必须是有记录、可审计的妥协。

2. 把对外服务直接丢进内网，究竟会付出什么代价

2.1 一条完整的失守链路推演，比任何理论都有说服力

假设某公司把官网、会员系统和内部 ERP 都放在 10.0.0.0/24 这个网段里，没有划分 DMZ。某天官网使用的某个开源组件爆出远程代码执行漏洞。接下来会发生什么，我把这条链路一步步写出来：

第一步，攻击者通过漏洞在官网服务器上拿到一个低权限 shell。这一步在公网侧看起来只是一次普通的 HTTP 请求，防火墙如果只做端口放行，完全看不出异常。

第二步，攻击者在机器上执行ifconfig或ip a，看到本机 IP 是 10.0.0.15，顺手扫一下同网段：nmap -sn 10.0.0.0/24。因为没有任何东西拦着他，同网段的 ERP、数据库、内部管理系统全部在扫描结果里亮起来。

第三步，他挑一台看起来最脆弱的横向过去。同网段互访不经过任何策略检查，很多时候连一台主机的 22 端口都没做限制，弱口令一撞就进去了。

第四步，数据被打包外传，整个过程可能只用了四十分钟。

如果同样的场景有 DMZ，链路会在第二步就被掐断：官网在 DMZ 的 172.16.10.0/24 里，扫同网段只能看到 DMZ 里的几台同类机器；尝试往 10.0.0.0/24 发起连接时，防火墙策略直接丢弃，连 RST 都不一定回。攻击者要多花的时间成本，可能就是从“四十分钟”变成“几天且大概率失败”。

这两者的差别，不在于官网有没有被打穿——官网大概率还是会被打穿——而在于打穿之后能走多远。这是理解 DMZ 价值的关键视角转换。

2.2 攻击面账本：哪些资产天然必须暴露，哪些纯属自找

做隔离之前，先把自己的暴露面盘清楚。我在实际项目里会让团队列一张“外部可达资产清单”，每一行必须回答三个问题：谁需要访问它、访问什么端口、如果它被打穿最坏结果是什么。

盘点时经常能发现一些“其实根本不需要暴露”的东西：测试环境的调试端口、某些后台管理界面的 8080、监控系统的 Web 面板、数据库的管理端口。这些东西被暴露的原因往往很朴素——当初图方便，把防火墙策略加宽了一点点，然后就忘了。每关掉一个这样的端口，你的 DMZ 就少一个需要防守的门。

注意：盘点暴露面的时候，不要只查防火墙的策略表，还要查云上的安全组、负载均衡的监听器、CDN 的回源配置、以及 NAT 映射表。这四处的策略经常是不同的人在不同时间配的，彼此不知道对方存在，实际暴露的端口往往比防火墙台账上多得多。

盘完之后你会发现，真正必须暴露在公网的资产数量通常比想象中少得多。一个中等规模的业务系统，对外真正需要开放的往往就是 80/443 加上少量特定协议的端口。剩下的资产全部应该待在 DMZ 之后甚至内网深处。

2.3 DMZ 真正挡住的不是“入侵”，而是“入侵之后的自由活动”

这一点值得单独拎出来讲，因为它是很多方案文档里没写清楚的地方。防火墙、WAF、入侵检测这些东西，防的是“进门”；DMZ 防的是“进门之后在屋里乱窜”。

从攻防的实际统计来看，没有任何一种边界设备能保证百分之百拦截。组件漏洞、配置错误、弱口令、供应链投毒，任何一条路都可能被走通。假设入侵一定会发生，那么设计目标就应该从“阻止入侵”调整为“让入侵的收益尽可能小、被发现的时间尽可能早”。DMZ 正好服务于这两个目标：

• 收益变小：DMZ 里没有核心数据。一台对外 Web 服务器上最多有一些缓存和会话，拿下了也榨不出多少东西。
• 发现变早：DMZ 的流量模式非常单一，就是外部到 Web 的 HTTP(S)。任何往内网的连接尝试、任何异常的出站连接，在这种单一基线下一眼就能看出来。反过来，一个几百台机器混在一起的大内网，异常流量很容易被淹没在正常的业务流量里。

所以我在给非技术管理者解释 DMZ 时，用的说法是：它不是门锁，它是把贵重物品从门厅搬进了保险柜，同时在门厅装了一个只能走正门的通道。

3. 单防火墙、双防火墙、云上方案：三种主流拓扑怎么取舍

3.1 单防火墙三接口方案：性价比最高，也最容易配出漏洞

最常见、成本最低的做法，是一台防火墙至少划出三个接口：一个接公网（Untrusted）、一个接 DMZ、一个接内网（Trusted）。三个接口分属三个安全区域，策略在区域之间写。有些设备还会额外划一个管理口，专门跑带外管理流量。

这套方案的优点很直接：一台设备、一套策略、一份日志，维护成本低，中小规模环境完全够用。缺点也很明确——它把所有信任判断压在了同一台设备上。这台设备如果被绕过（比如通过管理面漏洞、或者策略配置失误），三个区域之间的隔离同时失效。而且单台设备的性能是共享的，公网侧被流量攻击打满的时候，DMZ 和内网之间的策略处理也会受影响。

配置这类方案时，最容易出问题的地方是接口的信任级别和策略方向的对应关系。不同厂商的设备对“从高安全级别到低安全级别”和“从低到高”的默认行为定义不一样，有些默认允许高到低，有些默认全拒。我建议不管设备默认行为是什么，都显式把两个方向的默认策略写成拒绝，然后再逐条放行，不要依赖设备的默认值。依赖默认值这件事，在你换设备、换固件版本、或者被别人接手维护的时候，会变成一颗定时炸弹。

3.2 双防火墙背靠背方案：中间那段“夹层”到底换来了什么

对安全要求更高的环境会用两台防火墙串起来：外网防火墙接互联网和 DMZ，内网防火墙接 DMZ 和内网。DMZ 就夹在中间，成了一个真正意义上的“夹层”。任何从公网到内网的流量，必须依次穿过两台设备的两套独立策略。

这套方案的收益主要有三块。第一，异构性：两台设备可以是不同厂商、不同型号，一套设备的零日漏洞很难同时打穿两套。第二，策略职责分离：外网防火墙只管“谁能进来”，内网防火墙只管“谁能往核心区走”，两拨人可以分开维护，出问题时定位范围更小。第三，性能隔离：公网侧的流量压力不会直接传导到内网侧。

代价也很实在：成本翻倍、策略要维护两套、故障点变多、排障链路变长。我见过一些团队上了双防火墙，但因为人手不足，内网防火墙的策略长期没维护，最后退化成全通，反而多了一层“看起来有防护”的假象。所以选这套方案之前，先问自己一句：有没有人真的会去维护第二套策略？如果没有，老老实实用单台加严格的策略收敛，效果可能更好。

3.3 云环境下 DMZ 的等价物：子网、路由表和安全组的三重组合

上了云之后，“DMZ 口”这种物理概念消失了，但隔离逻辑完全一样，只是换了一套积木：

云上做 DMZ 有一个传统机房没有的优势：路由表可以直接让两个子网不通。在物理网络里，只要网线连着，隔离全靠策略；在云上，你可以让 DMZ 子网的路由表里根本没有指向核心业务子网的路由条目。路由层不通，比策略层拒绝更硬，也更不容易被误配打开。我在云上做隔离时，优先用路由隔离，其次才用安全组，最后才是主机防火墙，从外到内三层叠加。

这里有个容易忽略的细节：安全组是有状态的，你放行了入方向的 443，回程流量会自动放行；但网络 ACL 是无状态的，入方向放行了还得单独放行出方向的临时端口段。这两者搞混，就会出现“策略明明写了却不通”的诡异现象，排查起来非常耗时。

3.4 三套方案的选型对照

把上面的内容压缩成一张表，选型时对着看：

我的实际建议是：先从单防火墙加严格策略起步，把策略收敛的流程跑顺，再考虑加设备。策略管理能力跟不上，设备加得越多，漏洞反而越多。

4. 从零落地一套 DMZ：五个必须按顺序走的步骤

4.1 第一步先定资产清单，网段规划反而是后面的事

很多人的习惯是先画网段、先分 IP，结果配到一半发现“这台机器到底该放哪”说不清楚。正确的顺序是先出资产清单，再根据清单划网段。

清单至少要有这几列：主机名、业务用途、对外暴露端口、需要访问的内网资源（IP+端口）、需要访问的外网资源、负责人。填完之后按“暴露程度”排序，凡是需要被公网访问的，进 DMZ；不需要的，一律进内网。这里有个原则我一直在用：能不放 DMZ 就不放 DMZ。DMZ 不是荣誉勋章，它是一块高风险区域，每多放一台机器，就多一个需要持续打补丁、看日志、做基线加固的对象。

网段规划上，DMZ 要用一个和内网完全不重叠的独立地址段。我见过地址段重叠导致路由混乱的案例：DMZ 用了 192.168.1.0/24，某个远程办公点的内网也是 192.168.1.0/24，两边的机器互相访问时路由直接懵掉，最后靠改地址段才解决。规划时把未来三年的扩容空间留出来，别用 /28 这种刚好够用的掩码。

4.2 第二步接口、路由和基础连通性，先通再谈隔离

接口配置这块没什么花活，但有两个细节容易翻车。一是默认网关的位置：DMZ 里的主机默认网关必须指向防火墙的 DMZ 接口地址，不能指到内网网关上去，否则流量绕开了策略检查，隔离形同虚设。二是非对称路由：如果 DMZ 主机有多块网卡、或者有双上行，很容易出现去程走防火墙、回程走另一条路的情况，表现为“能连上但传输不稳定、大包丢”。遇到这种症状，先查路由对称性，别急着怀疑应用。

下面是一段在 Linux 防火墙上初始化三个区域接口的基础配置，用 nftables 写的，逻辑上等价于任何商业防火墙的区域划分：

# 定义三个区域对应的接口与网段（示例网段，按实际替换） nft add table inet edge nft add chain inet edge forward '{ type filter hook forward priority 0; policy drop; }' # 公网侧 nft add rule inet edge forward iifname "eth0" oifname "eth1" tcp dport { 80, 443 } accept # DMZ 到内网：默认不放行，先留空，后续按需逐条添加 # DMZ 到公网：仅放行时间同步和软件源，其余拒绝 nft add rule inet edge forward iifname "eth1" oifname "eth0" udp dport 123 accept nft add rule inet edge forward iifname "eth1" oifname "eth0" tcp dport { 80, 443 } accept

注意policy drop这一行是整个配置的地基。所有链的默认策略都设成 drop，然后一条条往上加放行规则，加一条测一条。反过来做——默认 accept 然后往下加拒绝——几乎必然会漏。

4.3 第三步策略只写必要方向，源和目的都要精确到 IP

策略这块，我总结了一个“三不写”原则：不写 any 源、不写 any 目的、不写端口段。听起来很苛刻，实际执行下来你会发现大部分业务的真实需求其实很窄，只是提需求的人习惯性说“要能访问”。

举个真实例子。某项目的 DMZ 里有一台对外的 API 服务，需要读内网的一台缓存服务。业务方最初的描述是“要访问内网的缓存”。如果照这个描述配，就是 DMZ 整段 → 内网整段 → 6379 端口放通，这等于把内网所有缓存实例全部暴露给 DMZ。追问之后实际需求是：DMZ 的两台 API 服务器的 IP 地址，访问内网某一台缓存实例的 6379 端口。策略从“段对段”收窄成“两台 IP 对一台 IP 的一个端口”，攻击面缩小了几个数量级。

策略写完一定要双向验证：正向测一遍该通的能通，反向测一遍不该通的不通。反向测试特别容易被跳过，因为大家潜意识里觉得“我没写放行规则，应该就是不通的”。但默认策略、隐式放行、状态跟踪、以及某些设备上“相关连接自动放行”的机制，都可能让本该拒绝的连接通过。测的方法很简单，从 DMZ 主机上telnet或nc一下内网数据库的端口，看是连接超时还是连接被拒——超时通常是被丢弃，被拒说明包到了对端，两种情况含义完全不同。

4.4 第四步发布方式：目的 NAT、反向代理还是双栈，各有各的账

把 DMZ 里的服务发布到公网，常见三种方式：

• 目的 NAT（端口映射）：把公网 IP 的某个端口映射到 DMZ 主机的内网地址。简单直接，但暴露的是真实服务，应用层攻击直接打在业务进程上。
• 反向代理前置：公网只暴露代理，代理再回源到 DMZ 里的业务。可以在代理层做 TLS 卸载、路径过滤、限速、访问日志，攻击面比裸映射小很多。
• 双栈/直接公网地址：DMZ 主机直接持有公网地址，最简单也最危险，主机完全暴露，不建议。

我的默认选择是反向代理前置。理由不只是安全，运维上也更好受：证书统一在代理层管理，业务机器不用各自维护证书；流量统计和访问日志集中在一处；后端扩容时前端不用改。代价是多了一跳，排查问题时多一层要看。

不管选哪种方式，NAT 映射表本身就是一份暴露面清单，要定期和资产清单对账。我见过映射表里挂着三年前下线系统的条目，主机早就重装了，映射还在，端口就这么敞着。

4.5 第五步日志与告警的最小闭环，别等出事才发现没记录

DMZ 的日志是最有价值的安全数据之一，因为它的流量基线极其干净。最低限度要采集三类：

1. 防火墙的策略命中日志，特别是被拒绝的连接。DMZ 主机被攻陷后常见的动作就是向内网发起扫描，这个动作会在防火墙日志里留下一串密集的拒绝记录，是最早的告警信号。
2. DMZ 主机的登录日志和进程启动记录。谁在什么时候登进来的，跑了什么命令。
3. 出站连接的日志。DMZ 主机往公网发起的每一个连接都值得关注，尤其是非常见端口和非常见目的地。

提示：日志一定要做时间同步。我在一次真实排查里吃过这个亏——防火墙日志和应用日志的时间差了七分钟，导致完全无法判断某个请求是先到代理还是先到后端，硬生生多花了两个小时。所有 DMZ 设备统一指向同一组时间源，这件事花五分钟配，能省后面几小时。

告警阈值别设得太激进。DMZ 拒绝日志的量在正常情况下也不小（扫描器每天都在扫），如果每一条拒绝都告警，运维三天就会把告警静音。我的做法是按“同一源 IP 在五分钟内触发拒绝超过 N 次”和“DMZ 主机发起到内网的连接尝试”这两类做聚合告警，噪音低，命中率高。

5. 我在 DMZ 上踩过的坑，以及完整的排查链路

5.1 坑一：DMZ 主机居然能直接连内网数据库

这是最经典、也最致命的一个。现象是安全扫描报告里写着“DMZ 区域主机可访问内网数据库端口”。当时第一反应是策略写错了，翻了一遍策略表，明明没有放行这一条。继续查，发现问题出在主机自身的路由和双网卡上——那台 DMZ 服务器为了“方便运维”，额外插了一块接内网的网卡，等于从一个侧门绕过了防火墙。防火墙上的策略再严，也管不到不经过它的流量。

这个坑的教训是：隔离必须在网络层做，不能依赖主机的配合。只要存在物理或逻辑上的旁路路径，策略就是纸糊的。修复办法是拔掉那块网卡，运维访问改走跳板机。拔网卡的时候业务方很不情愿，说“这样每次传文件很麻烦”，但这就是安全的成本，绕不过去。

排查这类问题的标准动作是：在 DMZ 主机上执行ip route和arp -a，看清楚它到底有几条路可以出去、能看见哪些邻居。很多人只查防火墙策略，不查主机自身，方向一开始就偏了。

5.2 坑二：策略方向写反，排查了整整三小时

某个新上线的服务，公网访问一直超时。检查了一圈：DNS 解析正常、负载均衡健康检查正常、后端服务在本机 curl 正常，就是外网进不来。最后发现是防火墙策略的方向配反了——写成了“从内网区域到公网区域放行 443”，而实际流量方向是“从公网区域到 DMZ 区域”。

这种错误的根源在于对设备“区域”概念的理解偏差。有些设备的安全区域是按接口命名的，有些是按信任级别命名的，写策略时如果脑子里想的是“内网到外网”，而设备上实际要选的是“Untrusted 到 DMZ”，很容易选错。而且很多设备的策略界面只会显示区域名，不会提示你这条规则匹配的流量方向，配错了也不报错，只是不生效。

我现在的做法是：每条策略上线前，先临时开一条全量日志的观察规则，确认流量确实命中了预期的那条，再正式启用。多花十分钟，省三小时。

5.3 坑三：只控入方向，DMZ 变成对外攻击的跳板

这个坑的后果比想象中严重。某次外部通报说我们的一台服务器在对某个地址发起大量连接。查下来是 DMZ 里一台对外 Web 服务器被植入了东西，正在往外发包。问题在于，我们的策略只管了“谁能进来”，完全没管“能往哪出去”，DMZ 主机的出站流量是默认放通的。

修复之后我把出站策略收成了白名单：只允许访问软件源、时间源、以及业务确实需要回调的几个固定地址，其余全部拒绝。收完之后业务确实受了一点影响——有个第三方 SDK 会往一个没登记过的域名发心跳，被拦了之后功能异常。这个异常反而是好事，它让我们发现了业务实际依赖的外部地址清单，顺便做了一次资产梳理。

出站白名单落地时有个技巧：不要一次收死。先跑一周的“只记录不拦截”模式，把实际的出站连接全记下来，人工过一遍，形成白名单，再切换成拦截模式。这样业务中断的风险最小。

5.4 坑四：把运维管理后台放在 DMZ

有些团队为了“方便远程管理”，把堡垒机、监控面板、CI 的 Web 界面放在 DMZ 里，因为这些界面需要从外网访问。这个做法等于把管理入口直接摆在了火线上——攻击者一旦拿下这些面板，就等于拿到了内网的钥匙，前面所有的隔离设计瞬间清零。

正确的做法是管理面走独立通道：要么通过专门的运维接入方式，要么把管理界面收到内网，只允许特定来源访问，需要远程运维时通过多因子认证加最小权限。管理面绝不能和业务面共用同一个暴露入口。

我在评审时会专门问一句：“DMZ 里有没有任何一台机器，登上去之后能管理其他机器？”只要答案是“有”，这个设计就得重新考虑。

5.5 故障排查时的完整顺序：从外到内逐层剥

遇到“外网访问 DMZ 服务不通”这类问题，我按下面这个顺序走，基本不会漏：

这个顺序的核心逻辑是从最外层往里剥，每一层只判断“包到没到这一层”。判断“到没到”最可靠的手段是抓包——在防火墙内外两侧各抓一次，如果外侧有包内侧没有，问题就在防火墙；如果两侧都有但应用没日志，问题在主机或应用。抓包这件事看着麻烦，但它能把猜测变成事实，尤其在多方扯皮的时候，一份抓包记录能让讨论立刻收敛。

6. 把 DMZ 做“薄”：代理前置、微分段与更细的隔离思路

6.1 让 DMZ 里只放代理，业务退回内网

传统的 DMZ 里塞满了各种业务服务器，每一台都要打补丁、做基线、看日志。维护成本高不说，任何一台出问题都是暴露面。近些年更流行的思路是把 DMZ 做薄：DMZ 里只放反向代理和 WAF，真正的业务服务全部退回内网，代理通过受控路径回源。

这样做的好处很实在。第一，暴露面从“N 台业务机”收缩成“几台代理”，补丁和加固的工作量骤降。第二，业务机不再需要公网可达，可以直接放在更深的内网区域，享受更严格的保护。第三，代理层天然是流量汇聚点，做访问控制、限速、证书管理、日志采集都集中在一处。

代价是代理层成了关键路径，可用性要求更高，需要做冗余。而且代理的配置本身也要严格审查，一个配置错误（比如开放了任意路径的转发）就可能把整个内网暴露出去。我见过反向代理配置成“任意 Host 头都转发到内网”的案例，等于给攻击者开了一个通用入口。

6.2 DMZ 内部也要分段：一台失守不等于全段沦陷

很多环境把 DMZ 当成一个新的“大内网”，里面十几台机器全在一个 VLAN 里互访无阻。前面说过，这等于把内网的横向移动风险搬到了 DMZ。正确做法是 DMZ 内部继续按业务链路分段。

比如对外 Web 和缓存服务是一组，邮件网关是另一组，文件交换是第三组。每组一个小子网，组间默认不通，只放行必要的调用关系。这样即使某一组被打穿，攻击者也只能在那一小组里活动。

落到配置上，就是在同一台防火墙上为每个小组划一个子接口或 VLAN，区域之间写细粒度策略。如果设备支持，可以用更细的微分段能力（比如基于标签或身份的访问控制），把策略从“IP 对 IP”升级成“角色对角色”，运维上会轻松很多，因为机器扩容换 IP 时不用改策略。

6.3 零信任的语境下，DMZ 还值不值得做

这个问题我被问过好几次。零信任的核心主张是“不信任任何默认的网络位置，每次访问都要验证”，听起来像是要把 DMZ 这种基于边界的思路淘汰掉。我的看法是：思路在演进，但隔离这件事本身没有过时。

零信任强调的是身份和持续验证，它解决的是“进了内网就畅通无阻”这个问题。DMZ 解决的是“暴露面收敛和攻击路径阻断”。两者不是替代关系，而是分层叠加。在零信任架构下，你依然需要一个地方放对外入口，依然需要保证这个入口被攻破之后不能直接摸到核心数据——这本质上还是 DMZ 要解决的问题，只是实现手段从“网段隔离”变成了“身份加网段双重隔离”。

实际落地时，我的做法是在保留 DMZ 网段隔离的基础上，叠加身份验证：所有对 DMZ 后业务的访问，除了网络层放行，还必须通过身份认证和授权，两者都过才放行。这样即使网络层策略被误配放宽，身份层还能兜底；即使身份凭证泄露，网络层还能限制横向范围。

6.4 几个可以直接抄的落地习惯

最后分享几个我在多个项目里坚持下来的习惯，都是低成本高回报的：

第一条，DMZ 资产清单每季度对一次账。对账内容包括：清单上的机器是否还在、防火墙的 NAT 映射是否和清单一致、安全组是否有清单外的放行。这件事花不了半天，但能发现大量“幽灵资产”。

第二条，新服务上线前必须过一遍“最小暴露”评审。评审只问三个问题：这个服务真的需要公网访问吗？需要的端口能再少吗？被攻破的最坏结果是什么？三个问题问下来，通常能砍掉一半的暴露需求。

第三条，DMZ 主机的出站流量白名单化，并且用“先记录后拦截”的方式平滑过渡。这一步做完，DMZ 被当作跳板的风险会大幅下降，而且你会意外发现业务对外部依赖的真实情况。

第四条，把“DMZ 主机能否访问内网”做成一条定期自动检测项。从 DMZ 里挑一台上机，定时对内网几个关键端口发起连接，全不通才算合格。这件事不依赖人工检查，能长期守住底线。

第五条，所有策略变更留痕，写清变更原因和回滚方法。我在一次紧急排障中深切体会到这条的价值——凌晨两点要临时放通一个端口，如果当时没记下来，第二天可能就永远留在那里了。变更记录不用复杂，一个表格，四列：时间、改了什么、为什么改、什么时候回滚。

这套东西做下来，DMZ 才不是一个停留在拓扑图上的方框，而是真正在起作用的隔离层。我自己最大的体会是，安全设计里最难的部分从来不是配一条策略，而是在业务压力和交付节奏下，坚持不把那条默认拒绝的底线一点点放宽。