第二十一章：数据治理之数据安全：数据安全的驱动因素以及常见的数据安全举措

怎么样就算数据安全了？这个问题的答案和数据质量有点类似。在数据质量中没有绝对的高低，只要能够满足当前业务的发展需求，就算是高质量数据了。同样的，在数据安全上，也可以做类似的对比，只要满足了对数据安全的要求，那么数据就是安全的了。

这些要求是动态的，可能在此刻是安全的，下一刻新的要求出现就是不再安全的了，所以数据安全这个状态是一个动态的，随着要求变化而变化的。

数据安全都有哪些要求？也就是数据安全的驱动因素都有哪些。

1、数据安全的驱动因素

数据安全的驱动因素一共分两类：外部因素、内部因素。

在外部因素上，首先就是各种法律法规。

在国内，《网络安全法》、《数据安全法》、《个人信息保护法》，以及各种行业部门规章、地方性法规等等。国外的，欧盟的《通用数据保护条例》（GDPR）等等。都对于数据的安全提出了一些要求。因此，企业在应对数据时，都需要遵守相应的法律法规。

同时，对数据安全的监管上也呈现上升趋势。特别是在金融、水利、交通、教育、政府、电信与互联网，都是监管较为严格的行业。基于监管的要求，企业也需要重视数据安全。

在内部因素上，主要是数据量激增和行业教育，使得自身的数据安全意识增强。

随着数据量的增加，隐藏在数据中的信息、知识，甚至智慧也逐渐丰富。并且国家也将数据作为一个生产要素，不断强调数据是一种生产资料。让企业意识到数据是企业的一种资产，需要有意识地保证数据的安全。

同时，企业在日常运营中收集了大量数据，而这些数据的泄露可能造成严重后果，也让企业意识到数据安全是一项不可推脱的责任。

基于外部因素和内部因素，企业在重视探索数据价值的同时，也不断在强调需要在保证数据安全的前提下进行。

2、数据安全是系统性的一系列活动

保证数据安全是系统性的一系列活动，影响因素很多。

比如，网络与基础架构安全中防火墙、VPN、入侵检测与防御，应用安全的web应用防火墙，数据库中的数据库安全、数据库审计和风险控制，身份与访问管理的运维审计堡垒机，安全管理的日志分析和审计等等很多的领域，都会和数据安全有关。

同样，给数据安全造成风险的是因为未授权的访问，还是有意无意的泄露，是被篡改了内容，还是被外部破坏，是人为的丢失，还是数据不可用，等等也是多方面的都会对数据安全造成影响。

那么，我们在数据治理中，或者说在数据平台产品这个框架内要讨论哪些数据安全举措。这个就又可以参考【数据治理的边界】那一章中提到的数据治理的边界，这里我们仅讨论已经入湖之后的数据的数据安全，在入湖之前的数据，不在我们讨论的边界范围内。

再详细列举的话，我们仅仅会讨论入湖后数据的：数据权限、数据脱敏、数据加密、数据分级、数据备份、数据审计，六个方面。

这些数据安全的举措，可以涉及到数据生命周期的各个阶段：数据收集--数据存储--数据处理--数据使用--数据共享--数据归档--数据销毁，我们不去做具体对应哪些阶段的映射，注重讲解数据安全的六个方面。

3、数据安全像一只隐藏的“黑天鹅”

在正式介绍数据安全六个方面之前，说一下个人对于数据安全的感受。

数据安全有一点像一个隐藏的黑天鹅，平时的时候似乎不怎么受关注，但是一旦出问题就可能是影响巨大的事情，而且这种事情还比较难以预测。

数据安全风险可能存在数据生命周期中的任何环节。出现数据安全问题的原因也可能是多样的，是技术的问题、是管理的问题、还是人的因素。

是内部无意造成的，误删、泄露，还是外部恶意造成的，窃取。似乎可以从任何一个意向不到的角度，就会出现数据安全的问题。

这就让数据安全，像一根弦一样，并不一定时刻都紧绷着，但是需要知道有这样的一个存在。

数据安全并不为使用数据负责，甚至有“安全和效率不可兼得”的说法，给数据安全做的限制越多，使用数据时的效率就会有相应的下降。

