如何利用云安全运营中心监测数据泄露

前言：

2019 年上半年数据泄露事件频出。

4 月，国内一大型二次元网站后台工程源代码被上传至 Github ；

5 月，三星手机厂商多个内部项目代码泄露，包括 SmartThings 敏感的源代码、证书和密钥。 近日，Verizon 发布的《 Verizon 2019 年数据泄露调查报告》对 41686 起安全事件进行分析，其中包括 2013 起已证实的数据泄露事件。

泄露事件层出不穷，作为一名安全攻城狮，除了当个吃瓜群众看热闹之外，我们能做些什么来强化自身能力呢？这里不准备大谈特谈数据安全治理、数据加密、脱敏之类的重性措施，仅仅从可实操、可运营的角度分享一些个人在云上做数据泄露监测的一些技巧和经验，希望能帮助到一些云上的用户。

0×00 适用对象

·业务上云的开发者、运维工程师、安全小白；

·业务跑在云上且对数据泄露较关注的企业；

0×01 数据泄露的“冷静三问”

·典型的数据泄露事件有哪些？

·数据泄露产生的主要原因是什么？

·为避免数据泄露事件，我们能做什么？

0×02 关于数据泄露那些事儿

1.数据泄露定义及常见分类

数据泄露的严格定义一般指“受保护或机密数据可能被未经授权的人查看、偷窃或使用”。而由于企业业务性质、开发制度等原因，互联网公司一般会涉及较多的版本变更，且大部分互联网企业内部崇尚开源文化，开放的同时，也为数据泄露事件的埋下隐患。

以近几年数据泄露的影响较大的几个事件案例来分，从泄露渠道上可以分类为：

Github 代码类数据泄露事件： 即由于人为有意或无意的上传了包含企业内部敏感信息的代码到 Github 网站，从而导致被外部攻击者获取到进行入侵利用。

案例：某大型二次元网站后台工程源代码被上传至 Github。

网站入侵类数据泄露事件： 往往由于网站或服务平台、App 等存在漏洞遭受攻击而导致数据丢失泄露。 案例：某大型技术社区网站六百万用户信息泄露。

网络黑市交易类泄露事件： 二手泄露渠道，指在地下交易市场上售卖和交易的数据泄露事件，其中数据来源渠道可能会有很多种，比如通过雇佣黑客社工获取到了数据服务器的权限，或通过内部暗箱操作获取到了内部数据等，这里的数据泄露事件往往以盈利为目的被在网络黑市渠道进行发布和售卖。 案例：国内某知名酒店住房数据泄露事件。

合作商接口类数据泄露事件： 由于合作商接口调用内部数据没有做好安全防护措施或监测，导致敏感数据通过合作商渠道泄露到了外部，这其中包含合作商恶意的和非恶意的，可能由于本身技术问题，也有可能非法利用这部分数据进行他用。 案例：剑桥分析公司不正当方式获取 5000 万 Facebook 用户个人信息 案例方面还有其他种种，这里不再一一举例。

2.数据泄露产生的根本原因是什么？

“策略”不规范，“企业”两行泪。

数据泄露的根本原因可能多种多样，总结起来，几乎都可以归类为两种，一种为企业对于数据的技术管控策略不足到导致的数据泄露，另外一种则是数据安全管理策略或制度上缺失导致敏感数据被未授权的访问。

技术方面，网站 /平台 /应用 /系统因为存在安全问题，如系统漏洞或配置失误、数据脱敏手段和数据加密措施缺失、异常操作审计手段缺失、敏感信息泄露发现机制缺失等，都可能导致攻击者利用获取到敏感数据；

管理方面，由于开发人员或实习员工安全意识薄弱、或对合作商缺乏数据使用约束条款或限制措施等，导致数据未授权公开或被非法滥用，也是导致数据外泄另外一大主要原因。

3.出现数据泄露事件，我们能做什么？ 数据可说是企业的核心生命线了，数据泄露事件的危害不言而喻，当企业出现泄露事件，虽不至于致命，但往往也让企业元气大伤。

