大数据安全之kerberos+ldap身份验证(理论篇)

大数据安全

1、限制只有合法用户身份的用户访问大数据平台集群
（1） **用户身份认证：**外部用户或者第三方服务对集群的访问过程中的身份鉴别；用户在访问启用了安全认证的集群时，必须能通过安全认证。
（2）**网络隔离：**大数据平台集群支持通过网络平面隔离的方式保证网络安全（比如配置防火墙）。

2、定义什么样的用户和应用可以访问数据
权限控制：包括鉴权、授信管理，即确保用户对平台、接口、操作、资源、数据等都具有相应的访问权限，避免越权访问；分级管理，即根据敏感度对数据进行分级，对不同级别的数据提供差异化的流程、权限、审批要求等管理措施，数据安全等级越高，管理越严格。
（比如不同的应用，其对应的文件夹设置权限，赋予不同的用户不同的权限。）

3、数据加密和脱敏；多租户隔离；数据侵权保护；容灾管理
（1）数据加密：提供数据在传输过程及静态存储的加密保护，使得敏感数据被越权访问时仍然能够得到有效保护。此外，加解密对上层业务透明，上层业务只需指定敏感数据，加解密过程业务完全不感知。
（2）用户隐私数据脱敏：数据脱敏和个人信息去标识化。
（3）多租户隔离：实施多租户访问隔离措施，实施数据安全等级划分，比如基于标签的强制访问控制，基于ACL的数据访问授权模型。
（4）数据容灾：为集群内部数据提供实时的异地数据容灾功能，例如Google的spanner作为NewSQL数据库对外提供跨数据中心的容灾机制。
（5）数据侵权保护：当存储数据为一种特殊的数字内容产品时，其权益保护难度远大于传统的大数据，一旦发生侵权问题，举证和追责过程都十分困难。大数据平台底层能利用区块链类似技术实现数据的溯源确权。
[
物理安全(自然灾害，操作人员，机房环境);
主机安全（数据自身存储和处理的安全，系统，默认设置，软硬件）；
网络安全（防火墙，第三方网络认证协议——kerbros）；
应用安全（应用数据隔离等）
]

什么是kerberos

引自：维基百科-kerberos

Kerberos（/ˈkərbərəs/）是一种计算机网络授权协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。这个词又指麻省理工学院为这个协议开发的一套计算机软件。软件设计上采用客户端/服务器结构，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证。可以用于防止窃听、防止重放攻击、保护数据完整性等场合，是一种应用对称密钥体制进行密钥管理的系统。Kerberos的扩展产品也使用公开密钥加密方法进行认证。
Kerberos的3个头颅代表中认证过程中涉及的3方：Client、Server和KDC。

补充：
1.对称密钥体制:加密和解密都使用同一个密钥
2.公开密钥加密:也称为非对称加密，它需要两个密钥，一个是公开密钥，另一个是私有密钥；一个用作加密的时候，另一个则用作解密。使用其中一个密钥把明文加密后所得的密文，只能用相对应的另一个密钥才能解密得到原本的明文；甚至连最初用来加密的密钥也不能用作解密。

我们常用的SSH就是这样的加密方式，关于SSH以及SSH免密登录不再赘述，可参考阮一峰的这篇文章

kerbros缺陷：

失败于单点：它需要中心服务器的持续响应。当Kerberos服务宕机时，没有人可以连接到服务器。这个缺陷可以通过使用复合Kerberos服务器和缺陷认证机制弥补。
Kerberos要求参与通信的主机的时钟同步。票据具有一定有效期，因此，如果主机的时钟与Kerberos服务器的时钟不同步，认证会失败。默认设置要求时钟的时间相差不超过10分钟。在实践中，通常用网络时间协议后台程序来保持主机时钟同步。

kerberos基本概念

场景：
咱们想调用Hadoop的API，读取Hdfs的数据，我们就需要借用kerbros第三方组件来进行验证。

**KDC：**密钥分发中心（Kerberos Distribution Center-KDC）。KDC在整个Kerberos Authentication中作为Client和Server共同信任的第三方起着重要的作用，而Kerberos的认证过程就是通过这3方协作完成
KDC分发SServer-Client的简单的过程：[2]

