大数据安全验证之 Kerberos | StartDT Tech Lab 11

这是奇点云全新技术专栏「StartDT Tech Lab」的第 11 期。

在这里，我们聚焦数据技术，分享方法论与实战。一线的项目经历，丰富的实践经验，真实的总结体会…滑到文末，可以看到我们的往期精彩内容。

本篇由奇点云高级 Java 架构专家「大门」带来：

作者：大门

阅读时间：约 13 分钟

一、背景

2021 年，人类已经从 IT 时代走向 DT 时代，大数据技术和应用也慢慢从幕后走到幕前，更多地曝光在公众面前。同时，就像互联网从蛮荒走向繁荣，大数据技术和应用也不可避免的碰到安全问题。

从 GB 到 TB，从 PB 到 EB、ZB，当今世界，每天产生的数据正在快速的指数级增长。随着数据的增长以及使用该数据的应用程序和框架的增长，数据的存储、分析、应用链路也越来越复杂，以前的安全手段已无法满足数据的指数级增长。

2006 年初，Hadoop 横空出世，给大数据行业带来了很大的变化。

Hadoop 在最初的设计中，默认集群内所有的节点都是可靠的。由于用户与 HDFS 或 M/R 进行交互时不需要验证，恶意用户可以通过伪装成真正的用户或者服务器入侵到 Hadoop 集群上，随意提交作业，修改 JobTracker 状态，篡改 HDFS 上的数据，伪装成 NameNode 或者 TaskTracker 接受任务，从而对数据进行破坏。

随后，HDFS 就对此作了改进，增加了文件和目录的权限。但由于没有强认证的保障，这些权限只能对偶然的数据丢失起保护作用。恶意的用户仍然可以伪装成其他用户来篡改权限，致使权限设置形同虚设。不能够对 Hadoop 集群起到安全保障。

在 Hadoop 的集群中，存在以下安全认证问题：

1 用户到服务器的认证问题

1.1 NameNode，JobTracker 上没有用户认证

用户可以伪装成其他用户入侵到一个 HDFS 或者 MapReduce 集群上。

1.2 DataNode 上没有认证

Datanode 对读入输出并没有认证。导致如果一些客户端如果知道 block 的 ID，就可以任意访问 DataNode 上 block 的数据。

1.3 JobTracker 上没有认证

可以任意杀死或更改用户的 jobs，可以更改 JobTracker 的工作状态。

2 服务器到服务器的认证问题

2.1 没有 DataNode, TaskTracker 的认证

用户可以伪装成 datanode，tasktracker，去接受 JobTracker, Namenode 的任务指派。

为了解决上述的安全问题，Hadoop 从 1.0.0 版本以后，引入 Kerberos 认证机制，即用户跟服务通信以及各个服务之间通信均用 Kerberos 认证，在用户认证后做任务执行、访问服务、读写数据等均采用特定服务发起访问 token，让需求方凭借 token 访问相应服务和数据。

图源：Youtube

Kerberos 可以将认证的密钥在集群部署时事先放到可靠的节点上。集群运行时，集群内的节点使用密钥得到认证，认证通过后的节点才能提供服务。企图冒充的节点由于没有事先得到的密钥信息，无法与集群内部的节点通信。这样就防止了恶意地使用或篡改数据集群的问题，确保了集群的可靠性、安全性。

二、Kerberos 介绍

地狱三头犬 图源：Baidu

Kerberos 是一种由 MIT（麻省理工大学）提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

Kerberos 这个名字来源于希腊神话，是冥界守护神兽的名字。之所以用 Kerberos 来命名一种完全认证协议，是因为整个认证过程涉及到三方：客户端、服务端和 KDC（Key Distribution Center）。而冥界守护神兽也是三头犬，正好符合了协议的语义。

Kerberos 可提供功能强大的用户验证以及完整性和保密性。通过验证，可保证网络事务的发送者和接收者的身份真实。该服务还可以检验来回传递的数据的有效性（完整性），并在传输过程中对数据进行加密（保密性）。使用 Kerberos 服务，可以安全登录到其他计算机、执行命令、交换数据以及传输文件。

此外，该服务还提供授权服务，这样管理员就可以限制（其他用户）对服务和计算机的访问。