大多数场景下，一般企业泄露的内容往往是部分较敏感数据，攻击者利用这部分数据可通过渗透或进一步挖掘获取到更为深层的敏感数据信息，据此，如果企业建立了敏感信息泄露监测体系，在出现泄露事件后能通过技术手段快速应对并积极开展自查修复，仍然能够起到“亡羊补牢”的作用，在黑客利用之前提前进行整改和加固防御，规避各类不必要的隐性风险，将损失降到最低。

上述提到了四种主流的数据泄露事件风险，因网站 /应用 /APP 漏洞引起的数据泄露，由于涵盖面涉及较多，这里不一一列举，且一般稍大型的企业内部安全体系也会将分网分域、入侵检测、加解密、数据库审计等基本措施覆盖得相对比较齐全，攻击者获取敏感数据难度也相对较大，合作商导致的数据泄露更多是在合同的条款缺失、数据共享脱敏上、接口权限上做一些控制，管理和技术上各占一部分，这里不再展开。

这里我们重点针对比较典型的、且危害较大的 Github 代码泄露、黑市数据交易这两种行为，探讨我们能够能在技术上落地的手段和管理上的控制思路。

技术管控策略

1 ）严禁员工私自搭建代码管理工具，需使用公司统一授权的代码管理工具(git,svn)进行代码管理；

2 ）严格管控项目代码权限，人员变动（转岗、离职）需及时回收代码权限；

3 ）大型项目使用 submodule （子模块）进行划分，对项目进行实行权限最小化原则；

4 ） 不把代码存放在外部网站，如：Github、Onedrive 等网站

5 ）对 Github、地下交易市场等网站进行敏感信息泄露监测，当出现敏感信息时，关注进行自查确认，避免问题扩散。

合规管理策略

1 ）制定《源代码开源安全管理》，开源需经过开源流程评估；

2 ）对合作商的接口的使用范围约束条款、限制或监督审计等

3 ）对内部员工的合同法律约束，高压线措施

合规管理策略一般涉及到企业的采购、法务等流程，这里暂不细说，技术管控策略前面 4 项偏向于事前，作为一个安全技术人员，比较好落地且运营效果比较好的是 Github 和网络黑市的泄露监测：即当发现有企业自身关注的敏感信息上传到公网时，安全人员能够快速了解，并展开处理。

“工欲善其事，必先利其器”，重复造轮子、从 0 到 1 去开发 Github 监测系统的人，这里太耗费工作量，个人不太推荐；将开源的系统拿过来自己用，虽然高效，但存在一定的部署维护成本，且部分系统的稳定性、安全性及 API 限频等问题也是后期解决起来比较麻烦的，很多企业往往考虑到系统自身安全性，会将系统部署在企业外部服务器，但是在真实运营过程中，会不利于企业进行统一运营管理。使用云平台 SaaS 化的服务形式，虽然可控性差了点，但短平快、轻量级的特点还是比较友好，也不需要太多的维护工作量。

这里以一个普通的云用户或企业为例，介绍下云上数据泄露监测的一些思路或方法。

0×03 关于泄露监测的安全运营平台

