hadoop安全性问题

时间:2022-09-23 13:10:02
对于处理大数据的组织来说这意味着什么?意味着你拥有的数据越多,对数据的保护就越重要。意味着不仅要安全有效地控制离开自有网络的数据,还必须做好网络内部的数据访问控制。依据数据的敏感程度,我们可能要确保数据分析师能看到的数据是可以让他们分析的数据,并且必须明白发布这些数据及其分析结果可能产生的后果。仅Netflix数据泄漏一个案例就足以表明,即使已经试图对数据做了“匿名化”处理,也可能会发布一些意料之外的信息——一些在差异化隐私领域标明的东西。


Apache Hadoop是最流行的大数据处理平台之一。尽管最初设计Hadoop时根本没考虑安全问题,但它的安全模型在不断地演进。Hadoop的兴起也招致了很多批判,并且随着安全专家不断指出其潜在的安全漏洞及大数据的安全风险,使得Hadoop一直在改进其安全性。“Hadoop安全”市场曾出现过爆炸性的增长,很多厂商都发布了“安全加强”版的Hadoop和对Hadoop的安全加以补充的解决方案。这类产品有Cloudera Sentry、 IBM InfoSphere Optim Data Masking、 英特尔的安全版Hadoop、DataStax企业版、 DataGuise for Hadoop、用于Hadoop的Protegrity大数据保护器、Revelytix Loom、Zettaset 安全数据仓库,此外还有很多,这里就不再一一列举了。与此同时,Apache也有 Apache Accumulo这样的项目,为使用Hapdoop提供了添加额外安全措施的机制。最终还出现了 Knox网关 (由HortonWorks贡献)和Rhino项目(由英特尔贡献)这样的开源项目,承诺要让Hadoop本身发生重大改变。


要让Hadoop达到安全性要求的巨大需求使得Hadoop一直在发生着变化,这也是我要在本文中重点讨论的内容。


Hadoop安全(简)史

Doug Cutting和Mike Cafarella最初为Nutch项目开发Hadoop时并没有考虑安全因素,这是众所周知的事实。因为Hadoop的最初用例都是围绕着如何管理大量的公共web数据,无需考虑保密性。按照Hadoop最初的设想,它假定集群总是处于可信的环境中,由可信用户使用的相互协作的可信计算机组成。

最初的Hadoop中并没有安全模型,它不对用户或服务进行验证,也没有数据隐私。因为Hadoop被设计成在分布式的设备集群上执行代码,任何人都能提交代码并得到执行。尽管在较早的版本中实现了审计和授权控制(HDFS文件许可),然而这种访问控制很容易避开,因为任何用户只需要做一个命令行切换就可以模拟成其他任何用户。这种模拟行为非常普遍,大多数用户都会这么干,所以这一已有的安全控制其实没起到什么作用。

在当时,考虑到安全问题的组织把Hadoop隔离在专有网络中,只有经过授权的用户才能访问。然而由于Hadoop内部几乎没有安全控制,在这样的环境中也会出现很多意外和安全事故。善意的用户可能会犯错(比如用一个分布式删除在几秒内就会删除大量数据)。所有用户和程序员对集群内的所有数据都有相同的访问权限,所有任务都能访问集群内的任何数据,并且所有用户都可能会去读取任何数据集。因为MapReduce没有认证或授权的概念,某个顽劣的用户可能为了让自己的任务更快完成而降低其他Hadoop任务的优先级,甚至更坏,直接杀掉其他任务。

随着Hadoop在数据分析和处理平台中的地位日益凸显,安全专家们开始关心来自Hadoop集群内部的恶意用户的威胁。恶意开发人员能轻易写出假冒其他用户Hadoop服务的代码来(比如写一个新的TaskTracker并将其注册为Hapdoop服务,或者冒充hdfs或mapred用户,把HDFS里的东西全删掉等等)。因为DataNode没有访问控制,恶意用户可以绕过访问控制从DataNode中读取任意数据块,或将垃圾数据写到DataNode中破坏目标分析数据的完整性。所有人都能向JobTracker提交任务,并可以任意执行。

因为这些安全问题,Hadoop社区意识到他们需要更加健壮的安全控制,因此,雅虎的一个团队决定重点解决认证问题,选择Kerberos作为Hadoop的认证机制,这在他们2009年的白皮书上有记录。