个人感觉数据安全是一种状态，一种动态的状态，不可能做了什么就是安全的，只能去做什么尽量避免打破这个安全的状态。

一种：没人敢说数据安全了，也没人敢说数据不安全的薛定谔的猫的状态。

4、数据权限是第一步限制

说到数据安全，数据权限一定是第一步的限制。

哪些用户，能够对哪些对象，进行哪些操作。

用户也是我们一直说的数据加工者、数据消费者，这两类用户。

操作的对象，主要是表，有时会到字段粒度，有时还需要对数据行进行区分。

能够进行的操作也是增、删、改、查的通用操作。

这三者的组合其实就是一个数据权限授权的过程，如何将这三者组合好进行授权，也是数据权限需要关注的关键？

个人理解有三种形式：基于人的、基于角色的、基于组织的。

基于人的：

最直接的方式就是基于人的，直接在人的粒度上进行设置，什么人可以对什么表进行什么操作，这种的权限设置当然也是可以的，但是数据量一多了，一定程度上就会很乱。如果软件设置的不合理，某张表被授权给了多少人，这些人分别有什么权限，都很难统计出来。同一个部门的人是不是具备相同的权限，是不是有超过合理范围的权限被设置？等等。都是基于人设置权限的问题。

基于角色的：

****如果不直接作用在人上面，增加一个中间的角色那？也就是基于角色的访问控制--RBAC模型了。虽然，这个模型主要是基于角色的权限控制，是用在功能权限管理中的，在数据权限中有一定的局限性，并不能适配所有的场景，但是这个模型简单、通用，可以基于这个模型进行调整，更加方便理解。

相较于直接基于人的授权，基于角色的授权在两者之间，增加了一个角色的概念，即从“用户-权限”，调整为“用户-角色-权限”的三层关系。

将一组数据的权限（可以是数据的增删改查的任意权限）放到一个角色里面去，然后再将角色授权给不同的用户。

这样设置的问题，也很明显。

问题一：缺乏动态的数据关联

动态的数据关联，也就是行级权限的限制。比如：根据不同的用户只能访问不同部门的数据。

因为在添加的一组数据权限里面，都是静态的，没有办法做到根据数据做动态调整。

应对方案：

应对的方案也很明确，就是将“数据权限”和“功能权限”解耦。（这里的数据权限特指行权限）。

比如在SQL查询中自动 注入如：WHERE department_id = current_user_department类似的限制条件，就做到了行级别的数据权限限制了。

但是，这个方案有三个限制点，一就是用户在查询的时候，能够知道用户当前部门是什么部门的。二即使知道了是什么部门的也需要知道这个部门能够和数据层面映射上，进而去限制住，这个部门的人能够查允许的数据。三就是需要下游使用数据时，能够对此种形式的逻辑做适配，毕竟，是在SQL逻辑中添加了一个过滤语句，是否能够适配下游的应用，需要做下调整。

这里比较重要的一点是，需要考虑清楚，目前是不是必须进行行级别的数据权限限制。如果在数据权限中并没有行级权限的需求，那么这一条就可以忽略了。

问题二：角色爆炸问题

产品功能是有限的，所以RBAC模型在进行功能权限管理时，角色数量有限，能够很好的管理住产品的功能权限。

但是，数据的权限组合是无限的，哪些用户，能够对哪些对象，进行哪些操作，这种组合的过程中，如何单纯将哪些对象可以进行哪些操作打包成一个角色，然后授权给个人，很容易出现角色爆炸的问题，角色会急速膨胀，管理成本激增。如果产品设计没有考虑细，当统计某些人有哪些表的权限，某些表被授权给某些人，甚至比基于人的授权更加难以统计，因为中间有一个中间层了。

应对方案：

应对方案的话就是ABAC模型，即基于属性的的访问控制。

怎么理解基于属性的访问控制那？

如果RBAC基于角色的访问控制中，角色是可以灵活创建、临时创建的。

那么ABAC基于属性的访问控制，就是需要提前创建好属性，我们主要是对人进行授权，也就是需要提前设置好人的属性，比如一个部门如果是经理，能够进行读写操作；如果是普通员工，只能进行只读操作。

这个方案的限制，其实和上一个类似，就是需要提前知道人所在的部门，已经在部门的属性。

这一点其实是更难的，一个公司里面的组织架构其实有的时候并不能完全反应实际情况。

