互联网企业应当如何建设数据安全体系？

　　原文标题：互联网企业：如何建设数据安全体系?

　　作者：赵彦，现任美团点评集团安全部高级总监，负责集团旗下全线业务的信息安全与隐私保护。

　　一、背景

　　Facebook数据泄露事件一度成为互联网行业的焦点，几百亿美元市值瞬间蒸发，这个代价足以在地球上养活一支绝对庞大的安全团队，甚至可以直接收购几家规模比较大的安全公司了。

　　虽然媒体上发表了很多谴责的言论，但实事求是地讲，Facebook面临是一个业界难题，任何一家千亿美元的互联网公司面对这种问题，可能都没有太大的抵抗力，仅仅是因为全球区域的法律和国情不同，暂时不被顶上舆论的浪尖罢了。但是全球的趋势是越来越重视隐私，在安全领域中，数据安全这个子领域也重新被提到了一个新的高度，所以笔者就借机来说一下数据安全建设。(按照惯例，本文涉及敏感信息的部分会进行省略处理或者一笔带过。)

　　二、概念

　　这里特别强调一下，“隐私保护”和“数据安全”是两个完全不同的概念，隐私保护对于安全专业人员来说是一个更加偏向合规的事情，主要是指数据过度收集和数据滥用方面对法律法规的遵从性，对很多把自身的盈利模式建立在数据之上的互联网公司而言，这个问题特别有挑战。有些公司甚至把自己定义为数据公司，如果不用数据来做点什么，要么用户体验大打折扣，要么商业价值减半。GDPR即将实施，有些公司或将离场欧洲，就足见这件事的难度不容小觑。当然市场上也有一些特别推崇隐私保护的公司，他们很大程度上并不能真正代表用户意愿，而只是因为自家没有数据或缺少数据，随口说说而已。

　　数据安全是实现隐私保护的最重要手段之一。对安全有一定了解的读者可能也会察觉到，数据安全并不是一个独立的要素，而是需要连同网络安全、系统安全、业务安全等多种因素，只有全部都做好了，才能最终达到数据安全的效果。所以本文尽可能的以数据安全为核心，但没有把跟数据安全弱相关的传统安全体系防护全部列出来，对于数据安全这个命题而言尽可能的系统化，又避免啰嗦。另外笔者也打算在夏季和秋季把其他子领域的话题单独成文，譬如海量IDC下的入侵防御体系等，敬请期待。

　　三、全生命周期建设

　　尽管业内也有同学表示数据是没有边界的，如果按照泄露途径去做可能起不到“根治”的效果，但事实上以目前的技术是做不到无边界数据安全的。下图汇总了一个全生命周期内的数据安全措施：

　　数据泄露有一部分原因是用户会话流量被复制，尽管有点技术门槛，但也是发生频率比较高的安全事件之一，只是是很多企业没有感知到而已。下面从几个维度来说明数据采集阶段的数据保护。

　　流量保护

　　全站HTTPS是目前互联网的主流趋势，它解决的是用户到服务器之间链路被嗅探、流量镜像、数据被第三方掠走的问题。这些问题其实是比较严重的，比如电信运营商内部偶有舞弊现象，各种导流劫持插广告(当然也可以存数据，插木马)，甚至连AWS也被劫持DNS请求，对于掌握链路资源的人来说无异于可以发动一次“核战争”。即使目标对象IDC入侵防御做的好，攻击者也可以不通过正面渗透，而是直接复制流量，甚至定向APT，最终只是看操纵流量后达到目的的收益是否具有性价比。

　　HTTPS是一个表面现象，它暗示着任何互联网上未加密的流量都是没有隐私和数据安全的，同时，也不是说有了HTTPS就一定安全。HTTPS本身也有各种安全问题，比如使用不安全的协议TLS1.0、SSL3，采用已经过时的弱加密算法套件，实现框架安全漏洞如心脏滴血，还有很多的数字证书本身导致的安全问题。

　　全站HTTPS会带来的附带问题是CDN和高防IP。历史上有家很大的互联网公司被NSA嗅探获取了用户数据，原因是CDN回源时没有使用加密，即用户浏览器到CDN是加密的，但CDN到IDC源站是明文的。如果CDN到源站加密就需要把网站的证书私钥给到CDN厂商，这对于没有完全自建CDN的公司而言也是一个很大的安全隐患，所以后来衍生出了Keyless CDN技术，无需给出自己的证书就可以实现CDN回源加密。

　　广域网流量未加密的问题也要避免出现在“自家后院”——IDC间的流量复制和备份同步，对应的解决方案是跨IDC流量自动加密、TLS隧道化。

　　业务安全属性

　　在用户到服务器之间还涉及两个业务安全方向的问题。第一个问题是账号安全，只要账号泄露(撞库&爆破)到达一定数量级，把这些账号的数据汇总一下，就必定可以产生批量数据泄露的效果。

　　第二个问题是反爬，爬虫的问题存在于一切可通过页面、接口获取数据的场合，大概1小时爬个几百万条数据是一点问题都没有的，对于没有彻底脱敏的数据，爬虫的效果有时候等价于“黑掉”服务器。账号主动地或被动地泄露+爬虫技术，培育了不少黑产和数据获取的灰色地带。

　　UUID

　　UUID最大的作用是建立中间映射层，屏蔽与真实用户信息的关系链。譬如在开放平台第三方应用数据按需自主授权只能读取UUID，但不能直接获取个人的微信号。更潜在的意义是屏蔽个体识别数据，因为实名制，手机号越来越能代表个人标识，且一般绑定了各种账号，更改成本很高，找到手机号就能对上这个人，因此理论上但凡带有个体识别数据的信息都需要“转接桥梁”、匿名化和脱敏。譬如当商家ID能唯一标识一个品牌和店名的时候，这个原本用于程序检索的数据结构也一下子变成了个体识别数据，也都需要纳入保护范畴。

　　五、前台业务处理

　　鉴权模型

　　在很多企业的应用架构中，只有在业务逻辑最开始处理的部分设置登录态校验，后面的事务处理不再会出现用户鉴权，进而引发了一系列的越权漏洞。事实上越权漏洞并不是这种模型的全部危害，还包括各种K/V、RDS(关系型数据库)、消息队列等等，RPC没有鉴权导致可任意读取的安全问题。

　　在数据层只知道请求来自一个数据访问层中间件，来自一个RPC调用，但完全不知道来自哪个用户，还是哪个诸如客服系统或其他上游应用，无法判断究竟对当前的数据(对象)是否拥有完整的访问权限。绝大多数互联网公司都用开源软件或修改后的开源软件，这类开源软件的特点是基本不带安全特性，或者只具备很弱的安全特性，以至于完全不适用于海量IDC规模下的4A模型(认证、授权、管理、审计)。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!