Zoom事件：APP如何做好SDK合规？

事件快速回顾：Zoom 为何被禁？

全球疫情的爆发使更多会议转移到线上，远程会议服务软件 Zoom 的用户数量也随之大幅增加，但却因为被连续曝出存在隐私和安全问题而引起了广泛关注，根据外媒报道，马斯克的 SpaceX 公司，以及美国 NASA，都要求禁止他们的员工使用视频会议应用 Zoom，理由是存在“严重的隐私和安全问题”。伴随 Zoom 的股价暴跌，Zoom 也紧急宣布未来 90 天将冻结功能更新，并承诺在此期间解决隐私安全问题，同时还发起“漏洞赏金”计划，为发现安全漏洞的人提供报酬，并与第三方一起解决问题。

那么，Zoom 究竟为何被禁呢？扼要分析一下：

Zoom 被禁的导火索主要有两个：

第一：Zoom 客户端本身存在的安全漏洞（Zoom 可能并没有做到真正的端对端加密）。

据外媒披露，不同版本的 Zoom 可能存在对应的安全问题。例如，对于 Windows 版的 Zoom 客户端：因容易受到 NUC 路径注入攻击而存在安全漏洞，从而导致用户面临隐私泄露的风险（用户的 Windows 登录凭据将可能被窃取）。而对于 iOS 版：则因内嵌的脸书的 SDK 问题，无论使用 Zoom 的用户有没有注册 Facebook 账户，Zoom 内嵌的这个脸书 SDK 都会向 Facebook 传递用户的手机型号、时区、所在城市、运营商以及广告唯一标识符等信息。

第二：Zoom 隐私政策内容不甚明确，特别是对于第三方 SDK 的描述部分。

虽然 Zoom 的隐私政策有提及“当用户使用脸书帐号登录时，将会收集用户脸书帐号的个人资料”，但是，对于如何使用第三方 SDK 的内容，可能并没有比较清楚地向用户进行描述，一些没有脸书帐号的用户，也会因为这个内嵌的 SDK 而接受到相关的推送信息等。据媒体报道，随后，Zoom 虽然发表了相关声明，但同时也在 iOS 客户端移除了脸书的 SDK。

关于第一点，与整体的安全保护方案（开发设计、测试、发布和运维全生命周期的安全保护）相关，我们暂不讨论，而引起我们思考的是第二点，关于 App 中如何做好 SDK 合规的问题。

SDK 究竟是什么？

谈所谓的合规之前，我们还是先来扒一扒什么是 SDK。其实关于 SDK 的介绍市面上挺多的，我们也扼要概括一下。

SDK 即软件开发工具包（Software Development Kit），是软件工程师用于为特定软件包、软件框架、硬件平台、作业系统等创建应用软件的开发工具集合，开发者无需了解 SDK 内部实现细节，只需要调用程序接口，便可以帮助 App 实现登陆分享、支付、广告、数据统计、地图、风控插件等一系列功能。

一般而言，SDK 供应商开发出各种类型 SDK 后，会上传到开发者社区或者其他发布渠道，企业或个人开发者将这些 SDK 集成到 App 中后会把这些 App 再发布到应用商店，供最终用户从应用商店下载这些 App 使用。在这个链条中，SDK 供应商将自身的数据和能力提供给企业和个人开发者，企业和个人开发者利用这些数据和能力使自己的产品变得更加丰富，更加多元化，同时又降低了自己的开发成本。

虽然说 SDK 是现在各类 App 不可或缺的小伙伴，但是这里要注意，因为 SDK 自身就具备获取相当一部分设备信息和用户个人信息的能力，所以存在对应的违规收集和使用个人信息的风险。例如，在上述场景下的 SDK 就需要引用方采取适当的安全防护措施，保障所引用 SDK 的安全性。

SDK 的供应路径

1. SDK 都有哪些类型？

为了审视 SDK 相关的安全问题，根据使用形态对 SDK 进行分类

引入 SDK: 自身应用中集成引入的第三方 SDK（ZOOM）

外发 SDK：将自身业务服务封装，发布出去给第三方厂商调用使用的 SDK

2. SDK 有哪些神通广大的功能？

SDK 根据功能的不同可以分为推送、通信、存储、安全、地图及位置服务、统计及增长、社交、广告、语音识别、图像识别等种类。

例如金融行业的开放银行领域，银行业者通过将自己的业务服务和数据服务封装到一个 SDK 中，实现向第三方合作伙伴提供开放金融能力。

3. SDK 都收集哪些信息？（通过 Android 提供的标准系统加入平台获取）

应用信息类：到用户手机上已经安装的 App 信息列表和正在运行的应用列表

账号信息类：用户账号信息

网络相关信息类：用户移动设备的联网信息、用户通信的设备信息、GPS、NFC 信息等

设备信息类：用户移动设备标识信息、SIM 标识信息等

