3. 网络分区设计原则

网络分区不是把网段随手切成几块，而是用一组可验证的原则约束“谁能到谁、能到哪一层、出问题影响多大”。如果只按部门或楼层划 VLAN，往往得到的是“看起来分了区、实际横向畅通”的假隔离。本节把分区设计拆成四条原则、三个可调参数（粒度、边界、命名），并给出可直接套用的落地方法。

一、四条原则：从“允许什么”到“如何证明”

最小权限是分区的第一性原理：任何两个对象之间默认不可达，只有业务确实需要的“源—目的—协议—端口—方向”五元组才被显式放通。它约束的是策略集合，而不是网段数量。例如数据库区只接受应用区发起的 TCP 3306，且只允许应用区中承担写库角色的主机；运维跳板机到数据库只开放 22/3306 且必须经审计。判断是否做到最小权限，可以统计“任意—任意”规则条数、宽端口范围（如 1-65535）条数、双向放通条数，这三类应趋近于零。

纵深防御要求同一攻击路径上存在多个独立控制点，且不依赖单点。典型层次是：边界防火墙做粗粒度区域间控制，主机防火墙/安全组做实例级控制，工作负载微隔离做进程级控制，应用层再做认证与鉴权。纵深的关键是“控制点异构”——如果三层都由同一台设备、同一份策略下发，一旦策略误配就是全链路失效。设计时应明确每一层“拦什么、不拦什么”，避免层层重复却不覆盖盲区。

故障域隔离关注的是“一个区出事，最多影响谁”。它既包括安全爆炸半径（勒索软件、横向移动），也包括可用性爆炸半径（广播风暴、路由震荡、策略下发失败）。做法上：把不同信任等级、不同生命周期、不同爆炸半径的对象分到不同区；控制区间依赖为有向无环图，避免 A→B→C→A 的循环依赖导致故障级联；对关键区设置独立策略计算与独立审计通道，防止控制面故障连带数据面。

可观测性是前三条原则能否被验证的前提。分区必须产生可读的信号：策略命中日志、被拒绝连接日志、流量基线、标签与策略的映射关系。没有可观测性，最小权限无法收敛（不知道哪些规则没用过），故障域无法评估（不知道真实调用关系）。落地时至少保证：每条拒绝都有日志、每个工作负载都有身份标签、每次策略变更都有版本与回滚点。

二、分区粒度：粗、中、细三档怎么选

粒度决定策略的数量与维护成本。粗粒度按环境划分，例如生产、预发、测试、办公四个区，策略少、易维护，但横向移动空间大，适合作为第一层骨架。中粒度按业务域或应用划分，例如订单区、支付区、用户区，能表达业务依赖，是多数企业的推荐起点。细粒度按工作负载甚至进程身份划分，能实现“同一应用内不同角色也不互通”，但策略条目可能从几十条涨到几千条，必须依赖标签自动生成与流量学习，否则无法维护。

选择粒度可用一个简单判据：如果两个对象被攻陷后不应互相访问，就应分到不同区。例如 Web 前端与数据库不应同区；同一应用的读副本与写主库，若读副本被攻陷不应能写主库，也应分到不同策略组。粒度不是越细越好，而是“刚好覆盖真实信任边界”。

三、边界定义：策略执行点在哪里

边界不是画在地图上的线，而是“策略在哪里被执行”。常见边界有三类：物理/基础设施边界（机架、机房、云账号、VPC），逻辑网络边界（子网、安全组、防火墙接口），身份边界（标签、服务账号、证书）。设计时要回答：跨这条边界的流量，由哪个设备或代理检查？如果一条边界上没有执行点，它就只是命名，不构成隔离。

以云环境为例，VPC 是粗边界，安全组是实例级边界，微隔离代理是进程级边界。三者应形成纵深：VPC 间默认拒绝，安全组只放通必要端口，微隔离再按标签限制东西向。若只配了安全组而微隔离未启用，则同一安全组内实例仍可任意互通，边界实际是“虚”的。

四、命名规范：让策略可读、可查、可回滚

命名是分区能否长期维护的关键。推荐统一格式：环境-区域-业务-角色-序号，例如 prod-dmz-web-01、prod-core-db-02、test-app-order-03。同时用标签承载策略语义，至少包含五类：env（prod/test/dev）、zone（dmz/core/mgmt）、app（order/pay/user）、role（web/app/db）、tier（frontend/backend/data）。策略写成“允许 env=prod 且 zone=core 且 role=app 访问 role=db 的 3306”，而不是写 IP 列表。

五、一个可执行的收敛示例

假设某业务初始只有“生产区”一个网段，所有主机互通。按上述原则收敛：第一步打标，给 12 台主机分别标注 env=prod、zone=core、app=order、role 为 web/app/db。第二步观察 7 天流量，得到真实调用关系：web→app 的 8080、app→db 的 3306、跳板机→所有主机的 22。第三步生成白名单策略，默认拒绝其余全部。第四步验证：从 web 主机尝试直连 db 的 3306，应被拒绝并产生日志；从 app 主机连 db 应成功。第五步收敛：两周后检查命中计数，若某条规则命中为 0，评估后删除，进一步缩小权限。

这个过程中，粒度选择为“按角色分三组”，边界执行点为微隔离代理，命名为 prod-core-order-web 等。最终效果不是“网段变多了”，而是“任意两台主机之间的可达性都有明确依据，且可被日志证明”。

六、常见误区与检查要点

• 只分区不控流：划了 VLAN 但三层路由全通，等于没隔离。检查区间策略是否存在默认拒绝。
• 边界无执行点：命名了“DMZ 区”但流量不经过任何检查设备。检查每条边界的执行点清单。
• 粒度失控：策略条目数月增长超过 30% 且无人清理。检查是否有流量学习与规则生命周期机制。
• 命名随意：出现 vlan10、server1 等名称，导致策略无法按语义生成。检查命名表与标签覆盖率。
• 无可观测性：拒绝日志未采集，无法判断策略是否过严或过松。检查拒绝日志的采集率与保留周期。

四条原则不是并列的口号，而是互相约束：最小权限决定策略内容，纵深防御决定控制点分布，故障域隔离决定分区拓扑，可观测性决定前三条能否被验证和持续收敛。粒度、边界、命名则是把原则翻译成可执行配置的三个旋钮。设计时先定边界与执行点，再选粒度，最后用命名和标签把策略写成可读、可查、可回滚的形式，分区才算真正落地。