企业级大数据安全架构

安全架构

一、集群访问控制
- 1.1 Kerberos认证机制
- 1.2 Apache Knox 统一访问网关
二、资源授权管理
- 2.1 Apache Ranger 数据授权与管理
三、服务安全保障
- 3.1 LDAP 轻量目录访问协议
四、大数据安全架构

当谈到企业级大数据平台时，安全性是一个至关重要的方面。随着数据规模的不断增长和信息的敏感性，大数据平台面临着多种安全隐患，需要得到充分的关注和解决，以确保其在生产环境中可靠可用。

缺乏统一的访问控制机制:
- 大数据平台由Hadoop生态体系众多组件组成，而每个组件都会提供相应的Web UI界面和RESTful接口，例如NameNode UI，Yarn提供ResourceManager UI等等，这些系统服务是没有设置访问控制的，任何人只要知道服务URL地址，就能任意使用管理控制台或者调用RESTful接口，这样会造成安全隐患。
缺乏统一的资源授权管理:
- 平台用户可以不受限制的访问任意的数据和服务，例如HDFS数据、Hive数据、Hbase数据等等，如果恶意删除数据会造成重大安全隐患。正常情况下是每个用户只能访问到自己的数据，不同用户和不同应用之间的数据存储需要隔离，用户通过授权之后才能访问数据。
缺乏Hadoop体系安全保障:
- Hadoop生态体系是由一系列的组件组成的，这些组件之间会进行大量的通讯，默认情况下这些交互信息是没有经过加密的，系统也没有验证这些信息来源的可靠性。

解决Hadoop服务的安全隐患的思路是引入Kerberos认证机制，通过集成Kerberos协议，就能够使用Kerberos用户代替服务器本地的Linux用户，让大数据平台中Hadoop相关服务全部使用Kerberos用户通过认证中心去认证，防止datanode regionserver等组件冒充加入集群解决了服务端到服务端的认证，也解决了客户端到服务端的认证，提升平台的安全性。

一、集群访问控制

1.1 Kerberos认证机制

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的。

Kerberos协议的侧重在于认证通信双方的身份，客户端需要确认即将访问的网络服务就是自己所想要访问的服务而不是一个伪造的服务器，而服务端需要确认这个客户端是一个身份真实，安全可靠的客户端，而不是一个想要进行恶意网络攻击的用户。

Kerberos中会自带一个数据库(企业通常使用ldap作为数据库存储)，这个数据库会由创建Kerberos的运维人员提前在库中添加好整个系统中拥有使用Kerberos认证权限的用户和网络服务。

Kerberos协议的用户和网络服务，在添加进Kerberos系统中时，都会根据用户凭证(用户密码)生成一把密钥存储在Kerberos数据库中，且Kerberos数据库也会同时保存用户的基本信息(例如: 用户名，用户IP地址等)和网络服务的基本信息(IP，Server Name)

Kerberos协议涉及的角色:
- 客户端(Client)：发送请求的一方
- 服务端(Server)：接收请求的一方
- 密钥分发中心(Key distribution KDC)，包含AS和TGS
  - AS(Authentication Server)：认证服务器，专门用来认证客户端的身份并发放客户用于访问TGS的TGT(票据授予票据)
  - TGS(Ticket Granting ticket)：票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据(ticket)
Kerberos协议认证过程:
- 1- 为获得能够用来访问服务的票据，客户端首先需要访问AS获得服务授予票据(TGT)。客户端用户向AS以明文的方式发起请求，该次请求中携带了用户名、主机IP、和当前时间戳；AS访问Kerberos的数据库，根据用户名查找用户是否存在，此时不验证身份的可靠性，仅验证是否存在。
  - 验证成功后，AS返回服务授予票据(TGT)，以及一段使用客户端密钥加密的内容(这段内容是存储用户时提前保存在Kerberos数据库中的)。
  客户端获取TGT后需要解密后才可以去向TGS获取真正的服务器访问凭证
  关于TGT中包含的一段加密内容，用户可以根据自己的密钥进行解密，因为部分信息是在Kerberos数据中存储的用户凭证加密的，从未出现在网络通信中，因此不存在密钥被劫持破解的情况。
