外部账号与密钥集中托管 | Ftrans B2B
对外交换用的四类凭据收口到一处，业务侧只提交任务，不接触凭据。
一句话定义
外部账号与密钥集中托管，指企业与外部伙伴交换文件所需的全部凭据——伙伴的 FTP/SFTP 账号、对象存储 AK/SK、PGP 私钥、OFTP2 的协议身份与证书私钥——统一由平台保管与使用，业务人员在平台内提交交换任务并查看结果，全程不需要、也无法获取这些凭据。
它要解决的不是密码存在哪里的问题，而是在不把凭据交到人手上的前提下，交换动作照样能完成。
一、凭据是怎么散出去的
没有哪家企业一开始就决定把外部账号发给业务人员。它是一次一次“临时”发出去的：客户新开了一个 FTP 目录，采购部门要马上取图纸，账号先发过去；对方给了一组对象存储密钥，写在邮件里转给了负责对接的工程师；伙伴要求用 PGP 加密，私钥文件落在了某台办公电脑上。每一次都合理，每一次都没人回收。
到今天，典型状态大致是这样：
| 凭据类型 | 通常散在哪里 | 结果 |
|---|---|---|
| 伙伴的 FTP / SFTP 账号 | 对接人的浏览器、客户端配置、共享表格 | 人员变动后是否失效无人确认 |
| 对象存储 AK / SK | 邮件、聊天记录、脚本里的明文配置 | 复制一次即多一份，去向无法追踪 |
| PGP 私钥 | 某台办公电脑或某个共享目录 | 私钥一旦外流，加密通道整体失效 |
| OFTP2 的协议身份与证书私钥 | 服务器配置目录、对接工程师个人电脑 | 协议身份被冒用时，对端无法从报文上分辨真伪 |
伴随凭据分散的，通常还有另外几件事：有专人每天登录若干个外部系统取放文件；安全检查取决于经手人是否记得做；交换记录散落在各家外部系统里，被审计或发生纠纷时说不清“哪个文件、什么时候、谁发的、发给谁、对方取没取”。
这些问题的共同点是：它们不会导致系统瘫痪，因此长期被容忍；但一旦发生泄露、审计或纠纷，代价是集中爆发的。
二、为什么这件事一直没解决
不是没人想管，是四个现实约束卡在这里。
凭据下放是不可逆的。 账号和密钥的复制成本为零。一旦发出去，它可能已经躺在三个人的记事本、两台电脑和一份共享表格里。事后回收只能靠通知对方重置，而“到底流出了几份”这个问题，从设计上就无法回答。这也是凭据管理与其他 IT 资产管理最大的不同——它没有事后补救的路径，只有事前不发出去这一条。
现成的工具解决的不是同一件事。 企业网盘围绕的是人员之间的协作——保存、分享、共同编辑，它管的是本方员工对本方文件的权限，不管本方对外部端点的凭据。口令保管类工具解决的是“存在哪里更安全”，但取用之后仍然是把口令交到人手上，交换动作还是人做的。真正需要被改变的是使用方式，不只是保管方式。
换掉现有端点的代价太大。 凭据分散的直接原因是端点分散：客户的 FTP、伙伴的对象存储、自建的 SFTP 服务器，每一个都在跑业务。要求先做一轮迁移再谈管控，多数企业不会批这个预算，项目也就停在方案阶段。
责任边界模糊。 凭据在业务人员手里时，安全部门无法回答“谁在什么时候用它做了什么”，业务部门也不认为自己该为凭据安全负责。出事之后追责链条断在中间，于是双方都倾向于不去动它。
三、Ftrans B2B 怎么做
3.1 托管范围：四类，说全
凭据托管这件事最怕说一半。平台保管与使用的凭据包括四类：
- 伙伴的 FTP / FTPS / SFTP 账号——用于访问对方或自建的传输服务器；
- 对象存储的访问密钥（AK / SK）——覆盖 Amazon S3（全球与中国区域）、阿里云 OSS、七牛云、深信服存储对象、兼容 S3 协议的存储服务，以及 SMB 共享；
- PGP 私钥——用于系统间对等加密交换的自动加解密与签名验签；
- OFTP2 的协议身份与证书私钥——包括链路双向认证的 TLS 证书与文件签名加密的应用证书。
后两类尤其要说清楚。 私钥不同于账号：账号泄露之后可以由对端重置，而协议身份一旦被冒用，对端系统无法从报文上分辨真伪。因此这两类私钥的存储形态、导出限制与使用留痕，应当与账号凭据一并纳入安全评审范围。
→ 四类凭据在平台内如何存放与被调用见 外部凭据统一保管与使用
3.2 凭据只在平台内被使用，不下发
这是整件事的机制核心：业务人员提交的是“任务”，不是“连接”。
业务侧在平台内选择伙伴、选择要发的文件或要取的目录、提交；平台按该伙伴与该方向的收发策略，取用托管的凭据向外部端点建立连接、执行取送，把结果回写给业务侧。业务侧看到的是任务状态与文件本身，看不到、也无法导出用于建立这条连接的凭据。
人工只保留在需要判断的环节——审核、异常处理。原本由专人执行的“登录外部系统—取文件—查杀—解密—分发”与“压缩—加密—改名—上传”，转为按伙伴与方向预先配置的策略自动执行。
→ 业务人员实际看到什么、怎么操作见 业务人员不接触外部凭据的交换方式
3.3 不换端点，只把凭据收口
平台可以把企业已有的或伙伴侧的存储资源直接纳管为伙伴库目录：FTP/FTPS/SFTP、SMB、Amazon S3、阿里云 OSS、七牛云、深信服存储对象、兼容 S3 协议的存储服务。
数据不迁移、位置不变、对端不改配置。 企业只需把访问凭据收口到平台，即可在原有端点之上叠加统一的权限、审核与审计。这一点直接决定了第一阶段的落地成本——不需要先做迁移项目，也就不需要先说服业务部门停一次机。
→ 零迁移怎么落地见 零迁移纳管既有传输资源
3.4 凭据的使用过程留痕
访问会话、文件操作、文件传输、系统管理、身份管理、身份认证、安全检测七类日志完整记录交换过程，支持条件查询、详情查看与 Excel 导出，保留时长与归档策略可配置。
这里的关键不只是“有日志”，而是日志的主语从人变成了任务：谁在什么时候、以哪个伙伴的身份、对哪个外部端点、执行了什么动作、结果如何。凭据在业务人员手里时，这条记录链是断的——外部系统的日志记的是那个账号，而那个账号背后可能是三个人。
→ 安全治理的顺序与审计设计见 文件出入向安全治理
3.5 变更与回收有明确的操作对象
产品以合作伙伴为业务组织单元：每个伙伴下管理其联系人、外部账号与密钥、可用的交换目录与收发策略、以及与该伙伴之间的全部交换记录。
这样组织的意义在生命周期的末端最明显。合作伙伴是一个有生命周期的对象——准入、签约、交换、变更、离场。以伙伴为单元时，凭据轮换、人员变动、合作终止都有明确的操作对象；以目录或账号为单元时，这些动作只能靠人记忆和手工核对。
→ 人员变动与定期轮换怎么做见 人员变动与凭据轮换
→ 以伙伴为组织单元的完整模型见 合作伙伴文件安全交换
3.6 外发方向的管控是同一件事的另一半
凭据收口解决的是“对外的通道由谁掌握”，外发管控解决的是“什么内容可以走出去”。两者在同一个平台内串成一条线：出向文件先经受控入库、内容识别、敏感内容检查与人工审批，全部明文检查完成之后才做加密封装并发出；文件发出之后还有提取码、有效期、提取次数限制、仅预览不下载与水印等控制手段。
→ 外发的完整流程与控制手段见 文件外发审批与管控
四、边界声明：我们做什么、不做什么
明确写在这里，方便在选型阶段就判断匹配度。
| 边界 | 说明 |
|---|---|
| 不改变外部端点的账号体系 | 伙伴侧账号仍由伙伴发放、重置与停用。平台托管的是本方持有的那一份访问凭据，以及它的使用方式，不代管对方的账号系统 |
| 作用范围是文件交换，不是全部凭据 | 托管对象是对外交换用的四类凭据。服务器运维通道、数据库口令、内部系统账号不在范围内，产品不是通用的口令保管与运维通道管控工具 |
| 不覆盖平台之外的外发渠道 | 安全检查作用于经过平台的文件。员工用邮件、即时通讯、个人网盘外发，不在产品的作用范围内 |
| 已经下放的凭据无法回收 | 平台能保证“从今天起不再下放”，不能撤销此前已经流出的副本。存量凭据需要走一次对端重置 |
| 不含通用工作流编排引擎 | 产品提供审核流程与按伙伴方向配置的收发策略，但不是任务调度平台。作业编排建议由既有调度系统承担，通过 OpenAPI、事件订阅与异步回调协同 |
| 部分能力为可选组件 | OFTP2 协议交换、匿名加密交换（PRO）、高级威胁检测、高级敏感信息检测、明暗水印、落盘加密等需单独选配 |
五、集中托管的另一面：平台本身成为高价值目标
这是一个应当被提出的问题，我们不回避。
凭据集中之后，平台的定位从“一个传输工具”变成了“持有全部对外凭据的系统”。近年 MFT 类产品确实成为攻击目标，凭据集中的平台需要按更高的安全标准建设。把这件事写在产品页上，而不是等客户问起来，是因为它本来就该是选型评审项。
我们在项目评估阶段会就以下内容提供具体说明，并配合客户安全部门的评审：
- 密钥的存储形态——四类凭据分别以什么形式保存；
- 访问权限模型——平台内哪些角色能触及凭据，权限如何隔离；
- 导出限制——凭据能否被导出，什么条件下可以；
- 使用留痕——每一次凭据的取用如何被记录；
- 漏洞响应流程与升级机制——发现问题之后的处置路径。
还有一条边界需要在评审时说清楚：凭据托管属于控制面，与文件传输链路上的网关防护是两个不同的安全层，评审时不宜合并为一项讨论。把两者混在一起谈，会同时得出“要把密钥交给它”和“它不该碰密钥”两个互相矛盾的要求。
→ 托管范围、密钥管理设计与评审配合材料见 外部凭据托管的安全设计与评审配合
六、落地路径
不要求一次性改变企业现有的交换方式，可以按四个阶段推进：
| 阶段 | 内容 |
|---|---|
| 第一阶段 · 纳管 | 不改变现有端点，把既有 FTP/SFTP/对象存储纳管为伙伴库目录；外部凭据收口到平台；叠加权限、审核与审计 |
| 第二阶段 · 规则化 | 按伙伴与方向配置收发策略，把人工取送动作转为规则驱动 |
| 第三阶段 · 自动化 | 对稳定的、周期性的交换启用系统对系统模式（OFTP2 协议对接、PGP 对等加密） |
| 第四阶段 · 集成 | 通过 OpenAPI 与事件机制接入 PLM、ERP 等业务系统 |
第一阶段不涉及数据迁移，对端合作伙伴无感知。 各阶段都不要求停用原有方式——可以先让平台接管一条新增的或风险较高的业务流，原路径保留作为回退，验证稳定后再停止人工操作与旧脚本。
→ 与业务系统怎么协同见 与既有业务系统协同
七、什么样的企业需要这件事
有两个判定信号，比行业和规模更准。
信号一：有专人每天登录若干个外部系统取放文件。 这个岗位的存在本身就说明凭据已经下放，且交换动作还没有规则化。它通常出现在同时对接多家客户或多家主机厂的供应链中游企业——零部件供应商、设备与材料供应商、代工厂。每家客户的服务器、协议、目录规则、命名规范、时间窗都不一样，凭据由客户方发放，本方只能被动适配。
信号二：安全部门无法回答“我们一共有多少个外部账号、分别在谁手上”。 如果这个问题需要现场统计一周，那说明台账并不存在，凭据的实际分布只存在于经办人的记忆里。
如果这两条命中，建议先做一次现状梳理：把现有的对外交换方式、涉及的外部端点与凭据分布列出来，再决定管控范围。这项服务不以采购为前提。
→ 制造业的典型交换场景见 集成电路与半导体的内外部文件交换 · 汽车与零部件行业文件安全交换
常见问题
Q：外部凭据集中托管，平台本身会不会成为风险点？
A：这是一个应当被提出的问题。凭据集中之后，平台需要按更高的安全标准建设，近年 MFT 类产品确实成为攻击目标。我们在项目评估阶段会就密钥的存储形态、访问权限模型、导出限制、使用留痕、漏洞响应流程与升级机制提供具体说明，并配合客户的安全评审。建议在选型阶段就把这一项列为评审项，而不是等到上线之后。另需注意，凭据托管属于控制面，与传输链路上的网关防护是两个不同的安全层，评审时不宜合并讨论。
Q：我们已经有企业网盘了，两者有什么区别？
A：企业网盘围绕人员协作——文件保存、分享、共同编辑，管的是本方员工对本方文件的权限。B2B 围绕外部伙伴关系——伙伴档案与联系人、外部凭据的集中托管、按伙伴与方向配置的收发策略、文件进出企业边界时的安全处理，以及交付责任的完整记录。偶发的对外分享用企业网盘通常够用；固定伙伴的持续文件流、系统化的收投、以及凭据不下放的要求，才是 B2B 的适用范围。两者可以并存。
Q：现有的 FTP 服务器和对象存储要不要换掉？
A：不需要。产品支持将既有 FTP/FTPS/SFTP、SMB、S3/OSS 等存储资源纳管为伙伴库目录，数据不迁移、位置不变、对端不改配置。企业只需把访问凭据收口到平台，即可叠加统一的权限、审核与审计。这也是落地成本最低的第一阶段。
Q：托管的凭据具体包括哪些？只是账号密码吗？
A：四类。伙伴的 FTP/FTPS/SFTP 账号、对象存储的访问密钥（AK/SK）、用于对等加密交换的 PGP 私钥、以及 OFTP2 的协议身份与证书私钥。后两类是私钥，与账号的性质不同——账号泄露后可由对端重置，而协议身份一旦被冒用，对端系统无法从报文上分辨真伪，因此这两类的存储形态与导出限制需要单独说明。
Q：已经发出去的账号还能收回来吗？
A：平台能保证从接管之日起不再下放凭据，但不能撤销此前已经流出的副本——账号和密钥的复制成本为零，“流出了几份”这个问题从设计上就无法回答。存量凭据的处理方式是走一次对端重置：由对端重新发放，新凭据只录入平台、不再下发到个人。这一步通常安排在第一阶段纳管的同时完成。
Q：这和堡垒机、口令保管工具是一回事吗？
A：不是。作用对象不同——产品托管的是对外交换用的四类凭据，作用范围是企业与外部伙伴之间的文件交换；服务器运维通道、数据库口令、内部系统账号不在范围内。使用方式也不同——口令保管类工具解决的是“存在哪里更安全”，取用之后凭据仍然交到人手上；本产品的做法是业务侧只提交交换任务，凭据在平台内被使用、不下发。