上午九点五十二，住院部的电梯门“叮”一声合上。

林昼站在电梯里，手里攥着一份打印的《进场取证流程与证据保全要点》，纸张边缘被他捏得微微起皱。电梯镜面里映出他的眼睛――红，但不乱；疲惫，但很清醒。

今天取证审计机构进场。

这不是“会谈”，不是“核对”，也不是“整改沟通”。这是把一切从叙事里拽出来，放到证据桌上：代码、日志、权限、token、调用链、审批链、时间戳。所有人都可以说话，但只有系统会按自己的方式说真话。

他在电梯里看了眼手机：梁组长发来的消息只有一句――“十点整，进场，监管与平台见证，先封存权限系统。”

“先封存权限系统。”

这句话像一道闸门，意味着今天第一刀不是查故事，而是查钥匙。钥匙在哪里，谁握着，谁就能改变故事。

电梯到一楼，门开，林昼出门时迎面碰到接收医院信息安全负责人。他一贯的沉稳今天更像一层薄铁：“你来得正好，审计机构已经到会议室。我们先把医院侧的控制账号值班机制确认下来，防止供应商借口‘你们不在线’走歪路。”

林昼点头：“别给他们口子。”

对方看了他一眼，没有多问，只说：“你去看你父亲了吗？”

林昼一怔：“刚看过，状态不错。”

“那就好。”信息安全负责人说完，转身往行政楼走。

林昼跟上去，走廊里消毒水味道被咖啡味冲淡，像两种秩序互相覆盖：病房的秩序是生命维持，行政楼的秩序是规则维持。今天，规则要开刀。

---

十点整，会议室的门关上。

审计机构来了四个人：带队的取证负责人姓周，身形瘦，眼神却极稳；两名技术取证员负责系统镜像与日志采集；一名法证记录员负责全程笔录与哈希记录。监管两名人员到场见证，第三方平台协查联系人也在场。供应商坐在对面一排，合规负责人、技术负责人、流程管理专员都在，脸色比前几天更紧。

周负责人开场没有寒暄，只把一张纸放到桌上：“这是取证授权与范围。今天的顺序固定：第一，封存权限与签发系统；第二，封存代码仓与编排系统；第三，封存日志与审计库；第四，现场重放关键时间段的调用链。每一步完成后计算哈希，见证方签字。”

供应商合规负责人立刻开口：“我们配合，但涉及商业秘密的代码审阅希望限定在封闭环境，不允许复制。”

周负责人点头：“封闭环境可以，但‘不复制’只限于不对外扩散。取证需要形成证据副本，否则无法完成法证链。我们会按约定对副本进行加密封存，哈希记录在案，存放在监管指定介质。你们的商业秘密诉求不影响证据保全。”

监管补了一句：“这是取证，不是咨询。请配合。”

一句话，供应商的“条件”就被压回程序里。

周负责人看向第三方平台协查联系人：“请你们先提供平台侧已保全的审计事件原始记录，包括两次撬锁拒绝、历史成功关围栏事件、以及高权限token异常刷新摘要。我们要把这些作为对照基准，防止租户侧提供材料后改写叙事。”

第三方平台协查联系人立即打开只读介质，递出一个加密u盘：“已加密封存，密钥按监管要求分段管理。这里有三份：audittrail原始导出、api调用轨迹、版本链哈希证明。每份都带sha-256清单。”

周负责人当场插入法证工作站，计算哈希，屏幕上滚出一串长字符。法证记录员逐字抄录，监管人员在抄录旁签字，第三方平台协查联系人也签字。桌面上出现第一条铁证链：先固定对照，再动被审计方。

林昼坐在旁边，没说话，只看着那串哈希。它像冰一样冷，却也像门闩一样牢。门闩一旦卡上，谁都不能说“你改过”。

---

第一步：封存权限与签发系统。

周负责人对供应商技术负责人说：“打开你们的iam与token签发后台，只读权限登录。我们要做系统级快照：账号列表、角色定义、scope绑定记录、token签发与刷新日志。重点：itops_superadmin、svc_route_admin、itil_admin，以及routehealthguardian相关的凭据与token。”

供应商技术负责人深吸一口气，登录系统。页面一开，周负责人第一眼就问：“时间同步状态在哪里？”

对方愣了一下：“在系统设置里。”

“打开。”周负责人说，“我们要ntp状态、时间源、偏差记录。后续任何时间戳争议，先从这里解决。”

供应商照做。屏幕显示时间源正常，偏差在毫秒级。周负责人点头：“记录。”

法证记录员写下：ntp同步正常，偏差毫秒级。以后任何“系统时钟不准”的说辞都难以成立。

接着，周负责人要求导出itops_superadmin账号的授权范围。页面上赫然列出多项敏感权限：geofence.write、freeze.controlwrite、routingpolicy.admin、token.issuehighscope。旁边的“失效时间”一栏空着，写着“长期”。

周负责人抬眼看供应商合规负责人：“长期权限，为什么不设失效？季度复审在哪里？”

合规负责人试图解释：“历史遗留，之前用于应急保障。”

周负责人没接话，只对技术取证员说：“截图固化，导出原始记录，计算哈希。”

很快，权限记录导出成json与csv两份，哈希写进笔录。每一条“长期”都从文字变成证据。

随后，周负责人调出token签发日志，定位到第三方平台提示的“冻结启用前一小时异常刷新”。日志里果然存在：同一来源ip两分钟内三次签发高权限token，scope一致，reasoncode为空，approvalref为空，签发账号显示为itops_superadmin下的一个子凭据。

周负责人问：“这个子凭据是谁创建的？创建时间？审批引用？用途？”

供应商技术负责人额头渗出细汗：“可能是自动化组件使用的服务凭据。”

