怎样利用区块链来保护自己的数据安全

前言

“叶舟瓠壶浪如屋，暗桩触船船版折”，浪上行舟，一个暗桩便会惹得货损船毁。外部暗桩尚可通过经验避开而行，内部暗桩想排查难如登天。等到发现时，已如朽木一般无法补救。

现代企业便如这浪上之舟，怎知自己公司中没有被暗桩渗透？怎知核心信息没有被暗桩泄露？

然而，从古至今，防范内部主动或被动泄密都不是一个容易回答的话题。

在数字化时代，数据，成为一个企业创新与发展的核心，已无法通过枷锁式的方式来进行管控。数据在整个行业生态中的流转以及在新兴业务场景下的使用，促使企业需要采用更灵活的方式来对数据进行管控。数据防泄漏（DLP， Data Loss Prevention）技术应运而生并且日臻成熟，已在不同的行业，尤其是具备敏感的研发或客户数据的企业中广泛应用。

2018年Gartner首次将数据防泄漏技术由“魔力象限报告”调整为《企业级数据泄漏防护市场指南报告》，这跟DLP技术日趋成熟、越来越多的安全产品包含了DLP功能，比如云访问安全代理（Cloud Access Security Broker， CASB）不无关系。

然而，全球企业数据泄露安全事件仍层出不穷。我国的《网络安全法》、美国针对健康保险行业的HIPPA、欧盟的GDPR等法规对数据安全也提出了更严格的要求。目前，我们看到很多企业选择较为传统的DLP工具，也看到市场上的一些技术创新，如利用人工智能进行内容识别。虽然很多企业部署了DLP，却无法很好地发挥其效用，要么事件积累搁置不管，要么花费大量人力进行运维，这都与DLP实施的每一个环节息息相关。今天就简单聊聊企业部署推广DLP的一些方法和注意点。

数据防泄漏技术能实现什么？

数据防泄漏保护是通过一定的技术手段，防止企业的特定数据或信息资产以违反安全策略规定的形式流出企业的一种策略。

对很多新兴科技企业，研发部门往往是企业的核心部门，掌握着大量敏感数据。关于企业内部泄密有很多大家耳熟能详的场景：► 研发工程师在离职前，将核心技术源代码下载至个人电脑，并加入竞争对手公司或创立自己的公司► 自主设计的产品信息被发现在黑市交易，例如，源代码、设计图纸、技术规范等

► 企业员工将高敏感度的公司信息（如企业战略、营销计划、科研产品信息等）上传至公共论坛或社交网站上

以上场景只是数据泄露场景的冰山一角，数据防泄漏对于很多企业来说是至关重要，且能够直接为企业进行止损。

而传统的DLP系统可以在数据存储和传输过程中进行实时扫描，识别这些数据是否违反现有策略规则，进而对数据外发事件进行静默审计，隔离可疑文件，加密数据或直接阻拦传输。

DLP实施前要提前做好什么工作？

为了更精准地保护企业的敏感数据，提升后期DLP运维的效率，在实施DLP项目之前，有几件需要提前做好的工作：

数据分类分级：

企业需要针对自身所持有的数据进行分级分类，而后对特定等级的数据进行DLP策略的实施。如：企业将数据分级为绝密、机密、内部、公开四个等级，并仅针对绝密和机密数据实施数据防泄漏保护。部分行业有专门针对数据分级分类的国家政策规定或指导，如证券期货行业的《证券期货类数据分级分类指引》，企业可根据国家规定、行业实践进行相应的数据分级分类工作。

人员角色和岗位权限定义：

一般情况下DLP产品会读取企业的AD（Active Directory）域信息来进行管控。如果企业实施精细化管理，AD域的准确性将会是一个影响DLP管理效果的重要因素，否则企业人工维护人员信息需要投入的人力成本将会非常高。

内部沟通：

由于有很多企业会部署终端DLP，这将需要在员工电脑上安装软件并且可能会影响到员工的日常操作流程，管理层的重视与支持，自上而下进行推广，对于一个DLP项目的成功实施至关重要。同时实施过程的数据识别、运维阶段的事件处理，都离不开业务部门的支持，这都需要在实施前进行充分的沟通。

DLP实施应从哪些技术层面进行考量？

目前市场上使用比较多的DLP类型有终端DLP，网络DLP以及邮件DLP。

终端DLP会针对所安装的终端的数据使用行为做监控，这也是目前应用范围最广的DLP类型。即使设备在离线的状态，只要策略已经在终端生效，也会实施相应的管控措施。

网络DLP一般是放在企业内网出口位置，可以对发送的信息做第二道审核。同时有些产品为了减轻终端压力，图像识别功能（如扫描的图片，截图或非文字转换为PDF的文档）也是放在网络DLP中。