- 2-客户端接收到AS返回的TGT后，会对TGT加密部分使用自己的密钥进行解密，获取时间戳，将要访问的TGS的信息，用于与TGS通信时的密钥CT_SK。紧接着根据时间戳判断该时间戳与自己发送请求时的时间的差值是否大于5分钟，如果大于5分钟则认为该AS是伪造的，认证至此失败。如果时间戳合理，客户端便准备向TGS发起请求，请求的目的是获取能够访问目标网络服务的服务授予票据(Ticket)。
  - 客户端使用从AS获取的CT_SK加密TGT，以明文的方式访问TGS(票据授予服务器)。具体加密如下图①TGS_REQ所示。
- 3-TGS(票据授予服务器)接收到客户端请求后，解密明文传输过来的ServerIP查看当前Kerberos的数据库中是否存在可以被用户访问的服务信息，如果不存在则认证结束。认证成功会才会使用自己的密钥对TGT中的内容进行解密，查看经过AS认证后的用户数据，并通过时间戳判断通信是否超时可靠；如果时延正常，TGS使用CK_SK对明文数据中的客户端内容进行解密，对比其中的用户数据和Kerberos中存储的用户数据是否一致(用户密码)，认证成功后，TGS返回票据凭证。
  
  票据凭证内容:
  第一部分: 用于客户端访问网络服务，使用对应服务端密码加密的ST(Server Ticket)，包括客户端的Name、IP、访问服务的IP、ST有效时间、时间戳、以及用于客户端和服务端通信的CS_SK(Session Key)
  第二部分: 使用CT_SK加密的内容，包括CS_SK和时间戳，以及ST的有效时间。这部分中，在第一次客户端与AS通信时，AS已将CT_SK通过客户端加密交给了客户端，因此客户端在接收到响应时可以自己解密。
- 4-客户端收到了来自KDC(TGS)的响应，并使用缓存在本地的CT_SK解密了第二部分内容(第一部分内容中的ST是由Server密码加密的，客户端无法解密)，检查时间戳无误后取出其中的CS_SK准备向服务端发起最后的请求。
  - 客户端使用CK_SK将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将ST(服务授予票据)作为第二部分内容都发送给服务端。
  - 服务端收到来自客户端的请求，会使用自己的密钥，即Server密钥将客户端第二部分内容进行解密，核对时间戳之后将其中的CS_SK取出，使用CS_SK将客户端发来的第一部分内容进行解密，从而获得经过TGS认证过后的客户端信息，此时它将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过KDC认证的具有真实身份的客户端，是可以提供服务的客户端。此时服务端返回一段使用CT_SK加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的CS_ST解密之后也确定了服务端的身份(其实服务端在通信的过程中还会使用数字证书证明自己身份)。

整个Kerberos认证的过程较为复杂，三次通信中都使用了密钥，且密钥的种类一直在变化，并且为了防止网络拦截密钥，这些密钥都是临时生成的Session key，即它们只在一次Session会话中起作用，即使密钥被劫持，等到密钥被破解可能这次会话都早已结束。这为整个Kerberos认证过程保证了较高的安全性。

Kerberos认证过程较为复杂，感兴趣的可以看看原文--> Kerberos认证过程详解

1.2 Apache Knox 统一访问网关

Apache Knox是一个为Apache Hadoop部署的，提供交互的应用网关，其通过REST API和界面UI，为所有与Hadoop集群的REST和HTTP交互提供了统一的访问点。

Knox不仅仅是一个访问网关，它还具备强大的访问控制功能，可以精确管理用户对Hadoop资源的访问权限。另外，Knox与企业常用的身份管理和单点登录（SSO）系统集成，使得企业可以直接使用现有的身份验证系统，将其身份用于访问Hadoop集群，无需复杂的认证步骤，为企业数据安全提供了更高的便利性和保障性。
在这里插入图片描述

