【大数据安全】基于Kerberos的大数据安全验证方案

1.背景

互联网历来就不是一个安全的地方。不少时候咱们过度依赖防火墙来解决安全的问题，不幸的是，防火墙是假设“坏人”是来自外部的，而真正具备破坏性的攻击事件都是每每都是来自于内部的。

近几年，在thehackernews等网站上总会时不时看到能够看到一些由于数据安全问题被大面积攻击、勒索的事件。在Hadoop1.0.0以前，Hadoop并不提供对安全的支持，默认集群内全部角色都是可靠的。用户访问时不须要进行任何验证,致使恶意用户很容易就能够假装进入集群进行破坏。

要保证Hadoop集群的安全，至少要作到2个A：Authentication（认证），Authorization（受权）。常见的方案有：

• Authentication：
  MIT Kerberos, Azure AD, Kerby

• Authorization：
  Apache Sentry(Cloudera), Apache Ranger(Hortonworks)

Hadoop集群对Kerberos的支持

2012年1.0.0版本正式发布后，Hadoop增长了对Kerberos的支持。使得集群中的节点是可信任的。Kerberos能够将认证的密钥在集群部署时事先放到可靠的节点上。集群运行时，集群内的节点使用密钥获得认证，认证经过后的节点才能提供服务。企图冒充的节点因为没有事先获得的密钥信息，没法与集群内部的节点通讯。这样就防止了恶意地使用或篡改Hadoop集群的问题，确保了Hadoop集群的可靠性、安全性。

2.Kerberos介绍

Kerberos是种网络身份验证协议,最初设计是用来保护雅典娜工程的网络服务器。Kerberos这个名字源于希腊神话，是一只三头犬的名字，它旨在经过使用密钥加密技术为Client/Server序提供强身份验证。能够用于防止窃听、防止重放攻击、保护数据完整性等场合，是一种应用对称密钥体制进行密钥管理的系统。Kerberos的扩展产品也使用公开密钥加密方法进行认证。

Kerberos目前最新版本是5，1~3版本只在MIT内部发行，由于使用DES加密，早期被美国出口管制局列为军需品禁止出口，直到瑞典皇家工学院实现了Kerberos版本4，KTH-KRB。后续也是这个团队实现了版本5: Heimdal，目前常见的Kerberos5实现之一。
本文中讨论的Kerberos5实现版本为MIT Kerberos，MIT保持的大约半年左右一次的更新速度，目前最新版本是2018-11-01发布的1.16.2版本。

2.1 名词解释

• AS（Authentication Server）：认证服务器
• KDC（Key Distribution Center）：密钥分发中心
• TGT（Ticket Granting Ticket）：票据受权票据，票据的票据
• TGS（Ticket Granting Server）：票据受权服务器
• SS（Service Server）：特定服务提供端
• Principal：被认证的个体
• Ticket：票据，客户端用来证实身份真实性。包含：用户名，IP，时间戳，有效期，会话秘钥。

使用Kerberos时，一个客户端须要通过三个步骤来获取服务:

1. 认证: 客户端向认证服务器发送一条报文，获取一个包含时间戳的TGT。
   
2. 受权: 客户端使用TGT向TGS请求指定Service的Ticket。
3. 服务请求: 客户端向指定的Service出示服务Ticket鉴权通信。

Kerberos协议在网络通讯协定中属于显示层。其通讯流程简单地说，用户先用共享密钥从某认证服务器获得一个身份证实。随后，用户使用这个身份证实与SS通讯，而不使用共享密钥。

2.2 具体通讯流程

①此流程使用了对称加密; ②此流程发生在某一个Kerberos领域中； ③小写字母c,d,e,g是客户端发出的消息，大写字母A,B,E,F,H是各个服务器发回的消息。

首先，用户使用客户端上的程序进行登陆：

