滴滴大数据安全权限实践_文化 & 方法_滴滴技术

【AICon】如何构建高效的 RAG 系统？RAG 技术在实际应用中遇到的挑战及应对策略？>>> 了解详情 



 写点什么

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

提到安全，首先要面对的就是用户认证，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 (社区版本）

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

2.Ranger Metastore（自研）

作用：用于提供权限的查询的 Thrift Server。需要说明的是 Ranger 原生鉴权架构是客户端插件定时从 Ranger Admin 拉取所有的策略到本地，然后在本地进行的权限校验，这个机制会导致 3 个问题：1，在策略很多的时候，会造成拉取变慢，影响 SQL 执行引擎的整体性能；2.客户端比较多的情况下，客户端插件同时拉取的时候，对 Ranger Admin 的压力也会很大，机器带宽也会成为瓶颈；3，无法进行实时鉴权，比如用户申请权限后还需要等几分钟才可以生效，体验非常不好。因此为了解决上述痛点，我们基于 hive metastore 自研了中心化的实时鉴权方式。
架构：

拓展 Hive Metastore 的 thrift 接口，定义鉴权请求的各个参数
将 Ranger 插件的功能移植到 Metastore 上
实现 thrift 客户端，增加 check_privilege 的 RPC 接口
取消周期性的全量策略拉取，将创建 Evaluator 的逻辑从 Refresher 移到了 RangerHiveAuthorizer 调用 checkPrivileges 地方，从而直接从 Ranger Admin 获取策略，这样实现了实时的鉴权

Ranger Plugin（自研）

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

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