App安全合规的思考(六)SDK合规 – 作者:Moench

App安全合规的思考(一):APP安全认证的工作流程梳理
App安全合规的思考(二) 监管的重点变化梳理
App安全合规的思考(三)如何做好App整改应急响应工作
App安全合规的思考(四) 权限问题
App安全合规的思考(五)隐私合规产品调研
App安全合规的思考(六)SDK合规

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.1 背景

在说解决方案之前,先来看一下一个App的组成情况,以渠道游戏包为例:

image

通过上图可以清晰的划分为:渠道SDK(其实也是第三方SDK,但渠道SDK在各个渠道不同)、第三方SDK、自研SDK,可通过分别对渠道SDK、母包、自研SDK、第三方SDK进行把控。

4.2 及时更新

其实,现在很多家SDK提供者都在为了更合规而优化产品,SDK迭代的速度很快,保持SDK的随时更新并参见其定制的合规指南,可以解决一部分合规问题。

4.3 安全评估

虽然问题很多,但是解决办法始终是一样的——做安全评估,推动提供者整改,在公司内把控接入。《移动互联网应用程序(App)使用软件开发工具包安全指引》里还列了其他8想,详见5.2 App 提供者安全措施的内容。

SDK安全评估

来源性评估:包括但不限于:SDK提供者的基本信息;SDK提供者的沟通反馈渠道;SDK隐私政策链接地址;提供者的安全能力;SDK的基本功能;SDK的版本号等。

代码安全性评估:是否存在已知的恶意代码;是否存在已知的安全漏洞;是否申请敏感权限;是否嵌入了其他SDK等。

行为安全性评估:调用的敏感权限、目的和频率;收集的个人信息类型、目的和频率;个人信息回传服 务器域名、IP地址、所在地域;是否在热更新行为及热更新是否可主动关闭;传输数据是否加密;是否存在单收集用户个人信息的界面;是否存在后台自启动和关联启动后收集个人息的行为等。

对集成后的SDK进行持续动态监测或定期进行安全评估。

4.3.1 来源性评估

针对在用SDK进行基本信息梳理,包括:SDK名称、版本、公司名称、公司资质、是否签署数据处理协议、隐私政策、合规指南、SDK安全性资质、沟通回复速度、是否有发生过安全事件等。

根据这些信息就可以有些动作了,比如没有隐私政策的沟通SDK提供方添加,回复速度慢(不配合)尽量业务推动暂停使用……

这个步骤获取的信息还可用于隐私政策披露。

4.3.2 代码安全性评估

(我是菜鸡,不会审代码,并且是合规篇,这个先忽略吧)

4.3.3 行为安全性评估

Step1:针对4.1.1中来源性评估,从SDK提供方获取权限及个人信息收集的情况。

Step2:对SDK打DEMO包逐一进行测试,主要关注权限索取、个人信息收集情况(同意前、同意后)。

Step3:比对合规指南披露的情况与实际情况是否一致,实际情况只能比官方披露的少不能多。

通过上述三种评估的评估结果,即可对SDK有了一个初始的判定,合规SDK接入,不合规SDK整改或拒绝接入。

4.4 《隐私政策》对使用第三方SDK的使用情况披露详尽

对第三方SDK的基本情况调研(网站、合规指南、数据处理协议等等)获取的信息+测试结果信息,就是最终需要对外披露的信息了,这里会存在披露颗粒度的问题,是披露到大类还是到字段需要自己把控。

《信息安全技术 移动互联网应用程序(App)SDK安全指南》中附录D给出了一个披露第三方SDK的示例表格(很细),包括SDK名称、命名空间、公司名称、SDK用途、收集个人信息、申请权限情况、隐私政策链接。
image

4.5 持续性合规

指南说对“集成后的SDK进行持续动态监测或定期进行安全评估”,一般触发安全评估是在SDK版本发生变化的时候。当然还可以根据情况增加一起触发安全评估的场景,如接入方式发生变化、年度评估等等。

4.6 形成管理机制

如果有额外人力,可以趁热打铁,和公司供应商管理一样,制定一套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提供中大部分还是很配合的,有问题可以通过多沟通的方式解决~

写在最后

正应该是这个系列最后一篇文章了,本人不是专业律师,有些语言组织的没那么专业,全部都是在实践中的一些经验,如果有任何问题可以一起交流~

来源:freebuf.com 2021-07-09 15:34:34 by: Moench

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享