社区团购网拼多多卖菜美团菜鸟橙心兴盛优选中国十大团购平台

1.概述

随着移动互联网的发展成熟，各种不同形式的网购成为了用户消费模式当中非常重要的一部分，同时随着平台用户量的不断增长，平台企业可以拥有的数据量也随之成倍增长，随着大数据的到来，数据当中蕴藏的巨大商业价值正在逐步被挖掘出来。但是这些数据当中包含了个人用户隐私以及企业的经营数据，个人用户隐私当前国家出台了相关的隐私保护法，企业必须保证这些隐私信息的安全，同时企业的经营信息是企业的机密信息，必须防范这些信息被竞争对手获取或者泄露。为了保证用户隐私信息安全以及防止企业机密数据的泄露风险，需要对于兴盛优选底层大数据组件当中存储的数据进行用户访问安全控制，核心表的数据必须经过授权才能访问，将数据控制在有限的范围内；隐私数据需要经过脱敏才能访问，不展示原始的隐私数据。

2.业界分析

通过调研分析发现，业界比较知名的大数据用户权限控制的产品有Ranger和Sentry：

Apache Sentry：

Sentry是由Cloudera公司内部开发而来的，初衷是为了让用户能够细粒度的控制Hadoop系统中的数据（这里主要指HDFS，Hive的数据），所以Sentry对HDFS、Hive以及同样由Cloudera开发的Impala有着很好的权限控制支持。

Apache Ranger：

Ranger则是由于另一家公司Hortonworks所主导，它同样是做细粒度的权限控制，但相比较于Sentry而言，它能支持更丰富的组件，包括于HDFS、Hive、 HBase、Yarn、Storm、Knox、Kafka、Solr、NiFi。

我们目前使用的大数据的底层组件采用的是MRS以及GaussDB，而MRS对于Ranger做了集成，对MRS中的用户、角色、群组通过Ranger进行管理，形成了一套完整的用户身份安全认证及用户权限管理的一站式权限平台，对用户访问Hadoop生态的大数据资源库、表、列脱敏、行过滤有着完整的支持。

接下来我们着重介绍一下Ranger的架构。

Ranger主要由以下三个组件构成：

1、Ranger Admin：Ranger Admin是Ranger的核心模块，它内置了一个Web管理页面，用户可以通过这个Web管理界面或者REST接口来制定安全策略。

2、Agent Plugin：Agent Plugin是嵌入到Hadoop生态组件中的插件，它定期从Ranger Admin拉取策略并执行，同时记录操作记录以供审计。

3、User Sync：User Sync将操作系统用户/属组（Users/Groups）的权限数据同步到Ranger的数据库中。

它们之间的关系如下图所示：

图一 Ranger架构图

Ranger Admin是Apache Ranger和用户交互的主要界面。当用户登录Ranger Admin时，可以针对不同的Hadoop组件制定不同的安全策略；当策略制定好并保存之后，Agent Plugin定期（默认是30秒）从Ranger Admin拉取该组件配置的所有策略，并缓存到本地。这样，当有用户来请求Hadoop组件的数据服务时，Agent Plugin就提供鉴权服务，并将鉴权结果反馈给相应的组件，从而实现了数据服务的权限控制功能。当用户在Ranger Admin中修改配置策略后，Agent Plugin会拉取新策略并更新；如果用户在Ranger Admin中删除了配置策略，那么Agent Plugin的鉴权服务也无法继续使用。

以Hive为例：

图二 Ranger控制Hive权限原理图

3.业务诉求及系统约束

既然Ranger已经做了比较精细化的权限管控，为什么我们还要做一套大数据安全管控平台呢，原因如下：

1、Ranger只能管控Hadoop生态的数据，并不支持管控其他的MPP架构的OLAP数据库，如GaussDB、StarRocks，无法做到一站式对多数据库类型（如GaussDB、StarRocks等）进行权限的管理。

2、Ranger Admin管控界面对用户使用者无法做到快速授权、撤权的规范，使用不当或权限复杂的情况无法定位用户拥有哪些库和表的权限。

3、对于不同MPP架构的OLAP数据库需要维护不同的授权命令，管理成本较高。

4、方便被其他系统集成。

我们的系统设计目标要满足如下的约束：一站式、系统自我安全、服务化。

一站式

整个数仓架构当中使用了不同的大数据组件，用于不同的业务场景，当前数仓架构当中包含如下的主要大数据组件：Hive、Hetu、Guassdb，不同的产品有不同的权限管理规则，将这些产品集中在数据安全管控平台(Datas)统一管理，目的如下：

1、多集群多数据源统一管理，减少运维成本。

2、用户权限可视化授权、撤权、查看权限。

3、屏蔽每个DB的权限管理逻辑，平台已在后台针对性实现，反馈上层用户化统一权限规则。

4、统一上层用户数据源管理，防止用户越权访问DB账户。

系统自我安全

1、平台接口对接麒麟统一鉴权，同时对外提供自己的接口访问认证机制，保证访问者是合法安全的。

2、DB账户密码采集非用户自己输入，平台会随机生成强密码，对数据访问账户密码屏蔽。

