首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

滴滴大数据安全权限实践

用户认证 - 自研账号密码机制

提到安全,首先要面对的就是用户认证,Hadoop 社区版本是没有安全认证的,因此只要随意 export HADOOP_USER_NAME=Anyone,就可以伪装为任意用户操作集群上的数据了,存在非常大的安全隐患。为了解决用户安全认证的问题,Hadoop 社区方案主要是基于 Kerberos,Kerberos 提供了比较完善安全认证的能力,但是运维成本比较高,而且 KDC 容易成为性能瓶颈,综合考虑下,我们基于 Hadoop 自研了一套易于运维管理的账号密码认证机制,流程交互大致如下图:

下面将具体讲下各个模块是如何实现的。

▍1. 客户端

1.1 普通客户端

  • Hadoop 客户端,Spark 客户端,Hive 客户端,启动时都需要请求 Namenode,因此我们统一在 Namenode 做了密码校验
  • 如何传密码:我们在 hadoop 的 IpcConnectionContext.proto 里增加了 password 字段,而其他客户端(spark,hive)只需要基于 hadoop 客户端进行编译既可使用。
  • 如何设置密码:通过 export HADOOP_USER_PASSWORD=123456 或者 System.setProperty("HADOOP_USER_PASSWORD", "123456");

1.2 Beeline/JDBC:

  • 这种方式是通过 Hive Serer2 访问大数据的,我们在 Hive Server2 做了密码验证
  • 如何设置密码:beeline -u jdbc:hive2://xxxxxx  -n test   -p 123456

▍2. 服务端

2.1 Namenode 验证:

密码验证  我们在 Server.java 增加了密码校验功能,代码如下:

密码更新 密码配置是以本地文件存在 Namenode 本地,然后定时进行刷新到 namenode 内存中

2.2 Hive Server 验证:

使用了 hive 提供的用户自定义安全验证,其中密码校验模块是我们自己实现的类似上述 Namenode 机制,具体如下配置:

▍3. 用户管理模块

这里主要是基于滴滴的数梦用户管理平台,主要是用来管理多租户的,维护着用户的数据资产信息,包括密码信息管理;涉及到密码管理,主要提供了 3 个功能,密码生成,密码维护,密码同步到服务端(Namenode 和 Hive server)。

通过上面的各模块落地,当前我们是建设了一套相对比较完善的账号认证机制,通过账号和密码实现了用户身份的安全认证,但是仅有用户认证是不够的,同时最复杂的其实是权限鉴权体系,下面我将介绍下我们的权限鉴权是怎么做的。

权限认证 - 列级别鉴权体系

说起滴滴的大数据权限机制,我们其实是经历了从 0 到 1,又从 1 到 2 的过程,最早我们是基于 Hive SQL Standard-based+ HDFS UGO 机制构建了一套基于 hive 表粒度的权限体系,但是随着业务的发展和数据安全的诉求,我们在 2018 年对权限体系进行了重构 ,基于 Ranger 建设了基于列级别鉴权的数据权限体系,下面将具体说下,我会先讲下滴滴的数据权限的模型,以及我们是怎么实现的。

▍1. 权限模型

我们是设计了一套基于字段策略的 RBCA 的权限体系,下面具体展开说下。

1.1 数据分级

首先需要说下滴滴的数据分级,为了保障数据安全,在滴滴数据是做了非常严格的安全级别划分,依据数据的价值和敏感程度,从低到高划分为 4 个安全级别:公开数据(C1)、内部数据(C2)、秘密数据(C3)、机密数据(C4),基于安全等级不同,也指定了不同数据的访问权限审批模型,比如 C3 及以下降低一些审核门槛;C4 则需要更加严格审批流程才能使用。

1.2 RBAC 模型

我们是基于 RBCA 权限模型设计的权限体系,因此我们主要涉及到用户,角色,权限三个实体

  • 用户对应到 Ranger 的 User
  • 角色对应到 Ranger 的 Group
  • 权限对应到 Ranger 的 Policy

1.3 基于字段的策略

为什么要做基于字段的权限控制呢,主要是因为数据分级是按照具体数据内容来定义的,即是按照具体字段的数据来定义数据的安全等级,而不是按照表级别,很多情况下一张 Hive 表往往包括了好多字段数据,安全等级也是不一样,如果不支持字段级别鉴权,往往会有大量的表成为 C4 表,这样一来一方面对安全的挑战是比较大的,另一方面也提高了用户使用数据的门槛,因为用户往往的需求是访问这个表的非 C4 字段就够了。因此支持字段级别鉴权是势在必行,为了把权限细化到字段,我们在 ranger 里面配置的权限策略也细化到了字段级别,比如策略会配置为  db.db.table.$column.c4。

为了提升易用性,降低大家使用数据的门槛,我们通过不同的安全等级分成了不同的角色包,比如对于 C1,C2 的字段可高效低门槛访问,这样对用户来说易用性大大的增强,对于我们来说也做到了字段级别的权限控制,保障了 C3,C4 数据的安全性,大致如下:

▍2.权限的实现

谈到实现,先给给大家展示下我们目前权限体系大致系统交互流程,如下图:

是不是有点小复杂,下面具体介绍各自模块的作用以及权限体系是怎么工作起来的!

2.1 数据分级模块

