信息安全理论：

CIA模型：机密性、完整性和可用性

CIA模型能够帮助建议一些信息安全原则，但该模型并不是一个需要严格遵守的规则

hadoop平台可能设计多个CIA模型组件，也kennel一个也不涉及

机密性：

信息只应该被期望的接收者看到

身份标识：唯一标识消息传递者

身份验证：证明自己的身份

加密：将数学算法应用于信息片段，使加密后输出内容对于非预期接收者不可读

解密：只有期望的接收者能对加密消息进行解密，从而得到原始信息

完整性：

保证发送方发送的信息和接收分接收的完全一致

可用性：

数据能够被准确送达，不会丢失

验证、授权和审计(AAA)：

指计算机安全领域的一个架构模式，在该模式中，使用服务的用户要证明自己的身份，然后规则规则被授予权限，同时其操作被记录下来留待审计。

身份：指系统如何将不同的实体、用户和服务区分开来

linux系统：

验证：/etc/passwd

授权：/etc/sudoers、/etc/group

审计：/var/log/secure

统一身份认证管理：

在开源大数据平台中，用户可能需要同时使用很多开源组件，因此会涉及到每个组件的身份认证和访问权限等问题。利用统一的认证服务能够更好的管理用户的身份认证及会话管理等。

在大数据平台中通过统一用户管理系统,可以实现平台中的各种开源组件应用系统的用户、角色和组织机构统一化管理，实现各种应用系统间跨域的单点登录登出和统一的身份认证功能。

统一身份认证系统的主要功能特性如下：

用户管理

用户认证

单点登录

分级管理

权限管理

会话管理

兼容多种操作系统

目前，绝大多数厂商的统一认证管理系统都是由统一认证管理模块、统一身份认证服务、身份信息存储服务器三大部分组成。

在华为大数据解决方案中，我们通过基于开源的OpenLDAP的身份认证的管理和存储技术以及Kerberos统一身份认证技术，实现了一种能够通过WebUI进行集群中的数据与资源访问控制权限管理

kerberos：

kerberod是麻省理工学院开发的一个认证机制，该系统设计上采用客户端/服务器结构与DES，AES等加密技术，并且能够进行互相认证，即客户短和服务端均对对方进行身份认证。客户端需要确认即将访问的网络服务就是自己所想要访问的服务而不是一个伪造的服务器，而服务端需要确认这个客户端是一个身份真实，安全可靠的客户端，而不是一个想要进行恶意网络攻击的用户。

Kerberos核心三要素：

krbServer认证机制的核心工作是使用一种能够证明用户身份的票据(密钥)，保护集群免受窃听和攻击。

kerberos client: 发送请求的一方

kerberos kdc server: 接收请求的一方

kdc(key distribution center): 有两个部分，分别是：

AS(Authentication Server)：认证服务器，专门用来认证客户端的身份并发放客户用于访问TGS的TGT（授予票据)

TGS(Ticket Granting ticket): 票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据。

kerberos 术语：

主体(principal):

kerberos中的身份标识，每个参与kerberos认证协议的用户和服务都需要一个主体来唯一地表示自己。

用户主体(UPN)：

代表常规用户，类似于操作系统中的用户名

<短名称><@域>

<短名称>/admin@<域>

服务主体<SPN>:

代表用户需要访问的服务，例如特定服务器上的数据库

<短名称>/<主机名>@<域>

域(realm):

就是一个身份验证管理区域，所有主体都被分配到特定的kerberos域，域确定了边界，使得管理更为容易。

密钥分发中心(KDC):

kerberos数据库：存储主体及其所属域的所有相关信息

认证服务(AS)：当客户端向AS发起请求时，向客户端发放票据授予票据TGT用于请求访问其他服务

票据授予服务(TGS)：负责验证票据许可票据(TGT), 并授予服务票据(ST)。服务票据允许认证过的主体使用应用服务器提高的服务，该服务通过SPN进行标识。

EXAMPLE.COM：Kerberos域

zph：一个系统用户，其UPN为zph@EXAMPLE.COM

myservice：server1.example.com上运行的一个服务，其SPN为myservice/server1.example.com@EXAMPLE.COM

kdc.example.com：Kerberos域EXAMPLE.COM的KDC

kerberos工作流程：

简化流程：

在这里插入图片描述

1、客户端向KDC请求获取想要访问的目标服务的服务授予票据(Ticket)；

2、客户端拿着从KDC获取的服务授予票据(Ticket)访问相应的网络服务

上面简化了kerberos的认证流程，大致分为两步，虽然只有两步，但是其中还是有一些问题问题：

(1) KDC怎么知道你(客户端)就是真正的客户端？凭什么给你发放服务授予票据(Ticket)呢？
(2) 服务端怎么知道你带来的服务授予票据(ticket)就是一张真正的票据呢？

kerberos认证过程中的第一步做了两件事，这两件事解决了上述问题中的问题1，然后第二部解决了问题2，最终结束认证过程建立通信。

因此kerberos认证流程可以细化为三个阶段，也可以理解为三次通信，接下来从三个阶段三次通信角度细说认证过程。

Kerberos认证流程：

在这里插入图片描述

kerberos认证前提条件：

1、kerberos协议是一个”限权“的认证协议，kerberos中会自带一个数据库，数据库会由创建kerberos的运维人员提前在库中添加好整个系统中拥有使用kerberos认证权限的用户和网络服务。在后续的认证中也是根据数据库中是否存在该用户和服务来判断该对象是否能够通过认证服务的。

2、所有使用kerberos协议的用户和网络服务，在他们添加到kerberos系统时，都会根据自己当前的密码生成一把密钥存储在kerberos数据库红，且kerberos数据库也会同时保存用户的基本信息(用户名，用户ip地址)和网络服务的基本信息(ip)

3、kerberos中存在的三个角色，只要发生两两之间的通信，那都需要先进行身份认证。

第一次通信：

在这里插入图片描述

为了获得能够用来访问服务端服务的票据，客户端首先需要来到KDC获得服务授予票据(Ticket)。由于客户端是第一次访问KDC，此时KDC也不确定该客户端的身份，所以第一次通信的目的为KDC认证客户端身份，确认客户端是一个可靠且拥有访问KDC权限的客户端，过程如下：

1、客户端用户向kdc以明文的方式发起请求，该请求携带自己的用户名、主机ip和当前时间戳

2、kdc中的AS接收请求后去kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性。(AS是KDC中专门用来认证客户端身份的认证服务器)

3、如果没有用户名，认证失败，服务结束，如果存在该用户名，则AS认证中心认为用户存在，此时便返回客户端，其中包含两部分内容：

第一部分为TGT，票据授予票据，客户端需要使用TGT去kdc中的TGS获取访问网络服务所需的Ticker(服务授予票据),TGT中包含的内容有kerberos数据库中存在的该客户端name、ip、当前时间戳、客户端即将访问的TGS的name，TGT的有效时间以及一把用户客户端和TGS间进行通信的session_key(CT_SK)。整个TGT使用TGS密钥加密，客户端解密不了，由于密钥没有在网络中传输过，所以不存在密钥被劫持破解的情况。

第二部分是使用客户端密钥加密的一段内容，其中包括用户将客户端和TGS间通信的CT_SK，客户端即将访问的TGS的name以及TGT的有效时间、当前时间戳。该部门内容使用客户端密钥加密，所以客户端难道该部门内容可以通过密钥解密。如果是一个假的客户端，那么他不会拥有真正客户端的密钥，因为密钥也没有在网络中传输过。这就认证了客户端的身份，如果是假客户端会犹豫解密失败从而终端认证流程。

至此，第一次通信完成。