企业数据安全建设的经历与实践

前言

回想到自己刚到量化派任职安全总监的时候，记得领导就多次跟我提到过数据安全的事情：公司组建安全团队的起因就是因为有数据泄漏，希望安全团队能够从整体上去考虑和解决。 可那时安全工作却是刚从0到1的时候，不仅人手不够，很多时候都需要自己来处理，根本没有太多时间去整体思考和制定数据安全方案，待一些安全基础工作完成后，已经差不多是三个月后的事情了。所以整体来说，我们数据安全建设的时间周期其实并不长，大概半年左右，因此中间也难免会有不足或不周全的地方，欢迎讨论和指正。

本文目的：分享下数据安全建设实践中一些的思考和经验，希望对数据安全建设感兴趣的朋友有一些指导和帮助，同时也是对自己的总结。

本文题纲

1.为什么做

2.该怎么做

3.落地改造

4.问题与效果

1.为什么做

记得当时思考的第一个问题就是这个；我尝试按照自己的理解，从主观和客观两方面来阐述下理由：

• 企业的重视（主观）

安全对于企业高层而言，其实只有四层：基础安全，数据安全，业务安全，合规安全；基础安全基本无感，合规安全可能又有点偏虚，因此重心自然就落在了数据安全和业务安全上，而业务安全通常会由业务团队重点关注和反馈，因而数据安全就会成为安全团队的核心问题了；而且数据作为企业的核心资产，它不仅直观可见，加之近年来数据泄漏事件也较为频繁，领导们对数据安全的认识也是高度地一致，也有一些企业的领导对安全的诉求直接就是保障数据安全；因而数据安全也就成了甲方安全负责人绕不过去的坎，迟早是要面对的。

• 数据的价值（客观）

数据其实是对事实的一种客观表现以及量化描述，它作为原始材料，可以被人们进行消费和解释，从而创造出信息；信息它是指有上下文的数据，而它是有时效性的，通过对信息进行整合和归纳，使其有价值的部分沉淀下来，并形成一种观点，这样就可以获得知识，信息则是有助于知识的产生，而只有积累到足够多的知识最终才能内化成智慧。举个安全方向的例子，如下：

1. IP地址8.8.8.8，攻击次数1000，它们都是数据；

2. 通过增加上下文内容成为信息，比如，时间和相关性，信息：今天IP地址8.8.8.8攻击次数为1000

3. 通过增加趋势判断对信息进行整合并形成观点，比如，我们收集了半年的数据，每天这个IP地址8.8.8.8的攻击次数都大于1000，那么我们就可以推断该IP为恶意IP，并可形成黑IP知识库

由此，可以看出它们之间的关系，如下：

总结下，也就是说数据是信息、知识和智慧的基础，积累行业数据它是能够帮助企业在该领域变得更聪明更智慧；数据的价值是无可替代的。

2.该怎么做

也许一提到数据安全，我们会很自然地想到数据的全生命周期：采集、传输、存储、使用、销毁，然后围绕数据生命周期中的每个阶段来进行安全方案的设计和落实；但在实际的实践中，我们可能并没有足够的精力和成本进行全部覆盖，为了解决安全问题，同时保证一定的效果；在数据传输和数据存储得到基础保障后，我们就将重心转向到了数据使用上，所以这里所说的数据安全建设经历也会更多地聚焦在数据使用过程。

2.1 数据界定

在数据安全建设中，我们首先需要清楚保护的数据对象以及数据范围，主要了解这些数据对象都存储在哪些位置，

数据对象

• 结构化数据

• 指可以使用关系型数据库表示和存储，表现为二维形式的数据。一行数据表示一个实体的信息，比如，用户信息，订单信息等。

• 半结构化数据

• 属于结构化数据的一种形式，但它并不符合关系型数据库的数据模型结构，它主要通过标记，来分隔语义元素以及对记录和字段进行分层描述。常见的半结构数据有XML和JSON，比如，日志和流量，这类信息用该数据形式来描述就会更加方便。

• 非结构化数据：

• 各种文档、图片、视频/音频等都属于非结构化数据，没有固定结构的数据。

数据位置

其次就是数据对象存储的位置，它作为数据的载体，也是数据的核心源头，结构化和半结构化的数据通常会以数据库的形式进行存储，而非结构化数据则通常会在办公终端进行流转。 因此，数据位置的分布范围主要会集中在：数据库（关系型和非关系型）+ 办公网终端；不过生产环境中的数据库通常都不会是单一的角色，而是一种数据平台架构；因此我们还需要以数据平台的视角来进行看待，如下：

2.2 数据路径

每个企业的网络和业务环境可能不同，我们可以根据企业的自身状况去梳理和完善每一条数据可达的路径。当时我们结合具体环境，梳理了6条路径如下：

2.3 防护思路

在弄清楚数据对象、数据位置和数据路径后，我们的防护目标也就很清晰：建立敏感数据的企业边界，对于流出的敏感数据可感知且可回溯。

2.3.1 生产环境

路径1:DBA/研发人员操作线上库

• 防护思路：

• 1.缩紧线上库访问权限，对帐号进行分类管理：特权帐号，应用账号和服务账号，并对帐号进行实时监控，除特权帐号外，杜绝非审核的人为数据库操作。

• 2.数据库敏感操作的审计与报警

路径2:管理/运营人员通过数据应用导致的数据泄漏

• 防护思路：

• 1.通常此类角色他们并不会直接与数据库接触，主要是通过内部的系统或应用， 因此在这块我们主要还是从帐号，权限和审计三个角度来处理

• 2.加强员工的数据安全意识

路径5:第三方服与合作（API接口）数据泄漏

• 防护思路

路径6:终端用户(外部攻击者)访问线上库

