大数据集群安全策略研究

张 彬，曹京卫，刘 果，李长连（.中讯邮电咨询设计院有限公司，北京 00048；.中国联通智网创新中心，北京 00033）

0 前言

随着《网络安全法》［1］和《国家网络空间安全战略》［2］的发布和实施，网络安全问题被提升到了国家战略高度。大数据平台作为用户核心业务和机密数据的载体，一方面要保证其平台内部的数据安全，另一方面，也要保障大数据平台与应用提供者之间的接口安全。

大数据平台建设大多采用分布式架构。作为大数据平台的标准解决方案，Hadoop 成为目前最流行的大数据分布式系统架构［3］，已广泛应用于各个大数据产品生态体系。Hadoop 平台由多个组件搭建而成，所以各个组件的安全共同影响并决定着大数据平台的安全。

目前，Hadoop 存在以下几个方面的安全问题：内部网络攻击或越权访问［5］；缺乏必要的安全认证机制；权限管理依赖Linux 账户的权限，控制能力较弱并且缺少细粒度的访问控制；缺乏统一的审计日志监控；无法保证数据传输安全。针对以上安全问题，本文从主机防火墙策略、Kerberos 用户认证和加密、Apache Ranger 细粒度权限控制和统一日志审计3 个方面，提出一套完整的大数据平台安全加固的解决方案。

1 安全加固方案

1.1 防火墙安全方案

传统的防火墙已经将外网和内网隔离开［4］，但实际上，80% 的攻击和越权访问来自内部网络［5］。大数据集群一般部署在内部网络，并且大多数厂商会租用数据基地的服务器来部署自己的集群。数据基地和外网有专业的防火墙做隔离，但是内网之间，各个厂商所租用的服务器都要接受数据基地综合监控平台的监管，并没有做到完全的资源隔离，不能排除内网员工恶意攻击或者做一些不恰当的操作。此时就需要依赖服务器操作系统的主机防火墙来阻断内网中其他服务器的非法访问。

Hadoop 集群部署时，各个节点需要完全互信，并且集群运行时，各个服务占用端口比较多，集群在高负荷运行时，开启防火墙会影响集群的整体性能，所以官方文档建议所有主机关闭防火墙。但是，数据安全是提供任何服务的前提，遵循“默认拒绝，最小放开”的原则，在不影响服务通信的前提下，集群内所有服务器开启主机防火墙。对Hadoop 集群内开放所有IP 和端口访问权限；对集群外的主机，只开放某些IP下的具体服务端口访问权限。以HDFS和Kafka为例。

a）HDFS 客户端访问HDFS 服务：对客户端放开用于获取文件系统Metadata 信息的8020 端口（coresite.xml 配置文件中参数fs.default.name namenode）；对客户端放开用于数据传输的所有DateNode 节点的50010端口（hdfs-site.xml配置文件中参数dfs.datanode.address）。

b）Kafka 生产者或者消费者访问Kafka 集群：对客户端放开Kafka 集群所有节点之间通信的RPC 端口9092（server.properties 配置文件中参数listeners 或者advertised.listeners）；对客户端放开连接Zookeeper 的端口2181（server.properties 配置文件中参数zookeeper.connect）。

主机防火墙作为网络侧细粒度的访问控制机制，能够有效阻止主机外任何外网或者内网节点的非法访问。

1.2 用户认证和加密方案

用户身份认证是对访问者身份进行识别并确认的过程，是数据访问控制的基础，同时也是实现大数据安全架构的基础。Hadoop 集群默认采用基于操作系统账号的Simple 认证，没有安全性保证，用户只需在客户端的操作系统上建立一个同名账号，即可伪装成任何用户访问集群［6］，一旦拥有Hadoop 用户权限，便能随意查看、复制HDFS 上的内容，或者进行其他操作［7］。Kerberos 作为一种可信的第三方认证服务［8］，无需主机操作系统认证，在非安全网络通信中，可使用Kerberos 通过共享密钥的方式向另一个实体表明其身份信息［9］。

1.2.1 Kerberos认证机制

使用Kerberos 时，一个客户端需要通过以下4 个步骤来获取服务。

a）认证：客户端向认证服务器（AS）发送服务请求。

