三点速览

1. 不可回收。 账号密码是可以被复制的。交接一次、代班一次、写进一个便签一次，副本就多一份。回收动作只能作用于你知道存在的那一份。
2. 无人确认失效。 对接人调岗或离职时，通常没有人负责去问对方”把这个账号停掉”——因为账号是外部企业发放的，本方的离职流程管不到它。
3. 没有审计对象。 一个账号被多个人用过之后，日志里只剩账号名。发生泄露或纠纷时，”是谁在什么时候用它做了什么”这个问题在技术上已经无法回答。

为什么会这么做

先承认它的合理性——这种做法之所以普遍，是因为在当时它确实是最快的选择。

客户或主机厂发来一组账号，要求本周开始按目录投放文件。IT 手上没有现成的中转机制，业务那边下周就要交付。把账号转给对接人，当天就能跑起来。任何一个替代方案，只要需要三天以上的准备，都会输给这个选择。

所以这一页讨论的不是”当初不该这么做”，而是：在已经这么做了之后，风险积累到哪一步，以及怎么在不打断业务的前提下把它收回来。

下放之后发生了什么

一份凭据下放之后，通常会沿着这条路径扩散：

变动阶段是不可逆的转折点。到这里，这份凭据的边界已经不再由本方掌握。后面每一天都在累积一个无法量化、但一旦触发就是集中爆发的敞口。

追责阶段的性质则更麻烦一些：它不是”安全措施不够强”，而是”缺少可归属的主体”。任何审计与追责机制都要先有一个对象，共享账号恰好把这个对象抹掉了。

凭据收口之后的同一条路径

平台的做法是把凭据从人手里挪到平台里，业务侧的使用体验不下降，但凭据本身不再流动：

关键差别在第二行：业务人员不接触凭据，不是靠制度约束，而是因为平台不提供获取它的路径。

→ 外部账号与密钥集中托管
→ 业务人员不接触外部凭据的交换方式

完整对照表

表格最后两行是这件事能推动的原因：收口凭据不要求对端做任何改变，也不要求更换现有的 FTP 服务器或对象存储。
→ 零迁移纳管既有传输资源

各自的适用场景

不是每一个外部账号都值得走一遍收口流程。合理的分界是这样的：

一个可操作的判断：如果你现在说不出”这个账号一共有几个人知道”，它就已经越过了直接使用的边界。

怎么收口而不打断业务

收口不需要一次性完成，也不需要先改造现有系统：

1. 先建档。 把外部企业建立为合作伙伴，其联系人、账号与密钥登记到这份档案下。
2. 纳管原有端点。 既有的 FTP/FTPS/SFTP、SMB、对象存储纳管为该伙伴的伙伴库目录，数据不迁移、对端不改配置。
3. 挑一条流先接管。 建议选一条新增的或风险较高的业务流，原路径保留作为回退。
4. 验证稳定后再收权。 确认平台侧的取送与记录正常之后，再把原来分散在个人手中的凭据作废或轮换。
5. 逐步扩大范围。 按伙伴与方向配置收发策略，把人工取送转为规则驱动。

第 3 步与第 4 步的顺序很重要：先让平台跑起来，再回收凭据，这样任何一步出问题都还有原路径可退。

凭据集中之后，平台本身的安全性会成为下一个被追问的问题——这是应当被提出的问题，我们把它单独写了一页：
→ 外部凭据托管的安全设计与评审配合

行业里的典型交换结构 → 汽车与零部件行业文件安全交换