3、SDK提供统一数据访问连接池，用户不需要关心JDBC账号、密码，只需要提供kylin账户ID即可获取到能够访问的数据权限的连接池。

4、审计日志记录，对用户操作DB账户权限的操作以日志的方式记录。

服务化

对外提供统一的授权API，其他系统可以集成数据安全管控平台的SDK对于系统当中涉及的大数据表进行用户权限的管控。

4.架构及实现

4.1 整体技术架构

安全管控平台架构总体分为四层，分别为：Rest API层、DB权限服务层、异步授权处理层、用户访问数据（SDK）控制层。

Rest API层：对权限管理平台（前端）的服务接口，包含用户、群组、DB集群、DB集群用户、审计日志、审批流、授权管理接口。

DB权限服务层：对不同DB授权业务逻辑实现。

异步授权处理层：处理并发授权容易导致权限混乱，采取异步排队方式，基于申请时间前后处理用户权限申请。

用户访问数据（SDK）控制层：用户在系统业务开发需要通过JDBC账户密码获取连接来操作数据库，SDK就是专门为开发人员打造的用户数据源插件，系统可以通过kylin用户获取对应的连接池来执行用户需要操作的sql，从而达到控制用户对数据操作权限的规范。

从业务的角度，我们需要依赖DataStudio元数据中心，用户针对自身业务来选择自身业务的库、表授权，在存储上采用mysql来管理kylin用户、群组、db用户、以及用户授权信息，权限管理上采用对database、table、column进行常用增、删、改、查、admin、建表权限的控制，以及对列的敏感信息过滤，我们还提供的SDK用户认证及数据源管理插件，用户不需要关心怎么去连接数据库，只需要给我们提供kylin登录用户ID，即可获取当前kylin用户对数据库操作的连接池，至于用户是否有可操作性库、表权限，由数据库本身来提供鉴权，如果没有操作权限用户需自行catch异常来满足自身业务的告警。

图三：数据安全管控平台系统架构图

Distributed Lock：分布式锁，为了保证安全管控平台服务稳定性，我们将平台部署N台机器，每台节点都有一个授权异步工作线程，如果多个节点同时从队列中拿出同样的授权待处理请求，这样会造成权限错乱。所以通过分布式锁，每台节点的工作线程通过分布式锁来获取当前有谁来处理队列中的授权任务，处理完成后释放锁。

异步处理引擎：库、表授权都采用异步处理机制，这样处理目的：

1、预防多用户同时对一个表授权、删除权限等操作导致权限的不完整性

2、批量提交库、表权限会比较耗时，防止请求等待过久影响使用体验

身份认证拦截器：对用户请求安全认证，认证分为两种模式：

1、接入Kylin用户认证

2、对外开放rest api token认证，通过请求token来验证当前是否合法用户请求

虚拟用户API：内部封装了调用MRS平台的安全接口，同时对虚拟用户创建、修改密码、生成keytab认证文件等接口的封装。

Ranger授权API：Ranger是一个对大数据组建授权的开源框架，我们通过对Ranger提供的api进行对接，封装了一系列对Hive、Presto权限管理的一套api，满足对用户授权，失败重试操作的幂等性和完整性。

DB授权API：内部封装了对GaussDB的授权接口，满足对用户授权失败重试操作的幂等性和完整性。

SDK数据源插件：为开发或应用提供的数据源插件，用户可以将SDK通过maven引入到自己系统，通过当前操作sql的kylin用户ID即可获得JDBC Connection，然后通过Connection去执行用户的需要执行的SQL，如果SQL执行失败或者未授权等，需要用户自行根据异常信息来判断失败原因。

4.2 用户关系介绍

权限管理系统最终是以用户为中心，如何便捷分配的管理用户的权限，需要在用户之上划分虚拟组。我们采用的Kylin用户划分群组的概念，一个群组代表一类操作群体，群组可以绑定多个Kylin用户，每个群组关联数据库用户连接账号，授权我们直接对每个DB用户进行授权，从而可以做到通过kylin登录用户能够操作的数据库，以及数据库的Database、Table等。

我们先看看用户、群组、DB用户的关系，如下图所示：

图四 用户、群组、DB用户的关系图

以上图可见，用户、群组、DB用户关系如下几点。

1、kylin用户只允许绑定一个群组

2、一个群组不允许绑定一个DB集群的多个DB用户

3、DB用户只允许绑定一个群组

群组会关联认证用户和DB用户，最终我们只需要对这些用户授理库、表权限，kylin用户就可以根据群组找到想要操作的数据库（Hive、Presto、GaussDB）对应的DB用户，从而控制kylin用户对数据的访问控制。

4.3 授权管理

4.3.1 权限范围

当前大数据底层组件有Hive、Hetu、GaussDB，不同组件有自己特有的权限支持粒度，当前已使用的组件权限支持粒度支持如下图所示：

图五 大数据不同组件对权限支持粒度

有些组件不支持以上属性是因为该组件本身的业务场景定位导致，比如：

1、Hive是一个批量写入和读取的数据库，不支持delete from table where id=1类似删除的操作。

2、GaussDB必须是表的owner用户才能拥有Drop权限，其他用户无法Drop表。