代理服务：通过访问Knox暴露的 REST 和 HTTP 服务访问集群，而不暴露集群内部信息，对 Web 应用程序的漏洞进行过滤，或使用 SSL 协议来增强安全性。

Knox作为Hadoop生态集群网关代理，用户通过其提供的URL集群组件进行访问，不会暴露集群内部信息。
认证服务：通过使用REST API访问的身份验证以及ui的WebSSO流。可以使用Kerberos 封装服务或使用单个 SSL 证书，简化访问，还可以集成LDAP/AD服务，基于标头的预验证，Kerberos，SAML、OAuth都是可用的选项。

我们将不同服务的证书集中在 Apache Knox 服务器上，而不是所有客户机上，这样用户只需访问Knox服务器即可，Knox会使用这些证书对相应的服务进行访问，这在撤销和创建新证书时非常有用。

Apache Knox与Kerberos协议集成后的验证过程：
1- 用户首先从 Kerberos KDC（Key Distribution Center）获取 TGT（Ticket Granting Ticket）。提供其 Kerberos 凭证（用户名和密码或密钥表文件）来获取 TGT。
2- 用户使用 TGT 向 KDC 请求服务票据（Service Ticket），该票据用于访问特定的服务（如 HDFS、YARN 等）。
3- 用户通过 Knox 网关发送请求，请求中包含用户服务票据。Knox 网关接收到请求后，解析用户服务票据并验证其有效性。
4- Knox 网关使用自身的 Kerberos 凭证（Knox 的 principal 和 keytab 文件）与 KDC 通信，验证用户服务票据的有效性。如果票据有效，Knox 网关将请求转发到目标 Hadoop 服务。
5- 目标 Hadoop 服务（如 HDFS、YARN）接收请求并验证用户服务票据的有效性。如果票据有效，服务处理请求并返回响应。
客户服务：通过领先的市场解决方案（Microsoft Active Directory、LDAP、Kerberos 等）或使用自定义解决方案（Apache Shiro 等）进行企业集成。客户端的开发可以通过DSL使用脚本或者直接使用Knox Shell类作为SDK来完成。KnoxShell交互式脚本环境将groovy shell的交互式shell与Knox Shell SDK类结合起来，实现与数据的交互。

Knox与企业常用的身份管理和单点登录（SSO）系统集成，使得企业可以直接使用现有的身份验证系统，将其身份用于访问Hadoop集群，无需复杂的认证步骤，为企业数据安全提供了更高的便利性和保障性。

二、资源授权管理

Apache Ranger是一款被设计成全面掌管Hadoop生态系统的数据安全管理框架，为Hadoop生态系统众多组件提供一个统一的数据授权和管理界面，
管理员只需要对接一个Ranger管理系统，就可以对整个Hadoop生态系统进行数据管理，数据授权和审计。

2.1 Apache Ranger 数据授权与管理

数据平台中资源安全，资源包括数据资源（HDFS、HIVE、HBASE等），系统资源包括YARN资源队列等，虽然这些系统都有各自的权限管理功能，但是比较分散比较原始，需要进行统一管理配置。

Apache Ranger是一个用来在Hadoop平台上进行监控，启动服务，以及全方位数据安全访问管理的安全框架。

Ranger愿景是在Apache Hadoop生态系统中提供全面的安全管理。随着企业业务的扩展，企业可能在多用户环境中运行多个工作任务,这就要求Hadoop内的数据安全性需要扩展为同时支持多种不同的需求进行数据访问，同时还需要提供一个可以对安全策略进行集中管理，配置和监控用户访问的框架。

Apache Ranger 通过以下几方面提升了企业的数据安全和治理能力：

