大数据权限与安全

1、权限概述

1.1、大数据平台权限管控现状

权限的管控，历来是大数据平台中最让人头疼的问题之一。管得严了，业务不流畅，用户不开心，放得宽了，安全没有底。而且大数据平台组件，服务众多；架构，流程复杂；有时候，就是想管，也未必能管得起来。

权限管控，做多少，怎么做，花多少代价，取决于目标出发点。权限管控目标：是对用户常规的业务行为范围进行限定，敏感数据的控制，对业务逻辑和流程的约束；通过减少用户不必要的权限，减少受害面，降低可能的业务风险，同时也便于明确用户的权责归属关系。

1.2、权限管控技术方案

涉及到的技术方案层面，Kerberos，LDAP，Ranger，Sentry，ACL，包括各个组件的权限管控方案以及权限管控的目标。

1.3、权限管控步骤

权限管控的两个步骤：认证和授权，前者鉴定身份，后者根据身份赋予权限。

在授权环节，如何进行对权限集中统一的管理；如何让用户自主的申请权限；如何把权限的管理工作交给具体的业务负责人而不是平台管理员；如何在不同的组件之间，不同的用户之间打通权限关系。

在用户身份鉴定环节，需要对当前权限建设重点目标流程进行剖析以及选择合适的权限技术方案。

2、权限方案

2.1、权限管理技术方案概述

权限管理相关工作可以分为两个部分内容：

• 管理用户身份，也就是用户身份认证(Authentication)
• 用户身份和权限的映射关系管理，也就是授权(Authorization)

用户身份认证环节，Hadoop生态系统中常见的开源解决方案是Kerberos+LDAP；授权环节，常见解决方案有Ranger，Sentry等，还有Knox这种走Gateway代理服务的方案。

2.2、Kerberos

Kerberos是Hadoop生态系统中应用最广泛的集中式统一用户认证管理框架。

2.2.1、工作流程

提供一种集中式的身份验证服务器，各种后台服务并不直接认证用户的身份，而是通过Kerberos这个第三方服务来认证。用户的身份和密钥信息在Kerberos服务框架中统一管理。这样各种后台服务就不需要自己管理这些信息并进行认证，用户也不需要在多个系统上登记自己的身份和密码信息。

2.2.2、原理

1. Kerberos 基于 Ticket 实现身份认证，而非密码。如果客户端无法利用本地密钥，解密出 KDC 返回的加密Ticket，认证将无法通过。
2. 客户端将依次与 Authentication Service，Ticket Granting Service 以及目标Service进行交互，共三次交互。
3. 客户端与其他组件交互是，都将获取到两条信息，其中一条可以通过本地密钥解密出，另外一条将无法解密出。
4. 客户端想要访问的目标服务，将不会直接与KDC交互，而是通过能否正确解密出客户端的请求来进行认证。
5. KDC Database 包含有所有 principal 对应的密码。
6. Kerberos 中信息加密方式一般是对称加密（可配置成非对称加密）。
   

2.2.3、核心思想

Kerberos最核心的思想是基于密钥的共识，有且只有中心服务器知道所有的用户和服务的密钥信息，如果信任中心服务器，就可以信任中心服务器给出的认证结果。

2.2.4、应用难点

Kerberos从原理上来说很健全，但是实现和实施起来很繁琐。

• 所有的后台服务必须针对性的接入Kerberos的框架，其次所有的客户端也必须进行适配。需要有后台服务提供对应的客户端接入封装SDK，否则，客户端需要改造以适配Kerberos的认证流程。
• 用户身份的认证要真正落地，就需要实现业务全链路的完整认证和传递。客户端直连单个服务，问题并不大，在大数据平台服务分层代理，集群多节点部署的场景下，需要做用户身份认证的链路串联就没那么简单。
• 用户通过开发平台提交一个Hive脚本任务，该任务首先被开发平台提交给调度系统，再由调度系统提交给Hive Server，Hive Server再提交到Hadoop集群上执行。每个上游组件都需要向下游组件进行用户身份认证工作。
• 在Hadoop集群上运行的一个MR任务，这个认证关系链还需要继续传递下去。每个环节如果要支持基于Kerberos的身份验证，要么要正确处理秘钥的传递，要么要实现用户的代理机制。
• 身份验证的超时问题，秘钥信息的保管和保密问题等等，比如MR任务跑到一半秘钥或Token过期了该怎么办，总不能中断任务。
• 性能问题，集中式管理在某种程度上意味着单点，如果每次RPC请求都要完整的走完Kerberos用户认证的流程，响应延迟，并发和吞吐能力都会是个比较大的问题。

