一句话定义

企业间文件交换，指企业与外部合作伙伴之间持续、受控地收发文件的全过程——包含伙伴关系与联系人的管理、外部账号与密钥的保管、按伙伴与方向配置的收发策略、文件进出企业边界时的安全处理，以及全部交换行为的记录。它与企业内部的文件协作不是同一件事：内部协作围绕人和团队组织，企业间交换围绕外部组织与交付责任组织。

一、问题定义：交换的对象是一家公司，系统里管的却是目录和账号

绝大多数企业不是没有对外交换文件的手段——手段太多了。有网盘、有 FTP、有邮件、有几个供应商给的账号、有一台谁也说不清是谁在维护的中转机。真正缺的是一个与业务对应的组织单元。

业务上说的是”给这家供应商发图纸””从这家客户那里取订单文件”，落到系统里却变成了”往那台服务器的某个目录里放””用记在某人电脑上的那个账号登进去下载”。对象对不上，后面所有的管理动作就都对不上。

具体表现通常是下面这几条，你大概率能对上其中的大半：

这些问题的共同点是：它们不会导致系统瘫痪，因此长期被容忍；但一旦发生泄露、审计或纠纷，代价是集中爆发的。

二、为什么现有做法解决不了

不是工具不够好，是组织单元错位。

企业网盘围绕人员协作组织。 它管的是”谁的文件夹””分享给谁”。对外发一次文件它能做，但它没有”合作伙伴”这个对象——不知道这家供应商有几个联系人、之前发过什么、密钥归谁、合作终止时该收回什么。偶发的对外分享用网盘通常够用，固定伙伴的持续文件流不是它的设计目标。

把 FTP 账号直接发给业务，凭据就再也收不回来了。 账号一旦交出去，它会被抄进邮件、记在便签、传给下一任接手的人。谁在用、用了多少次、离职后是否还在用，全都没有对象可查。更根本的问题是：账号不是”人”，它是一串可以无限复制的字符串，没有任何一次使用能被归因到具体的人。

邮件与即时通讯的边界很清楚。 大文件发不出去，批量文件更不行；发出去之后无法设有效期、无法限制转发、无法知道对方取没取。它们不是为交付责任设计的。

自研脚本 + 对象存储能跑起来，但跑不长。 写脚本的人还在的时候一切正常，人走了之后没人敢改；安全检查通常从一开始就没有做进去。

这四种做法都不是错的，它们只是都以”文件去了哪里”为中心，而不是以”这是哪一家伙伴”为中心。

→ 这四种做法各自的适用场景与取舍分析见 零迁移纳管既有传输资源

三、Ftrans B2B 怎么做

3.1 以合作伙伴为业务组织单元

产品不以”目录”或”账号”为组织单元，而以合作伙伴（外部企业、供应商、客户、机构）为业务组织单元。每一家伙伴是一份档案，档案下挂七类内容：

伙伴本身按树状结构分类管理，可以按分类与分组做权限控制。这不是一个页面上的信息聚合，而是授权、策略与审计共同指向的那个对象。

→ 档案结构、收发策略与权限模型见 合作伙伴档案与收发策略

3.2 伙伴是一个有生命周期的对象

这是”以伙伴为单元”最实际的意义，也是它与目录、账号最锋利的区别。

合作关系从准入开始，经过签约、日常交换、人员与凭据的变更，最终走到离场。以伙伴为单元时，这五个阶段的每一次动作都有明确的操作对象：

• 准入——建档、录联系人、配管理员，一次性把这家伙伴的边界划出来。
• 签约——配置收发策略，确定谁能对谁收、谁能对谁发，以及走哪种交换方式。
• 交换——文件按策略进出，全程留痕在这份档案下。
• 变更——对方换了对接人，或本方的经办人调岗，改的是档案里的联系人与策略，不是去若干台服务器上找账号。凭据轮换在平台一处完成。
• 离场——合作终止时禁用这一家，与之相关的账号、密钥、目录权限随之失效。

而以目录或账号为单元时，这些动作只能靠人记忆和手工核对。“这家供应商去年就不合作了，他们的 FTP 账号还能不能登”——这个问题在有伙伴档案的系统里是一次查询，在没有的系统里是一场排查。

3.3 交换方式覆盖对端能力的全区间

合作伙伴的 IT 能力不是齐平的。同一份供应商名单里，既有能做系统对接的大厂，也有只会点链接的几个人的小作坊。产品提供四种交换模式，外加一对链接型机制，可在同一平台内并存：

