第四十六章：冻结开关(7/9)

测试”“自动脚本”。他们永远有词。 所以关键不在于他们说什么，而在于：**第三方平台把撬锁尝试写进了审计，且保全了来源。**这条记录一旦进入取证审计，它就不再是口径，而是证物。 证物会逼出两件事： *谁拥有超级权限； *为什么在冻结期间仍有人敢用超级权限。 如果他们能在冻结期间动手，那“禁变窗口”就不安全。 如果他们不能动手却仍敢尝试，那他们在“试探监管底线”。 无论是哪一种，都意味着接下来冲突会升级。 --- 晚上七点，供应商终于给出解释：itops_superadmin的两次操作为“自动化健康检查脚本误触发”，脚本设计用于“校验策略一致性”，在检测到“延迟异常”时会尝试执行“回退恢复动作”，但由于冻结已启用，动作被阻止。供应商称已立即停用脚本并提交整改。 这份解释看似合理，却暴露了更危险的事实：他们确实存在一个脚本，能在检测到延迟异常时自动尝试关闭围栏、夺回控制权——哪怕只是“误触发”，也说明这种行为被写进自动化流程里。自动化流程存在，就说明这不是偶然，这是惯例的一部分。 惯例就是：遇到延迟就开回退，遇到风险就夺控制权。 这恰恰是整改要消灭的东西。 监管的回应比以往更硬：“请提供脚本设计说明、触发条件、权限调用方式、近三个月运行记录与审计轨迹。并说明为何健康检查脚本具有系统级超级权限。此问题属于严重安全风险，须纳入第三方取证审计范围。” 供应商没有再说话。 沉默意味着他们的脚本并不干净。干净的脚本敢拿出来，脏的脚本拿出来会露出更多东西：触发条件、权限链、执行日志、甚至历史上曾经成功关过围栏、改过策略。 如果脚本曾经成功过，那就不是“误触发”，而是“暗门”。 暗门一旦成立，这件事的性质会从“流程缺陷”跳到“安全风险”。 林昼感觉太阳穴有点跳。他知道他们正在逼近一条更危险的线：从整改走向取证，从取证走向责任追究。责任追究会让某些人失去工作，甚至失去自由。 失去越近，反扑越激烈。 --- 夜里九点半，许景又发来消息：“他们说监管要查脚本，说是因为我‘乱说话’。我现在很怕，他们会不会把锅甩给我？” 林昼看着这句话，心里一沉。供应商与原医院内部一定有人在制造叙事：把升级归因于
本章还未完，请点击下一页继续阅读>>>