在Hadoop发布.20.20x版本时他们实现了自己的目标,该版本采用了下面这些机制:

用Kerberos RPC (SASL/GSSAPI) 在RPC连接上做相互认证——用SASL/GSSAPI来实现Kerberos及RPC连接上的用户、进程及Hadoop服务的相互认证。
为HTTP Web控制台提供“即插即用”的认证——也就是说web应用和web控制台的实现者可以为HTTP连接实现自己的认证机制。包括(但不限于)HTTP SPNEGO认证。

强制执行HDFS的文件许可——可以通过NameNode根据文件许可(用户及组的访问控制列表(ACLs))强制执行对HDFS中文件的访问控制。
用于后续认证检查的代理令牌——为了降低性能开销和Kerberos KDC上的负载,可以在各种客户端和服务经过初始的用户认证后使用代理令牌。具体来说,代理令牌用于跟NameNode之间的通讯,在无需Kerberos服务器参与的情况下完成后续的认证后访问。

用于数据块访问控制的块访问令牌——当需要访问数据块时,NameNode会根据HDFS的文件许可做出访问控制决策,并发出一个块访问令牌(用HMAC-SHA1),可以把这个令牌交给DataNode用于块访问请求。因为DataNode没有文件或访问许可的概念,所以必须在HDFS许可和数据块的访问之间建立对接。
用作业令牌强制任务授权——作业令牌是由JobTracker创建的,传给TaskTracker,确保Task只能做交给他们去做的作业。也可以把Task配置成当用户提交作业时才运行,简化访问控制检查。

把这些整合到一起让Hadoop向前迈出了一大步。自那之后,又实现了一些值得称道的修改:
从“即插即用的认证”到HTTP SPNEGO认证——尽管2009年的Hadoop安全设计重点是即插即用的认证,但因为RPC连接(用户、应用和Hadoop服务)已经采用了Kerberos认证,所以Hadoop开发者社区觉得如果能跟Kerberos保持一致更好。现在Hadoop web控制台被配置成使用HTTP SPNEGO这一用于web控制台的Kerberos实现。这样可以部分满足Hadoop亟需的一致性。

网络加密——采用了SASL的连接可以配置成使用机密保护质量(QoP),在网络层强制加密,包括使用Kerberos RPC的连接和使用代理令牌的后续认证。Web控制台和MapReduce随机操作可以配置成使用SSL进行加密。HDFS文件传输器也能配置为加密的。

自对安全性进行重新设计以来,Hadoop的安全模型大体上没发生什么变化。随着时间的推移,Hadoop体系中的一些组件在Hadoop之上构建了自己的安全层,比如Apache Accumulo,提供单元级的授权,而HBase提供列和族系一级的访问控制。

Hadoop当前所面临的安全挑战

组织在保证Hadoop的安全性时会面临一些安全方面的挑战,在我和Boris Lublinsky 及 Alexey Yakubovich写的新书中,我们用了两章的篇幅集中讨论Hadoop的安全问题,其中一章的重点是Hadoop本身的安全能力,另外一章的重点是对Hadoop的安全性进行补充的策略。

常见的安全问题有:

如何强制所有类型的客户端(比如web控制台和进程)上的用户及应用进行验证?
如何确保服务不是流氓服务冒充的(比如流氓TaskTracker和Task,未经授权的进程向 DataNode 出示ID 以访问数据块等?)
如何根据已有的访问控制策略和用户凭据强制数据的访问控制?
如何实现基于属性的访问控制(ABAC)或基于角色的访问控制(RBAC)?
怎么才能将Hadoop跟已有的企业安全服务集成到一起?
如何控制谁被授权可以访问、修改和停止MapReduce作业?
怎么才能加密传输中的数据?
如何加密静态数据?
如何对事件进行跟踪和审计,如何跟踪数据的出处?
对于架设在网络上的Hadoop集群,通过网络途径保护它的最好办法是什么?
这其中很多问题都能靠Hadoop自身的能力解决,但也有很多是Hadoop所无能为力的,所以行业内涌现出了很多Hadoop安全补充工具。厂商们发布安全产品来弥补Hadoop的不足有几个原因:

没有“静态数据”加密。目前HDFS上的静态数据没有加密。那些对Hadoop集群中的数据加密有严格安全要求的组织,*使用第三方工具实现HDFS硬盘层面的加密,或安全性经过加强的Hadoop版本(比如今年早些时候英特尔发布的版本)。

以 Kerberos为中心的方式——Hadoop依靠 Kerberos做认证。对于采用了其他方式的组织而言,这意味着他们要单独搭建一套认证系统。

有限的授权能力——尽管Hadoop能基于用户及群组许可和访问控制列表(ACL)进行授权,但对于有些组织来说这样是不够的。很多组织基于XACML和基于属性的访问控制使用灵活动态的访问控制策略。尽管肯定可以用Accumulo执行这些层面的授权过滤器,但Hadoop的授权凭证作用是有限的。

安全模型和配置的复杂性。 Hadoop的认证有几个相关的数据流,用于应用程序和Hadoop服务的Kerberos RPC认证,用于web控制台的HTTP SPNEGO认证,以及使用代理令牌、块令牌、作业令牌。对于网络加密,也必须配置三种加密机制,用于SASL机制的保护质量,用于web控制台的SSL,HDFS数据传输加密。所有这些设置都要分别进行配置,并且很容易出错。

如果Hadoop如今还不具备实现者所要求的安全能力,那么他们只能转而集成第三方工具,或使用某个厂商提供的安全加强版Hadoop,或采用其他有创造性的办法。

即将发生的大变化

2013年开端之际,英特尔发起了一个开源项目Rhino,以提升Hadoop及其整个体系的安全能力,并将代码贡献给了Apache。这有望显著加强Hadoop当前的贡献。这一开源项目的总体目标是要支持加密和密钥管理,一个超越Hadoop当前提供的用户及群组ACL的通用授权框架,一个基于认证框架的通用令牌,改善HBase的安全性,改善安全审计。这些任务都被记录在Hadoop、 MapReduce、HBase 和 Zookeeper的JIRA中,择重点摘录如下:

加密的静态数据——JIRA 任务 HADOOP-9331 (Hadoop加密编码解码器框架及加密编码解码器的实现) 和 MAPREDUCE-5025 (支持MapReduce中的加密编码解码器的密钥发行和管理) 有直接的关系。第一个侧重于创建一个加密框架及其实现,以支持对HDFS上文件的加密和解密;第二个侧重于为MapReduce提供密钥发行和管理框架,以便能在MapReduce操作过程中对数据加密和解密。为此向Hadoop中引入了一个可分割AES编码解码器的实现,可以对磁盘上分散的数据加密和解密。密钥发行和管理框架可以在MapReduce操作过程中解析密钥的上下文,因此MapReduce作业能够进行加解密操作。他们已经发展出的需求包括MapReduce作业不同阶段的不同选项,并且要支持灵活的密钥获取办法。在一些相关的任务中,ZOOKEEPER-1688 将提供透明的快照加密能力,并在硬盘记录日志,防止敏感信息从静态文件中泄漏出去。

基于令牌的认证及统一授权框架——JIRA 任务 HADOOP-9392 (基于令牌的认证及单点登录) 和 HADOOP-9466 (统一授权框架) 也是相互关联的。第一项任务展示了一个跟Kerberos耦合不是那么紧密的基于令牌的认证框架。第二项任务会用基于令牌的框架支持灵活的授权强制引擎,以取代(但能向后兼容)当前的ACL式访问控制。对基于令牌的认证框架,第一项任务计划支持多种认证机制的令牌,比如LDAP 用户名/密码认证,Kerberos,X.509证书认证,SQL认证(基于SQL数据库的用户名/密码认证)和SAML。第二项任务要支持一个先进的授权模型,侧重于基于属性的访问控制(ABAC)和XACML标准。
提升HBase的安全性——JIRA 任务 HBASE-6222 (增加每-键值安全) 向HBase添加Apache Accumulo具备但HBase还没有的单元级授权。开发出构建在加密框架上的HBASE-7544 ,把它扩展到HBase,提供透明的表加密。

这些就是Hadoop的主要变化,但有望解决有这些安全需求的组织的安全问题。