集中化的权限管理：Ranger 提供了一个统一的界面，管理员可以在其中管理所有大数据平台组件的访问权限，简化了权限管理流程。
细粒度的权限控制：Ranger 支持基于角色、用户、组的访问控制（RBAC），并能够设置针对具体数据集、表、甚至行级别的权限，确保数据访问的最小化权限原则。
审计和监控：Ranger 提供了详细的审计功能，记录每个用户的访问行为，并生成可视化报告，帮助管理员监控数据使用情况并检测潜在的安全威胁。
增强的合规性：通过 Ranger 的审计和权限管理，企业可以满足诸如 GDPR 和 HIPAA 等数据隐私法律法规的要求，确保数据访问可追踪、可审计。
与 Hadoop 生态系统的深度集成：Ranger 无缝集成了 Hadoop 的核心组件，如 HDFS、Hive、HBase、Kafka 等，提供统一的安全策略管理。

在这里插入图片描述

Ranger提供可插拔的Plugin用于集成Hadoop生态中的各种组件，用户可以通过一个UI界面对管理策略进行设置，甚至可以对数据表的行级记录设置用户组权限。用户组由一或多个用户组成。

Apache Ranger以及集成了大多数Hadoop生态组件，并提供一个WebUI界面对组件的权限进行了监控和审计，管理员可以设置设置用户组

三、服务安全保障

Hadoop服务的安全问题由来已久，其在设计之初并未考虑安全问题。这导致用户可以在提交任务的时候可以随意伪造身份，或是恶意程序伪装成服务进程对集群造成破坏。随着时间的推移，行业内的安全意识越来越高，Hadoop生态顺应潮流也逐渐补充完善了自己的安全模型。

3.1 LDAP 轻量目录访问协议

LDAP（Lightweight Directory Access Portocol，轻量目录访问协议）是一种用于访问与管理分布式目录服务的开放协议。目录服务是一种特殊的数据库，主要用于读取和查询操作，而不是写入操作。

在企业范围内实现LDAP可以让运行在几乎所有计算机平台上的所有的应用程序从 LDAP目录中获取信息。LDAP目录中可以存储各种类型的数据：电子邮件地址、邮件路由信息、人力资源数据、公用密匙、联系人列表，等等。通过把 LDAP目录作为系统集成中的一个重要环节，可以简化员工在企业内部查询信息的步骤。

LDAP目录以树状的结构来存储数据，可以理解为一个目录数据库。

LDAP 读性能好，但写性能差，不支持事务处理、回滚等复杂功能，不适用与频繁的数据更新场景，主要还是应用于读多写少场景。
关系数据库表则是将数据是以行列的形式存储在一张表中，而LDAP 数据库则是将数据组织成一个树形结构，数据存储在叶子节点。

名词解释:

Entry (项)：LDAP树状结构中每一个节点称为一个条目，每一个条目由唯一个dn标识。
dc（Domain Component，域组件）：用于表示域的组成部分。例如，dc=example,dc=com通常使用域名反写代表。

可以把它当作关系型中的库，比如将 http://aimyon36.com这样的域名，可以拆成 dc=com,dc=aimyon36这样的形式。
ou（Organizational Unit，组织单元）：用于组织和分类条目，例如部门、团队等。例如，ou=dept表示部门组织单元。

如果把比作库的话，ou也是可以比作表的，比如一个部门的员工应该存储在一张表中。
dn（Distinguished Name）：它用于唯一标识一个「项」，以及他在目录信息树中的位置。（一条dn就类似于关系型数据库中的一条数据）

dn示例：ou=user,dc=cubigdata,dc=cn | cn=技术部,ou=dept,dc=cubigdata,dc=cn
dn 字符串从左向右，各组成部分依次向树根靠近。
cn（Common Name，通用名称）：常用于表示条目的名字。例如，cn=John Doe表示一个名为John Doe的条目。
uid（User ID，用户ID）：唯一标识一个用户，例如uid=john。
object classes：每个「项」里面包含若干个 Object Classes，相当于是项的属性。（一条dn中的这些属性就类似于关系型数据库中一条数据的各个字段）