本文发布在Freebuf:https://www.freebuf.com/articles/compliance/280167.html
0 前言
软件开发工具包(Software Development Kit,简称SDK)因其可以简化开发提高运营效率近几年被广泛使用,但因SDK提供者安全意识淡薄、市场监管力度低,从而出现安全漏洞、恶意行为、违法违规收集用户个人信息等安全问题
自2020年315晚会爆第三方开发的SDK违规收集用户个人信息的情况后,监管力度才逐渐加强。虽然监管重心依旧在App开发及应用平台方,但迫于App接入方和监管方压力,SDK提供方也在积极配合整改,如设立SDK合规专区、增强提示告知开发者完成合规指引、更新合规性SDK等等。
1 参考
参考为什么前边,不放文末?因为重要呀。
本文主要参考一下三个规范,里边有很多详细的内容,在下文中没有摘出来特别说明,可以提前下载学习。
《信息安全技术 移动互联网应用程序(App)SDK安全指南征求意见稿》
《移动互联网应用程序(App)使用软件开发工具包安全指引》
《软件开发包sdk安全与合规报告2020》
2 SDK分类
目前从功能性划分,有分享、支付、推送、统计、广告、地图等,但同一个公司有很多业务开发人员不同,选择接入的厂商不同,可能会导致同功能类型的接入了很多,解决办法可以考虑建立SDK管理机制(相信公司都有供应商管理机制,套用下)。
为了方便App开发者,有些SDK提供者聚合了同功能但又不能互相替代的SDK,形成了新的SDK,如xx社会化分享SDK(微博、微信、QQ等)、xx推送(小米推送、华为推送等)、x验(移动、联通一键等登录等)。
此外,还要单独提一类聚合类SDK——渠道联运SDK,主要集成了账号SDK、支付SDK,还有数据后台统计等功能。但是每个App如果要上不同渠道,都需要接入该渠道指定的SDK。
3 目前遇到的问题
SDK存在违法违规收集用户个人信息以及索权情况肯定是根本问题,这里列出的是这一根本问题引发的一些连带问题。
SDK提供方缺乏合规专业人员,对于SDK的合规性把控力度不够;
SDK提供方合规性动作滞后,很多是接入方推动其整改,并且部分SDK提供方整改配合度不够;
SDK提供方对其SDK合规性的披露颗粒度不够(华为写得就很好,权限和个人信息一目了然)
SDK接入方隐私政策披露颗粒度存在问题,SDK外接的SDK是否需要披露;
SDK版本在迭代,如何保障持续性合规;
App上n渠道,上架前要打不同的渠道包,最后每个App就会有N个,如何保证每个包体的合规;
4 解决方案
4.0 背景
在说解决方案之前,先来看一下一个App的组成情况,以渠道游戏包为例:
通过上图可以清晰的划分为:渠道SDK(其实也是第三方SDK,但渠道SDK在各个渠道不同)、第三方SDK、自研SDK,可通过分别对渠道SDK、母包、自研SDK、第三方SDK进行把控。
4.1 安全评估
虽然问题很多,但是解决办法始终是一样的——做安全评估,推动提供者整改,在公司内把控接入。《移动互联网应用程序(App)使用软件开发工具包安全指引》里还列了其他8想,详见5.2 App 提供者安全措施的内容。
- SDK安全评估
- 来源性评估:包括但不限于:SDK提供者的基本信息;SDK提供者的沟通反馈渠道;SDK隐私政策链接地址;提供者的安全能力;SDK的基本功能;SDK的版本号等。
- 代码安全性评估:是否存在已知的恶意代码;是否存在已知的安全漏洞;是否申请敏感权限;是否嵌入了其他SDK等。
- 行为安全性评估:调用的敏感权限、目的和频率;收集的个人信息类型、目的和频率;个人信息回传服 务器域名、IP地址、所在地域;是否在热更新行为及热更新是否可主动关闭;传输数据是否加密;是否存在单收集用户个人信息的界面;是否存在后台自启动和关联启动后收集个人息的行为等。
- 对集成后的SDK进行持续动态监测或定期进行安全评估。
4.1.1 来源性评估
针对在用SDK进行基本信息梳理,包括:SDK名称、版本、公司名称、公司资质、是否签署数据处理协议、隐私政策、合规指南、SDK安全性资质、沟通回复速度、是否有发生过安全事件等。
根据这些信息就可以有些动作了,比如没有隐私政策的沟通SDK提供方添加,回复速度慢(不配合)尽量业务推动暂停使用……
这个步骤获取的信息还可用于隐私政策披露。
4.1.2 代码安全性评估
(我是菜鸡,不会审代码,并且是合规篇,这个先忽略吧)
4.1.3 行为安全性评估
Step1:针对4.1.1中来源性评估,从SDK提供方获取权限及个人信息收集的情况。
Step2:对SDK打DEMO包逐一进行测试,主要关注权限索取、个人信息收集情况(同意前、同意后)。
Step3:比对合规指南披露的情况与实际情况是否一致,实际情况只能比官方披露的少不能多。
通过上述三种评估的评估结果,即可对SDK有了一个初始的判定,合规SDK接入,不合规SDK整改或拒绝接入。
4.2 《隐私政策》对使用第三方SDK的使用情况披露详尽
对第三方SDK的基本情况调研(网站、合规指南、数据处理协议等等)获取的信息+测试结果信息,就是最终需要对外披露的信息了,这里会存在披露颗粒度的问题,是披露到大类还是到字段需要自己把控。
《信息安全技术 移动互联网应用程序(App)SDK安全指南》中附录D给出了一个披露第三方SDK的示例表格(很细),包括SDK名称、命名空间、公司名称、SDK用途、收集个人信息、申请权限情况、隐私政策链接。
4.3 持续性合规
指南说对“集成后的SDK进行持续动态监测或定期进行安全评估”,一般触发安全评估是在SDK版本发生变化的时候。当然还可以根据情况增加一起触发安全评估的场景,如接入方式发生变化、年度评估等等。
4.4 形成管理机制
如果有额外人力,可以趁热打铁,和公司供应商管理一样,制定一套SDK管理机制,包括SDK准入、SDK评估、SDK退出等等过程。
统一管理第三方SDK有如下好处:
- 可以随时了解业务SDK接入情况。
- 减少测试、管理、推动整改等人力成本。
- 既能优质SDK全公司共享,还可以较少支出成本。
- ……
5 碰到过的关于SDK的问题
5.1都是在接入第三方SDK,有些被认定为为委托处理有些被认为是共享,怎么区分?
有些SDK提供者确实不好区分,根据《软件开发包SDK安全与合规指南》中5.2.1的解释,认定“当第三方 SDK 可以直接透过 App 露出自己品牌时,App 开发者更容易让 SDK 提供方独自成为个人信息的数据控制者,应当在 App 《隐私政策》的共享章节或者展示 SDK 的专门章节介绍 App 接入了哪 些具体的第三方 SDK、向这些第三方 SDK 共享个人信息的目的、功能、 范围、开启权限等情况、第三方 SDK 的隐私政策情况(如有);如果在披露第三方 SDK的隐私政策时,可实现跳转至第三方 SDK官方服务页面的,建议向用户直接展示该第三方 SDK 的《隐私政策》。”
白话就是,有品牌露出就认定为数据共享,没有品牌露出就认定为数据委托处理。比如使用三方登录跳转到第三方App、再比如分享会跳转到第三方App。
5.2 App本身根本用不到因为打了某三方SDK中的功能和权限,应该怎么办?
其实,有些第三方SDK是可以提供更合规版本的(未上线),可以和客服/商务沟通获取;有些三方SDK Demo中申明的必要权限在和客服/BD沟通,在不影响业务的场景下可以不声明。
我遇到过得,比如ym收IDFA,但通过沟通对方提供不收的版本的;gd收精准地理位置,但业务功能场景就是地区排名,粗略位置足矣,后联系可以不声明精准地理位置权限。
在沟通过程中SDK提供中大部分还是很配合的,有问题可以通过多沟通的方式解决~
写在最后
本人不是专业律师,有些语言组织的没那么专业,全部都是个人在实践中的一些经验,如果有任何问题可以和我交流,~