数据安全纵深防御
谈到黑客攻防对抗，我们都知道如何进行纵深防御。
一方面，我们会在基础设施和应用上进行加固。包括网络，主机，应用三方库以及应用自身代码等。因为很多漏洞需要在设计层面就进行解决，我们建立SDL流程，来管控从设计开发测试到上线运营整个流程中的安全方案。
另一方面，我们建立整套漏洞发现，攻击阻断，入侵检测和响应流程。流量上从四层、七层流量到用户操作布控，主机上从内核态、用户态再到应用内布控，架构上从Web服务器到数据库，从邮箱、浏览器到办公PC进行布控，网络上从办公网、测试网、生产网和DMZ进行布控。
在以往的攻防对抗中，我们关注的更多的是主机，但当我们把目光投向数据，以数据为核心防护资产时，我们该如何对数据安全建立纵深防御机制呢？
我们的对手
在前一篇文章中，我们提到，数据安全的终极问题是合规合法和自身数据保密性需求。合规方面涉及到数据的采集传输使用存储和共享的标准，这个是需要根据公司的发展阶段，来定义要做到几级合规。这个是需要与监管研讨和根据业务发展情况找出适合自身的发展方案。这里我们暂不做讨论。
以下谈的数据安全都是仅谈谈数据保密性的解决方案。
数据安全防的到底是谁？
-
内鬼
-
黑客
-
手滑
前两个都很好理解。手滑是指，员工或者开发人员误操作，导致重要数据直接暴露在外，任何人都能访问。
搞清楚对手之后，我们就需要针对这些对手去设计相应的解决方案。传统的数据安全解决方案，把重点都放在了内鬼身上，认为黑客窃取数据的对抗应该是系统安全的主责。而系统安全又认为自己只关注机器被黑，数据方面的事情应该是数据安全搞定。从来没有站在系统化的角度上，去梳理各自能做哪些事情，形成合力，解决问题。
今天我们将试图站在更系统的角度来思考这个问题。
数据安全SDL
数据安全要有类似于SDL的团队，一方面参与到重点项目的全生命周期，另一方面，对接合规法务团队，形成数据安全基础规范，帮助全员建立数据安全心智。这里的全员不仅包括普通员工，还要上升到董事会成员。
该团队也要参与到基础设施的构建上，让数据采集使用和共享能够secure by default。团队负责人可以从情报团队订阅数据安全相关情报，用情报团队详细分析的外部的泄露case来指导数据安全治理。
这里有一点需要特别注意，我们在进行传统安全对抗时，可能即使没有SDL团队，通过扫描器，通过WAF，通过入侵检测也能给一个公司续命。但对整个数据安全而言，如果没有这样一支做数据安全SDL的团队，数据安全压根没法开展。因为敏感数据泄露的口子太多，如果不进行没有他们进行治理收拢，根本不可能建立能用的解决方案。
敏感数据识别
首先我们需要能够识别业务敏感数据。
数据安全和系统安全的分歧往往是在敏感数据的定义上。
传统的数据安全聚焦在敏感合同这类商务机密上，而对于用户的身份证号手机号这类信息不是特别关注。更别提数据库密码，api key这些了。
而传统的系统安全对内网一碗水端平，敏感合同这类业务属性系统安全是看不见的。他看见的仅仅是员工电脑，办公网，服务器，生产网这些系统。
我们对敏感数据定义如下：
-
商业机密，包括财务信息，贸易信息，人员信息，源代码等
-
用户数据，包括用户个人信息等
-
研发密钥，包括数据库密码，api key等
定义出存储标准和共享标准。
例如在存储上是否要进行加密存储。其他团队如果要使用这份数据，要统一走特定的api，不允许直连数据库进行读取。
敏感系统收拢
对于敏感数据查询和使用，我们需要根据需要，收拢到特定的几个系统。例如财务核算系统，采购管理系统，客服系统，hr系统等。
一个合格的数据安全SDL要能够清楚的阐述出公司有哪些涉及敏感数据的系统。
常规的敏感系统经常遇到的问题是，系统收拢，数据分散。虽然有了财务系统，但使用人员将数据导出，存到了自己的电脑上。然后又发送给其他人。这就是虽然系统收拢了，但是数据还是分散出去了。可能非财务人员电脑上也放了这个数据。当然，这个数据也不会分散到太多电脑上。
而核心研发生产资料遇到的问题是，系统上就不收拢。每台生产网的机器上可能都有api key，配置文件里都有数据库密码。
敏感系统治理
-
需要对能够访问敏感系统的人进行限制
-
需要对每个访问者的操作进行详细记录
数据安全感知监控体系
敏感系统数据窃取对抗
在用户登录敏感系统后，可以通过敏感系统本身提供的“导出”功能，手动截图，浏览器复制，手工记到小本本上等多种方式拿走数据。
敏感系统本身提供的导出功能，我们可以通过导出加密文件，要求必须用密码打开以及单独记录日志来进行追踪。这个地方可以使用透明加解密系统。
浏览器复制，可以通过埋入浏览器插件和js来检测。DLP的浏览器插件和自主研发的js可以完成。
手动截图需要通过主机上的数据泄露监控系统，对截图api进行hook，来识别截图的位置和表单。需要主机上的DLP和EDR来识别此类行为。
而手工记到小本本上，就没啥好办法了。面对这样的对手，只能去分析，他每天读了哪些数据，是否跟正常需求相匹配。这个地方需要通过UEBA算法进行持续的分析。
办公网数据传输对抗
-
封禁网盘 QQ等传输软件
-
文件生命周期追踪。对截图，复制，导出的文件，进行全生命周期跟踪。识别文件的压缩，读取，拷贝操作
-
对上行流量过大的情况进行识别并追踪
生产网密钥窃取对抗
对生产网的密钥上，需要进行两点改造：
-
密钥不落盘。数据库的密码在同一的密钥管理系统上。主机跟密钥管理系统之间采用证书校验。只有特定的进程才能连接密钥管理系统。此处可以对密钥管理系统单独建立异常识别的规则
-
业务间不共用。不同业务系统不共用密钥
这样即使生产网机器上的密钥被窃取，黑客也没法直接使用。
生产网数据传输对抗
-
默认禁止外连
-
对需要外连的机器走统一的网关，在网关上对流量进行过滤识别
用户数据窃取对抗
用户数据窃取常见方式有SQL注入，爬虫、撞库等。SQL注入通过常规的系统安全对抗方案解决，爬虫需要先识别暴露敏感数据的api，然后建立人机识别算法，识别爬虫行为。
敏感数据扫描
在开发阶段进行代码扫描，部署阶段进行配置文件扫描，运营阶段进行github扫描，服务器日志扫描，数据库字段扫描，其他服务器敏感信息扫描等。
UEBA
如何定义User Entity与Behavior？
毫无疑问，User Enitity包含用户身份，用户设备信息，用户网络环境等
Behavior则需要根据数据安全进行细化。例如，数据访问，数据下载。这里面毫无疑问，存在一个难点。那就是Behavior的细化。
很多地方Behavior可能仅仅记录，访问了某个URL。但这个是百分百不满足异常检测需求的。我们需要细化到，他访问这个URL用的Post参数是啥，这个行为的具体意义。例如，内部某个数据查询平台上，他查了多少条信息，查了谁的信息。这里就可能出现拼接SQL进行绕过的情形。他的SQL语句里面写的where id= concat(xxxx,yyyyy)。要能够标识出查询的方式，从而更进一步的发现异常
总结
通过以上几个常规场景对抗，我们可以识别到，如果要对数据进行监控，需要建立以下基础设施：
办公网方面：
-
网络、终端DLP&EDR，包括浏览器插件
-
文档透明加解密系统
-
水印系统（网页）
-
UEBA
生产网方面：
-
密钥统一管理系统
-
生产网安全网关
以及对标漏扫的敏感数据扫描系统。
之后需要通过持续的运营细化，尤其是UEBA方面，如何针对特定的系统为每个人建立适合的策略，是需要不断优化的
