数据安全数据仓库系列01

Posted 2021-04-24 晓阳的数据小站

（一）数据安全体系全貌

（二）一般意义上的数据安全流程

数据安全流程包括以下几个步骤：

1. 数据的产生：通过数据分级体系对敏感字段打标签；

2. 数据的存储：需要通过加密的方式存储相关数据，避免直接存储Text格式的数据；

3. 数据的使用：包括了一个独立的权限控制系统；

4. 数据的传输：相关的申请与查询操作需要通过专门的API接口进行，并且有高安全等级的加密措施；

5. 数据的展示：在申请通过后，根据申请人的安全等级，展示对应等级的数据；

6. 数据的销毁：敏感数据仅在HDFS上做逻辑删除是不够的，需要配合物理删除同步清理敏感数据。

（三）数据表分级标准

数据表分级的目标，在于通过设置合理的等级，加强对数据仓库平台下数据表的安全管理，确保敏感数据的增删改查操作都能够经过适合的授权。由于开发人员为使用便捷，数据表的安全等级通常存在安全等级设置偏低的情况，因而需要根据数据表中安全等级最高的字段进行表安全等级的设定。

以前文提到的数据使用的安全标准为例，包括业务重要程度及计算关联范围两个象限，简略的将数据表安全设置为四个等级：

S4：非业务核心表，删除对于其他计算任务无影响；

S3：非业务核心表，但删除对于其他计算任务有一定的影响；

S2：业务核心表，仅限本部门使用，删除对于其他部门使用无影响；

S1：业务核心表，删除对于其他部门使用有影响。

实际上，可以根据自身公司的业务情况，设置更多的安全等级，以标示不同业务场景下的数据安全情况，本文仅提出一个可参考的案例。

但很多情况下，大量的敏感数据是混杂在普通表中的，例如针对搜索广告系统，核心指标有三个：展现量、点击量及消费量，几乎所有不同维度的统计都需要涉及到这三个指标，因此只针对数据表的分级可能不够用，需要针对字段加入安全标准评分。

例如以用户统计的中间表为例，常见的统计指标除了上述提到的三个敏感字段之外，还包括了用户量、访问ip数、创意数量、单元数量等指标，这些非核心的字段安全等级为S2，但三个敏感字段的安全等级为S1，因此整张表从全局上看，应该设置为字段安全等级最高的级别，也就是S1。

不论是数据表，还是数据字段，通常都需要开发人员、产品人员甚至是运营人员介入进行人工的制定，但为了简化打标签的流程，通常是开发人员进行初步设定，指派一名数据安全接口人进行二次审核，并将字段的涵义明确的填入元数据平台之中。

同时，如果元数据平台包括了订阅接口人等功能，在有修改数据安全等级等操作后，还需要邮件通知相关订阅人，防止下游任务不知情导致的数据计算错误。

（四）自动标签机制

很多时候，数据表并不只是由数据开发人员创建，产品、数据分析、运营等人员操作数据表，自行建立中间查询过程，也是需要被允许的，因而有必要设定一套自动数据标签的体系，来对初始创建的数据表进行自动的安全等级检定。

但该步骤极度依赖规范化的数据规则，例如同一种统计指标，只对应一种英文涵义。例如在搜索广告中，每次搜索的结果为搜索量，每次搜索中带有的广告展示称之为展现量，在英文名的设定上，show对应搜索量，ad_show对应广告展现量。这种规范化的体系应该贯穿在元数据平台及数据开发平台的建设上，例如在开发平台上使用Select *应该是被禁止的，需要准确写出Select show才可以展示对应数据。

自动标签机制能够根据预设的安全等级规则，例如show对应S2级别，ad_show对应S1级别，既可以准确标注其字段等级。其余字段，只要是常用的业务字段，也应该有明确的英文名称。最典型的是经纬度，字段统一命名为：longitude / latitude，系统可自动设定安全等级为S4。

当自动标签机制设定完成后，整理的授权流程如下所示：

1. 使用人员新建任务；

2. 系统扫描表字段，基于规则自动建立标签；

3. 开发 / 安全人员根据规则升级 / 降级对应表等级；

4. 通知相关人员权限变更。

（五）权限申请

权限申请类似于财务报销一样，需要经过层级审批才可以使用。通常来说S2及以下字段可以直接由数据安全接口人审批，S1需要数据安全接口人、使用人的直属上级领导两层审批。

数据权限的审批应遵循如下几个原则：

1. 权限只根据需求进行授予，不能授予超过需求使用的字段及等级；

2. 不允许直接查询底层表，只能查询中间表以上的数据表；

3. 不允许查询全量数据，只可以根据字段进行查询，并且必须要有where条件；

4. S2及以上数据，不允许直接下载，仅可以在云端查看；

5. 只能够以单张表为单位，逐个申请，不允许一次性申请大范围的表权限。

（六）风险管理

1. 由于权限问题设计人员比较广，因此离职员工需要及时收回权限；

2. 权限申请时，应该设定权限申请的时间，例如一天/一周/长期；非开发人员，如果权限申请时间过长，应该及时收回；

3. 如果申请了权限而长期不适用，出于安全性考虑，也应该定期扫描并收回；

4. 申请权限时，如有必要，应填写数据披露申请单，详细说明申请的原因，用于后续问题的排查。