1、概述
在大数据平台建设初期，安全也许并非被重点关注的一环。大数据平台的定位主要是服务数据开发人员，提升数据开发效率，提供便捷的开发流程，有效支持数仓建设。大数据平台的用户都是公司内部人员。数据自己的安全性已经由公司层面的网络及物理机房的隔离来获得保证。那么数据平台建设过程当中，须要考虑哪些安全性方面的问题？web
环境隔离，数据开发人员应当只需关注本身相关业务域的数据，也应该只能访问这一部分数据。从数据的角度，减少了被接触面，下降了被误操做的可能。从数据开发人员的角度，只能访问本身业务域的数据，在数据开发的过程当中，能够减小干扰项，提升效率。安全
数据脱敏，有些敏感数据即便是公司内部的数据开发人员，也须要限制其直接访问的权限。网络
明晰权责，各业务域数据都有相应的负责人，对本身的数据负责。同时，全部数据访问与操做都有审计信息记录，对数据的转化与流动有据可查。架构
最后，大数据平台的目标是赋能数据开发人员，提升数据开发效率，而安全管理必然会下降数据平台的便利性。如何平衡安全和便利性的关系，尤其重要。机器学习
有赞大数据平台安全建设是在大数据平台自己的发展以及数仓元数据建设的过程当中不断演进的。归纳起来能够分为三个阶段。oop
2、基于 ranger +组件 plugin 的权限控制
在大数据平台刚开始构建的时候，咱们重点关注的是基础服务、任务调度、监控预警等方面。数据安全这一块，只有有限的几个数仓同窗有数据读写权限，而各业务组的同窗都只有读权限。随着公司的发展，业务量的提高，按业务进行数据隔离的需求开始变的强烈。学习
当时，咱们对各方需求进行了梳理，主要为如下几点。将数据按业务域划分，数据开发人员只能访问相关业务域的数据，粒度为表或字段级别。业务域能够和公司组织架构相对应，相关部门默认有相应权限。能够方便的进行权限申请与审批。调研对比各类实现方案以后，咱们选择了 ranger +组件 plugin 的权限管理方案。其中 ranger+ hiveServer2 plugin 的架构图以下( ranger + spark thrift server plugin 相似)：大数据
全部数据访问在 Hive Server 中进行鉴权，经过公司的 LDAP 服务进行用户认证。当时的入口有 hue、数据平台和 beeline，只有 beeline 的用户须要进行 LDAP 认证，而 hue 和数据平台的用户已经认证过了，只要传 proxy user 过来进行鉴权便可。为了支持业务域与公司组织架构相对应，须要从公司的 OA 系统将部门组织信息分别导入 ranger 以及 hadoop 进行用户组的映射。另外，扩展 hue 增长了一个权限申请与审批的模块。spa
这样的方案基本知足了业务数据隔离的需求。可是在用户使用过程当中，仍是收到了不少不满的反馈，主要缘由就是阻碍了用户使用的便利性。数据开发人员可能在数据平台进行数据查询，发现没有数据访问权限以后，须要到 hue 上申请权限。权限审批人员收到申请通知以后，须要登陆 ranger web UI，进行权限配置。数据管理人员须要直接在 ranger 中配置初始权限。这些都是很不方便的点。另外，ranger 支持的查询引擎有限，想要增长查询引擎(如 presto)就须要定制化开发。所以，这种 ranger + plugin 的作法，执行引擎的可扩展性并很差。由此，咱们进入了安全建设的第二阶段。rest
3、基于 ranger 的权限管理服务
为了提升用户使用的便利性，咱们须要收敛数据平台的入口，下线 hue，全部的数据访问及权限申请与审批都直接可在数据平台上完成。而且，当用户访问到某个无权限的数据时，能够直接一键申请。为了提高执行引擎可扩展的能力，咱们须要将 ranger 与执行引擎解耦，执行引擎能够不用鉴权。所以，咱们在元数据系统中增长了权限管理服务模块，经过 Restful 接口与 ranger 交互。架构图以下：
全部数据访问直接在数据平台这个入口，经过权限管理服务进行鉴权。支持权限一键申请及一键审批。还能够支持临时权限等特殊请求。数据管理人员也不用在 ranger 中配置策略，而是经过权限管理页面直接进行数据业务域配置，而后自动映射为 ranger 中的策略。另外，咱们还在这一阶段创建了完整的审计体系，作到了全部数据访问与操做有据可查。
4、基于 column masking 的数据脱敏
随着公司业务的进一步增加，对敏感数据的脱敏需求变的更增强烈。咱们须要将各类手机号、邮箱地址之类的敏感字段进行脱敏处理，例如手机号只显示后四位。ranger 虽然支持 column masking，可是咱们在第二阶段已经将 ranger 与执行引擎进行解耦。所以，咱们须要在数据平台层面，对数据进行脱敏。咱们采用的方案是 SQL 重写。架构图以下：
SQL Engine Proposer 是咱们开发的一个智能执行引擎选择服务，能够根据查询的特征以及当前集群中的队列状态为 SQL 查询选择合适的执行引擎。数据平台向某个执行引擎提交查询以前，会先访问智能执行引擎选择服务。在选定合适的执行引擎以后，经过敏感字段重写模块改写 SQL 查询，将其中的敏感字段根据隐藏策略(如只显示后四位)进行替换。而敏感字段的隐藏策略存储在 ranger 中，数据管理人员能够在权限管理服务页面设置各类字段的敏感等级，敏感等级会自动映射为 ranger 中的隐藏策略。例如表 ods.xxx 中的列 acct_no 的敏感等级为 2，那么映射为 ranger 中的策略以下：
当某个查询语句为
select acct_no from ods.xxx where par='20181128' limit 10;
通过脱敏重写，最终执行的查询语句为
SELECT acct_noFROM (SELECT `par`, `id`, CAST(mask_show_last_n(acct_no, 4, 'x', 'x', 'x', -1, '1') AS bigint) AS `acct_no`, `kdt_id`, `water_no` , `target_id`, `remark`, `create_time`, `sub_target_id` FROM `ods`.`xxx` ) `xxx`WHERE par = '20181128'LIMIT 10;
咱们使用 antlr4 来处理执行引擎的语法文件，实现 SQL 重写。其中，spark 和 presto 都是使用的 antlr4，因此他们的语法文件直接拿过来用便可。因为 hive 目前使用的是 antlr3 的版本，咱们将 hive 的语法文件使用 antlr4 的语法重写了一遍。之因此要所有用 antlr4，是为了最大程度的重用 visitor 的逻辑。基于一样的方法，咱们实现了字段血缘的追溯，从而能够进行字段的敏感等级传递。
5、将来展望
大数据平台的安全建设并非一项孤立的工做，而是随着大数据平台支持的业务量和业务种类愈来愈多，与大数据平台自己的进化而一块儿发展的。随着有赞实时数仓的建设、机器学习平台的构建等等新业务的发展，安全建设仍有很长的路要走。