第四十九章：取证进场
上午九点五十二，住院部的电梯门“叮”一声合上。
林昼站在电梯里，手里攥着一份打印的《进场取证流程与证据保全要点》，纸张边缘被他捏得微微起皱。电梯镜面里映出他的眼睛——红，但不乱；疲惫，但很清醒。
今天取证审计机构进场。
这不是“会谈”，不是“核对”，也不是“整改沟通”。这是把一切从叙事里拽出来，放到证据桌上：代码、日志、权限、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，创建时间为凌晨04:03，备注写着“token refresh fix”。
凌晨04:03。
林昼的呼吸停了一瞬。04:03在那张补录申请单04:12之前。补录发生前，先补了一个“token refresh fix”的凭据。这个顺序不像修复，更像铺路：先把钥匙磨好，再写申请单，再说“误触发”。
周负责人显然也捕捉到了这个顺序，他没有做结论，只说：“记录。此凭据创建时间在补录单据前，存在关联嫌疑，后续与变更补录轨迹对齐。”
监管人员在笔录旁画了一个小小的圈。那一圈不是批注，是预告：这条线会被拉到最紧。
---
第二步：封存代码仓与编排系统。
周负责人让供应商打开代码仓管理平台，要求提供RouteHealthGuardian组件的仓库只读访问。供应商合规负责人再次强调商业秘密，周负责人仍是那句话：“封闭环境可谈，证据副本必须保全。”
取证员把代码仓镜像到法证介质，生成快照哈希。快照完成后，周负责人说：“现在我们做两件事：一，看关键函数；二，看关键提交历史。先从关键函数开始。”
技术取证员在封闭环境中打开仓库，搜索关键词：GeoFence、Freeze、Controller、AUTO_RECOVERY、APAC、PriorityBoost、ProbeWindow、TriggerSensitivity。屏幕上连续跳出匹配行，像一串密集的心电图。
周负责人指着其中一个文件名：“recovery_actions.py？”
取证员打开。文件顶部注释写得很直白：
“当区域延迟劣化等级≥L3，执行自动恢复策略以保证投递成功。”
下面是一段函数：
* detect_latency_degradation(level)
* if level >= 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，并且有这样一行：
“if approval_ref is None: log_warning('ApprovalRef missing'); proceed_if_auto_recovery_enabled()”
也就是说，审批引用缺失并不会阻止动作，只会写一条warning，然后继续执行，只要“自动恢复开关”是开启的。
周负责人抬眼看供应商合规负责人：“你们的自动恢复开关在哪里？谁能开？什么时候开的？医疗客户默认开还是默认关？”
合规负责人声音发紧：“默认是开，用于提升可靠性。”
周负责人没有提高音量，却更冷：“医疗关键系统默认开一个能关围栏、改优先级、缩短窗口的自动恢复。你们认为这叫可靠性？”
供应商合规负责人说：“这是行业通行做法。”
第三方平台协查联系人立即补了一句：“平台建议此类**险动作必须受控，至少需要审批引用与禁变窗口约束。平台提供强制配置能力，租户未启用。”
周负责人点头：“记录为‘可控未启用’。”
可控未启用，等于选择。
随后，周负责人让取证员继续检索“Freeze.ControlWrite”。取证员在另一个模块里找到了一段代码，功能是“在恢复动作受阻时尝试调整控制权”：
“if freeze_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 (when degradation>=L2)”
“MedicalTenantOverride=true”。
林昼看到这个字段，手指轻轻收紧。他意识到一个更尖锐的问题：这套**险自动恢复并不是对所有租户一样，它有“医疗租户覆盖模式”。覆盖意味着特殊，特殊意味着人为选择——有人把医疗租户放进了一个“更激进”的自动恢复模式，理由可能是“可靠性”，但结果是跨区、缩窗口、高敏感，等于把风险拉得更近。
周负责人问：“MedicalTenantOverride是谁配置的？什么时候配置的？有哪些租户ID在列表里？”
供应商技术负责人低声说：“这个需要查配置库。”
“查。”周负责人说，“现在查。配置库导出，哈希固化。”
配置库导出很快完成，里面是一串租户ID列表。监管人员看着列表，眉头皱起：“这批ID里包含原医院的租户。”
会议室里空气像被抽走了一部分。供应商合规负责人试图解释：“医疗租户对投递及时性要求高，所以策略更积极。”
周负责人不做道德评判，只问：“更积极的策略是否评估过跨区与禁变窗口风险？是否告知过医院？是否有审批与签署？”
供应商沉默。
沉默比争辩更响。没有审批，没有签署，没有告知，那么“更积极”就是单方面决定。单方面决定在医疗场景里不叫服务优化，叫风险外溢。
取证员继续抽取关键时间段日志：转运当夜18:00到06:00。日志里出现一条条“degradation detected”“auto recovery triggered”。周负责人让取证员把19:08前后五分钟的记录截取出来，与之前audit_export对齐。
19:07:58，日志写：Latency L2 detected（CN relay）。
19:08:03，auto recovery triggered（MedicalTenantOverride）。
19:08:08，reduce probe window -> 5。
19:08:11，set trigger sensitivity -> High。
19:08:13，boost fallback priority -> APAC。
19:08:15，change applied。
这串时间戳像一条极短却极硬的鞭子，把“人为审批”与“系统自动执行”绑在一起：19:08:13在audit_export里已经出现过；现在日志证明它不是“某个人点了一下”，而是脚本按检测结果自动触发。审批角色OpsMgr可能存在，但更关键的是：执行链已经自动化，且处于医疗覆盖模式。
供应商合规负责人终于忍不住：“这只是自动调整参数，不等于跨境传输，也不等于数据出境。”
周负责人看着他：“我们今天不讨论法律结论。我们只讨论事实链：你们的脚本在未完成审批引用、未绑定禁变窗口、未告知确认的情况下，自动把回退优先级指向APAC，并缩短探测窗口、提高敏感度。事实成立，风险评估与告知义务就要重新计算。至于法律结论，由监管决定。”
监管人员点头：“事实链已记录。”
林昼在旁边听着，胸口像被压住，但同时又有一种奇怪的松动——松动来自于“事实终于完整”。完整意味着不再需要靠猜。猜测是最耗人的东西，事实反而能让人喘气。
---
中午十二点半，取证暂停，大家短暂休息。供应商的人走出会议室时明显在打电话，声音压得很低，但能听到“统一口径”“别乱说”几个词。
周负责人没有阻止，只对监管人员说：“建议监管同步下发‘禁止施压与反报复提醒’，尤其针对证人和内部人员。取证期间出现一致性声明或封口要求，会影响证据可信度。”
监管当场发了一条指令给供应商：“取证期间不得要求员工签署任何限制陈述事实的声明，不得以纪律处分威胁配合调查人员。违者纳入不配合记录。”
“写字让人不敢胡来。”林昼想起父亲的话。监管把提醒写出来，至少能让对方收敛一点。
---
与此同时，另一个战场在原医院的人事谈话室。
许景按约到了，接收医院法务安排了律师陪同。谈话开始时，人事负责人把一份《保密与一致性声明》推到桌上，语气像例行：“签一下，这是内部要求。签了我们再谈。”
律师立刻开口：“请问声明依据是什么？是否与监管取证冲突？声明是否限制陈述事实？”
人事负责人卡了一下：“这是保护医院与合作方商誉。”
许景按林昼给的模板，第一句就说：“我只陈述事实，不对结论作判断。任何要求我承认不当沟通的结论，我不签。”
人事负责人脸色变了：“你这是不配合。”
律师把监管刚下发的“禁止施压提醒”打印件放在桌上：“请注意，取证期间要求签署限制陈述事实的声明，可能构成不当施压。谈话可以继续，但不得以签署声明作为条件。”
人事负责人沉默片刻，最终把声明收回。谈话改成了问答，但每一个问题都被律师要求写进笔录。许景只回答自己做过什么、何时做、通过什么渠道提交给法务与监管。对于“你是不是故意对外泄露”，许景只说：“我通过医院法务与监管渠道提交材料，属于依法配合。其他不评价。”
谈话结束时，人事负责人想让许景在谈话记录上签“确认存在不当沟通”。许景拒签，只签“确认以上为谈话内容记录，不代表结论”。律师在旁边加了一句：“保留异议”。
笔录被带走，抄送监管。
许景走出谈话室时腿都在发软，但他没有倒。他知道自己没有赢，他只是没有被按下去。没有被按下去，证据链就不会断。
林昼下午收到法务的简报，只回了两个字：“做得好。”
这两个字不是夸奖，是确认：事实口径有效，施压落空。
---
下午两点，取证继续，周负责人进入“提交历史”审阅。
取证员把代码仓的提交记录拉出来，筛选关键日期：转运当日、以及补录发生的凌晨。列表里出现两个极刺眼的动作：
* 18:52，一次提交：commit message “hotfix: emergency assurance tuning”，修改了auto recovery阈值与FallbackRegion默认值。作者显示为一个普通工程账号。
* 04:05，一次强制推送（force push）记录：重写了部分提交作者信息与message，随后04:12出现补录申请单。
“强制推送”。
强制推送意味着有人尝试改写历史。代码仓不像区块链那样天然不可变，但企业级仓库会记录操作日志。只要有force push，就会留下痕迹。
周负责人问供应商技术负责人：“为什么凌晨04:05发生force push？谁执行？目的是什么？”
技术负责人明显慌了一下：“可能是清理敏感信息。”
周负责人冷冷问：“清理敏感信息为什么要重写提交历史？你们有事后补录申请单，且补录被认定存在疑点。现在又出现重写代码历史的操作，你们认为这会被如何解读？”
供应商合规负责人急忙插话：“这是工程管理行为，与事件无关。”
周负责人把问题钉回去：“我们不接受‘无关’。取证只看时间线与关联性：04:05重写历史，04:12补录申请单，且04:03创建token刷新凭据。三条线在十分钟内连续发生。你们需要给出可审计的解释：谁、为什么、依据何种流程、审批在哪里。否则记录为‘疑似证据污染行为’。”
“疑似证据污染”这六个字像砸在桌面上，会议室瞬间更安静了。监管人员没有说话，但笔已经开始写。
林昼的手心出汗。他明白这一刻意味着什么：供应商可能从“整改对象”走向“调查对象”。调查对象面对的不是整改清单，而是更严肃的后果。更严肃的后果会带来更极端的反扑。
周负责人像预判到了这种气氛，他没有继续刺激，只把下一步推进：“现在我们固定仓库操作日志与force push记录，导出原始字段并哈希。你们可以在后续提交解释材料，但今天先把证据固定。”
取证员导出日志，哈希生成，见证签字。历史被锁住了。
---
下午四点，周负责人开始重放“跨区回退优先级提升”与“冻结撬锁尝试”的调用链，把平台侧API轨迹与租户侧日志逐条对齐。
对齐结果很清晰：
* 19:08脚本触发提升APAC优先级、缩ProbeWindow、设高敏感；调用由svc_route_admin执行，但源头是RouteHealthGuardian。
* 16:22与16:23冻结后两次撬锁尝试，触发于“freeze blocks action”分支，先刷新高权限token，再尝试改Controller，均被平台拒绝。
* 冻结启用前一小时高权限token异常刷新，确实存在，且ApprovalRef为空。
* 三个月前成功关围栏事件，ApprovalRef为空，ReasonCode=AUTO_RECOVERY，触发为延迟劣化L3。
四条证据链合并后，一个轮廓变得异常清晰：这不是一套“临时救火”，而是一套长期存在的自动化权柄机制——以应急为名，持有超级权限；以恢复为名，牺牲边界；以效率为名，缺失审批引用；遇到冻结，就尝试夺回控制权。
这套机制存在的每一天，禁变窗口都只是“你希望它不要发生”；而冻结开关被按下之后，它就变成了“机制与机制的对抗”。
周负责人最后说：“取证阶段结论不做法律评价，但我们会在阶段报告里写明：存在**险自动化动作与权限过大问题；存在审批引用缺失情况下仍可执行的设计；存在试图修改冻结控制权的逻辑；存在疑似证据污染行为（force push重写历史）需进一步解释。”
监管人员接着补了一句：“供应商需在24小时内提交解释材料与整改措施。解释材料必须可审计，不得以口头替代。整改必须先收敛权柄，再谈效率。”
供应商合规负责人脸色很难看，却只能点头。
---
傍晚六点，林昼回到病房，父亲正坐在窗边晒一点落日余光。
父亲看到他，第一句仍旧是：“你今天吃了吗？”
林昼笑了一下：“吃了。真的。”
父亲不再追问，只说：“今天查得怎么样？”
林昼把话说得很短：“脚本不是误触发，它有一套自动动作，能关围栏、提APAC、缩窗口，还会在被锁住时试图把锁夺回来。取证把它写在纸上了。”
父亲沉默了很久，眼睛望着窗外的光：“那就危险了。”
林昼点头：“是危险。但危险写出来，就不再是暗的。”
父亲缓慢地说：“暗的最吓人。明的……还能防。”
林昼握住父亲的手：“我们现在能防。”
父亲轻轻回握了一下，声音低低的：“你别逞强。你只要让他们写字，写到他们不敢乱动就行。”
林昼应了一声，没有再多解释。他知道父亲要的不是技术细节，而是一个可依靠的秩序感：事情正在被写成字，而不是被压成沉默。
---
夜里十点，供应商发来一份紧急“解释草稿”，试图把force push说成“误操作”，把MedicalTenantOverride说成“保障名单”，把冻结撬锁逻辑说成“容灾自愈”。草稿里充满了“可能”“大概”“历史原因”“行业惯例”。
法务把草稿转给林昼，问他要不要逐句反驳。
林昼只回了一句：“不逐句。让他们把四样东西补齐：审批链、授权链、运行记录、回收证据。没有这四样，文字就是雾。”
法务回：“明白。”
林昼关掉手机，坐在走廊的长椅上，第一次真正感到一种近乎锋利的疲惫。不是因为事情太难，而是因为事情终于走到“必须承担后果”的阶段。承担后果的人会发疯。发疯的人会反扑。反扑可能更脏、更险。
但他也知道，取证进场的这一天，真正改变的是一个底层逻辑：从此以后，对方再说“误触发”，也要和代码对话；再说“紧急保障”，也要和权限清单对话；再说“行业惯例”，也要和审批引用缺失对话；再说“你们害的”，也要和force push时间戳对话。
话术仍会存在，但它的成本变高了。
他把今天的最后一条记录写进索引，笔尖划过纸面时发出轻微的声响：
* 取证进场完成：封存IAM/token/代码仓/编排任务/关键日志；固定19:08自动动作链；固定冻结撬锁逻辑；发现MedicalTenantOverride；发现04:05 force push疑点；要求补齐审批链与回收证据
写完，他合上本子，靠在椅背上闭眼。
黑暗里，他只剩一个清晰的判断：
“钥匙已经被点名，暗门已经被写字。接下来要看的，不是他们怎么解释，而是他们愿不愿意把钥匙交出来，愿不愿意亲手把暗门拆掉。”
(https://www.lewenn.cc/lw54513/41053812.html)
1秒记住乐文小说网：www.lewenn.cc。手机版阅读网址：m.lewenn.cc