b）授权：AS生成2个票据（Ticket）返回给客户端，一个用客户端密钥加密，另一个用服务端密钥加密。

c）服务请求：客户端向服务器出示服务Ticket，证实自己的合法性。

d）验证服务器：服务器给客户端回复一条消息，客户端比较服务器返回的时间戳是否一致，来验证服务器的真实性。

Kerberos 支持单点登录，即当客户端通过了Kerberos的认证后，便可以访问多个服务实体。

1.2.2 Kerberos服务高可用方案

在实际生产环境中，集群规模都比较大，部署单个节点的Kerberos 认证服务往往会出现单点故障问题。对于一个启用了Kerberos 服务的Hadoop 集群来说，KDC 的高可用是必须要考虑的。Kerberos 服务支持一主多备的模式，通过kprop 服务将主节点的数据同步到各个备节点。Kerberos 服务高可用认证系统架构如图1所示。

图1 Kerberos高可用架构

Kerberos 中每个KDC 都包含数据库的副本。主KDC 包含域（Realm）数据库的可写副本，它以固定的时间间隔复制到从KDC 中。所有数据库更改（例如密码更改）都在主KDC 上进行，当主KDC 不可用时，从KDC 提供Kerberos 票据给服务授权，但不提供数据库管理。

Kerberos 的同步机制只复制主数据库的内容，相关配置文件必须手动复制到每个Slave 中，Kerberos 服务配置高可用的主要步骤如下。

a）主备节点安装Kerberos服务。

b）主节点Kerberos配置文件修改。

c）主节点配置文件拷贝至备节点。

d）主节点数据同步至备节点并配置同步任务。

Kerberos 高可用服务为Hadoop 提供了较强的认证及授权保护，所有节点必须通过认证确认身份后才能访问集群资源，有效避免了针对Hadoop集群的恶意使用或篡改。

1.2.3 Kerberos数据加密

客户端和服务端相互认证阶段使用的是长期密钥，而认证结束后，客户端和服务端都会获取到认证服务器随机生成的临时会话密钥，此密钥将作为临时通信密钥来加密需要传输的内容，一段时间后会话密钥会过期，需要重新申请，这样保证了数据传输的安全性。

1.3 Ranger权限管理和日志审计方案

大数据集群中各个组件的访问权限控制都依赖于HDFS 分布式文件系统的权限控制。HDFS 的权限设计基于POSIX 模型，权限划分为用户、用户组以及其他用户的读写执行权限。每个用户使用不同的Linux 账户便能访问到相应文件。若用户已获得HDFS NameNode 地址和端口号，在HDFS 客户端安装完成后，使用与NameNode 相同的用户名，即可获得任意文件的访问权限，这就无法保证各个组件的数据安全性。

Apache Ranger 作为一个集中式安全管理框架，能为Hadoop 生态组件提供操作、监控、管理复杂数据权限的能力［10］，并且可以对用户的行为日志进行统一的审计管理［11］。

1.3.1 Ranger权限管理

细粒度权限管理在数据级别没有共性，不同的组件对应的业务资源是不一样的，细粒度权限控制如表1所示。

表1 细粒度权限控制表

Ranger 基于策略来抽象出用户、资源以及权限之间的关系，从而进一步延伸并形成自己的权限模型。

用户：用用户（User）或者用户组（Group）来表示。

资源：用（服务，策略）二元组来表示；一条策略对应一个服务，并且是唯一对应，但一个服务可以对应多个策略。

权限：用（AllowACL，DenyACL）二元组来表示，AllowACL代表允许执行，DenyACL中则代表拒绝执行。

用户访问决策树如图2所示。

图2 访问决策树

一条策略有4 组决策项：allow、allowException、deny、denyException，优先级由高到低依次是：denyException、deny、allowException、allow。如果没有策略能决策访问，一般情况是认为没有权限拒绝访问，此时Ranger会将决策下放给系统自身的访问控制层，如HDFS 分布式文件系统的权限控制层。

1.3.2 Ranger Audit日志审计

大数据集群各个组件都可以配置审计日志，这些审计日志会以文件的方式存储在各个节点上，查询审计日志比较繁琐，不利于追踪、定位用户发起的任务。

