星环大数据安全组件Guardian与hadoop自带的安全组件区别

在进行讲解之前，先带大家学习下hadoop关于hdfs自己的安全如何实现的---------------------------

名词：

ACL-访问控制列表（Access Control List，ACL）

ARBAC-基于角色的权限访问控制（Role-Based Access Control）

所有安全体系的了解，大数据平台安全体系的四个层次说起：外围安全、数据安全、访问安全以及访问行为监控，如下图所示；

外围安全技术多指传统意义上提到的网络安全技术，如防火墙，登陆认证等；
数据安全从狭义上说包括对用户数据的加解密，又可细分为存储加密和传输加密；还包括用户数据的脱敏，脱敏可以看做“轻量级”的数据加密。如某人的生日为“2014-12-12”，脱敏后的数据为“2014-x-x”。数据的轮廓依然存在，但已无法精确定位数值。脱敏的程度越高数据可辨认度越低。上述的例子还可脱敏为“x-x-x”，相当于完全对外屏蔽该信息。
访问安全主要是对用户的授权进行管理。Linux/Unix系统中用户-组的读、写、执行权限管理堪称其中的经典模型。HDFS对这一概念进行了扩充，形成了更加完备的ACL体系；另外随着大数据的应用的普及和深入，文件内部数据访问权限差异化的需求也变得越来越重要；
访问行为监控多指记录用户对系统的访问行为：如查看哪个文件；运行了哪些SQL查询；访问行为监控一方面为了进行实时报警，迅速处置非法或者危险的访问行为；另一方面为了事后调查取证，从长期的数据访问行为中分析定位特定的目的。

在这四个安全的层次中，第三层同上层业务的关系最为直接：应用程序的多租户，分权限访问控制都直接依赖这一层的技术实现。

HDFS的权限管理

普通Hadoop集群中的各个组件通常使用不同模型进行权限管理。

例如HDFS使用类似POSIX ACL的权限模型，用HDFS shell授权；
Hive使用基于角色的RBAC模型，用SQL授权；
而HBase使用的是基于组的RBAC权限模型，使用HBase shell授权。

这就意味着为三个组件授权需要登录三个系统，使用三种不同的模型授权，为权限运维造成不小的难度。基本上就是访问安全，并没有其他安全的防护。。。。

问题背景：

Hadoop在企业中广泛地应用，越来越多的业务场景要求大数据访问控制的粒度也不再局限在文件级别，而是更加细致地约束文件内部的数据哪些只能被读，哪些完全不允许被访问。对于基于SQL的大数据引擎来说，数据访问不止要到表粒度，更要精确到行列级别。

CDH的安全组件

安全组件的来源背景：

Hive是早期将高级查询语言SQL引入Hadoop平台的引擎之一，早期的Hive服务器进程被称作Hiveserver1；Hiveserver1既不支持处理并行的多个连接，又不支持访问授权控制；后来这两个问题在Hiveserver2上被解决，Hiveserver2能够使用grant/revoke语句来限制用户对数据库、表、视图的访问权限，行列权限的控制是通过生成视图来实现的；但Hiveserver2的授权管理体系被认为存在问题，那就是任何通过认证登陆的用户都能够为自己增加对任何资源的访问权限。也就是说Hiveserver2提供的不是一种安全的授权体系，Hiveserver2的授权体系是为防止正常用户误操作而提供保障机制；不是为保护敏感数据的安全性而设计的。然而这些更多的是某些公司的说辞，事实上Hiveserver2自身的安全体系也在逐步完善，上述问题也在快速修复中。

但授权管理其实不止是Hive需要，其他的查询引擎也迫切需要这些技术来完善和规范应用程序对数据的访问。对于细粒度授权管理的实现，很大一部分功能在各引擎之间是可以公用的，因此独立实现的授权管理工具是非常必要的。

在这样的背景下，Cloudera公司的一些开发者利用Hiveserver2中现有使用价值的授权管理工具Sentry，下图是Sentry与Hiveserver2中的授权管理模型的对比：

Sentry的很多基本模型和设计思路都来源于Hiveserver2，但在其基础之上加强了RBAC的概念。在Sentry中，所有相应的权限。权限à角色à用户组à用户，这一条线的映射关系在Sentry中显得尤为清晰，这条线的映射显示了一条权限如何能最后被一个用户所拥Hadoop自身的用户-组映射来实现的。有集中配置，易于修改的好处。

Sentry将Hiveserver2中支持的数据对象从数据库/表/视图扩展到了服务器，URI以及列粒度。虽然列的权限控制可以用视图来实现，但是对于多用户，表数量巨大的情况，视图的方法会使得给视图命名变得异常复杂；而且用户原先写的针对原表的查询语句，这时就无法直接使用，因为视图的名字可能与原表完全不同。

