白名单要有可追溯的矩阵
白名单不是按印象逐条放行，而是先把资产、端口协议、来源三个维度画成矩阵，逐格标注业务必要性与责任人，再落成规则。矩阵本身就是评审与审计的依据：任何一条规则都应该能回答“谁批准、为什么需要、什么时候复核”。缺少矩阵的白名单会迅速退化成一堆没人敢改的放行集合，最后与全放行相差无几。
基本信息
| 适用平台 | 全部平台（主机防火墙、云安全组、网络设备 ACL） |
|---|---|
| 三个维度 | 资产 × 端口/协议 × 来源 |
| 必填属性 | 用途、责任人、到期复核日期 |
| 基线 | 每条规则可追溯到资产与来源 |
| 风险等级 | 中 |
典型使用场景
- 新项目上线：先出矩阵再落规则，避免边做边加造成无序放行
- 定期评审：按到期日期逐条复核，剔除已失效的放行
- 变更评审：变更单附上矩阵片段，评审有据可依
- 审计取证：等保与内部审计要求访问控制规则有明确授权依据
- 事故复盘：快速判断某条放行是否属于必要规则
矩阵样例可用格式
矩阵样例可用格式
# | 资产 | 端口/协议 | 来源 | 用途 | 责任人 | 复核到期 |
# | web01 | 443/tcp | 0.0.0.0/0 | 对外网站 | ops | 2027-01 |
# | web01 | 22/tcp | 10.8.0.0/24 | 堡垒机 | ops | 2027-01 |
# | db01 | 3306/tcp | 10.0.1.0/24 | 应用访问 | dba | 2027-01 |
# | db01 | 22/tcp | 10.8.0.0/24 | 堡垒机 | dba | 2027-01 |
# 落地顺序：先加新放行 → 验证业务 → 再删旧放行矩阵各列读法
| 列 | 含义 | 填错的后果 |
|---|---|---|
| 资产 | 主机名或资产编号 | 写泛称则无法判断规则属于哪台机器 |
| 端口/协议 | 如 443/tcp、53/udp | 协议写错，规则看似放行实际不通 |
| 来源 | 网段或地址集合 | 网段边界画错等于给邻居开门 |
| 用途 | 业务必要性说明 | 缺说明的规则在评审时难以判断能否删除 |
| 责任人与复核到期 | 归属与复核时间 | 无人负责的规则会长期留存 |
评审原则：来源写 0.0.0.0/0 的条目必须给出强理由（确实对公网提供服务），其余一律要求收敛到具体网段。
落地要点
- 规则变更遵循先加后删：先加新放行并验证业务，再删旧放行
- 把复核到期写进规则备注并设日历提醒，避免矩阵与实际脱节
- 来源写网段前确认网段归属与边界，尤其是云内共享网段与办公网段
- 矩阵纳入版本控制，变更留痕，谁改的、什么时候改的一目了然
- 定期用实际规则反查矩阵：出现矩阵里没有的规则就是影子放行
矩阵脱离实际会迅速失效：若长期无人更新，规则与矩阵对不上，评审就变成走过场，风险在无人察觉中积累。