打通登记的是一条弱口令：第三方接入凭证才是真实边界
一、”谁能访问我们”这个问题通常只答了一半
据公开报道，一个国家级人口登记系统被未授权访问了三周上下才被发现，入口不是被攻破的加固边界，而是一家持有合法访问权限的小公司手里的管理员账号，报道还提到该账号的口令强度近乎不存在，被获取的居民信息规模以百万计。这些数字在本篇里只作为背景出现一次，不作为任何一条判断的依据；真正可复用的是它的形状：攻击没有穿过防线，它走的是防线自己发出去的钥匙。
多数组织回答”谁能访问我们”的时候，只盘了第一跳。员工账号、直连接口、对外服务的认证方式，这几项在资产管理系统里有表、有负责人、有周期复核。而供应商、代运营、外包运维、驻场实施手里那份长期凭证，从来没有被当作”我们自己的资产”来登记。它挂在对方的管理责任下，写进合同的保密条款里，于是所有人都以为它被管着。
有三种自我说服最常见。一是”那是对方公司的账号体系，他们自己管”，问题在于这个账号能进你的库，管不住对方的内部流程不等于你不需要补偿控制。二是”只是只读权限，风险有限”，只读大批量导出在事件里的损失和写入并不差多少。三是”合同有保密与合规条款”，条款处理的是事后追责，不处理事前发现。这三条的共同点是：它们都假设存在某个地方有一份完整的清单。而实际做法应该是把访问链本身当作一类资产来登记，字段齐不齐是能被检查的。
二、把访问链当资产：台账要有的字段
这份台账不需要复杂系统支撑，一张表就够，但字段必须一次定全，缺一个字段后面所有动作都落不下去。下面这张表是我们做第三方接入治理时的字段形状和它各自的用途。
| 字段 | 为什么必须有 | 常见缺失后果 |
|---|---|---|
| 外部主体标识 | 记录法人名称、对接责任人与联系方式，主体不唯一时按角色分行 | 出事后找不到”这家公司的账号到底是哪几个” |
| 持有的入口标识 | 系统、接口、账号名逐项列出，一个主体多份凭证就列多行 | 只登记了主接口，遗留的调试入口与报表接口无人认领 |
| 认证方式与口令强度基线 | 记录是否多因子、是否可被本方强制改名、由谁轮换、轮换周期 | 默认口令长期不改，撞字典成功与否完全取决于运气 |
| 可达范围到字段级别 | 不止写”可读客户表”，要写能读哪几列 | 证件号、地址、结算信息与业务标记被同等对待 |
| 是否共享账号 | 一个身份被多人使用的情况必须显式标出 | 归因失败，处置只能整条断链 |
| 上一次登录与末次操作时间 | 判断该主体是否还有业务必要 | 项目结束半年，凭证仍然有效 |
| 活跃时段与使用用途 | 给异常检测提供历史基线 | 夜间批量查询无人觉得奇怪 |
| 退出方式 | 撤销路径、撤销所需时间、由谁执行 | 需要断链时找不到入口，只能停机 |
| 复核人、复核结论与下次复核触发条件 | 让”该访问”这个判断有主体和时间 | 复核变成安全部门自己打勾 |
字段里最容易做错的是”可达范围”。写”能看客户数据”的台账没有可操作性，必须落到视图与列。同一个代运营角色，读订单状态和读订单加收件地址加手机号，是两个完全不同的处置等级。字段级别还决定了事件发生后能不能缩小受影响范围——这一点在第六节会回到。
另一处容易忽略的是台账的归属行。这张表不能只挂在安全岗，每一行必须有一个业务侧的负责人，因为”这个主体为什么需要访问”只有业务侧答得出。安全岗能做的是检查行的完整性，不是判断行的必要性。
三、共享账号的四个必然后果
多人共用一个身份，是第三方接入里最普遍也最被低估的做法，因为它的成本在出事时才发生。四个后果是结构性的，不取决于运气。
- 无法归因到人。日志里只有账号名，事件报告写不出”谁在什么时刻做了什么”，只能整条链路一起处理。
- 无法按人撤销。一个对接人员离开，你不能从共享账号里把他摘出来，唯一办法是改口令，而改口令要通知所有还在用的人。
- 口令变更时协同失效。改密意味着正在跑的定时任务、脚本里硬编码的凭据、同事之间的转发全部要同步更新。这个协调成本高到让双方都倾向于不改——弱口令能长期存活的经济原因就在这里，而不是因为对方粗心。
- 离职后残留。凭据一旦进过共享文档、个人笔记和聊天记录，它就不再受任何一方的控制。你能撤销账号，撤不回已经扩散的文本。
前三条指向同一个结论：对外部主体发放的身份，一个主体一份，是唯一能让后续所有治理动作可执行的前提。做不到”一份身份一个人”的场合，就得在别的地方补偿，比如把接入点收敛到跳板机上。
四、口令策略管不到别人手里时的四档替代
要求一家十几人的供应商实施企业级口令策略，是不现实的，也不该是交付的验收条件。可行的做法是在自己这一侧把补偿控制做完。四档按侵入性从低到高：
- 强制改名并纳入监控。把交付时的默认账号名改掉、禁止沿用初始口令，同时把这个账号的每一次登录变成可观测事件。改名挡不住定向攻击，它的价值是让通用字典失效、让”这个身份被使用了”这件事进入日志。
- 拆出独立子账号并按最小字段授权。给每个外部主体单独的身份，权限按视图和列裁剪，只给它当日任务需要的列。这一档改造的真实成本不在权限模型，在映射关系——业务上常常是一个角色对应多家外部主体，系统里却没有”角色到主体”的表达。
- 要求专用跳板接入。不允许从对方办公网直连，接入点收敛到本方控制的跳板，会话可录屏、可打时间戳。它同时解决归因与扩散：共享账号即使存在，也从固定的、有记录的入口进来。
- 一次性临时凭证替代长期账号。按工单申请、限时限次、到点自动失效。这一档运维成本最高，适合低频维护与实施类场景；高频日常对接（对账、内容代运营）走第二档加第三档的组合更划算。
选档的判断依据是访问频次与可达范围，不是对方的规模或名声。判断标准可以写成一句话：可达字段越接近个人标识与资金要素，越不允许长期账号存在。
五、”能访问”与”该访问”要分开确认
台账建完，第一件要做的事是权限复核，而复核最容易犯的错是把两件事合成一件：把”这个账号确实还有访问权限”当成”这个账号还需要访问权限”。前者是资产核对，后者是业务必要性判断，必须由不同的人做。
复核的动作按行进行，每行问三个问题：过去一个季度有没有真实的使用记录；可达范围是不是当初按最小需求配的，还是随功能叠加越来越宽；如果今天把它断掉，哪个流程会停。第三个问题最有价值，答不上来的行就是可以清理的行。
留痕的最低要求是结论挂到具体的人和时间。”经业务部门确认可以保留”这种文字在审计里等于没确认，必须写明确认人姓名与岗位、确认时刻、结论对应的处置（保留、收窄、到期撤销、转临时凭证）、下一次复核的触发条件。
周期按主体的可达范围分级，字段级含个人标识的走最短周期；除周期触发之外，四类事件必须立即重跑：对方对接人员变更、接口或数据结构变更、合同续签、以及任何一次异常告警之后。最后一类最容易被省掉，出过一次事的主体，其复核不该等到下一个周期。
六、为什么三周没人发现，以及发现之后先做什么
长期不被发现通常有三个原因。第一，监控压在互联网边界上，第三方通道走的是内部端口，日志量小但不在任何一条告警规则里。第二，日志量大而没人查，指望人工翻日志不成立，必须换成异常检测，而异常检测依赖历史分布——这就是台账里”活跃时段”和”上次登录”那两行的用处。第三，缺少行为基线，没人知道这个账号”正常”一天查多少次，所以查了五千次也不显得异常。
在此基础上，可落地的最小监测集只有五条，它们共同的特征是都不需要买新设备：异常时段登录，按主体历史活跃窗口判定；单会话批量查询超过该主体历史分位；导出量超出历史量的量级变化；首次出现的访问目标，即某个身份第一次访问一张它从未碰过的表或模块；共享账号的并发登录。五条里”首次出现的访问目标”性价比最高，因为它几乎不产生误报。
真的发现异常之后，动作顺序比动作内容更容易出错。要固定留证的时间点包括：认证事件、首次异常查询、首次批量导出、告警触发、断开时刻、通知对方与对方确认的时刻，并且这些时间必须来自同一套服务端时钟——双方各自拿本地时间对账，一定对不平。受影响范围的界定要用交叉而不是包含：以”该主体可达的字段”乘”时间窗内真实访问到的记录”为准，不能因为它有权限就把全部数据算进去，也不能反过来只算被导出的那部分。通知口径要提前写成模板，区分可陈述的事实、进行中的判断和尚未确认的推断三档，避免事件当天把猜测写进对外说明。
最难的一步是双方记录不一致。供应商会说”我们的同事那几天没人登录”，而服务端日志显示该账号在活动。对账的做法是要求对方提供其侧的接入来源、设备与人员名单，与我方的会话记录逐条比对，比对结果无论一致与否都写进事件报告；不要接受电话里的口头一致，因为下一次事件又要从头争。洹拓在项目里把这一套收敛成三份交付物：第三方接入主体台账、按最小字段的授权改造清单、异常访问最小监测集。三份都在项目启动阶段做完才谈得上后面的加固，因为它们的共同前提是你知道链条上一共有几把钥匙。