主要是由滴滴安全部门负责进行对数据进行打标签,通过实时订阅 Kakfa 中的 DDL 事件获取到数据的元数据信息和数据内容,通过安全算法,定义出数据的具体安全等级,将具体到表的字段级别,再把分级好的数据发送到 DDMQ(滴滴自研的消息队列)。

2.2 数据地图

元数据管理服务

面向用户提供统一的元数据查询管理服务,同时将实时订阅 DDMQ 中的数据分级信息,及时更新数据的分级信息。

人工标记服务

用于人工进行表数据的分级设定或者修正,经过审核,系统也将也将实时更新发布到 DDMQ 中。

表数据抽样

用于提供表的样例数据查询,目前是基于 presto 随机查询 10 条样例数据。

2.3 数据权限平台

权限申请管理系统

为用户提供可视化的管理和申请权限的平台,如下图:

权限申请流程

权限申请主要分为 Hive 表权限的申请和 HDFS 权限的申请,大概如下图:

SQL 鉴权服务

用于为数据查询平台类似数易报表,提取工具等服务提供基于 Restfull API 的 SQL 鉴权功能。值得说明的是,SQL 鉴权服务是独立于 ranger 体系的,数梦平台申请和维护权限的同时也将权限信息维护在数梦平台的 mysql 中,独立的提供了一套面向数据产品权限的鉴权服务。

权限策略管理模块

基于数据分级信息,生成对应的 ranger 权限策略,并通过 Ranger admin 的 api 更新策略数据,关于 api  可以参考: 

https://cwiki.apache.org/confluence/display/RANGER/REST+APIs+for+Service+Definition%2C+Service+and+Policy+Management

2.4 引擎层

引擎层的鉴权流程大致如下图:

接下来详细介绍一下:

1.Ranger Admin (社区版本

  1. 作用:用于维护着所有的权限策略,可以通过 Ranger Admin 进行权限的增删改查,我们当前用的社区的 0.6 版本,更多信息可以参考 https://cwiki.apache.org/confluence/display/RANGER/0.6+Release+-+Apache+Ranger
  2. 高可用:目前我们是基于 LVS 做的负载均衡,后面部署着多台 Ranger Admin 服务

2.Ranger Metastore(自研)

  1. 作用:用于提供权限的查询的 Thrift Server。需要说明的是 Ranger 原生鉴权架构是客户端插件定时从 Ranger Admin 拉取所有的策略到本地,然后在本地进行的权限校验,这个机制会导致 3 个问题:1,在策略很多的时候,会造成拉取变慢,影响 SQL 执行引擎的整体性能;2.客户端比较多的情况下,客户端插件同时拉取的时候,对 Ranger Admin 的压力也会很大,机器带宽也会成为瓶颈;3,无法进行实时鉴权,比如用户申请权限后还需要等几分钟才可以生效,体验非常不好。因此为了解决上述痛点,我们基于 hive metastore 自研了中心化的实时鉴权方式。 
  2. 架构:
  1. 拓展 Hive Metastore 的 thrift 接口,定义鉴权请求的各个参数
  2. 将 Ranger 插件的功能移植到 Metastore 上
  3. 实现 thrift 客户端,增加 check_privilege 的 RPC 接口
  4. 取消周期性的全量策略拉取,将创建 Evaluator 的逻辑从 Refresher 移到了 RangerHiveAuthorizer 调用 checkPrivileges 地方,从而直接从 Ranger Admin 获取策略,这样实现了实时的鉴权

Ranger Plugin(自研)

引擎客户端鉴权插件,用于查询 Ranger metastore 的权限策略信息,并判断用户是否拥有权限。我们也是基于 Ranger metastore 自研了一套,具体实现方式如下:

1.引擎依赖配置包含 ranger 鉴权接口的 hive 版本依赖

2.然后配置文件中增加如下的配置:

3.引擎侧构造 RangerMetastoreClient,请求 checkPrivilege 方法即可。如果能够正常的返回 true,说明鉴权通过,否则会收到异常信息。

大账号机制(自研)

前面说的基于 ranger 的鉴权,主要是针对 hive 元数据层面,然后涉及到 HDFS 权限,我们提供了一种基于大账户的机制,即当元数据权限鉴权通过后,将不进行 HDFS 鉴权,这样可以屏蔽掉 HDFS 权限,从而实现 hive 权限和 hdfs 权限的解耦,同时也可以比较好的支持视图权限:

1.用户涉及到 hive 表操作,只要 ranger 权限校验通过,HDFS 将直接不鉴权

2.涉及到直接 HDFS 路径操作(非 SQL 查询),将基于 HDFS UGO 权限机制进行鉴权。通过上面介绍这些模块和组件,我们实现了比较成熟的基于字段级别的权限体系,目前已经落地并且运行俩年的时间,已经支持了超过数百万的安全权限策略,极大的提升了滴滴数据数据权限的安全性。

总结

本文总结了我们在滴滴大数据安全权限方面的工作,从用户认证讲到了权限鉴权模块的实现,其实在安全权限实际推动落地的过程中远远要比文章写的要复杂,有兴趣的同学欢迎一起讨论,也欢迎大家加入我们,解决世界级的技术难题。

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/YfXkHJDask0eMe2GaQNZ
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券