第三十三章：权限日志(2/3)

首发：~第三十三章：权限日志

可系统并不会无缘无故选择“回滚到v2.9”。系统的规则由人配置，触发阈值由人设定，审批链由人设计。所谓自动化，只是把责任推远。

林昼回：“要求查看与该回滚事件关联的‘触发规则ID’、‘监测指标’、‘阈值’、‘审批链’（如果有），以及触发来源（监测模块/人工工单）。至少要在笔录里写明：供应商拒绝提供哪些字段。”

梁组长回：“他们同意展示触发规则ID，但不允许抄录，称属于算法。”

林昼回：“那就让监管记录：供应商拒绝抄录触发规则ID，理由‘算法’。同时要求供应商提供触发规则的摘要说明：触发指标名称、阈值范围、规则生效日期。摘要不是算法。”

梁组长回：“监管在要求。”

十点四十七，梁组长又发：“发现一个更敏感的条目：同一时间段还有‘策略更新-覆盖’事件，版本从v3.1切换到v3.1-hotfix。时间在转运前一天。操作者账号为‘vendor_ops_07’。原医院信息科说他们没有这个账号。”

林昼的心跳加快。v3.1-hotfix意味着供应商曾在转运前一天做过紧急补丁。紧急补丁后又在转运当夜回滚到v2.9。热修复、回滚，这是一套典型的运维事故处置链。如果他们把某个策略包改成更“干净”的行为模式，再回滚到旧版执行“照做”，就能在日志里伪装成“故障处置”。

但原医院信息科说“没有这个账号”，说明账号属于供应商，并且可能绕过医院的可见权限。这将把“医院内控”与“供应商权限”之间的边界撕开。

林昼回：“把‘vendor_ops_07’写入笔录。询问：该账号权限级别是什么（观察/策略/回滚）？是否需要医院授权？是否在合同里备案？是否有登录IP段（可哈希）？是否存在境外中继节点路由特征？这条能直接连接东京回路。”

梁组长回：“供应商同意说明该账号属于驻场工程师，但拒绝提供登录IP，称涉及个人隐私与安全。”

林昼回：“IP可以哈希或掩码，不必暴露完整。至少提供‘登录区域/节点’（境内/境外/东京中继）与‘是否通过中继’字段。否则‘境外中继节点’无法核对。”

梁组长回：“监管要求提供‘是否通过中继’字段。供应商说系统没有记录中继信息。”

林昼冷笑了一下，但只在心里。系统怎么可能没有记录中继信息？只要经过中继，就会有路由痕迹。说没有，可能是他们不想提供，或他们把日志拆分在不同系统里。拆分也是一种隐藏：把关键字段放在另一个你看不到的审计系统里。

他回：“记录供应商声称‘无中继记录’。同时要求说明：中继节点属于什么层（网络加速/CDN/VPN/跳板机）？若是跳板机，必有跳板日志；若是CDN，必有边缘日志。让他们提供最小证据：中继节点清单与用途。”

梁组长回：“监管记了。”

十一点二十，梁组长发来一句：“原医院信息科开始推卸，说他们只负责业务系统，邮件网关运维完全由供应商托管。供应商说托管是合同约定。”

托管——责任的黑洞。托管意味着医院可以说“我不知道”，供应商可以说“我只是服务”，监管就会面对一层层外包。外包链条越长，真相越难追。

但今天的日志已经让黑洞出现了边缘：回滚事件、热修复事件、操作者账号、回执SUCCESS。只要这些东西写进监管笔录，外包链条再长也挡不住“行为发生过”。

行为发生过，就有人要解释。

---

中午十二点五十，核对会结束。梁组长发来一份简报式结论（仍是内部）：

1）确认存在策略回滚事件：02:18回滚至M-SUPv2.9，回执SUCCESS；

2）确认存在热修复覆盖事件：转运前一日v3.1→v3.1-hotfix，操作者vendor_ops_07；

3）供应商拒绝提供：触发规则ID抄录、登录IP明细、中继记录；

4）监管制作笔录并要求供应商盖章确认“已查阅”；

5）原医院信息科承认托管模式，称无相关账号控制权。

林昼看完简报，第一反应不是兴奋，而是警惕：这份简报意味着结构被撕开了一道口。口一撕开，旧版照做的刀就会变得更锋利。他们会立刻做三件事：

*强化“自动化应急”叙事，把回滚解释成故障处置；

*追查内部匿名线索提供者，以“泄密”封口；

*反向污名化证人，把护士长写成“配合外院串联”、把许景写成“焦虑失常”、把陈某某写成“流程不严”。

他给梁组长回：“今天拿到的不是结论，是‘行为存在’。下一步必须把‘自动化应急’拆解为‘规则与授权’：谁设规则、何时生效、为何触发、谁可审批。供应商拒绝字段要继续追问并固化为‘拒绝提供’记录。并立即加强匿名人保护，泄密排查会升级。”

梁组长回：“他们已经开始排查。匿名人暂时断联。我们准备由监管发函要求停止针对协助人员的报复性调查。”

林昼回：“发函要写清：协查调取与监管笔录合法，任何以泄密名义打击协助者可能构成妨碍调查。”

梁组长回：“收到。”

---

下午三点，原医院与供应商联合发布一份“技术说明”——比昨天那份更长，更专业，充满术语：

*回滚属于“高可用架构下的自动化故障转移”

*v2.9为“稳定策略基线包”，用于保障业务连续性

*v3.1-hotfix为“安全补丁”，用于修复已知风险