Ranger在控制访问权限的同时会记录所有用户访问集群资源的行为并写入日志，这些审计日志统一存储在HDFS 文件系统中。Ranger 提供一个统一的审计管理平台来展示和统计这些审计日志，审计管理包含以下6个部分。

a）Access：Access 页为管理员提供所有已开启审计策略的服务活动数据，记录用户试图访问资源的行为和决策结果（允许或者拒绝）。

b）Admin：Admin 选项卡记录管理员操作Ranger Web UI 的所有事件，包括创建、删除、修改策略等操作。

c）Login Sessions：Login Sessions 页面记录每个用户登录Ranger Web UI的会话信息。

d）Plugins：插件选项卡显示安全代理的上载历史，用于检查组件是否成功地与Ranger通信。

e）Plugin Status：插件状态选项卡显示每个插件的有效策略，包括相关的主机信息以及插件下载和开始执行策略的时间。

f）User Sync：用户同步页面记录从Unix 或LDAP同步的用户和组信息，默认1 min同步1次。

通过Ranger 审计管理界面可以看到详细的用户操作日志信息，方便管理员监控、查询用户的历史操作，做到有证可查。

2 安全加固方案部署

2.1 防火墙策略部署

本节以访问HDFS 文件系统为例对防火墙策略部署进行说明，具体如图3所示。

图3 数据采集拓扑图

假设数据采集区的采集服务器从公网采集过来的数据要写入核心数据区的HDFS 文件系统，首先要开放kerberos 服务的kdc 端口88 和admin_server 端口749，用作kerberos 用户认证，其次需要核心数据区的NameNode 节点对数据采集区开放用于获取文件系统Metadata 信息和接收Client 端RPC 连接的端口8020，另外还要对数据采集区的节点开放所有DateNode 的50010 端口，此端口是DateNode 服务端口，用于数据传输。

以“默认拒绝，最小放开”的原则，既能保证用户的访问，又最大限度地保证网络安全。

2.2 Kerberos认证部署

为了确保Hadoop 集群的安全，集群内每个节点都必须设置Kerberos 认证。首先，选择安全且独立的节点安装并配置Kerberos 服务；然后，将集群中所有服务、节点和用户标识都保存至Kerberos 数据库中；最后，修改所有节点的Hadoop 配置，配置文件中加入Kerberos 认证，方可启动Hadoop 集群。详细配置流程如下。

a）安装KDC，选择2 个独立节点进行安装，要保证绝对安全；在安装成功后，需要修改3 个配置文件：krb5.conf、kdc.conf 和kadm5.acl，包括配置KDC 所在的位置、管理服务器、主机名与Kerberos 领域名之间的映射等。最后，在所有节点上安装Kerberos客户端。

b）配置Hadoop 服务标识。在KDC主节点中分别创建HDFS、Mapred、Yarn 三者的对应标识，以确保Kerberos 认证Hadoop 的守护进程，然后创建HTTP 服务标识。

c）为Hadoop 服务创建Keytab 文件。Keytab 文件中包含1 个键值对：Kerberos 标识、基于Kerberos 密码生成的加密密钥。该文件的作用是当服务在后台运行时，在没有人机交互的情况下进行认证。

d）启用KDC主节点kprop服务将主节点的数据同步到KDC备节点。

e）向集群节点分发Keytab 文件。每个节点都需要创建相应的Keytab 文件，在创建完成后需将Keytab文件移动到节点的/etc/hadoop/conf目录。

f）修改Keytab 文件权限，确保Keytab 文件的所有者才可以进行查看。

g）设置Hadoop 配置文件，Kerberos 生效。在更新配置文件前，要先关闭集群，并重新设置core-site.xml和hdfs-site.xml配置文件。

在Hadoop 开源社区提供的大数据平台框架上部署Kerberos 认证服务较为复杂，如果使用Ambari 搭建的HDP 集群，部署Kerberos 认证会简便很多。Ambari服务会自动为Hadoop 集群中的服务创建用户密钥和Keytab文件，并协助用户修改Hadoop配置文件。

2.3 Ranger权限管理和日志审计部署

