大数据平台Hadoop 的安全机制 本章学习目标 . 了解Hadoop的安全机制 . 理解Hadoop组件的安全机制 . 分析Hadoop的安全性 . 掌握Hadoop的安全架构 Hadoop是常用的大数据处理平台,其安全性对于业务数据处理尤为重要。本章主 要向读者介绍Hadoop的安全机制、Hadoop组件的安全机制、安全技术工具、Hadoop的 安全性分析,并对其安全架构进行阐述。 3.1 安全威胁概述 Hadoop是Apache旗下基于Java语言实现的开源大数据计算处理框架,允许使用简 单的编程模型在计算机集群上对大型数据集进行分布式处理。正因为Hadoop在处理大 数据方面具有高效性、高容错性、高可扩展性和低成本等优势,当前许多企业或机关事业 单位等都采用Hadoop来存储和处理海量数据。Hadoop由于自身的业务特点,一般都部 署在用户内网中,所以在早期设计的时候不是太注重安全方面的设计,而更多的是专注于 实现业务的功能。下面是网上报道过的关于其安全漏洞的案例。 Apache的Ambari引用给Hadoop带来了很多便利,可以直接通过外部的管理对 Hadoop的生态组件进行管控,但在这个过程中由于外部技术的引用,导致一些外部应用 层的漏洞,主要是SSRF伪造请求漏洞。恶意攻击者通过SSRF攻击,远程对Hadoop服 务以及进程进行操纵和读取数据。 MapReduce信息漏洞主要是由于数据文件、用户产生的数据以及加密密钥都存储在 同一个文件和磁盘中,导致恶意用户获取到加密密钥,并读取了数据块中的数据。 Ambari重定向漏洞是由于target的URI参数被修改成了黑客指定的任意网址,由 此造成钓鱼攻击,甚至结合Linux底层的操作系统漏洞以及Hadoop的其他漏洞还能实 现恶意代码的加载。 2017年,Hadoop的一个新的漏洞被曝光,漏洞的主要原因在于Hadoop 引入了 Docker组件,但是在Linux这层没有输入过程的认证,并且Docker命令又是通过root身 3 65 份来执行的。因此,黑客就通过Docker命令伪造了root身份,然后对Hadoop进行了全 线账户的提权,实现了整个操作系统的权限控制。 通过上述案例可以发现,这些安全漏洞的产生大部分都是由于Hadoop的身份认证 授权没有做好。早期Hadoop在默认情况下,是没有身份认证和访问控制机制的,基本上 是继承了Linux的权限控制体系。另外,它在数据传输过程中和静态数据保存过程中都 没有有效的加密措施。 3.2 Hadoop 安全机制 3.2.1 基本安全机制 为了增强Hadoop 的安全机制,从2009 年起,Apache专门组织了一个团队,为 Hadoop增加基于Kerberos 和Delegation Token 的安全认证和授权机制。Apache Hadoop1.0.0和ClouderaCDH3之后的版本添加了安全机制。Hadoop提供了两种安全 机制:Simple机制和Kerberos机制。 1. Simple 机制 Simple机制是JAAS(Java Authenticationand Authorization Service)协议与 DelegationToken结合的一种机制,JAAS提供Java认证与授权服务。 (1)用户提交作业时,JobTracker端要进行身份核实,先是认证到底是不是这个人, 即通过检查执行当前代码的人与JobConf中的user.name中的用户是否一致。 (2)然后检查ACL(AccessControlList)配置文件(由管理员配置)确认是否有提交 作业的权限。 一旦通过认证,会获取HDFS或者MapReduce授予的DelegationToken(访问不同 模块有不同的DelegationToken),之后的任何操作,比如访问文件,均要检查该Token是 否存在,以及使用者跟之前注册使用该Token的用户是否一致。 2. Kerberos 机制 Kerberos机制是基于认证服务器的一种方式。简单来说,大数据平台Hadoop中有 一个专门的认证服务器KDC,可以把它看作户籍派出所,它可事先给所有的平台用户发 放户籍证明,即keytab(密钥表)。之后某个用户要使用大数据平台,就要拿着这个证明 先去KDC认证,认证无误之后,才能够使用大数据平台服务。Kerberos机制工作原理示 意如图3.1所示。 在身份认证方面,在Hadoop集群内部,一般使用基于Kerberos的身份认证机制。 主要原因在于,该机制具有如下优势:①可靠,Hadoop本身并没有认证功能和创建用户 组功能,只是使用依靠外围的认证系统;②高效,Kerberos使用对称密码操作,比使用 SSL的公钥密码快;③操作简单,用户可以方便地进行操作,不需要很复杂的指令,比如 废除一个用户,只从Kerberos的KDC数据库中删除即可。 图3.ebrs机制工作原理示意 1 Kreo 2.总体安全机制 3.2 Hadoop的安全机制如下所述。 (1)Hadoop的客户端通过Hadoop的RPC 库访问相应的服务,Hadoop在RPC 层 中添加了权限认证机制,所有RPC 都会使用SASL(SimpleAuthenticationandSecurityLayer)进行连接。其中,SASL 协商使用Kerberos或者DIGESTMD5 协议。 (2)HDFS 使用的认证可以分成两部分:第一部分是客户端与NameNode连接时的 认证;第二部分是客户端从DataNode获取Block时所需要的认证。第一部分使用 Kerberos协议认证和授权令牌(DelegationToken)认证,这个授权令牌可以作为接下来 访问HDFS 的凭证。第二部分则是客户端从NameNode获取一个认证令牌,只有使用这 个令牌,才能从相应的DataNode获取Block。 (3)在MapReduce中用户的每个Task均使用用户的身份运行,这样就防止了恶意 用户使用Task干扰TaskTracker或者其他用户的Task。 (4)HDFS 在启动时,NameNode首先进入一个安全模式,此时系统不会写入任何数 据。NameNode在安全模式下会检测数据块的最小副本数,当一定比例的数据块达到最 小副本数时(一般为3), 系统就会退出安全模式,否则补全副本,以达到一定的数据块 比例 ( 。 5)当从HDFS 获得数据时,客户端会检测从DataNode收到的数据块,通过检测每 个数据块的校验和(Checksum)来认证这个数据块是否损坏。如果损坏,则从其他 DataNode获得这个数据块的副本,以保证数据的完整性和可用性。 (6)MapReduce和HDFS 都设计了心跳机制,Task和DataNode都定期向JobTracker 和NameNode发送信条数据。当JobTracker不能接收到某个Task的心跳数据时,则认 为该Task已经失败,会在另一个节点上重启该任务,以保证整个MapReduce程序的运 行。同理,如果NameNode收不到某个DataNode的心跳消息,也认为该节点已经死掉, 不会向该节点发送新的I/O任务,并复制那些丢失的数据块。 66 67 3.3 Hadoop 组件的安全机制 Hadoop安全性与其组件安全机制息息相关。本节进一步介绍Hadoop中RPC、 HDFS、MapReduce的安全机制。 3.3.1 RPC安全机制 RPC是指远程过程调用,也就是说,两台不同的服务器(不受操作系统限制),一个应 用部署在A 上,一个应用部署在B上,若A 想要调用B上的某个方法,由于不在一个内 存空间,不能直接调用,因此需要通过网络来表达调用的语意和传达调用的参数。 Hadoop集群是Master/Slave(主/从)结构,Master包括NameNode和JobTracker, Slave包括DataNode和TaskTracker。NameNode可看作分布式文件系统中的管理者, 主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。NameNode会将 文件系统的MetaData存储在内存中,这些信息主要包括文件信息、每一个文件对应的文 件块的信息和每一个文件块在DataNode中的信息等。DataNode是文件存储的基本单 元,它将Block存储在本地文件系统中,保存了Block的MetaData,同时周期性地将所有 存在的Block信息发送给NameNode。Client就是需要获取分布式文件系统文件的应用 程序。就通信方式而言,Client与NameNode、NameNode与DataNode都是在不同进程、 不同系统间的通信,因此Hadoop要用到RPC。 RPC安全机制是在HadoopRP中添加权限认证授权机制。当用户调用RPC时,用 户的LoginName会通过RPC头部传递给RPC,之后RPC使用SASL确定一个权限协 议(支持Kerberos和DIGEST-MD5两种),完成RPC授权。 3.3.2 HDFS安全机制 客户端获取NameNode初始访问认证(使用Kerberos)后,获取一个Delegation Token,该Token可以作为接下来访问HDFS或者提交作业的凭证。为了读取某个文 件,客户端首先要与NameNode交互,获取对应数据块的BlockAccessToken,然后到相 应的DataNode上读取各个数据块,而DataNode在初始启动后向NameNode注册时,已 经提前获取了这些Token,当客户端要从TaskTracker上读取数据块时,首先认证 Token,通过后才允许读取。 1. Delegation Token 当用户使用Kerberos证书向NameNode提交认证后,从NameNode 获得一个 DelegationToken,之后该用户提交作业时可使用该DelegationToken进行身份认证。 DelegationToken是用户和NameNode之间的共享密钥,获取DelegationToken的任何 人都可以假冒该用户。只有当用户再次使用Kerberos认证时,才会再次得到一个新的 DelegationToken。 当从NameNode获得DelegationToken时,用户应该告诉NameNode这个Token 的renewer(更新者)。在对该用户的Token进行更新之前,更新者先向NameNode进行 认证。Token的更新将延长该Token在NameNode上的有效时间,而非产生一个新的 Token。为了让一个MapReduce作业使用一个DelegationToken,用户通常需要将 JobTracker作为DolegationToben的更新者。同一个作业下的所有任务使用同一个 Token。在作业完成之前,JobTracker确保这些Token是有效的;在作业完成之后, JobTracker就可以废除这个Token。 NameNode随机选取masterKey,并用它生成和认证DelegationToken,保存在 NameNode的内存中,每个DelegationToken都有一个Token,存在expiryDate(过期时 间)。如果curentTime>expiryDate,该Token将被认为是过期的,任何使用该Token 的认证请求都将被拒绝。NameNode将过期的DelegationToken从内存中删除,另外,如果 Token的owner(拥有者)和renewer废除了该Token,则NameNode将这个DelegationToken 从内容中删除。SequenceNunber(序列号)随着新的DelegationToken的产生不断增大,唯 一标识每个Token。 当客户端(如一个Task)使用DelegationToken认证时,首先向NameNode发送Token。 TokenID代表客户端将要使用的DelegationToken。NameNode利用TokenID和 masterKey重新计算出DelegationToken,然后检查其是否有效。当且仅当该Token存在于 NameNode内存中,并且当前时间小于过期时间时,这个Token才算是有效的。如果Token 是有效的,则客户端和NameNode就会使用它们自己的TokenAuthenticator作为密钥、 DIGESTMD5作为协议相互认证。以上双方认证过程中,都未泄露自己的Toke Authenticator给另一方。如果双方认证失败,意味着客户端和NameNode没有共享同一个 TokenAuthenticator,那么它们也不会知道对方的TokenAuthenticator。 为了保证有效,DelegationToken需要定时更新。假设JobTracker是一个Token的 更新者,在JobTacker向NameNode成功认证后,JobTracker向NameNode发送要被更 新的Token。 NameNode将进行如下认证。 (1)JobTracker是TokenID中指定的更新者。 (2)TokenAuthenticator是正确的。 (3)curentTime