与此同时，AOL发布了一个“匿名化”的搜索引擎日志数据集，用于研究目的，而纽约时报的一位记者交叉引用该数据集和通信录列表，能够识别出用户的身份。这暴露了AOL用户三个月内的搜索历史——其中一些是非常令人尴尬的。其结果是AOL的首席技术官(CTO)辞职、两名AOL员工被解雇以及一场针对公司的集体诉讼。

还有不胜枚举的其他例子——MIT的一位研究人员在将一个“匿名化”的州保险数据库与公开可用的州选举注册记录一起分析时，发现能够从该数据集中识别出其州长的医疗记录。

这些例子演示了手头的问题，以及一起使用数据集中的信息会如何潜在地违反隐私法律、规章，并绕过对用户的访问控制。通过使用这些相同的方法，你的内部Hadoop用户也许能够绕过安全限制，如果没有设置适当的控制的话。

12.2.3 加密静止的数据

由于针对保存在磁盘上和终端用户设备上信息的保密性存在很多威胁，因此许多有敏感信息的组织都有要求加密静止数据的策略。此种策略的多数原因与恶意软件的威胁、数据的敏感性或保密性、或者法律规章相关。例如，HIPPA具有与加密电子保护的健康信息(EPHI)中静止数据相关的指导意见，并且其他保护个人可识别信息(PII)的法律也在发挥作用。

一些组织正在推动加密HDFS上的静止数据，Hadoop并不原生地提供该功能。然而，可以将第三方库和其他产品与Hadoop一起使用来满足这些需求，而且Rhino项目(如第10章中的讨论)也正在致力于解决Hadoop中的这个问题。

12.2.4 企业级安全集成

大多数公司在企业内部都有各式各样的安全基础设施，包括用于认证的公钥基础设施(PKI)组件、活动目录实例、安全令牌服务、属性服务和用于认证用户的策略服务器，提供授权凭据，并做出和实施访问控制决策。Hadoop的原生安全机制并不总能让你与各个组织的安全基础设施“适配”或集成。当安全需求指定要将企业级应用与组织的安全基础设施集成时，安全架构师的工作就是设计一个解决方案，能够在使用Hadoop的同时，使用其他工具与安全基础设施相集成。

12.3 保证使用Hadoop的企业级应用安全的方法

近来，大量的项目、Hadoop插件和专门的Hadoop发行版已经承诺了要增强Hadoop的安全性。Hortonworks的Knox Gateway、Intel的安全增强型Hadoop发行版和诸如Rhino等开源项目已经发布，并实现了帮助企业级应用开发者满足安全需求的承诺。无论如何，重要的是要记住每个企业级应用都是不同的，而且每个部署中的安全需求也将是不同的。

在讨论细节之前，重要的是要理解一些一般的基础知识和指南，用于为使用Hadoop的企业级应用提供安全保证。当大量的项目都只关注于特定的安全机制，而不是遵从某些适用于任何项目的、常识性的指导方针时，它们在运行过程中都会出现问题。

基于客户的任务和需求，每个项目的企业安全策略都可能不同，但却都遵从这些常识规则：

● 确定安全需求——理解安全需求很关键。对于认证、访问控制、审计、加密、完整性和隐私的需求将由组织自身来决定。需要问的一些问题可能会围绕着Hadoop MapReduce作业结果数据集的安全性，以及Hadoop运行时自身的安全性(为进行查询和运行作业的应用程序/用户提供访问控制)。与适当的决策制定者会晤来理解哪些是需要的，以便可以做相应的准备。

● 从一开始就设计安全性——这些类型项目最大的问题之一就是到最后才尝试改进安全性，这样的实践导致了短暂且脆弱的架构，通常会注定项目的失败。如果项目中有本章所讨论的安全需求，但却认为可以只关注数据分析而后续再尝试考虑保证解决方案安全性的话，那么会有极大的失败风险。应该关注于开发可以与有关当局进行讨论的初始总体安全架构，以获得概念上的认可。

● 不要使用不需要的安全性——如果没有要达到本章所讨论的某些目标的安全需求，那么就不要做任何事！不要实现那些不需要的东西来增加复杂性和性能开销。

● 使用“防御纵深”方案——永远不要假设使用个别安全方案或机制就能够阻止或预防攻击或违反安全策略。防御纵深策略包含多层防御。

● 牢记蓝图——了解数据的生命周期(如前面图12-1中所示)。理解提供安全性可能意味着访问控制，以及在整个数据生命周期(从原始数据源中的数据，到加载到Hadoop集群中的数据，再到结果数据集)中保持和实施策略。

接下来的几小节会深入到满足某些安全需求的具体细节中，并补充Hadoop原生提供的安全机制。讨论关注于三个主要方案，在与Hadoop原生机制结合的同时，它们提供了企业级安全的构成组件。在接下来的这些小节中，讨论将聚焦于Apache Accumulo。

12.3.1 使用Accumulo进行访问控制保护

Apache Accumulo是一个稀疏的、分布式的、有序的以及多维度的键/值存储，提供单元格级别的细粒度访问控制属性。它于2008年由NSA开发，基于Google BigTable的设计，于2011年发布到Apache开源社区，并且现在是顶级Apache项目。它是构建在Hadoop和Zookeeper之上的、高度可扩展的NoSQL数据库。开发它的部分原因是为了解决大数据安全问题。

Accumulo扩展了BigTable的数据模型，但添加了一个元素，以提供单元格级别的、强制的基于属性的访问控制(ABAC)。可以使用可见性控制来标记所有导入到Accumulo中的数据，当数据分析师查询数据时，基于访问控制策略中的可见性控制，他们将仅能看到你期望他们看到的内容。Accumulo的API为你提供的能力包括编写认证用户的客户端，以及与企业级属性服务相集成，并拉取用户的授权凭证以提供某个级别的访问控制。Accumulo还提供将用户和授权信息保存在其自身中的能力。

如图12-2中所示，Accumulo是一个键/值存储，它的键是一个5元组。Accumulo中的键由行ID、列族、列限定符、列可见性和时间戳构成。此5个元素的键与一个值相关联。

图12-2 Accumulo数据模型

该5元组键提供原子性、本地性、唯一性、访问控制和版本化。重要的是要注意键中的时间戳维度包含了基于不同的时间和日期，提供相同数据多个版本的能力。大体来说，Accumulo的数据模型多数借用了BigTable数据模型，但添加了可见性元素来提供面向数据的安全——它将仅返回那些运行查询的用户/应用程序的凭据满足可见性标签的单元格。

Accumulo和HBase中数据级安全性的差异