• 防护思路：
• 1.在网络边界上敏感数据流出监控
• 2.在重要项目中实施SDL，从源头上减少安全漏洞，增强抵御外部攻击者的能力
• 3.加强漏洞管理与修复能力

2.3.2 办公环境

路径3:各种形式的数据泄漏，如：邮件，IM，网盘，截屏和GitHub等

• 防护思路：

• 1.部署网络和终端DLP系统以及敏感文件水印，当时我们评估的那款DLP功能和场景大部分都能覆盖，所以可以适当地在产品选型上多下点功夫。

路径4:移动网络的数据泄漏

• 防护思路：

• 1.虽然也有移动端的DLP，当时我们也有所了解，但鉴于我们的实际情况以及内部移动办公还暂未普及，因此，在第一期项目中我们并没有太着急去落实。

整合上面所有的数据路径来看，主要就是需要在企业边界和数据源头两处进行强化防御，当时我们给出的防护思路，则是按照 企业边界安全防护+重要泄漏路径深度防护 ，如下:

边界防护（办公+生产）

• 生产边界
• 机房出口流量分析，对出入口的流量进行特征分析和检测，建立敏感信息流出的智能分析和预测
• 通过流量分析建立API的持续监控和异常发现
• 在企业边界增加全局的安全阻断能力
• 办公边界
• 网络和终端DLP对敏感数据的协同监控和响应

路径防护

所谓路径防护就是我们需要在访问主体到数据对象的访问路径中设定1个或以上的防护节点，并对访问路径进行技术、流程和制度层面规范和控制。主要的技术手段可以利用访问控制和流量分析；同时对于涉及敏感数据使用的人员需要安装终端DLP进行强管控。同时还需要在公司层面配合相应的管理制度，对数据使用的流程和规范进行约束，如下：

3.落地改造

1.首先是整个方案中的一些基础设施改造和部署，下面是我们具体的改造工作和方案，当然这里可以根据企业的自身情况选择开源自研或商业解决方案来实现。

1. 堡垒机和VPN，商业产品
2. 数据库操作审计平台，商业产品
3. 数据库操作审核平台，开源自研(Yearning)
4. 帐号集中管控系统，开源自研，这部分工作开发的工作量会较多，安全需要作为需求方，并给出相应的技术方案来推动整个项目和完成验收，最终我们将内部系统完成90%的接入和验收。
5. 办公网络中DLP部署，商业产品，之前公司也曾提到过桌面云的方案并让我们调研，类似把办公环境的主机进行云端集中管理，然后通过桌面终端接口(显示器和鼠标)暴露给员工使用；但站在安全角度上考虑，它其实并不算是一个安全解决方案，更像一个成本改造方案，因为改造后对于每一个桌面主机，仍然需要进行数据安全的管控，因此后来也被我们给Pass了，后来才转向DLP的方案，而DLP这个方案中，对于产品的选型和部署也确实都是比较耗时间的工作，差不多花了小半年的时间，最终我们选择了网络+终端DLP的部署。
6. 机房出口流量分析，开源自研+商业产品，在这个方向，我们主要做了两部份事情，一块主要是漏洞和爬虫风险，这块主要借助了白山云ATD的机器学习分析能力；另一部分主要是数据泄漏风险，我们主要通过Packetbeat+ELK的方案在负载均衡上对HTTP流量进行采集来实现对出口流量的敏感数据泄漏检测和识别，在分钟窗口内，按照IP和API维度，提取特征提取和模型训练，然后利用模型进行智能化检测和调优；IP维度的分析上已取得一定的效果，并协助发现一起敏感数据泄漏事件。

2.访问主体与数据对象的访问控制策略制定和落实，这部分的工作量比较大，主要需要跟运维团队配合，把数据路径中每两个节点的访问关系通过主机防火墙进行网络层面控制和来源限定。

3.每一条数据路径中的帐号与权限管控都是一个不小的项目，当时我们主要是针对 MySQL 线上库和数据应用来进行处理，

1. 其中MySQL线上库由于自身拥有完善的帐号和权限体系，我们可以很容易的对帐号进行管理和监控，并对帐号的高权限进行缩紧，尤其是DROP和DELETE权限；

2. 至于数据应用,我们当时主要是针对ELK来进行管控，由于ELK本身并不带帐号和权限的概念，如果按照默认的方式部署在内网，那直接就是个数据泄漏源；团队成员调研几种方案，后来也是基于成本考虑，利用ES的开源权限插件SearchGuard实现帐号访问控制以及索引级权限控制；如果企业内部已经用ELK把所有的业务日志进行整合管理，也没有预算压力，那么还是建议使用官方插件X-Pack,简单方便。

4.问题与效果

1. 在整个企业环境中，我们其实还只是设立了单点的防护，没有把单点防护打通，也无法进行协同处理，因此它们还无法形成安全大脑的优势；前期主要还是要借助安全人员的手工分析和经验积累。

2. 基于泄漏路径来进行数据安全防护，它虽然属于一种被动的防护思路，但鉴于泄漏路径的增量并不会像漏洞一样频繁，在相当长的一段时间内都是可以保证效果，而且在项目推动上也是很有优势。

3. 需要针对数据平台的增加帐号和细粒度权限的控制以及完整的审计

4. 数据安全中的工作还有很多，这里我只是把整体的思路重新给梳理了下，还有一些具体的工作在具体实践中也会遇到，比如，敏感字段的识别和分级，脱敏裤的建立，服务端敏感数据密态保存等等，这里就不细提了。

5. 在整个方案的推行过程中，我们还是取得了一定的效果，发现两起数据泄漏事件， 一起是在办公网的终端处捕获，另一起则是在机房出口流量处捕获。

声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如需转载，请联系原作者获取授权。