Apache Ranger 是Hadoop 生态中的安全管理框架，主要由Hortonworks 开源和维护，和Hortonworks HDP 结合得比较好，通过Ambari 服务，用户可以直接安装Ranger 服务和相关插件。使用原始的方式部署Ranger，需要从官网下载源码手动编译，并修改大量的配置文件。简单介绍一下使用Ambari 集成Ranger 服务的注意事项。

a）Ranger 服务需要依赖第三方的数据库如MySQL、Oracle、Postgres 等，建议使用集群依赖的存储元数据的数据库。

b）Ranger服务节点需要安装数据库客户端。

c）建议在数据库中提前创建好Ranger管理用户、密码和database。

d）如果使用MySQL 作为数据库，请修改MySQL配置文件my.cnf，添加skip_ssl 来关闭SSL 验证，修改后重启MySQL服务

e）执行ambari-server setup 指定配置Ambari-Server的JDBC驱动信息。

f）Ranger deny 策略默认不会启用，如果需要启用，需要在Ranger部署完后在Ambari中Ranger配置下添加：ranger.servicedef.enableDenyAndExceptionsInPolicies=true。

使用Ambari 管理界面配置Ranger 服务较为简单，这里不再介绍。

3 方案实验验证

3.1 实验目的

通过Hadoop 客户端上传数据文件到HDFS 文件系统模拟数据采集流程，验证本文大数据平台加固方案的安全性，用户访问控制需满足如图4所示的流程。

图4 用户访问控制流程图

3.2 实验环境

使用3 台虚拟机组成的Ambari HDP 集群作为验证环境，另外1台虚拟机模拟数据采集服务器访问Hadoop 集群，实验环境和实验拓扑如表2 和图5 所示。

表2 实验环境

图5 实验拓扑图

3.3 实验操作步骤

实验操作步骤如下。

a）集群内的3 台服务器全部开启主机防火墙，默认拒绝所有节点访问。增加访问策略如下：集群内的3台服务器可互访；允许采集服务器data1访问hdp1和hdp2 中的Kerberos 认证端口88 和749；允许采集服务器data1 访问hdp1 的8020 和50010 端口；允许采集服务器data1访问hdp2和hdp3的50010端口。

b）为采集服务器data1 部署hadoop 客户端，保证其能正常访问执行HDFS命令。

c）为采集服务器data1 新增Kerberos 认证用户hdfstest，并生成Keytab 文件；同时将Keytab 文件拷贝到data1节点。

d）使用hdfs用户登录hdp1节点，创建HDFS目录/hdfstest，并修改权限为700。

e）登录Ranger 管理界面，新增Ranger 内部用户hdfstest并添加至用户组hadoop。

f）新增hdfstest 用户访问策略，允许访问/hdfstest目录的读写权限。

3.4 验证方式及实验结果

在主机防火墙启用但未开放端口策略的前提下，执行HDFS 上传文件命令到/hdfstest 目录失败，无法访问目标主机；采集服务器data1节点在没有使用Kerberos认证的情况下，执行HDFS上传文件命令到/hdfstest目录，访问失败，没有有效的证书；禁用Ranger 内部用户hdfstest 的访问策略，使用Kerberos 分配的证书认证后，能够识别用户身份，但用户没有权限访问/hdfstest目录；启用Ranger 内部用户hdfstest 的访问策略，使用Kerberos 分配的证书认证后，上传文件到/hdfstest 目录成功；停掉主KDC 的进程，使用Kerberos 分配的证书认证后，上传文件到/hdfstest目录成功。

实验结果满足图4中用户访问控制流程。在停掉主节点KDC 进程后，客户端仍然能够通过Kerberos 认证并上传数据文件，验证了KDC 的高可用性；登录Ranger管理界面后，能够看到详细用户访问审计日志，方便管理员监控、查询用户的历史操作。

实验结果符合预期目标，验证了方案的可行性和有效性，并且该方案已应用到实际生产环境中，能够满足大数据平台的安全需求。

4 结束语

随着Hadoop生态系统的广泛应用，安全漏洞日益增多，本文从主机防火墙策略、Kerberos 用户认证和加密、Apache Ranger 细粒度权限控制和统一日志审计3个方面，提出一套完整的大数据平台安全加固的解决方案，并通过实验验证该方案的可行性与有效性。下一步将研究针对大数据平台的系统风险评估和安全预警，并提出相应的安全加固方案。