防火墙策略即代码的落地路径

我以前改防火墙，习惯在控制台里点，点完截个图存到文档里，觉得这就是留痕了。后来才明白，截图只能证明“我改过”，证明不了“改得对不对”，更救不回一次误阻断。真正让我改变做法的，是意识到安全和网络的变更里，最贵的不是写规则，而是写错之后发现不了。

把策略塞进版本库，是这条路的起点。源内容里提到 AWS 的集中式网络检查方案用 GitOps 来管理防火墙、策略和规则组的变更，覆盖成百上千个 VPC 和账号。这个做法的价值不在“留痕”，而在于每次变更都能被流水线拦一道、被 diff 审一遍、被回滚一次。控制台上手点的规则，没法 diff，也没法在合并前被同事看一眼。

门禁要拦住的是语义错误

语法错误其实好办，平台自己就会报。麻烦的是那些“配置成功”的错误：一条全拒绝规则被放到规则组顶部、网段写成了 /8、标签选择器写错导致规则只对一半业务生效。这类问题在控制台里长得一模一样。

源内容给了一个最小门禁的思路：声明本次变更的目标和涉及范围，然后挂几条硬规则——不得新增全源全目的的拒绝条目、新增拒绝数不能超过基线一定比例、变更涉及的 VPC 必须全部落在声明的范围里、必须附带可执行的回滚计划和责任人。四条规则不复杂，但每一条都对着一次真实可能发生的事故。

仿真不是跑一遍不报错

我一开始以为仿真就是拿新策略跑一下，没报错就发。其实有用的做法是拿最近几天的流量日志抽样，用新旧两套策略分别判定，输出三张表：新增拒绝、新增放行、不变。新增拒绝那张表最危险，每一条都得让业务方点头说“这是该断的”，不然就是一次误阻断。这一步成本比事后回滚低太多。

回滚也得是代码

引流本身就有成本。源内容里提到，开启防火墙时底层网络会做路由收敛，通常带来一两秒的抖动。这意味着变更窗口不能按“无损”设计。更关键的是回滚要分层：先看是不是路由的问题，再回退策略快照，再退到单个规则组，最后才是切备用出口。顺序反了，改策略也是白改。

我现在会把这些判断写进脚本：指标异常加上时间窗口内确实有变更，两个条件同时满足才自动动作。没演练过的回滚方案，和没有回滚方案其实差不多——这话我吃过亏才信。