首先Client向KDC发送一个对SServer-Client的申请。这个申请的内容可以简单概括为“我是某个Client，我需要一个Session Key用于访问某个Server ”。KDC在接收到这个请求的时候，生成一个Session Key，为了保证这个Session Key仅仅限于发送请求的Client和他希望访问的Server知晓，KDC会为这个Session Key生成两个Copy，分别被Client和Server使用。然后从Account database中提取Client和Server的Master Key分别对这两个Copy进行对称加密。对于后者，和Session Key一起被加密的还包含关于Client的一些信息。

TGT:（ticket-granting ticket）一个有限的有限期的小型加密标识文件,是一个用于与KDC服务器建立安全会话的票据。TGT文件包含会话密钥，到期日期和用户的IP地址等信息。

**Princal(安全个体)：**被认证的个体，有一个名字和口令

AS (Authentication Server)： 认证服务器

TSG(Ticket Granting Server)： 许可证服务器

三个子协议：
Kerberos整个认证过程通过3个sub-protocol来完成。这个3个Sub-Protocol分别完成上面列出的3个子过程。这3个sub-protocol分别为：

• Authentication Service Exchange
• Ticket Granting Service Exchange
• Client/Server Exchange

kerberos认证原理，过程

1.客户端A想访问server B，首先需要向KDC发送请求，请求中附上自己的信息，申请TGT（Ticket Granting Ticket）；
2.KDC是一个“大家”都信任的第三方，KDC检验【KDC还负责身份验证功能，(Authentication Server)】通过后将加密的TGT发给客户端A；
3.客户端A通过拿到的TGT，向KDC请求其他Service的Ticket，从而通过其他Service的身份鉴别

详细过程（源自参考[2]）:

1.Authentication Service Exchange

通过这个Sub-protocol，KDC（确切地说是KDC中的Authentication Service）实现对Client身份的确认，并颁发给该Client一个TGT。具体过程如下：

Client向KDC的Authentication Service发送Authentication Service Request（KRB_AS_REQ）, 为了确保KRB_AS_REQ仅限于自己和KDC知道，Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密（KDC可以通过Domain 的Account Database获得该Client的Master Key）。KRB_AS_REQ的大体包含以下的内容：

• Pre-authentication data：包含用以证明自己身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。一般地，它的内容是一个被Client的Master key加密过的Timestamp。
• Client name & realm: 简单地说就是Domain name\Client
• Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，而我们也说了TGT是和Server无关的（Client只能使用Ticket，而不是TGT去访问Server）。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name。

AS（Authentication Service）通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法的Timestamp，则可以证明发送放提供的是正确无误的密码。验证通过之后，AS将一份Authentication Service Response**（KRB_AS_REP）发送给Client**。KRB_AS_REQ主要包含两个部分：本Client的Master Key加密过的Session Key（SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大体又包含以下的内容：

• Session Key: SKDC-Client：Logon Session Key
• Client name & realm: 简单地说就是Domain name\Client
• End time: TGT到期的时间。

Client通过自己的Master Key对第一部分解密获得Session Key（SKDC-Client：Logon Session Key）之后，携带着TGT便可以进入下一步——TGS（Ticket Granting Service）Exchange。

2.TGS（Ticket Granting Service）Exchange

TGS（Ticket Granting Service）Exchange通过Client，向KDC中的TGS（Ticket Granting Service）发送Ticket Granting Service Request（KRB_TGS_REQ）。
KRB_TGS_REQ大体包含以下的内容：

• TGT：Client通过AS Exchange获得的Ticket Granting Ticket，TGT被KDC的Master Key进行加密。
• Authenticator：用以证明当初TGT的拥有者是否就是自己，所以它必须以TGT的办法方和自己的Session Key（SKDC-Client：Logon Session Key）来进行加密。
• Client name & realm: 简单地说就是Domain name\Client。
• Server name & realm: 简单地说就是Domain name\Server，这回是Client试图访问的那个Server。

