关于react.js:有赞大数据平台安全建设实践

3次阅读

共计 2979 个字符，预计需要花费 8 分钟才能阅读完成。

简介： 在大数据平台建设初期，平安兴许并不是被重点关注的一环。大数据平台的定位次要是服务数据开发人员，进步数据开发效率，提供便捷的开发流程，无效反对数仓建设。大数据平台的用户都是公司内部人员。数据自身的安全性曾经由公司层面的网络及物理机房的隔离来失去保障。那么数据平台建设过程中，须要思考哪些安全性方面的问题？

文 | 群演 on 大数据

在大数据平台建设初期，平安兴许并不是被重点关注的一环。大数据平台的定位次要是服务数据开发人员，进步数据开发效率，提供便捷的开发流程，无效反对数仓建设。大数据平台的用户都是公司内部人员。数据自身的安全性曾经由公司层面的网络及物理机房的隔离来失去保障。那么数据平台建设过程中，须要思考哪些安全性方面的问题？

环境隔离，数据开发人员该当只需关注本人相干业务域的数据，也应该只能拜访这一部分数据。从数据的角度，减小了被接触面，升高了被误操作的可能。从数据开发人员的角度，只能拜访本人业务域的数据，在数据开发的过程中，能够缩小烦扰项，提高效率。

数据脱敏，有些敏感数据即便是公司外部的数据开发人员，也须要限度其间接拜访的权限。

清晰权责，各业务域数据都有相应的负责人，对本人的数据负责。同时，所有数据拜访与操作都有审计信息记录，对数据的转化与流动有据可查。

最初，大数据平台的指标是赋能数据开发人员，进步数据开发效率，而平安治理必然会升高数据平台的便利性。如何均衡平安和便利性的关系，尤为重要。

有赞大数据平台平安建设是在大数据平台自身的倒退以及数仓元数据建设的过程中一直演进的。概括起来能够分为三个阶段。

在大数据平台刚开始构建的时候，咱们重点关注的是根底服务、任务调度、监控预警等方面。数据安全这一块，只有无限的几个数仓同学有数据读写权限，而各业务组的同学都只有读权限。随着公司的倒退，业务量的晋升，按业务进行数据隔离的需要开始变的强烈。

过后，咱们对各方需要进行了梳理，次要为以下几点。将数据按业务域划分，数据开发人员只能拜访相干业务域的数据，粒度为表或字段级别。业务域能够和公司组织架构绝对应，相干部门默认有相应权限。能够不便的进行权限申请与审批。调研比照各种实现计划之后，咱们抉择了 ranger + 组件 plugin 的权限治理计划。其中 ranger+ hiveServer2 plugin 的架构图如下 (ranger + spark thrift server plugin 相似)：

所有数据拜访在 Hive Server 中进行鉴权，通过公司的 LDAP 服务进行用户认证。过后的入口有 hue、数据平台和 beeline，只有 beeline 的用户须要进行 LDAP 认证，而 hue 和数据平台的用户曾经认证过了，只有传 proxy user 过去进行鉴权即可。为了反对业务域与公司组织架构绝对应，须要从公司的 OA 零碎将部门组织信息别离导入 ranger 以及 hadoop 进行用户组的映射。另外，扩大 hue 减少了一个权限申请与审批的模块。

这样的计划根本满足了业务数据隔离的需要。然而在用户应用过程中，还是收到了很多不满的反馈，次要起因就是妨碍了用户应用的便利性。数据开发人员可能在数据平台进行数据查问，发现没有数据拜访权限之后，须要到 hue 上申请权限。权限审批人员收到申请告诉之后，须要登录 ranger web UI，进行权限配置。数据管理人员须要间接在 ranger 中配置初始权限。这些都是很不不便的点。另外，ranger 反对的查问引擎无限，想要减少查问引擎 (如 presto) 就须要定制化开发。因而，这种 ranger + plugin 的做法，执行引擎的可扩展性并不好。由此，咱们进入了平安建设的第二阶段。

为了进步用户应用的便利性，咱们须要收敛数据平台的入口，下线 hue，所有的数据拜访及权限申请与审批都间接可在数据平台上实现。并且，当用户拜访到某个无权限的数据时，能够间接一键申请。为了晋升执行引擎可扩大的能力，咱们须要将 ranger 与执行引擎解耦，执行引擎能够不必鉴权。因而，咱们在元数据系统中减少了权限治理服务模块，通过 Restful 接口与 ranger 交互。架构图如下：

所有数据拜访间接在数据平台这个入口，通过权限治理服务进行鉴权。反对权限一键申请及一键审批。还能够反对长期权限等非凡申请。数据管理人员也不必在 ranger 中配置策略，而是通过权限治理页面间接进行数据业务域配置，而后主动映射为 ranger 中的策略。另外，咱们还在这一阶段建设了残缺的审计体系，做到了所有数据拜访与操作有据可查。

四、基于 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 的逻辑。基于同样的办法，咱们实现了字段血统的追溯，从而能够进行字段的敏感等级传递。

大数据平台的平安建设并不是一项孤立的工作，而是随着大数据平台反对的业务量和业务品种越来越多，与大数据平台自身的进化而一起倒退的。随着有赞实时数仓的建设、机器学习平台的构建等等新业务的倒退，平安建设仍有很长的路要走。

原文链接
本文为阿里云原创内容，未经容许不得转载。

正文完