一、前言：
非常感谢Hadoop专业解决方案群：313702010，兄弟们的大力支持，在此说一声辛苦了，春节期间，项目进度有所延迟，不过元宵节以后大家已经步入正轨， 目前第12章 为Hadoop应用构建企业级的安全解决方案已经翻译完成，在此对：译者：杨有鹏 不莱梅狗 78280847 表示感谢。
二、意见征集：
本章节由《Hadoop专业解决方案群：313702010》翻译小组完成，为小组校验稿，已经通过小组内部校验通过，特此面向网络征集意见，如果对本章节内容有任何异议，请在评论中加以说明，说明时，请标明行号，也可以以修订的方式，发送给我。非常感谢。
三、原书说明
英文原书《Wrox.Professional.Hadoop.Solutions》第12章，请参照英文原文。
四、翻译原稿
本章内容：
➤理解企业级应用的安全关注考量
➤理解Hadoop未为企业级应用提供的安全措施
➤学习构建企业级安全应用解决方案的方法
本书的第10章节讨论了Hadoop安全以及Hadoop内部的安全控制机制。在构建企业安全解决方案（这类方案会包括很多与Hadoop数据相关的应用以及企业服务）的时候，保证Hadoop自身的安全只是其中一个方面。组织机构正努力利用不同安全策略来为从异构数据源提取的数据提供一致的安全机制。当组织机构从外部不同的数据源中提取数据，并且进行转换，装载到Hadoop中时候，在这些数据要被导入到企业应用的时候过程中，安全方面的挑战就变的更加复杂。例如，Hadoop 工作组合多个数据集并产生新的组合数据集，对于原始数据集你采用何种安全访问控制策略。
要命的是，许多企业发现Hadoop自身提供的安全级别并不能满足他们所有的需求，他们必须要补充Hadoop的安全模型。例如，一些机构被要求加密静态数据以满足他们的需求，这样的功能，是Hadoop不具备的。另外，数据科学家进行分析查询的时候，一些企业需要为Hadoop 查询提供细粒度的基于属性的访问控制。虽然这些需求目前已经在Hadoop路线图上面，或者会出现未来的Hadoop 安全策略中（如第10章所述）。这类的功能大大超出了Hadoop 本身能够提供的功能。
因为这些挑战，企业级的解决方案必然要按照一个整体的安全方式去开发，而不是以Hadoop为中心。当然，你可以使用Hadoop自身的安全机制去满足你的一部分安全需求，但是在许多企业中，你会发现Hadoop的安全机制并不能满足所有的需求。使用Hadoop的企业级的应用必须要结合企业大局，集成其他的安全机制来计划，设计，以及实施。
在第10章的讨论中，Hadoop的设计和开发是没有考虑安全的，而且在很长一段时间内，几乎没有为Hadoop定制的安全机制。早期社区内的设想是，Hadoop集群会在可信赖环境中由可信赖用户使用的协同，可信赖的机器组成。在之后，Hadoop社区采用了一个新的安全架构，该架构包括了新的安全控制（如第10章讨论），但是对于那些有很强的访问控制限制，保密制度，隐私要求，以及合规要求的企业或者组织来说，仍然不能利用Hadoop生态系统中基本的工具来满足他们的需求。他们想要利用Hadoop的功能，那么他们就必须要把安全也构建到其他工具中，或者另外设计一套使用Hadoop的安全解决方案。
本章是为想要利用Hadoop，却同样要回应安全问题的企业级应用的开发者而写的。企业级应用需要支持一个企业的安全要求，理解这一点很重要。这可能需要集成身份访问管理基础设施、以及其他的网络基础设施，这同样意味着要采用其他的独立于Hadoop的安全控制。本章提供了满足这些需求的一种方法论以及一些可能的解决方案。
本章首先会介绍开发基于Hadoop的企业级应用的安全考量的简要概述。然后，会讨论Hadoop安全不提供的功能，以及一系列构建集成Hadoop企业安全解决方案的方法，包括现实的例子。最后，本章会简要的涉及一下另外一种安全工具Apache Accumulo，你能够将之应用到Hadoop分布式集群中，Apache Accumulo是一种高级安全存储和检索系统，它由美国国家安全局（NSA）为了精细审计而在Hadoop基础上面构建的。
企业级应用的安全考量
在构建Hadoop解决方案的时候，不仅是考虑Hadoop自身的安全性（如第10章所讨论的那样）很重要，另外要理解全局安全策略以及以数据为中心，这两点也很重要。
如图12-1所示，你需要理解Hadoop数据的生命周期。在构建Hadoop解决方案的时候，数据的生命周期包括：从信息源提取数据，装载数据到Hadoop Cluster中，运行查询，以及分析，到最终利用结果数据。当数据到达的时候，安全框架的目标就是确保整个数据的生命周期中所有的安全策略都能被强制执行。
不管使用到的工具，数据可以从很多数据源中提取数据，转换为通用的数据格式，然后被装载到Hadoop集群中的HDFS上面去，这个过程通常会被称为：抽取，转换以及装载的过程（ETL）。数据分析师可以接着运行一些列的MapReduce 工作，以及执行能够产生解决集的查询，这也就是企业级应用所典型的利用Hadoop的方式。
这里的挑战是多方面的，你必须能够在数据生命周期之间的迁移过程中，保证数据的安全性，要坚持最初的安全策略。数据被抽取、装载、和集群中其他机器上面的数据组合、以及产生最终会被其他应用使用的结果集，整个过程都是一个挑战。
图12-1给出关于安全考量点的一个很好的一览，这些安全考量会在本章中被检测。要建立牵涉Hadoop的安全的企业级应用，架构师们需要理解信息安全的基础，以及他们是如何被应用的。利用Hadoop的解决方案中很多安全目标需要解释，要明白最优方法依赖于理解这些安全考量以及相关术语的含义。这里的讨论没有提供一份详尽的安全考量点的清单或者是关于每一个安全考量的详细解释，只是提供了作为企业架构师需要知道的为了达到安全目标的简略的信息安全词汇列表。对于每一个术语定义的目标，你会学习在Hadoop环境中，认识到为什么是重要的。
认证
认证就是识别一个主体的身份。一个主体可以是一个用户，一个应用，一个任务，或者系统中其他的角色。就如第10章中所讨论的那样，Hadoop可以被配置使用Kerberos来认证用户，服务，以及Hadoop集群中服务器。认证确保了用户和服务正如他们的所表明的身份那样是可靠的用户和服务，阻止了来自于其他恶意系统的模仿的用户、服务、任务。
需要提及的是，并不是所有的企业在Hadoop系统之外都部署了一套企业级的Kerberos系统来作为认证系统。企业级的应用可能需要把其他的身份访问管理基础设施集成进入他们的应用。
授权
授权就是决定一个主体能够拥有什么样的权限，在主体通过了认证之后，系统必须确定主体的特许凭证，并且需要将主体的特许凭证和一个授权策略做比较，以给主体提供对请求的资源的访问许可。如第10章所述，目前Hadoop提供一种访问控制级别，这种访问控制利用访问控制列表（ACLs）来表述访问控制策略，非常类似于UNIX的用户-组的用户权限。
除了Hadoop自身提供的授权机制，大多数企业机构都采用了另外的授权机制。例如，一个企业机构可能拥有以下一种，或者多种授权机制：
➤轻量级目录访问控制（简称OLAP）目录、或者活动目录（AD）实例，这两种方式都保存了主体的组、角色以及权限。
➤属性服务，这种方式使用属性作为主体的特许凭证
➤安全令牌服务（Security Token Services简称STS），这种授权机制是分配与主体的特许凭证对应的令牌，并分配授权决策事务。
➤策略服务（Policy Services），该机制是用可扩展访问控制标记语言（eXtensible
Access Control Markup Language 简称XACML），或者安全断言标记语言（Security Assertion Markup Language简称SAML）来表述对资源访问控制策略，并为主体提供访问控制决策。
使用Hadoop的企业应用需要根据他们自身组织的访问控制策略来控制对数据的访问，也就是说要利用其它的机制来补充Hadoop自身的授权控制。
需要记住的是，在数据的整个生命周期中实施授权控制的一致性是很重要的。如果你的初始数据源自身就拥有对于他们的数据的访问控制策略，为查询数据的数据科学家提供同样的访问控制策略很重要。同样，对于之后产生的需要被导入到企业应用中的结果集来说，采用恰当合适的访问控制更加重要。这确实是一个挑战。
机密性
机密性就是限制敏感数据，用户只能看到被授权了的允许看到的部分数据。当敏感数据在网络上传输的时候，这就需要在数据传输过程中，数据不能被偷听者读取。这可以用过网络加密来实现。一些企业需要磁盘加密，或者是静态数据加密，静态数据加密就是数据只在被存储地方被加密，减少了未受保护数据的被盗窃的风险。
在第10章中，我们学习到Hadoop提供了网络加密的功能和机制。然而，Hadoop没有提供对静态数据的加密功能。在本章的后面的章节，你可以学习到达到静态数据加密这一目标的集中策略。
完整性
完整性确保了数据在传输过程中或者是落地之后（成为静态数据）不能够被更改。完整性可以通过加密完成，该加密可以利用信息摘要，哈希码，或者是数字签名的副影响。当Hadoop被配置成采用网络加密的时候，Hadoop会在传输过程中保证数据的完整性。
静态数据就是另外一种情况，幸运的是，Hadoop保证了静态数据的完整性，他通过采用副本形式保证数据可靠性。数据的完整性以及可靠性是Hadoop系统的健壮性，以及他的分布式架构的一个有意的附加影响。由于HDFS被设计成运行在标准化商用硬件上面，用在不同节点上面拷贝数据的方式来达到容错的目的，正是由于数据副本的数目，校验和检查机制，冲突检测机制，Hadoop为保存在HDFS上面的数据提供了一套保证数据完整性的健壮的机制。
然而，安全架构师有时会提议一种担心，这就是如果Hadoop当中的一个节点缺乏抵抗能力，一个恶意的用户可能会修改数据，那么这就会歪解数据分析的结果，这种情况完全可能发生，但是使用Hadoop的安全机制（服务器/服务 认证，数据完整性确认等等），配合深度防御策略，企业级解决方案架构师能够减少这个风险。
审计
大多数的公司都会采用安全审计来保证合规事项的保密性，以及识别潜在的安全缺口。Hadoop当然可以被配置成记录所有的访问日志-NameNode上面保存一份本地日志，一个审计日志记录器可以被配置将访问信息写入一个特定的安全卷上面以保证日志的完整性。企业当然也可以在授权和认证方面拥有更多的需求。
|
注意：尽管关于经典安全目标的大多数的描述都关注机密性，完整性，以及可使用性，这里的描述却关注认证、授权、机密性、完整性以及审计，这是由于这些都是企业应用的安全的关键方面。可使用性（确保能够访问Hadoop）当然也是很重要的，这点在Hadoop设计的时候就已经被关注了。Hadoop是高度可靠的，对于可使用性，Hadoop包含一条重要的跟踪记录，Hadoop同时能够部署你企业内部的其他的安全机制（比如入侵检测系统），来保护系统避免受到Dos攻击。这些都不会在本章讨论，因为这个讨论主要面向于企业应用的开发者。 |
对于企业应用, Hadoop安全机制不提供什么？
在本章剩余的部分中的内容以及安全术语中，重要的一点是你需要理解企业安全的某些方面，而这些方面Hadoop自身也不能够提供。当然Hadoop提供了一定级别的认证（Kerberos）、一定程度的授权（ACLs 以及 UNIX级别的文件权限）、以及支持网络加密和完整性的能力。然而，仅仅靠Hadoop，还有很多安全方面不能提供。
面向数据的访问控制
除了在HDFS上面的针对用户和组的ACLs（访问控制列表）以及基于POSIX的文件读写权限，Hadoop自身不会跟踪数据的访问控制策略。正如你在本章学到那样，很多企业机构都会根据不同的策略来限制对数据的访问，而这些策略通常又非常复杂。可能会出现一些情况，Hadoop系统中数据集中的一部分数据不能被数据分析师访问，这些数据分析师可能不能访问MapReduce
工作的结果集以及查询的结果。
下面介绍了一些好的例子：
➤一个卫生保健机构可能要求医师只能访问和他的相关病人的数据，并且只能在正常的工作时间（早上9点以及下午5点）访问数据。这就意味着需要对病人的数据提供访问控制，需要一个系统，该系统能够基于角色（医师），以及时间（比如正常的工作时间）来限制数据访问权限，同时还要判断该数据是否属于这个医师的病人。
➤一份*文件可能要根据一个用户的国籍，以及/或者一个安全检查的要求，该安全检查通常被称为强制访问控制。
➤某公司的金融咨询师不能访问该公司竞争方的计划以及建议。这种情况被称为“利益冲突”或者是“中国长城”策略。
➤一个大学可以搜集各个部门或者子机构的学生信息，可能涉及金融，医疗记录，校园警察。大学可能需要根据部门或者角色（医疗、警察、金融策略）来控制数据的访问。
这里面的每一个例子当中，Hadoop自身的安全机制不能够轻易的实行这些访问控制策略。一些挑战可能是架构方面的，这需要根据MapReduce的算法。导入的数据可能在开始的时候和访问控制策略关联好（比如在数据用安全策略标记的例子当中）。然而，当数据分布在HDFS上面或者和其他数据集连接的时候，这就可能会导致数据和安全策略之间产生裂缝。这可能导致新合成数据上面的访问控制策略就会不那么清晰。
对于需要这种级别的访问控制的机构来说这就是一个问题，本章的后面的内容中会检验该问题。
差异性隐私
对于无意泄露的信息的研究工作已经开展了将近40年，包括统计学数据库，到与数据挖掘有关的安全以及隐私关注。在数据科学当中，微软研究院的Cynthia Dwork博士使用差异性隐私（differential privacy）来定义这一领域。
差异性隐私关注于保护来自不同数据集或者数据库的信息，避免其被泄露。由于Hadoop以及其他数据分析平台能够利用大量计算资源来处理众多不同的大数据集，包含了重要的隐私和法律含义的差异性隐私就变成了热门话题。在诸如美国健康保险携带和责任法案（Health Insurance Portability and Accountability Act 简称HIPAA）等隐私保护数字法当中，差异化隐私显得尤为重要。
即使一个Hadoop数据集的隐私保密信息已经被略去，而该数据集可能只包含（或者配合）其他看起来并不有害的信息，这些看似无害的信息仍然可能被用来泄露个人的身份或者其他敏感信息，这就导致了违背隐私策略。可能会合成来自多个不同的Hadoop工作中提取的数据信息，这样，数据分析师或者Hadoop用户就不能看到这部分公开的信息。然而，Hadoop自身是不提供这种差异性隐私的保护功能的。当然，Hadoop包含了为内部用户提供了访问控制隐含式，对和其他组织共享统计信息以及数据的组织也提供了非常重要的隐含式。
因为被众多组织采用的Hadoop是强大的分析平台，它可以被用来发现你可能不能发现的信息。组织机构需要在向公众或者合作方发布数据之前都需要再三思考。根据你的实际环境，对你的数据可能会有一些内部的控制，要明白，一些Hadoop用户在他们的分析查询当中可能不允许看到某些结果。这也是NSA所关注的一点，NSA开发并发布了Accumulo，Accumulo项目是属于Apache的开源项目，他提供单元级别（cell-level）的安全。
|
差异性隐私问题举例 |
|
最为广泛关注一个差异性隐私的例子发生在Netflix。在2006年，Netflix开展了一个奖金为1百万美元的比赛，来给它的电影推荐系统提高10%。为了给参加比赛的开发者在比赛当中有数据可用，Netflix发布了一些的被处理过的匿名训练数据集，其中包含了一百万订阅者的电影浏览历史信息。该数据集中有Netflix用户观看电影的排名，但是没有个人身份信息。 两个研究者，来自于奥斯汀的德克萨斯州大学的Arvind 就在同时，出于研究目的，AOL发布了一些“匿名的”搜索引擎日志。一个纽约时报记者利用电话薄对照这个数据集就能够识别一个用户。这份数据集当中包含了AOL用户的三个月的搜索历史，其中一些信息相当令人相当尴尬。该事件直接导致了AOL的CTO的辞职，以及两个AOL雇员被结果，以及一起针对该公司的集体诉讼。 还有其他无数需要注意的例子。比如，MIT的一个研究者能够从一个匿名的州保险数据库中结合公开可用的州选举登记记录识别她主管的医疗记录。 这些例子证明安全问题迫在眉睫，例子显示出数据集是如何能够被组合使用，从而违反隐私法律，法规，以及绕过用户的访问控制限制。通过使用这些相同的原理，如果你并没有进行恰当的控制，内部的Hadoop用户可能能够绕过安全限制。 |
加密静态数据
由于对存储在磁盘或者终端用户设备上面信息的机密性有太多的威胁，许多拥有敏感信息的的组织机构都需要对静态数据进行加密。这种需求的原因与来自恶意软件的威胁有关、也与数据敏感度和机密性有关，或者是与法律条例有关。例如，HIPAA就包含了对静态加密数据的指导条例，这些静态加密数据与电子受保护的健康信息（Electronic
Protected Health Information简称EPHI）或者其他受法律保护的个人身份信息（Personally Identifiable Information简称PII）。
一些组织机构正在努力对存储于HDFS上面的静态数据进行加密，而这种加密是Hadoop自身并不提供的。然而，第三方库以及其他的产品能够配合Hadoop一起来满足这些需求，Rhino项目（在第10章讨论那样）正致力于解决Hadoop当中的这个问题。
企业安全集成
大多数的企业在他们内部都有各式各样的安全基础设施，包括进行身份认证的公钥基础设施（Public Key Infrastructure 简称PKI）组件、活动目录（Active Directory）、安全令牌服务（Security Token Service）、属性服务、用户认证的策略服务器，策略服务器提供了授权特许凭证，并且制定和执行访问控制决策。Hadoop自身的安全功能并不能总是能够嵌入或者集成每一个组织的安全基础设施。当安全需求要求企业应用要和一个组织的安全基础设施进行集成的时候，安全架构师的的职责就是设计出一套解决方案能够利用其它工具将Hadoop与这些安全基础设置进行集成起来。
保护使用Hadoop的企业应用的方法
近来，大量的项目，包括Hadoop附属项目，或者是专有的Hadoop发行版都许诺要强化Hadoop的安全。Hortonwork的Knox Gateway项目，Intel的安全加强版Hadoop的发行版，以及一些诸如Rhino等开源项目，Rhino已经发布了并且承诺帮助企业应用开发者来达到他们安全要求。不管怎样，每一个企业应用都不一样，每一个应用部署所需要的安全要求也不一样，认识到这一点非常重要。
在进入到具体细节之前，你必须理解为使用Hadoop的企业应用而提供的一些通用的基本要素和指导方针。对于这些基本要素和指导方针，很多项目在关注某些安全机制的时候出现了偏移，他们并不按照那些适用于任何项目的通用的指导方针。
➤确定你的安全需求 -- 理解你的安全需求非常重要。对于认证、访问控制、审计、加密、完整性、以及保密性的需求都取决于你的组织。相对于Hadoop运行时自身的安全（Hadoop自身的安全提供了针对执行查询或者运行工作的应用以及用户的访问控制），围绕Hadoop MapReduce工作的结果数据集的安全，你可能会提出这样问题。要和合适决策制定者交谈，以理解什么是需要的，这样你才能制定相应的计划。
➤从开始就围绕安全而设计 -- 这些项目的一个共同的重大的问题是最终还是试图改进安全性--这种做法导致了架构变得短期化并且脆弱，而且使得项目最终注定失败。如果你项目中存在类似于本章讨论的安全性需求，而你认为你只关注数据分析而在后来才去担心去保护你的方案的时候，那么你就会面临着非常大的风险。重点开发初期的高级安全架构的，这些架构可以和一些合适的权威专家一起讨论，以获得概念上的赞同。
➤不要保护你不需要保护的东西 -- 如果你为了达到本章讨论的某些目的而不需要安全性需求是，那么就不要采取安全性保护措施。不要让不必要的需求的加重复杂性，或者是负载的性能。
➤使用深度防御方法 -- 不要设想通过一个单独的安全性措施或者机制来阻挠或者阻止一次攻击或者是违反安全策略的行为。深度防御方法涉及到过个层次的防御。
➤记住大局 -- 理解你的数据的生命周期，如图12-1所示的那样。要明白提供安全性保护可能意味着在整个数据生命周期（从原始数据源的数据，到被转载到Hadoop集群中的数据，指导最终的结果数据）当中都要控制访问，以及维护和执行安全策略。
下面的部分就会深入研究满足某些安全性需求以及补充Hadoop自身安全性功能的方法。讨论会关注于三个主要的方法，这些方法配合Hadoop自身的机制构建企业安全的保护墙，在下一个部分当中，将讨论Apache Accumulo。
利用Accumulo的访问控制保护
Apache Accumulo是一个稀疏的、分布式的、分类 、多维的键/值存储方案，他具有单元级别的精细访问控制的特性。他是由NSA在2008年根据Google的BigTable的论文开发的，在2011年的时候Accumulo被发布到Apache开源社区里面。目前Accumulo已经成为Apache的*项目。Accumulo是一个高度可扩展的NoSQL数据库，他建立在Hadoop和Zookeeper之上。Accumulo被开发的一部分原因是要解决大数据的安全性问题。
Accumulo扩展了BigTable的数据模型，但是添加了一个元素以提供单元级别的强制基于属性的访问控制（Attribute-Based Access Control，简称ABAC）。所有被导入到Accumulo的数据都可以通过可视化的控制来标记，基于访问控制策略当中的可视化控制，数据分析师查询数据的时候，他们只能查看到被允许看到的那部分。Accumulo的API提供了可供你*实现客户端，自定义的客户端程序可以认证用户、和企业属性服务集成，企业属性服务可以拉取用户授权凭证以提供一定程度的访问控制。Accumulo同样提供了存储用户和授权信息的功能。
如图12-2所示，Accumulo是一个key/value的存储方案，Accumulo的key包含了5个元组。Accumulo中的Key是由Row
ID、Column Family、Column Qualifier、Column Visibility、Timestamp组合而成，这个5个元素的key关联一个value。
这个5元组的Key提供了原子性、局部性、独特性、访问控制和版本控制。需要注意的是Key当中的Timestamp提供了同一数据包含多个版本的功能，Timestamp根据不同的时间和日期。在很大程度上，Accumulo借鉴了BigTable的大部分数据模型，但是加入了可视化元素以提供面向数据的安全性--这就会只返回那些可视化标签满足于执行查询的用户或者应用的凭证的单元。
|
Accumulo以及HBase当中数据级安全性差异 |
|
HBase和Accumulo相似--都是运行在Hadoop上面的BigTable的实现的Apache项目。HBase和Accumulo都提供了相似的数据级安全性，但是是以不同的方式。正如第十章所讨论的，HBase提供了对每个表或者每个列的数据访问控制。在这点上面，HBase不提供单元安全性，而这正是Accumulo提供的。但是，目前在Intel的发行版本Rhino项目中已经在进行类似的工作，在不久Hbase也会支持基于单元的安全。 HBase能够很容易的集成Hadoop安全模型（使用Kerberos），而这种方式和Hadoop生态系统的其他项目保持了一致。另外一方面，Accumulo是Apache新的*项目，他包含了一个内置的访问控制数据库，而他没有采用和Hadoop生态系统的其他项目一样的方式。 HBase和Accumulo都很流行。由于Accumulo的单元级的安全性，在一些高级安全环境中，Accumulo更加普遍，Accumulo许诺提供和强制执行访问控制（Mandatory Access 简称MAC）以及其他不同的安全性相关的解决方案。 |
大多数的开发者都比较熟悉关系型数据库，这些数据库的表结构如表12-1所示，示例的表是一个二维模型。
表12-1:关系型数据库模型示例
在Accumulo结构中，相同的数据如表12-2所示，Accumulo中数据按照比较细的粒度存储，包括可见度（visibility）以及一个timestamp，其中timestamp可以使你跟踪超时的数据的改变。
表12-2:Accumulo数据模型中的数据
需要注意的是，在表12-2中，可见度被用安全标记进行了标记。这些安全标签能够被添加，使用AND/OR的布尔逻辑。例如，你可以提出如表12-3所示的授权策略，表12-3中授权凭证可以被新建以及和用户关联，以限制表中每一个单元的访问。
表12-3:安全策略以及对应的安全标签示例
在Accumulo的安全模型中，需要用户访问信赖的客户端（作为一个开发者，你可以编写这样的客户端）进行认证，客户端要负责认证用户，并且向Accumulo发送合适的授权信息。你可以选择集成你自己的认证和授权系统，或者你可以使用Accumulo内部的认证/授权的组件，该组件当中存储了用户和用户的授权凭证。本节当中会提供每种选择的例子。
一个简单的例子
让我们用一个大学的数据库作为例子，该大学从不同的部分和子机构当中搜集学生的信息。在例子当中，你会看到来自校园医疗中心、财务中心、大学管理、体育设施、大学警备人员的数据。很大范围内的数据都被收集了，并且能够被所有的机构查询，你可能被要求保护这些数据，这些要求包括如下几种：
➤学生的医疗检查记录只能被医疗人员或者是管理人员浏览。
➤大学体育课当中学生的与体育记录相关的记录只能对他们的教练、有时一些医疗人员可见
➤付款记录,成绩，如社会保险号码等敏感信息只能对大学管理人员所见
➤关于学生的校园警备记录只能对校园警察或者大学管理人员可见。
对于这个例子，让我们加载一些示样数据到Accumulo数据库中，如表12-4所示，在这个简单的例子中，有一个名叫Kirk Rest的学生，他有各种各样的信息，这些信息来自该大学的众多数据源。
表12-4 大学数据示例的Key/Value（待续）
表12-4 大学数据示例的Key/Value（续）
假设装载这部分信息的Accumulo存储是建立在一个测试Hadoop实例上面的。为此，你需要使用Accumulo的shell，该shell是Accumulo一个简单的客户端，能够被用来创建和修改表，同样能够被用来创建用户以及给用户指定授权凭证。因为本章将关注与安全性而不是Accumulo的细节，所以不会在本章提及装载数据的细节。
|
注意：由于不同版本的Accumulo使用了不同版本的Hadoop和Zookeeper，有时设置Accumulo是很大的挑战。一个开始Accumulo的简单的方法就是使用一个已经配置完了的虚拟机（VM）。Sqrrl公司的网站提供了一个亚马逊单机实例（Amazon Machine Instance 简称AMI），借助它可以快速的开始Apache Accumulo，Sqrrl公司也提供了一个Oracle VirtualBox的VM。具体细节，查看他们的网站http://www.sqrrl.com/ VM的网址：http://blog.sqrrl.com/post/40578606670/quick-accumulo-install/ |
Accumulo被优化成能够快速提取key的value的系统。为此，一个你开发的Accumulo客户端（在这里的情况中，客户端可以是Accumulo的shell）可以创建scanner，scanner可以迭代value。如你看到Listing 12-1，scan命令使得你迭代查询一张你新建名叫universitydata的表的value值（root用户被授权可以访问表中所有的内容）
为了证明单元可见性的例子，你创建如下几个用户：
➤一个医生（drhouse），你给他授予了MEDICAL 角色
➤一个管理员（denyseAccountant），你给他授予了ADMIN角色
➤一个教练（coachTark），你给他授予了COACH角色
➤一个警察局长（chiefDoug），你给他授予了POLICE角色
如Listing 12-2所示，你使用Accumulo shell给所有用户指定读取表的权限（授予他们每个人Table.READ权限），然后使用setauths命令为他们指定角色，这一步是为了设定可见度。
最后，为了显示Accumulo将会保护表中的数据，你用Accumulo sheel以每一个用户进行登录。你可以scan（或者迭代）整个universitydata表。Listing 12-3，显示了你可能如何用用户coachTark,drHouse,denyseAccountant和chiefDoug，并进行表迭代，表根据每一个用户的权限进行访问控制。
从Listing 12-3可以看到，Accumulo可以根据每一个用户授权控制来限制访问，这一点可以通过使用Accumulo shell来证明。现在，让我们来使用JAVA建造一个Accumulo Client，来证明本例中同样级别的访问控制，该客户端同时还会和企业内的身份识别和访问管理基础设施集成。
因为Accumulo适合于集成企业的基础设施，Accumulo拥有一个灵活的模型。如前面的提及的那样，Accumulo Client的责任就是认证用户并提取用户的授权凭证，发送凭证给Accumulo以进行处理。只要Accumulo的表中数据的可见性属性被用与你企业属性存储系统中相同的属性和角色标记了，数据的可见度就会工作良好。如果不是，你会需要在Client端中对这些从属性存储系统中拉取的属性进行一下处理，以保证他们具有相同的特征。
为了证明这点，让我们通过一个简单的例子，该例子描述了如何编写一个简单的Client来认证用户，认证可以通过你选择的认证机制来完成，以及从由你选择的属性服务或者LDAP
目录拉取授权凭证。
Listing 12-4 显示了一个例子，该例子使用JAVA类来连接Accumulo。为了连接，你必须使用Connector来建立一个Accumulo连接。为此，你需要首先连接到Zookeeper实例上，该Zookeeper实例使用ZookeeperInstance类来跟踪Accumulo，ZookeeperInstance会返回一个connector。
一旦你建立了一个连接，你想要认证一个用户。在这种情况下，对于这个简单的例子来说，你从命令行获取用户，并且将之传递给一个外部类叫做CustomAuthenticator，该类简单的显示了你可以使用另外一个在Accumulo外部的认证机制以及授权机制。在CustomAuthenticator类中，你把从命令行扫描到的用户名和密码传递到authenticate()方法中。如果一个用户成功通过认证，然后你就可以从外部的存储系统中拉取用户的授权凭证，凭证在Accumulo的类org.apache.accumulo.core.security.Authorizations类被返回。最后，如在之前的例子中所示的那样，你创建一个scanner来迭代在同一个表中value值，然后答应结果。
Listing 12-5 显示了命令行的结果。在这个例子中，你设置了一个外部的LDAP目录，该目录中有一个用户名为joeUser，他的角色为ADMIN。
本例中被认证的用户，joeAdmin，并不像之前的那些例子那样被存储在Accumulo当中。如这里表示的那样，你可以编写一个Client来认证一个用户，从企业的存储系统中拉取授权凭证，以及查询Accumulo的数据。
关于Apache Accumulo还有很多东西--很多不能在本章中覆盖到。然而，重要的是为了数据安全性使用Accumulo的组织机构，要认识到Accumulo只是企业安全解决方案中的一个方面。企业安全需要深度防御，必须覆盖到数据的整个生命周期里面，而不仅仅在Hadoop当中的数据。
加密静态数据
加密Hadoop中静态数据已经是很多项目中的热门话题了--这些项目中一些是开源的，一些是商业的。Hadoop自身并不提供这样的加密功能。目前，很多公司正在保护位于不同发行版的Hadoop中的敏感数据,不仅仅是保护敏感信息,也迎合如HIPAA这样的法律或者其他安全法规.很多组织机构想要利用加密静态数据来保护避免恶意用户获取对DataNode的未经授权的访问。
目前已经提出的一些解决方案中，包括Gazzang zNcrypt，该方案为Cloudera的发行版提供了数据安全性保护。于在2013早期发布的Intel的Hadoop发行版，已经经过优化来加密静态数据，这需要在使用该公司的Xeon处理器。好像，每天都有新的解决方案出现--但是到目前为止，所有的解决方案要么就是私有的，要么需要将你绑定在某一Hadoop的发行版中。
如第10章中提到的那样，Rhino项目（又Intel贡献给Apache社区）包含了增强功能，包括分布式Key管理，和静态数据加密功能。Hadoop开发社区目前正在考虑将这功能也放在未来的Hadoop版本中。
不管你用什么机制来为Hadoop加密静态数据，你必须明白静态加密功能的非故意的影响，这点很重要。如果你需要一种加密静态数据的解决方案，记住加密会影响到你的性能。如果你认为你的MapReduce工作可能比目前预想的要慢，想象加密会给性能带来什么样的影响。Intel的Hadoop发行版通过优化来做加密和解密，这种优化是通过使用特定处理器的硬件来完成的。记住只有Intel的Hadoop发行版是结合他自己的硬件加速器。企业架构师需要衡量加密静态数据给应用带来的影响--如果你确实需要这种功能，那么要根据性能来进行规划。
目前，你可能会由于多个原因想避免实施静态数据加密，除非你继续要实现。首先，静态数据加密领域是非常复杂的，因为分布的数据和key管理。另外，Rhino项目给这个领域带来的提高即将到来，但是在此之前，你可能会绑定在某一特定的发行版或者厂商上面。最后，如提到的那样，存在静态数据加密来带来的性能上面的后果。如果你的数据是如此的敏感以至于你正在探索加密静态数据的可能性，下面的部分可能会是一个解决方案。
网络隔离和分离方法
如前面提到的那样，拥有保密和敏感的数据的组织机构可能一直会用网络隔离的方法来隔离他们的Hadoop集群，用这种方法来满足他们的安全需求。这些机构通常会基于用户级的授权来控制对某个单独集群的访问，这种用户级的授权机制通常使用物理安全来作为保护机制。其他一些机构会使用低限制的方法，比如分离网络，但是允许受信任服务器和工作站能够在两个网络里面进行传输。
这些方法仍然是一个可行的选择，原因包括：
➤安全性集成的复杂性 -- 如果你的安全策略非常严格，你的数据非常敏感，以至于你不得不需要集成大量Hadoop自身未提供的安全性控制到Hadoop当中，考虑使用网络隔离，将它懂其他网络中分离出来，并且限制只允许被授权的用户访问。如果你做了，那么你只需要担心Hadoop结果数据集的发布，而不是Hadoop运行时的安全性。这就最小化了你的整体风险，并且能够减少大量的工作。
➤性能 -- “安全是性能的敌人”这句话经常被提及。在一个解决方案中，你加入了越多的安全性机制的时候，解决方案就会变得越慢。在保护Hadoop的时候，这点确实如此，特别是如果你考虑使用第三方的工具来加密和解密位于HDFS上面的数据的时候。许多人都会使用网络隔离的方式来轻易的避免了性能损耗。
➤数据集的差异化安全性 -- 你组织的一些数据可能只能发布给某些特定人群。在这种情况，Hadoop工作的结果集也同样敏感。虽然一些和Hadoop相关的工具（比如HBase、Accumulo）能够提供一种在列级（HBase）和单元级（Accumulo）过滤访问的方式，其他使用Hadoop的工具不会提供这种安全级别。如果你正在运行Java MapReduce工作以建造某些结果集，并且使用了大量的不通的工具，也许考虑根据可访问的人群来分离集群是一个比较聪明的做法。
➤Hadoop安全性蓝图的演进 -- 针对Hadoop的许多新的产品，发布品、发行版本都提供了新的安全特征。如第10章提及的，针对Hadoop的安全性的增强在近几年即将到来。即将而来的改变会影响到使用Hadoop企业的应用，在明白这些改变带来的后果之前，有很多组织机构正在选择网络隔离的模型。
➤在集成之前进行数据安全评审 -- 由于网络隔离的方式不能对位于其他网络上面企业应用的数据进行实时访问，在企业应用使用资料之前，网络隔离允许审查和过滤这些资料，这减小了可能的保密性和隐私的侵犯。（对于实时Hadoop来说网络隔离肯定是一把双刃剑，并且为了发布企业应用使用的数据集，还需要一定的处理）。
企业应用安全中，网络隔离能在很多方式实现，图12-3 显示了一种方式。一个组织机构创建了一个“Data Analytics”网络，他与组织的企业网分通过一个物理的“air gap”离开来，以阻止数据在两个网络之间进行传输。在“Data
Analytics”网络中，用户恰当访问控制的数据分析师在Hadoop集群中进行查询和MapReduce操作，对于这个网络的访问控制又物理安全设备或者通过对执行查询的客户端机器进行认证。
图 12-3 “Air
gap”网络隔离内的导入导出工作流
为了支持使用这些结果数据集的企业应用，需要开发和利用一些非常重要的工作处理：
- 首先，任何需要被分析的数据都必须从在企业网中数据库和应用中提取到，写入，并带入到这个隔离的网络。
- 一旦数据准备好被分析了，并且也被装载到集群中，Hadoop MapReduce工作就能运行，直到结果能被检阅。
- 基于最终的结果，结果集必须被用授权策略进行标记，该授权策略也能够被外部的企业应用控制，或者结果集必须被过滤，保证敏感、机密或者保密的数据被移除掉。
- 一旦数据集被过滤或者被用访问控制策略标记过了，数据集就被写入到介质中，导入到企业应用中。
对于许多机构，由于要牵涉到两个网络，这就需要一个笨重的处理，就需要一个从原网络导出数据，并导入到数据分析网络，进行分析，过滤，然后为了企业应用准备结果集。即使这个过程非常笨重，然而，在数据非常敏感的时候，许多组织机构都会采用这种方式。
因为牵涉的复杂性，许多组织都转向一个类似的模型，该模型限制了企业网内的可信赖主机到数据分析网络的流量，如图12-4所示，ETL处理过程可以跨网络进行，移除了之前描述的第一步。
图 12-4 单向传输的网络隔离
有些机构优先选择Apache的Accumulo来对数据进行访问控制，他们把结果集进行数据过滤之后，发布到企业网中--比如，创建一个“企业网用户”，该用户拥有的凭证等于该网络最低级别的授权。根据该用户过滤数据，通常会使结果集能够很容易的传送，而不用担心信息的非故意的泄露。
网络隔离可以通过其他很多种方式来实现--这只是其中的一些。其他涉及到Hadoop集群网络隔离方式需要根据数据的类型，一些低限制的方式需要允许连接到企业网络中机器或者从企业网络中的机器连接出来，这需要使用访问控制列表（ACLs）来对可信赖的主机进行限制。
你的解决方案中对于企业安全性的每一部分都依赖于你的组织机构的安全需求--两个机构很少一样，无论如何，本章中示例和指导意见应该能够帮助你构建你企业的安全解决方案。
总结
本章从安全策略以及以数据为中心的观点出发，为你提供了关注于数据的生命周期的企业安全视图。安全架构师在能够利用Hadoop和其他补充安全工具来解决企业安全性的不同方面，要理解这个大局，这点很重要。
本章开头介绍了开发使用Hadoop的企业应用的安全关注点的一个总的简图。你学习了Hadoop自身没有解决的一些安全挑战点--包括数据集安全，差异化隐私，静态数据加密。你看到很多结合Hadoop构建企业安全的解决方案的方法，并且学习了一些指导意见和示例。你学习了如何使用Apache Accumulo来实现单元级的安全，同时了解了静态数据加密和一些可用的选择。你同时还学习了网络隔离的一些方法，这些方法被许多关心敏感数据暴露的机构所采用。
安全问题目前正成为Hadoop中不管进化的话题，在接下来的几年时间内Hadoop将会成长的领域。第13章关注于其他一些即将到来的Hadoop的增强功能，其讨论趋势正涌现出来，并且将会在未来不断成长。