2. 云网络基础与安全域设计
在云上做微隔离，第一步不是打开防火墙策略编辑器，而是先把“网络长什么样”画清楚。VPC/VNet、子网、路由表、安全组、网络ACL、可用区与区域，这些对象共同决定了流量“能不能到、从哪到、被谁拦”。如果对底层拓扑理解有偏差，后续写的每一条微隔离策略都可能落在错误的边界上。
一、云网络的骨架：区域、可用区与 VPC/VNet
区域（Region）是云服务商在地理上独立的数据中心集群，可用区（AZ）是区域内电力、网络、制冷相互独立的故障域。跨可用区通信通常走低延迟内网，但存在跨 AZ 流量费用与故障隔离差异；跨区域通信则必须经过公网或云专线/对等连接，延迟和成本都显著上升。因此安全域划分的第一条原则是：先按故障域和合规边界切分，再按业务功能细分。
VPC（AWS 语境）或 VNet（Azure 语境）是云上逻辑隔离的私有网络，是安全域划分的顶层容器。一个 VPC 内可以划分多个子网，子网是绑定在某个可用区内的 IP 地址段。子网一旦创建，其可用区不可更改，这是设计时必须提前规划的关键约束。例如规划一个 10.10.0.0/16 的 VPC，可按如下方式切分：
VPC: 10.10.0.0/16
├─ 子网 web-a 10.10.1.0/24 AZ-A 业务：Web 前端
├─ 子网 web-b 10.10.2.0/24 AZ-B 业务：Web 前端
├─ 子网 app-a 10.10.11.0/24 AZ-A 业务：应用服务
├─ 子网 app-b 10.10.12.0/24 AZ-B 业务：应用服务
├─ 子网 db-a 10.10.21.0/24 AZ-A 业务：数据库
└─ 子网 mgmt 10.10.31.0/24 AZ-A 业务：运维管理
这种“同功能跨 AZ 成对出现、不同功能分网段”的布局，使安全域天然具备可用区冗余，同时让后续策略可以按网段聚合，而不是逐台主机维护。
二、路由表：决定流量“往哪走”
路由表是子网级别的属性，控制子网内实例的出向流量路径。它不负责“允许或拒绝”，只负责“下一跳是谁”。常见路由条目包括：本地路由（VPC 内互通）、NAT 网关（私网访问公网）、互联网网关（公网直连）、对等连接（VPC 互通）、专线/VPN 网关（混合云）。
安全域设计中的关键判断是：哪些子网需要默认路由指向互联网网关，哪些只能指向 NAT，哪些完全不出网。例如数据库子网通常不配置 0.0.0.0/0 路由，只保留本地路由；应用子网通过 NAT 出网以获取补丁；Web 子网才可能挂载互联网网关。路由表本身不提供安全能力，但它是流量可见性的前提——如果流量根本不经过某个检查点，安全组和 ACL 就无从拦截。
三、安全组与网络ACL：两层过滤的差异
安全组（Security Group）作用于实例/网卡级别，是有状态的：允许出向请求后，返回流量自动放行，无需单独配置入向规则。网络ACL（NACL）作用于子网级别，是无状态的：入向和出向必须分别显式放行，返回流量需要单独配置临时端口范围。二者是互补关系，不是替代关系。
| 对比项 | 安全组 | 网络ACL |
|---|---|---|
| 作用对象 | 实例/弹性网卡 | 子网 |
| 状态 | 有状态 | 无状态 |
| 规则类型 | 仅允许 | 允许 + 拒绝 |
| 规则顺序 | 全部评估后合并 | 按编号从小到大，命中即停 |
| 典型用途 | 主机级精细控制 | 子网级粗粒度隔离与兜底 |
工程实践中常见的错误是：只配安全组、忽略 NACL，导致子网间横向流量在安全组层面被放行后无人兜底；或者 NACL 只放行入向、忘记出向临时端口，造成返回流量被丢弃。一个可用的 NACL 出向规则示例（允许已建立连接的返回流量）：
规则号 100 协议 TCP 端口 1024-65535 源 0.0.0.0/0 允许
规则号 110 协议 TCP 端口 443 源 0.0.0.0/0 允许
规则号 * 协议 全部 端口 全部 源 0.0.0.0/0 拒绝
四、安全域划分原则与工程落地
安全域划分的核心目标是把“信任级别相近、访问模式相似”的工作负载放在同一域内，域间默认拒绝、按需放行。可遵循四条原则：
- 按信任级别分层：互联网区、DMZ、应用区、数据区、管理区，信任度逐层递减。
- 按业务功能聚合：同一业务的前端、应用、数据库可各自成域，避免跨业务混布。
- 按合规要求隔离：涉及个人敏感信息、支付数据的域单独划分，满足等保/PCI 的边界要求。
- 最小化域间通道：域间只开放必要的协议和端口，且优先通过安全组引用（SG 引用 SG）而非 IP 段。
落地时，建议先画出“域—子网—路由—过滤”四层关系图，再逐条把访问关系转成策略。下图展示了一个典型三层业务在双可用区下的安全域与流量路径：
图中可以看到，Web 域只接受来自互联网网关的 80/443，App 域只接受来自 Web 安全组的 8080，DB 域只接受来自 App 安全组的 3306。跨可用区的 Web→DB 直连被默认拒绝，这正是微隔离“域间最小化通道”的体现。实际配置时，安全组规则应尽量引用安全组 ID 而非 CIDR，这样实例扩缩容时策略无需修改。
最后，安全域不是一次划分就固定不变的。业务上线、合规审计、攻防演练都会推动域边界调整。建议把“域—子网—安全组—NACL—路由”的对应关系维护成一份可版本化的清单，每次变更同步更新，这样微隔离策略才能持续与真实拓扑保持一致。