在第三方服务运行在自己的APP前，如何做好数据和风险权限管控

金融和政务类APP 接入第三方服务时，最核心需要关注的就是如何保证APP的安全稳定：业务方希望尽快把合作伙伴的服务接进来，安全团队拿到手的是一个编译好的代码包和一份对方出具的承诺函，翻遍自己的审查清单，发现没有一条适用。

代码是人家的，跑在自己的APP 里，出了问题算谁的。安全团队手里有标准，但标准在这类场景里失效了：要源码审计，第三方不可能给；做漏洞扫描，对方的服务每周都在更新，这周审完的内容下周就变了样。审查一个持续迭代的黑盒，用静态的手段永远追不上。

今天分享一种基于沙箱的解决方案，看看小程序多端框架的安全沙箱，是怎么把审查对象从"别人的全部代码"收敛成"暴露出来的接口边界"的。

两种接入方式都缺一道清楚的边界

按照传统的接入方式，第三方服务进 APP 通常有两条路，两条路在安全评审上都走得艰难。

首先是SDK 集成，第三方的代码直接编译进 APP 主工程，拿到的是和自有代码同级的系统权限，安全团队要审的实质上是对方的全部实现，而对方出于商业考虑往往只给文档不给源码，评审只能靠对方填表。

然后是H5页面的方式，审查负担小了，但管控也基本放弃了，页面加载什么内容、请求什么接口、埋什么统计代码，APP 侧既看不见也管不住，用户体验和安全责任却还要 APP 方承担。

两种方式共同的症结在于，第三方代码和宿主APP 之间没有一道清楚的边界。要么全部信任，要么完全不信任，没有中间状态可选，评审会就是在这种二选一里卡住的。

审查对象从全部代码收敛到运行边界

以 FinClip的小程序容器的方案为例，第三方服务以小程序的形式接入，小程序运行在SDK 提供的安全沙箱里，业务代码从头到尾跑在一个封闭的运行环境中，这道环境就是边界。

边界立起来之后，安全审查的问题就变了。原来要回答的是"对方的代码安不安全"，这个问题只有对方自己能回答；现在要回答的是"这个运行环境能拦住什么、放出去什么"，这个问题是有确定答案的，而且可以逐项验证。

安全团队的工作从读别人的代码，变成核对一张边界清单。

沙箱把运行、启动和通信都圈进了边界内

先看运行隔离，小程序的逻辑层和渲染层是分开的两个线程，二者之间不允许直接通信，所有数据交互都必须经过宿主应用中转，第三方代码没有旁路可以绕过这道中转直接去碰系统。

再看启动权限，第三方只能通过 SDK 主动暴露的接口来启动运行时，每个小程序关联到平台上登记的宿主应用，SDK 初始化时校验 SDK Key、SDK Secret 和 Bundle ID，没在平台上完成关联的代码包在 APP 里打不开，也就是说 APP 里能跑哪些第三方服务，始终是平台侧受控的名单。

然后是对外通信，SDK 完全管控业务应用的运行环境和对外网络通信，通过多种机制保证通信不被拦截和干扰，第三方小程序请求什么地址、走什么协议，都在这层管控之内。

桌面端还有额外的隔离措施，Windows 等桌面环境采用 Chromium Embedded Framework 内核，运行环境和系统浏览器完全隔离，避免第三方代码借系统浏览器的漏洞或扩展拿到额外能力。

宿主能力按白名单开放

小程序总要调用一些系统能力，登录、定位、支付、人脸，这些能力怎么给，是安全审查的另一个焦点。

FinClip 的做法是白名单逻辑，宿主 APP 通过自定义 API 把自己的能力注入小程序运行环境，开放哪一项、开放到什么程度，完全由 APP 方定义。第三方小程序能用宿主 APP 的统一登录和统一支付，但拿到的只是 APP 方明确暴露出来的那几个接口，接口之外的能力一概摸不到。

对安全团队来说，这意味着能力开放从"给一个 SDK 就给出了一片权限"变成"逐条登记、逐项审批"的清单管理，每一项放出去的能力都有明确的边界，事后也查得到。

异常服务的下架和回退都不需要动主工程

边界再清楚，审查也需要回答最后一个问题：万一还是出了事，能怎么办。

小程序的形态在这里有一个天然优势，它和 APP 主工程是解耦的。发现某个第三方服务有异常行为，可以直接在管理平台上把这个小程序下架，用户侧立即失效，整个过程不需要动 APP 主工程，也不用等应用商店审核。如果是版本问题，可以回退到最近的历史版本，最多支持回退 5 个，回退操作不需要重新审核。

对比 SDK 集成的方式就很直观，第三方 SDK 出了问题，只能发一个新的 APP 版本把它摘出去，再经过应用商店审核、等用户升级，处置周期按周计。两种方式的止损速度不在一个量级上。

平台自身的合规认证也是评审材料的一部分

运行边界之外，平台自身的合规材料也是评审的一部分，这方面有现成的清单可以对照。

FinClip 小程序 SDK 通过了信息安全等级保护三级认证、ISO 27001 信息安全管理体系认证，并通过了中国信通院的 SDK 安全专项评测，评测覆盖产品基础安全、数据存储安全、数据交互安全等五个方面。安全团队如果需要留档，还可以向 FinClip 申请 SDK 质量检测证书，用来完善自有 APP 的合规材料。

数据归属也值得单独说一句，FinClip 小程序 SDK 收集的终端信息由开发者自行设定是否上报，数据仅上传至开发者自己部署的环境，SDK 厂商一侧拿不到任何业务数据和用户数据。对金融和政务场景来说，这一条往往就是数据合规评审的分界线。

边界清楚之后，评审的节奏就变了

如果团队正在评估第三方服务的接入方案，安全讨论可以聚焦到 FinClip 的运行边界上，能看到的变化有几个方面。

审查范围上，安全团队面对的不再是第三方持续迭代的全部代码，而是一张可以逐项核对的边界清单：运行隔离、启动权限、对外通信、能力开放，每一项都有确定答案。

接入效率上，第三方服务的接入评审从按月起的不确定性流程，变成按清单执行的常规动作，业务方不用再为每个合作伙伴单独和安全团队拉锯。

处置能力上，异常服务的下架和回退都在管理平台上完成，止损周期从客户端发版周期里解脱出来，安全团队手里有了真正的开关。

合规留档上，等保三级、ISO 27001、信通院 SDK 评测这些现成的认证材料，加上可申请的质量检测证书，让评审材料的准备工作量大为减少。

安全审查的目标是把每一次接入都放进看得清、管得住的边界之内，边界清楚了，合作的速度反而能快起来。