目标
防火墙与安全组规则会随每次救火与早已下线的集成不断累积，直到网络许可的远超任何人本意。用“预期流量矩阵”对“实际观测流量”做对账，考古变成证据：没观测到的规则多半是死重，观测到却没预期的就是该堵的暗道。
步骤要点
- 建模预期流：从架构出发记录哪些服务、层级、端口应该互通，由架构负责人签署，不参考现行规则。
- 捕获实际流：取代表性窗口的流日志，把源目地址联结到服务身份而非裸 IP。
- 对账预期与实际：观测到但无预期的流要么缺文档要么真问题，预期但从未观测的规则是删除候选。
- 按观测需要收紧规则：重写规则只覆盖预期流加登记例外，历史窗口也从未命中的规则删除。
- 收紧后再跑一轮对账：捕捉只在周或月级出现的流，反复迭代直到差异清零或全部处置。
排错提示
删了规则月度批处理挂了是窗口太短，收紧后必须再观测一个完整周期；规则数只增不减说明从没做过对账，把删除候选显式列出来评审；break-glass 路径平时零流量，删之前先登记为例外并做一次演练。
适用边界
流日志采样率与覆盖周期决定对账灵敏度，长周期任务需延长窗口；服务身份联结依赖 IP 与服务的稳定映射，弹性 IP 频繁变化的环境要先建身份解析。
代码示例
intended matrix (signed by owners):
web -> api:443 api -> db:5432
api -> cache:6379 batch -> db:5432
observed (14d window, service identity):
web -> api:443 OK
api -> db:5432 OK
api -> cache:6379 OK
batch -> db:5432 OK
api -> legacy-pay:8443 UNINTENDED (rule from 2023)
admin-pod -> *:ANY UNINTENDED (over-broad)
rules: 214 -> 96 (118 never observed, removed
after 14d + 30d history check)
re-run window: 2 monthly flows restored (registered)