1. 输入用户ID和密码到客户端（或使用keytab登陆）。
2. 客户端程序运行一个单向函数（大多数为Hash）把密码转换成密钥，这个就是客户端的“用户密钥”(user's secret key)。

2.2.1 客户端认证（Kinit）

客户端(Client)从认证服务器(AS)获取票据的票据（TGT）。

1. Client向AS发送1条明文消息，申请基于该用户所应享有的服务，例如“用户Sunny想请求服务”（Sunny是用户ID）。（注意：用户不向AS发送“用户密钥”(user's secret key)，也不发送密码）该AS可以从本地数据库中查询到该申请用户的密码，并经过相同途径转换成相同的“用户密钥”(user's secret key)。
2. AS检查该用户ID是否在于本地数据库中，若是用户存在则返回2条消息：
   • 【消息A】：Client/TGS会话密钥(Client/TGS Session Key)（该Session Key用在未来Client与TGS的通讯（会话）上），经过 用户密钥(user's secret key) 进行加密
   • 【消息B】：票据受权票据(TGT)（TGT包括：消息A中的“Client/TGS会话密钥”(Client/TGS Session Key)，用户ID，用户网址，TGT有效期），经过TGS密钥(TGS's secret key) 进行加密
3. 一旦Client收到消息A和消息B，Client首先尝试用本身的“用户密钥”(user's secret key)解密消息A，若是用户输入的密码与AS数据库中的密码不符，则不能成功解密消息A。输入正确的密码并经过随之生成的"user's secret key"才能解密消息A，从而获得“Client/TGS会话密钥”(Client/TGS Session Key)。（注意：Client不能解密消息B，由于B是用TGS密钥(TGS's secret key)加密的）。拥有了“Client/TGS会话密钥”(Client/TGS Session Key)，Client就足以经过TGS进行认证了。

2.2.2 服务受权

Client从TGS获取票据(client-to-server ticket)。

1. 当client须要申请特定服务时，其向TGS发送如下2条消息：
   • 【消息c】：即消息B的内容（TGS's secret key加密后的TGT），和想获取的服务的服务ID（注意：不是用户ID）
   • 【消息d】：认证符(Authenticator)（Authenticator包括：用户ID，时间戳），经过Client/TGS会话密钥(Client/TGS Session Key)进行加密
2. 收到消息c和消息d后，TGS首先检查KDC数据库中是否存在所需的服务，查找到以后，TGS用本身的“TGS密钥”(TGS's secret key)解密消息c中的消息B（也就是TGT），从而获得以前生成的“Client/TGS会话密钥”(Client/TGS Session Key)。TGS再用这个Session Key解密消息d获得包含用户ID和时间戳的Authenticator，并对TGT和Authenticator进行验证，验证经过以后返回2条消息：
   • 【消息E】：client-server票据(client-to-server ticket)（该ticket包括：Client/SS会话密钥 (Client/Server Session Key），用户ID，用户网址，有效期），经过提供该服务的服务器密钥(service's secret key) 进行加密
   • 【消息F】：Client/SS会话密钥( Client/Server Session Key) （该Session Key用在未来Client与Server Service的通讯（会话）上），经过Client/TGS会话密钥(Client/TGS Session Key) 进行加密
3. Client收到这些消息后，用“Client/TGS会话密钥”(Client/TGS Session Key)解密消息F，获得“Client/SS会话密钥”(Client/Server Session Key)。（注意：Client不能解密消息E，由于E是用“服务器密钥”(service's secret key)加密的）。

2.2.3 服务请求

Client从SS获取服务。

1. 当得到“Client/SS会话密钥”(Client/Server Session Key)以后，Client就可以使用服务器提供的服务了。Client向指定服务器SS发出2条消息：
   • 【消息e】：即上一步中的消息E“client-server票据”(client-to-server ticket)，经过服务器密钥(service's secret key) 进行加密
   • 【消息g】：新的Authenticator（包括：用户ID，时间戳），经过Client/SS会话密钥(Client/Server Session Key) 进行加密
2. SS用本身的密钥(service's secret key)解密消息e从而获得TGS提供的Client/SS会话密钥(Client/Server Session Key)。再用这个会话密钥解密消息g获得Authenticator，（同TGS同样）对Ticket和Authenticator进行验证，验证经过则返回1条消息（确认函：确证身份真实，乐于提供服务）
   • 【消息H】：新时间戳（新时间戳是：Client发送的时间戳加1，v5已经取消这一作法），经过Client/SS会话密钥(Client/Server Session Key) 进行加密
3. Client经过Client/SS会话密钥(Client/Server Session Key)解密消息H，获得新时间戳并验证其是否正确。验证经过的话则客户端能够信赖服务器，并向服务器（SS）发送服务请求。
4. 服务器（SS）向客户端提供相应的服务。

3.Kerberos HA架构

Kerberos支持两种服务器在域内冗余方式：Master/Slave（MIT和Heimdal）和Multimaster结构（Windows Active Directory）。在生产环境中部署Kerberos时，最好使用一主(Master)多从(Slave)的架构，以确保Kerberos服务的高可用性。

Kerberos中每一个KDC都包含数据库的副本。主KDC包含域（Realm）数据库的可写副本，它以固定的时间间隔复制到从KDC中。全部数据库更改（例如密码更改）都在主KDC上进行，当主KDC不可用时，从KDC提供Kerberos票据给服务受权，但不提供数据库管理。KDC须要一个Admin来进行平常的管理操做。
Kerberos的同步机制只复制主数据库的内容，但不传递配置文件，如下文件必须手动复制到每一个Slave中：

- krb5.conf
- kdc.conf
- kadm5.acl
- master key stash file

3.1 HA方案

目前单机房HA方案使用的较多的是Keepalived + Rsync 。Keepalived能够将多个无状态的单点经过虚拟IP(如下称为VIP)漂移的方式搭建成一个高可用服务。

首先，在Master KDC中建立数据库的dump文件(将当前的Kerberos和KADM5数据库转储为ASCII文件)：

kdb5_util dump [-b7|-ov|-r13] [-verbose] [-mkey_convert] [-new_mkey_file mkey_file] [-rev] [-recurse] [filename [principals...]]

而后使用Rsync将目录同步到Slave机器的对应目录中，
再导入KDC中：

kdb5_util load [-b7|-ov|-r13] [-hash] [-verbose] [-update] filename [dbname]

Hadoop全部请求经过请求内网域名，解析到Keepalived绑定的VIP的方式来使用KDC:

4. 优化和展望

4.1 优化

（1）用户（Principal）管理

若是团队中已经有一套权限系统，要将现有的身份系统集成到Kerberos中会很困难。
随着业务的飞速增加，服务器规模愈来愈大，Kerberos Principal手动操做会愈来愈频繁，手动的增删改查维护会很是痛苦。须要在Kerberos管理系统中规范Principal申请、维护、删除、keytab生成流程。Principal申请和权限管理自动化。

（2）数据同步优化

Kerberos数据同步能够将生成的数据记录同步写入到MySQL中，使用MySQL双主同步方式。在跨机房环境中，KDC数据使用Rsync工具进行增量同步。以A核心机房做为主机房，Rsync Server使用了Keepalived VIP的方式，当Kerberos主机宕机后，VIP漂移到另一台主机器上，Rsync Client会以VIP所在的KDC主机器为Rsync Server进行数据同步，以保证KDC数据同步的高可用性。

（3）运维

使用进程管理工具对Kerberos相关进程进行存活监控，当发现有进程异常退出时，邮件/微信/钉钉报警，主动再次拉起进程。

4.2 展望

部署过Kerberos的同窗都知道，在Hadoop集群部署Kerberos实际是一项很是繁琐的工做。Kerberos本质上是一种协议或安全通道，对于大多数用户或普通用户来讲，是有必定学习曲线的，是否有更好的实现可以对普通用户隐藏这些繁琐的细节。

阿里和Intel合做项目Hadoop Authentication Service (HAS) 据称目前已经应用到ApsaraDB for HBase2.0中:

HAS方案使用Kerby替代MIT Kerberos服务，利用HAS插件式验证方式创建一套人们习惯的帐户密码体系。

目前HAS在Apache Kerby项目has-project分支开发中，将来会做为Kerbby的新feature出如今下一次release中。

Apache Kerby做为Apache Directory的一个子项目，目前关注度并不高，让咱们期待它在后续的发展吧。