君哥有话说
企业安全建设中，应用安全、内网安全、数据安全，关注点和投入度分别从高到低，防护难度从低到高。一系列国内外安全大事件表明，数据安全将从企业安全建设的后台走到幕前，少数金融企业已经预见到这一趋势并成立了专门的数据安全团队，从管理、技术、资源等多方面进行了较多建设实践。本公众号将发表某大型金融企业数据安全负责人一翔老师有关数据安全建设实践的系列文章，敬请关注。
本篇为数据安全第二篇。
4. 存储数据安全
企业的很多数据除了落地在终端，更重要的是落地在后端存储上的，这里的数据安全工作会涉及到存储数据的加密、敏感文件的扫描发现、以及数据的销毁等方面的内容。
4.1 存储数据的加密
存储数据的加密，从数据加密位置的不同，一般分为应用层加密（如数据库、备份软件）、网关层加密（如加密交换机）、存储系统加密。
应用层加密，肯定是兼容性最好的方案，因为应用自身实现了加密，存储层、网络层根本无感知；另外由于应用层加密可以保护数据端到端的安全，所以实用价值更大一些。以数据库为例，包括oracle、sqlserver在内的数据库，都在高版本里支持透明加解密功能，即存储在磁盘上的数据是加密的，加解密功能由数据库自身来完成。Mysql也在5.7版本推出数据加密功能：透明数据加密（Transparent Data Encryption）。用户在创建加密表时，不用指定加密密钥。数据在写盘时加密，在读盘时解密。不过目前Mysql的透明数据加密只支持InnoDB存储引擎，未来可能会有新的改进。
网关层加密，使用加密存储安全交换机，连接在存储设备和主机之间，所有数据都会经过它，性能是一个需要关注的问题；另外已经有存储交换机的企业来说，还需要另外采购加密交换机来实现加密功能。
存储系统加密，依靠存储本身提供的加密就可以，不需要引入加密交换机，也不会对主机的性能有影响。很多企业都使用磅带库的方式进行备份，一般都支持加密功能。
4.2 存储数据敏感扫描
常规的DLP产品，都会支持敏感数据发现功能，除了对本地终端，还可以对远程存储上的文件进行扫描，比如文件共享、Lotus Notes数据库、SQL数据库、SharePoint服务器、Exchange Server扫描等等，都是一些DLP产品里的功能，就不再多说了。
4.3 数据销毁
数据销毁有两种，一种是我们常说的数据擦除，一种是针对物理设备的销磁或粉碎。
有经验的同学都知道，Shift+Delete删除的文件其实在磁盘上还是能找回来的，下图为某数据恢复工具实际效果图：
其原理是当你删除一个文件的时候，并没有真正的把文件从磁盘的存储位置上删除，而只是在文件分配表上把该文件存储位置的标志置为0，也就是说只有你下次存储新的东西要用到这个标志的时候，原来被删除的东西才能真正的被物理的覆盖掉。
安全的删除方法，是使用专业的工具进行，免费的有Eraser，看其设置里各种模式就知道什么叫专业了，美国国防部标准都搞上了，下图是其功能设置界面：
如果想针对某个重要文件做处理，但已经不小心被删除，一种办法是先恢复再安全删除，还有一种办法就是直接硬盘填充多次，硬盘填充工具网上有免费的FillDisk，也有系统有自带的cipher命令，如下图：
此类工具的原理都是写数据一直到磁盘写满，多运行几次再用数据恢复工具测试下效果进行验证。
针对磁盘的销磁，需要专业的销磁设备来进行，一般金融机构数据中心都会配备，不过多介绍。针对SSD固态硬盘，由于其不是磁性媒介组成，所以销磁机就派不上用场了，一般的做法是将其芯片粉碎，市面上也有相应的设备。
5. 应用数据安全
企业里有各种各样的应用系统，数据安全工作者往往需要从数据的采集或输入、存储、内部访问或API调用、前端展示等维度去考虑。前端展示涉及的数据脱敏话题在后面阐述，建议是以API接口服务形式提供数据消费功能，通过对接口的统一管理，并尽量提供数据终态结果，避免原生态敏感数据的输出使用，减少原生态敏感数据的扩散半径。除了业务系统上层的控制，还需要关注数据库安全、数据提交流程控制以及大数据平台上的数据安全，下面分别阐述。
5.1 数据库安全
数据库里存放在各种各样的数据，所以常常也成为重点攻击目标。这里的攻击，除了传统的通过web漏洞拖库外，还有内部管理员直接后台Dump，还有业务人员通过系统批量导出。为了尽可能覆盖各种攻击场景，一般企业需要如下的方案：
使用数据库代理保护数据库免受攻击，比如数据库防火墙可以直接阻断基于数据库协议的攻击行为，一般的proxy还可以提供IP过滤、SQL命令过滤与审计功能，可以对非法来源或sql语句进行阻断；
对数据库进行封装，提供统一的运维平台给DBA或开发人员使用，使管理员无法直接接触数据库服务器，通过用户账号管理、权限控制、操作审计来实现；
数据库审计，通过基于网络流量或者代理插件等技术来实现数据库审计，以此发现针对数据库的入侵或违规操作；
数据库所在服务器及数据库软件本身的安全性加固工作。这其实是一个基础工作，如果数据库存在未授权访问漏洞甚至直接能远程溢出到服务器，那前面这些工作可能就白干了。
关于数据库安全，商业产品比较多比如imperva及国内的安恒等，开源的也有不少可以选择，比如Mcafee的mysql-audit插件、数字公司的MySQL Sniffer、美团的DBProxy等，具体的使用可以参考兜哥的《企业安全建设入门：基于开源软件打造企业网络安全》一书中关于数据库安全的内容。
5.2 数据交换平台
理论上业务系统功能够强大，都可以直接在业务系统上实现数据导出功能了，不需要有单独提取数据的场景了。但理论有时候只是理想，监管或公安来了要求导出原始数据给不给？很多企业将生产与办公隔离开来，有时候也需要将一些数据提取到办公网来，于是数据交换平台类产品出现了，从早期的安全隔离网闸，到如今的一些交换平台类方案等等，这里就不过多评价其优劣了，笔者关注到有些产品开始融合网闸、网盘和DLP思想或技术于一体，通过授权、审批、敏感性检测、审计等方式保障数据交换过程的安全性。下图是某公司的数据交换平台示意图：
有些场合，需要给外部机构提供大文件，通过邮件通常有大小限制，直接开放FTP访问也不安全，放到外网类似百度网盘也担心有风险，怎么破？有些厂商借鉴百度云盘的方案为企业搞一个自己的云盘对外提供服务，外链分享、密码提取、有效期限制等等功能都有，再结合企业内部审批流程、邮件对接等也是一个可选的方案。
5.3 大数据安全
越来越多的企业将各种各样的日志丢到大数据平台进行分析，管控不好会造成大批量的数据泄露。如果企业安全建设能力还不够，建议是放到封闭环境进行操作访问，类似我们上面提到的数据仓库保护方案。互联网企业在这块走在前面，可以借鉴其思路开展工作，包括：
在大数据平台上提供各种各样的模型，方便业务人员直接在平台上做分析，可视化展示，这样可使数据导出的需求尽可能的少；
建设大数据风控平台，对敏感数据展示时进行脱敏或者只对用户展示最终的视图；
实在需要导出离线分析的，请结合前面的各种方案进行选择，比如桌面虚拟化确保数据不落到终端，或者落到终端的数据有审批、水印、审计。
大数据平台本身的安全性，包括身份认证、访问控制和授权等等。Hadoop及其生态系统中的其它组件都支持使用Kerberos进行用户身份验证。Hadoop和HBase都支持ACL，同时也实现了RBAC（基于角色的访问控制）模型，更细粒度的ABAC（Attibute Based Access Control）在HBase较新的版本中也可通过访问控制标签和可见性标签的形式实现。
6. 其它话题
6.1 数据脱敏
数据脱敏在百度百科上的定义：指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。
数据脱敏的应用非常广泛，比如我们常见的火车票上的身份证号码会用星号替换其中一些数字。按照脱敏规则，可以分为可恢复性脱敏和不可恢复性脱敏。可恢复性脱敏就是数据经过脱敏规则的转化后，还再次可以经过某些处理还原出原来的数据，相反，数据经过不可恢复性脱敏之后，将无法还原到原来的样子，可以把二者分别看做可逆加密和不可逆加密。
金融行业作为一个强监管的行业，经营过程中收集到的客户资料信息包括身份证、银行卡号、手机号、住址等个人信息必须进行严格保护，数据脱敏是一个必不可少的环节，特别是在开发、测试过程中可能会使用到真实生产数据时。随着业务越来越复杂及后台数据库里表规模越来越大、结构越来越复杂，依靠人工梳理敏感信息的方式已经不能满足日益复杂的需求，商业的脱敏系统应运而生，基本上都利用各类敏感信息的规则去自动扫描来发现敏感信息字段。
除此外，生产系统中的真实数据在对客户展示时，也需要考虑脱敏处理；内部系统也是一样，避免不必要的信息泄露的方式，基本都需要对系统进行改造，在前端展示、数据导出环节进行控制。这里需要注意一些坑，比如测试环境中的数据已经脱敏，测试人员对功能测试时往往发现不了系统内在逻辑是否有脱敏，一旦有问题的代码发布到生产环境，可能效果就会和测试环境不一样，假设某页面上直接出现了客户信息如手机号，随着现在互联网传播手段的流行，造成的声誉风险可能会非常大。
6.2 水印与溯源
水印在数据安全领域广泛应用，主要用来防止敏感信息被截屏、拍照的方式泄露出去。水印，从可见性来区分，可以分为明文水印和隐藏水印。明文水印一般主要是起警示的效果，比如企业内部文档通常加上“内部资料，请注意保密”字样的水印，而隐藏水印，更多是站在追踪溯源的角度考虑。这两种水印一般会同时使用，企业里通过技术手段配合行政手段的有效使用，往往具有更好的震慑效果。
从使用场景的不同，水印又有屏幕水印、网页数字水印、图片水印、文档水印等各种呈现方式。屏幕水印一般是通过后台Agent来实现在屏幕上打上水印，网页数字水印则一般通过网页背景技术来实现，图片水印则是通过将图片上打上水印标记生成另一个图片来实现，文档水印更多是在文档本身体现，需要文档工具支持。结合笔者经验，下面介绍三种比较特殊的水印处理技术，供大家参考。
6.2.1 强化版网页数字水印
常规的网页数字水印，基本上都是写着诸如员工编号等信息的透明度很高的图片，background-image 的方式平铺满整个屏幕，稍微懂点的同学用浏览器按F12找到对应元素直接删除即可。
有没有更好的办法防止删除呢？一般人会想到通过JavaScript来实现当发现有人删除这个DOM节点时再重新生成即可。除了删除，还有DOM节点的隐藏、挪动、篡改等手段也会影响水印效果，还得继续。
另外，如果通过防火墙或一些浏览器插件工具拦截到水印服务的请求呢？再来个连接检查请求，看水印服务是否可达，不可达则破坏页面不显示正常内容。
如果以上都解决了，那攻击者通过查看js代码发现其判断逻辑，在浏览器代理工具中修改相应结果呢？这时候就需要对js代码进行保护了，不是常见的压缩混淆，还会涉及到前端代码保护技术了。这里的对抗是无止境的，结合已有的保护技术，在代码里通过埋点对恶意行为进行记录，也是一个非常好的方案，毕竟企业里真正懂这些人的不多，通过埋点发现“高手”也是件有趣的事情。
6.2.2 WPS字库水印
WPS文档朔源专用版客户端创建的公文可将用户的登录身份基本信息（以及硬件ID设备信息）形成隐藏的数字水印分布在公文的文字排版中。
从上图可以看出，其水印功能是利用特殊字体，在打开、打印文件时对字体进行绘制，埋入相应的数据水印，下面是WPS隐写用户信息的原理图：
以上过程不影响原文件，仅影响WPS呈现出来的效果，而且通过肉眼识别不出来，用户基本感觉不到。但是如果当用户通过打印、复印、拍照等方式造成文档泄密，单位管理者仅需要获取到公文的复印件、或相关的拍照图片，即可通过WPS公文溯源解析系统，寻找到泄密的原始人，从而方便追责工作，下图为溯源提取原理图：
6.2.3 矢量水印
屏幕矢量水印是联软公司新一代的水印解决方案。该方案抛弃原有“所见即可得”的水印方式，用一种“轻微型”标记的方式来展现水印，近乎等同于“隐形水印”。如果有屏幕拍照或者截屏，一旦发生泄密事件，即可通过泄密照片上的矢量水印信息快速锁定泄密者。
屏幕矢量水印具有抗折叠、冗余备份、抗波尔纹等的特点，即无论照片如何压缩、优化、折叠都不会影响到水印信息的审计和泄密源的定位。只需要在查询页面中，输入水印信息进行查询，就可以锁定的泄密人。如果得到的泄密的图片不够完整，系统也能支持查询出精确度最高的结果。
下面是一个矢量水印效果截图：
可以看到在上面有很多点阵，每个点阵后台代表不同的字符，如下图：
通过特定的算法只需提取4-6个相连的点阵即可追溯出文档泄露相关信息。
6.3 UEBA
2014年，Gartner发布了用户行为分析(UBA)市场定义，UBA技术目标市场聚焦在安全(窃取数据)和诈骗(利用窃取来的信息)上，帮助组织检测内部威胁、有针对的攻击和金融诈骗。但随着数据窃取事件越来越多，Gartner认为有必要把这部分从诈骗检测技术中剥离出来，于是在2015年正式更名为用户实体行为分析(UEBA)。
UEBA最近很火，在国外一些领先的UEBA厂商凭借检测能力上的优势，已经在尝试颠覆原有市场格局，包括Exabeam、Gurucul、Interset、Niara、Securonix、Splunk（2015年收购Caspida）等。这些产品的出发点主要是解决以下问题，包括：
账号失陷检测
主机失陷检测
数据泄漏检测
内部用户滥用
提供事件调查的上下文
毫无疑问，这些威胁都是企业最关注的风险。而在国内这方面的公司或产品还不够完善，很多企业也在尝试从传统的SIEM/SOC转向大数据平台进而走向UEBA，需要保持关注，国外UEBA的火热不是没有道理的。
站在数据安全的角度，内部用户对业务系统的异常访问就需要关注，比如去年报道的针对征信系统批量查询的案例，通过对账号的异地、异常时间登录，到数据的批量查询下载，都是可以发现的。
6.4 CASB
随着云技术和虚拟化技术的普及，越来越多的企业已经没有传统意义上的数据中心机房了，各种业务系统迁移到云上，包括企业邮箱、企业网盘、CRM、ERP、OA、HR等各类业务系统均托管给云服务商，计算资源规模化、集约化使办公效率取得大幅度提升。在这种情况下存储资源变为共享式，企业随之失去了对应用及数据的安全控制权。既要享受便捷的云端服务，又不能失去对自身数据的控制权，基于这个预期，Gartner在2012年提出了CASB概念，定义了在新的云计算时代，企业或用户掌控云上数据安全的解决方案模型。CASB产品有两种工作模式：一种是Proxy模式，另一钟是API模式。
在Proxy模式下，CASB要处理企业上传到云应用的全部流量，重要数据采用加密等安全策略处理后再上传到云服务商；而在API模式中，企业数据直接传给云服务商，CASB通过利用云应用的API，对用户进行访问控制以及执行企业的安全策略。
金融行业的特殊性导致业务上云还是一个具有争议性的话题，笔者建议还是需要保持关注，技术潮流势不可挡，传统金融机构面临互联网公司的挑战势必加快这方面的技术转型。
7. 小结
最近有个同学跟我说，某厂商过来讲PPT，开篇就提到facebook泄露事件，讲完整个PPT也没见他们如何能解决facebook的问题，谈笑之余表示理解。因为数据安全建设工作，没有黑科技，只能靠对企业数据的全流程管理结合技术手段，尽可能的避免数据外泄。办公终端物理分布的广泛性导致数据管理半径的急剧扩大，同时加上终端的多样性导致终端数据安全管理难度进一步加大。数据安全未来管理方向在聚焦于敏感数据的基础上可以考虑转向后台集中管理，数据集中的承载平台包括应用系统和虚拟桌面等，不过前提条件是要提高应用系统、虚拟桌面的数据处理、分享能力，并打通后台的数据流转过程。未来随着云的流行和监管可能的放开，CASB是一个不错的方向，值得关注。
感谢以下朋友就这个话题与我的讨论：
中兴通讯 俞婷
广发证券 唐勤
连连支付 廖位明
网联 钱文斌
声明：本文来自君哥的体历，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