目前Sentry1.4能够支持的授权级别还局限于SELECT，INSERT，ALL这三个级别，但后续版本中已经能够支持到与Hiveserver2现有三个重要的组件：一是Binding；二是Policy Engine；三是Policy Provider。

Binding实现了对不同的查询引擎授权，Sentry将自己的Hook函数插入到各SQL引擎的编译、执行的不同阶段。这些Hook函数起两大作用：一是起过滤器的作用，只放行具有引擎的授权信息也存储在由Sentry设定的统一的数据库中。这样所有引擎的权限就实现了集中管理。

Policy Engine判定输入的权限要求与已保存的权限描述是否匹配，Policy Provider负责从文件或者数据库中读取出原先设定的访问权限。Policy Engine以及Policy Provider其实对于任何授权体系来说都是必须的，因此是公共模块，后续还可服务于别的查询引擎。

Transwarp Guardian保障HDFS安全

Guardian 5.0在原有安全解决方案的基础上提供了更加完整的功能以及方便的操作，包括用户认证、授权、配额管理以及资源控制。用户认证通过LDAP以及KERBEROS协议，确保只有经过身份甄别的用户才能访问系统，授权保证只有被赋予权限的用户才可以访问系统资源，配额管理与资源负责控制用户使用的资源大小，三个部分一同保证TDH平台大数据安全。

Guardian 5.0的框架共分为四层：
底层：ApacheDS
Guardian底层使用改进的ApacheDS方案，使用同一套用户统一LDAP/Kerberos认证方式，避免OpenLDAP使用Kerberos认证，从而加速LDAP认证效率。另外，Guardian优化了ApacheDS原生的数据存储，使读写效率提升10倍以上。同时还提供了Master-Slave的HA方案，保证用户数据安全和可靠性。
第二层：Guardian Server
架构第二层是独立的服务Guardian Server，实现完整的ARBAC模型支持，提供了用户友好的Web UI和密码策略等功能支持。Guardian Server对用户认证授权进行了统一化，从Web服务到Hadoop底层使用同一套用户，同一套授权机制；同时开放了LDAP接口、REST API和LoginService，供第三方应用通过Guardian用户进行认证和授权的整合。
第三层：Plugins
第三层使用插件的形式，为TDH各个组件提供认证、授权、组映射以及配额管理，使得TDH组件可以使用统一的用户、组和权限管理模型。
顶层：服务应用
架构顶层是与Guardian对接的各种TDH服务，受到Guardian的安全保护。
在Guardian的保护下，所有的应用服务都可以借助Kerberos实现数据加密，或者通过LDAP实现身份验证。各云产品和组件得到租户级别的资源管理，其多租户资源管理模块可以按照租户的方式管理资源，并通过一个图形化工具为用户提供权限配置以及资源配置接口。同时实现HDFS和所有数据库对象的细粒度访问控制。

功能优势

增强的ARBAC模型
Guardian引入了增强后的ARBAC（Administrative Role Based Access Control）模型，统一了各个组件的权限管理，使用户使用统一的Web UI或者REST API进行授权，同时也兼容了SQL、HBase shell授权方式，大幅度简化了运维。
精细的多粒度权限管理
Guardian为各个组件提供了完整统一的RBAC的权限管理，包括HDFS、YARN、Inceptor、Hyperbase、Workflow以及Midas服务；支持服务管理员的动态设置，实现服务管理员职责的精细划分，有很高的灵活度和可操作性；对于特定的服务，提供了一些粒度的权限管理，同时提供比表级更细粒度的权限管理，如行级权限管理，满足用户各个层面的权限管理需求。
智能的资源控制
Guardian配合Inceptor Scheduler提供了对于Inceptor细粒度的资源控制，可以针对用户的不同权限和优先级，设置合理的资源分配方式。资源管理配置界面支持设置用户允许提交的队列，每个队列可以使用的CPU数量，队列的权重，以及用户可提交的SQL数量上限。同时对HDFS配额、Yarn队列、Inceptor数据库及表的配额以及Discover用户配额提供配置接口。
运维简化
Guardian实现了标准的LDAP和KERBEROS认证协议，并将所有组件的权限信息都统一集中存储在ApacheDS，使得即使服务处于异常状态甚至关闭，用户仍然可以正常的对服务设置访问权限和配额，成功实现了资源管理与具体的服务之间的解耦。Guardian 5.0还提供了友好的日志系统和报错信息，便于降低运维难度。