好大夫在线是一家互联网医疗公司，医疗数据的安全性关乎重大。而现阶段的大数据平台并没有原生的安全认证，Cloudera公司的开源大数据平台CDH在内网实践中，也仅由网络防火墙来解决安全问题。在对数据安全要求极高的医疗领域场景下，这样的安全保障是不够的，它无法保证内网人员对数据访问权限的严格控制，这一缺点如果被人潜入内部利用则会发生灾难。

背景

医疗行为本身决定了患者和医生都不可能隐瞒或者造假，即医疗数据具有普遍的真实性和隐私性，并存在极高的质量和价值。同时，医疗数据覆盖范围广，既是个体的生物学数据，又包含了疾病传播、地区流行病发展等数据，一旦数据泄漏将会带来严重影响。因此，使用网络安全认证和权限管理来对数据资产进行安全加固势在必行。

好大夫在线大数据部门，通过前期的调研和验证，最终决定把Kerberos和Apache Sentry集成到大数据集群上，用于加固数据安全，防止数据的泄漏。

Kerberos是什么？

Kerberos提供了大数据组件之间的身份认证，简单说就是，当A组件去访问B组件时， B能够确认来访的A就是真的A，而不是被其他CDEF冒充的，A也能确认自己要访问的B就是真的B，而不是被路由到其他的恶意组件上。

Kerberos由MIT创建，是一种计算机网络安全协议，用于在不可信网络（例如Internet）上的两个或多个可信主机之间对服务请求进行身份验证，解决网络安全问题。

该协议的名称源于希腊神话中传说中的三头犬Kerberos，在此协议的架构中Kerberos的三个头分别代表了客户端，服务器和密钥分发中心（KDC）。KDC用作受信任的第三方身份验证服务。

它使用对称密钥加密手段验证客户端-服务器应用程序，使用密钥加密技术对受信任的第三方验证用户的身份。

这意味着未加密的密码不会在网络上传输，客户端可以通过不安全的网络连接向服务器证明其身份，之后，他们还可以加密所有通信，以确保在开展业务时的私密性和数据完整性。

Kerberos在可靠审核和身份验证功能的安全系统中大量使用。还可以用于Posix以及Active Directory，NFS和Samba的身份验证。

为什么要用Kerberos？

互联网本身就是一个不安全的环境。Internet中使用的许多协议都不提供任何安全性。恶意黑客通过嗅探网络来偷取用户的密码。因此，通过网络发送未使用加密密码的应用程序极易受到攻击。

更糟糕的是，客户端/服务器应用程序依靠客户端程序认为正在使用该客户端程序的用户的身份是安全可靠的。

Kerberos工作流程中涉及的主要概念

1、主体（Principal）

在Kerberos系统中，客户端和服务器都有一个唯一的名字即Principal，组件间相互访问使用Principal相互识别身份。每一个主体（Principal）都有自己的密码，且只有主体本身和密钥分发中心KDC知道。Principal由三个部分组成：primary, instance以及realm，其组成形式为primary/instance@realm：

primary：可以是OS中的username，也可以是service name；
instance：用于区分属于同一个user或者service的多个principals，该项为optional；
realm：类似于DNS中的domain，一个集群内的机器拥有相同的realm。

Kerberos中的Principal分两种。一种叫用户，例如在dev用户对应的Kerberos主体叫做dev@CDH.COM。另一种叫做服务，如cdh1机器上的Impala服务,对应在Kerberos中的主体为impala/cdh1@CDH.COM。

2、密钥分发中心KDC（key distribution center）

KDC包含身份验证服务器（AS）和票证授予服务器（TGS）两部分。

KDC 只做两件事：身份验证和票证授予，AS模块用于给所有用户主体（Principal）授予TGT, TGS模块用于验证访问发起方的TGT，并授予被访问主体的Ticket。

身份验证服务器AS（authentication service）：AS执行所需的客户端身份验证。如果身份验证成功完成，则AS向客户端颁发一个称为TGT（票证授予票证）的票证。此票证可确保其他服务器对客户端进行身份验证。

