文件出入向安全治理：顺序即安全｜Ftrans B2B

加密之后看不到内容，密文阶段查不出病毒——顺序错了，检查等于没做。

一句话定义

文件出入向安全治理，指对进出企业边界的文件按方向分别编排安全处理阶段，并把这个顺序固化在交换流程中。 出向（企业内部发往外部伙伴）与入向（外部伙伴发进企业内部）的处理顺序不同、且不可互换：出向的内容检查与审批必须在加密之前完成，入向的威胁检测必须在解密之后执行。

一、问题定义：不是”有没有检查”，是”检查排在第几位”

多数企业在被问到”对外发文件有没有做安全检查”时，都能给出肯定的回答——有杀毒软件、有 DLP、有审批流程。这个回答通常是真的，但它回答的是清单问题，不是顺序问题。

真正决定检查是否有效的，是下面这两条：

出向：加密之后，内容检查就做不了了。

外发给伙伴的文件常常要加密——有的是伙伴要求，有的是内部规定。如果加密动作发生在内容检查之前，那么后面这道 DLP 面对的就是一段密文：它看不到里面有没有源代码、有没有图纸、有没有客户名单。检查照做了，报告照出了，但检出率必然接近零。

入向：解密之前，病毒也查不出来。

反过来，伙伴发来的加密文件如果直接送进杀毒引擎，引擎同样只能看到密文。常见的应对办法是让业务人员先把文件解密到自己的电脑上，再手动查一遍——于是明文落在了终端上，检查发生在了企业的安全边界之外，而且做不做取决于当天这个人记不记得。

这两件事都不是能力缺口，而是编排缺口。它们的共同点是：不会导致系统瘫痪，因此长期被容忍；但一旦真的漏出去一份文件或收进来一个恶意样本，追溯时会发现流程本身就是失效的。

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

检查是”补做”的，不是通道内固有的。

在没有统一平台之前，检查往往挂在人身上：外发前记得扫一遍、收到文件记得查一遍。做与不做、先做后做，取决于经手人。同样一批文件，换一个人操作，走的就是另一条路径。

加密与检查由不同的人在不同时点完成。

加密是对外承诺的一部分，通常由对接人在发送环节做；内容检查是内部安全要求，通常由安全部门定策略。两件事分属两个流程，谁先谁后没有人专门裁定，结果就是各站点各不相同。

每条通道各做各的。

网盘一套规则、邮件一套规则、FTP 一套规则、协议直连又是一套。方向不同、伙伴不同，检查项和顺序也不同。被审计时无法给出一个统一的说法，也无法证明哪一批文件走过了哪些检查。

把顺序交给配置，就等于交给了运气。

即使平台提供了全部检查能力，如果阶段顺序是一个可以随意调换的配置项，那么它迟早会在某个项目上被调错——而调错之后系统照常运行，没有任何报错，问题要到出事那天才会暴露。

三、我们怎么做

3.1 按方向分别编排，顺序固化在流程里

Ftrans B2B 不提供”自由编排检查顺序”的能力，而是把出向与入向的处理顺序写死在流水线中。它是安全设计的一部分，不是配置人员需要判断的选项。

出向五段——从企业内部到外部伙伴：

数据入口是 Web 人工提交，或对内部存储位置的扫描监控（增量发现、自动成批）。送达目标可以是平台内置传输服务的目录、企业内部自建的传输服务器、伙伴侧的 FTP/SFTP 或对象存储、经协议直连投递到伙伴系统，或生成一条受控的文件包链接。

关键在于加密封装的位置：加密封装排在全部明文检查之后。走到这一步时，内容检查与审批都已经完成，加密不会遮蔽任何一项检查。

入向四段——从外部伙伴到企业内部：

数据入口包括伙伴上传到平台内置的传输服务、通过收集链接提交、对伙伴侧存储位置的扫描、伙伴经协议主动推送，以及伙伴库内的人工选择。送达目标是企业内部的目录或 NAS、内部 Web 提取区，或经对象存储与 API 回调投递到内部业务系统。

这里有两个细节值得留意：解密验签阶段完成解密之后，明文仍然停留在隔离区——它不会因为解开了就被视为可信；威胁检测阶段排在解密之后，才拿得到可供检测的明文。

