大数据安全: Hadoop 安全模型的演进

敏感信息的安全和保护是当今人们最关心的问题之一。进入大数据时代，很多组织都在从各种源头收集数据，进行分析，并基于对海量数据集的分析做出决策，因此这一过程中的安全问题变得愈发重要。与此同时，HIPAA 和其他隐私保护法之类的法律法规也要求组织加强对这些数据集的访问控制和隐私限制。来自内部和外部攻击者的网络安全漏洞与日俱增，通常都要数月之后才能发现，而那些受此影响的人正在为此付出代价。没能对他们的数据做出恰当访问控制的组织将受到起诉，出现在负面报道中，并将面临监管机构的罚款。

请想一想下面这些让人大开眼界的统计数据：

• 赛门铁克和 Ponemon 研究所今年公布的一项研究表明，一个安全漏洞在美国的平均组织化成本是 540 万美元 1。另据最近一项研究表明，仅仅网络犯罪在美国造成的损失每年就有 140 亿美元之多。
• 2011 年索尼游戏机网络中出现的漏洞可以算是近代最大的安全漏洞之一，专家们估计索尼与该漏洞相关的损失大约在 27 亿到 240 亿美元之间（范围很大，但这个漏洞太大了，所以几乎难以对其进行量化）。2
• Netflix 和 AOL 已经因为其管理的大量数据和对个人信息的保护而受到金额达数百万美元的起诉（某些已经立案），尽管他们已经对这些数据做了“匿名化”处理并且是为了研究才公布的。3
• 跟安全漏洞相关的除了可量化的成本（客户和业务合作伙伴的损失，诉讼，监管罚款），经历此类事件的组织的可信度和声誉还会受到影响，甚至可能会导致公司歇业。4

简而言之，如果没有恰当的安全控制，大数据很容易变成花费巨大的大问题。

对于处理大数据的组织来说这意味着什么？意味着你拥有的数据越多，对数据的保护就越重要。意味着不仅要安全有效地控制离开自有网络的数据，还必须做好网络内部的数据访问控制。依据数据的敏感程度，我们可能要确保数据分析师能看到的数据是可以让他们分析的数据，并且必须明白发布这些数据及其分析结果可能产生的后果。仅 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 的不足有几个原因：

1. 没有**“静态数据”**加密。目前 HDFS 上的静态数据没有加密。那些对 Hadoop 集群中的数据加密有严格安全要求的组织，被迫使用第三方工具实现 HDFS 硬盘层面的加密，或安全性经过加强的 Hadoop 版本（比如今年早些时候英特尔发布的版本）。
2. 以 Kerberos**** 为中心的方式——Hadoop 依靠 Kerberos 做认证。对于采用了其他方式的组织而言，这意味着他们要单独搭建一套认证系统。
3. 有限的授权能力——尽管 Hadoop 能基于用户及群组许可和访问控制列表（ACL）进行授权，但对于有些组织来说这样是不够的。很多组织基于 XACML 和基于属性的访问控制使用灵活动态的访问控制策略。尽管肯定可以用 Accumulo 执行这些层面的授权过滤器，但 Hadoop 的授权凭证作用是有限的。
4. 安全模型和配置的复杂性。 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 的主要变化，但有望解决有这些安全需求的组织的安全问题。

结论

在我们这个步履匆匆而又相互关联的世界里，大数据就是王道，在我们对海量数据进行处理和分析时，明白安全的重要性至关重要。这要从弄懂数据及相关的安全策略开始，也要明白组织的安全策略，并知道如何强制执行。本文介绍了 Hadoop 的安全简史，重点讲了常见的安全问题，并介绍了 Rhino 项目，给出了一个未来的快照。

关于作者

凯文 T. 史密斯是 Novetta 解决方案应用任务方案分部的技术方案及推广指导，他负责向客户提供战略性的技术领导力，开发具有创新性的、数据为本并且高度安全的解决方案。他经常在各种技术会议上演讲，发表过很多技术文章，还编写过许多技术书籍，包括即将出版的《专业 Hadoop 解决方案》，以及《应用 SOA：面向服务的架构及设计策略》，《语义 Web：XML，Web 服务及知识管理的未来发展指南》等等。可以通过 KSmith@Novetta.com 联系到他。

致谢

特别感谢 Stella Aquilina, Boris Lublinsky, Joe Pantella, Ralph Perko, Praveena Raavicharla, Frank Tyler 和 Brian Uri 对本文的审阅和部分内容的评论。 此外还要感谢克里斯·贝利制作了不断发展的 Hadoop 大象之“艾比路”这幅插图。

1 Ponemon 研究所, 2013 数据泄露的成本研究：全球分析，2013 年 5 月

2 商业内幕，PlayStation 网络危机可能让索尼花费了数十亿

3 请参见“CNN/Money –5 数据泄露 - 从尴尬到致命”, 及维基百科上关于 AOL 在匿名化记录上泄漏的研究数据的页面

4 Ponemon 研究所, “你的公司为大数据泄漏做好准备了吗？”, 2013 年 3 月

查看英文原文： Big Data Security: The Evolution of Hadoop’s Security Model

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。