大数据安全验证之KerberosStartDTTechLab11

　　这是奇点云全新技术专栏「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中的一些组件：
　　名称
　　作用   KDC
　　（Key Distributed Center）
　　整个安全认证过程的票据生成管理服务，包含两个服务AS和TGS   AS
　　（Authentication Service）
　　为client生成TGT的服务   TGS
　　（Ticket Granting Service）
　　为client生成某个服务的ticket   AD
　　（Account Database）
　　存储所有client的白名单，只有存在白名单的client才能顺利申请TGT   TGT
　　（Ticket-Granting Ticket）
　　用于获取ticket的票据
　　Client
　　想访问某个server的客户端
　　Server
　　提供某种业务的服务
　　Ticket
　　一个记录，客户用它来向服务器证明自己的身份，包括客户标识、会话密钥、时间戳。
　　三、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 相关进程、端口、主机进行存活监控，确保进程有问题时可以自动拉起进程，然后通过短信/钉钉告知维护人员。
　　本文简单介绍了Kerberos的前世今生和认证过程。Kerberos本质上是一种安全认证协议，用户在做集群部署或应用接入会碰到一些问题，希望本文能为大家解惑。
　　随着大数据技术和应用的快速增长，越来越多的人选择了Kerberos来保护数据安全，也有很多人做了部署方案优化、接入层封装等等。我们在后续的学习中会继续深入讨论。