根据以上介绍我们可以了解到用户、群组、DB用户关系、以及DB用户与数据库权限支持粒度，后续我们就会对DB用户授理权限，由于不同的DB都有自己的一套权限粒度，但是我们需要做到站在用户的角度对任何数据库类型（库、表）授权都是统一理解。

4.3.2 库、表权限分离

库表权限分离意味着当用户拥有库(dim)查询权限、表dim.table1查询权限两个当中的任意一个权限，用户都可以执行dim.table1的查询，如下图如所示：

图六 库表权限分离模式权限图

以上模式的需要注意的是用户对库、表权限都单独授权的情况下，如果想要取消某个用户组的某个表的权限，需要同时取消库和表的权限。

4.3.3 Hive、Hetu授权

了解到权限管理机制，那么是怎么通过Ranger对Hive、Hetu授权的呢，在Ranger中，管理库、表策略的是不能重复的，比如Dim库的权限策略形式示例：Catalog（*）,Database(dim)、Table（*）、Column（*），而此策略对应的用户和此策略对应users数组，我们将PolicyName规范成库权限：ALL#dim#all#all，表权限：ALL#dim#表名#all，有了策略名，策略对应的权限及用户，我们是通过一个access对应多个用户的规范，比如当accesses=select对应的users=[u1,u2,u3],这样做相当于我们为Ranger的策略格式制定的一套规范，权限格式如下：

本身Ranger权限管理UI没有一个严格的规范，只有定义这样的规范，我们才能对每个用户拥有什么权限可定位，以及对用户权限编辑、删除等操作才能按照此规范来找到Ranger对应的策略。

安全管控平台对Ranger定义一套规范，那么是怎么授权呢，Ranger对Hive、Hetu完整授权逻辑如下图所示：

图七 基于Ranger的异步授权流程

4.3.4 GaussDB授权

GaussDB权限管理与Hive、Hetu不一样，Ranger无法控制到GaussDB权限，我们只能通过GaussDB自身的权限来管理实现对DB用户的库、表权限管理。

前面说到我们对权限采取的是库表、权限分离的模式，但是GaussDB权限管理要实现这种模式存在如下问题：

1、库CRUD权限只能授理当前库已存在的表，未来在库下新建的表是无法自动生效，要做到未来新建表也拥有CRUD权限，需要处理拥有库的create权限的用户赋予拥有库CRUD权限的用户。

2、库有select权限，表也有select权限，revoke用户任意一方的select权限，应该还能对该表拥有select权限，但GaussDB是不行的，假设一个用户对dim库有select权限，对dim库当中table1表也有select权限，当取消表(dim.table1)的select权限，这时候在GaussDB执行select*from dim.table1会提示没有权限,这个是因为GaussDB在给库授权的时候其实是细化到给当前库当中已有的表进行了授权，所以删除了这个表的权限，也就无法访问这个表的权限了。

只有解决以上两个问题，我们才可以在GaussDB的权限当中做到库、表权限分离，为了做到这一点，需要每次给表授权都需要执行库回写命令，给库授权都需要执行表回写命令，如果在并发的场景，会导致权限管理混乱，为了解决此问题，我们与Hive授权保持一直，采用了异步排队的方式，将并发的权限请求根据先后顺序依次处理，以下是GaussDB授权的完整流程：

图八 GaussDB异步授权流程图

4.3.5 授权接入开放式API

权限开放接口API是为了进一步满足用户个性化权限需求，为了保障接口的安全，平台接入了安全用户平台、OA、及工作流平台，系统会根据当前登录人员授权请求，验证用户的合法性，同时会根据用户所属部门、申请的库表所属密级等级、申请期限（临时权限、长期权限）来匹配对应的审核人，只有通过审批后才能拥有申请对数据操作的权限，安全平台会根据权限的期限，在有效时间通知用户权限到期提醒，如果权限到期会回收用户的权限。

4.4 鉴权

鉴权顾名思义就是对库、表操作权限验证，确定该用户是否对于要访问的库表有访问的权限，为了方便上层应用的鉴权集成，我们对上层应用提供了鉴权SDK。

4.4.1 鉴权SDK

由于底层的数据组件不一样导致需要支持的SQL语法不一样，如果要提供一套通用的SQL解析进行库表权限的拦截，代价会比较大，所以我们对于每一种数据组件都采用预先分配资源队列和用户链接池的方式来对数据组件的访问，我们的SDK只是完成了用户ID到预分配资源队列和用户连接池的映射，鉴权的真正逻辑交给了底层的组件本身的鉴权模块，

应用层需要将catch对应的Exception，通过异常信息来反馈用户是否有操作权限，鉴权流程如下图所示：

图九 应用集成SDK之后的鉴权流程

5.总结

安全管控平台基本上已完成对大数据数据安全的统一授权管理，极大的保障企业数据的安全，降低了对数据账号和数据权限的运维成本，同时也有效的解决了各个系统对权限的管控，不同的企业用户在各个平台使用数据都有不同的访问权限，只需要接入安全管控平台即可做到用户权限千人千面，保障了企业数据和敏感信息的泄露风险！