一篇讲清:数据采集中的安全与隐私
1. 数据采集面临的安全与隐私挑战
不管是第三方分析工具,还是企业的第一方分析系统,在分析用户行为时,通常都会选择在客户端(一般是安卓、iOS 和 Web 端)采集用户的行为,然后经过打包、压缩等一系列处理步骤,发送给服务端,再进行存储和分析。由于客户端是在用户自己的网络环境下运行的,客户端与服务端之间的数据传输,是需要通过公网的,因此,也会带来一系列数据采集上的安全与隐私的问题。
这些问题包括:
- 数据采集的完整性问题:因为在客户端采集数据,为了保证尽量不影响用户体验,所以在采集数据时,一般不会同步发送数据,而是在本地先做缓存,然后再整体压缩、打包并在网络好时一起通过公网进行传输。如果客户端一直网络不好,传输失败时,则会累计在本地,而本地缓存会有限额,或者缓存数据全部发送完毕前,App 就被卸载则都会丢掉部分数据。在 Web 端使用 JS 传输数据时,虽然是同步发送,不过由于公网传输的网络问题,一般也会有 3% 到 7% 的数据丢失,并且基本难以避免。
- 数据采集的隐私性问题:第三方可能会在传输过程中截获传输的数据,从而拿到传输的这些用户行为数据。这些用户数据都是体现用户在客户端的一些具体的用户行为,蕴含着用户的隐私。
- 数据采集的准确性问题:第三方可能会在传输过程中伪造数据,从而让后台的分析结果不准确。这种伪造可能是直接调用传输的 API,可能是在多个模拟器上运行 App,甚至可能是直接人工作在真实设备上操作 App,都会导致传输到服务端的数据不准确。
在这三大类问题中,第二类问题由于涉及到用户隐私,所以一般会认为非常严重;第一类问题会影响最终分析结果的准确性,也应该尽量着力解决;而第三类问题,对于恶意第三方来说相当于是一个“损人不利己”的事情,对于很多并不出名的创业公司来讲一般也不会被人恶意针对,所以相对而言并没有那么严重。
2. 常见解决方案分析
2.1 使用 HTTPS 作为传输协议
HTTPS 是一种网络安全传输协议,它经由超文本传输协议(HTTP)进行通信,但利用SSL/TLS来对数据包进行加密。HTTPS开发的主要目的,是提供对网络服务器的身份认证,保护交换数据的隐私与完整性。
简单来说,不考虑太多技术细节,在有 HTTPS 作加密的情况下,可以认为,除了服务端与客户端,在中间的传输环节,是拿不到也无法修改传输的内容的,因此,采用 HTTPS 作为传输协议,可以很好地防止数据被窃取,神策分析(Sensors Analytics)也提供了采用 HTTPS 传输数据的方案。
由于依然是在客户端采集数据,依然是通过网络传输数据,所以采用 HTTPS 作为传输协议并不能解决数据完整性的问题。
同时,HTTPS 也不能阻止数据的伪造,伪造者在客户端是可以直接抓包拿到传输的内容的,从中获取传输 API 与传输协议后,就可以直接调用 API 通过 HTTPS 传输伪造的数据了,更别说通过模拟器运行 App 或者直接用机器运行 App 来伪造数据了。
2.2 传输内容加密
如前面所描述的那样,HTTPS 是在传输环节进行传输协议加密的,并不能阻止恶意第三方在客户端抓包获取数据,从而获取传输的内容与传输协议。因此,自然可以考虑更进一步,不仅仅通过传输协议加密,对于传输的内容也进行加密。
这样做的好处,是可以阻止恶意第三方拿到传输协议,从而没有办法通过直接调用 API 的方式来进行数据伪造,但是,对于模拟器运行 App 或者直接用机器运行 App 来伪造数据的手段,依然是无能为力。同时,对传输内容进行加密,也不能改变是在客户端采集数据,以及通过公网传输数据的本质,所以并不能解决数据完整性的问题。
与此同时,由于需要对传输内容进行加密,所以数据采集的代码和传输协议都不再能够开源了,否则就很容易被恶意第三方**加密方案。对于公司内部的第一方数据采集方案,并没有问题,但是,如果是第三方分析工具,它的代码如果不开源,一些对于安全与隐私比较敏感的客户,可能就不敢集成了。同时,由于传输协议不开源,也大大降低了系统的开放性。正因为这些原因,神策分析还是选择了优先保证 SDK 和传输协议的开放性,以打消客户集成 SDK 时的顾虑,所以并没有采用传输内容加密的方案。
2.3 后端采集
在后端采集数据,例如采集后端的日志,其实就是将数据采集的传输与加密交给了产品本身,认为产品本身的后端数据是可信的。而后端采集数据到分析系统中则是通过内网进行传输,这个阶段不存在安全和隐私性问题。同时,内网传输基本不会因为网络原因丢失数据,所以传输的数据可以非常真实地反应用户行为在系统中的真实体现。
因此,基于后端采集的上述优势,神策分析目前提供了 Java、PHP、Python、Ruby 等后端语言的 SDK,以及 LogAgent、BatchImporter、FormatImporter 等导入工具,支持在后端采集。
当然,对于模拟器运行 App 或者直接用机器运行 App 来伪造用户行为,由于后端拿到的就是伪造后的数据,所以对于这种伪造行为,依然是无能为力。
2.4 采集后再 antispam
对于之前提到的模拟器运行 App 或者直接用机器运行 App 来伪造用户行为这一类技术手段,只能依托于在采集数据后,再进行 antisapm 清洗数据。这些清洗有很多不同的策略,比较常见的有:
- 基于统计信息进行清洗:例如,把那些流量明显大于平均值的设备或者 IP 的用户行为过滤掉,把那些行为频率明显超过正常人限度的用户行为过滤掉等;
- 基于用户行为特征进行清洗:主要是用到一些机器学习的手段,通过对整体的用户行为进行训练,然后找到那些行为特征明显异于常人的用户;
- 基于设备真实性进行清洗:目前有一些第三方供应商提供了类似的方案,通过识别一个设备是一个真实的设备,还是一个模拟器,来解决虚拟机造假问题。
神策分析后面将会提供类似的 antispam 方案,并且将识别出来的用户作弊概率直接作为一个用户的 profile,以供使用者来选择使用。
3. 一些题外话
其实,除了数据采集这个环节以外,很多互联网产品,都会面临着网络传输中的“安全”与“隐私”这两类问题,而且也都会有所取舍与折衷。
我们以百度,这样一个典型的互联网产品为例,来看看它的网页端是如何选择来解决这些问题。
- 首先,百度选择了全站采用 HTTPS 进行加密,主要目的其实是为了避免第三方(如运营商等)篡改返回给用户的网页在其中加入第三方的广告,当然,这一做法,也客观保证了用户的操作不被第三方窃取;
- 其次,对于通过 Spider 等非人工的访问方式来抓取搜索结果的行为,则并没有在访问时就进行封禁等处理,而是在进行统计时再进行复杂的流量清洗等 antispam 手段,以获得准确的流量,这主要是为了在保持用户体验,避免因为误封禁而影响正常用户的访问,同时,也可以在后处理时可以加入复杂的策略保证最好的清洗效果;
- 第三,对于使用某些非法手段来对广告点击进行造假的行为,由于涉及到经济隐私,相比抓取搜索结果危害要更大,所以虽然都是采用后处理 antispam 的方式,但是时效性会更好,一般是会先做完 antispam,然后再扣费,从而避免作弊点击导致广告费用扣光,影响点击。广告点击的 antispam 是百度的核心策略与竞争优势,也是投入很多成本进行研发与维护的领域。
更多大数据分析干货与案例欢迎扫码关注“神策数据”公众号!
想直接了解神策数据?可扫描下方二维码~