文章总结： 本文复盘了因WAF规则描述歧义导致误操作、致使内部系统公网暴露10天的事故。根因在于文档与逻辑不一致及缺乏配置监控。整改措施包括标准化规则描述，引入IaC和GitOps将配置代码化，通过MR审核及自动化脚本比对线上与基线差异，有效防止配置漂移并降低人为操作风险。 综合评分： 91 文章分类： 安全建设,安全运营,云安全

一次有惊无险事故引发的思考：从 ClickOps 到 GitOps

原创

imBobby imBobby

imBobby的自留地

2026年1月23日 20:32 广东

2026 年 1 月，因为一条具有歧义的规则备注，导致运维误将核心 WAF 规则关闭，内部系统对公网暴露长达 10 天。

本文复盘了这次由“文档与代码不一致”引发的事故，并探讨如何通过 IaC 和 GitOps 彻底解决此类人为风险。

引言：当注释忽悠了我怎么办

咱们常说“代码是诚实的，但注释可能会撒谎”。我以前以为这只发生在代码里，没想到在 WAF 的配置界面上，一句规则描述竟然导致了防线失守…

上周，我们团队经历了这次静默故障：我们的内部测试系统 test canary alpha QA 等居然允许公网访问了接近十天，虽然说有 WAF 防护吧，但是这些系统肯定是不应该暴露出去的。

当然也要庆幸暴露出去的还好只是测试环境，而不是内部办公域…否则我估计运维团队免不了一番拷打。

事故现场：消失的 403

事情的起因很简单。例如说，我们使用 Cloudflare WAF 来保护内部开发域名 test.xx.dev，逻辑非常直观：

• 规则逻辑： 如果（来源 IP 不是办公室）且（来源 IP 不是 VPN），则 Block（拦截）。
• 预期效果： 只有自己人能访问，外网访问直接 403。

然而，有一个研发在今天，也就是 1 月 23 日发现这条规则的状态变成了 Disabled。

根因分析：好心办坏事

为什么会被关掉？是黑客入侵？还是恶意破坏？ 查看 Cloudflare 的审计日志后，真相让人哭笑不得…

审计日志还原：

// 2026-01-13 的操作记录"action": "rulesets.update","actor": "[email protected]","modified_rules": [  {    "enabled": false, // 关键动作：关闭规则    "description": "配置期间仅允许指定 IP 访问主站", // 罪魁祸首    "expression": "(not ip.src in $office_ip ...)"   }]

问题出在这个description上。

这条规则的规则描述写着：“配置期间仅允许指定 IP 访问主站”。 运维同学在看到这条规则时，会认为这条规则的意思是：

当规则启用时，只允许某些 IP 访问主站；当这条规则禁用时，就允许全部 IP 访问主站

我们可以认为这属于类似临时维护窗口一样的规则对吧！

刚好赶上了 1 月 13 日我们要切换部分流量到这个站点，也就是说希望 xxx.dev 这个域名能被全部 IP 访问，而不是仅限公司出口和 VPN 出口访问，因此运维同学直接就把这条规则关闭了（并没有看一眼规则内的表达式怎么写）…也还好他是关闭不是删除！

这就是典型的认知错位：

• 表达式逻辑： 是一个永久性的白名单防护。
• 描述文字： 和表达式逻辑不匹配。

为什么我们没能立刻发现？

这次事故持续了 10 天，为什么监控没报警？因为没监控（创业公司一团乱李姐一下😅测试环境属于非核心资产，监控级别较低，导致未能第一时间触发 P0 级告警

• 沉默的失败： 规则被关闭后，业务访问一切正常，没有反馈，运维自然不知道。
• 依赖单点防御： 我们过分依赖 WAF 这一层，而忽视了对 WAF 本身状态的 Meta-Monitoring。

（只能说还好我们这些测试系统也做了一层防御，并且入侵检测也一直开着…否则后果不好说啊）

痛定思痛：

事发生了，不应该去要找捅出娄子的同学麻烦，而是要找到问题造成的根因，从根上解决问题。

整改一：消灭歧义

我们将所有规则描述标准化，加上了类似 [CRITICAL]、[DO NOT DISABLE] 的前缀。

• Before:配置期间仅允许指定 IP...
• After:[核心访问控制] 仅允许办公网 IP 访问 (生产环境常驻)

整改二：拥抱 IaC

我们不能再容忍在 Cloudflare 网页控制台上“点点点”（ClickOps）了。我们编写了自动化脚本，将 WAF 规则纳入 GitLab 版本控制：

1. 代码化： 所有的规则变成 Terraform 代码或 JSON 配置文件。
2. 版本控制： 修改规则必须提 Merge Request，看到 diff 才能合并。
3. 自动化审计： 我临时写了一个脚本 cloudflare-scripts，定期拉取线上规则与 Git 仓库里的基线进行比对。如果线上规则被意外关闭，脚本会立刻报警。

结语

这次事故怎么说呢，属于给我们这种草台班子创业公司上了一堂生动的人因工程课。

安全不仅是对抗黑客，更是对抗熵增和人为失误。

好的安全系统，不应该让操作者去猜是什么意思，而是应该通过流程和工具，把犯错的成本提高。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：imBobby的自留地 imBobby imBobby《一次有惊无险事故引发的思考：从 ClickOps 到 GitOps》