票证授权票证TGT（ticket granting ticket）：由KDC的AS发放；获得这样一张票据后，以后申请其他应用的服务票据（ST）时，就不需要向KDC提交身份认证信息，TGT具有一定的有效期，就像是Kerberos进行用户登陆（Kinit）以后票证具有一个固定时间的有效期，过了有效期需要不断的去renew来续约，续约到期需要重新提交身份认证信息。

票证授予服务TGS（ticket granting service）：TGS以票证授权票证（TGT）为依据，生成服务票证ST。

服务票证ST(service ticket)：由KDC的TGS发放，任何一个应用（application）都需要一张有效的服务票据才能访问；如果能正确接受ST，说明客户端（client）和服务器（server）之间的信任关系已经被建立，通常是一张数字加密的证书。

Kerberos工作流程

Step 1: 初始客户端身份验证请求。用户（Principal）从身份验证服务器（AS）索取票证授予票证（TGT），该请求包括客户端ID。

Step 2: KDC验证客户端的凭据。AS检查数据库中的客户端和TGS的可用性。如果AS找到两个值，它将使用用户的密码哈希值生成客户端/用户密钥。然后，AS计算TGS密钥，并创建由客户端/用户密钥加密的会话密钥（SK1）。然后，AS会生成一个包含客户端ID，客户端网络地址，时间戳，生存期和SK1的TGT。然后，TGS密钥对票证进行加密。

Step 3: 客户端解密消息。客户端使用客户端/用户密钥对消息解密并提取SK1和TGT，从而生成用于验证客户端TGS的身份验证器。

Step 4: 客户端使用TGT请求访问。客户端通过将提取的TGT和创建的身份验证器发送到TGS，向提供服务的服务器请求票证。

Step 5: KDC为文件服务器创建票证。TGS使用TGS密钥解密从客户端收到的TGT并提取SK1。TGS解密身份验证器，并检查其是否与客户端ID和客户端网络地址匹配。TGS还使用提取的时间戳来确保TGT尚未过期。如果该过程成功进行了所有检查，则KDC会生成一个服务会话密钥（SK2），该密钥在客户端和目标服务器之间共享。最后，KDC创建一个服务票证，其中包括客户端ID、客户端网络地址、时间戳和SK2、使用从数据库获得的服务器密钥对该票证进行加密。客户端收到一条消息，其中包含服务票证和SK2，均用SK1加密。

Step 6: 客户端使用文件票证进行身份验证。客户端使用SK1解密消息并提取SK2。此过程将生成一个新的身份验证器，其中包含用SK2加密的客户端网络地址，客户端ID和时间戳，并将其和服务票证发送到目标服务器。

Step 7: 目标服务器接收解密和身份验证。目标服务器使用服务器的密钥来解密服务票证并提取SK2。服务器使用SK2解密身份验证器，执行检查以确保身份验证器中的客户端ID和客户端网络地址与服务票证相匹配。服务器还会检查服务票证，看它是否已过期。满足检查要求后，目标服务器将向客户端发送一条消息，以验证客户端和服务器之间是否已通过身份验证。若验证通过，用户就可以进行安全会话。

上述原理是不是已经有点晕了呢，没关系，举个例子就明白了：

假设小明要去游乐场玩，首先需要在大门口检查游客的身份(即检查小明的ID和PASS), 如果小明通过验证，游乐场的门卫 (AS) 则会提供给小明一张门卡 (TGT)。

这张卡片的用处就是告诉游乐场的各个场所的服务员，小明是通过正门进来，而不是后门偷爬进来的，同时这张卡片也是小明进入游乐场游玩需要的第一把钥匙。

