一句话定义

外部凭据托管，指把企业与外部合作伙伴交换文件时所需的账号、密钥与证书私钥，从各个业务人员手中收回到一个平台统一保管与使用。 它的收益是凭据可控、可轮换、可回收；它的代价是风险从分散变为集中。这一页讨论的就是后者。

引言：为什么需要这一页

近年 MFT 类产品确实成为过攻击目标。一个集中保管外部凭据的平台，需要按更高的安全标准建设——这是一个应当被提出的问题，而不是一个应当被回避的问题。

我们不打算用”我们更安全”来回答它。这一页做三件事：

1. 把托管范围说清楚，包括那些容易被忽略的部分； 2. 说明哪些安全机制的信息可以在这里公开给出，哪些需要在项目评估阶段针对具体环境单独说明； 3. 给出一份建议由贵方安全部门提出的评审项清单——包括我们希望被问到的问题。

如果读到最后发现某一项我们没有正面回答，那说明它属于第 2 类，请在评估阶段直接向我们提出。

一、先划一条边界：控制面与传输面是两个安全层

这是评审开始前最值得先对齐的一件事，因为混在一起讨论会导致双方都得不出结论。

凭据托管属于控制面，与文件传输链路上的网关防护是两个不同的安全层，评审时不宜合并为一项讨论。 我们不会把这两件事包装成同一句卖点——因为那会导致一个自相矛盾的销售话术：”把密钥交给我”与”我绝不碰密钥”不可能同时成立。

传输面的设计（出向必须在加密前完成内容检查与审批，入向必须先解密再执行威胁检测）是另一套论证。 → 见 文件出入向安全治理

二、问题一：托管范围到底包括什么

四类，其中后两类最容易被漏掉。

第 4 类需要单独强调一句：协议身份一旦被冒用，对端系统无法从报文上分辨真伪。 OFTP2 的身份核验发生在协议层，接收方看到的是一个通过了证书验证的合法会话，报文本身不携带任何可用于二次判别的信息。因此 OFTP2 证书私钥与 PGP 私钥的存储形态、导出限制与使用留痕，应当与账号凭据一并纳入评审，而不是当作”证书管理”这类运维事项跳过。

需要说明的是，这四类并非同时存在：OFTP2 协议交换与匿名加密交换（PRO）均为可选组件，未选配时第 3、4 类托管对象不产生。托管面的大小取决于实际选配范围。 → 标配与可选组件的完整边界见 B2B 产品构成与选配 → OFTP2 的协议身份与证书体系见 OFTP2 文件收发

三、问题二：密钥怎么存、谁能碰

这一节分两部分：可以在这里给出的，和需要在项目评估阶段针对具体环境说明的。我们把两者分开写，而不是用笼统的表述把后者盖过去。

3.1 可以在这里给出的

部署形态：私有化部署。 产品为私有化部署形态，不提供 SaaS 形态。平台连同其保管的凭据运行在贵方自有环境内，不依赖厂商侧的托管服务。这决定了本页讨论的攻击面主要在贵方环境边界之内，也决定了运维访问的授权关系由贵方掌握。

使用方式：凭据由平台代为使用，不下发。 业务人员在平台内提交交换任务并查看结果，全程不需要、也无法获取外部凭据。凭据的使用发生在平台内部——由平台代为登录、代为读写、代为加解密与签名。人员变动时无需逐个回收账号，凭据轮换在平台一处完成。 → 这件事本身的完整说明见 外部账号与密钥集中托管

访问控制：权责分离而非单一管理员。 平台支持三员分立、基于组织架构的分级管理，以及基于多级授权的外部伙伴管理；目录与资源侧支持细粒度权限、权限继承控制与权限有效期；访问侧支持 IP 白名单与黑名单。 管理员账号自身的保护包括：密码复杂度配置、首次登录强制改密、密码过期与账号有效期、错误锁定、禁止多端同时登录、超时自动登出，以及双因素认证（短信 / 邮件 / 图形验证码）与统一认证接入。

使用留痕：七类日志。 访问会话、文件操作、文件传输、系统管理、身份管理、身份认证、安全检测七类日志记录平台内的操作；身份管理侧另有用户、用户组、部门的全生命周期记录，覆盖创建、修改、删除操作。日志支持条件查询、详情查看与导出，保留时长与自动归档策略可配置，归档存储位置可指定。 → 日志结构与追溯方式见 交换全程审计与日志追溯