传统的泄露监测系统往往会固定死某几个监测特征(如云密钥、MySQL 密码泄露监测），腾讯云的安全运营中心对外免费开放了泄露监测功能，提供了相对比较灵活的规则配置，可以监测不同平台，不同数据库系统以及自定义特征的数据泄露。除泄露监测外，腾讯云安全运营中心还免费提供了另外一个比较实用的功能——安全情报，一个偏事前，一个偏事后。

由《 Verizon 2019 年数据泄露调查报告》中数据泄露威胁源头趋势图可见，内鬼及无意识管理员在最大的上升趋势，腾讯云安全运营中心数据泄露监测功能正是针对这一类。

这里分享下云鼎实验室工程师在代码泄露监测规则配置上的一些技巧。

1.使用方式

SaaS 化服务的优势是无需服务器、也无需代码部署、Github Token 申请调试等，使用起来快速便捷。整体大致分三部走：

Step1：一键点击开通

Step2：配置需要监测的规则关键字

Step3：查看泄露监测结果

详细操作步骤如下：

Step1：点击开通腾讯云-安全运营中心（免费，账户有无费用、机器都行）；

Step2：进入控制台，点击安全运营中心 > 产品设置 > 泄露监测> 添加，接下来进行 Github 和网络黑市监测的规则添加，添加过程会有示例模板，可作为参考；

Step3：添加完成后，任务应该在后台自动跑起来了，稍等一会后，可以点击左侧的泄露监测查看监测详细结果。

2.如何更好的配置监测规则？

腾讯云提供了比较灵活关键字配置，犹如一把锋利的武器，当关键字规则配置的好的时候，犹如高手使用，往往能够发挥巨大威力，如果规则关键字配置不当，可能起到的效果就很一般。

这里分享下云上 Github 泄露监测规则运营所积累的一些经验，供参考：

规则 1：基于云业务场景的规则——云 API 密钥规则

相信对于云用户而言，云 API 密钥的重要性不言而喻，如果泄露，危害巨大，但因业务需要，往往很多云用户在进行 API 调用时都会用到，因为开发的有意或无意中的一些操作，可能导致代码被上传到 Github，最终导致企业内部敏感代码泄露，这样的案例比比皆是，因此针对云 API 的密钥泄露监测规则十分必要。

以腾讯云为例，这里简单列举监测规则配置思路及步骤：

1、获取 SecretID：

2、将 SecretID 作为监测关键字进行配置 参考配置：AKIDmQtAxYTAB2iBS8s2DCzazxxxxxxxxxxxxx

优点：检查结果精准，干扰误报少。

缺点：暂无。

规则 2：基于帐号维度的规则——帐号 ID+帐号关键词

帐号类型极多，如数据库（ MySQL、MongoDB ）、网站后台登录模块帐号、中间件帐号等，具体可根据企业内部业务自身情况进行配置。

参考配置如下：

云帐号 appid/uin secretkey/qcloudAppId （云帐号 ID+关键字标识） 10332xxx password/mysql/passwd （数据库 /网站帐号 ID+关键字标识） 10332xxx login password/passwd （数据库 /网站 /帐号 ID+登录标识符+关键字）

优点：识别结果较为精确，干扰信息较少，误报少，方便快速定位分析。

缺点：有点繁琐，需要收集下内部部分数据库管理员或开发发布人员帐号 ID 信息，才能做到更精准识别。

规则 3：基于域名场景的规则——域名 /IP+业务关键字 /帐号组合

基于域名或 IP 场景应该是很多公司目前现有的做法，比如公司某个产品名称或内部域名、接口 API 域名，这种方式属于比较常见的、相对比较有效规则，在知道自己内部标准域名的情况下，配合帐号 ID 或部分关键字，可以相对比较全面的定位到受影响的代码。

参考配置如下：

console.xxx.com 云帐号 AppId/access_key （后台域名+帐号 /关键字） api.qcloud.com 云帐号 AppId/access_key （ API 域名+帐号 /关键字） xxxx-inc.com 帐号 ID/password/access_key （域名+帐号 /关键字） 10.23.xx.xx AppId/password/access_key/secretKey Qunar/bilibili/qq/alipay appid/password/access_key/secretKey （产品名+帐号 ID/关键字）

优点：优点是监测范围覆盖较全，漏报相对较少。

缺点：误报相对较多，关键字的组合需进行一定调整、优化和运营。

规则 4：其他场景的规则——开发人员英文名 /全拼+开发关键字+…

除了以上场景外，还有一些其他场景，如根据内部开发人员帐号+开发接口变量名的组合，或者加上数据库特征、用户名密码特征字段、Memcached、Redis、MongoDB 后台配置文件字段名等，这里可以自由组合搭配，灵活配置。

参考配置如下：

wangwu secret_key （开发人员姓名+密码特征字段） jackwang jdbc password （开发人员姓名+数据库特征+密码特征字段） account_name/id cursorclass password/passwd （数据库连接特征关键字+密码特征字段） account_name/id ConnectionPool password/passwd （数据库连接特征关键字+密码特征字段） account_name/id MongoClient password/passwd （数据库连接特征关键字+密码特征字段）

优点：能发现一些较为隐蔽的泄露，误报少。

缺点：需要基于企业情况，对涉及接口开发的人员、数据库开发人员帐户或 Memcached、Redis、MongoDB 登录字段信息进行简单梳理，并对组合规则进行运营，逐渐进行优化，消除误报。

3.注意事项

关于规则运营的建议

a)在配置规则过程中，腾讯云提供了规则命中数的字段，可以依据不同的规则命中数量查看泄露监测结果，并参考结果数量开展优化，这点对安全运营有比较大的参考意义；