3.2 入向不做敏感内容检查与人工审核

这一点需要明说，避免形成错误预期：入向的处理阶段就是上面四段，不包含敏感内容检查，也不包含人工审核。 这两段属于出向方向。产品没有为了对称而在入向重复设置它们。

原因也简单：出向管的是”我方的东西会不会流出去”，入向管的是”外面的东西干不干净”，两者要回答的问题不同。

3.3 两个方向都设放行闸

出向与入向的末端各有一道安全放行闸：安全治理全部通过之后，文件才被投递或发布。未通过的文件停留在隔离区，既不进入内部目标，也不发往外部伙伴。

这道闸是”检查有没有用”的分水岭。只出报告、不拦文件的检查，本质上只是记录；能拦下来的检查，才构成控制。

3.4 协议直连也走同一套顺序

企业出于伙伴要求引入 OFTP2 这类协议直连通道时，最容易出现的一种理解是”协议直连是另一条路，所以绕过检查”。在本产品中不是这样：协议直连只是把数据入口与送达目标换成了协议本身，安全治理的阶段顺序不变。

出向的内容识别、敏感内容检查与人工审批仍在前，协议的应用层签名与加密属于加密封装阶段，位于全部明文检查之后；入向的来件先落隔离区，应用层解密与验签属于解密验签阶段，威胁检测在其之后执行。

→ 协议本身怎么工作、需要准备什么见 OFTP2 文件收发

3.5 五个阶段各自展开

出入向的每一段都对应一组具体能力，本簇的其余页面逐一展开：

• 出向内容识别与敏感内容检查的内部机制——真实类型怎么识别、OCR 与 DLP 策略如何匹配、命中之后怎么分流。→ 外发内容检查与敏感信息识别
• 入向隔离与检测的内部机制——隔离区怎么工作、引擎怎么组合、被拦下的文件去哪里。→ 外来文件威胁检测与隔离
• 出向人工审批——流程怎么设计、审批动作怎么落在企业既有的办公入口里。→ 审批流程与既有 OA 集成
• 文件发出之后的控制——提取码、有效期、仅预览、明水印与暗水印，以及它们的作用边界。→ 外发后的控制与水印溯源
• 全过程的记录——七类日志、查询导出、保留与归档。→ 交换全程审计与日志追溯

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

明确写在这里，方便你在选型阶段就判断匹配度。

→ 哪些是标配、哪些需要选配见 B2B 产品构成与选配

→ 平台自身的安全设计与评审配合见 外部凭据托管的安全设计与评审配合

五、落地路径

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

建议第一阶段先开”仅检测模式”。 产品支持只识别、不执行处理动作的运行方式：策略先跑起来，把风险分布摸清楚，再决定哪些命中项该阻断、哪些该转审核。直接上来就配阻断规则，通常会在头两周被业务投诉推翻。

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

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

→ 与业务系统怎么协同见 与既有业务系统协同

六、什么样的企业最需要这套顺序

三类场景对处理顺序最敏感，也是本产品客户密度较高的场景：

图纸与技术文档的外发。 与外协厂商交换设计图纸、工艺文件、BOM 与质量报告时，文件本身就是核心技术数据。这类外发必须在加密封装之前完成内容检查与技术部门审核——因为一旦封装成密文交出去，后面所有的控制手段都只剩水印与提取限制。

多头对接下的入向收件。 同时对接多家客户或多家主机厂时，来件的来源可信度参差不齐，格式也各不相同。入向统一走”到货即隔离 → 解密验签 → 威胁检测”这条路径，比让不同的对接人在自己电脑上各自处理要可控得多。

面向客户的敏感资料收取。 收取身份证明、财务报表、合同这类资料时，提交内容涉及个人隐私与商业机密，需要在提交之后自动完成病毒检查与敏感内容检测，并触发审核流程后再进入业务处理。

→ 半导体与集成电路行业的内外部图文档收发见 集成电路与半导体的内外部文件交换

→ 汽车与零部件行业的交换需求见 汽车与零部件行业文件安全交换

→ 高端装备的图纸外发见 高端装备与精密制造的图纸外发

→ 以伙伴为单元的交换模型见 合作伙伴文件安全交换

常见问题