最后一行值得单独说一句：企业间交换的实际约束往往不在本方，而在对端。 合作伙伴名单里总有一部分是几个人的小供应商、临时的第三方机构、没有 IT 部门的客户单位。能不能覆盖这一档，直接决定平台能覆盖多少比例的实际交换量。选型时建议按最弱的那个对端来定，而不是按最有能力的那个。

→ 人对人的收发见 伙伴邮：类邮件的对外文件收发 → 目录级的持续交付见 伙伴库：专属交换目录与细粒度权限 → 对端什么都装不了的情况见 对端零部署的文件分发与收集 → 系统对系统的加密自动化见 匿名加密交换（PGP 对等加密） → 伙伴指定的标准协议见 OFTP2 文件收发

3.4 走哪种方式，安全处理的顺序都不变

四种模式与链接型机制换掉的只是”文件怎么进来、怎么出去”，不换安全治理的顺序。

出向文件先经受控入库、内容识别、敏感内容检查与人工审批，全部明文检查完成之后才做加密封装。顺序不能反过来——加密之后不再具备明文内容检查能力。

入向文件先落隔离区，经解密与验签之后再执行威胁检测。同样不能反过来——密文阶段的检测能力有限，有效杀毒只能在解密之后进行。

两个方向都设放行闸：安全治理通过后方可投递或发布，未通过的文件停留在隔离区，不进入内部目标，也不发往外部伙伴。不存在”因为走的是协议直连所以绕过检查”的通道。

→ 为什么必须是这个顺序见 文件出入向安全治理：顺序即安全

3.5 外部凭据由平台托管，业务侧不接触

伙伴的 FTP/SFTP 账号、对象存储密钥、PGP 密钥，以及协议对接所需的身份与证书私钥，统一由平台保管与使用。业务人员在平台内提交交换任务、查看结果，全程不需要、也无法获取这些凭据。

这同时意味着平台承担了更高的安全责任，凭据集中本身就是一个应当被评审的设计。密钥的存储形态、访问权限模型、导出限制与使用留痕，我们在项目评估阶段提供具体说明并配合客户的安全部门评审。

→ 凭据收口这件事本身见 外部账号与密钥集中托管 → 托管范围、密钥存储与评审配合见 外部凭据托管的安全设计与评审配合

3.6 交换记录归集在一处

访问会话、文件操作、文件传输、系统管理、身份管理、身份认证、安全检测七类日志完整记录交换过程，支持条件查询、详情查看与导出，保留时长与自动归档可配置。同一家伙伴的全部收发记录挂在这份伙伴档案下，不论它走的是哪种交换方式。

→ 记录结构与追溯方式见 文件出入向安全治理：顺序即安全

四、边界声明：我们做什么、不做什么

明确写在这里，方便你在选型阶段就判断匹配度，而不是上线之后才发现缺口。

另有一条容易被误解的：OFTP2 的证书体系与匿名加密交换的 PGP 密钥体系互相独立，伙伴关系与密钥要分别配置，不能互相复用，也不是”二选一的加密方案”。前者由伙伴方规定、本方适配，后者由双方自行约定，服务的是不同类型的伙伴。

→ 与 EDI 的关系、什么时候该找谁见 文件交换与 EDI 是什么关系 → 与业务系统怎么协同见 与既有业务系统协同

五、落地路径

不要求一次性改变企业现有的交换方式，可以按四个阶段推进：

各阶段都不要求停用原有方式。可以先让平台接管一条新增的或风险较高的业务流，原路径保留作为回退，验证稳定后再停止人工操作与旧脚本。

→ 不换现有系统怎么落地见 零迁移纳管既有传输资源

六、谁在用

客户密度最高的三类是集成电路与半导体、汽车与零部件、高端装备与精密制造。它们的共同特征不是行业，而是交换结构：同时对接多家外部组织，每一家的服务器、协议、目录规则、命名规范与时间窗都不一样，且交换的内容是图纸、工艺文件、测试数据这类核心技术资产。

这类企业通常处在供应链中游——既要向下游客户交付，又要从上游供应商收件，两个方向的凭据、策略与安全要求都不相同。以伙伴为单元组织交换，收益在对接家数上升时是非线性的。

→ 集成电路与半导体的内外部文件交换 → 汽车与零部件行业文件安全交换 → 高端装备与精密制造的图纸外发