滴滴事件发生以后，身边和行业的朋友们经常会谈到这个问题，也会问我对这个事件的看法，包括滴滴事件对信息安全的影响，以及企业数据安全如何建设等问题。下面我们首先简单回顾一下滴滴事件的过程：

6月30-滴滴上市

7月2日-国家网信办启动审查

7月5日-BOSS直聘、货车帮撤回美国上市IPO

7月5日-广东省数据要素市场化配置改革行动方案，提出数据海关、数据确权评估、数据管理成熟度模型等要求，并支持深圳数据立法试点

7月6日-中办、国办压实境外上市公司信息安全的主体责任，主要强调加强跨境监管合作，压实境外上市公司信息安全主体责任和审计监管

7月6日-深圳经济特区数据条例，强调市政府应当建立健全数据治理制度和标准体系，统筹推进个人数据保护、公共数据共享开放、数据要素市场培育及数据安全监督管理工作；市网信部门负责统筹协调及监督管理工作

7月10日-网信办的补充修订文件，超过100万个人数据的公司境外上市必须提报网络安全审查

7月11日-央视报导，聚焦深圳推动数字政府建设，加快构建新发展格局

7月16日-多部门进驻滴滴开展安全审查

从以上的过程，以及目前监管部门的各种动作，阿肯认为滴滴事件对数据安全行业的影响主要表现在：

1、跨境上市企业的数据安全审查监管将更加严格；

2、数据安全条例会更新细化、审查力度会有计划、分行业加强执行；

3、数据作为一种生产要素和资产会摸索一套市场交易共享体系；

4、今年是国企央企的数字化建设元年，国家会警惕工业技术的互联网化，逐步引导资本服务于广大的老百姓利益，而不是少数的资本集团。

其实，滴滴事件对境外上市、反垄断、资本投资走向都会产生持续的影响，接下来我们主要讨论一下新形势下，企业内部数据安全的建设问题。阿肯认为在企业中想体系化做好数据安全建设治理，可以从以下几个方面思考：

一、看清企业数据安全管理的现状和痛点

阿肯认为，要做好企业的数据安全建设工作，首先要深入分析目前企业数据安全建设存在哪些问题，才能做到有的放矢。从企业的角度，数据安全需求大致可以分成两类，一类是安全合规需求，比如基于网络安全法、网络安全审查办法、数据安全法、个人信息规范、APP 违法违规收集使用个人信息自评估指南等要求的几方面的数据安全工作；另外一类是基于企业业务自身的安全要求，需要做到数据的安全管理，比如对于业务系统中用户的数据权限控制；承载数据的应用系统要足够安全，不被攻击和脱库；运维过程中的数据安全管理，规避数据落地和权限过大引发的数据安全问题；大数据开发过程中的各类数据的非接触安全管理等等。

不管是哪一类的需求，目前数据安全的治理理论基本上都是从数据的安全标准、分类分级、数据的生命周期、数据的安全稽查，以及数据安全成熟度模型等方面考虑。但这些理论的作用主要在于指导企业数据安全稽查活动的开展，或者第三方视角下评价企业数据安全的管理水平，如果企业按照这些理论体系化地做企业数据安全的产品落地还是比较难的。因为企业不同业务场景、不同部门对数据的需求都不一样，各个企业的数据安全的落地建设就参差不齐，整个数据安全体系落地的效果就不理想。整体来讲，企业数据安全的痛点主要表现在三个方面，只有认清了这些问题才可能找到解决的办法：

1、数据业务太复杂了，安全作业流程不清晰：数据的收集、存储、加工、使用、共享、交易、发布等过程，在业务用户、开发、运维等角色中并不是完整一体的，每种角色的作业场景对于数据安全的接触程度和数据安全的要求也不一样，搅在一起就容易出现安全管理责任不清晰，多部门打架的情况，数据安全的闭环管理很难落地；

2、目前数据安全的处理都是点的技术，不成体系：目前大家说到数据安全的技术落地，大部分说的是加密、脱敏、数据库审计和权限控制等，没有从数据全场景、全周期去考虑落地数据安全的技术方案；

3、数据安全的风险不能数字化管理，看不到，就管不好：没有数据资产以及各类数据流转操作的详细日志，没有这些资产和对应的日志数据，就无法看到数据的风险，风险管理工作的效果肯定就会受到影响。

二、从繁到简认识企业数据业务

分析了解了企业数据安全治理存在的问题，接下来就是想办法去解决。解决问题的步骤和方法有很多，阿肯认为最重要的就是要深入业务本身，了解业务的详细过程，尽量做到以上帝视角去看待你要解决的问题，直到你能用自己的语言简单表达出来，一句话，就是如何将复杂的问题简单化。阿肯根据自身经验，并走访了业务人员、运维部门、开发部门、大数据部门，对企业数据业务做了以下简化：

