Kerberos: The Network Authentication Protocol
1 引言
- 0编写目的
针对DataIDE和C70集群中均采用kerberos进行通讯安全认证,为方便日后对kerberos的学习,形成文档。
- 1kerberos简介
Kerberos简单来说就是一个用于安全认证第三方协议,它采用了传统的共享密钥的方式,实现了在网络环境不一定保证安全的环境下,client和server之间的通信,适用于client/server模型,由MIT开发和实现。
- 2Kerberos的神秘之处
它并不要求通信双方所在的网络环境是安全的,即使通信过程中数据被截取或者篡改依然不会影响它的正常工作,它提供的认证是双向的,不仅能保证Server不被错误的Client使用,同时也能保证Client不使用错误的Server。同时Kerberos又严重依赖于时间,时间戳也是Kerberos用来保证通信安全的重要手段,这个一般通过通信双方同时访问同一个时间服务器来实现。Kerberos也能达到单点登录的效果,即当Client通过了Kerberos server的认证后,便可以访问多个Real Server。
2 Kerberos原理浅析
2.1 流程
在实际的应有场景中通常有三个角色,即需要访问服务的Client,提供服务的Application Server,以及提供安全认证的第三方Kerberos服务器KDC(Key Distribution Center)。它们彼此之间的认证、通信的数据流如下图所示,为方便理解,加了一个实体图
- 名词解释
- 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:提供某种业务的服务
2.2 kerberos的认证流程
- 流程总体分为3步
- client与AS交互
- client与TGS交互
- client与server交互
- 详细分析
- 相比kerberos,https可能更为熟悉一点,通过证书和非对称加密的方式,让客户端可以安全的访问服务端,但这仅仅是客户端安全,通过校验,客户端可以保证服务端是安全可靠的,而服务端却无法得知客户端是不是安全可靠的。这也是互联网的一种特性。而kerberos可以支持双向认证,就是说,可以保证客户端访问的服务端是安全可靠的,服务端回复的客户端也是安全可靠的
- 想证明client和server都是可靠的,必然要引入第三方公证平台,这里就是AS和TGS两个服务
- client向kerberos服务请求,希望获取访问server的权限。kerberos得到了这个消息,首先得判断client是否是可信赖的,也就是白名单黑名单的说法。这就是AS服务完成的工作,通过在AD中存储黑名单和白名单来区分client。成功后,返回AS返回TGT给client。
- client得到了TGT后,继续向kerberos请求,希望获取访问server的权限。kerberos又得到了这个消息,这时候通过client消息中的TGT,判断出了client拥有了这个权限,给了client访问server的权限ticket
- client得到ticket后,终于可以成功访问server。这个ticket只是针对这个server,其他server需要像TGS申请。
- 通过这3步,一次请求就完成了。当然这里会有个问题,这样也没比https快啊。解释一下
- 整个过程TGT的获取只需要一次,其中有超时的概念,时间范围内TGT都是有效的,也就是说一般情况访问server只需要直接拿到ticket即可
- 整个过程采用的是对称加密,相对于非对称加密会有性能上的优势
- kerberos的用户管理很方便,只需要更新AD中的名单即可
- 当然整个过程的通信都是加密的,这里设计到两层加密,因为所有的认证都是通过client,也就是说kerberos没有和server直接交互,这样的原因是kerberos并不知道server的状态,也无法保证同时和server,client之间通信的顺序,由client转发可以让client保证流程顺序。
- 第一层加密,kerberos对发给server数据的加密,防止client得到这些信息篡改。
- 第二层加密,kerberos对发给client数据的加密,防止其他网络监听者得到这些信息。
2.3 client和server的通信原理
- 名词解释:
- Client master key: KDC中存储的Client的密钥
- Server master key: KDC中存储的Server的密钥
- Sclient-Server:Client与Serv3er之间的会话密钥
- Client Info:记录了Client本身的Ip等基本信息
- Client询问KDC,我想访问某个Server,然后KDC会将会话密钥Sclient-Server用Client master key加密后传送给Client;与此同时,KDC也会将会话密钥Sclient-Server连同Client的基本信息打包用Server master key加密也发给Client,并经Client转发给Server,至此Client与KDC的交互完成
- Client用自己的master key解密KDC传过来的第一个包,解密后获得会话密钥Sclient-Server,并用这个密钥加密自己的的信息和时间戳打包后传送给Server,此时Client开始和Server交互,如下图:
- Server会收到两个数据包,一个用会话密钥加密,一个用自己的master key加密,Server先用自己的master key解密获取会话密钥和一份关于Client的信息,然后Server拿到解密后获取到的会话密钥再解开另外一个数据包,获得另一份关于Client的信息和时间戳,至此Client和Server的交互完成。
- 下面我们解释下这样传输数据的原因,为什么传递这些数据
- 上面有个数据包是KDC经Client转发给Server的,为什么不直接发给Server?
因为Server可能给多个Client提供服务,这样Server需要维护一个Client和会话密钥的对应表,这对Server是一个负担。
此外,因为网络传输的不确定性可能Client和Server并不能都及时获取到会话密钥,假如有一方获取失败,那么Client就不能访问Server
- 为什么要发两份关于Client的信息给Server?
通过这两份数据的对比,Server就能判断出是不是对的Client在访问服务。
- Client是如何判断自己在访问对的Server呢?
因为Client给Server的一个数据包是用Server的master key来加密的所以只有对的Server才能解密。
- 为什么要用会话密钥
通信方的master key是长期有效的,如果在网络上传输,一旦被截取,理论上来说只要有足够的时间是可以破解的,所以我们才用临时的会话密钥来通信,一段时间后会话密钥会过期,同时时间戳也防止了,恶意用户重复使用同一个数据包。
- 为什么要用时间戳?
如果Client向Server传送的数据包被其他的Client截取,然后自己拿来向Server请求服务这,这样就会出问题,那么引入时间戳后,Server收到请求后将从解密后的数据包中获得的时间戳和当前时间对比,一旦超过一定范围将直接拒绝请求;所以,正如前面所说,Kerberos高度依赖时间同步服务。
说明:
事实上这个并不是Kerberos认证的整个过程,KDC实际上由AS和TGS两部分组成,你可以将TGS视作一个Server,然后还沿用上面所说的步骤来分析,这样就可以基本上梳理出Client访问Server的一个完整的过程了
3 Kerberos账户管理
3.1 DataIDE添加账户案例
- 操作步骤
- 登陆DataIDE后,点击目录树中的数据管理==》点击kerberos管理
- 填写相应的账户信息
- 到C70的FI集群中,找到系统配置=》权限配置=》用户管理
4. 点击右侧的下载标志,下载对应的keytab到本地,并解压
5. 将解压得到的key上传到页面中的keytab中
6. 权限设定:在FI集群中可以选择该账户的权限,根据每个账户的性质选择相应的权限,用户添加设置完成
3.2 理论
- Kerberos本身的数据库中不能查看密码的,也没,有保存账号=使用人等信息,所有的信息都需要以命令行的形式获取,管理起来极不方便,因此我们就开发了一套基于Django we,b框架的
- Kerberos账号管理系统(Kerberos Account Man,agement System,简称KAS),以此来提高管理员的工作效率,让管理员更有效、更有条理的管理Kerberos账号,KAS的基本组件如下:
- 权限管理模块
设定了用户,用户组等角色;admin,read等权限类型;并将Kerberos账号视作一种资源类型;这样就有了某个角色,拥有某种资源的某种权限的一种通用架构,所以,这个模块适用于各种资源管理系统。
2.工具管理模块
此模块包含了KAS需要的各种工具,例如KAS和Kerberos server交互的工具,邮件发送工具等。
3.账号申请模块
为了减少沟通成本,我们设计了用户提交申请,管理员审批的账户申请流程,在审批阶段用户和管理员可以对申请账号做出评论,并可以视情况对申请账号做出重新编辑,撤销申请等操作,一旦有人提交了申请,做出了评论,或者其他操作系统会发邮件通知管理员和用户,以便减少账号申请时间。
4.账号管理模块、
对于通过审批的账号,用户可以查看密码,导出账号keytab,查看账号owner等,对账号有admin权限的账户还可以将账号授权给他人使用,以此来减小管理员的工作量。
5.API模块
由于有一些特殊人员因为工作的需要,希望查看或者使用owner为其他人的账号,所以我们设计了API模块;当有人需要使用API接口时,需要向管理员申请将自己设为超级用户,同时超级用户需要维护一个自己的机器列表,只有在此机器列表包含的Host上才能使用API接口,此外超级用户还需要到系统中查看自己的auth_token,用于在使用API接口时做校验。
1.Replicate模块
Web端的增删改查等操作只是修改了MySQL数据库,此时我们需要Replicate模块将MySQL中的修改实时同步到Kerberos自己的数据库中。
2.机房间同步模块
当多个机房都需要使用Kerberos认证的时候,我们就需要机房间同步模块将主Server上的修改同步到其他机房中来保证数据的一致性。
3.备份模块
用于备份MySQL中和Kerberos Server中的数据以防数据丢失或者其他意外发生
4 KAS架构及数据流程
1Webserver向MySql中写数据并从中读数据,备处于只读状态
2MySql向Kerberos Server中写数据
3主Server中的MySql向备Server中的MySql同步数据
4主Kerberos Server向其他的Kerberos Server同步数据
5本机房中的认证请求、
5 KAS服务的安全以及高可用
- 对于Web Server我们采用了Keepalived vip漂移的方式来保证服务的高可用性,同一时刻只有一台Server工作,写MySQL数据库。
- 主Server上的Replicate模块会将MySQL中的修改实时同步到Kerberos Server中,又通过Rsync加密、增量传输的方式把主Server中的Kerberos数据库的更改同步到其他的Kerberos Server的数据库中(包括同机房的和不同机房的)。
- 通常一个机房中的Kerberos Server有两个,我们采用LVS或者Keepalived的方式保证服务的高可用。
- Web Server,Replicate模块等的进程我们用God的守护,以确保服务在异常停止后能自动拉起。
此外,由于Kerbeos是比较基础的服务,又比较敏感,所以我们还做了端口监控,机器级别的安全加固等。