2.2.5、使用场景

总体来说，Kerberos是当前最有效最完善的统一身份认证框架，但是如果真的要全面实施，代价也很高。用户身份认证只是权限管理环节中很小的一部分，虽然技术难度大，但是从实际影响来看，合理的权限模型和规范的管理流程，通常才是数据安全的关键所在。

• 在企业网络中进行用户身份验证和单点登录。
• 在分布式系统中实现跨域用户身份验证和授权。
• 在云环境中确保用户和服务之间的安全通信。

2.3、Ranger

2.3.1、概述

Apache Ranger提供一个集中式安全管理框架, 并解决授权和审计。它可以对Hadoop生态的组件如HDFS、Yarn、Hive、Hbase等进行细粒度的数据访问控制。通过操作Ranger控制台,管理员可以轻松的通过配置策略来控制用户访问权限。

2.3.2、Ranger架构

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

• Ranger Admin：Ranger Admin是Ranger的核心模块，它内置了一个Web管理页面，用户可以通过这个Web管理界面或者REST接口来制定安全策略。
• Agent Plugin：Agent Plugin是嵌入到Hadoop生态组件中的插件，它定期从Ranger Admin拉取策略并执行，同时记录操作记录以供审计。
• User Sync：User Sync将操作系统用户/属组（Users/Groups）的权限数据同步到Ranger的数据库中。
  

2.3.3、Ranger工作流程

2.3.4、使用场景

1、HDP

Hortonworks Data Platform 随附的Apache Ranger使用策略提供针对 Hadoop 组件（例如，Hive、HBASE 和 HDFS）的细颗粒度访问控制和审计。

2、Apache Ranger

Apache Ranger官网是源码包版本，不提供二进制安装包，故需要Maven编译，并自行部署安装。

2.4、Sentry

2.4.1、概述

Apache Sentry是Cloudera公司发布的一个Hadoop开源组件，它提供了细粒度级、基于角色的授权以及多租户的管理模式。
Sentry提供了对Hadoop集群上经过身份验证的用户和应用程序的数据控制和强制执行精确级别权限的功能。Sentry目前可以与Apache Hive，Hive Metastore / HCatalog，Apache Solr，Impala和HDFS（仅限于Hive表数据）一起使用。

2.4.2、Sentry中的角色

• object: 受保护的对象
• privilege: 对 object 的访问权限
• role: privilege 的集合
• user: 用户
• group: user 的集合
  

2.4.3、使用场景

1、CDH

2.5、Knox

2.5.1、概述

Apache Knox Gateway是用于与Apache Hadoop部署的RESTAPI和UI交互的应用程序网关。Knox Gateway为与Apache Hadoop集群的所有REST和HTTP交互提供一个单一的访问点。

2.5.2、提供的服务

Knox提供三组面向用户的服务：

• 代理服务：Apache Knox项目的主要目标是通过代理HTTP资源提供对Apache Hadoop的访问。
• 认证服务：对USTAPI访问以及UIS的WebSSO流进行身份验证。LDAP/AD，基于头的PROAUTH，Kerberos，SAML，OAUTH都是可用的选项。
• 客户服务：可以通过DSL编写脚本或直接将Knox Shell类作为SDK来完成客户端开发。
  

2.5.3、使用场景

• 所有用户对集群的Rest／HTTP请求都通过Knox代理转发，既然是代理，就可以在转发的过程中做一些身份认证，权限验证管理的工作，因为只针对Rest／HTTP服务，所以它并不是一个完整的权限管理框架。
• 使用Gateway的模式有很大的局限性，比如单点，性能，流程等等，不过对于Rest／HTTP的场景倒也算是匹配。它的优势是通过收拢Hadoop相关服务的入口，可以隐藏Hadoop集群的拓扑逻辑，另外，对于自身不支持权限认证管理的服务，通过Gateway也能自行叠加一层权限管控。

