匿名加密交换（PGP 对等加密）｜Ftrans B2B
双方自行约定的对等加密，网络不通也能自动交换。
一句话定义
匿名加密交换是一种系统对系统的对等加密交换方式，基于标准 PGP 加密算法实现端到端加密，仅授权接收方可解密。双方预先交换公钥、以唯一匿名识别码验证身份后加入通道，此后每一次交换的加密、签名、解密与签名验证全部自动执行，可使用中间存储作为传输介质，双方无需网络直连。它属于匿名加密交换模块（PRO），是可选组件。
一、这个能力解决什么问题
它面向的是一类很具体的场景：双方之间存在稳定的、周期性的数据交换，双方都要求端到端加密与身份可验证，而两边的网络又不便直连。
在没有这类机制时，实际做法通常是这样的：
| 现状 | 后果 |
|---|---|
| 每次交换前由人手工用加密工具加密、加签，再上传 | 高频交换下工作量不可持续，且是否加密取决于经手人是否记得 |
| 密钥文件通过邮件或即时通讯交给对方 | 密钥的传递过程本身不受保护，也无从审计 |
| 为了让双方系统能直连，申请打通网络 | 涉及双方的防火墙与安全策略变更，周期长、阻力大，且长期敞开一条链路 |
| 加密与解密由两边各写脚本处理 | 写脚本的人离开后没人敢改，密钥轮换成为没人愿意碰的事 |
这些做法的共同问题是把加密当成一次性动作，而不是一条通道的属性。 一次性动作必然依赖人，而人不可靠也不可持续。
二、怎么工作
2.1 一次性的通道建立
通道建立是整件事里唯一需要人参与的部分，且只做一次：
1. 预先交换公钥——双方各自把公钥给到对方，加密与验签由此成立。 2. 分配唯一匿名识别码——每一方在通道中的身份由标识码承载，包括公司标识码（PID）与业务标识码（WID），内外部身份代码可分别管理。 3. 验证身份后加入通道——完成双向授权认证，通道生效。
2.2 之后每一次交换都自动执行
通道建立之后，一次完整的交换是这样的：
发送侧：文件自动加密、自动签名，投放到约定的位置。 接收侧：自动解密、自动验证签名，落地到目标位置。
全程无人工干预。加密是通道的属性，不是某个人在某一次交换里的操作选择。
2.3 中间存储：双方不必打通网络
这一条是它与”直接对接对方系统”最实质的差别：可以使用中间存储作为传输介质（例如一个双方都能访问的对象存储），发送方投放、接收方取走，两边不需要建立网络直连。
对安全部门而言，这意味着不必为一次业务合作在防火墙上长期开一条通道；对项目节奏而言，这意味着不必等待双方网络策略的评审与变更。而由于文件本身是加密的、且带签名，中间存储只是一个搬运介质，它看不到内容，也无法伪造来源。
2.4 去身份化传输
交换过程中以匿名识别码替代真实身份，业务数据与用户隐私在传输环节做脱敏处理。适用于双方不希望在交换链路上暴露具体组织与人员信息的场景。
2.5 与伙伴治理和安全治理的关系
匿名加密交换不是一个独立于平台之外的工具：通道对应的伙伴关系挂在伙伴档案下，密钥资料在档案内绑定与配置，交换记录与其他方式归集在同一处；出向文件在加密封装之前同样要完成内容识别、敏感内容检查与审批，入向文件同样先解密验签、再执行威胁检测。
顺序不能反过来——加密之后不再具备明文内容检查能力，密文阶段的威胁检测能力也有限。
→ 伙伴档案与密钥资料见 合作伙伴档案与收发策略 → 出入向的处理顺序见 文件出入向安全治理：顺序即安全
三、它与协议直连（OFTP2）是两套独立的体系
这是本页必须讲清楚的一条，也是选型时最容易被误解的一条。
两者不是”二选一的加密方案”，而是服务于不同类型伙伴的两套互相独立的体系。
| 匿名加密交换 | OFTP2 协议交换 | |
|---|---|---|
| 规则由谁定 | 双方自行约定 | 伙伴方（通常是主机厂或欧洲客户）规定，本方适配 |
| 身份标识 | 双方约定的匿名识别码 | 由 Odette 组织分配的 SSID |
| 密钥 / 证书体系 | PGP 公钥体系 | X.509 证书体系 |
| 适用对端 | 对端没有既定协议要求，双方可协商 | 对端把该协议作为对接前提，不支持就无法建立业务关系 |
| 网络要求 | 可经中间存储中转，无需直连 | 需要可互相访问的服务地址与端口 |
两套体系的伙伴关系与密钥必须分别配置，不能互相复用。 一家伙伴要求走 OFTP2，不代表可以用 PGP 密钥去满足它；反过来也一样。两者在同一平台内并存，分别服务于不同类型的伙伴，都是可选组件。
→ 伙伴指定的标准协议见 OFTP2 文件收发
四、配置与运维要点
4.1 私钥由平台托管，业务侧不接触
PGP 私钥与伙伴的账号凭据、对象存储密钥一样，由平台统一保管与使用。业务人员在平台内查看结果，全程不需要也无法获取密钥内容。
这同时意味着密钥的存储形态、访问权限模型、导出限制与使用留痕应当纳入安全评审范围——凭据集中本身就是一个需要被评审的设计。
→ 托管范围、密钥存储与评审配合见 外部凭据托管的安全设计与评审配合 → 凭据收口这件事本身见 外部账号与密钥集中托管
4.2 与对方的实现要做一次联调
PGP 是一套公开标准，但双方使用的实现、密钥算法与参数并不必然一致。建议在正式启用前与对方完成一次端到端联调并留下验证记录，而不是配置完成即认为可用。这一点与任何跨组织的加密对接一样，”配置正确”和”互通成立”是两件事。
4.3 密钥轮换要提前约定
对等加密的密钥轮换涉及双方，不是单边动作。建议在通道建立时就把轮换的周期与流程写进双方的对接约定，而不是等到需要轮换时再协商。
4.4 什么时候不该用它
对端没有系统对接能力时不该用它——通道建立需要对方配合交换公钥并配置端点，几个人的小供应商做不到这件事。这类对端应当走链接型的交换机制。
→ 对端零部署时用什么见 对端零部署的文件分发与收集
五、与其他能力的关系
- 本簇支柱：它在交换方式全区间中的位置 —— 系统对系统的一档，与目录级交付、链接机制并存。→ 合作伙伴文件安全交换
- 伙伴指定的标准协议 —— 两套体系互相独立，不能互相复用。→ OFTP2 文件收发
- 密钥挂在哪里 —— 伙伴档案内的密钥资料与收发策略。→ 合作伙伴档案与收发策略
- 目录内的自动加密 —— 伙伴库内的 PGP 自动加密签名同属该模块。→ 伙伴库：专属交换目录与细粒度权限
- 加密前后的安全处理顺序 —— 出向先检查后加密，入向先解密后杀毒。→ 文件出入向安全治理：顺序即安全
- 密钥托管的安全设计 —— 私钥的存储形态与评审配合。→ 外部凭据托管的安全设计与评审配合
- 典型行业 —— 系统间周期性交换稳定数据的场景。→ 集成电路与半导体的内外部文件交换
常见问题
Q：匿名加密交换和 OFTP2 是不是二选一的加密方案？
A：不是。两者是互相独立的两套体系，服务于不同类型的伙伴。OFTP2 是行业标准协议，由伙伴方规定、本方适配，身份用 Odette 组织分配的 SSID，走 X.509 证书体系；匿名加密交换是双方自行约定的 PGP 对等加密，身份用双方约定的匿名识别码，走 PGP 公钥体系。两者的伙伴关系与密钥要分别配置，不能互相复用；它们在同一平台内并存，都是可选组件。
Q：双方网络不通，还能做系统对系统的自动交换吗？
A：可以。支持使用中间存储作为传输介质（例如双方都能访问的对象存储），发送方投放、接收方取走，两边不需要建立网络直连。由于文件本身已加密并带签名，中间存储只承担搬运，看不到内容，也无法伪造来源。
Q：加密和解密需要人操作吗？
A：通道建立之后不需要。建立通道时需要双方预先交换公钥、分配匿名识别码并完成双向授权认证，这一步只做一次；此后每一次交换的加密、签名、解密与签名验证全部自动执行，全程无人工干预。
Q：PGP 私钥存在哪里？业务人员能拿到吗？
A：私钥由平台统一保管与使用，与伙伴的账号凭据、对象存储密钥同一处理方式。业务人员在平台内查看结果，全程不需要也无法获取密钥内容。密钥的具体存储形态、访问权限模型、导出限制与操作审计，我们在项目评估阶段提供具体说明并配合客户的安全评审。
Q：这项能力是标配吗？
A：不是。匿名加密交换模块（PRO）为可选组件，需单独选配。判断依据：是否需要与伙伴系统对系统地自动交换，且双方都要求端到端加密与身份可验证。如果对端没有系统对接能力，应当改用链接型的交换机制；如果对端把某个行业标准协议作为对接前提，那是另一套体系。