kerberos认证管理

Kerberos: The Network Authentication Protocol

1   引言

1. 0编写目的

针对DataIDE和C70集群中均采用kerberos进行通讯安全认证，为方便日后对kerberos的学习，形成文档。

1. 1kerberos简介

Kerberos简单来说就是一个用于安全认证第三方协议，它采用了传统的共享密钥的方式，实现了在网络环境不一定保证安全的环境下，client和server之间的通信，适用于client/server模型，由MIT开发和实现。

1. 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的认证流程

1. 流程总体分为3步

1. client与AS交互
2. client与TGS交互
3. client与server交互

1. 详细分析

• 相比kerberos，https可能更为熟悉一点，通过证书和非对称加密的方式，让客户端可以安全的访问服务端，但这仅仅是客户端安全，通过校验，客户端可以保证服务端是安全可靠的，而服务端却无法得知客户端是不是安全可靠的。这也是互联网的一种特性。而kerberos可以支持双向认证，就是说，可以保证客户端访问的服务端是安全可靠的，服务端回复的客户端也是安全可靠的
• 想证明client和server都是可靠的，必然要引入第三方公证平台，这里就是AS和TGS两个服务

1. client向kerberos服务请求，希望获取访问server的权限。kerberos得到了这个消息，首先得判断client是否是可信赖的，也就是白名单黑名单的说法。这就是AS服务完成的工作，通过在AD中存储黑名单和白名单来区分client。成功后，返回AS返回TGT给client。
2. client得到了TGT后，继续向kerberos请求，希望获取访问server的权限。kerberos又得到了这个消息，这时候通过client消息中的TGT，判断出了client拥有了这个权限，给了client访问server的权限ticket
3. client得到ticket后，终于可以成功访问server。这个ticket只是针对这个server，其他server需要像TGS申请。

• 通过这3步，一次请求就完成了。当然这里会有个问题，这样也没比https快啊。解释一下

1. 整个过程TGT的获取只需要一次，其中有超时的概念，时间范围内TGT都是有效的，也就是说一般情况访问server只需要直接拿到ticket即可
2. 整个过程采用的是对称加密，相对于非对称加密会有性能上的优势
3. kerberos的用户管理很方便，只需要更新AD中的名单即可

• 当然整个过程的通信都是加密的，这里设计到两层加密，因为所有的认证都是通过client，也就是说kerberos没有和server直接交互，这样的原因是kerberos并不知道server的状态，也无法保证同时和server，client之间通信的顺序，由client转发可以让client保证流程顺序。

1. 第一层加密，kerberos对发给server数据的加密，防止client得到这些信息篡改。
2. 第二层加密，kerberos对发给client数据的加密，防止其他网络监听者得到这些信息。

2.3 client和server的通信原理

• 名词解释：

• Client master key: KDC中存储的Client的密钥
• Server master key: KDC中存储的Server的密钥
• Sclient-Server：Client与Serv3er之间的会话密钥
• Client Info：记录了Client本身的Ip等基本信息

1. Client询问KDC，我想访问某个Server，然后KDC会将会话密钥Sclient-Server用Client master key加密后传送给Client；与此同时，KDC也会将会话密钥Sclient-Server连同Client的基本信息打包用Server master key加密也发给Client，并经Client转发给Server，至此Client与KDC的交互完成
2. Client用自己的master key解密KDC传过来的第一个包，解密后获得会话密钥Sclient-Server，并用这个密钥加密自己的的信息和时间戳打包后传送给Server，此时Client开始和Server交互，如下图：

      

1. Server会收到两个数据包，一个用会话密钥加密，一个用自己的master key加密，Server先用自己的master key解密获取会话密钥和一份关于Client的信息，然后Server拿到解密后获取到的会话密钥再解开另外一个数据包，获得另一份关于Client的信息和时间戳，至此Client和Server的交互完成。

• 下面我们解释下这样传输数据的原因，为什么传递这些数据

1. 上面有个数据包是KDC经Client转发给Server的，为什么不直接发给Server？

因为Server可能给多个Client提供服务，这样Server需要维护一个Client和会话密钥的对应表，这对Server是一个负担。

此外，因为网络传输的不确定性可能Client和Server并不能都及时获取到会话密钥，假如有一方获取失败，那么Client就不能访问Server

1. 为什么要发两份关于Client的信息给Server？

通过这两份数据的对比，Server就能判断出是不是对的Client在访问服务。

1. Client是如何判断自己在访问对的Server呢？

因为Client给Server的一个数据包是用Server的master key来加密的所以只有对的Server才能解密。

1. 为什么要用会话密钥

通信方的master key是长期有效的，如果在网络上传输，一旦被截取，理论上来说只要有足够的时间是可以破解的，所以我们才用临时的会话密钥来通信，一段时间后会话密钥会过期，同时时间戳也防止了，恶意用户重复使用同一个数据包。

1. 为什么要用时间戳？

如果Client向Server传送的数据包被其他的Client截取，然后自己拿来向Server请求服务这，这样就会出问题，那么引入时间戳后，Server收到请求后将从解密后的数据包中获得的时间戳和当前时间对比，一旦超过一定范围将直接拒绝请求；所以，正如前面所说，Kerberos高度依赖时间同步服务。

说明：

事实上这个并不是Kerberos认证的整个过程，KDC实际上由AS和TGS两部分组成，你可以将TGS视作一个Server，然后还沿用上面所说的步骤来分析，这样就可以基本上梳理出Client访问Server的一个完整的过程了

3 Kerberos账户管理

3.1 DataIDE添加账户案例

    

• 操作步骤

1. 登陆DataIDE后，点击目录树中的数据管理==》点击kerberos管理
2. 填写相应的账户信息
3. 到C70的FI集群中，找到系统配置=》权限配置=》用户管理

     

  4. 点击右侧的下载标志，下载对应的keytab到本地，并解压

  

  5. 将解压得到的key上传到页面中的keytab中

    

6. 权限设定：在FI集群中可以选择该账户的权限，根据每个账户的性质选择相应的权限，用户添加设置完成

   

3.2 理论

• Kerberos本身的数据库中不能查看密码的，也没，有保存账号=使用人等信息，所有的信息都需要以命令行的形式获取，管理起来极不方便，因此我们就开发了一套基于Django we，b框架的
• Kerberos账号管理系统（Kerberos Account Man，agement System，简称KAS），以此来提高管理员的工作效率，让管理员更有效、更有条理的管理Kerberos账号，KAS的基本组件如下：

1. 权限管理模块

设定了用户，用户组等角色；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服务的安全以及高可用

1. 对于Web Server我们采用了Keepalived vip漂移的方式来保证服务的高可用性，同一时刻只有一台Server工作，写MySQL数据库。
2. 主Server上的Replicate模块会将MySQL中的修改实时同步到Kerberos Server中，又通过Rsync加密、增量传输的方式把主Server中的Kerberos数据库的更改同步到其他的Kerberos Server的数据库中（包括同机房的和不同机房的）。
3. 通常一个机房中的Kerberos Server有两个，我们采用LVS或者Keepalived的方式保证服务的高可用。
4. Web Server，Replicate模块等的进程我们用God的守护，以确保服务在异常停止后能自动拉起。

此外，由于Kerbeos是比较基础的服务，又比较敏感，所以我们还做了端口监控，机器级别的安全加固等。