3、权限模型

3.1、概述

• 权限管控可以理解为权力限制，即不同的人由于拥有不同权力，所看到的、能使用的可能不一样。对应到一个应用系统，就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。
• 从本质来说，无论何种类型的权限管理模型都可以抽象出三个基本的要素——即：用户(user)、系统／应用(system/application)、策略(policy)。
• 开源项目中常见的权限模型概念：RBAC／ACL／POSIX／SQL Standard。

3.2、RBAC模型

3.2.1、概述

「用户-角色-权限」的权限逻辑就是目前行业内普遍使用的 RBAC (Role-Based Access Control：基于角色的权限控制)权限模型。其核心是引入角色的概念，用角色作为中间介质，使用户与权限配置更加灵活。

3.2.2、RBAC模型的应用

• RBAC是基于角色的访问控制，通过将用户的角色与权限进行关联来实现对系统资源的访问控制。
• RBAC具有灵活性、可扩展性和安全性等优点，但实现难度较大，需要管理员具有较高的技术水平。
• 在实现RBAC时，需要根据角色、权限、资源、访问控制策略等进行定义，并遵循规范进行应用。
  

3.3、POSIX模型

3.3.1、概述

POSIX权限模型是基于文件的权限模型，与Linux系统的文件系统权限类似。即一个文件有相应的OWNER和GROUP，只能支持设置OWNER,、GROUP和其他用户的权限，可授权限也只有读写执行权限。

3.3.2、POSIX模型的应用

这种模型不适用于企业用户，有一个明显的缺点就是它只有一个GROUP，不能实现不同的GROUP有不同的权限，也无法实现精细化的权限管理，只能在文件级授权，所授权限也只有读写与执行权限。

3.4、ACL模型

3.4.1、概述

ACL(Access Control List)访问控制列表，一种访问控制机制，主要包含三个关键要素用户（User）、资源（Resource）和操作（Operate）。当用户请求操作资源时会检查资源的权限列表，如果资源的权限列表中存在该用户的操作权限则允许否则拒绝。

3.4.2、ACL模型的应用

ACL即Access Control List，ACL权限模型可以弥补POSIX权限模型的不足，可以实现比较精细化的权限管理。通过设置访问控制列表，可以授予某一个用户多个权限，也可以授予不同用户不同的权限。但ACL也有明显的缺点，当用户数较大时，ACL列表会变得庞大而难以维护，这在大企业中问题尤其明显。

3.5、SQL标准的权限模型

3.5.1、概述

SQL Standard模型是Hive/Spark使用权限模型之一，本质是使用SQL方式的授权语法来管理权限。Hive中的权限模型也是基于ACL和RBAC模型，即可以给单独的用户直接授权，也可能通过角色进行授权。

3.5.2、SQL Standard模型的应用

SQL标准的权限模型，从模型的角度来说和ACL模型并没有什么本质的区别，只不过是在类SQL语法的系统中，模仿了MySQL等传统数据库中标准的授权语法来与用户进行交互。

4、数据安全

4.1、数据安全面临的风险和压力

4.1.1、企业内部监管

目前企业缺少数据安全方面的技术手段和有效的管理制度，增加数据泄漏风险。
另一个就是由于内部员工安全意识不足造成数据信息泄漏。

4.1.2、外部法律和合规要求

随着国内外政府和行业对信息安全的重视，提出相关法律规定和管理制度，不断要求增强数据安全性且安全要求趋细化。例如我国在2017年6月正式生效的《中华人民共和国网络安全法》、欧盟2018年5月生效的《GeneralData Protection Regulation》(简称GDPR)、中国2018年5月生效的GB/T 35273《信息安全技术个人信息安全规范》等等

4.1.3、数据泄漏风险

随着IT技术不断迭代，造成数据泄漏懂的风险途径不断增加，增加数据泄漏风险。
恶意攻击风险不断增加也是一个方面。

4.1.4、数据安全现状和问题

