Kerberos 原理
1. 数据安全防护
用户在访问大数据集群数据时会有如下几个维度的安全防护方式来保证访问数据的安全:
-
边界安全(Perimeter Security):如设置防火墙、安全组控制端口。
-
认证(Authentication):大数据集群中组件服务开启身份认证功能,只有用户提供了合法的身份信息才有可能访问服务,它是后续授权的基础,没有身份认证的授权是有漏洞容易被冒充的。例如:任意连接到 HDFS 系统的用户都可以查看 HDFS 中的数据,设置是可以操作 HDFS 中的数据,存在安全问题。
-
授权(Authorization):通过身份认证的用户并不能访问服务所有的资源,需要通过授权机制对用户访问服务中实际的资源进行控制。例如通过 Ranger、Sentry 对访问 Hive 的用户进行授权限制用户访问 Hive 表中的哪些数据。
-
审计(Audit):用户对服务资源的访问,需要利用审计日志进行监控/跟踪,便于问题/风险的排査。
-
加密(Encrypt):涉及数据传输加密/数据存储加密,防止数据被窃取/窃取后被破解等。
以上边界安全主要是针对企业大数据集群节点的防火墙和安全组端口控制,避免非法访问和操作集群数据,边界安全假设“坏人”在外面,这通常是一个非常糟糕的假设,大多数真正具有破坏性的计算机犯罪事件都是内部人员所为,所以对于可以访问集群节点的人员还需进一步认证;
认证主要是针对通过边界安全维度后进行用户身份的确认,认证有很多形式,如服务组件自身提供了简单的用户名/密码认证方式、通过 Kerberos 认证服务对用户身份进行认证;
为了更好细粒度控制通过认证用户访问的资源可以通过对用户授权方式来决定用户操作资源的权限,这就是授权;最终操作集群资源时可以对数据进行加密传输,所有操作都会通过审计日志进行记录,便于风险排查。
针对认证(Authentication)部分,目前大数据企业比较通用的是使用 Kerberos 协议,集群上启动的多个服务组件可以通过使用同一个第三方的Kerberos 认证服务,对用户进行身份认证,例如大数据中 HDFS 默认安全认证的方式就采用的是 Kerberos 认证协议。
2. 什么是 Kerberos
Kerberos 是一种网络身份验证协议,Kerberos 协议通过使用密钥加密为 Client/Server 应用程序提供强大的身份验证。不同于其他网络安全协议的保证整个通信过程的传输安全,Kerberos 侧重于通信前双方身份的认定工作帮助客户端以及服务端验证是真正的自己并非他人,从而使得通信两端能够完全信任对方的身份,在一个不安全的网络中完成一次安全的身份认证继而进行安全的通信。
Kerberos 由麻省理工学院(MIT)研发实现,官网地址为:https://web.mit.edu/kerberos/
Kerberos 一词来源于古希腊神话中的 Cerberus(守护地狱之门的三头犬)
在大数据开发中,很多大数据组件都支持 Kerberos 身份认证,例如:HDFS、Yarn、Hive、HBase、Spark、Kafka 等。
3. Kerberos 认证原理
3.1 加密
为了更好理解 Kerberos 认证原理,需要首先对加密和数字证书概念进行理解。互联网通信中为了保证信息传输过程中数据的机密性可以对数据进行加密,加密又分为对称加密和非对称加密。
-
对称加密
对称加密是指加密和解密使用相同的密钥。发送方使用该密钥将明文转换为密文,接收方使用相同的密钥将密文还原为明文。这种方法的优点是加密和解密速度快,适用于大量数据的加密,但缺点是需要保护好密钥,因为密钥一旦泄露,所有的加密信息都将暴露。在 Kerberos 中信息加密方式默认就是对称加密。
常见的对称加密算法有:DES、AES、3DES 等。 -
非对称加密
非对称加密指的是:加密和解密使用不同的秘钥,一把作为公开的公钥,另一把作为私钥。 公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密。例如:发送方使用接收方的公钥加密明文,接收方使用自己的私钥解密密文。这种方法的优势就是即使密文和公钥被拦截,但是由于无法获取到私钥,也就无法破译到密文,但缺点是加密和解密速度相对较慢,不适用于大量数据的加密。
常见的非对称加密算法有:RSA、ECC 等。
3.2 Kerberos 认证流程
整个 Kerberos 认证流程中涉及到三种角色:客户端 Client、服务端 Server、密钥分发中心 KDC(Key Distribution Center)。
-
客户端(Client):发送请求的一方;
-
服务端(Server):接收请求的一方;
-
密钥分发中心 (Key Distribution Center,KDC):KDC 是一个网络服务,提供 ticket 和临时会活密钥。由三个部分组成:认证服务器(Authentication Server,AS)、票证授予服务器(Ticket Grantion Server,TGS)、Kerberos 数据库。
- 认证服务器 AS:负责认证客户端的身份并发放客户端访问 TGS 的 TGT(Ticket Grantion Ticket,票据授予票据);
- 票证授予服务器 TGS:用来发放客户端访问服务端所需的服务授予票据(ticket)。
- Kerberos 数据库:客户端和服务端添加进 keberos 系统时有对应的密钥,数据库负责存储这些密钥,并保存客户端和服务端的基本信息,如:用户名、用户 IP 地址、服务端 IP、服务端名称等。
Kerberos 认证过程总体流程为:客户端向 KDC 请求要访问的目标服务器的服务授予票据( ticket),然后客户端拿着从 KDC 获取的服务授予票据(ticket)访问服务端。
通俗的理解: 票据(ticket)可以理解为通行证。核心流程是:客户端向 TGS 索取一张通行证(票据 ticket),然后客户端拿着通行证(票据 ticket)去联系服务端,如果服务端核实了通行证无误,则建立通信。
在以上这个过程中需要保证客户端和服务端为正确的客户端和服务端,整个 Keberos 认证流程共有三次交互,如下:
- 客户端向 KDC AS 获取 TGT
为了获取访问服务端的服务授予票据,客户端首先向 KDC 中 AS 获取 TGT(票据授予票据),客户端需要使用 TGT 去 KDC 中的 TGS(票据授予中心)获取访问服务端所需的 Ticket(服务授予票据)才能进一步的与服务端通信。
客户端首先向 KDC 以明文方式发起请求,该请求中携带了访问 KDC 的用户名、主机IP、当前时间戳。由于客户端是第一次访问 KDC,KDC 中 AS(认证服务器)接收请求后,去 Kerberos 数据库中验证是否存在访问的用户名,这个过程不会判断身份的可靠性。如果没有该用户名,认证失败;如果存在该用户名,AS 会返回两部分信息给客户端:
- 第一部分信息为票据授予票据(TGT),TGT 包含该客户端的名称、IP、当前时间戳、客户端即将访问的 TGS 的名称、TGT 的有效时间以及客户端与 TGS 之间通信的 Session Key(简称 CT SK),该 Key 后续会用来对客户端向 TGS 发送的消息加密,整个 TGT 使用 TGS 公钥加密,客户端是解密不了的,后续客户端需要使用 TGT 去 KDC 中的 TGS(票据授予中心)获取访问服务端所需的 Ticket(服务授予票据)。
- 第二部分信息是使用客户端公钥加密的信息,该信息包含客户端和 TGS 通信的 Session Key(CT SK),客户端将要访问 TGS 的名称、TGT 的有效时间以及当前时间戳。该部分内容由于是使用客户端密钥进行加密,所以客户端拿到该部分内容可以使用自己的私钥进行解密,如果这时数据被劫持到一个假的客户端,由于真正客户端的私钥没有在网络中传输过,所以假的客户端无法对这部分信息进行解密,认证流程就会中断。只有正确的客户端才能对这部分信息进行解密,这个过程相当于是对客户端进行认证。
- 客户端向 KDC TGS 获取目标服务器的服务授予票据 ticket
客户端收到了来自 KDC AS 返回的两部分信息后,对第二部分信息进行解密,可以获取与 TGS 通信的 Session Key(CT SK)、将要访问 TGS 的名称、时间戳。首先会检查时间戳是否与自己返送数据的时间戳相差 5 分钟,如果大于 5 分钟则认为该 AS 是假的,认证中断。如果时延合理,客户端便向 TGS 发起请求去获取要访问目标服务端的服务授予票据 ticket。
客户端向 KDC TGS 请求的信息包括三部分:
-
客户端将要访问的服务端名称
-
客户端从 KDC AS 中获取的第一部分信息,即:使用 TGS 密钥加密的 TGT,通过 TGT 客户端可以从 TGS 中获取访问服务器的服务授予票据 ticket
-
使用 CT SK 加密的信息,包括客户端名称、IP、时间戳
当 KDC 中的 TGS 收到了客户端的请求后,首先去 Kerberos 数据库中查询是否存在该服务端,如果不存在认证失败。如果存在,TGS 会使用自己的私钥对TGT 进行解密,从而获取到经过 KDC AS 认证过的客户端信息、CT SK、时间戳信息,TGS 会根据时间戳判断此次通信是否超出时间延迟,如果正常,TGS 会对客户端发送过来的加密信息(使用 CT SK 加密的信息)进行解密,获取客户端名称、IP 信息,如果这部分信息与 TGT 中的客户端信息一致,那么就确认客户端的身份正确,否则中断认证。
KDC TGS 通过确认是对的客户端后,会将如下两部分信息返回给客户端:
-
第一部分信息:客户端需要访问服务端需要的 Server Ticket(服务授予票据,后续简称 ST),该 Ticket 通过 Server 公钥进行加密,其中包括客户端名称、IP、需要访问的服务端的 IP、ST 有效时间、时间戳、用于客户端与服务端之间通信的 Session Key(后续简称 CS SK)。
-
第二部分信息:使用 CT SK 加密的内容,这些加密内容包括:CS SK、时间戳、ST 有效时间,由于客户端与 AS 通信时,AS 已经将 CT SK 私钥通过客户端公钥加密交给了客户端,客户端缓存了 CT SK,并能对该部分内容进行解密。
- 客户端向服务端发送通信请求
当客户端收到来自 KDC TGS 的响应后,对第二部分内容进行解密,获取 CS SK、时间戳、ST 有效时间,检查时间戳在时间延迟范围内,向服务端进行请求。
客户端会通过 CS SK 将客户端名称、时间戳进行加密发送给服务端,此外还会将服务授予票据 ST 发送给服务端。
服务端收到来自客户端的请求,会使用自己私钥对 ST 进行解密获取信息(客户端名称、IP、需要访问的服务端的 IP、ST 有效时间、时间戳、用于客户端与服务端之间通信的 CS SK),将 CS SK 取出对客户端发来的通过 CS SK 加密的内容进行解密获取信息(客户端名称、时间戳),如果客户端信息一致说明该客户端是通过 KDC 认证的客户端,可以进一步提供服务,这时服务端返回通过 CS SK 加密的接收请求信息给客户端,客户端接收到该请求后,使用缓存在客户端的 CS SK 解密后,也确认了服务端身份,这个过程服务端还会通过数字证书证明自己身份。
以上 3 个步骤代表了整个 Kerberos 认证的流程,通信的客户端和服务端都确认了双方的身份信息。这个过程使用了各方的密钥,且密钥的种类一直变化,为了防止网络拦截密钥,这些密钥都是临时生成的 Session Key,即它们只在一次 Session 会话中起作用,即使密钥被劫持,等到密钥被破解可能这次会话都早已结束,这为整个 Kerberos 认证过程保证了较高的安全性。
4. Kerberos 优势
Kerberos 具备如下三点优势:
- 密码无需进行网络传输。基于 Ticket 实现身份认证,保障密钥安全性。
- 双向认证。整个认证过程中,不仅需要客户端进行认证,待访问的服务也需要进行身份认证。
- 高性能。密钥采用对称加密方式,相比于 SSL 的密钥操作快几个数量级。一旦 Client 获得访问某个 Server 的 Ticket,该 Server 就能根据这个 Ticket 实现对 Client 的验证,而无须 KDC 的再次参与。