凌晨三点四十七，行政楼走廊的灯一盏接一盏亮着，像一条被迫清醒的脊柱。

林昼靠在法务室门口的墙边，手里握着一次性纸杯，杯沿已经被指腹磨出一圈湿痕。他没喝水，只是在等――等监管的“下一步”落下来。

取证进场之后，事情不会立刻结束，反而会进入一个更危险的阶段：证据已经被固定，但解释还没落地；权柄已经被点名，但回收还没执行；暗门已经被写字，但拆门要动刀。

动刀的时候，最容易出血。

手机震了一下，屏幕跳出梁组长的消息，只有八个字：

“保全令已下，立即执行。”

林昼的后背像被什么轻轻推了一下，站直了。

保全令不是一张纸，它是把所有“再改一改”“再补一补”“再清理一下”都变成违法成本的开关。它会把供应商所有想用“误操作”“历史遗留”“我们马上整改”抹平的空间，压缩成“你现在必须停手”。

他把消息转给接收医院法务与信息安全负责人，法务只回了一个“收到”，信息安全负责人回得更短：“上锁。”

“上锁”两个字，和他们这段时间一直在做的事一样：把规则写进系统，把开关的主人换回来。

四点零五分，监管正式文件在工作群里下发，标题冷硬：

《证据保全令（临时）》。

正文条款写得很具体，像一份把手伸进系统内部的手术指令：

1）供应商立即停止对相关租户的任何代码仓强制推送、历史重写、权限模型变更；

2）立即冻结并封存itops_superadmin、itil_admin及其所有子凭据；冻结期间禁止任何高权限token签发与刷新；

3）routehealthguardian组件“自动恢复”功能必须立刻切换为“只读监测”模式，不得执行geofence、freeze、priority、probewindow相关动作；

4）所有相关日志、审计库、编排任务配置、代码仓操作日志、备份快照，必须在监管指定介质上加密封存，哈希固化；

5）任何妨碍取证、施压证人、要求签署限制陈述事实声明的行为，纳入不配合记录并触发更严肃程序。

每一条都像钉子，钉在供应商的手背上：你不能再摸开关。

供应商合规负责人第一时间回复：“我们理解并配合。但若routehealthguardian切换为只读监测，将增加投递延迟与失败风险，建议保留自动恢复的部分能力。”

监管没有与他争辩，只回了一句：“风险评估以证据为准，执行以保全令为准。”

这句话等于把供应商最惯用的恐吓话术直接关门：你可以说风险，但你必须在规则里说。

第三方平台协查联系人随后补充了一条更关键的技术通告――不是建议，而是动作：

“平台已对该租户启用强制策略：禁止高危scope签发；geofence与freeze控制项进入双重签名锁定；任何涉及围栏冻结优先级窗口的api请求将返回拒绝码并记录。”

这意味着即便供应商不配合，平台也会把门闩插到底。制度不再依赖对方的自觉，而依赖系统的拒绝。

林昼看着“拒绝码并记录”六个字，心里反而更紧。他清楚，门闩插到底之后，供应商能动的地方就会从“系统”转向“人”。

他们会去找医院内部的“松动点”。

早上七点，医院内部突然出现一份“系统稳定性提示”。

发文部门是原医院信息科，措辞看似中立：由于近期外部监管整改要求，部分服务策略调整可能引发邮件排队延迟，建议临床科室尽量减少大附件发送，重要通知同步采用电话im确认。

它没有点名供应商，没有点名禁变窗口，但它把所有不便都提前投递到临床，让焦虑先行。

焦虑一旦扩散，制度就会被迫做“妥协解释”。

接收医院信息安全负责人看到这份提示后，第一时间做了两件事：

第一，拉起一份“临床沟通保障方案”――把重要通知分级，关键通告走院内专线与双通道，邮件只作为留痕与备份；对重要科室开通内部白名单广播，减少对外链路依赖。

第二，在院内公告里只写事实：保全令要求禁用高危自动恢复，目的是防止关键期出现不可控策略；目前监测到延迟波动在可控范围内，已有替代通道，临床无需恐慌。

公告没有指责任何一方，没有渲染风险，只有“分级”“通道”“可控范围”几个词，把焦虑从情绪拉回流程。

林昼看到公告的第一反应不是松一口气，而是更警觉：对方一定会换一种方式制造“不可控”。

不可控最容易发生在夜里。

上午十点，取证审计机构周负责人再次到场，携带两名取证员进行“保全令落实核查”。

他们不再看代码细节，而是看“动作是否发生”。

供应商需要当场完成三件事：

1）在编排系统里将routehealthguardian所有恢复动作开关置为off；

2）在iam里冻结itops_superadmin与itil_admin及其所有子凭据，并导出冻结事件；

3）在代码仓上锁：禁止forcepush、禁止历史重写、开启强制审批与签名提交。

这三件事，不靠承诺，靠审计事件。

供应商技术负责人操作时手都在出汗。编排系统里“autorecoveryenabled=true”的那一行被改成false，点击保存时系统弹出审计提示：需要approvalref。

这一次，他们不得不填。供应商填了一个编号，周负责人让法证员抄录，然后立即导出变更前后配置快照，计算哈希。每一个开关的关闭，都变成可复核的证据。

冻结账号时更有戏剧性。

itops_superadmin冻结成功，事件写得干净：冻结者、时间戳、原因、审批号，都齐了。轮到itil_admin时，系统弹出提示：“该账号近24小时发生异常登录尝试，风控建议立即锁定并触发二次核验。”

周负责人没有评论，只让取证员把异常尝试的原始字段导出：来源ip、时间戳、失败原因。

异常来源ip不在供应商办公网段，像从某个外部网络跳进来，尝试失败了三次。

供应商合规负责人赶紧解释：“可能是账号泄露，我们会内部排查。”

周负责人看着他：“你们的账号是否泄露，属于你们安全管理问题。现在的问题是：在保全令下发后，仍有人尝试触碰关键账号，这说明风险仍在。我们会把这条异常尝试纳入阶段报告。”

异常尝试被写进报告，意味着“有人仍想拿钥匙”。

有人是谁，下一步就会被追。

中午十二点半，供应商提交了“24小时解释材料”的第一版。

材料厚，结构也像模板：背景、目的、历史遗留、行业惯例、现已整改、保证不再发生。可周负责人只问四个问题――也是林昼一直强调的“四链”：

1）审批链：谁批准了medicaltenantoverride？批准文件在哪里？

2）授权链：谁批准routehealthguardian持有geofence.write与freeze.controlwrite？

3）运行记录：过去六个月该脚本执行过多少次高危动作？成功多少、失败多少、拒绝多少？

4）回收证据：你们说已回收scope与凭据，回收事件在哪？时间戳与哈希在哪？