现在小明有了这张卡，但是小明来游乐场拿这张卡是不能玩游乐项目的。这时小明想玩过山车，过山车的服务员 (client) 拦下小明，向小明要过山车的 (ST) 票据，小明说他只有一个门卡 (TGT), 那小明只要把 TGT 放在一旁的票据授权机 (TGS) 上刷一下。票证授权机 (TGS) 就会根据小明现在所在的过山车项目，给小明一张过山车的门票 (ST), 这样小明有了过山车的票据，验证通过后小明就可以畅通无阻地游玩了。

当然如果小明玩完过山车后，想去游乐场的跳楼机玩，那小明一样只需要带着那张门卡 (TGT)，到对应的跳楼机票证授权机 (TGS) 上刷一下，得到跳楼机的票据 (ST) 就可以玩跳楼机了。

但是当小明离开游乐场后，这张门卡（TGT）就作废了，因为小明的 TGT 已经过期了，再想做任何事都会被拒绝，除非重新申请拿到门卡（TGT）。

Kerberos是如何在大数据平台使用的？

a) 因为要使用超过 128 位的加密密钥，那么必须使用非受限管辖区域策略文件local_policy.jar，US_export_policy.jar，所以需要在部署Kerberos服务的机器上替换JRE的加密jar包，可自行去Oracle官网下载；

b) Kerberos的集群节点可以被DNS解析或者在hosts中配置所有节点的映射关系；

c) 在其中一台机器上安装KDC：yum -y install krb5-server krb5-libs krb5-auth-dialog krb5-workstation openldap-clients；

d) 剩余机器上安装Kerberos的客户端：yum -y install krb5-libs krb5-workstation；

e) 安装完成后，修改KDC所在机器的krb5.conf，主要修改的内容已加注释说明：

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = CDH.COM #域名要保持一致
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h #票证的声明周期
 renew_lifetime = 2d #票证的最大续期时间
 forwardable = true

[realms]
 CDH.COM = {
  kdc = cdh1
  admin_server = cdh1
 }

[domain_realm]
 .cdh1.com = CDH.COM
 cdh1.com = CDH.COM

[kdc]
 profile=/var/kerberos/krb5kdc/kdc.conf

f) 修改kdc.conf，主要修改内容已加注释说明：

[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 CDH.COM = { #与krb5.conf的域名保持一致
  #master_key_type = aes256-cts #不使用默认的加密
  max_renewable_life= 2d #最大续期时间
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }

g) 修改kadm5.acl，添加管理员权限：/admin@CDH.COM

h) 创建数据库：kdb5_util create -r CDH.COM -s；

i) 创建管理员账户及密码然后启动Kerberos；

j) 分发krb5.conf到其他相同路径的Kerberos客户端节点上；

k) CDH集群配置开启Kerberos：

全选后点继续：

下一步导入 KDC Account Manager 凭据命令完成后，点击继续：

默认配置，点击继续：

自动重启集群中的所有服务，校验是否启用成功，并对各角色进行授信：

至此，大数据集群各组件的Kerberos认证就完成了！

那么Kerberos就一定安全可靠么？

Kerberos仍然是当今可用的最佳安全访问协议，该协议足够灵活，可以采用更强大的加密算法来帮助抵御新的威胁，如果用户实施了良好的密码选择策略，那么安全级别也会更高。

好了，至此Kerberos的背景、原理及搭建过程大致结束。下一篇中，我们将继续讲述Apache Sentry相关知识，以及其如何和Kerberos一起来进行访问权限控制的，感兴趣的小伙伴欢迎持续关注Kerberos。

作者介绍：

张博雅：好大夫在线大数据开发工程师，涉猎技术包括分布式实时离线计算，数据仓库建设，数据安全等，喜欢研究解决大数据组件相关问题。

马大芳：好大夫在线大数据开发工程师，专注大数据领域，主要关注Kafka/Spark/HBase等开源组件，热爱技术和探索。

好大夫在线创立于2006年，是一家互联网医疗平台。已收录国内10496家正规医院的69.2万名医生信息。其中，23万名医生在平台上实名注册，直接向患者提供线上医疗服务。

创作场景

Kerberos 和 Apache Sentry 干货实践（上）