外部凭据统一保管与使用 | Ftrans B2B
保管只是一半，另一半是“取用之后凭据仍然不出平台”。
一句话定义
外部凭据统一保管与使用，指企业访问外部端点所需的账号与密钥统一录入平台、按合作伙伴归属管理，并且只在平台内部被交换任务调用，不下发到业务人员手中。
一、这个能力解决什么问题
“密钥不能给业务人员”——安全部门几乎都同意这句话。真正卡住的是下一句：那文件谁去取、谁去发？
于是多数企业停在一个折中状态：凭据名义上归 IT 管，实际上还是发给了几个固定的对接人，因为只有他们每天在做取送。管理办法写了，执行不了。
把这个折中拆开看，会发现“保管”和“使用”是两件被混在一起的事：
| 保管 | 使用 | |
|---|---|---|
| 要回答的问题 | 凭据存在哪里、谁能看到 | 凭据在什么时候、被什么动作、向哪个端点用了一次 |
| 常见做法 | 集中记录在表格、口令工具或运维文档里 | 由人登录外部系统手工完成 |
| 遗留的问题 | 取用之后仍然要交到人手上 | 使用行为没有记录对象，日志里只有一个共享账号 |
只解决保管，凭据仍然会在取用的那一刻离开管控范围。这个能力要做的是把使用也收进来：业务人员提交任务，平台取用凭据执行，凭据从头到尾不出平台。
→ 凭据收口这件事的全景与落地路径见 外部账号与密钥集中托管
二、怎么工作
2.1 四类凭据，一处录入，按伙伴归属
平台保管与使用的凭据分四类：
| 类型 | 用途 | 归属位置 |
|---|---|---|
| FTP / FTPS / SFTP 账号 | 访问伙伴侧或自建的传输服务器 | 第三方存储资源，可作为该伙伴的伙伴库目录 |
| 对象存储访问密钥（AK / SK） | 访问 Amazon S3（全球 / 中国区域）、阿里云 OSS、七牛云、深信服存储对象、兼容 S3 协议的存储服务；SMB 共享同此 | 同上 |
| PGP 密钥 | 系统间对等加密交换的自动加解密与签名验签 | 合作伙伴的密钥资料 |
| OFTP2 的协议身份与证书私钥〔可选组件〕 | 链路双向认证的 TLS 证书、文件签名加密的应用证书 | 合作伙伴的连接配置与证书管理 |
归属到伙伴，是这套机制能运转的前提。产品不以目录或账号为组织单元，而以合作伙伴为业务组织单元——每个伙伴下管理其联系人、外部账号与密钥、伙伴库目录、收发策略与全部交换记录。一份凭据属于哪家伙伴、被哪些策略引用、影响哪些目录，是可以直接查到的，而不需要靠人回忆。
表中标〔可选组件〕的一类凭据只在选配了 OFTP2 协议交换后才存在，未选配时平台不涉及该类私钥。见 B2B 产品构成与选配。
2.2 业务侧提交的是任务，不是连接
一次交换任务在平台内的走法是固定的四步：
收发策略校验。这个用户（或用户组、部门）在这个伙伴、这个方向上是否被授权。收发策略支持内外部用户收发关系配置、策略优先级设置与在线收发关系检查，并按收发方式分别授权。校验不通过，任务不进入下一步。
平台取用凭据、建立连接。平台按目标端点取用对应的托管凭据向外部建立连接。这一步完全发生在平台内部——业务侧的界面上不出现凭据字段，也没有导出入口。
方向化的安全处理。出向在加密前完成内容识别、敏感内容检查与审批，入向先落隔离区、解密验签之后再执行威胁检测。这个顺序不是配置选项。
执行取送并回写结果。按伙伴与方向的策略对外部端点执行取放，把任务状态与文件回写给业务侧。业务人员看到的是“这批文件发出去了/取回来了”，看不到这条连接是用什么凭据建立的。
2.3 每一次取用都落在日志里
访问会话、文件操作、文件传输、系统管理、身份管理、身份认证、安全检测七类日志完整记录交换过程，支持条件查询、详情查看与 Excel 导出。
凭据托管带来的审计变化，在于日志的主语。凭据在个人手里时，外部系统日志记录的是那个账号——而那个账号背后可能是三个人、五台电脑。凭据收口之后，每一次取用都对应平台内一个具体的发起人、伙伴、方向与任务，责任链条是连着的。
→ 出入向为什么必须是这个顺序、日志与审计怎么设计见 文件出入向安全治理
三、配置与运维要点
3.1 凭据录入之后就不再需要被“取出来”
这是与口令保管类工具最实际的差别：录入是一次性动作，之后的日常使用都由平台代为完成，运维侧不需要为每次交换重新分发一次凭据。如果实施过程中出现“某个场景还得把凭据发给某人”，那说明这个场景还没有被策略覆盖，应当在配置阶段解决，而不是开一个例外。
3.2 权限与凭据是两套东西，都要配
凭据决定“平台能连到哪里”，权限决定“谁能让平台去连”。后者由伙伴库授权与收发策略承担：基于用户 / 部门 / 用户组 / 伙伴联系人授权，细粒度权限（浏览 / 预览 / 下载 / 上传 / 管理 / 编辑）、子文件夹权限与继承控制、权限有效期控制。
平台还支持三员分立与基于组织架构的分级管理，以及基于多级授权的外部伙伴管理——能碰凭据的角色与能发起交换的角色可以分开，这一点在安全评审时通常会被单独问到。
3.3 存储资源纳管不改变数据位置
既有 FTP/FTPS/SFTP、SMB、S3/OSS/七牛/深信服等存储资源可直接纳管为伙伴库目录，数据不迁移、对端不改配置，只是把访问凭据收口到平台，随后叠加统一的权限、审核与审计。
需要注意的是，不同存储类型在实际使用中的能力表现存在差异，建议在项目评估阶段按实际使用的存储类型逐项确认，而不是按“都支持”来做方案假设。
→ 不换现有端点怎么落地见 零迁移纳管既有传输资源
3.4 证书与密钥有到期这件事
PGP 公钥的绑定与配置、Odette 证书的在线生成或导入、关联到本企业或指定伙伴、密钥指纹与有效期查看、到期提醒通知，都在平台内完成。证书过期导致的传输失败通常不能靠重试解决，因此到期提醒不是锦上添花的功能——它是这类凭据管理中最容易出事故的一环。
3.5 私钥的安全设计属于评审议题
密钥的具体存储形态、访问权限模型、导出限制与操作审计，我们在项目评估阶段提供具体说明并配合客户安全部门评审。这一项建议在选型阶段就提出来，它比功能清单更能区分产品。
→ 托管范围、密钥管理设计与评审配合材料见 外部凭据托管的安全设计与评审配合
四、与其他能力的关系
- 凭据收口的整体主张与落地路径
为什么要做、分几步做。→ 外部账号与密钥集中托管
- 业务侧的实际使用体验
不给凭据之后，业务人员每天怎么干活。→ 业务人员不接触外部凭据的交换方式
- 凭据要换的时候
人员变动、合作终止与定期轮换的操作路径。→ 人员变动与凭据轮换
- 外发方向的完整管控
内容检查、审批与外发后控制。→ 文件外发审批与管控
- 以伙伴为组织单元的完整模型
凭据为什么要归属到伙伴。→ 合作伙伴文件安全交换
- 半导体与制造业的典型交换场景
对接家数越多，凭据归属的收益越明显。→ 集成电路与半导体的内外部文件交换
常见问题
Q：凭据存在平台里，业务人员真的看不到吗？
A：看不到，也导不出。业务侧的操作界面提交的是交换任务——选择伙伴、选择文件或目录、提交，平台按收发策略校验后取用托管凭据向外部端点建立连接并执行取送，把任务状态与文件回写。凭据字段不在业务侧界面上出现，也没有面向业务角色的导出入口。密钥的具体存储形态、访问权限模型与导出限制，我们在项目评估阶段提供说明并配合安全评审。
Q：托管的凭据包括哪几类？私钥也托管吗？
A：四类：伙伴的 FTP/FTPS/SFTP 账号、对象存储访问密钥（AK/SK，含 SMB 共享凭据）、用于对等加密交换的 PGP 密钥、以及 OFTP2 的协议身份与证书私钥。后两类是私钥。私钥与账号的性质不同——账号泄露后可由对端重置，而协议身份一旦被冒用，对端系统无法从报文上分辨真伪，因此这两类的存储形态与导出限制应当单独纳入评审。
Q：这和口令保管工具有什么区别？
A：口令保管解决的是“存在哪里更安全”，取用之后凭据仍然交到人手上，交换动作还是人做的。本产品把使用也收了进来：业务人员提交任务，平台取用凭据执行，凭据从录入到日常使用都不离开平台。作用范围也不同——托管的是对外交换用的凭据，服务器运维通道、数据库口令、内部系统账号不在范围内。
Q：能不能限制谁可以维护凭据？
A：可以。平台支持三员分立、基于组织架构的分级管理，以及基于多级授权的外部伙伴管理，能维护凭据的角色与能发起交换的角色可以分开。伙伴库授权与收发策略另有一套细粒度权限（浏览 / 预览 / 下载 / 上传 / 管理 / 编辑），支持子文件夹权限继承与权限有效期控制。
Q：我们的存储类型比较杂，都能纳管吗？
A：支持的类型包括 FTP/FTPS/SFTP、SMB、Amazon S3（全球区域 / 中国区域）、阿里云 OSS、七牛云、深信服存储对象，以及兼容 S3 协议的存储服务，纳管后作为伙伴库目录使用，数据不迁移、对端不改配置。不同存储类型在实际使用中的能力表现存在差异，建议在项目评估阶段按实际使用的类型逐项确认，不要按“都支持”来做方案假设。