前阵子帮一位做跨境电商的朋友看他新机房的拓扑草图图上把订单服务、数据库、对外的接口网关全画在同一个网段里我随口问了句“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拒绝仅 80/443 等业务端口只暴露必要服务DMZ → 公网拒绝仅软件源、时间同步、特定回调防止被当作外联通道DMZ → 内网拒绝极少数如到指定数据库的 3306阻断横向渗透内网 → 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 网段独立的 VPC 子网与业务子网不同网段防火墙接口策略安全组 网络 ACL安全组是有状态的ACL 无状态公网出口弹性公网 IP / NAT 网关DMZ 出网走独立 NAT内网访问控制路由表 对等连接策略路由不通比策略拒绝更彻底边界防护设备云防火墙 / WAF 实例注意部署形态是串联还是旁路云上做 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 的日志是最有价值的安全数据之一因为它的流量基线极其干净。最低限度要采集三类防火墙的策略命中日志特别是被拒绝的连接。DMZ 主机被攻陷后常见的动作就是向内网发起扫描这个动作会在防火墙日志里留下一串密集的拒绝记录是最早的告警信号。DMZ 主机的登录日志和进程启动记录。谁在什么时候登进来的跑了什么命令。出站连接的日志。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 服务不通”这类问题我按下面这个顺序走基本不会漏顺序检查点命令/方法判断依据1DNS 解析dig/nslookup解析出的 IP 是否为入口 IP2入口可达性telnet IP 443/curl -v超时还是拒绝3负载均衡/代理查看监听器状态与后端健康后端是否被判为不健康4防火墙策略命中查策略日志/计数器有无该流量的命中记录5NAT 映射核对映射表内外地址端口是否对应6主机监听ss -lntp端口是否真的在监听7应用日志看业务日志请求是否到达应用层8路由与回程ip route/ 抓包回程路径是否对称这个顺序的核心逻辑是从最外层往里剥每一层只判断“包到没到这一层”。判断“到没到”最可靠的手段是抓包——在防火墙内外两侧各抓一次如果外侧有包内侧没有问题就在防火墙如果两侧都有但应用没日志问题在主机或应用。抓包这件事看着麻烦但它能把猜测变成事实尤其在多方扯皮的时候一份抓包记录能让讨论立刻收敛。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 才不是一个停留在拓扑图上的方框而是真正在起作用的隔离层。我自己最大的体会是安全设计里最难的部分从来不是配一条策略而是在业务压力和交付节奏下坚持不把那条默认拒绝的底线一点点放宽。
