开发者社区> mantoudev> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

基于Kerberos的大数据安全方案

简介:
+关注继续查看

1.背景

互联网从来就不是一个安全的地方。很多时候我们过分依赖防火墙来解决安全的问题,不幸的是,防火墙是假设“坏人”是来自外部的,而真正具有破坏性的攻击事件都是往往都是来自于内部的。

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

不安全的Hadoop集群

要保证Hadoop集群的安全,至少要做到2个A:Authentication(认证),Authorization(授权)。常见的方案有:

  • Authentication
    MIT Kerberos, Azure AD, Kerby
  • Authorization
    Apache Sentry(Cloudera), Apache Ranger(Hortonworks)

Hadoop Cluster Secure

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:
Kerberos HA

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

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

目前HAS在Apache Kerby项目has-project分支开发中,未来会作为Kerbby的新feature出现在下一次release中。

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Kerberos 身份验证在 ChunJun 中的落地实践
Kerberos 是一种计算机网络授权协议,用来在非安全网络中,对个人通信以安全的手段进行身份认证。Kerberos 旨在通过密钥加密技术为客户端 / 服务器应用程序提供身份验证,主要用在域环境下的身份验证。
0 0
TeamTNT变种攻击Hadoop集群,云上服务对外开放需谨慎
近日,阿里云安全监测到TeamTNT变种,除了沿用之前攻击手法,最新利用了Hadoop Yarn未授权访问漏洞进行传播,同时使用多个域名和IP确保恶意文件落地,对脚本进行二进制化封装以对抗主机端检测。
0 0
【大数据安全】Kerberos集群安装配置
1. 概述 Kerberos是一种计算机网络认证协议,它允许某实体在非安全网络环境下通信,向另一个实体以一种安全的方式证明自己的身份。它也指由麻省理工实现此协议,并发布的一套免费软件。它的设计主要针对客户-服务器模型,并提供了一系列交互认证——用户和服务器都能验证对方的身份。
3156 0
㉒云上场景:邵逸夫远程医疗平台,基于分布式系统的备份与安全机制
邵逸夫健康云平台采用阿里云分步式文件系统会把每一个文件切成64K的碎片,加密存储在服务器上,并进行3份拷贝,保证文件存储的安全,确保云端医患数据的安全与隐私。
1937 0
RSA发布DLP套件8.0 提供基于政策的数据保护方法
2010年3月16日,信息安全事业部RSA全球同步发布RSA® Data Loss Prevention (DLP)套件8.0版。 DLP套件是RSA公司市场领先的集成数据安全产品,用于发现、监控和防止敏感数据丢失、数据泄漏或数据滥用,它支持数据中心、网络和端点各个环节的数据保护。
1110 0
+关注
mantoudev
Java, Android, 大数据开发
文章
问答
文章排行榜
最热
最新
相关电子书
更多
云上基于Kerberos的大数据安全实践
立即下载
大数据时代数据安全防 护通用最佳实践
立即下载
\"ALIBABA SECURITY攻击过程的威胁情报应对体系 --安全威胁情报中心\"
立即下载