所以，基于角色的授权，看似方便，但是在实际落地的过程中可能存在各种各样的问题，需要考虑清楚。

基于组织的：

除了基于人的、基于角色的，第三种授权形式就是基于组织的了。

这里的组织，多少类似于组织架构中的部门的概念，但是总感觉直接利用组织架构中的部门，会将数据权限扩散。所以，这里的组织更多的是在数据权限管理过程中自己创建的一个。

让不同的部门自己创建自己团队的组织，然后指定组织的管理员，统一进行权限申请，统一进行权限分配。

个人认为，这是一个比较好的权限分配形式。

上面三种方式，不管最终使用哪一种方式，有一个最大的问题就是，这种授权方式是否试用于现有的企业内的权限申请流程。

如果现在企业内权限的申请流程是按人申请的，且申请之后只能开通现有流程中已申请的表的权限，那么只能基于人来做授权了。

如果现有企业内的权限的申请是按照组织来进行，授权之后组织内进行二次分配，那么按照部门就是一个很好的方式。

到底需要用怎样的数据权限授权方案，其实需要结合实际的权限申请流程、粒度来做决定。

而数据权限申请的过程，需要先找到需要申请权限的数据。这就又和我们前面介绍的数据目录相结合，我们在【数据目录】也提到了数据目录的三种分类“数据资源目录、数据资产目录、数据开放目录”，对于数据加工者和数据消费者，是基于这三类目录中的哪个目录的基础上进行权限申请流程，也是需要按照实际情况进行讨论的。

上面大概说了数据权限的授权形式，下面我们思考两个问题？

一个问题是数据权限的审批节点问题？

一个问题是数据权限的传递的问题？

数据权限审批节点的问题：

数据中台只管理数据，不拥有数据。数据仍然是业务的，换句话说就是数据中台的数据owner仍旧是各个数据的业务方。因为我们不拥有数据，所以当有业务方想使用数据，进行申请数据的时候，理论上仍然需要业务方进行审批的（当然，这里也会有数据owner、数据BP等不同的审批类型）。业务方审批通过之后，数据中台的人再审批（主要技术层面的一些审批）。这里有个问题就是如果数据消费者来申请的话，抛开敏感的、机密的数据不提，业务方有什么理由不审批通过那。如果都审批通过了，是不是申请审批就变成了一种形式了。

这还不考虑，数据中台将数据进行加工之后，多个业务方数据汇总表，没有办法指定唯一业务方，甚至区分不出来业务方了。

所以，是否比较合理的形式是，规定好数据密级之后，如果是普通密级的，跳过业务方审批，直接数据中台进行偏技术维度的审批就可以了。如果是高密级的再进行业务审批。（当然高密级的也不会放在一个集群上）。这样既能减少各方的审批压力，又能加快用数效率，还能提升数据中台的审批地位。

这是一个思考的问题，每个人都可以有自己的答案。

数据权限传递的问题：

这里的权限的传递，到不是说权限的上下继承，这里的权限传递是指在不同组件间的权限打通。这里仅仅是一个想法讨论，并没有实践完全实现。或者有更好的方案，工作中没有接触到。

要考虑数据权限的传递范围，首先需要考虑的一个点就是在整个大数据流转使用过程中一共经过多少种存储组件，或者说一共经过了多少种存储类型。不考虑批流一体，数仓一体等等。只说一个比较通用的场景，业务数据进入数据中台被用户使用的流转：第一步进入数据湖（HIVE、ODPS等等大数据存储，在其中进行数据的分层加工），第二步，进入数据仓库（MPP、MySQL、GP等。因为大数据存储类的查询效率较慢，不足以支撑快速查询要求所以需要一个快速查询引擎）第三步，被多种方式进行数据消费（做成BI报表被消费、做成数据服务API被消费、直连查询被消费）。

我们总是希望一处授权，多处使用的，但是像上面这三步，涉及到不同的存储，不同的工具。不同存储有不同账号进行权限管理，不同工具之间又会有自己的权限体系。基本上打通很困难，很多环节中都需要人工进行一定的传递。

上面说的这种，可能有不同的方式能够更好的来解决这个问题，只是自己没有接触到。希望后续能够不断的深入吧。