在 Kerberos 认证中，最主要的问题是如何证明「你是你」的问题，如当一个 Client 去访问 Server 服务器上的某服务时，Server 如何判断 Client 是否有权限来访问自己主机上的服务，同时保证在这个过程中的通讯内容即使被拦截或篡改也不影响通讯的安全性，这正是 Kerberos 解决的问题。在域渗透过程中 Kerberos 协议的攻防也是很重要的存在。

在解释 Kerberos 的认证过程之前，有必要先介绍一下 Kerberos 中的一些组件：

三、Kerberos 认证流程

如上图可以看到，一次安全认证包含 6 个步骤。下面我们详细地讲解认证过程：

#1

Client 发送请求到 AS ( Authentication Server )，告知 AS 自己的身份，请求一个访问 Server 的 Ticket。在这次请求 Ticket 的过程中，即使网络不安全，密码也不会外泄。因为这个请求是用 Client 的密码 A 加密过的，无需在网络中传递 Client 的密码 A —— AS 收到请求后，会从创建用户的数据库里找到 Client 的密码 A 用于解密。

#2

认证成功后，AS 会返回 TGT ( Ticket Granting Ticket ) 给 Client，注意，这个 TGT 会用另一个密码称为密码 B 来加密，如下图：

#3

Client 获取到 TGT 后，会将用密码 B 加密过的 TGT 发送给 TGS ( Ticket Granting Server )，来申请访问 Server。

 TGS 收到加密后的 TGT 后，会从 AS 获取密码 B 来做解密验证。从下图中可以看出，AS 和 TGS 是共享秘钥的。

#4

然后，TGS 会给 Client 发送一个 Token。该 Token 是在 TGS 上用另外一个不同的秘钥加密的。这是第三个秘钥 C 了。

#5

Client 在收到 Token 后，会把 Token 发往 Server。

#6

Client 可以访问 Server 了。

整个认证过程中出现了三次秘钥。最后，我们再总结下 Kerberos 验证过程中的四个组件三个密码的关系：密码 A 是 Client 和 AS 共有的，而密码 B 是 AS 和 TGS 共有的，最后密码 C 是 TGS 和 Server 共有的。

在下图（Hadoop 中使用 Kerberos 的实例）里可以看到，其步骤和 Kerberos 的认证过程是一样的。

图源：Youtube

四、使用经验和优化

01

Kerberos HA 架构

在生产环境中设置 Kerberos 时，最好有多个从 KDC 和一个主 KDC，以确保 Kerberos 服务的持续可用性。

每个 KDC 都包含 Kerberos 数据库的副本。主 KDC 包含领域数据库的可写副本，它会定期复制到从 KDC。所有数据库更改（例如密码更改）都在主 KDC 上进行。当主 KDC 不可用时，从 KDC 提供 Kerberos 票证授予服务，但不提供数据库管理。

需要注意：

· Kerberos 系统依赖于正确时间信息的可用性。确保主 KDC 和所有从 KDC 具有正确同步的时钟。

· 最好在访问受限的安全专用硬件上安装和运行 KDC。如果您的 KDC 同时也是一个文件服务器、FTP 服务器或 Web 服务器，甚至只是一台客户端机器，那么通过任何这些区域的安全漏洞获得 root 访问权限的人可能会获得对 Kerberos 数据库的访问权限。

参考资料：https://web.mit.edu/kerberos/krb5-1.12/doc/admin/install_kdc.html

02

HA 方案

目前单机房 HA 方案使用的较多的是 Keepalived + Rsync。

Keepalived 软件起初是专为 LVS 负载均衡软件设计的，用来管理并监控 LVS 集群系统中各个服务节点的状态。Keepalived 采用 VRRP （虚拟路由冗余协议）热备份协议，以软件的方式实现 Linux 服务器的多机热备。VRRP 是针对路由器的一种备份解决方案——由多台路由器组成一个热备组，通过共用的虚拟 IP（VIP）地址对外提供服务；每个热备份组内同一时刻只有一台主路由器提供服务，其他路由器处于冗余状态，若当前在线的路由器失效，则其他路由器会自动接替（优先级决定接替顺序）虚拟 IP 地址，以继续提供服务。

首先，在 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：

03

方案优化

#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 相关进程、端口、主机进行存活监控，确保进程有问题时可以自动拉起进程，然后通过短信/钉钉告知维护人员。