b)建议多收集一些的数据接口特征作为关键字进行监测，如 cursorclass、MongoClient，ConnectionPool 等，配合内部域名、帐号密码关键字组合可以比较准确的监测到某类应用的敏感数据泄露，效果较好； c)如果真的出现泄露事件该如何处理？

1、发现有敏感信息泄露事件时，第一时间是通知开发确认，若属实则联系开发或作者在 Github 上进行删除或脱敏处理，当被 fork 到大量人员时或事件影响较大时，则可以考虑联系 GitHub DMCA （数字千年版权法案处理规则）向 GitHub 发送邮件进行处理，要求进行删除，并同时针对内部受影响系统开展自查，修改帐号密码等；

2、建立一套泄露监测处理规范，比如出现泄露后的敏感信息删除或修改，涉及敏感信息的系统或服务器的内部安全自查、内部的安全意识宣告，代码管理平台或工具建设等

d)除 Github 监测外，目前在腾讯云泄露监测关键字配置界面还可选择络黑市监测这一项，网络黑市监测的规则相对于企业而言相对会简单，可以根据企业名、域名、产品的思路开展络黑市的监测，这里不再展开赘述，感兴趣的朋友可以自己去尝试下。

0×04 思考及感悟

泄露监测是一个偏事后的安全策略，对于企业而言，虽不如渗透测试、漏洞扫描、WAF 等其他事前事中手段来的直接干脆，但根据安全的“木桶原理”，很多入侵往往不是因为大家所关注的各类高深的漏洞，而很可能是因为内部人员不小心的一次失误或误操作将具备高价值的内部信息或密钥外泄，导致入侵者轻松获取到这部分信息并顺藤摸瓜，最后获取到了比较重要的核心数据。

因此，敏感信息的泄露监测也是企业安全运营中的重要一环，在设置各类复杂的安全入侵防护策略和漏洞扫描规则的同时，企业也应投入一定精力去开展敏感信息泄露的监测和处置，通过把一类问题“全盘考虑，迭代运营”，在某种程度上才能说真正防范此类危机或风险，而不仅仅是搭建了一套系统。

0×04 写在最后

没有绝对的安全，如同没有绝对完美的安全系统，也因此，就有了安全运营的概念，即通过持续的运营对抗，来弥补企业安全体系木桶的“短板”（漏洞、弱口令）。

基于 SaaS 安全运营平台对于企业安全运营的收益，可以简单理解为以下几点：

1、Saas 化的服务省去了自身泄露监测系统的代码维护成本和服务器成本，能是企业开发者、运维者或安全管理员将更多精力集中在规则运营上；

2、与云平台能够更好的整合，开发，运维，事件处理集中在一处，提高处理效率；

3、在误报规则的运营处理上，SaaS 化的平台比开源系统运营更持久，基于云上用户的集中体验优化，及背后目前由云鼎实验室团队进行后台策略维护支持，误报问题应该会相对少一些，告警的质量相对较高。

由于企业安全建设过程中人员安全意识带来的安全问题是很常见的一块“短板”（ Github 泄露），常常被企业忽视，因此，笔者这里花了较多笔墨分享云上安全数据泄露监测的运营浅见和思路，希望对业务上云的开发者、业务跑在云上且对数据泄露较关注企业用户有帮助，相互学习，共同进步。