第四十九章：取证进场(1/4)

首发：~第四十九章：取证进场

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

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

今天取证审计机构进场。

这不是“会谈”，不是“核对”，也不是“整改沟通”。这是把一切从叙事里拽出来，放到证据桌上：代码、日志、权限、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，备注写着“tokenrefreshfix”。

凌晨04:03。

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

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

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