邮件DLP一般是部署在邮件服务器上，对于邮件发放进行审核。有的企业邮箱是在外网可以登陆的，此种方式可以减少这种在外网通过企业邮箱发送数据而产生数据泄露的风险。

DLP策略是整个实施过程的核心，策略的准确性和覆盖性会直接影响到DLP 项目的成败。可以分为四个维度来进行考虑，分别为：数据的识别规则，策略生效的范围，安全应对策略和数据传输方式。

数据的识别规则：

此维度是指针对特定密级文档的识别，也就是需要保护的对象。一般类型的文档可以使用关键字，建立字典或者使用正则表达式等方法来识别。一些特殊的文件需要针对文件类型来做相应的识别方法，如CAD等图纸类文件。还有一些其他的方式如针对单个文件打指纹等等。大部分DLP产品中会自带一些可一键使用的识别方式，如身份证号、个人简历、源代码等等，由于这些通用性的策略没有根据企业实际情况进行定制化，因此必须在调优过程中逐步进行优化。

策略生效的范围：

此维度是指本条策略生效的终端（人员）。理论上来说，所有策略都是需要针对企业内部所有终端进行下发，但某些更加严格的策略会需要针对特定群组的员工实施。亦或是有些企业的研发环境与办公网络环境是隔离的，某些机密文件的策略只需要针对该部门的员工终端实施。

安全应对策略：

此维度是指针对这条策略实施怎样的应对方式，如静默审计、阻拦等等。一般在策略生效之初的优化阶段，只会对事件做静默审计以免影响合理的业务往来。当策略优化到误报量达到可接受的范围内时，企业会根据自身需要调整策略，进行发送确认或者阻拦等方式。

数据传输方式：

此维度是指该类型文件所允许的传输渠道。如邮件、U盘、网络云盘等。企业需要针对每个类型的文件有清晰的传输渠道定义，如某机密文件只可以通过内部邮箱发送，其余渠道都需要阻拦等。

当然还有其他一些维度，如针对时间段进行设置，企业可根据自身要求和产品功能进行相关策略的配置。

从人员及管理方面，应当进行哪些工作来保证DLP的有效性？

一

当DLP投入正式运维后，需要有一定的组织和人员来保障持续运营，方能及时发现和处理数据泄露事件。

一般情况下，除了安全团队，企业内部还需要以下几个团队：

DLP运维团队：

DLP运维团队的所属部门一般由于企业实际情况而有所不同。DLP系统后台管理会由基础架构团队或者信息安全团队负责，部分企业可能由合规团队负责。此团队主要负责DLP后台的运维，诸如后台账号创建、事件、日志审阅等。

应急响应团队：

此团队主要工作是在发生信息安全事件时，进行相关的数据泄露事件响应和处理。团队成员可包括信息安全团队相关负责人，各业务部门相关负责人，合规团队负责人，人力资源团队负责人等等。

基础架构支撑团队：

从终端DLP软件的推送、网络DLP的部署，到服务器资源配置等，都需要基础架构团队的参与，方能从技术上保障DLP工具的落地和运维。

审计团队：

防范DLP管理过程中可能发生的二次泄露。

二

事件审查模式的有效建立方能保障数据防泄漏的持续性效果

目前有三种事件审查模式比较常见：

信息安全团队审查：

完全由信息安全团队来审查DLP后台事件。这种模式优点是由信息安全团队专人进行事件处理，效率会比较高。但由于安全团队人员对于业务理解度不高，可能无法判断该业务需求是否合理，还需多次与业务部门沟通，或存在事件处理结果不恰当的情况。

业务部门审查模式：

完全由业务部门来审查DLP后台事件。这种模式优点是各业务部门出于对自身业务的了解，能更加有效地判断事件是否为真实的信息安全事件。但是这种模式存在以下几种缺点：

业务部门调查人员可能存在包庇行为，或业务部门内部解决而不报告安全部门的情况

由于DLP实施前期误报可能比较多，造成业务部门调查人员积极性不高，并且当大量误报形成时会导致潜在信息安全事件被淹没

对调查人员本身及其上司的信息泄露事件可能有所缺失

混合团队审查模式：

由信息安全团队和业务部门混合调查。这种模式主要可以理解为，信息安全团队对后台事件先进行筛选，剔除掉重复或者明显是误报的事件，随后将各业务部门的潜在安全事件分配给业务部门调查人员进行确认。当然，这种混合型审查模式也是有缺点的，过于依赖信息安全团队人员的筛选，分配事件的时间较长，事件调查的时效性会比较差。

三