数据权限本身是一个很大的领域，这一小段仅仅就是抛转引玉了。

5、数据脱敏

数据脱敏和数据加密都是数据保护技术。对于一些敏感信息，如电话号码、地址、身份证信息等等，防止泄露，进行数据保护。

脱敏在隐藏数据真实内容的时候，仍然保持数据可用，也就是仍旧保持了数据本身的格式，如11位手机号，中间四位变成*，如人名变成“王*”。

而且，脱敏后的数据是不可逆的，即通过获取脱敏后的数据，没有办法之后，未脱敏的数据是什么样。

主要也是在开发测试、数据分析、数据共享等，场景下使用。

脱敏方式可以分为静态脱敏和动态脱敏，每种脱敏也有不同的脱敏形式。

• 静态脱敏

  静态脱敏是在底层存储的时候，就直接存储脱敏之后的内容。

  静态脱敏方式有：

  替换：用虚构数据替代真实值（如将真实姓名替换为随机生成的姓名）。

  遮蔽（Masking）：隐藏部分字符（如手机号 138****1234）。

  泛化（Generalization）：降低数据精度（如年龄“25”脱敏为“20-30岁”）。

  随机化：打乱数据顺序（如随机重排订单ID）。

  删除：直接移除敏感字段（如删除身份证号列）。

• 动态脱敏

  动态脱敏，底层存储的数据仍就是原始的数据。而是在读取数据的时候，需要进行动态的脱敏，返回的是加密之后的内容。

动态脱敏往往又和数据的密级、用户的密级有关，这个在数据密级部分在介绍。

动态过敏的方式有：

条件遮蔽：基于用户身份动态隐藏部分数据（如普通员工仅看到客户姓氏）。

数据截断：仅展示部分信息（如银行卡号显示后四位）。

虽然，数据脱敏了，但是在进行数据关联的时候仍旧是希望能够进行关联上的。这种时候，就需要判断选择的数据脱敏方式，是不是仍旧能够满足数据可用的这个目标，这是一个比较关键的点。

6、数据加密

数据加密是防止数据被未授权访问，保证数据机密性。加密之后的数据，数据格式就会变化了，甚至是不可读的密文。比如保护银行卡密码。

而且，加密后的数据一般是可逆的，只要有对应的秘钥，就能将数据还原。

主要也是在数据传输、存储、访问控制等高安全场景下使用。

加密方式可以分为对称加密、非对称加密、哈希算法加密。

• 对称加密： 原理：加密与解密使用同一密钥，速度快，适合大数据量场景。

算法：

AES（高级加密标准）：支持128/192/256位密钥，广泛用于文件加密。

DES/3DES：逐渐被AES取代，仍用于遗留系统。

• 非对称加密：

  原理：使用公钥加密、私钥解密，解决密钥分发问题。

  算法：

  RSA：用于数字签名、HTTPS证书。

  ECC（椭圆曲线加密）：同等安全下密钥更短，适合移动设备。

• 哈希算法（单向加密）： 原理：将数据转换为固定长度哈希值，不可逆。

算法：

SHA-256：用于数据完整性验证（如文件校验）。

MD5（已不推荐）：易碰撞，仅用于非敏感场景。

当然，还有其他的加密方式，有兴趣的可以多了解些。

7、数据分级

在【数据脱敏】小节，也提到动态脱敏往往又和数据的密级、用户的密级有关。不同用户的密级在查询不同密级的数据时，依据密级的规则，来判断是返回真实数据，还是脱敏后的数据。

如果是动态加密的话，我们希望级别高的人能够正常查看数据，级别低的人看到的是加密之后的数据，所以这就又和数据的密级有关。每条数据都会涉及到密级，可以给一个默认的。密级比较高的再单独设置。

如果设置了数据的密级，就需要有一个人员的密级来进行配合。当人员密级高于数据密级时，正常显示数据。当人员密级低于数据密级时，数据被加密，显示加密脱敏后的数据。

不管是密级设置还是脱敏功能，都涉及到同一个用户在不同产品模块中是不是能够行为一致的问题，这个是一个需要统一考虑的点。

而且，密级的设置又是设置在表之上的，而我们的所有表的管理都归类到了【数据目录】中，如何在数据目录中统一进行密级设置，也是需要提前考虑的。