传感器信息类：不同型号的移动设备，集成传感器的数量与种类也有所区别，比如用户的行踪可以通过位置传感器精确追踪

第三方 SDK 的应用现状是怎么样的？

近日，南都个人信息保护研究中心、中国金融认证中心（CFCA）对 60 款常用 App 以及主流 SDK 进行了测评。发现了目前 SDK 使用过程中的部分问题。

问题包括：

1. App 使用 SDK 数量较多。每款 App 携带的 SDK 平均不少于 10 款。其中消息推送类 SDK 最多，综合类和辅助开发类其次。

2. SDK 获取的客户的部分个人信息并未在《隐私权政策》中明确告知并说明使用目的。影响了用户的知情权。

3. 收集了超出必要范围的客户信息。

App 中使用第三方 SDK 的数量分布图

数据来源：南都智库《2019个人信息安全年度报告》

第三方 SDK 主要存在哪些安全隐患？

1. 隐瞒收集个人信息的情况

前面提到过，第三方 SDK 和 App 一样，也是具有收集用户个人信息的能力的，但究竟这个小玩意（SDK）究竟收集了哪些个人信息，从用户的层面来看其实是很难有感觉的，甚至 App 的运营者或开发者也未必全都知道。一旦这个第三方 SDK 在没有经过用户同意的情况下，就收集了各类与用户密切相关的敏感信息，例如银行账号，生物特征信息等，并传输到其他服务器甚至境外，将会引发极大的个人数据隐私风险。

2. 程序自身存在安全漏洞

目前，已经发现的 SDK 安全漏洞包括 HTTP 误用，SSL/TLS 不正确配置、敏感权限滥用、通过日志造成信息泄露等。如果一个 App 嵌入的第三方 SDK 越多，它的安全漏洞可能就越明显，影响范围也就越大了。

3. 恶意 SDK 导致软件供应链污染

比如说，“引入 SDK”的主要安全风险来自 SDK 自身的恶意行为。由于 Android 操作系统带有热更新机制，这使得一部分恶意 SDK 在客户集成阶段会表现为一个非常正常的应用，而一旦应用发布后到了运行阶段，攻击者就会通过热更新机制，更新恶意代码，执行盗取用户数据、采集敏感信息等恶意行为。这种发布后作恶的行为在很大程度上绕过了发布前的静态检测，具有非常大的迷惑性，也使得其作恶行为更加难以被发现。

而“外发 SDK”的风险则主要存在于在发布后的运行阶段，极容易遭遇剥离、破解、注入、调试和渗透测试等运行时攻击行为。

对于 App 开发者使用

SDK 的合规思路扼要分析

合规总思路：

首先分析嵌入的是哪种类型的 SDK

根据不同 SDK 的具体特性，区分第三方 SDK 的角色

根据 SDK 角色的不同，进一步分析第三方 SDK 需要承担的责任

合规分析流程图：

1. 第三方 SDK 是否有收集个人信息行为？

如有，则需进一步分析该第三方 SDK 是自动收集的，还是通过其所依附的宿主 App 收集的。

如否，属于功能性 SDK。

2. 第三方 SDK 收集个人信息的行为是通过其所依附的 App 主动获取的，还是该第三方 SDK 自行收集的？

如果是通过 App 主动获取的，并将收集到的个人信息共享给第三方 SDK，属于间接收集类 SDK。

此时，该 App 需要在隐私政策向用户告知第三方 SDK 的名称、收集个人信息的目的、方式和范围等；

如果是该第三方 SDK 自行收集的，则需要进一步分析该第三方 SDK 是否与宿主 App 为共同控制者。

3. 第三方 SDK 自行收集个人信息时，如果宿主 App 关闭相应收集权限，该第三方 SDK 是否还能继续收集个人信息？

如是，属于直接收集类 SDK。

如否，则具体要看第三方 SDK 与宿主 App 的具体协议约定，判断是否为共同控制者。

第三方 SDK 合规分析流程图

对于 App 开发者使用 

SDK 有哪些合规建议？

1. 对于间接收集类 SDK

一些常见的情况是，第三方 SDK 只是作为受宿主 App 委托处理数据的数据处理者时，由于用户难以感知这些 SDK 对个人信息的收集情况，且第三方 SDK 也不会用自己的名义收集个人信息，这时，App 运营者/开发者就特别需要注意，把如何向第三方 SDK 分享个人信息的情况告知用户，并获得用户的有效同意了，例如通过弹窗告知、增加链接等不同方式。同时，根据最新出的网络安全标准实践指南——《移动互联网应用程序（App）个人信息安全防范指引（征求意见稿）》的规定，也要求了需要对嵌入的收集用户个人信息的第三方 SDK 进行披露，告知第三方 SDK 类型，及收集使用的个人信息的目的、方式和范围。特别在涉及敏感信息时，还需要告知接收方的身份和数据安全能力，并征得明示同意，当用户撤回同意后，还需要帮助用户删除在第三方 SDK 的相关数据。