TGS收到KRB_TGS_REQ在发给Client真正的Ticket之前，先得整个Client提供的那个TGT是否是AS颁发给它的。于是它不得不通过Client提供的Authenticator来证明。但是Authentication是通过Logon Session Key（SKDC-Client）进行加密的，而自己并没有保存这个Session Key。所以TGS先得通过自己的Master Key对Client提供的TGT进行解密，从而获得这个Logon Session Key（SKDC-Client），再通过这个Logon Session Key（SKDC-Client）解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response（KRB_TGS_REP）。这个KRB_TGS_REP有两部分组成：
使用Logon Session Key（SKDC-Client）加密过用于Client和Server的Session Key（SServer-Client），和使用Server的Master Key进行加密的Ticket。该Ticket大体包含以下一些内容：

• Session Key：SServer-Client。
• Client name & realm: 简单地说就是Domain name\Client。
• End time: Ticket的到期时间。

Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后获得Session Key（SServer-Client）。有了Session Key和Ticket，Client就可以之间和Server进行交互，而无须在通过KDC作中间人了。所以我们说Kerberos是一种高效的认证方式，它可以直接通过Client和Server双方来完成，不像Windows NT 4下的NTLM认证方式，每次认证都要通过一个双方信任的第3方来完成。

我们现在来看看 Client如果使用Ticket和Server怎样进行交互的，这个阶段通过我们的第3个Sub-protocol来完成：CS（Client/Server ）Exchange。

3.CS（Client/Server ）Exchange

Client通过TGS Exchange获得Client和Server的Session Key（SServer-Client），随后创建用于证明自己就是Ticket的真正所有者的Authenticator，并使用Session Key（SServer-Client）进行加密。最后将这个被加密过的Authenticator和Ticket作为Application Service Request（KRB_AP_REQ）发送给Server。除了上述两项内容之外，KRB_AP_REQ还包含一个Flag用于表示Client是否需要进行双向验证（Mutual Authentication）。

Server接收到KRB_AP_REQ之后，通过自己的Master Key解密Ticket，从而获得Session Key（SServer-Client）。通过Session Key（SServer-Client）解密Authenticator，进而验证对方的身份。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。

对于需要进行双向验证，Server从Authenticator提取Timestamp，使用Session Key（SServer-Client）进行加密，并将其发送给Client用于Client验证Server的身份。

---

LDAP

LDAP是轻量目录访问协议，英文全称是Lightweight Directory Access Protocol。LDAP目录以树状的层次结构来存储数据。【在UNIX文件系统中，最顶层是根目录（root）。在根目录的下面有很多的文件和目录。象上面介绍的那样，LDAP目录也是用同样的方法组织起来的。】
LDAP中有个概念需要明白：目录记录的标识名（数据唯一标识符）—>DN

LDAP属性：
以下是常用的属性名和它代表的意义(在LDAP中属性名大小写不敏感)：

CN ----->常用名称，常常是DN的一部分
L ----->地名，通常是城市的名称
ST ----->直辖市或省的名称
O ----->组织名称
OU ------>组织单位
C ------>国家名称
STREET –>街道地址
DC ------>域名成分
UID ------>用户标识

kerberos认证应用场景

在安全模式集群中，访问集群的任意资源，都需要经过kerbros的认证。

LDAP在CDH中的实践

这里的LDAP指的openldap
这部分过些时间我一定会在真实的集群上实践，实践后，文章会单独记录。

kerbros在CDH中的实践

这部分过些时间我一定会在真实的集群上实践，实践后，文章会单独记录。
标记一篇文章（其实该博主有几篇kerbros的文章），该文章貌似是不借助平台，手动搭建实现的。基于CDH搭建之前，看一看应该会学到更多？
文章：https://blog.csdn.net/forever19870418/article/details/68922707

参考

[1]博客园——大数据平台安全标准设计
[2]kerberos认证原理
[3]博客园——LDAP概念
[4]centos6.5环境openldap实战之ldap配置详解及web管理工具lam

---

---

---

小生目前山西大学大三学生，最近计划实习，主要学习大数据，J2EE，机器学习。

同道的前辈，师兄弟姐妹们，欢迎扫码加微（/抱拳\）。或指点一二，或共同探讨学习！

文章的不妥之处，欢迎各位前辈斧正！