1、梳理数据的业务场景：大家在讲数据安全的时候，总会讲到采集、存储、处理、使用、共享、销毁...。但实际上企业如果按照这个逻辑是无法很好落地数据安全的风险管理，因为数据本身是没有任何意义的，比如，一个用户数据从APP采集到后端API，到微服务到库表字段，另外一个应用又有另外的入口，这种场景永远无法穷举，数据安全的风险管理就很难落地。数据只有在具体的业务场景下，才会发生变化，产生价值，同时也会存在风险，需要管理和处置，只有确定的场景下才能将数据、动作和特定人员产生关联和闭环，才能落地，这是企业落地数据安全风险管理的核心所在。阿肯根据经验，把这些场景简单划分成三个场景：

  • 人-应用：这里的人指的是业务系统的用户，这里的应用是直接提供给用户使用的业务系统，这种场景下数据安全需要做到的就是，根据业务需要，决定什么样的用户赋予什么样的权限；

  • 应用-库：这里的应用指的是业务系统中的各个API接口，这些API和微服务会读写库表字段；这里的库，指的是DB或者大数据的各种数据存储计算服务。这种场景下API接口需要在管理和技术上一系列管控，以防范接口类的数据风险；

  • 人-库：这里的人指的是科技团队的DBA、开发、运维等人员，库跟上面一样，就是大数据平台的数据存储计算服务，以及各个应用的DB库。这些人因为不同的角色分工，在系统的搭建、开发、部署、调试和运行阶段需要对库表字段做各种业务操作，这些操作需要满足最小权限原则，还需要操作留痕，防范人为操作引发安全风险。

2、数据的分类：数据分类更多是从业务角度出发，理清自家企业的数据家底，明确知道哪些数据属于哪个业务范畴，便于后面的分级保护，比如：员工类、客户类、运营类、设计类、工艺参数类等等。

3、数据的分级：不管数据量有多大，存储方式有多少，企业都必须做好数据的分级，知道哪些数据需要重点保护。至于说是否一定要分出1、2、3、4、5级别，我的理解是，越简单越好执行，太复杂的东西等于没说，也无法落地。比如企业可以简单将数据定位为敏感和普通，敏感的数据后续需要重点保护和监控，可以做敏感数据自动识别、权限控制、加密处理、导出脱敏、流转追踪等等，普通数据的控制就可以简单一点，毕竟企业的资源始终是有限的。那到底应该把哪些数据定义为敏感？从合规角度是一个视角，比如个人隐私数据、联系方式、身份证、生物信息等，从企业的业务安全角度工艺参数、客户信息、经营财务中的关键数据等，反正不同的企业不一样。

三、用产品和技术思维去考虑数据安全的建设落地

数据安全团队了解了数据业务过程，并站在上帝视角，做了业务场景的抽象和简化以后，接下来就要考虑在这些数据业务场景下，数据安全的管控要求和处理办法。阿肯在“掌握企业安全建设的1+1+N，你就拿到了通向未来CISO的钥匙！”中介绍了信息安全建设的信息化、产品化和数字化，那么数据安全的建设治理更要产品化和数字化。做过企业大数据研发的人都知道，大数据的治理平台和开发平台的重要性和复杂度不亚于企业ERP建设的复杂度和重要性，这是企业数字化后期的核心工作。而数据安全的产品化数字化的复杂度和重要性对于企业安全业务数字化建设也是一样，非常复杂，而且也是整个安全业务数字化后续工作的重点。根据个人经验，阿肯认为，数据安全的建设治理方案可以简单总结为3+3: “人-应用”、“应用-库“、“人-库”三个场景，按照三个原则开展：能事前的不事中、能技术的不管理、敏感数据优先保护。概述如下：

1、人-应用：这种场景下的业务系统的用户一般涉及的是能访问哪个系统，这个系统中哪个模块，以及模块中哪些数据，是部门数据还是全网数据，以及某些敏感字段是否能访问，是否要控制还是只做审计记录，能否导出数据，或者限定可以访问的地点（公司里面可以访问，但是出了公司禁止访问）等等；这就要求企业在研发业务系统的时候，要在架构上提前布局，规划专门的精细化授权系统，做到系统、模块、行、列、按钮等授权功能，这样才能实现“人-应用”场景下的数据安全事前控制，以及事中的操作日志告警和事后的追溯分析等数据安全管理能力。

