敏感信息的安全和保护是当今人们最关心的问题之一。进入大数据时代，很多组织都在从各种源头收 集数据，进行分析，并基于对海量数据集的分析做出决策，因此这一过程中的安全问题变得愈发重要。与 此同时，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提供列和族系一级的访问控制。