核心是结构化梳理业务关系、划分安全域、遵循最小权限原则。先建业务互访矩阵表明确访问需求，再按域间关系配置策略，使用地址/服务集管理，严格限制管理流量，每条策略需可验证、可审计、有生命周期管理。
规划不同业务子网之间的互访防火墙策略，核心不是堆规则，而是理清“谁要访问谁、为什么能通、凭什么不能通”。重点在于结构化梳理业务关系、明确安全边界、分层配置策略，避免后期策略爆炸或误放行。
先画清楚业务互访矩阵
不要一上来就写策略。先整理一张表，横向是源业务子网（如财务系统 10.10.1.0/24），纵向是目标业务子网（如HR系统 10.10.2.0/24），格子里填：是否允许访问、访问协议端口（如 HTTPS/443）、访问动因（如单点登录跳转）、是否有 NAT 或代理中转。这张表就是后续所有策略的依据，也是审计和变更时的参照底图。
- 建议用 Excel 或 CMDB 工具维护，标注责任人和最后更新时间
- 有跨部门或外包系统的，必须同步确认访问意图，避免单方面假设
- 对“默认不允许”的场景，明确标出例外项，不写“其他端口均禁止”这类模糊描述
按安全域划分策略区域
防火墙策略本质是安全域之间流量的许可清单。把功能相近、信任等级一致的子网归入同一安全域（如 trust-zone、dmz-zone、hr-zone），再基于域间关系配置策略，比逐个子网配更清晰、易维护。
- 例如：所有数据库子网统一划入 db-zone，应用服务器划入 app-zone；app-zone → db-zone 允许 MySQL/3306，但反向拒绝
- 一个子网只能归属一个安全域；若某子网需同时对接高/低信任区，应拆分为两个逻辑子网或启用策略标签精细化控制
- 域内互通（如同属 app-zone 的微服务）通常不由防火墙控制，交由交换机 ACL 或安全组处理
策略配置遵循“最小权限+显式拒绝”原则
每条策略只解决一个明确的访问需求，且只放开必要协议、端口、IP 范围。默认策略设为“拒绝所有”，不依赖隐式拒绝。
- 优先使用地址集（address-set）和服务集（service-set）管理 IP 段和端口组合，避免在多条策略里重复写 10.10.1.0/24、TCP/443
- 涉及 NAT 场景（如公网用户访问内网 Web），策略中的源/目的地址必须填写转换前的真实地址，而非 NAT 后地址
- 对管理类流量（如 SSH、RDP），严格限制源 IP，建议单独建一条高优先级策略，日志全开
预留验证与运维通道
策略上线前必须可验证，上线后必须可追踪。否则等于盲配。
- 每条策略附带测试用例：从源子网某台终端 ping 目标 IP、telnet 端口、curl 接口，记录预期结果
- 开启会话日志（session log）和策略命中统计，定期检查未命中策略或高频拒绝项，识别配置偏差或业务变更
- 设置策略生命周期标签（如“临时开通-20261231”），到期前自动提醒复核，避免僵尸策略堆积