2、应用-库：在快速迭代的应用研发模式下，应用系统都是通过API对外提供数据服务的，这时候“应用-库”的数据安全，一是要做到API本身的安全，API不能随便被外部访问或调用；二是API的回参数据要有安全管理。对于API本身的安全，架构上需要有个API网关，这个网关具备API的安全管理功能，比如发布订阅、密钥管理、配置管理、签名保护，以及API调用的日志管理，实现API层面的事前防护、事中监控和事后分析能力；对于API出参数据的安全，API必须基于授权系统要求，实现出参数据的配置管理，并从业务上区分公共接口，避免暴露敏感数据，同时具备API调用库的SQL语句解析能力，实现应用对敏感字段调用访问的日志记录和打标功能，记录API调用了哪些库表数据，涉及哪些敏感字段需要脱敏。

3、人-库：这种场景下要分两类库，一类是每个应用的DB库，涉及的人主要是DBA、运维和少量开发人员，安全的要求主要是记录减少接触DB实体的人员，敏感数据落库的加密，数据导出的脱敏，以及排障查库的数据权限控制等；这类情况下，行业基本上有比较成熟的产品，比如：堡垒机/特权平台做到生产数据的不落地，以及后台操作审计；加密和脱敏产品实现敏感数据入库、出库的安全；数据库网关基于SQL语句解析和敏感数据打标功能实现开发运维人员对DB数据操作的事前控制，和事中事后管理。另一类库是大数据的存储计算服务，大家也都叫大数据湖/池，涉及的人主要是大数据的数据治理和开发人员。这类情况下，大数据湖/池中基本上有企业的全部数据，而且因为报表开发的特殊性，大量的研发人员需要对生产库进行操作，这种情况下大数据的数据治理开发以及报表配置平台除了需要满足全面的应用安全要求外，还需要跟业务系统一样，需要细化到库表字段的授权体系。这里主要涉及两类技术，一个是元数据管理和敏感数据打标功能，另一个是大数据各类SQL语句的解析能力。企业的大数据平台只要做到了这些，大数据生产过程中的数据安全基本上就有保障了。

4、安全ERP-数据安全中心：数据安全告警、数据安全报表、数据风险地图

从上面的三个场景的分析来看，要全面落地数据安全的产品化数字化工作，是一个非常艰难的过程，对企业业务的数字化和自研能力要求非常高：业务系统需要实现模块、行、列、字段、按钮以及监控埋点能力，大数据平台和DB运维平台需要基于元数据、敏感数据打标以及SQL解析实现数据细粒度控制，以及日志审计功能。这就需要企业的安全团队与研发部门通力合作，研发部门实现三个场景下应用的安全功能，完成数据安全的大部分事前防护工作，安全团队再根据数据运作中的日志做数据风险管理就简单了。所以，只要数据安全建设的方向梳理清楚了，安全团队就可以将任务切片，一步一步来，坚定不移去做，实现数据安全的产品化数字化就不难。按照阿肯一贯的做事方式，简单来说可以分成几步：

  • 首先，按照三个场景列出数据安全稽查清单，做一次完整的数据安全稽查工作；

  • 然后，基于稽查的问题清单进行专项整改，从风险的角度，督促研发部门完善三个数据场景下的系统安全功能，只要这些功能实现了，数据安全的事前防护能力就具备了；

  • 最后，安全团队基于安全ERP这个平台（详见：掌握企业安全建设的1+1+N，你就拿到了通向未来CISO的钥匙！ ），消费三个数据场景下的安全日志，实现数据风险的数字化，并在看到数据风险的情况下不断优化数据安全建设的质量。这里涉及两点：第一，数据安全人员需要确定以什么载体来看待数据安全，就像我们以IP段划分看系统资产风险地图，以部门组织看员工风险地图。阿肯认为数据风险以业务系统的维度来看比较好，因为这样可以将数据的安全问题跟各个产品线挂钩，而每个产品线都代表相应的业务部门。第二，消费数据安全的日志时，数据安全告警可以加入到预警中心，业务系统下的数据风险地图可以放到风险地图中，对各业务系统的敏感数据使用和异动可以放到安全报表中心。

补充一点，前面讲的都是线上数据的安全管理，一旦数据落到电脑终端如何管理没有说。其实这个很简单，目前终端的防泄密的技术产品就是透明加解密，沙箱技术或者事中、事后的监控和追溯等桌管产品，企业根据自身需要可以搭配使用。

阿肯发现身边有些朋友已经开始创业做一些数据安全方面的产品，希望国内越来越多的安全公司能从企业的痛点出发，做出好的数据安全产品，毕竟这是安全业务数字化过程中很重要，也是很难做的产品。

本文结束，安全无止境，让我们一起努力。

声明：本文来自阿肯的不惑之年，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。