“可能”不被取证接受。周负责人语气仍稳：“不是可能。导出该凭据的创建修改使用轨迹。我们要看到创建者账号与时间戳，看到是否存在审批引用。若审批引用为空，记为权限控制缺陷。”

导出开始。系统里跳出一个字段：credentialcreator=itil_admin，创建时间为凌晨0403，备注写着“tokenrefreshfix”。

凌晨0403。

林昼的呼吸停了一瞬。0403在那张补录申请单0412之前。补录发生前，先补了一个“tokenrefreshfix”的凭据。这个顺序不像修复，更像铺路：先把钥匙磨好，再写申请单，再说“误触发”。

周负责人显然也捕捉到了这个顺序，他没有做结论，只说：“记录。此凭据创建时间在补录单据前，存在关联嫌疑，后续与变更补录轨迹对齐。”

监管人员在笔录旁画了一个小小的圈。那一圈不是批注，是预告：这条线会被拉到最紧。

---

第二步：封存代码仓与编排系统。

周负责人让供应商打开代码仓管理平台，要求提供routehealthguardian组件的仓库只读访问。供应商合规负责人再次强调商业秘密，周负责人仍是那句话：“封闭环境可谈，证据副本必须保全。”

取证员把代码仓镜像到法证介质，生成快照哈希。快照完成后，周负责人说：“现在我们做两件事：一，看关键函数；二，看关键提交历史。先从关键函数开始。”

技术取证员在封闭环境中打开仓库，搜索关键词：geofence、freeze、controller、auto_recovery、apac、priorityboost、probewindow、triggersensitivity。屏幕上连续跳出匹配行，像一串密集的心电图。

周负责人指着其中一个文件名：“recovery_actions.py？”

取证员打开。文件顶部注释写得很直白：

“当区域延迟劣化等级≥l3，执行自动恢复策略以保证投递成功。”

下面是一段函数：

*detect_latency_degradation(level)

*iflevel>=l3

*disable_geo_fence()

*boost_fallback_priority(region="apac")

*reduce_probe_window(minutes=5)

*set_trigger_sensitivity("high")

“disable_geo_fence()”“boost_fallback_priority(apac)”“reduce_probe_window(5)”――这三行像三把刀，把供应商之前所有“模板告知”“紧急保障”“误触发”剥成了代码事实：它不是“健康检查”，它是“自动执行**险策略”。并且执行顺序与转运当夜的关键点高度一致：缩短窗口、高敏感、apac优先级提升。

供应商技术负责人想说话，周负责人先按住：“先别解释。我们要看这段代码是否存在审批引用检查、禁变窗口检查、冻结检查。”

取证员往下滚。代码里有一个“approval_ref”参数，但默认值为none，并且有这样一行：

“ifapproval_refisnonelog_warning('approvalrefmissing');proceed_if_auto_recovery_enabled()”

也就是说，审批引用缺失并不会阻止动作，只会写一条warning，然后继续执行，只要“自动恢复开关”是开启的。

周负责人抬眼看供应商合规负责人：“你们的自动恢复开关在哪里？谁能开？什么时候开的？医疗客户默认开还是默认关？”

合规负责人声音发紧：“默认是开，用于提升可靠性。”

周负责人没有提高音量，却更冷：“医疗关键系统默认开一个能关围栏、改优先级、缩短窗口的自动恢复。你们认为这叫可靠性？”

供应商合规负责人说：“这是行业通行做法。”

第三方平台协查联系人立即补了一句：“平台建议此类**险动作必须受控，至少需要审批引用与禁变窗口约束。平台提供强制配置能力，租户未启用。”

周负责人点头：“记录为‘可控未启用’。”

可控未启用，等于选择。

随后，周负责人让取证员继续检索“freeze.controlwrite”。取证员在另一个模块里找到了一段代码，功能是“在恢复动作受阻时尝试调整控制权”：

“iffreeze_blocks_action

try_refresh_token(high_scope=true)

try_change_controller_to_tenant_admin()”

这段逻辑几乎就是昨天下午两次撬锁尝试的代码对应。也就是说，“撬锁”不是误触发按钮，它是写进恢复策略里的“第二条路”：第一条路关围栏、提apac、缩窗口；如果冻结挡住了，就尝试刷新高权限token，再尝试把冻结控制权改回租户。

这不是慌乱的误操作，这是设计。

设计意味着预谋：他们预想过医院会冻结，预想过冻结会挡住动作，于是写了绕行逻辑。只不过这次被平台降级拦住，没成功。

周负责人对法证记录员说：“标记：存在绕过冻结的逻辑路径，属于严重安全风险。并且与平台拒绝事件时间戳一致，形成闭环。”

监管人员的笔尖停了一下，写下“严重安全风险”五个字。写下去，性质就变了。

---

第三步：封存日志与审计库。

周负责人要求供应商提供编排系统（cron作业平台）的任务定义导出，包括触发条件、参数、执行身份。供应商技术负责人打开编排系统，routehealthguardian的任务赫然列在列表里：每分钟一次健康检查，触发阈值可配置，动作开关可配置。关键配置项里有一条：

“autorecoveryenabled=true

medicaltenantoverride=true

emergencyassurancemode=enabled

fallbackregion=apac

probewindow=5(whendegradation>=l2)”

“medicaltenantoverride=true”。

林昼看到这个字段，手指轻轻收紧。他意识到一个更尖锐的问题：这套**险自动恢复并不是对所有租户一样，它有“医疗租户覆盖模式”。覆盖意味着特殊，特殊意味着人为选择――有人把医疗租户放进了一个“更激进”的自动恢复模式，理由可能是“可靠性”，但结果是跨区、缩窗口、高敏感，等于把风险拉得更近。