证书与密钥的生命周期管理。 Odette 证书可在平台内在线生成自签名证书或导入已有证书，关联到本企业或指定伙伴，可查看密钥指纹与有效期，并配置到期提醒通知。PGP 侧提供公钥管理与绑定配置。

3.2 需要在项目评估阶段单独说明的

以下几项与具体实现和部署环境强相关，我们不在公开页面上给出概括性结论，而是在项目评估阶段针对贵方环境提供具体说明，并配合评审：

• 凭据在平台内的存储形态与保护方式（含是否使用专用硬件保护、密钥的加密保护层次等实现细节）
• 凭据的导出限制：是否允许导出、在什么条件下允许、由谁批准、导出行为如何记录
• 访问权限模型的实现细节：哪些角色在哪些操作中会接触到凭据的使用路径，权限边界如何落到实现层
• 凭据使用留痕的字段范围与不可篡改性保障
• 国密算法的支持情况
• 实施与运维阶段厂商侧人员的访问方式与授权流程

这不是回避。 把未经确认的机制写在官网上，等于在评审现场制造一个必须被推翻的说法——对双方都不划算。请在评估阶段直接就上述各项向我们提出，我们按项作答。

四、问题三：出事了怎么办

可以在这里给出的： 维保期内提供版本升级与安全补丁；对承载关键业务的系统，可协商专项服务条款。

需要在项目评估阶段说明的： 漏洞的接收与评估流程、修复与发布节奏、面向客户的通告方式、以及升级机制的具体安排。这些内容与服务协议关联，我们在评估阶段提供说明并写入相应条款，具体服务范围、响应等级与服务时间以正式服务协议为准。

我们不在这里承诺一个响应时长数字。 一个写在官网上、不在合同里的 SLA 数字，对贵方的风险管理没有意义。

五、问题四：怎么配合贵方的安全评审

5.1 我们可以提供的材料

• 架构说明：系统分层、组件构成、数据流与信任边界
• 密钥管理说明：托管对象清单、存储与使用方式、访问权限模型、留痕范围
• 漏洞响应机制说明：接收、评估、修复、通告与升级的流程安排
• 测试环境支持：测试方案设计、环境搭建与过程支持，供贵方在真实环境中验证控制项

5.2 建议贵方提出的评审项

这是一份我们希望被问到的清单。把它写在这里，是因为一次有效的评审对双方都是保护：

1. 托管的凭据类型清单，以及各自在什么业务动作中被使用 2. 凭据在平台内的存储形态与保护方式 3. 凭据能否被导出？在什么条件下、由谁批准、如何留痕 4. 哪些角色可以配置凭据、哪些角色可以触发凭据的使用，两者是否分离 5. 每一次凭据使用是否留痕？留痕包含哪些字段、保留多久、能否被删除或修改 6. 管理员账号自身的认证强度、访问来源限制与操作审计 7. 人员变动、合作终止时的凭据轮换与回收流程，以及验证方式 8. PGP 私钥与 OFTP2 证书私钥是否与账号凭据采用同一套保管与留痕机制 9. 审计日志的导出与归集方式，能否满足贵方的日志留存与审计要求 10. 漏洞的接收、评估、修复与通告流程，以及紧急补丁的发布与升级方式 11. 私有化部署下，厂商在实施与运维阶段的访问方式、授权流程与留痕 12. 哪些控制项可以在测试环境中由贵方自行验证

六、我们不做的安全主张

一份经得起追问的材料，需要同时说明它不主张什么。以下表述我们在任何对外材料中都不使用：

七、把托管的收益与代价一起放在桌面上

集中托管改变的是风险结构，不是风险总量：

最后一行是这件事的实质：托管把一个无法被评审的问题，变成了一个可以被评审的问题。 这也是我们把评审项清单直接写在页面上的原因。

→ 凭据收口这件事本身的完整说明见 外部账号与密钥集中托管 → 凭据在平台内如何保管与使用见 外部凭据统一保管与使用 → 产品整体见 Ftrans B2B 企业间文件安全交换系统