2. 对于直接收集类 SDK

当这些嵌入到 App 中的第三方 SDK 直接收集个人信息，并用自己的名义向用户提供服务时，由于第三方 SDK 露出对应品牌，用户其实对于这类的 SDK 是有明显的感知的，此时的第三方 SDK 较大程度成为个人信息控制者，在收集用户个人信息时候，需要向用户告知并获得用户的同意。

这里也要特别注意的是，当第三方 SDK 也可能与 App 开发者进行信息共享的时候，建议采取三重授权原则，即用户授权+平台授权+用户授权，以便解决合法授权的问题。

3. 对风险等级进行评估

建议 App 运营者/开发者对第三方 SDK 进行安全评估和风险等级评估，包括对代码进行审计和对漏洞进行检测，进而评估该 SDK 来源的可靠性、代码的安全质量以及对应的潜在安全风险。比如说，可以对 SDK 所收集的个人信息的字段等具体应用场景进行安全评估，遵循最小化权限使用原则等。举一些例子如下：

（1）采集用户移动设备上已经安装的应用信息、安装列表。

通过采集手机 App 安装的应用程序列表，从而了解用户的生活习惯、爱好等，实际上侵犯了用户的隐私。

风险级别：极高

（2）采集移动设备正在运行或最近运行的程序任务信息。

通过采集用户手机设备的应用情况，包括启动次数、时长等信息进行记录分析，同样数据侵犯用户隐私。

风险级别：高

（3）采集用户移动设备账户信息。

账户信息也同样具备敏感性，尤其是当账户信息与设备信息进行关联，必然导致客户的账户安全受到不同程度的影响，甚至导致用户的利益损失。

风险等级：极高

但现实中，确实也存在比较难地通过技术检测逐一去核实 SDK 的合规性和安全性，此时，仍然建议可以通过与 SDK 供应商签订合同或承诺保证函等方式，约定 SDK 供应商的权利和义务。

总体来说，从数据合规及安全的角度，客户的个人信息并非不能收集，而是要遵循合法、正当、必要的原则，在获取用户信息前征得用户同意。另外在获取用户个人信息后，应当按照相应的标准进行存储和管理，避免用户因此遭到信息的泄露。一旦 App 接入的 SDK 存在问题，则第一责任主体为 App 运营主体。例如，通过制作、发布、吸引 App 嵌入含有恶意代码的第三方 SDK，那么用户首先可追究 App 运营者的责任，App 运营者和 SDK 提供者对用户损失承担连带赔偿责任。当然，也有连带责任的例外，当第三方 SDK 与用户单独授权获取用户信息，在用户与 SDK 提供者之前因客户信息授权、使用的责任由用户与 SDK 使用者之前自行处理。

在监管上有哪些对策建议吗？ 

对于 SDK 的监管，比较可能成为接下来的监管热点，从目前公开的一些资料来看，在监管上的对策建议概括总结如下：

1. 制定 SDK 安全评估标准

目前尚无明确的 SDK 安全评估标准规范可以评估和识别 SDK 厂商是否符合安全标准，这就势必导致部分不合规的 SDK 厂商由此钻漏洞，“私携”客户信息、或留“后门”等。监管部门应尽快制定安全评估标准，引导 App 运用者识别不良 SDK 厂商，避免用户信息泄露或造成用户风险损失。

2. 引入第三方 SDK 独立监管体制

目前监管部门把重点放在 App 上，想通过 App 对 SDK 进行管理和监督。但实际头部 SDK 比 App 更强势，很多 App 运营者无技术能力和监控手段对 SDK 进行监督和管理。因此由监管部门直接管理或许更有利于行业的健康发展。特别需要注意的是，SDK 独立监管并不意味着 App 运营者无责任，同样应当对接入的 SDK 进行评估和管理，当因 App 运营者疏忽或者故意引入不当 SDK 造成客户损失的情况下，仍应按照《民法》等相关法律承担相应的赔偿责任。

参考资料：

1. 安全内参：关注 App 嵌入第三方 SDK 收集使用个人信息的安全隐患

2. 《SDK安全与合规白皮书》

【声明】本文内容可能会因法律法规修改而变更，司法实践中依个案实际情况来处理。本文仅代表作者目前所持的理论观点，不代表作者供职机构或其他相关机构的意见。本文仅为交流之用，所有内容不构成对任何个案的意见、建议或观点。作者和发布平台明示不对任何根据本文任何内容的作为或不作为所导致的后果承担责任。

推荐阅读

商务合作

Cassie | 微信：18506490569

媒体咨询

Ares | 微信：18606066421

开发者对接

唐迟 | 微信：15605086341

长按图片扫码

加入白鲸社群