分析各行业和自身企业在数据安全方面面临的一些安全问题。

1、数据资产管理问题

数据资产管理问题，主要体现在如下三个方面：

• 资产状况不清
• 访问状况不清
• 权限状况不清

数据资产梳理是一个持续的过程，数据和业务是不断发生变化的，因此需要借助自动化工具来开展数据资产管理工作。准确掌握数据资产安全状况，是开展数据安全体系建设的基础条件。如：存储位置，管理人，部门，分级，分类等。

2、数据管理责任问题

数据管理责任问题，主要体现在如下两个方面：

• 数据资产未认责
• 管理角色的职责边界模糊

数据安全管理角色一般情况会由研发、运维、安全、运营人员来兼任，没有独立的团队或虚拟团队，导致权责不清，不利于整体提升数据安全防护能力。建立数据安全管理角色至关重要：数据资产管理员、数据库管理员、安全审计员、安全检测工程师、数据运维工程师、权限管理员等。

3、数据制度不完善问题

数据制度不完善问题，主要体现在如下两个方面：

• 制度规范未落实或难落实
• 缺少稽核手段

数据管理制度通过数据安全咨询规划建立一套切实可行的制度规范，同时制定出数据安全管控措施与SLA评价指标，避免由于缺少稽核手段，导致数据安全管理部门无法及时掌握执行情况。

4、数据交换管理混乱问题

数据交换管理混乱问题，主要体现在如下两个方面：

• 交换共享的方式和接口不标准
• 运维人员和应用系统负责人的数据管控压力大

数据会向外部、内部和合作伙伴进行交换共享，随着开放的接口越来越多，交换关系越来越复杂，将交换共享的方式和接口标准化，将会避免出现功能重复、调用复杂、多点登录等现象，且不会影响数据应用的发展。

5、安全技术措施零散问题

安全技术措施零散问题，主要体现在如下两个方面：

• 数据安全产品功能分散
• 安全能力孤岛

数据安全能力的建设也会以组织为单位开展，避免各组织分散建设，从数据生命周期的统一建立防御体系。

6、数据审计能力不足问题

数据审计能力不足问题，主要体现在如下两个方面：

• 安全规则有效的差异
• 非法的事情、合规的操作无审计

可通过审计对攻击的操作轨迹和规律从而发现安全隐患，建立相关动态信任机制。

4.2、数据安全方面的风险点

4.2.1、数据安全的风险点

4.3、数据安全生命周期治理

4.3.1、数据安全生命周期治理

4.4、数据安全生命周期能力模型

4.4.1、数据安全生命周期能力模型

4.5、数据安全治理

4.5.1、多维度数据安全治理

• 组织管理建设

  结合自身企业的组织架构从上而下，定义管理层、业务部门、实施部门、合规监控和审计部门、运营部门等的相关职责。

• 标准制度和规范建设

  建设或完善数据防泄漏的总体策略、管理办法、应急方法以及具体操作流程。从制度体系上支撑数据防泄漏工作。

• 技术工具建设

  采用专业、成熟的技术，落地管理层认可的细化策略，通过平台实现数据外泄行为，并记录、告警以及阻断。从技术上实现防泄漏目标。

• 整体实现核心技术

  数据资产管理，分类分级，数据权限管理和审计，KMS+CA，零信任，数据安全网关，数据画像，DLP，区块链隐私，水印，TEE，联邦学习，同态加密。

4.5.2、数据安全平台

结合自身企业的组织架构从上而下，定义管理层、业务部门、实施部门、合规监控和审计部门、运营部门等的相关职责。

• 标准制度和规范建设

  建设或完善数据防泄漏的总体策略、管理办法、应急方法以及具体操作流程。从制度体系上支撑数据防泄漏工作。

• 技术工具建设

  采用专业、成熟的技术，落地管理层认可的细化策略，通过平台实现数据外泄行为，并记录、告警以及阻断。从技术上实现防泄漏目标。

• 整体实现核心技术

  数据资产管理，分类分级，数据权限管理和审计，KMS+CA，零信任，数据安全网关，数据画像，DLP，区块链隐私，水印，TEE，联邦学习，同态加密。

4.5.2、数据安全平台