8、如何找到需要被加密的数据

上面介绍的，不管是数据脱敏、数据加密、还是对数据进行密级的设置，这些脱敏、加密的方法本身不是难点。

难点是在不同的阶段，如何识别出来，需要被脱敏、被加密、被设置密级的数据？

前面介绍过的数据的整个流程。对照这流程，我们需要解答三个问题。

第一个问题：哪些用户的哪个阶段？

各个方法涉及的阶段不同。

你是对数据加工者进行设置的，还是对数据消费者进行设置的？

你是在数据加工阶段进行的设置，还是在数据消费阶段进行的设置？

数据脱敏，如果是动态脱敏，则是在数据消费阶段，即数据消费者消费数据的时候，进行脱敏。如果是静态脱敏，则是在数据加工阶段进行数据脱敏，则存储的数据直接就是脱敏之后的数据。

数据加密，如果是在数据加工阶段进行数据加密，则存储的就是加密之后的数据。如果是动态加密，则是查数据的时候。

第二个问题：如何找出来对应的数据

如果需要设置的字段，直接体现在字段名称上，可以识别字段名来确定需要设置的字段。

如果在字段名称上没有体现，而是只在内容里面那，需要如果识别出来。都是需要考虑的。

第三个问题：如何设置

是通过手动设置，还是通过自动识别来设置？

是设置在表级别上，还是设置到字段级别上？

个人其实也没有特别好的思路，之前设计的产品都是手动的在字段级别上面设置。但是这种方式的问题就是，一方面，设置过程复杂，因为是手动字段级别，需要分别去设置。另一方面，就是设置了之后，其实是很影响使用的，所以这个功能的使用率一直是不高的。这个问题，目前没有好的思路。

9、备份

备份也是一种常见的数据安全手段，不过因为现在技术上都是几副本机制，也算是一种变相的备份机制了。

10、审计

如果说权限、脱敏、密级等等都是在查询过程中进行数据安全的限制。那么审计就是数据已经查询了之后的告警、统计。

可以统计出来谁访问过什么数据，谁修改过什么数据，从而做到事后的汇总。

这个安全更多的是，事后的一个统计定位。进行问题、风险的复盘。

11、安全与效率的冲突

数据安全的举措，显然是与数据使用的效率相冲突的。一个好的数据安全举措，在将使用使用体验降低到最小的前提下，还能保证数据安全，也就是说当数据安全越不引人注意的时候，数据安全就是越成功的。

这些数据安全的设置可以在数据加工过程中，也可以在数据消费过程中，可以是静态的、也可以是动态的。

不论是哪个阶段、哪种形态，都势必会影响到原有的，或者说没有安全设置的流程。那么，怎么将这个影响降到最低，就是一个需要考虑的方案。

这个方案中有一种就是，对数据存储区域进行划分，而不是在技术上进行限制？

就像在数据权限部分讨论过的一样，大部分时候对于内部数据的普通数据使用，又有什么理由拒绝那？增加数据审批，大部分时候沦为了流程记录器。

如果设置了数据加密、数据脱敏、数据密级，那么在使用数据的过程中，如何保证在使用时，仍然是可用的那。

12、5个维度

• 组织

在组织上似乎不需要做特殊设置。唯一需要的是和安全部门、合规部门进行配合。毕竟外部的法律法规不是数据中台的专业。

• 政策

影响了效率，就需要有政策的支撑。

• 工具

不管是数据权限，还是数据脱敏、数据加密、审计，都是需要有相应的工具支撑的。需要提前准备好工具。

• 业务

什么样的数据是需要确保安全的，需要结合具体业务。可能大部分都是通用的，但是不同业务有没有特例，是需要具体业务具体分析的。

• 数据

数据安全中不需要对数据了解多深。

13、总结

对于数据安全的重视，是随着对数据的重视而越来越多的被提起。

随着各种数据安全法的出台，对于数据安全会越来越重视。同时，这又是一个相对即新又老的模块。说它老，是因为，随着数据的产生，数据安全就是一直被提及的。说它新，是因为很多刚刚出台的法律，需要如何做调整，都是不明确的，而且隐私计算、区块链在数据安全上承担的定位在哪里，也是需要不断探索的。

安全线就是生命线，保护好了数据安全，就是保护好我们自身。