Hadoop 安全实践指南（二）

宁睿 · 2024-9-25 10:07:29

原文：Practical Hadoop security
协议：CC BY-NC-SA 4.0
六、Hadoop 日志：关联息争释

有一天，一位非常恼火的商业智能主管(在一个客户站点)冲进我的办公室，抱怨此中一个承包商从生产服务器上删除了一些分类账记载。她收到了一份逐日摘要审计日志陈诉，显示有 300 个分类账记载(财务生意业务条目)被删除！首先，有题目的承包商不应该接触到它们。所以我进行了调查，结果发现客户使用的 ERP(企业资源规划)软件有一个缺陷，它通过“公共”脚色提供访问。如果我没有启用审计日志记载，我就不会发现这个错误，这证实白审计日志记载从安全角度来看是多么紧张。
HDFS 审计日志记载的目的是记载 Hadoop 内的所有 HDFS 访问活动。MapReduce 审核日志包含所有已提交作业的条目。此外，Hadoop 保卫进程日志文件包含启动消息、内部诊断信息、错误、信息或警告消息、配置日志等。您可以过滤以后不需要的信息，但记载所有访问(包罗授权访问)会很有资助。即使授权用户也可以实验未授权的任务。例如，一名警察可能在没有适当批准的环境下对其女友的罚单记载进行了未经授权的更新。此外，对于被审核的应用步伐或任何符合 SOX 的应用步伐，必须审核对应用步伐中数据对象(例如，表)的所有访问，以及审核更改被审核的应用步伐中任何数据的所有作业活动。
在本章中，我将讨论如何为 Hadoop 启用审计，以及如何捕捉审计数据。Log4j 是 Hadoop 日志记载的核心，无论是审计日志还是 Hadoop 保卫进程日志。我将从对 Log4j API 以及如何使用它进行审计日志记载的高级讨论开始，然后讨论 Log4j 日志记载级别及其目的。在概述了保卫进程日志及其捕捉的信息之后，您将了解如何将审计与 Hadoop 保卫进程日志关联起来，以有用地实现安全性。
使用 Log4j API
Apache Log4j 是一个基于 Java 的实用步伐或框架，由 Ceki Gülcü创建，厥后成为 Apache 软件基金会的一个项目。日志记载是任何开发周期的紧张组成部分，在没有调试器的环境下(通常是这样)，它是排除应用步伐代码故障的唯一工具。使用正确的日志记载类型非常紧张——可靠、快速、灵活的日志记载类型。Log4j 满足这些要求:

可靠性 是对相关错误或状态信息显示无任何异常的期望。自定义日志记载例程容易出现错误，由于一些消息由于逻辑错误而无法显示。Log4j 没有这个题目。这个日志系统经过了很好的测试，并且已经流行了很长时间。Log4j 固然可以包管日志输出逻辑的可靠性。
速度指所使用的测井步伐的相应时间。使用 Log4j，Logger类被实例化(创建一个实例),而不是与接口交互，从而产生超快的相应。决定记载什么(基于日志记载级别)只涉及基于记载器条理结构的决定，这很快。由于使用了使用结构和附录的预格式化，日志消息的输出很快；通常，实际的日志记载大约需要 100 到 300 微秒。使用 simple Layout(Log4j 最简单的结构选项，在“结构”一节中有解释)，Log4j 可以像 print 语句一样快速地记载日志(它只是将输入文本打印到控制台或文件中)！
灵活性 是指对日志记载系统进行更改的容易程度(无需修改使用它的应用步伐二进制文件)以及使用修改后的日志记载的应用步伐的易用性。例如，使用 Log4j，您可以使用多个日志目的地(也称为 Appenders)将输出定向到两个目的地，比如控制台和日志文件。只需修改 log4j.properties 配置文件来进行这一更改；不需要修改代码。

固然，包含状态或错误消息的最简单的方法是将它们直接插入到代码中。那么，与在应用步伐代码中插入解释或使用自定义日志模块相比，使用 Log4j 进行日志记载有什么上风呢？嗯，插入解释和删除解释是一个乏味且耗时的过程,依赖于步伐员的专业知识——他们可能会在测试后忘记删除解释。获得正确的批评百分比(偶然太多，偶然太少)是困难的，并且有选择地显示那些批评是不可能的。此外，对解释的任何更改都涉及到代码的重新编译。最后，一个定制的日志模块可能会有错误，或者可能没有 Log4j API 那样丰富的功能。
通过配置文件，Log4j 允许您在运行时设置日志行为，而无需修改应用步伐二进制文件。日志记载的一个主要题目是它对性能的影响。任何日志记载本质上都低落了应用步伐的速度，但是对于 Log4j，对性能的影响微乎其微。例如，对最新发布的 Log4j 2(版本 2)的独立测试显示，它每秒可以输出高达 1800 万条消息(完整结果请参见 Christian Grobmeier，“Log4j”:性能靠近疯狂，”www.javacodegeeks.com/2013/07/Log4j-2-performance-close-to-insane.html)。对于 Log4j，影响被限制在纳秒到微秒的范围内，这取决于您的 Log4j 配置、日志记载级别和 Appenders。
Log4j 日志框架的主要组件是记载器、附加器、结构和过滤器。因此你可以更好地理解它们是如何一起工作的，图 6-1 阐明白它们在框架中的位置。

图 6-1 。Log4j 框架及其主要组件
接下来的部分将具体讨论这些组件，并提供关于它们的作用以及它们在框架中简直切脚色的信息。
记载器
记载器 是一个命名实体，它与一个配置(LoggerConfig)相关联，随后与一个日志记载级别相关联。为了让 Log4j 日志记载正常工作，您需要一个定义了相关配置的根日志记载器。根记载器定义默认配置(附加器、结构等。).那么，这些日志记载级别是什么，它们是如何相互关联的呢？
Log4j 的日志记载级别
Log4j API 有七个日志记载级别。它们按照严重性顺序记载信息，每个级别都包含所有更高的级别。例如，日志级别INFO包罗信息性消息、警告(包罗更高级别的WARN)、非致命错误(包罗更高级别的ERROR)和致命错误(包罗更高级别的FATAL)。类似地，日志级别WARN包罗警告、非致命错误和致命错误。图 6-2 总结了这些内含物。

图 6-2 。Log4j 测井级别和内含物
七个日志级别如下:

ALL :这是可能的最低日志级别，它记载包罗更高级别的所有消息(例如，致命错误、非致命错误、信息性消息等。)
TRACE :顾名思义，这个级别比调试级别记载更细粒度的信息事故。
DEBUG :记载对调试应用步伐最有用的细粒度信息事故。
INFO :记载信息性消息，以更粗粒度的级别突出应用步伐的进度。
警告:记载埋伏的有害环境。
ERROR :记载可能仍旧允许应用步伐继续运行的错误事故。
FATAL :记载可能导致应用步伐中止的非常严重的错误事故。

请留意，启用的TRACE和DEBUG级别可被视为生产系统中的严重安全缺陷，并可能被漏洞扫描器陈诉。因此，请仅在解决题目时使用这些日志级别，并确保在解决题目后立即禁用它们。
记载器继承
记载器名称区分巨细写并分层命名。如果一个记载器的名字后面跟一个点是其子女记载器名字的前缀，那么这个记载器就是另一个记载器的先人。如果一个日志记载器和它的子女日志记载器之间没有先人，那么这个日志记载器就是子日志记载器的父代。举个例子，那个名叫 L1 的伐木工。L2 是名为 L1.L2.L3 的记载器的父亲，L1 也是 L1 的父亲。L2 和 L1.L2.L3 的先人(认为是祖父母)。根记载器位于记载器条理结构的顶端。
可以为记载器分配默认的日志级别。如果一个级别没有分配给记载器，那么它将从其近来的先人那边继承一个已分配的级别。给定记载器 L1 的继承级别即是记载器条理结构中的第一个非空级别，从 L1 开始，在条理结构中向上朝着根记载器前进。为了确保所有记载器都继承一个级别，根记载器总是有一个指定的级别。图 6-3 包含了一个级别继承的例子。

图 6-3 。记载器级别继承
如你所见，伐木工 L1 和 L1。L2.L3 已经分配了日志记载级别。伐木工 L1。没有为 L2 分配日志记载级别，它从其母公司 L1 继承了 L1 日志记载级别。如果日志哀求的级别高于或即是其记载器的级别，则称该日志哀求已启用。否则，哀求将被禁用。
大多数 Hadoop 发行版都在/etc/Hadoop/conf或$HADOOP_INSTALL/hadoop/conf目录下的log4j.properties中定义了五个标准记载器(图 6-4 )。为了使 Log4j 日志记载正常工作，必须定义一个根日志记载器(带有相关配置)。安全记载器记载安全审计信息。审计记载器记载 HDFS 和 MapReduce 审计信息，而作业摘要记载器记载关于 MapReduce 作业的摘要信息。一些发行版还为 Hadoop metrics、JobTracker 或 TaskTracker 定义了记载器。

图 6-4 。记载器和默认日志级别
图 6-5 是来自log4j.properties的 HDFS 审计记载器的示例条目。

图 6-5 。HDFS 审计记载者
maxfilesize设置是临界巨细(此处为 256MB ),在此之后，日志文件将“滚动”并创建一个新的日志文件；maxbackupindex(本例中为 20)是要创建的日志文件的备份副本数量。在此示例中，当日志文件滚动 21 次时，最旧的文件将被擦除。其他记载器的属性在log4j.properties文件中以类似的方式指定。
附加器
对于 Log4j 框架，输出目的地被称为附加器。目前，附加器存在于控制台、文件、GUI 组件、长途套接字服务器、JMS、NT 事故记载器和长途 UNIX 系统日志保卫进程中。换句话说，您可以将此中任何一个定义为日志记载的输出目的地。从 Log4j Version 2 开始，您还可以异步记载日志，将控制权从日志记载器通报回应用步伐，同时 I/O 操纵由单独的线程或进程在背景实验。异步日志记载可以提高应用步伐的性能。
追加加法
一个记载器可以连接多个附加器。给定记载器的每个启用的日志记载哀求将被转发给该记载器中的所有附加器以及条理结构中更高的附加器。这是一个默认的行为，称为追加器累加性，可以通过在log4j.properties配置文件中将累加性标志设置为false来轻松禁用。
思量图 6-6 中的例子。如果将控制台 Appender 添加到根日志记载器，那么所有启用的日志记载哀求都将显示在控制台上。此外，如果一个文件附加器被添加到记载器 L1，L1。L2 和 L1。L2。L3，然后记载 L1 L1 的哀求。L2 和 L1。L2.L3 将被写入适当的文件并显示在控制台上。现在假设您将 Logger L4 的加法标志设置为false。这有用地断开了 L4 及其子节点与日志输出向上传播的连接。由于 Logger L4 的父。L5(在本例中是 L4)将其可加性标志设置为false，L4。L5 的输出将只指向 L4 中的 Appenders。L5(在这种环境下没有)及其先人直到并包罗 L4 ( File4)，但是不会传播到 L1、L2 或 L3。图 6-6 列出了结果。

图 6-6 。Log4j 框架的附加器可加性
主要 Hadoop 发行版经常使用的附加器有:

控制台追加器:在控制台上显示日志信息
文件附加器:将日志信息写入一个特定的文件，该文件在log4j.properties中定义
滚动文件追加器:将日志消息写入文件，并根据巨细滚动
逐日滚动文件追加器:将日志消息写入文件并逐日滚动

使用与 HDFS 审计记载器雷同的条目(图 6-5 )，思量图 6-7 中的附录部分。

图 6-7 。HDFS 审计记载器的滚动文件附加器
在图 6-7 中，我将RollingFileAppender与 HDFS 审计记载器一起使用。输出按照结构(PatternLayout)和定义的转换模式格式化(我稍后将讨论结构和转换模式)，如下所示:

2014-02-09 16:00:00,683 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE) ip=/127.0.0.1 cmd=getfileinfo src=/user/sqoop2/.Trash/Current dst=null perm=null

复制代码

留意 HDFS 审计输出可能会产生一个大文件。因此，每天或按巨细将它回滚到一个新文件是一个好主意。
结构
结构是日志条目的输出格式。它可以与一个 Appender 相关联，并且可以在通过 Appender 通报哀求之前，根据您的规范格式化日志记载哀求。
以一种易于阅读息争释的方式组织和出现信息是很紧张的。通常有必要将日志信息通报给长途机器上运行的另一个错误处理惩罚步伐。因此，决定记载信息的结构很紧张。这就是Layout对象所提供的。
结构使用转换模式来格式化和输出日志消息。转换模式由格式修饰符和转换字符组成。例如，修饰符t输出天生日志事故的线程的名称，转换字符%5p使用五个字符显示(或写入)日志级别，在左边填充空格。因此，日志级别INFO显示(或写入)为"INFO"。
可以在log4j.properties文件中为一个追加器指定一个结构。例如，我在图 6-8 的中指定了 PatternLayout 作为一个结构(用于我们的 HDFS 审计日志附录)。

图 6-8 。HDFS 审计记载器的模式结构
图 6-8 中的转换图形%d{ISO8601} %p %c{2}: %m%n输出为:

2014-01-27 20:34:55,508 INFO FSNamesystem.audit: allowed=true ugi=mapred (auth:SIMPLE) ip=/127.0.0.1 cmd=setPermission src=/tmp/mapred/system/jobtracker.info dst=null perm=mapred:supergroup:rw-------

复制代码

第一个字段是 ISO8601 (YYYY-MM-DD HH:mm:ss，SSS)格式的日期/时间。第二个字段是日志语句的级别或优先级。第三个是类别，第四个字段是消息自己，第五个字段是行分隔符(newline 或/n)。
Apache Log4j 提供了几个Layout对象:

简单结构 : org.apache.log4j.SimpleLayout为日志消息提供了非常根本的结构。它只包罗日志信息的级别和日志消息自己。如果使用简单结构而不是 PatternLayout:
1. INFO allowed=true ugi=hdfs (auth:SIMPLE) ip=/127.0.0.1 cmd=getfileinfo src=/user/sqoop2/.Trash/Current dst=null perm=null
复制代码
，这就是 HDFS 审计记载器的日志消息(来自图 6-8 )的输出方式
Thread-Time-Category-Context Layout (TTCCLayout): This Layout outputs the invoking thread, time (in milliseconds since application started), the category or Logger used to create this logging event, and nested diagnostic context. All these properties are optional and if they are all disabled, the Layout will still write out the logging level and the message itself, just like Simple Layout. If you specify the following options in log4j.properties:
1. #configuring the Appender CONSOLE
2. log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
3. log4j.appender.CONSOLE.layout=org.apache.log4j.TTCCLayout
4. #configuring the Layout TTCCLayout
5. log4j.appender.CONSOLE.layout.ThreadPrinting=false
6. log4j.appender.CONSOLE.layout.ContextPrinting=false
7. log4j.appender.CONSOLE.layout.CategoryPrefixing=false
8. log4j.appender.CONSOLE.layout.DateFormat= ISO8601
复制代码
您将获得以下输出:
1. INFO allowed=true ugi=hdfs (auth:SIMPLE) ip=/127.0.0.1 cmd=getfileinfo src=/user/sqoop2/.Trash/Current dst=null perm=null
复制代码
DateLayout :顾名思义，这种结构提供了 NULL(不显示日期/时间)、RELATIVE(显示应用步伐启动后经过的时间)、DATE (dd MMM YYYY HH:mm:ss、SSS 模式；最终 SSS 是应用步伐启动后经过的时间)、绝对时间(HH:mm:ss，SSS 模式)和 ISO8601 (yyyy-MM-dd HH:mm:ss，SSS 模式)。
HTMLLayout :您的应用步伐可能需要在一个美观的 HTML 格式文件中出现日志信息。org.apache.log4j.HTMLLayout是相关对象。使用 HTML 格式的日志文件的一个很大的优点是，它可以作为网页发布，以便长途查察。
XMLLayout :为了以可移植(跨多个应用步伐模块)的格式出现日志信息，Log4j 提供了org.apache.log4j.xml.XMLLayout对象。需要留意的是，最终输出是而不是一个格式良好的 XML 文件。这个Layout对象产生大量的<log4j:event>元素形式的日志信息。
PatternLayout :您可以使用这种结构，使用同等的模式来“格式化”或输出日志消息，以便于外部实体使用它们。相关的结构对象是org.apache.log4j.PatternLayout 。格式由格式修饰符指定(如m写日志信息，p写日志级别信息)，转换模式如%d{ISO8601} %p %c{2}: %m%n。显示(或写入)信息由转换字符指定。例如，%10c指示记载器名称必须是 10 个字符，如果它更短，就在左边添加空格填充。指定%-10c表示应该向右添加空格填充。有关 PatternLayout 类和转换字符的更多具体信息，请参见:http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html。

过滤
过滤器评估日志事故，并允许或不允许它们被发布。有几种类型的过滤器，它们根据事故数量(BurstFilter)等标准筛选失事故；匹配正则表达式(RegexFilter)的日志事故消息；或者事故 ID、类型和消息(StructuredDataFilter)。过滤器的类型决定了您需要指定它的位置:

上下文范围的过滤器作为配置(LoggerConfig)的一部分进行配置，并在将事故通报给记载器进行进一步处理惩罚之前对其进行评估。
记载器过滤器是为记载器配置的，并在记载器的上下文范围过滤器和日志级别之后进行评估。
Appender 过滤器是为 Appender 配置的，它确定特定的 Appender 是否应该发布事故。
Appender 引用过滤器是为记载器配置的，它确定记载器是否应该将事故路由到 Appender。

请留意，所有这些过滤器都需要在您的log4j.properties文件中的适当部分(针对记载器或附加器)指定。例如，图 6-9 显示了来自log4j.properties的一个部分，它定义了一个 RegexFilter 来捕捉仅用于登录根的 HDFS 审计事故:

图 6-9 。HDFS 审核记载器的 RegexFilter
同样，您可以使用其他类型的过滤器来防止捕捉不需要的事故，这将有助于保持较小的审计日志巨细，并使关注特定题目变得更加容易。
查察 Hadoop 审计日志和保卫步伐日志
正如您已经了解到的，您可以使用 Log4j 组件为很多目的天生日志输出(例如，调试、操纵统计、审计)。Log4j 输出的日志数据依次由系统保卫进程天生，特定类型的数据可能存在于多个位置。如何连接和分析来自不同来源的数据，以获得系统操纵、历史和状态的总体视图？关键是 Hadoop 的审计日志。本节将讨论哪些保卫进程天生哪些数据，审计捕捉哪些类型的数据，以及如何使用 Hadoop 审计日志来提出安全发起。
为了获得完整的系统图片，您需要了解 Hadoop 保卫进程或进程(天生日志)记载了什么类型的数据，以及这些日志文件驻留在那里。您还需要了解捕捉的数据与配置的日志记载级别有何不同。例如，来自 HDFS 的审计数据没有实验的作业的细节。该数据存在于其他地方，因此将职务与 HDFS 访问审计关联起来需要一些工作。您必须知道 JobTracker、TaskTracker (MapReduce V1)和 ResourceManager (MapReduce V2)的日志在那里，或者任务尝试的日志数据存储在那里。您将需要它来对数据访问(谁/什么/那里)进行完整的审计，并且在出现安全漏洞时，您肯定会需要它。
Hadoop 审计的一个主要题目是，没有直接或简单的方法将审计数据与作业数据关联起来。例如，JobTracker 和 TaskTracker 日志(以及任务尝试日志数据)可以提供已实验作业的具体信息以及与作业相关的所有统计信息。但是，如何将这些数据与只有所有 HDFS 访问细节的审计数据联系起来呢？在本章的后面，你将会学到几种可能的方法。
审计日志
Hadoop 中的审计是使用 Log4j API 实现的，但默认环境下是不启用的。Hadoop 提供了一个 HDFS 审计日志，用于捕捉对 HDFS 的所有访问，以及 MapReduce 审计日志，用于捕捉关于 Hadoop 集群的所有已提交作业的信息。使用位于$HADOOP_INSTALL/hadoop/conf directory ( $HADOOP_INSTALL是 Hadoop 的安装目录)的hadoop-env.sh配置文件中定义的环境变量HADOOP_LOG_DIR来指定审计日志的位置。审计日志文件名在log4j.properties文件中定义，默认为hdfs-audit.log(针对 HDFS 审计日志)和mapred-audit.log(针对 MapReduce 审计日志)。您还不能使用log4j.properties为纱线定义审计日志；这仍在进行中(参见“将 YARN 审计日志添加到 log4j.properties”，https://issues.apache.org/jira/browse/HADOOP-8392)。
要启用审计，您需要修改log4j.properties配置文件，将适当记载器的记载级别从WARN更改为INFO。您将在/etc/Hadoop/conf目录或$HADOOP_INSTALL/hadoop/conf目录中找到该文件，此中$HADOOP_INSTALL是 Hadoop 的安装目录。log4j.properties定义 NameNode 和其他 Hadoop 保卫进程(JobTracker、TaskTracker、NodeManager 和 ResourceManager)的日志配置。例如，要启用 HDFS 审计，请在log4j.properties文件中查找这一行:

log4j.logger.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=WARN

复制代码

将WARN替换为INFO以启用 HDFS 审计，并确保为每个 HDFS 事故在 HDFS 审计日志中写入一个日志行。
同样，要启用 MapReduce 审计，请将其记载器设置为 INFO 级别:

log4j.logger.org.apache.hadoop.mapred.AuditLogger=INFO

复制代码

图 6-10 显示了log4j.properties中定义 HDFS 审计配置的部分。

图 6-10 。HDFS 审计日志记载配置
Hadoop 保卫进程日志
Hadoop 保卫进程日志是由 Hadoop 保卫进程(NameNode、DataNode、JobTracker 等)天生的日志。)并位于/var/log/hadoop下；实际目录可能会因所使用的 Hadoop 发行版而异。可用日志如下:

NameNode 日志(hadoop-hdfs-namenode-xxx.log)包含有关文件打开和创建、元数据操纵(如重命名、mkdir 等)的信息。
DataNode 日志(hadoop-hdfs-datanode-xxx.log)，包含有关 DataNode 访问和数据块修改的信息。
二级 NameNode 日志(hadoop-hdfs-secondarynamenode-xxx.log)，包含有关 FSimage 编辑应用、新 FSimage 天生和 NameNode 传输的信息。
JobTracker 日志(hadoop-xxx-mapreduce1-jobtracker-xxx.log)，包含有关已实验作业的信息。JobTracker 为集群上运行的每个作业创建一个 xml 文件(job_xxx_conf.xml)。XML 文件包含作业配置。此外，JobTracker 为作业创建运行时统计信息。统计数据包罗任务尝试、任务尝试的开始时间和其他信息。
TaskTracker 日志(hadoop-xxx-mapreduce1-tasktracker-xxx.log)，包含有关已实验任务的信息。TaskTracker 为任务尝试创建日志，包罗标准错误日志、标准输出日志和 Log4j 日志。
ResourceManager ( yarn-xxx-resourcemanager-xxx.log)和作业历史服务器日志(mapred-xxx-historyserver-xxx.log)，包含有关作业提交、视图或修改的信息。这些仅在使用 MapReduce V2 或 YARN 时可用。

与审计日志一样，您可以在配置文件log4j.properties中指定 Hadoop 保卫进程的日志记载级别，如果需要，每个保卫进程可以有不同的日志记载级别。例如，您可以将 HDFS 的审计日志记载器设置为INFO级别，并指示 TaskTracker 在TRACE级别记载日志:

log4j.logger.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=INFO
log4j.logger.org.apache.hadoop.mapred.TaskTracker=TRACE

复制代码

请留意，其他组件(例如，蜂巢、HBase、猪、Oozie 等。)在自己的配置目录中有对应的log4j.properties文件。
任何可运行的 Hadoop 集群都有很多在不同时间实验的筹划(和未筹划的或暂时的)作业，由任何批准的用户提交。如上所述，将作业日志与通过审核捕捉的 HDFS 访问日志相关联是一项挑战。例如，思量审计记载中的典范行:

2013-10-07 08:17:53,438 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE) ip=/127.0.0.1 cmd=setOwner src=/var/lib/hadoop-hdfs/cache/mapred/mapred/staging dst=null perm=mapred:supergroup:rwxrwxrwt

复制代码

这一行只说了一个下令(在本例中为setOwner)是在源文件上实验的，但没有指出它是否是作为作业的一部分实验的。
您需要参考相应的 JobTracker 或 TaskTracker 日志来查察当时是否有任何作业正在实验，或者假设这是使用 Hadoop 客户端实验的特定操纵。因此，除了审计日志之外，您还需要维护其他 Hadoop 保卫进程或进程的日志，并将它们关联起来，以便进行有用的故障排除。
关联息争释日志文件
Hadoop 会天生大量日志。有审计日志和保卫进程日志，它们分别提供关于在网络它们的源上完成的处理惩罚的大量信息。然而，它们并没有形成在您的 Hadoop 集群上实验的所有处理惩罚的连贯、完整的画面。这就是为什么在解决题目或调查安全漏洞时，您需要关联这些日志。
将 Hadoop 审计数据与 Hadoop 保卫进程天生的日志关联起来并不简单，确实需要一点努力，但是结果非常值得。使用用户名或作业号以及 Linux 过滤器(例如 sed 或流编辑器实用步伐)，您可以关联数据并识别安全漏洞。
关联什么？
Hadoop 保卫进程记载了很多有用的信息，您还可以启用和网络审计日志。假设您有所有这些可用的日志，您应该关联什么？嗯，这取决于你要调查的事故。
在第三章的票务系统例子中思量一个可能的安全漏洞。如您所知，所有警察局每晚都会向警察总部的中央存储库发送票务数据。中央存储库将票据数据保存在一个 Hive 表中，该表包含每天的分区。每天，IT 专业人员都会使用收到的数据运行自动流程来添加新分区。
一天，一名 IT 专业人员决定资助他的女朋侪删除超速罚单记载。由于使用相关日志进行分析，他被捕了。他从传票表中删除了传票条目，但忘记了从司法相关的表中删除相应的条目，当案件要进行听证时，系统标志了错误。随后，进行了彻底的调查。让我们跟随它展开的轨迹；不专业的 IT 专业人员使用用户名RogueITGuy。
检测到错误时，系统管理员使用以下下令检查对 HDFS 的访问:

HDFS 审计日志 :该日志提供了用户在集群上实验的所有下令的具体信息。由于Ticket_details是丢失记载的表，调查人员将留意力集中在它上面，过滤掉用户root和 HDFS 超级用户hdfs(由于两者都是暗码受控的系统用户)的访问，以获得访问过Ticket_details的用户列表。为了过滤，调查人员(包罗系统管理员在内的团队)使用了以下 shell 下令:
1. grep Ticket_details hdfs-audit.log | grep -v 'ugi=root' | grep -v 'ugi=hdfs'
复制代码
(The -v option for command grep filters records with the keyword specified after the option.) The results included normal user activity plus the following suspicious activity by a user RogueITGuy:
1. 2014-03-06 22:26:08,280 INFO FSNamesystem.audit: allowed=true ugi=RogueITGuy (auth:SIMPLE) ip=/127.0.0.1 cmd=getfileinfo
2. src=/Ticketing/Ticket_details_20140220
3. dst=null perm=null
5. 2014-03-06 22:26:08,296 INFO FSNamesystem.audit: allowed=true ugi=RogueITGuy (auth:SIMPLE) ip=/127.0.0.1 cmd=rename
6. src=/Ticketing/Ticket_details_20140220
7. dst=/Ticketing/Ticket_stg/Ticket_details_20140220
8. perm=RogueITGuy:supergroup:rw-r--r—
10. 2014-03-06 22:27:02,666 INFO FSNamesystem.audit: allowed=true ugi=RogueITGuy
11. (auth:SIMPLE) ip=/127.0.0.1 cmd=open
12. src=/Ticketing/Ticket_stg/Ticket_details_20140220 dst=null
13. perm=null
复制代码
调查人员得出以下结论:
- 用户RogueITGuy ( ugi=RogueITGuy)加载了新版本的逐日登台文件Ticket_details_20140220 ( cmd=rename src=/Ticketing/Ticket_details_20140220 dst=/Ticketing/Ticket_stg/Ticket_details_20140220)。
- 文件被加载到指向外部登台表Ticket_details_stg的 HDFS 位置，该表用于通过创建和覆盖特定日期的分区将数据加载到Ticket_details表。
- 第一个条目(cmd=getfileinfo src=/Ticketing/Ticket_details_20140220)是确保他从自己的 PC 上传了正确的(修改后删除了他女朋侪的机票条目)文件。
- 第三个条目是确保修改后的文件被正确地上传到暂存位置。
Hive log: If this user overwrote a partition with the modified file, he would have done that using Hive. So, investigators looked at the Hive logs next (in /var/log/hive for Cloudera CDH4; may vary as per your distribution and configuration):
1. grep 'ugi=RogueITGuy' hadoop-cmf-hive1-HIVEMETASTORE-localhost.localdomain.log.out | grep 'ticket_details' | grep -v 'get_partition'
复制代码
他们通过表Ticket_details中的RogueITGuy搜索活动，并在查察输出后，过滤掉'get_partition'条目，由于该下令不会修改分区。以下是他们看到的环境:
1. 2014-03-06 22:42:36,948 INFO
2. org.apache.hadoop.hive.metastore.HiveMetaStore.audit: ugi=RogueITGuy
3. ip=/127.0.0.1 cmd=source:/127.0.0.1 get_table : db=default tbl=ticket_details
5. 2014-03-06 22:42:37,184 INFO
6. org.apache.hadoop.hive.metastore.HiveMetaStore.audit: ugi=RogueITGuy
7. ip=/127.0.0.1 cmd=source:/127.0.0.1 append_partition: db=default
8. tbl=ticket_details[2014,2,20]
复制代码
调查人员得出以下结论:
2/20/14的分区被RogueITGuy覆盖了Ticket_details表的ugi=RogueITGuy ip=/127.0.0.1 cmd=source:/127.0.0.1 append_partition: db=default tbl=ticket_details[2014,2,20]。
文件Ticket_details_20140220于 2014 年 3 月 6 日 22:26 上传，配置单元分区于 2014 年 3 月 6 日 22:42 被同一用户RogueITGuy覆盖。结案了。

最后，调查人员检查了RogueITGuy提交的工作。几个任务相关日志提供了用户实验任务的细节。调查人员从审查 MapReduce 审计日志**开始，此中包含所有用户、日期/时间和提交作业的结果细节。对于 Cloudera，它们的位置是/var/log/hadoop-0.20-mapreduce/mapred-audit.log。调查人员接下来发布了以下下令:

grep 'RogueITGuy' mapred-audit.log

复制代码

它创造了几个工作机会:

2014-03-06 22:28:01,590 INFO mapred.AuditLogger: USER=RogueITGuy IP=127.0.0.1
OPERATION=SUBMIT_JOB TARGET=job_201403042158_0008 RESULT=SUCCESS
2014-03-06 22:42:07,415 INFO mapred.AuditLogger: USER=RogueITGuy IP=127.0.0.1
OPERATION=SUBMIT_JOB TARGET=job_201403042158_0009 RESULT=SUCCESS
2014-03-06 22:45:55,399 INFO mapred.AuditLogger: USER=RogueITGuy IP=127.0.0.1
OPERATION=SUBMIT_JOB TARGET=job_201403042158_0010 RESULT=SUCCESS
2014-03-06 22:47:39,380 INFO mapred.AuditLogger: USER=RogueITGuy IP=127.0.0.1
OPERATION=SUBMIT_JOB TARGET=job_201403042158_0011 RESULT=SUCCESS
2014-03-06 22:48:46,991 INFO mapred.AuditLogger: USER=RogueITGuy IP=127.0.0.1
OPERATION=SUBMIT_JOB TARGET=job_201403042158_0012 RESULT=SUCCESS

复制代码

调查人员在http://JobTrackerHost:50030/JobTracker.jsp使用 JobTracker 的 web 界面检查了 JobTracker 和 TaskTracker 日志。乔布斯job_201403042158_00010、job_201403042158_0011和job_201403042158_0012是没有修改任何数据的精选语句，但是乔布斯job_201403042158_0008和job_201403042158_0009导致了确凿的证据！调查人员检查了这些作业的job.xml文件中的hive.query.string属性，并检索了实验的查询，它是:

FROM Ticket_details_stg INSERT OVERWRITE TABLE Ticket_details PARTITION (Yr=2014,Mo=2,Dy=20) SELECT TicketId,DriverSSN,Offense,IssuingOfficer

复制代码

该查询使用来自Ticket_details_stg表(逐日分段表)的数据来覆盖表Ticket_details的日期为 2/20/14 的分区。HDFS 审计日志已经确定RogueITGuy已经将一个暂时数据文件加载到暂存表中。
这些日志一起明确了RogueITGuy编辑了逐日暂时数据文件，并删除了包含其女友门票条目的记载。然后，他将这个新文件上传到 staging 表，并使用 staging 表来覆盖Ticket_details表的一个分区，以确保 ticket 条目被删除。通过使用 HDFS 审计日志、Hive 日志、MapReduce 审计日志和job.xml文件，调查人员获得了RogueITGuy进行未授权活动简直凿证据，并能够成功结束调查。
结果，RogueITGuy丢了工作，女朋侪要付机票钱。然而，她被他的忠诚所感动，同意嫁给他。所以，最后连RogueITGuy都感谢了相关日志！
如何使用工作名称进行关联？
有几种方法可以关联日志。最简单的方法是使用登录名或作业名，由于日志消息包含这些信息。您看到了RogueITGuy用户名如何关联各种日志文件来调查未授权的活动。使用作业名关联日志也是紧张的一步。为了追踪安全漏洞，调查人员必须从日志中提取相关信息，并使用作业名称来关联多个日志，以获得特定作业所实验活动的具体信息。
我现在将带你完成这个过程，从 MapReduce 审计日志(mapred-audit.log)开始，它有如图 6-11 所示的条目。

图 6-11 。MapReduce 审核日志
留意带有作业名称job_201403042158_0008的高亮条目。HDFS 审核日志对此作业有多个条目。你如何过滤掉它们？
如果您查察这个作业的第一个条目(在hdfs-audit.log中)，您会发现它具有模式cmd=getfileinfo以及作业名称job_201403042158_0008。这实用于 Cloudera 的 Hadoop 发行版(CDH4 ),如果您使用不同的发行版，您将需要为特定作业的第一次和最后一次出现确定一个唯一的模式。好消息是，对于 Hadoop 发行版，您只需实验这个训练一次。您只需为作业名称的第一次和最后一次出现创建一个唯一的模式，将它与随后的出现区分开来；然后你可以用它进行所有的搜索。
随后，您可以使用 Linux 实用步伐 awk 来获取该模式第一次出现的行号:

awk '/cmd\=getfileinfo/ && /job_201403042158_0008\t/ { print NR }' hdfs-audit.log

复制代码

awk 实用步伐寻找匹配模式cmd=getfileinfo和job_201403042158_0008的第一行，并使用内置变量NR输出行号。
此外，您可以通过使用模式cmd=delete和/src=/tmp/mapred/system/ job_201403042158_0008获得作业名称最后出现的行号，如下所示:

awk '/cmd\=delete/ && /src=\/tmp\/mapred\/system\/job_201403042158_0008/ { print NR }' hdfs-audit.log

复制代码

之后，您可以使用流编辑器，比如 sed，打印以第一个模式开始，以第二个模式结束的行。例如，sed –n 1,20p hdfs-audit.log将在屏幕上显示文件hdfs-audit.log的第 1 至 20 行。

sed -n `awk '/cmd\=getfileinfo/ && /job_201403042158_0008\t/ { print NR }' hdfs-audit.log
`,`*awk '/cmd\=delete/* && */src=\/tmp\/mapred\/system\/ job_201403042158_0008/ { print NR }' hdfs-audit.log*`p hdfs-audit.log

复制代码

sed下令使用之前步骤中获得的行号(用粗体和斜体标志)作为开始和结束，打印中间的所有行。您可以将下令sed的输出重定向到一个文件，并查察 HDFS 审计记载，而不是在屏幕上查察它们(正如最后一个sed下令所暗示的)。您可以使用这个sed下令从hdfs-audit.log中提取任何作业(对于 CDH4)的作业细节——只需替换作业名称！
现在，在这种环境下，您没有从hdfs-audit.log条目中获得太多信息，除了这个作业进行了与 Hive 相关的处理惩罚，并且还显示了job.xml的位置:

2014-03-06 22:27:59,817 INFO FSNamesystem.audit: allowed=true ugi=RogueITGuy (auth:SIMPLE) ip=/127.0.0.1 cmd=create src=/user/RogueITGuy/.staging/job_201403042158_0008/libjars/hive-builtins-0.10.0-cdh4.4.0.jar dst=null perm=RogueITGuy:supergroup:rw-r--r—
2014-03-06 22:28:02,184 INFO FSNamesystem.audit: allowed=true ugi=RogueITGuy (auth:SIMPLE) ip=/127.0.0.1 cmd=getfileinfo src=/user/RogueITGuy/.staging/job_201403042158_0008/job.xml dst=null perm=null
2014-03-06 22:28:02,324 INFO FSNamesystem.audit: allowed=true ugi=RogueITGuy (auth:SIMPLE) ip=/127.0.0.1 cmd=getfileinfo src=/tmp/hive-RogueITGuy/hive_2014-03-06_22-27-55_562_981696949097457901-1/-mr-10004/164c8515-a032-4b6f-a551-9bc285ce37c4 dst=null perm=null

复制代码

为什么不直接使用grep下令来检索hdfs-audit.log中作业job_201403042158_0008的作业细节呢？原因是与作业job_201403042158_0008相关的所有行可能不包含作业名称模式，并且您希望确保不会遗漏日志文件hdfs-audit.log中的任何相关行。
使用作业名称检索作业具体信息
您可以使用查找第一次出现的唯一模式的雷同技术，从 JobTracker 或 TaskTracker 日志中检索与作业相关的记载。例如，要在 JobTracker 日志文件中查找模式，并获得作业第一次出现的行号，如job_201403042158_0008，请使用:

awk '/job_201403042158_0008/ && /nMaps/ && /nReduces/ { print NR }' hadoop-cmf-mapreduce1-JOBTRACKER-localhost.localdomain.log.out

复制代码

要检索“job_201403042158_0008”最后一次出现的行号，请使用:

awk '/job_201403042158_0008/ && /completed successfully/ { print NR }' hadoop-cmf-mapreduce1-JOBTRACKER-localhost.localdomain.log.out

复制代码

您可以使用下令sed通过指定作业名从 CDH4 的 JobTracker 日志文件中获取具体信息。例如，打印出job_201403042158_0008的所有记载的sed下令是:

sed -n `awk '/job_201403042158_0008/ && /nMaps/ && /nReduces/ { print NR }' hadoop-cmf-mapreduce1-JOBTRACKER-localhost.localdomain.log.out
*`,`awk '/job_201403042158_0008/* && */completed successfully/ { print NR }' hadoop-cmf-mapreduce1-JOBTRACKER-localhost.localdomain.log.out*`p hadoop-cmf-mapreduce1-JOBTRACKER-localhost.localdomain.log.out

复制代码

该下令的输出提供了有代价的具体信息，如实验任务的节点或任务输出的位置:

2014-03-06 22:28:01,394 INFO org.apache.hadoop.mapred.JobInProgress: job_201403042158_0008: nMaps=1 nReduces=0 max=-1
2014-03-06 22:28:01,764 INFO org.apache.hadoop.mapred.JobInProgress: Input size for job job_201403042158_0008 = 74\. Number of splits = 1
2014-03-06 22:28:01,765 INFO org.apache.hadoop.mapred.JobInProgress: tip:task_201403042158_0008_m_000000 has split on node:/default/localhost.localdomain
2014-03-06 22:28:01,765 INFO org.apache.hadoop.mapred.JobInProgress: Job job_201403042158_0008 initialized successfully with 1 map tasks and 0 reduce tasks.
2014-03-06 22:28:02,089 INFO org.apache.hadoop.mapred.JobTracker: Adding task (JOB_SETUP) 'attempt_201403042158_0008_m_000002_0' to tip task_201403042158_0008_m_000002, for tracker 'tracker_localhost.localdomain:localhost.localdomain/127.0.0.1:47799'

复制代码

使用 Web 浏览器检索工作具体信息
您还可以使用浏览器界面轻松查察 JobTracker 和 TaskTracker 日志记载。最好使用浏览器界面查察作业的运行时统计信息或作业的 XML 文件。记载的 URL 由跟踪者的姓名和 web 访问端口组成。例如，如果您的 JobTracker 主机名为'MyJobHost'，并使用端口 50030 进行 web 访问，那么可以在http://MyJobHost:50030/logs/查察 JobTracker 日志。同样，在主机'MyTaskHost'上运行并使用端口 50060 的 TaskTracker 的日志可以在http://MyTaskHost:50060/logs/查察。检查您的配置文件(mapred-site.xml)以了解运行特定保卫步伐和端口的主机的具体信息。文件名可能因发行版而异，但日志文件的名称中会有TaskTracker或JobTracker，使它们易于识别。
图 6-12 显示了使用 MapReduce 1.0 的集群的日志目录和各种 MapReduce 日志文件。

图 6-12 。MapReduce 版本 1 的 MapReduce 日志文件
如果使用 YARN，那么对应的保卫进程是 ResourceManager(而不是 JobTracker)和 NodeManager(而不是 TaskTracker)。请检查纱线配置文件(yarn-site.xml)中的网络访问端口(mapreduce.johistory.webapp.address和yarn.resourcemanager.webapp.address的值)。例如，在图 6-13 的中，资源管理器使用端口 8088。

图 6-13 。纱线资源管理器 web 界面
节点管理器使用端口 8042，如图图 6-14 所示。

图 6-14 。YARN 的节点管理器 web 界面
最后，历史服务器使用端口 19888 ( 图 6-15 )。

图 6-15 。纱线的历史服务器 web 界面
当使用 YARN 时，应该使用 NodeManager 和 ResourceManager 的 YARN 日志来获取作业细节。Historyserver 保存已存档或“退役”作业的日志。因此，如果您需要访问旧的工作具体信息，这就是您需要检查的内容。定位第一行和最后一行的模式可能稍有厘革，可能需要调整；但是您可以轻松地浏览日志文件来进行这些调整。找出纱线日志文件位置的一个简单方法是参考位于/etc/hadoop/conf中的log4j.properties文件，并查察合适的附件指向那里。
在我结束这一章之前的一个想法。您已经看到了如何为一个作业关联日志，但是如果您想要跟踪一个用户的所有活动或者想要跟踪一整天的活动，该怎么办呢？定义和使用 awk 模式会很麻烦、困难，并且容易堕落。相反，可以尝试为 appender 定义 Log4j 过滤器，并定义额外的 appender 来将相关输出定向到一个题目的单独文件，并合并一个题目的所有文件。为此，您可以使用 Flume，也可以简单地让 shell 脚本为您进行整合。
日志记载的紧张留意事项
一些额外的因素将资助您有用地使用日志记载。虽然它们与安全性没有直接关系，但我将在本节中扼要先容它们，您可以决定它们与您的具体环境有多大关系。
时间同步
Hadoop 是一个具有多个节点的分布式系统，通常有大量节点。因此，Hadoop 日志也分布在集群中的各个节点上。各个日志消息都偶然间戳，在进行故障排除时，您需要确保一个节点上的 12:00 PM 与另一个节点上指定的 12:00 PM 是同一时间。
对于一个网络，时钟毛病是网络上不同节点时钟的时间差。通常，以毫秒为单位的时间差是可以接受的；但是需要制止更大的时钟偏移。很多协议(例如，网络时间协议，http://en.wikipedia.org/wiki/Network_Time_Protocol)可用于确保存在可忽略的时间毛病。确保为集群天生的日志是时间同步的，这一点固然很紧张。
Hadoop 分析
在“关联息争释日志文件”一节中，我讨论了如何结合使用 Linux 流编辑器 sed 和功能强盛的文本处理惩罚器 awk 来搜索模式并打印适当的行。您可以很容易地将这种方法扩展到盘算匹配模式的行数。您可以对日志文件进行多次检查，并聚合匹配项来分析使用模式。现在天生的分析可能对安全调查没有用处，但它们肯定能为您的 Hadoop 集群提供有用的统计数据。
例如，下面的下令可以告诉您自 Hadoop 集群启动以来用户RogueITGuy访问了它多少次(固然您也可以轻松地提取访问的日期范围):

grep 'ugi=RogueITGuy' hdfs-audit.log | wc -l

复制代码

以下下令告诉您自从集群重新启动以来，RogueITGuy实验了多少个作业:

grep 'USER=RogueITGuy' mapred-audit.log | wc -l

复制代码

以下脚本提取作业job_201403042158_0008的开始和结束日期/时间(然后您可以盘算作业持续时间):

awk –F ',' '/cmd\=getfileinfo/ && /job_201403042158_0008\t/ { print $1 }' hdfs-audit.log
awk –F ',' '/cmd\=delete/ && /src=\/tmp\/mapred\/system\/job_201403042158_0008/ { print $1 }' hdfs-audit.log

复制代码

您可以开发自动化脚本，将所有日常作业分析或 HDFS 访问分析写入文件，并将它们作为分区添加到适当的配置单元表中。然后，您可以在自己的分析系统中对这些数据实验聚合或使用其他统计函数。
固然，与你更相关的分析可能会有所不同，但我相信你理解它们背后的方法。
通过定义厘革阈值，该历史数据(存储为 Hive 表)也可用于天生安全警报。例如，您可以编写一个 Hive 查询来天生一个警报(通过 Nagios ),如果一个用户实验的作业数量是他的月匀称值的两倍(或更多)。安全警报的历史数据的使用总是依赖于使用中的忽然厘革，您可以使用实用于您的环境的概念。
软体
Splunk 是一个非常强盛的分析 Hadoop 数据的工具。使用 Splunk 的 Hadoop Connect 模块，您可以导入任何 HDFS 数据，并使用 Splunk 的索引功能进一步搜索、陈诉、分析和可视化您的数据。您还可以导入 Hadoop 日志，对其进行索引和分析。
Splunk 为搜索和分析实时和历史数据提供了强盛的搜索处理惩罚语言(SPL)。它还可以提供实时监控日志数据(模式/阈值)的功能，并在特定模式出现时(在您的数据中)天生警报。例如，如果您正在使用 Hive，您想知道一个分区(对于您的一个生产表)何时被覆盖或添加。当此中一个用户连接到您的集群时，您可能还希望提醒您的系统管理员。
Splunk 最紧张的功能(从安整日志的角度来看)是关联数据的本事。Splunk 支持以下关联数据的方式:

基于时间和地理位置的:您可以关联在特定日期或时间段以及特定位置发生的事故的数据。因此，如果我使用 Splunk 对RogueITGuy进行调查，我可以要求 Splunk 向我提供 2014 年 3 月 16 日(题目发生的具体日期)的所有日志数据。
基于事故的:您可以关联一个业务流程(或一系列业务流程)的所有数据，并将其标识为单个事故。尽管它不能用于安全性，但它可以为作业或业务流程提供分析(如持续时间、消耗的 CPU 和 RAM 资源等。).
子搜索:允许你使用一次搜索的结果，并在另一次搜索中使用。因此，如果我使用 Splunk 对RogueITGuy进行调查，那么我可以将我的子搜索定义为 HDFS、MapReduce 或 Hive access，以便于分析。
查找:允许您关联来自外部来源的数据。例如，我可以检查来自 Nagios 的所有 Hive 警报，看看RogueITGuy是否涉及任何其他题目。
Joins :允许您基于用户名或事故 ID 字段将两个完全不同的数据集链接在一起。使用 Splunk，我可以使用用户名RogueITGuy链接 Ganglia 的监控数据和 Hadoop 日志数据，并调查他在实验已知的非法活动时还访问了什么。

最后，Splunk 提供了 Hunk，这是一款专门为 Hadoop 和 NoSQL 数据设计的分析工具。它允许您探索、分析和可视化原始的非结构化数据。Hunk 还提供基于脚色的访问，以限制对敏感数据的访问(更多信息见www.splunk.com/hunk)。看一看，是不是对你的需求更有用！
摘要
在本章中，我讨论了 Hadoop 日志如何有用地用于安全目的。高级方法是使用 Linux 实用步伐和流编辑器来处理惩罚日志文件中的文本，并获取必要的信息，但是这固然黑白常过时和困难的工作。通过使用 Splunk 等第三方解决方案，有更简单的方法来实现类似的结果。
大量第三方产物可用于淘汰排除故障或调查安全漏洞的工作量。缺点是，在关联或分析日志时，您将没有足够的控制力或灵活性。首选项是您的，而且大多数时间是由您的环境和需求决定的。无论接纳哪种方法，在依赖天生的日志之前，都要确保同步所有需要思量的节点上的时间。
最后，探索使用 Hadoop 日志进行分析是值得的——无论是否与安全相关。您可以购买昂贵的软件来实验分析，或者开发您自己的脚本，如果您确定您的需求——如果它们的数量很少！*
七、Hadoop 中的监控

任何系统管理员都会告诉你，监控是找到性能题目根源的理想方法。例如，监视可以资助您了解系统 CPU 或 RAM 资源不足的原因，并在 CPU 或 RAM 使用率靠近指定百分比时关照您。您的系统管理员可能不知道(但您可以在阅读本章后解释)的是，监视同样非常适合于找出安全题目。
思量一个场景:您管理一个 Hadoop 集群(作为系统管理员)，并且关注两个特定的用户:Bob，一个公认的黑客，和 Steve，他喜欢运行访问大量他不应该访问的数据的查询！为了防止暗码丢失和制止服务器瓦解，您希望在 Bob 试图读取/etc/password文件和 Steve 运行检索整个数据库的大型查询时得到关照。Hadoop 监控可以提供你需要的信息。具体来说，Hadoop 提供了很多指标来获取有用的安全细节，领先的监控系统可以使用这些指标来提醒您留意题目。此外，这些监控系统允许您基于特定指标值定义阈值(用于天生警报)，还允许您定义适当的操纵(如果达到阈值)。因此，Hadoop 监控提供了很多功能，您可以使用这些功能进行性能监控和故障排除。
在本章对监控的具体概述中，我将讨论监控系统需要的特性，重点是监控分布式集群。此后，我将讨论可以用于安全目的的 Hadoop 指标，并先容 Ganglia 和 Nagios，这是两个最流行的 Hadoop 监控应用步伐。最后，我将讨论一些对 Ganglia 和 Nagios 有用的插件，它们提供了这两个步伐之间的集成，以及提供安全相关功能的插件。
监控系统概述
监控分布式系统总是具有挑战性。不但多个进程与用户交互，而且还相互交互，您必须在不影响这些进程性能的环境下监视系统。像 Hadoop 这样的系统提出了更大的挑战，由于监控软件必须监控单个主机，然后在整个系统的上下文中整合数据。它还需要思量整个系统中各种组件的作用。例如，DataNode 上的 CPU 使用率不如 NameNode 上的 CPU 使用率紧张。那么，系统将如那边理 CPU 消耗警报，或者为分布式系统中具有不同脚色的主机确定单独的阈值级别呢？此外，在思量 datanode 的 CPU 或存储使用环境时，监视系统必须思量群集中所有 datanode 的组合使用环境。随后，监控系统还需要能够按脚色汇总监控阈值。
除了复杂的资源监控本事之外，用于分布式系统的监控系统还需要随时访问正在实验的进程的细节。这是天生警报(例如，导致 90% CPU 使用率的用户进程)或实验任何防备步伐(例如，用户正在访问关键系统文件)所必需的。
在有用应对监控 Hadoop 系统的挑战之前，您需要了解一个简单监控系统的架构。在下一节中，我将讨论有用监控分布式系统所需的组件、处理惩罚和特性，以及如何调整这个简单的架构以更好地监控 Hadoop 集群。
简单监控系统
一个简单的监控系统需要四个关键组件:一个服务器或协调器进程，轮询分布式系统主机并网络必要信息的连接，一个存储网络信息的存储库，以及一个作为前端的图形用户界面(图 7-1 )。

图 7-1 。简单监控系统
如您所见，监控服务器整合了通过轮询分布式系统主机吸收到的输入，并将具体的(以及汇总的)输出写入存储库。控制台为网络的数据提供显示选项，这些数据可以使用各种参数进行汇总，如监视事故、服务器、警报类型等。
不幸的是，像这样简单的监控系统架构不能很好地扩展。思量一下，如果图 7-1 的系统必须监控数千台主机而不是三台，会发生什么。监控服务器必须管理一千个连接的轮询，处理惩罚和整合输出，并在几秒钟内将其出现在控制台上！随着每台主机添加到监控系统，监控服务器上的负载也会增长。达到肯定数量的主机后，您将无法再添加任何主机，由于服务器根本无法支持它们。此外，大量轮询会增长网络流量并影响整体系统性能。
除此之外，Hadoop 集群的复杂性还在于，您需要在整合数据时思量节点的脚色，以及汇总具有雷同脚色的多个节点的数据。简单的设计是不够的，但它可以用于监控 Hadoop 集群。
Hadoop 监控系统
一个简单的监控系统遵循与传统的客户端-服务器设计雷同的处理惩罚安排:一个单一的集中式监控服务器完成所有的处理惩罚，并且随着主机数量的增长，处理惩罚负载也会增长。网络流量也会低落负载，由于来自主机的轮询数据会整合到监控服务器上。
正如 Hadoop 的分布式架构在效率上比传统的客户端-服务器处理惩罚有了显著提高一样，分布式处理惩罚模型也可以改进简单的监控系统。例如，如果本地化的监控流程为 Hadoop 集群中的每个节点捕捉和存储监控数据，那么就不会再有集中式服务器成为处理惩罚瓶颈或单点故障。每个节点都是并行实验部分处理惩罚的自动到场者。然后，这些本地化进程中的每一个都可以将数据传输到群集中的其他节点，并且还可以从群集中的其他节点吸收数据的副本。轮询过程可以以任何预定的频率从集群内的任何节点轮询整个集群的监控数据。数据可被写入储存库并存储以供进一步处理惩罚，或由基于图形或网络的前端显示。图 7-2 显示了一种可能的设计。

图 7-2 。Hadoop 监控系统
使用这种体系结构，即使添加 1000 台主机进行监控也不会对性能产生负面影响。任何现有节点或轮询进程都没有额外的负载负担，由于轮询进程仍旧可以从任何节点进行轮询，而不必进行多次轮询。集群节点将数据传输到公共信道，所有其他节点吸收该数据。因此，增长节点数量不会以任何方式影响轮询过程或系统性能，从而使体系结构具有高度可伸缩性。与传统的监控系统相比，您需要做的唯一额外工作是将监控流程配置应用于所有节点。
仔细查察图 7-2 ，留意各个节点上的监控进程盘算“本地监控数据”监控数据需要在本地盘算；由于 Hadoop 是一个多节点分布式系统，数据分布在浩繁的 datanode 上，根据 Hadoop“对数据进行处理惩罚”的理念，数据在本地进行处理惩罚(数据驻留在 datanode 上)。这个“本地监控数据”实际上是各个节点的度量输出；它可以告诉你很多关于你的系统的安全性和性能的信息，这一点你接下来会学到。
Hadoop 指标
Hadoop 指标是关于系统内发生的事情的简单信息，例如内存使用环境、打开的连接数或节点上的剩余容量。您可以配置每个 Hadoop 保卫进程定期网络指标，然后使用插件输出数据。网络的数据可以包含关于 Hadoop 保卫进程(例如，它们使用的资源)、事故(例如，MapReduce 作业实验)和测量(例如，为 NameNode 创建的文件数量)的信息。您使用的输出插件决定了指标的目的地。例如，FileContext 将指标写入文件，GangliaContext 将通报给 Ganglia 监控系统的指标进行显示和整合，而 NullContext 则抛弃该指标。
根据它们包含的信息，度量被分为四个上下文 : jvm、dfs、rpc 和 mapred。jvm 的度量包含 JVM (Java 虚拟机)的根本统计数据，如内存使用或线程计数等。这个上下文实用于所有 Hadoop 保卫进程。dfs (分布式文件系统)上下文实用于 NameNode 和 DataNode。该上下文的一些指标输出诸如容量或文件数量(对于 NameNode)、故障磁盘卷数量、特定工作节点上的剩余容量(对于 DataNode)等信息。JobTracker 和 TaskTracker 为它们的计数器使用 mapred 上下文。这些度量包含作业前计数器数据、作业计数器和作业后计数器。rpc 上下文用于长途过程调用(rpc)指标，如处理惩罚 RPC 所需的匀称时间、打开的连接数等，实用于所有 Hadoop 保卫进程。表 7-1 总结了上下文。
表 7-1 。Hadoop 指标的上下文

NameNode 的活动统计:监控 NameNode 上的活动很紧张，由于它可以提供大量信息，提醒您留意安全题目。作为 Hadoop 集群的“大脑”, NameNode 是所有文件创建活动的中枢。如果新创建的文件数量急剧厘革，或者权限被更改的文件数量急剧增长，这些指标会触发警报，以便您进行调查。
活动统计对于一个 DataNode: 对于一个 DataNode，如果一个本地客户端的读写次数忽然增长，你肯定需要调查。此外，如果添加或删除的块数发生较大百分比的厘革，则指标会触发警报向您发出警告。
RPC 相关处理惩罚的活动统计:** 对于 NameNode(或 DataNode)，您需要密切监视 RPC 统计，例如处理惩罚的 RPC 哀求的数量、失败的 RPC 认证调用的数量或失败的 RPC 授权调用的数量。您可以将每天的数字与每周的匀称值进行比较，如果数字相差阈值百分比，则天生警报。例如，如果一天中失败的 RPC 授权调用次数为 50 次，每周匀称次数为 30 次，那么如果警报阈值为每周匀称次数的 50%或更多，将会天生警报(30 的 50%为 15，每天的次数(50)大于 45)。**
系统忽然厘革的活动统计****资源: 监视任何主要系统资源(如可用内存、CPU 或存储)的忽然厘革都是有益的。Hadoop 提供了监控这些资源的指标，您可以定义一个特定的百分比(用于天生警报)或监控与每周或每月匀称值的百分比毛病。后一种方法更加精确，由于即使受到恶意攻击，一些集群也可能永远达不到目标警报百分比(例如，如果集群的匀称内存使用率为 20%，而恶意攻击导致使用率跃升至 60%)。如果您定义了 80%或 90%的警报阈值，那么您将永远不会收到警报。或者，如果您将警报阈值定义为 50%或更多(匀称使用率)，那么您肯定会收到警报。

您可以结合使用 Ganglia 和 Nagios 来监控任何 Hadoop 保卫进程的任何系统资源或指标值的忽然厘革。同样，附录 D 有一个描述这种方法的例子。
如果您不想使用监控系统，而想接纳将指标数据写入文件并使用 Hive 或 HBase 将数据加载到表中的“老式”方法，这也是可行的。固然，您需要开发 will 脚本来调度您的数据加载、实验聚合、天生摘要陈诉以及天生适当的警报。
指标过滤
当您对安全漏洞或可能的性能题目进行故障排除时，查察大量指标数据可能会花费时间，并且会分散留意力和容易堕落。过滤指标数据有助于您关注可能的题目并节省名贵的时间。Hadoop 允许您通过源、上下文、记载和指标来配置指标过滤器。最高级别的筛选是按源(例如，DataNode5)，最低级别的筛选是按指标名称(例如，文件创建)。可以组合过滤器以优化过滤效率。
例如，以下文件吸收器仅接受来自上下文 dfs 的指标:

bcl.sink.file0.class=org.apache.hadoop.metrics2.sink.FileSink
bcl.sink.file0.context=dfs

复制代码

要设置过滤器，您首先需要在您的$HADOOP_INSTALL/hadoop/conf/Hadoop-metrics 2 . properties文件中添加如下代码片段:

# Syntax: <prefix>.(source|sink).<instance>.<option>
*.sink.file.class=org.apache.hadoop.metrics2.sink.FileSink
*.source.filter.class=org.apache.hadoop.metrics2.filter.GlobFilter
*.record.filter.class=${*.source.filter.class}
*.metric.filter.class=${*.source.filter.class}

复制代码

此后，您可以包罗以下任何配置选项，这些选项将在不同级别设置过滤器:

# This will filter out sources with names starting with Cluster2
jobtracker.*.source.filter.exclude=Cluster2*
# This will filter out records with names that match localhost in the source dfs
jobtracker.source.dfs.record.filter.exclude=localhost*
# This will filter out Metrics with names that match cpu* for sink instance file only
jobtracker.sink.file.metric.filter.exclude=cpu*
jobtracker.sink.file.filename=MyJT-metrics.out

复制代码

因此，总的来说，您可以根据源、源中的模式或者吸收的输出文件中的指标名称或模式来过滤指标数据。
请记着，当您仅指定“包罗”模式时，过滤器仅包罗与过滤条件匹配的数据。此外，当您仅指定“排除”模式时，匹配的数据将被排除。最紧张的是，当您指定这两种模式时，不匹配任何一种模式的源也包罗在内！最后，包含模式优先于排除模式。
将指标输出捕捉到文件
如何将 NameNode 或 DataNode 指标输出到文件中？使用 Metrics2，您可以定义一个吸收器(输出文件),通过向目录/etc/Hadoop/conf或$HADOOP_INSTALL/hadoop/conf中的hadoop-metrics2.properties配置文件添加几行，将来自您的度量源的输出定向到该吸收器中。在下面的示例中，我将 NameNode 和 DataNode 指标重定向到单独的输出文件以及 Ganglia 监控系统(请记着，Metrics2 可以支持同时输出到两个吸收器):

# Following are entries from configuration file hadoop-metrics2.properties
# collectively they output Metrics from sources NameNode and DataNode to
# a sink named 'tfile' (output to file) and also to a sink named 'ganglia'
# (output to Ganglia)
# Defining sink for file output
*.sink.tfile.class=org.apache.hadoop.metrics2.sink.FileSink
# Filename for NameNode output
namenode.sink.tfile.filename = namenode-metrics.log
# Output the DataNode Metrics to a separate file
datanode.sink.tfile.filename = datanode-metrics.log
# Defining sink for Ganglia 3.1
*.sink.ganglia.class=org.apache.hadoop.metrics2.sink.ganglia.GangliaSink31
# Default polling period for GangliaSink
*.sink.ganglia.period=10
# Directing output to ganglia servers
namenode.sink.ganglia.servers=gangliahost_1:8649,gangliahost_2:8649
datanode.sink.ganglia.servers=gangliahost_1:8649,gangliahost_2:8649

复制代码

现在您已经将所有的度量数据保存在文件中，您需要有用地使用它。如果您不计划使用监控系统，您将不得不为所有 Hadoop 保卫进程定义文件吸收器(作为输出),并手动分析巨大的输出文件或根据需要聚合它们！最多，您可以定义 Hive 外部表并简化处理惩罚。或者，您可以将指标输出定向到 JMX 控制台进行检查。
请留意，无论使用哪种方法，您都无法以图形方式显示指标数据或聚合以进行快速查察。此外，您还需要通过 shellscripts(访问配置单元数据)设置带有警报机制的接口，并设置用于寻呼系统管理员的接口(如果发生关键事故)。
但是，如果您筹划使用 Ganglia，那么将您的指标发送到 Ganglia 监控系统就像将它们发送到一个文件一样简单，并且提供了更多的上风，您将在下一节中了解到。
使用 Ganglia 和 Nagios 进行安全监控
最适合您的 Hadoop 集群的安全监控系统是一个符合您的环境和需求的系统。在某些环境下，确保只有授权用户才能访问可能是最紧张的，而在其他环境下，您可能需要监控系统资源，并在资源使用发生忽然厘革时立即发出警报。一些集群管理员只想监控失败的认证哀求。Hadoop 安全监控领域的向导者 Ganglia ( http://ganglia.sourceforge.net)和 Nagios ( www.nagios.org)通过提供灵活性和各种监控系统资源、连接以及技术上可能监控的 Hadoop 集群的任何其他部分的方法来应对这一挑战。
两者都是开源工具，具有不同的上风，可以很好地互补。Ganglia 非常善于网络指标，随着时间的推移跟踪它们，并汇总结果；而 Nagios 更偏重于提供一种警报机制。由于网络指标和发出警报都是监控的紧张方面，Ganglia 和 Nagios 共同得最好。这两种工具都有在集群的所有主机上运行的代理，并通过轮询过程网络信息，轮询过程可以轮询任何主机以获取必要的信息。
神经节
Ganglia 是在加州大学伯克利分校设计的，最初是一个开源监控项目，旨在用于大型分布式系统。Ganglia 的开放式架构使其易于与其他应用步伐集成，并网络有关其操纵的统计数据。这就是 Ganglia 能够轻松吸收和处理惩罚来自 Hadoop 指标的输出数据并有用使用它的原因。
对于受监控的集群，每个主机运行一个名为 gmond 的保卫进程，该进程网络并广播本地指标数据(如 CPU 使用率、内存使用率等。)发送到集群中的所有主机。然后，轮询进程( gmetad )可以查询任何主机，读取所有指标数据，并将其路由到中央监控服务器。中央主机可以显示指标、汇总指标或汇总指标以备将来使用。 Gmond 开销很小，因此可以很容易地在集群中的每台机器上运行，而不会影响用户性能。Ganglia 的 web 界面可以根据您的需要轻松显示已往一小时、一天、一周或一个月的使用环境摘要。此外，您可以根据需要获得这些资源使用的具体信息。
神经节架构
概括地说，Ganglia 有四个主要组件:gmond、gmetad、rrdtool 和 gweb。gmond 在集群中的所有节点上运行并网络指标数据， gmetad 轮询来自 gmond 的数据， rrdtool 存储轮询的数据， gweb 是为存储的数据提供可视化和分析的接口。图 7-3 展示了 Ganglia 的组件如何适应图 7-2 所示的根本 Hadoop 分布式监控系统。

图 7-3 。实用于 Hadoop 的 Ganglia 监控系统
仔细看看每个 Ganglia 组件的功能:

gmond: gmond needs to be installed on every host you want monitored. It interacts with the host operating system to acquire Metrics such as load Metrics (e.g., average cluster load), process Metrics (e.g., total running processes) or rpc Metrics (e.g., RpcAuthenticationFailures). It is modular and uses operating system–specific plugins to take measurements. Since only the necessary plugins are installed at compile time, gmond has a very small footprint and negligible overhead.
gmond 不是根据来自外部轮询引擎的哀求被调用的(用于测量)，而是根据本地配置文件定义的时间表进行轮询。通过在同一组播地点广播的简单监听/告示协议，与其他主机(来自集群)共享测量结果。每个 gmond 主机还记载它从集群中的其他主机吸收到的指标。
因此，Ganglia 集群中的每个主机都知道同一个集群中每个其他主机记载的每个指标的当前值。这就是为什么每个集群只需要轮询一台主机来获取整个集群的指标，任何单个主机故障都不会影响系统！此外，这种设计淘汰了需要以指数方式轮询的主机数量，因此很容易扩展到大型集群。
gmetad: gmetad 是 Ganglia 监控系统中的轮询过程。它需要一个主机名列表，为每个集群指定至少一台主机。gmetad 可以通过端口 8649 从集群中的任何主机哀求集群指标的 XML 格式转储，这就是 gmetad 获取集群指标数据的方式。
RRDtool: RRDtool 是 Ganglia 组件，用于存储 gmetad 从任何集群主机轮询的度量数据。指标以“循环”方式存储；当没有剩余空间来存储新值时，旧值将被覆盖。根据指定的数据保存需求， RRDtool 聚集数据值或“汇总它们”这种数据存储方式允许我们快速分析近来的数据，并使用少量的磁盘空间维护多年的历史数据。此外，由于所有需要的磁盘空间都是预先分配的，所以容量规划非常容易。
gweb: gweb is the visualization interface for Ganglia. It provides instant access to any Metric from any host in the cluster without specifying any configuration details. It visually summarizes the entire grid using graphs that combine Metrics by cluster and provides drop-downs for additional details. If you need details of a specific host or Metric, you can specify the details and create a custom graph of exactly what you want to see.
gweb 允许您更改图表中的时间段，支持以各种文本格式(CSV、JSON 等)提取数据，并提供了一个功能齐全的 URL 接口，以便您可以通过特定的 URL 将必要的图表嵌入到其他步伐中。此外，gweb 是一个 PHP 步伐，运行在 Apache web 服务器下，通常安装在与 gmetad 雷同的物理硬件上，由于它需要访问 gmetad 创建的 RRD 数据库。

配置和使用 Ganglia
对 Ganglia 的主要组件有了更清晰的理解后，您就可以设置它并让它为安全相关的监控和输出特定的 Hadoop 指标而工作了。
要在想要监控的 Hadoop 集群上安装 Ganglia，请实验以下步骤:

在一个集群节点或主机上安装 Ganglia 组件 gmetad、gmond 和 gweb。(以我为例，我调用了主机 GMaster)。
在所有其他集群节点上安装 Ganglia 组件 gmond。

确切的下令语法或安装方式会因您使用的操纵系统而异。具体请参考 Ganglia 安装阐明。然而，在所有环境下，您都需要修改配置文件，以使 Ganglia 正常工作，并使 Hadoop 按照预期通过 Ganglia 输出指标(需要修改配置文件gmond.conf、gmetad.conf和hadoop-metrics2.properties)。
首先，将gmond.conf(具有以下配置)复制到所有集群节点:

/* the values closely match ./gmond/metric.h definitions in 2.5.x */
globals {
daemonize = yes
setuid = yes
user = nobody
debug_level = 0
max_udp_msg_len = 1472
mute = no
deaf = no
allow_extra_data = yes
host_dmax = 86400 /*secs. Expires hosts in 1 day */
host_tmax = 20 /*secs */
cleanup_threshold = 300 /*secs */
gexec = no
send_metadata_interval = 0 /*secs */
}
/*
* The cluster attributes specified will be used as part of the <CLUSTER>
* tag that will wrap all hosts collected by this instance.
*/
cluster {
name = "pract_hdp_sec"
owner = "Apress"
latlong = "N43.47 E112.34"
url = "http://www.apress.com/9781430265443"
}
/* The host section describes attributes of the host, like the location */
host {
location = "Chicago"
}
/* Feel free to specify as many udp_send_channels as you like */
udp_send_channel {
bind_hostname = yes #soon to be default
mcast_join = 239.2.11.71
port = 8649
ttl = 1
}
/* You can specify as many udp_recv_channels as you like as well. */
udp_recv_channel {
mcast_join = 239.2.11.71
port = 8649
bind = 239.2.11.71
retry_bind = true
}
/* You can specify as many tcp_accept_channels as you like to share
an xml description of the state of the cluster */
tcp_accept_channel {
port = 8649
}
/* Each Metrics module that is referenced by gmond must be specified and
loaded. If the module has been statically linked with gmond, it does
not require a load path. However all dynamically loadable modules must
include a load path. */
modules {
module {name = "core_metrics"}
module {name = "cpu_module" path = "modcpu.so"}
module {name = "disk_module" path = "moddisk.so"}
module {name = "load_module" path = "modload.so"}
module {name = "mem_module" path = "modmem.so"}
module {name = "net_module" path = "modnet.so"}
module {name = "proc_module" path = "modproc.so"}
module {name = "sys_module" path = "modsys.so"}
}

复制代码

在 Globals 部分，daemonize属性，当true时，将使 gmond 作为背景进程运行。大于 0 的debug_level将导致 gmond 在前台运行并输出调试信息。当true时，mute属性将制止 gmond 发送任何数据，当true时，deaf属性将制止 gmond 吸收任何数据。如果host_dmax设置为正数，那么 gmond 将在host_dmax秒内没有收到主机消息后革新主机。cleanup_threshold是 gmond 打扫任何带有过期数据的主机或指标之前的最短时间。send_metadata_interval设置为 0 意味着 gmond 将只在启动时以及在收到长途运行的其他 gmond 节点的哀求时发送元数据包。
几个 Ganglia 指标可以检测系统资源的忽然厘革，非常适合安全监控:

cpu_aidle(自上次启动以来 cpu 周期空闲的百分比；对 Linux 有用)
cpu_user(实验用户进程所花费的 cpu 周期百分比)
load_five(陈诉的系统负载，五分钟内的匀称值)
mem_shared(系统和用户进程占用的内存量)
proc_run(运行的进程总数)
mem_free(可用内存量)
disk_free(总可用磁盘空间)
bytes_in(从所有非环回接口读取的字节数)
bytes_out(写入所有非环回接口的字节数)

您可以将它们添加到您的gmond.conf文件中，格式如下:

collection_group {
collect_every = 40
time_threshold = 300
metric {
name = "bytes_out"
value_threshold = 4096
title = "Bytes Sent"
}
}

复制代码

正如您在示例中看到的，需要以雷同的时间间隔网络和发送的指标可以被分组到同一个collection_group下。在本例中，collect_every指定采样间隔，time_threshold指定最大数据发送间隔(即，数据以该间隔发送)，而value_threshold是度量方差阈值(即，如果值凌驾value_threshold值，则发送该值)。
第二个配置文件是gmetad.conf，它只需要驻留在主机(GMaster)上。请记着，下面的代码只是一个示例，您可以根据需要设置自己的数据源或更改设置以进行循环归档:

# Format:
# data_source "my cluster" [polling interval] address1:port addreses2:port ...
#
data_source "HDPTaskTracker" 50 localhost:8658
data_source "HDPDataNode" 50 localhost:8659
data_source "HDPNameNode" 50 localhost:8661
data_source "HDPJobTracker" 50 localhost:8662
data_source "HDPResourceManager" 50 localhost:8664
data_source "HDPHistoryServer" 50 localhost:8666
#
# Round-Robin Archives
# You can specify custom Round-Robin archives here
#
RRAs "RRA:AVERAGE:0.5:1:244" "RRA:AVERAGE:0.5:24:244" RRA:AVERAGE:0.5:168:244" "RRA:AVERAGE:0.5:672:244" "RRA:AVERAGE:0.5:5760:374"
#
# The name of this Grid. All the data sources above will be wrapped in a GRID
# tag with this name.
# default: unspecified
gridname "HDP_GRID"
#
# In earlier versions of gmetad, hostnames were handled in a case
# sensitive manner. If your hostname directories have been renamed to lower
# case, set this option to 0 to disable backward compatibility.
# From version 3.2, backwards compatibility will be disabled by default.
# default: 1 (for gmetad < 3.2)
# default: 0 (for gmetad >= 3.2)
case_sensitive_hostnames 1

复制代码

最后，您需要定制目录/etc/Hadoop/conf或$HADOOP_INSTALL/hadoop/conf中的hadoop-metrics2.properties配置文件。您可以定义适当的源(在本例中，可以是 dfs、jvm、rpc 或 mapred 指标)、吸收器(只是 Ganglia 或 Ganglia 和输出文件的组合)和过滤器(过滤掉您不需要的指标数据)。
要设置源和吸收器，请使用类似如下的代码:

# syntax: [prefix].[source|sink|jmx].[instance].[options]
# See package.html for org.apache.hadoop.metrics2 for details
*.period=60
*.sink.ganglia.class=org.apache.hadoop.metrics2.sink.ganglia.GangliaSink31
*.sink.ganglia.period=10
# default for supportsparse is false
*.sink.ganglia.supportsparse=true
.sink.ganglia.slope=jvm.metrics.gcCount=zero,jvm.metrics.memHeapUsedM=both
.sink.ganglia.dmax=jvm.metrics.threadsBlocked=70,jvm.metrics.memHeapUsedM=40
# Associate sinks with server and ports
namenode.sink.ganglia.servers=localhost:8661
datanode.sink.ganglia.servers=localhost:8659
jobtracker.sink.ganglia.servers=localhost:8662
tasktracker.sink.ganglia.servers=localhost:8658
maptask.sink.ganglia.servers=localhost:8660
reducetask.sink.ganglia.servers=localhost:8660
resourcemanager.sink.ganglia.servers=localhost:8664
nodemanager.sink.ganglia.servers=localhost:8657
historyserver.sink.ganglia.servers=localhost:8666
resourcemanager.sink.ganglia.tagsForPrefix.yarn=Queue

复制代码

将supportsparse设置为true有助于淘汰带宽使用。否则，每次发布指标时都会更新指标缓存，这可能会占用大量 CPU/网络资源。Ganglia slope可以有值zero(度量值始终保持不变)、positive(度量值只能增长)、negative(度量值只能淘汰)或both(度量值可以增长或淘汰)。dmax值表示特定值将保存多长时间。例如，JVM 指标threadsBlocked(来自前面的配置)的值将只保存 70 秒。
正如我在前面的“指标过滤”一节中所讨论的，过滤器在您进行故障排除或需要关注已知题目并且只需要特定指标数据的环境下非常有用。固然，您可以通过gmond.conf中的设置来限制您正在捕捉的指标数据(正如您在本节前面所学的那样)，但是当您需要暂时限制(或捕捉)指标数据时，过滤器会很有用——而且要快！
使用 Ganglia 监控 HBase
Ganglia 可用于监控 HBase，就像您看到的它用于监控 Hadoop 一样。在目录$HBASE_HOME/conf中有一个名为hadoop-metrics.properties的配置文件(此中$HBASE_HOME是 HBase 安装目录)。您需要为 HBase 配置所有“上下文”,以便将 Ganglia 用作输出:

# Configuration of the "hbase" context for Ganglia
hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext
hbase.period=60
hbase.servers=localhost:8649
# Configuration of the "jvm" context for Ganglia
jvm.class=org.apache.hadoop.metrics.ganglia.GangliaContext
jvm.period=60
hbase.servers=localhost:8649
# Configuration of the "rpc" context for Ganglia
rpc.class=org.apache.hadoop.metrics.ganglia.GangliaContext
rpc.period=60
hbase.servers=localhost:8649

复制代码

对于hbase上下文，您可以在 HBase 主服务器上看到 averageLoad(每个区域服务器服务的匀称区域数)或 numRegionServers(在线区域服务器数)等指标的值。
别的，对于jvm上下文，您可以看到 MemHeapUsedM(使用的堆内存，以 MB 为单位)和 MemHeapCommittedM(提交的堆内存，以 MB 为单位)这样的指标。如果不止一个 jvm 正在运行(即不止一个 HBase 进程), Ganglia 会聚合指标值，而不是针对每个实例陈诉它们。
HBase 监控部分到此结束。我在附录 D 中列出了所有 HBase 指标，供您参考。
在结束关于 Ganglia 的讨论之前，我想让您快速浏览一下 Ganglia web 界面。请回顾图 7-4 。它显示了 Ganglia 仪表板，此中显示了上个月的摘要图。您可以看到匀称和最大负载、CPU 使用率、内存使用率和网络使用率。从控制面板中，您可以选择任何这些资源的具体图表，或者为您需要的特定指标创建自定义图表。

图 7-4 。神经节仪表盘

注神经节在http://ganglia.sourceforge.net/可用。神经节的插件在https://github.com/ganglia/可用。Ganglia 的用户社区 URL 是:http://ganglia.info/?page_id=67。
Nagios〔??〕
Nagios 是一个专门的调度和关照引擎。它不监控任何进程或资源，而是调度插件(可实验步伐——Nagios 插件与 Hadoop Metrics 插件不同)的实验，并根据实验状态接纳举措。例如，状态 0 表示成功，1 表示警告，2 表示严重，3 表示未知。您可以配置 Nagios 服务，为配置文件中定义的所有插件的每个输出映射特定的动作。此外，您可以定义自己的插件，并定义监视它们的频率以及映射到每个可能输出的操纵。
除了代码之外，插件还可以返回文本消息，该消息可以写入日志，也可以显示在 web 界面上。如果文本消息包含管道字符，则厥后的文本将被视为性能数据。性能数据包含来自被监控主机的指标，可以通报给外部系统(如 Ganglia)使用。
大多数时间，Nagios 与 Ganglia 一起用于监控。原因是这两种开源工具很好地互补，由于它们有不同的上风。例如，Ganglia 更偏重于网络指标并在一段时间内跟踪它们，而 Nagios 更偏重于作为一种警报机制。由于网络指标和发出警报都是监控的紧张方面，所以它们最好结合使用。Ganglia 和 Nagios 都在集群的所有主机上运行代理，并网络信息。
回到 Nagios，让我从 Nagios 体系结构开始。
架构
Nagios 保卫进程或服务运行在一台主机上，并在所有需要监控的长途主机上运行插件。(要将 Nagios 与 Ganglia 集成，请确保 Ganglia 进程 gmond 正在运行 Nagios 插件的每台主机上运行)。长途 Nagios 插件向 Nagios 服务发送信息和更新，Nagios web 界面显示这些信息。当检测到题目时，Nagios 保卫步伐使用电子邮件或页面(发送到手机的文本消息)关照预定义的管理联系人。配置文件中定义的日志文件中提供了历史日志数据。正如你在图 7-5 中看到的，Nagios 监控系统有三个主要组件:

**服务器:**服务器负责管理和调度插件。服务器定期检查插件状态，并根据状态实验操纵。出现警报时，会关照已配置的管理资源。
插件: Nagios 提供了一组标准的用户可配置插件，您还可以根据需要添加更多插件。插件是可实验步伐(大多用 C、Java、Python 等编写)。它实验特定的任务并将结果返回给 Nagios 服务器。
Nagios 的浏览器界面:这些是由 CGI 天生的网页，显示关于被监控资源的概要信息。

图 7-5 。Nagios 架构

留意 Nagios 在http://www.nagios.org免费提供。你可以在http://nagiosplug.sourceforge.net从 Nagios 插件开发团队下载 Nagios 官方插件。此外，Nagios 社区正在不断开发新的插件，您可以在http://exchange.nagios.org找到。
尽管结合使用 Ganglia 和 Nagios 是一种有用的安全监控方法，但是在默认环境下，这些应用步伐并没有集成。正如下一节所解释的，您需要通过插件来集成它们。
Nagios 与 Ganglia 的集成
Nagios 没有内置的指标。Nagios 实验长途或本地插件，并将它们的状态与用户指定的状态/关照映射进行比较，以实验任何须要的关照任务。像 NRPE (Nagios 长途插件实验器)或 NSCA (Nagios 服务检查吸收器)这样的服务被用于长途实验。但是，如果使用 Ganglia 进行监控，Nagios 需要的所有指标(CPU、内存、磁盘 I/O 等。)已经有了。您只需将 Nagios 指向 Ganglia 来网络这些指标！为了资助您，从版本 2.2.0 开始，Ganglia 项目开始在其 gweb 版本中包含很多官方 Nagios 插件(有关具体信息，请参见https://github.com/ganglia/ganglia-web/wiki/Nagios-Integration)。在 Nagios 中，您可以使用这些插件创建下令和服务，将 Ganglia 捕捉(或天生)的指标与 Nagios 中定义的警报阈值进行比较。
最初，有五个 Ganglia 插件可用:

check_heartbeat(检查心跳以验证主机是否可用)
check_metric(检查特定主机上的单个指标)
check_multiple_metrics(检查特定主机上的多个指标)
check_host_regex(检查 regex 定义的主机范围内的多个指标)
check_value_same_everywhere(检查一组主机上的值是否雷同)

现在，当前的 Ganglia web tarball(版本 3.6.2)包含 10 个用于 Nagios 集成的插件！你可以在http://sourceforge.net/projects/ganglia/files/ganglia-web/3.6.2/下载它来检查五个新插件。
使用 Ganglia 的 Nagios 插件
解压缩后，Ganglia web tarball 包含一个名为nagios的子目录，此中包含 well 脚本以及每个插件的 PHP 脚本。插件的 shellscript 接受参数值，并将它们通报给相应的 PHP 脚本。PHP 脚本处理惩罚这些值，并使用网格状态的 XML 转储(包含所有指标细节的集群状态；由 gmetad 获得)以按照哀求获取当前度量值。一个返回代码(指示哀求的状态)被通报回 Nagios。图 7-6 阐明白这个过程。

图 7-6 。Ganglia-Nagios 集成处理惩罚
记得在使用服务器端 PHP 脚本功能之前启用它，并验证配置文件conf.php(由 gweb 使用)中的以下参数值:

$conf['nagios_cache_enabled'] = 1;
$conf['nagios_cache_file']= $conf['conf_dir']."/nagios_ganglia.cache";
$conf['nagios_cache_time'] = 45;

复制代码

conf.php的位置因操纵系统、Hadoop 发行版和其他因素而异。您的最佳选择是使用find下令:

find / -name conf.php –print

复制代码

使用 Nagios 作为五个 Ganglia 插件中任何一个的调度和警报机制的步骤都非常相似。因此，我将用两个插件来演示这个过程:check_heartbeat和check_multiple_metrics。我还假设您已经安装了 Ganglia、PHP 和 Nagios，并且正在使用 Hortonworks Hadoop 发行版。
check_heartbeat插件是 Ganglia 用来确保主机正常运行的心跳计数器。每当主机收到新的度量数据包时，此计数器都会重置。要在 Nagios 中使用这个插件，首先将 Ganglia web tarball(在我的例子中是/var/www/html/ganglia/nagios)中 Nagios 子目录下的check_heartbeat.sh脚本复制到您的 Nagios 插件目录下(在我的例子中是/usr/lib64/nagios/plugins)。确保脚本中的GANGLIA_URL是正确的。替换您的本田主机名，并检查http://localhost/ganglia是否会将您带到 Ganglia 主页进行安装。然后检查这是否是check_heartbeat.sh中的设置:

GANGLIA_URL=http://*<localhost>*/ganglia/nagios/check_heartbeat.php

复制代码

此时，您可能还想验证 Nagios 服务器上的 PHP 下令行安装是否正常工作；你可以通过运行php –version下令来实现。您应该会看到类似以下内容的相应:

PHP 5.3.3 (cli) (built: Aug 6 2014 05:54:27)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

复制代码

运行插件脚本，并验证它是否正确提供了心跳状态:

> ./check_heartbeat.sh host=pract_hdp_sec threshold=75
OK Last beacon received 0 days, 0:00:07

复制代码

接下来，将这个插件定义为 Nagios 的一个下令(详见侧栏“Nagios 下令和宏”)。阈值是自上次陈诉心跳以来的时间量；也就是说，如果收到的最后一个数据包是在 50 秒之前，您应该将阈值指定为 50:

define command {
command_name check_ganglia_heartbeat
command_line $USER1$/check_heartbeat.sh host=$HOSTADDRESS$ threshold=$ARG1$
}

复制代码

请留意宏$HOSTADDRESS$(替换为主机的 IPaddress)、$USER1$(在资源文件中定义的用户自定义宏)和$ARG1$(下令的第一个参数)的使用。使用宏会将宏中包含的信息自动提供给下令(由于引用的值是可用的)。因此，下令check_ganglia_heartbeat可以用于检查集群中任何主机的心跳。类似地，通报给该下令的参数值允许您在运行时更改该参数。请参考侧栏“Nagios 下令和宏”,了解关于宏的更多细节。
NAGIOS 下令和宏
对于 Nagios，可以将下令定义为包罗服务检查、服务关照、服务事故处理惩罚步伐、主机检查、主构造照和主机事故处理惩罚步伐。下令定义可以包含在运行时替换的宏；这是使 Nagios 灵活的主要特性之一(关于宏的更多信息，请参考http://nagios.sourceforge.net/docs/3_0/macros.html)。
宏可以提供来自主机、服务和其他来源的信息。例如，$HOSTNAME$或$HOSTADDRESS$是经常使用的宏。宏也可以使用 A R G n ARGn ARGn通报参数(第 n 个参数通报给下令*)。Nagios 支持多达 32 个参数宏($ARG1$到$ARG32$)。定义下令的语法如下:*
define command{
command_name
command_line
}
此中<command_name>是下令的名称，而<command_line>是 Nagios 在使用下令时实际实验的内容。
您可以在名为nagios.cfg的 Nagios 主配置文件中定义下令。大多数环境下，该文件驻留在/etc/nagios中，但是对于您的安装，位置可能会有所不同。主配置文件为下令、服务、联系人、模板等定义了单独的对象配置文件。此外，可能会有一个针对 Hadoop 服务器的特定部分。例如，Hortonworks nagios.cfg有以下部分:

# Definitions for hadoop servers
cfg_file=/etc/nagios/objects/hadoop-hosts.cfg
cfg_file=/etc/nagios/objects/hadoop-hostgroups.cfg
cfg_file=/etc/nagios/objects/hadoop-servicegroups.cfg
cfg_file=/etc/nagios/objects/hadoop-services.cfg
cfg_file=/etc/nagios/objects/hadoop-commands.cfg

复制代码

我将在配置文件/etc/nagios/objects/hadoop-commands.cfg中定义下令check_ganglia_heartbeat。最后一步是为 Nagios 定义一个服务。在 Nagios 中，术语服务的使用非常通用或者不明确。它可以指示主机上运行的实际服务(例如，POP、SMTP、HTTP 等)。)或与主机相关联的某种其他类型的度量(空闲磁盘空间、CPU 使用率等)。).服务在配置文件/etc/nagios/objects/hadoop-services.cfg中定义，其语法如下:

define service {
host_name localhost
use hadoop-service
service_description GANGLIA::Ganglia Check Heartbeat
servicegroups GANGLIA
check_command check_ganglia_heartbeat!50
normal_check_interval 0.25
retry_check_interval 0.25
max_check_attempts 4
}

复制代码

请留意，check_command表示将在指定主机上实验的实际下令。参数normal_check_interval指示在安排服务的下一次检查之前要等待的时间单位数。一个时间单位是 60 秒(这是默认值)，因此 0.25 表示 15 秒。retry_check_interval定义了当服务变为非正常状态时，在安排重新检查服务之前等待的时间单位数，而max_check_attempts表示在这种环境下重试的次数。
下令check_multiple_metrics检查多个 Ganglia 指标并天生一个警报。要使用它，请将 Ganglia web tarball 中 Nagios 子目录下的check_multiple_metrics.sh脚本复制到您的 Nagios 插件目录中。确保脚本中的GANGLIA_URL被设置为http://localhost/ganglia/nagios/check_heartbeat.php，还记得用适当的主机名替换localhost。
在配置文件/etc/nagios/objects/hadoop-commands.cfg中定义相应的下令check_ganglia_multiple_metrics:

define command {
command_name check_ganglia_multiple_metrics
command_line $USER1$/check_multiple_metrics.sh host=$HOSTADDRESS$ checks='$ARG1$'
}

复制代码

您可以添加用冒号分隔的检查列表。每次检查由Metric_name,operator,critical_value组成。接下来，在配置文件/etc/nagios/objects/hadoop-services.cfg中定义相应的服务:

define service {
host_name localhost
use hadoop-service
service_description GANGLIA::Ganglia check Multiple Metric service
servicegroups GANGLIA
check_command check_ganglia_multiple_metrics!disk_free,less,10:load_one,more,5
normal_check_interval 0.25
retry_check_interval 0.25
max_check_attempts 4
}

复制代码

留意定义要实验的下令的check_command部分:

check_ganglia_multiple_metrics!disk_free,less,10:load_one,more,5.

复制代码

这表示如果(主机的)可用磁盘空间低于 10GB，或者如果 1 分钟匀称负载凌驾 5，将会天生警报。
成功定义 Ganglia 插件后，您可以使用 Nagios web 界面来检查和管理这些插件。正如您在图 7-7 中看到的，新的check_heartbeat和check_multiple_metrics插件已经就位，并由 Nagios 管理。

图 7-7 。带插件的 Nagios web 界面
如果您想要更多的训练，您可以遵循雷同的步骤并添加其他三个插件。
Nagios 社区
Nagios 的真正上风在于其活跃的用户社区，该社区不停致力于更有用地使用 Nagios，并添加插件来加强其功能。要查察其他用户开发的最新插件，请访问位于http://exchange.nagios.org/directory/Plugins的社区页面。出于安全目的，您会发现很多可以有用使用的插件，例如:

check_ssh_faillogin :监控ssh次失败的登录尝试；在http://exchange.nagios.org/directory/Plugins/Security/check_ssh_faillogin/details有售。
显示 _ 用户: 显示已登录的用户。可以使用白名单、黑名单或两者同时使用，对登录的特定用户发出警报。详情请见:http://exchange.nagios.org/directory/Plugins/System-Metrics/Users/Show-Users/details
**check _ long _ running _ procs . sh:**检查长时间运行的流程；在http://exchange.nagios.org/directory/Plugins/System-Metrics/Processes/Check-long-running-processes/details可用。

您可以使用与使用 Ganglia 插件雷同的过程来使用任何新插件。您需要将它复制到 Nagios 插件目录，然后定义一个下令和服务。固然，请遵循各个插件的任何特定安装阐明，或者安装它们运行所需的任何附加包。
摘要
在本章中，我讨论了 Hadoop 的监控以及流行的开源监控工具。请记着，监视需要对需要监视的资源和您筹划监视的环境有很好的了解。虽然我可以告诉您 Hadoop 集群需要监控什么，但是您最了解您的环境的具体需求。我已经尝试提供一些一般性的提示，但是从我的经验来看，监视总是比您自己的系统管理员对您的环境的了解和理解要好。
“相关性”(一个系统的“最新”或“最先辈”程度)也是一个非常有用的思量因素。您必须每天关注您感兴趣领域的所有创新(包罗恶意攻击),并根据它们调整您的监控。请记着，最好的系统管理员是那些最警觉、反应最敏捷的人。
最后，请试着透过特定的工具和版本号来理解本章中描述的监控技术背后的原理和意图。您可能无法使用雷同的工具进行监控，但是如果您遵循这些原则，您将能够创建有用的监控系统——最终，这是我们的共同目标。
八、Hadoop 中的加密

近来，我和一个朋侪谈论可能使用 Hadoop 来加速对他公司的 4TB“海量”数据堆栈的陈诉。(他是芝加哥地区最大的房地产公司之一的 IT 部门主管。)虽然他勉强同意了一个可能的性能收益，但是他非常自大地问道，“但是加密我们的 HR(人力资源)数据呢？对于基于 MS SQL Server 的 HR 数据，我们使用对称密钥加密和证书，并辅以 C#代码。你如何用 Hadoop 实现这一点？”
随着 Hadoop 越来越多地在企业环境中使用，越来越多的人会问同样的题目。答案并不简单。大多数 Hadoop 发行版现在已经安装和/或实现了 Kerberos，并且包罗实现授权和传输加密的简单选项，但是对于 Hadoop 的静态加密，您的选项是有限的，尤其是文件级粒度。
当数据处于静止状态并存储在磁盘上时，为什么需要对其进行加密？当黑客完全访问您的数据时，加密是最后一道防线。知道你的数据仍旧是安全的，这是一种令人欣慰的感觉，由于没有加密它的密钥，它就不能被解密和使用。但是，请记着，加密是用于对抗未授权的访问，因此不能被认证或授权所代替(这两者都控制授权的访问)。
在本章中，我将讨论静态加密，以及如安在 Hadoop 中实现它。首先，我将扼要概述 DES 和 AES 算法使用的对称(密钥)加密、RSA 算法使用的非对称(公钥)加密、密钥交换协媾和证书、数字签名以及加密哈希函数。然后，我将解释 Hadoop 中需要加密的内容以及如何加密，并讨论英特尔 Hadoop 发行版，该发行版现在筹划部分随 Cloudera 的发行版提供，也可通过 Project Rhino 开源获得。最后，我将讨论如何使用 Amazon Web Services 的 Elastic MapReduce(或预装 Hadoop 的虚拟机)来实现静态加密。
数据加密简介
暗码学可以非常有用地用来对抗多种安全威胁。无论您将数据称为加扰的、伪装的还是加密的，它都不容易被读取、修改或操纵。幸运的是，即使暗码学劈头于高等数学，你也不需要理解它的数学基础来使用它。简单理解一下，一种常见的方法是将加密创建在一个密钥(一种用作加密息争密基础的独特字符模式)和一个算法(根据需要使用密钥对数据进行加扰或解扰的逻辑)的基础上。参见“加密的根本原理”侧栏，了解更多关于加密的构建模块*。*
加密的根本原理
小时间，我和我的朋侪们开发了我们自己的特别代码语言，以便在学校里交换。任何需要在讲堂上通报的信息都包含像“4 21 8 0 27 18 24 0 6 18 16 12 17 10”这样的数字序列，如果我们被捉住了，就会让老师感到困惑。
我们的代码是一个简单的替换暗码的例子，此中数字(表示字母表中的位置)被替换为字母，然后每个数字加一个 3；0 被用作单词分隔符。于是，上面的序列简单的问了对方一句“你来吗”？虽然我们的代码非常简单，但实际应用中的数据加密使用复杂的暗码，这些暗码依赖于复杂的逻辑来替换字符。在某些环境下，一个键，如一个单词或数学表达式，被用来调换字母。因此，例如，使用“myword”作为密钥，ABCDEFGHIJKLMNOPQRSTUVWXYZ 可以映射到my wordabcefghijklnpqstuvwxyz，这意味着短语“Hello world”的暗码文本将是“Brggj ujngo”。为了增长复杂度，可以用字母在字母表中的位置代替表达式 2 x + 5 £ 26 中的 x 来映射 ABCDEFGHIJKLMNOPQRSTUVWXYZ 到 gikmoqsuwyabcdefhjlnprtvxz。复杂的替换暗码可用于加强安全性，但一个大题目是加密息争密它们所需的时间。
另一种加密方法是转置(也称为重新排序、重新排列或置换)。换位是一种加密，此中原始文本的字母被重新排列以天生加密文本。通过在信息中传播信息，换位使信息难以理解。这种加密的一个非常简单的例子是列转置，它涉及到将文本行转置为列。例如，要将短语“你现在能读这个吗”转置为六列转置，我可以将字符写成六行，并一行接一行地排列:
C A N Y O U
R E A D T H
然后，天生的暗码文本将按列读取:“cri aes nan ydo otw uh”。由于所需的存储空间息争密密文所涉及的耽误，当时间至关紧张时，这种算法并不特别适合于长消息。
虽然替换和转置暗码并不单独用于实际世界的数据加密，但它们的组合构成了一些广泛使用的商业级加密算法的基础。
流行的加密算法
有两种根本的基于密钥的加密:对称的和非对称的。对称算法通常被称为机密密钥 ，使用雷同的密钥进行加密息争密。两个用户共享一个密钥，他们都用这个密钥来加密和发送信息给对方，以及解密来自对方的信息——就像我童年的朋侪和我用雷同的数字替换密钥来编码我们在讲堂上通报的笔记一样。由于每对筹划使用它的用户都需要一个单独的密钥，所以密钥分发是使用对称加密的一个主要题目。数学上， n 需要成对通讯的用户需要n×(n–1)/2 个密钥。因此，随着用户数量的增长，密钥的数量险些呈指数增长。使用对称密钥的两种流行算法是 DES 和 AES(稍后将具体先容)。
非对称或公钥系统不存在密钥分配和密钥指数的题目。公钥可以通过电子邮件消息分发，或者复制到共享目录中。使用它加密的消息可以使用相应的私钥解密，该私钥只有授权用户拥有。由于一个用户(在一个系统内)可以使用任何其他用户的公钥来加密发给他的消息(该用户有相应的私钥来解密)，密钥的数量仍旧很少——是用户数量的两倍。流行的加密算法 RSA 使用公钥。然而，公钥加密通常比对称密钥加密慢 10，000 倍，由于公钥加密使用的模幂运算涉及乘法和除法，比对称算法使用的位操纵(加法、异或、替换、移位)慢。因此，对称加密更常用，而公钥加密则保存给速度不是限制因素的特别应用。公钥加密变得非常有用的一个地方是对称密钥交换:它允许对称密钥的受保护交换，然后可以用它来保护进一步的通讯。
对称和非对称加密，尤其是 DES、AES 和 RSA，被用作实验诸如签署文档、检测更改和交换敏感数据等盘算任务的构建模块，您将在“加密的应用”一节中了解到这一点。现在，让我们仔细看看这些流行的算法。
数据加密标准(DES)
由 IBM 在其 Lucifer 算法的基础上开发的数据加密标准 ( DES )于 1976 年 11 月被正式接纳为美国联邦标准，用于所有公共和私营部门的非机密通讯。DES 算法是加密的两个根本原理的复杂组合:替换和换位。该算法的稳健性是由于在总共 16 个循环中重复应用这两种技术。DES 算法是一种块算法，这意味着它使用 64 位数据块而不是字符流。它将输入数据块分成两半，分别对每一半实验替换，将密钥与此中一半融合，最后交换这两半。这个过程实验 16 次，详见“DES 算法”侧栏。
DES 算法
对于 DES 算法，当最初的 64 个数据位通过初始置换进行转置时，第一个加密周期开始。首先，64 个转置数据位被分成左半部分和右半部分，每部分 32 位。64 位密钥(56 位用作密钥；其余的是奇偶校验位)用于变动数据位。接下来，密钥左移预定数量的位并被转置。产生的密钥与右半部分组合(替换),并且在一轮排列之后，结果与左半部分组合。这成为新的右半边。旧的右半部分(与键和左半部分结合之前的部分)成为新的左半部分。该循环(图 8-1 )实验 16 次。在最后一个循环完成后，实验最终的转置(与初始置换相反)以完成算法。

图 8-1 。DES 算法的循环
由于 DES 将其算术和逻辑运算限制为 64 位数字，所以它可以在当前大多数 64 位操纵系统上与软件一起用于加密。
这种算法的真正弱点是抵抗一种称为差分暗码分析的攻击，在差分暗码分析中，可以在 258 次搜索中从选择的密文中确定密钥。暗码分析攻击没有暴露 DES 中任何庞大的、可使用的漏洞，但是随着盘算本事的容易获得，使用 56 位密钥的风险正在增长。尽管破解 DES 所需的盘算本事或时间仍旧很紧张，但一个有刻意的黑客肯定能解密用 DES 加密的文本。如果使用三重 DES 方法(使用序列调用 DES 三次进行加密:通过 Key1 加密，使用 Key2 解密，使用 Key3 加密)，则有用密钥长度变为 112(如果三个密钥中只有两个是唯一的)或 168 位(如果 Key1、Key2 和 Key3 都是唯一的)，攻击难度成倍增长。DES 可以在短期内使用，但肯定会寿终正寝，需要被更结实的算法所代替。
高级加密标准(AES)
1997 年，美国国家标准与技术研究所呼吁接纳新的加密算法；随后，高级加密标准 ( AES )成为 2001 年的新标准。最初被称为 Rijndael ，AES 也是一种分组暗码，使用多个循环或回合，使用 128 的输入数据块巨细来加密数据。128、192 和 256 位的加密密钥分别需要 10、12 或 14 个加密周期。AES 的循环很简单，包罗一个替换、两个置换函数和一个键控函数(更多细节见侧栏“AES 算法”)。AES 没有已知的弱点，并且在商业上广泛使用。
AES 算法
为了资助您直观地了解 AES 的操纵，我先假设输入数据长度为 9 个字节，并将 AES 矩阵表示为一个 3 × 3 数组，数据字节为 b0 至 b8。
如图 8-2 所示，AES 算法的每一轮由以下四个步骤组成:

替换:为了扩散数据，使用替换表替换 128 位数据块的每个字节。
移位行:通过左循环移位对数据行进行置换；行 n 的第一个(最左边，高位) n 元素被移至末尾(最右边，低位)。因此，行 n 向左循环移位(n–1)字节。
混淆列:为了转换列，每列的三个元素乘以一个多项式。对于每个元素，比特被左移并与它们自身进行异或运算，以将该列的每个元素扩散到该列的所有三个元素上。
添加循环密钥:最后，对这个循环唯一的密钥(子密钥)的一部分进行异或运算或添加到每个数据列。子密钥是通过对密钥进行一系列置换、替换和异或运算而从密钥中得到的。

图 8-2 。AES 算法的周期
里维斯特-沙米尔-阿德尔曼加密
对于 DES、AES 和其他对称密钥算法，每对用户都需要一个单独的密钥。每增长一个用户( n + 1)， n 就需要更多的密钥，这使得很难跟踪你需要与之通讯的每个额外用户的密钥。确定和分发这些密钥可能是一个题目，维护分发的密钥的安全性也是一个题目，由于它们不可能都被记着。然而，非对称或公钥加密有助于制止对称密钥加密遇到的这一题目和很多其他题目。使用公钥加密的最闻名的算法是Rivest-sha mir-Adelman(RSA)算法。RSA 于 1978 年推出，并以其三位发明者(Rivest、Shamir 和 Adelman)的名字命名，至今仍旧安全，没有发现严重的缺陷。要了解 RSA 如何工作，请参见“Rivest-Shamir-Adelman (RSA)加密”侧栏。
RIVEST-SHAMIR-ADELMAN (RSA)加密
RSA 加密算法将数论的结果与确定给定数字的质因数的难度结合起来。RSA 算法用算术模 n 运算；对于一个数 P 的模 n 是你用 P 除以 n 的余数。
RSA 中用于解密和加密的两个密钥是可以互换的；可以选择任一个作为公钥，另一个可以用作私钥。任何明文块 P 都被加密为Pemodn。由于是求幂运算，mod n 和 e 以及 n 都黑白常大的数( e 一般是 100 位， n 一般是 200 位)，因式分解 P e 来解密加密的明文险些是不可能的。选择解密密钥 d 使得(Pe)dmodn=P。因此，知道 d 的正当吸收者可以简单地确定(Pe)dmodn=P，从而规复 P ，而不需要因式分解 P e 。加密算法基于分解大数的根本题目，该题目没有简单或快速的解决方案。
如何确定加密密钥？如果你的明文是 P ，你在盘算Pemodn，那么加密密钥将是数字 e 和 n ，解密密钥将是 d 和 n 。作为两个质数 p 和 q 的乘积， n 的值应该非常大，通常大约 100 位或大约 200 个十进制数(或 512 位)长。如果需要， n 可以是 768 位甚至 1024 位。 n 的值越大，因式分解 n 以确定 p 和 q 的难度就越大。
下一步，选择一个数 e ，使得 e 与(p-1)×(q-1)没有共同的因子。确保这一点的一种方法是选择 e 作为大于( p - 1)以及( q - 1)的素数。
最后，选择这样一个数字 d ,数学上:
e × d = 1 mod (p - 1) × (q - 1)
如你所见，即使已知 n 是两个素数的乘积，但如果它们很大，从 e 中确定素数 p 和 q 或私钥 d 是不可行的。因此，该方案为 d 提供了足够的安全性。这也是 RSA 安全并在商业上使用的原因。不外，值得留意的是，由于改进的算法和加强的盘算本事，多达 1024 位的 RSA 密钥已经被破解(尽管无论如何都不是微不足道的)。因此，被认为对大多数应用足够安全的密钥巨细是 2048 位；对于更敏感的数据，应该使用 4096 位。
数字签名算法加密
另一种使用公钥加密的流行算法是 DSA ( 数字签名算法)。尽管这个算法的最初目的是签名，但它也可以用于加密。DSA 安全性具有基于离散对数题目的理论数学基础，并且是使用离散对数题目没有快速或有用解决方案的假设来设计的。表 8-1 比较了 DSA 和 RSA。
表 8-1 。DSA 与 RSA
|
属性
|
目录系统代理(Directory System Agent)
|
南非共和国(Republic of South Africa)
|
| — | — | — |
| 密钥天生 | 更快的 | |
| 加密 | | 更快的 |
| [通讯]解密 | 更快 ** | |
| 数字签名天生 | 更快的 | |
| 数字签名验证 | | 更快的 |
| 较慢的客户端 | | 更好的 |
| 较慢的服务器 | 更好的 | |
** 请留意，“更快”也意味着使用更少的盘算资源
总而言之，DSA 和 RSA 具有险些雷同的加密强度，尽管它们各有自己的性能上风。在出现性能题目的环境下，评估题目出在那里(客户端还是服务器)并以此为基础选择关键算法可能是个好主意。
加密的应用
在很多环境下，一种类型的加密比另一种更适合您的需要，或者您可能需要多种加密方法的组合来满足您的需要。您将遇到的加密算法的四种常见应用是加密散列函数、密钥交换、数字签名和证书。对于 HDFS，客户端数据访问使用 TCP/IP 协议，该协议反过来使用 SASL 和数据加密密钥。Hadoop web 控制台和 MapReduce shuffle 使用使用公钥证书的安全 HTTP。英特尔的 Hadoop 发行版(现在的 Project Rhino)使用对称密钥进行静态加密，使用证书通过 MapReduce 作业进行加密数据处理惩罚。为了更好地理解 Hadoop 和其他应用步伐如何使用这些应用步伐，您需要了解每个应用步伐是如何工作的。
哈希函数
在某些环境下，诚信比保密更紧张。例如，在存储法律文档或管理贷款的文档管理系统中，知道文档没有被更改是很紧张的。因此，加密也可以用来提供完整性。
在大多数文件中，内容的组件没有以任何方式绑定在一起。换句话说，文件中的每个字符都是独立的，即使更改一个值会影响文件的完整性，也很容易被检测到。加密可以用来“密封”文件，这样任何更改都可以很容易地被检测到。提供这种密封的一种方法是盘算一个加密函数，称为文件的散列或校验和，或消息摘要。由于散列函数依赖于被密封文件的所有位，所以改变一位将改变校验和结果。每次访问或使用文件时，哈希函数都会重新盘算校验和，只要盘算出的校验和与存储的值匹配，就可以知道文件没有被更改。
DES 和 AES 非常适合于密封值，由于需要一个密钥来修改存储的值(以匹配修改的数据)。分组暗码也使用一种叫做链接的技术:通过使用异或将加密的前一个块与当前块的加密相结合，一个块链接到前一个块的值，从而链接到文件中所有前一个块，就像一个链。随后，文件的加密校验和可能是文件的链式加密的最后一个块，由于该块依赖于所有其他块。常见的哈希函数有 MD4 、 MD5 (MD 意为消息摘要)、以及 SHA / SHS (安全哈希算法或标准)。究竟上，当具有 Hadoop 令牌凭证的 Hadoop 客户端连接到 Hadoop 保卫步伐(例如，读取/写入 HDFS 的 MapReduce 任务)时，Hadoop 使用 SASL MD5-DIGEST 机制进行认证。
密钥交换
假设你需要与一个陌生人(他也不认识你)交换信息，同时确保没有其他人可以访问这些信息。解决方案是公钥加密。由于非对称密钥是成对的，所以一对密钥中的一半可以公开，而另一半不会受到影响。私钥可以用来加密，吸收方只需要有公钥就可以解密。为了理解这一点的紧张性，思量一个示例密钥交换。
假设萨姆和罗伊需要交换一个共享的对称密钥，并且两人都有一个通用加密算法的公钥(称这些为 K PUB-S 和 K PUB-R )以及私钥(称这些为 K PRIV-S 和 K PRIV-R )。最简单的解决方案是 Sam 选择任意对称密钥 K，并使用他的私钥(K PRIV-S )对其进行加密，然后将其发送给 Roy，Roy 可以使用 Sam 的公钥来解除加密并获得 K。不幸的是，任何能够访问 Sam 的公钥的人也可以获得仅对 Roy 有用的对称密钥 K。因此，更安全的解决方案是 Sam 首先使用他自己的私钥加密对称密钥 K，然后使用 Roy 的公钥再次加密它。然后，罗伊可以用他的私钥解密第一级加密(外部加密)——这是只有他能做的事情——然后用萨姆的公钥解密“内部加密”(证实通讯来自萨姆)。因此，总之，对称密钥可以在不侵害安全性的环境下进行交换。
数字签名和证书
今天，我们的大部分日常生意业务都是在数字世界中进行的，因此用于批准的签名的概念已经发展成一种依赖于数字签名的相互认证的模型。一个数字签名是一个像真实签名一样工作的协议:它可以为发送者提供一个唯一的标志，并使其他人能够从该标志中识别发送者，从而确认一个协议。数字签名需要以部属性:

不可复制
唯一可追溯的来源真实性(仅来自预期来源)
与信息不可分割
传输后不可变
近来使用过一次，不应允许重复使用

公钥加密系统非常适合数字签名。例如，出书公司可以先用自己的私钥加密条约，然后再用作者的公钥加密。作者可以使用他的私钥解密第一级加密，然后使用发布者的公钥解密内部加密以获得条约。之后，作者可以通过创建条约的哈希值，然后用自己的私钥加密条约和哈希值来“签名”。最后，他可以通过使用发布者的公钥再次加密来增长一层加密，然后将加密的条约通过电子邮件发送回发布者。由于只有作者和出书商有权访问他们的私钥，所以交换显然是不可伪造的，并且是唯一可信的。哈希函数和校验和确认了不变性(假设盘算并保存了条约的初始校验和以供比较)，而电子邮件的频率和时间戳确保了近来的一次性使用。图 8-3 总结了该过程。

图 8-3 。使用数字签名进行加密通讯
在图 8-3 中，E(C，K PRIV-P 表示契约 C 是用 KPRIV-P加密的，同样，D(E(E(C，K PRIV-P ，K PUB-A ，K PRIV-A 表示发送给作者的双重加密契约的第一级是用 KPRIV-A解密的)
数字证书创建在各方之间通过一个共同的受恭敬的个人的信任基础上，它在多方之间的作用类似于数字签名对两个人的作用。公钥和用户的身份在一个证书中相关联，然后由一个认证机构进行“签名”，证实关联的准确性并认证身份。
例如，一家出书公司可能会创建一个证书方案，以下列方式对作者、他们的代理和公司编辑进行认证。首先，发布者选择一个公钥对，将公钥公布在公司中每个人都可以访问的地方，并保存私钥。然后，每个编辑创建一个公钥对，将公钥和他或她的身份一起放入消息中，并将消息安全地通报给发布者。发布者通过创建消息的哈希值对其进行签名，然后用他或她的私钥对消息和哈希值进行加密。通过签署消息，发布者确认消息中的公钥(编辑者的)和身份(也是编辑者的)是同一个人的。这条消息被称为编辑证书。作者可以用他的公钥创建一个消息，作者的代理可以签名、散列并返回它。那将是作者的证实。因此，作者和编辑的证书可以创建和用于验证他们的身份。任何人都可以通过从发布者的公钥开始并解密编辑者的证书以检索他或她的公钥和身份来验证编辑者的证书。可以通过从代理从发布者处获得的公钥开始验证作者的证书，并使用该公钥解密证书以检索作者的公钥和身份。
由于 Hadoop 为其各种组件使用不同类型的加密，所以我将在下一节中扼要讨论这些加密在那里使用。
Hadoop 加密选项概述
当思量 Hadoop 中敏感数据的加密时，您需要思量存储在集群节点内磁盘上的“静态”数据，以及传输中的数据，这些数据在不同节点之间以及节点和客户端之间的通讯过程中会移动。第四章解释了保护节点和应用步伐之间传输的数据的细节；您可以为加密配置单个 Hadoop 生态系统组件(使用组件的配置文件)，就像您为加密配置 Hadoop 的 RPC 通讯一样。例如，要为 Hive 配置 SSL 加密，您需要在hive-site.xml中更改配置(需要将hive-site.xml中的属性hive.server2.use.SSL设置为true，并且需要使用属性hive.server2.keystore.path和hive.server2.keystore.password来指定密钥库)。因此，本章重点先容静态配置 Hadoop 数据。

留意加密是一项 CPU 密集型活动，会加重硬件负担，低落处理惩罚速度。仔细权衡使用加密的决定。如果您确定加密是必要的，则对存储在集群中的所有数据以及与该数据相关的处理惩罚实现加密。
对于 Hadoop 集群，静态数据是分布在所有 DataNodes 上的数据。需要加密可能是由于数据是敏感的，信息需要得到保护，或者加密对于服从法律法规(如保险业的 HIPAA 或金融业的 SOX)是必要的。
尽管目前没有 Hadoop 发行版提供静态加密，但 Cloudera 和 Hortonworks 等主要供应商提供了第三方解决方案。例如，Cloudera 与 Gazzang 的 zNcrypt 互助，为数据块和文件提供静态加密。为了提供额外的保护，zNcrypt 使用基于进程的 ACL 和密钥。此外，亚马逊 Web 服务(AWS) 通过其弹性 MapReduce web 服务和 S3 存储提供静态加密(您将很快了解到更多信息)，英特尔的 Hadoop 发行版也提供静态加密。但所有这些解决方案要么是专有的，要么将您限制在 Hadoop 的特定发行版上。
对于加密静态 Hadoop 数据的开源解决方案，您可以使用 Project Rhino。2013 年，英特尔启动了一个开源项目，通过向 Apache 贡献代码来提高 Hadoop 和 Hadoop 生态系统的安万本事。该代码尚未在 Apache Foundation 的 Hadoop 发行版中实现，但它包含了一些加强功能，包罗分布式密钥管理和静态加密功能。这个开源项目的总体目标如下:

支持加密和密钥管理
通用授权框架(逾越 ACL)
一个通用的基于令牌的认证框架
HBase 的安全性改进
改进的安全审计

你可以在https://github.com/intel-hadoop/project-rhino查察 Project Rhino 的进度，在下一节了解更多。
使用英特尔的 Hadoop 发行版进行加密
2013 年，英特尔公布了自己的 Hadoop 发行版——对于一家硬件制造公司来说，这是一个奇怪的决定，通过 Hadoop 发行版姗姗来迟地进入大数据领域。然而，英特尔向 Hadoop 世界包管，它的意图只是为 Hadoop 生态系统(Apache 基金会)做出贡献，并资助解决 Hadoop 安全题目。英特尔声称其 Hadoop 发行版与特定的英特尔芯片(用作 CPU)完美协调，加密息争密速度比当前的替换产物快 10 至 15 倍。
大约在同一时间，我有机会与英特尔团队互助，为一个需要加密存储在 HDFS 的数据的客户进行试点项目，我了解了英特尔的加密技术是如何工作的。客户使用 Hive 进行查询和陈诉，英特尔提供涵盖 HDFS 和 Hive 的加密。虽然我所使用的发行版(它构成了本节所先容信息的基础)还没有上市，但它所提供的大部分功能都可以通过 Project Rhino 和 Cloudera 的 Hadoop 发行版获得(现在英特尔已经投资了该发行版)。
具体来说，英特尔发行版使用编解码器来实现加密(稍后将具体先容)，并提供可用于 Hive 或 HBase 的文件级加密。它将对称和非对称密钥与 Java 密钥库结合使用(更多信息请参见侧栏“密钥库和信任库”)。我使用的实现细节将让您对 Project Rhino 的潜力有所了解。
密钥库和信任库
密钥库是用于各种目的的密钥或可信证书的数据库或储存库，包罗认证、加密和数据完整性。密钥条目包含所有者的身份和私钥，而可信证书条目除了实体的身份之外，只包含公钥。为了更好的管理和安全性，您可以使用两个密钥库:一个包含您的密钥条目，另一个包含您的可信证书条目(包罗证书颁发机构的证书)。使用您的私钥可以限制对密钥库的访问，而可信证书驻留在更容易公开访问的信任库中。
在决定信任什么时使用，信任库 包含来自您希望与之通讯的某人的证书，或者来自您信任以识别其他方的证书颁发机构的证书。仅当您信任埋伏条目的来源实体时，才将条目添加到信任库。
有各种类型的密钥库可用，如 PKCS12 或 JKS。JKS 是 Java 世界中最常用的。PKCS12 不是特定于 Java 的，但是对于具有从浏览器备份的私钥或者来自基于 OpenSSL 的工具的私钥的证书来说，使用起来很方便。PKCS12 主要用作密钥库，但对信任库来说用处不大，由于它需要一个与证书相关联的私钥。JKS 不要求每个条目都是私钥条目，因此您可以将它用作您信任但不需要私钥的证书的信任库。
渐渐实现
该客户的要求是对存储在 HDFS 并使用 Hive 访问的敏感财务数据进行静态加密。因此，我必须确保从 SQL Server 作为文本文件推送的数据文件在存储于 HDFS 时是加密的，并且只能由授权用户通过 Hive 正常访问(应用解密)。图 8-4 提供了加密过程的概述。

图 8-4 。英特尔 Hadoop 发行版的数据加密
实现我的目标的第一步是用下令创建一个机密(对称)密钥和密钥库(我在我的主目录下创建了一个目录/密钥，并在那边创建了所有与加密相关的文件):

> keytool -genseckey -alias BCLKey -keypass bcl2601 -storepass bcl2601 -keyalg AES -keysize 256 -KeyStore BCLKeyStore.keystore -storetype JCEKS

复制代码

这个keytool下令天生密钥BCLKey，并将其存储在新创建的名为BCLKeyStore的密钥库中。keyalg参数指定用于天生密钥的算法AES，而keysize 256指定要天生的密钥的巨细。最后，keypass是用于保护密钥的暗码，storepass对密钥库也是如此。您可以使用以下下令调整密钥库的权限:

> chmod 600 BCLKeyStore.keystore

复制代码

接下来，我用以下下令创建了一个密钥对(私钥/公钥)和密钥库:

> keytool -genkey -alias KEYCLUSTERPRIVATEASYM -keyalg RSA -keystore clusterprivate.keystore -storepass 123456 -keypass 123456 -dname "CN= JohnDoe, OU=Development, O=Intel, L=Chicago, S=IL, C=US" -storetype JKS -keysize 1024

复制代码

这将天生一个密钥对(一个公钥和相关的私钥)和单元素证书链，作为条目KEYCLUSTERPRIVATEASYM存储在密钥库clusterprivate.keystore中。留意使用算法RSA进行公钥加密和密钥长度1024。参数dname指定与alias关联的名称，作为自签名证书中的颁发者和主体。
我使用英特尔管理器(admin)

配置

安全

密钥管理在集群中分发创建的密钥库clusterprivate.keystore。
为了创建信任库，我接下来接纳了以下步骤:

Extract the certificate from the newly created KeyStore with the command:
1. > keytool -export -alias KEYCLUSTERPRIVATEASYM -keystore clusterprivate.keystore -rfc -file hivepublic.cert -storepass 123456
复制代码
该下令从 KeyStore clusterprivate.keystore中读取与alias KEYCLUSTERPRIVATEASYM相关联的证书，并将其存储在文件hivepublic.cert中。证书将以可打印的编码格式输出(如-rfc选项所示)。
Create a TrustStore containing the public certificate:
1. > keytool -import -alias HIVEKEYCLUSTERPUBLICASYM -file hivepublic.cert -keystore clusterpublic.TrustStore -storepass 123456
复制代码
该下令从文件hivepublic.cert中读取证书(或证书链),并将其存储在由HIVEKEYCLUSTERPUBLICASYM标识的密钥库(用作信任库)条目中。信任库clusterpublic.TrustStore被创建，导入的证书被添加到可信证书列表中。
用
1. > chmod 644 clusterpublic.TrustStore
2. > chown root:hadoop clusterpublic.TrustStore
复制代码
下令将clusterpublic.TrustStore所有权改为root，组改为hadoop，权限改为"644" (read/write for root and read for members of all groups)
创建一个文件TrustStore.passwords *，*将其权限设置为644，并在文件中添加以下内容:keystore.password=123456。
将/keys目录及其所有文件复制到集群中的所有其他节点。在每个节点上，密钥库目录必须在/usr/lib/hadoop/中。

准备好信任库后，我随后创建了一个文本文件(bcl.txt)用于测试加密，并将其复制到 HDFS:

> hadoop fs -mkdir /tmp/bcl.....
> hadoop fs -put bcl.txt /tmp/bcl

复制代码

启动 Pig (> pig)，被带到grunt>提示。我在 Pig 中实验了以下下令来设置所有需要的环境变量:

set KEY_PROVIDER_PARAMETERS 'keyStoreUrl=file:root/bcl/BCLKeyStore.keystore&keyStoreType-JCEKS&password=bcl2601';
set AGENT_SECRETS_PROTECTOR 'com.intel.hadoop.mapreduce.crypto.KeyStoreKeyProvider';
set AGENT_PUBLIC_KEY_PROVIDER 'org.apache.hadoop.io.crypto.KeyStoreKeyProvider';
set AGENT_PUBLIC_KEY_PROVIDER_PARAMETERS 'keyStoreUrl=file:keys/clusterpublic.TrustStore&keyStoreType=JKS&password=123456';
set AGENT_PUBLIC_KEY_NAME 'HIVEKEYCLUSTERPUBLICASYM';
set pig.encrypt.keyProviderParameters 'keyStoreUrl=file:root/bcl/BCLKeyStore.keystore&keyStoreType-JCEKS&password=bcl2601';

复制代码

接下来，为了从 HDFS 读取bcl.txt文件，对其进行加密，并将其存储到名为bcl_encrypted的目录中的雷同位置，我发出了以下下令:

raw = LOAD '/tmp/bcl/bcl.txt' AS (name:chararray,age:int,country:chararray);
STORE raw INTO '/tmp/bcl/bcl_encrypted' USING PigStorage('\t','-keyName BCLKey');

复制代码

退出 Pig 后，我通过发出以下下令检查加密文件的内容:

> hadoop fs -cat /tmp/bcl/bcl_encrypted/part-m-00000.aes

复制代码

控制字符似乎确认了加密。我使用以下步骤创建了一个 Hive 外部表并将其指向加密文件:

启动蜂巢。
设置环境变量:
1. set hive.encrypt.master.keyName=BCLKey;
2. set hive.encrypt.master.keyProviderParameters=keyStoreUrl=file:////root/bcl/BCLKeyStore.keystore&keyStoreType=JCEKS&password=bcl2601;
3. set hive.encrypt.keyProviderParameters=keyStoreUrl=file:////root/bcl/BCLKeyStore.keystore&keyStoreType=JCEKS&password=bcl2601;
4. set mapred.crypto.secrets.protector.class=com.intel.hadoop.mapreduce.cryptocontext.provider.AgentSecretsProtector;
5. set mapred.agent.encryption.key.provider=org.apache.hadoop.io.crypto.KeyStoreKeyProvider;
6. set mapred.agent.encryption.key.provider.parameters=keyStoreUrl=file:////keys/clusterpublic.TrustStore&keyStoreType=JKS&password=123456;
7. set mapred.agent.encryption.keyname=HIVEKEYCLUSTERPUBLICASYM;
复制代码
创建一个指向 Pig 创建的加密数据文件的加密外部表:
1. create external table bcl_encrypted_pig_data(name STRING, age INT, country STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE LOCATION '/tmp/bcl/bcl_encrypted/' TBLPROPERTIES("hive.encrypt.enable"="true", "hive.encrypt.keyName"="BCLKey");
复制代码
一旦创建了表，任何授权的客户端(在/usr/lib/hadoop/keys 目录中有适当的密钥和证书文件)都可以在 Hive 提示符下使用select查询(在 Hive 语法中):
1. > select * from bcl_encrypted_pig_data;
复制代码

总之，为了实现用于 Hive 的 Intel 发行版，我设置了用于加密的密钥、密钥库和证书。然后，我从密钥库中提取证书，并将其导入信任库。留意，虽然我在示例中为用户JohnDoe创建了密钥对和证书，但是对于多用户环境，您需要为所有授权用户创建密钥对和证书。
对称密钥用于加密 HDFS(和 Hive)内的数据。MapReduce 使用公钥和证书，由于配置单元内的客户端通讯使用 MapReduce。这也是 Hive 的授权用户(被授权访问加密数据的用户)需要密钥对和证书的原因。
英特尔发行版使用的特别类
静态加密的预期功能需要实现特别的编解码器、类和逻辑。尽管有很多类和编码解码器可用，但它们不能在提供加密功能的公共逻辑支持下协调工作。英特尔在其发行版中添加了底层逻辑。
例如，org.apache.hadoop.io.crypto.KeyStoreKeyProvider是类org.apache.hadoop.io.crypto.KeyProvider.的实现，HBase 对应的 Apache 类是org.apache.hadoop.hbase.io.crypto.KeyStoreKeyProvider，它是org.apache.hadoop.hbase.io.crypto.KeyProvider的实现。此类用于剖析本地文件系统上受保护的密钥库文件中的密钥。英特尔使用这个类来管理存储在密钥库(和信任库)文件中的密钥。使用的其他 Hbase 类有:

org.apache.hadoop.hbase.io.crypto.Cipher
org.apache.hadoop.hbase.io.crypto.Decryptor
org.apache.hadoop.hbase.io.crypto.Encryptor

复制代码

这些类是如何使用的？例如，用 Java 术语来说，类org.apache.hadoop.hbase.io.crypto.Cipher的方法Encryption.decryptWithSubjectKey使用提供的对称密钥解密加密数据块；而方法Encryption.encryptWithSubjectKey使用提供的对称密钥加密数据块。总之，这个类使用对称密钥提供加密/解密。
英特尔定制类com.intel.hadoop.mapreduce.crypto.KeyStoreKeyProvider专为加密 MapReduce 处理惩罚而设计，其工作方式类似于 Apache Hadoop 加密类mapred.crypto.KeyStoreKeyProvider。它实用于 MapReduce 作业，能够处理惩罚证书和密钥。
这些类中的大多数都是由 Apache 基金会开发和使用的。唯一的区别是 Apache Foundation 的 Hadoop 发行版倒霉用这些类来提供静态加密的累积功能，其他商业发行版也倒霉用这些类。Project Rhino 正在尝试补救这种环境，由于甚至英特尔定制类和编解码器也可供他们使用，因此您可以等待很快 Project Rhino 将提供静态加密功能。
使用亚马逊网络服务来加密你的数据
正如你所看到的，安装和使用加密可能是一项艰巨的任务，但 Amazon 有意识地努力让它变得简单。AWS 提供了简单的选项，消除了安装、配置、管理和使用 Hadoop 加密所需的大部分工作和时间。有了 AWS，您可以选择不做、做部分或全部工作，这取决于您租用的配置服务。例如，如果您需要关注项目的其他部分(例如设计从 RDBMS(关系数据库管理系统)向 HDFS 或分析系统批量加载数据的 ETL)，您可以让 AWS 负责为您的数据全面实现静态加密。
决定数据加密和存储的模式
AWS 为加密使用提供了几种配置或型号。第一个模型，模型 A，让你控制加密方法以及 KMI(密钥管理基础设施 ) 。它为您提供了最大的灵活性和控制力，但是所有的工作都由您来做。模型 B 让您在 AWS 存储密钥时控制加密方法。；你仍旧可以管理你的钥匙。最严格的选择是模型 C，它不能控制 KMI 或加密方法，尽管它是最容易实现的，由于 AWS 为您完成了所有工作。要实现模型 C，您需要使用支持服务器端加密的 AWS 服务，如亚马逊 S3、亚马逊 EMR、亚马逊红移或亚马逊冰川。
为了演示，我将使用 Amazon 的模型 C 实现静态加密。根本步骤很容易理解，您可以使用您获得的理解来实现模型 A，为此您需要实现所有的任务(我已经提供了实现模型 A 的步骤，可以在 Apress 网站上下载)。我将使用亚马逊 EMR(或 Elastic MapReduce，它提供了一个易于使用的 Hadoop 实现，运行在*亚马逊弹性盘算云、*或 EC2 上)以及亚马逊 S3 进行存储。请留意:租用 EMR 服务的一个警告是，AWS 按“正常”小时收费，而不是实际小时，由于该筹划使用多个 AWS“设备”和至少两个 EC2 实例。
如果你不认识 AWS 的产物，EC2 是 AWS 的焦点。EC2 允许您租用一个虚拟服务器(或虚拟机),这是一个预配置的 Amazon 机器映像，带有所需的操纵系统和虚拟硬件资源选择(CPU、RAM、磁盘存储等)。).您可以引导(或启动)这个虚拟机或实例，并根据需要运行您自己的应用步伐。术语弹性指的是灵活的、按小时付费的模型，实用于你创建和使用的任何实例。图 8-5 显示 AWS 管理控制台。这就是你需要开始“租用”各种 AWS 组件的地方(假设你已经先创建了一个 AWS 账户):http://aws.amazon.com。

图 8-5 。AWS 管理控制台
回到使用模型 C 的实现，如果您在获取 EMR 集群时指定了服务器端加密(选择 AWS 控制台中的弹性 MapReduce 选项，如图 8-5 所示)，EMR 模型将为您的数据提供服务器端加密，并透明地管理加密方法和密钥。图 8-6 描绘了 AWS 用于服务器端加密的方法“信封加密”。根本步骤如下:

当您哀求加密数据时，AWS 服务会天生一个数据密钥。
AWS 使用数据密钥来加密您的数据。
使用 S3 存储来存储加密的数据密钥和加密的数据
AWS 使用密钥加密密钥(在这种环境下是 S3 独有的)来加密数据密钥，并将其与数据密钥和加密数据分开存储。

图 8-6 。AWS 的信封加密
对于数据检索息争密，这个过程是相反的。首先，使用密钥加密密钥对加密的数据密钥进行解密，然后用它来解密您的数据。
从图 8-6 可以看出，S3 存储服务支持服务器端加密。亚马逊 S3 服务器端加密使用 256 位 AES 对称密钥作为数据密钥和主(密钥加密)密钥。
使用所选模型加密数据文件
在这一节中，我将讨论基于 EMR 的 model C 的渐渐实现，此中 AWS 透明地管理您的加密方法和密钥。如前所述，您可以在 Apress 网站上找到实现模型 A 的步骤。
通过 AWS 创建 S3 存储
您需要首先创建存储，由于您的 EMR 集群将需要它。只需登录 AWS 管理控制台，选择服务 S3，并在(图 8-7 )中创建一个名为htestbucket的存储桶和一个文件夹test。

图 8-7 。创建 S3 存储桶和文件夹
为您创建的文件夹test指定服务器端加密(图 8-8 )。

图 8-8 。激活文件夹的服务器端加密
根据需要调整先前创建的存储桶htestbucket的权限(图 8-9 )。

图 8-9 。调整 S3 存储桶的权限
创建一个密钥对(bclkey)用于认证
将.pem文件保存到您的客户端。使用 PuTTYgen 创建一个.ppk(私有密钥文件)，可以使用 PuTTY 进行认证，以连接到 EMR 集群(主节点)。有关使用 PuTTY 和 PuTTYgen 的具体信息，请参见第四章和附录 b。图 8-10 显示了创建密钥对的 AWS 屏幕。要访问它，请在 AWS 管理控制台上选择 service EC2，然后选择 option Key Pairs。

图 8-10 。在 AWS 中创建密钥对
创建访问密钥 ID 和机密访问密钥
这些密钥用作加密的凭证，并与用户相关联。如果您没有创建任何用户，并且正在使用 AWS 的root帐户，那么您需要为root创建这些密钥。从身份和访问管理(IAM)管理控制台 ( 图 8-11 )，选择 Dashboard，然后点击第一个选项，删除您的根访问密钥。(如果你没有为root创建这些键，你不会看到这个警告)。要访问 IAM 控制台，请在 AWS 管理控制台上选择服务“身份&访问管理”。

图 8-11 。AWS 的 IAM 控制台
点击管理安全凭证按钮，忽略警告“继续安全凭证”(图 8-12 )。

图 8-12 。安全凭证的创建
你的 AWS root账户就像一个 UNIX root账户，AWS 不发起使用它。相反，根据需要创建具有脚色、权限和访问密钥的用户帐户。如果这样做，您可以更容易地自定义权限，而不会影响安全性。关于使用root账户，另一件要记着的事情是，如果你丢失了访问密钥 ID 或机密访问密钥，你将无法找回它们！因此，我创建了一个用户Bhushan，用于我的 EMR 集群(图 8-13 )。我使用身份和访问管理(IAM)管理控制台中的“用户”选项和“创建新用户”按钮(图 8-11 )来创建这个新用户。

图 8-13 。创建用于 EMR 集群的用户
要为用户设置密钥，请再次从 IAM 管理控制台开始，选择“用户”选项，然后选择特定用户(或创建用户)。接下来，打开安全凭证区域，为所选用户创建访问密钥 ID 和机密访问密钥(图 8-13 )。

留意当您创建访问密钥 ID 和机密访问密钥时，您可以下载它们并将其保存在安全的地方作为备份。接纳这种防备步伐肯定比在丢失钥匙的环境下重新创建一套钥匙容易。
创建 AWS EMR 集群，指定服务器端加密
完成准备步骤后，您就可以创建 EMR 集群了。登录到 AWS 管理控制台，选择 Elastic MapReduce 服务，然后单击 Create Cluster 按钮。选择“服务器端加密”和“同等视图”配置选项，保存其他选项的默认值(图 8-14 )。

图 8-14 。创建 EMR 集群
在硬件配置部分(图 8-15 ，哀求一个主 EC2 实例运行 JobTracker 和 NameNode，哀求一个核心 EC2 实例运行 TaskTrackers 和 DataNodes。(这只是为了测试；在实际世界中，根据您所需的处理惩罚本事，您需要获得多个主实例或核心实例。)在 Security Access 部分，指定前面创建的密钥对之一(bclkey)，而在 IAM Roles 部分，为 EMR 脚色设置EMR_DefaultRole和EMR_EC2_DefaultRole。确保这些脚色有权访问 S3 存储(存储桶和文件夹)以及您需要使用的任何其他资源。

图 8-15 。EMR 集群的硬件配置
检查完所有要求的配置选项后，单击屏幕底部的“创建集群”按钮，根据您的要求创建一个 EMR 集群。
几分钟后，您将收到类似于图 8-16 的集群创建确认。

图 8-16 。EMR 集群已创建
测试加密
最后一步，测试 EMR 和 S3 之间的“静态”加密是否正常工作。根据 AWS 和 EMR 文档，任何将数据从 HDFS 传输到 S3 存储(或从 S3 传输到 HDFS)的 MapReduce 作业都应该对写入永久存储的数据进行加密。
您可以使用 Amazon utility S3DistCp 来验证这一点，该工具旨在亚马逊 S3 和 HDFS 之间移动大量数据(来自 EMR 集群)。S3DistCp 支持哀求亚马逊 S3 在将 EMR 数据写入您管理的亚马逊 S3 桶时使用服务器端加密。然而，在使用它之前，您需要将以下配置添加到您的core-site.xml(我已经清空了我的访问键):

<property>
<name>fs.s3.awsSecretAccessKey</name>
<value>xxxxxxxxxxxxxxxxxxxx</value>
</property>
<property>
<name>fs.s3.awsAccessKeyId</name>
<value>yyyyyyyyyyyyyyyyyyyy</value>
</property>
<property>
<name>fs.s3n.awsSecretAccessKey</name>
<value>xxxxxxxxxxxxxxxxxxxx</value>
</property>
<property>
<name>fs.s3n.awsAccessKeyId</name>
<value>yyyyyyyyyyyyyyyyyyyy</value>
</property>

复制代码

记着用值替换您自己的访问密钥 ID 和机密访问密钥。不需要重启任何 Hadoop 保卫进程。
接下来，确保以下 jar 存在于您的/home/hadoop/lib(my Hadoop 安装目录下的/lib)中。如果没有，找到并复制到以下位置:

/home/hadoop/lib/emr-s3distcp-1.0.jar
/home/hadoop/lib/gson-2.1.jar
/home/hadoop/lib/emr-s3distcp-1.0.jar
/home/hadoop/lib/EmrMetrics-1.0.jar
/home/hadoop/lib/httpcore-4.1.jar
/home/hadoop/lib/httpclient-4.1.1.jar

复制代码

现在，您已经准备好运行 S3DistCp 实用步伐，并将文件test1从 HDFS 复制到文件夹test中，用于 S3 桶htestbucket:

> hadoop jar /home/hadoop/lib/emr-s3distcp-1.0.jar -libjars /home/hadoop/lib/gson-2.1.jar,/home/hadoop/lib/emr-s3distcp-1.0.jar,/home/hadoop/lib/EmrMetrics-1.0.jar,/home/hadoop/lib/httpcore-4.1.jar,/home/hadoop/lib/httpclient-4.1.1.jar --src /tmp/test1 --dest s3://htestbucket/test/ --disableMultipartUpload --s3ServerSideEncryption

复制代码

我的示例在几秒钟内产生了以下相应:

14/10/10 03:27:47 INFO s3distcp.S3DistCp: Running with args: -libjars /home/hadoop/lib/gson-2.1.jar,/home/hadoop/lib/emr-s3distcp-1.0.jar,/home/hadoop/lib/EmrMetrics-1.0.jar,/home/hadoop/lib/httpcore-4.1.jar,/home/hadoop/lib/httpclient-4.1.1.jar --src /tmp/test1 --dest s3://htestbucket/test/ --disableMultipartUpload --s3ServerSideEncryption
....
....
14/10/10 03:27:51 INFO client.RMProxy: Connecting to ResourceManager at
14/10/10 03:27:54 INFO mapreduce.Job: The url to track the job: http://10.232.45.82:9046/proxy/application_1412889867251_0001/
14/10/10 03:27:54 INFO mapreduce.Job: Running job: job_1412889867251_0001
14/10/10 03:28:12 INFO mapreduce.Job: map 0% reduce 0%
....
....
14/10/10 03:30:17 INFO mapreduce.Job: map 100% reduce 100%
14/10/10 03:30:18 INFO mapreduce.Job: Job job_1412889867251_0001 completed successfully

复制代码

显然，MapReduce 作业成功地将文件复制到了 S3 存储。现在，您需要验证文件是否加密存储在 S3。为此，使用 S3 管理控制台并检查存储桶htestbucket中文件夹test内文件test1的属性(图 8-17 )。

图 8-17 。验证 MapReduce 作业的服务器端加密
如您所见，属性服务器端加密被设置为AES-256，这意味着来自 EMR 集群的 MapReduce 作业成功地将数据复制到具有服务器端加密的 S3 存储中！
您可以尝试调用 MapReduce 作业的其他方式(例如，Hive 查询或 Pig 脚本),并写入 S3 存储以验证存储的数据确实是加密的。您还可以使用 S3DistCp 将数据从您自己的本地 Hadoop 集群传输到亚马逊 S3 存储。只需确保在本地集群的所有节点上复制了core-site.xml中的 AWS 凭证，并且之火线出的六个.jar文件位于 Hadoop 安装目录的/lib子目录中。
如果您想比较使用 AWS EMR 的加密实现与更实用的模型 A 的实现(在模型 A 中，您管理加密和密钥，别的您需要在 EC2 实例上安装特定的软件来实现加密)，请记着您可以从 Apress 网站下载并查察这些步骤。
现在，您已经看到了使用 Hadoop 提供静态加密的两种选择(使用英特尔的 Hadoop 发行版和使用 AWS)。如果你仔细回顾，你会发现它们在实现加密方面确实有共性。图 8-18 总结了通用步骤。

图 8-18 。DataNode 使用对称密钥(来自客户端)来解密数据块，如果成功，则检索数据块。各个数据节点检索并传回后续数据块
摘要
Hadoop 的静态加密仍旧是一项正在进行的工作，特别是对于开源世界。大概当 Hadoop 在企业界得到更广泛的应用时，我们的选择会有所改善。现在，你必须告急于付费的第三方解决方案。这些第三方解决方案的缺点是，即使他们声称可以使用特定的发行版，他们的声明也很难得到验证。此外，不清晰他们给你的 Hadoop 安装添加了多少定制代码，以及你实际上为加密/解密获得了什么样的性能。最后，这些解决方案不是由训练有素的暗码学家或暗码分析师开发或测试的。因此，没有可靠性或包管它们是(并将是)“牢不可破的”。
英特尔以大量宣传和炒作进入 Hadoop 和静态加密领域，但很快退出并投资了 Cloudera。现在，Rhino 项目的将来以及该代码与 Cloudera 发行版的可能集成似乎还不太清朗。有一些零散的开源应用步伐，但是还没有一个结实的、集成的解决方案可以满足一个严厉的 Hadoop 实践者的实际加密需求。
现在，让我们希望这个 Hadoop 领域在用户中产生足够的兴趣，以便在将来使用开源解决方案实现加密的更多选择。
无论将来如何，就目前而言，这是最后一章。我真诚地希望这本书能够促进您对 Hadoop 安全选项的理解，并资助您确保环境的安全！
九、附录 A：Pageant 使用和实现

Pageant 是一个 SSH 认证代理，它可以与 PuTTY 或 WinSCP 一起使用，用于在内存中保存您的解密密钥，这样您就不需要在每次使用密钥对向服务器进行认证时输入暗码来解密您的密钥(第四章具体讨论了基于密钥的认证)。如果您使用多个密钥对来认证多个服务器，Pageant 甚至更有用。您可以使用 Pageant 将所有解密的密钥保存在内存中，这意味着您只需在启动 Windows 会话时输入一次相应的暗码。当您注销您的 Windows 会话时，Pageant 会退出，而不会将解密的密钥保存在磁盘上，这就是您需要在启动您的 Windows 会话时再次输入暗码短语的原因。
由于 Pageant 是 PuTTY 安装包的一部分，所以可以从同一个 URL ( http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)下载。当你运行可实验文件 Pageant.exe 开始 Pageant，一个图标，看起来像一个戴着帽子的电脑会出现在你的系统托盘。右键单击图标以调用 Pageant 菜单，然后选择所需的菜单选项:新建会话、保存的会话、查察密钥、添加密钥、关于或退出。但是，如果在添加键之前选择查察键，您将只会看到一个空的列表框。
使用 Pageant
要使用 Pageant，首先需要天生一个密钥对，并将公钥复制到需要连接的服务器上。例如，我天生了一个密钥对，并将密钥保存为keytest.ppk(私钥)和keytest.pub(公钥)。然后，我使用一个暗码对私钥进行了加密。由于我想连接到主机pract_hdp_sec，所以我将我的公钥粘贴到。ssh 目录(正如在第四章中讨论的)。接下来，我将把解密的私钥存储在 Pageant 中。图 A-1 阐明白选择和添加密钥。

图 A-1 。为 Pageant 比赛添加关键点
当您选择一个密钥时(此处为testkey.ppk，系统会提示您输入暗码短语(图 A-2 )。

图 A-2 。使用 Pageant 存储密钥的暗码短语
输入正确的暗码短语后，Pageant 解密您的私钥，并将其保存在内存中，直到您注销 Windows 会话。您可以看到您的密钥在 Pageant 中列出，如图 A-3 所示。

图 A-3 。列出 Pageant 比赛中存储的密钥
现在，您只需要在 PuTTY ( 图 A-4 )中指定您的私钥作为授权方式。

图 A-4 。在 PuTTY 中指定基于密钥的认证
下次您想连接到服务器pract_hdp_sec时，只需打开一个 PuTTY 会话，它会提示您输入登录名。一旦你输入登录名，PuTTY 会直接将你连接到服务器，正如你在图 A-5 中看到的。

图 A-5 。使用来自 Pageant 比赛的解密密钥实验基于密钥的认证
PuTTY 识别出 Pageant 正在运行，自动检索解密的密钥，并使用它进行认证。您可以根据需要为同一台服务器打开任意多个 PuTTY 会话，而无需再次键入暗码。
此外，Pageant 可以在启动时自动加载多个私钥。例如，假设您每天需要连接十台服务器。每天手动将密钥添加到 Pageant 比赛中既困难又容易堕落。要自动加载多个键，请使用类似下面的 Pageant 下令行；固然，目录路径取决于您的Pageant.exe或您的私钥文件(。ppk 文件)位于:

C:\Users\Administrator\Desktop>pageant.exe c:\bhushan\keytest.ppk c:\bhushan\bhushan.ppk

复制代码

您可以添加多个由空格分隔的键。如果密钥是加密的，Pageant 会在启动时提示输入暗码。如果 Pageant 已经在运行，并且您实验了这个下令，它会将密钥加载到现有的 Pageant 中。
你也可以创建一个快捷方式，并在那边指定下令行，如图图 A-6 所示。

图 A-6 。为多个键指定起始(默认)目录
如果您只有一个私钥，请在目标字段中指定其完整路径:

C:\Users\Administrator\Desktop>pageant.exe c:\bhushan\keytest.ppk

复制代码

如果您有多个键并且路径很长，您可以只指定一个起始目录，而不是为每个键指定路径。例如，要为我之前的多键示例指定一个起点，在目标字段中输入C:\Users\Administrator\Desktop>pageant.exe keytest.ppk，在起点字段中输入C:\Bhushan。
在 Pageant 初始化并加载下令行上指定的键之后，您可以下令 Pageant 启动另一个步伐。此步伐(例如 WinSCP 或 PuTTY 等。)然后可以使用 Pageant 加载的密钥。语法如下:

C:\Users\Administrator\Desktop>pageant.exe c:\bhushan\keytest.ppk
-c C:\PuTTY\putty.exe

复制代码

安全思量
在 Pageant 中保存解密的私钥比在本地磁盘驱动器上存储密钥文件更安全，但是仍旧存在一些已知的安全题目。
例如，Windows 不以任何方式保护“交换”数据(写入系统交换文件的内存数据)。因此，如果您长时间使用 Pageant，解密的密钥数据可能会被交换并写入磁盘。获得您硬盘访问权限的恶意攻击者也可以获得您的密钥。固然，这比将未加密的文件存储在本地磁盘驱动器上要安全得多，但仍旧存在漏洞。
Windows 只有防止可实验代码写入另一个可实验步伐的内存空间的安全步伐；但是仍旧提供对它的读访问。换句话说，步伐可以访问相互的内存空间，这是一种资助调试的方式。不幸的是，恶意步伐可以使用这一特性，并可以访问 Pageant 的内存来提取解密的密钥，并将它们用于非法目的。
然而，通过确保您的网络基础设施是安全的并且安装了防火墙，这些风险可以很容易地被减轻。
十、附录 B：基于 Linux 的客户端的 PuTTY 和 SSH 实现

在第四章的“使用 PuTTY 进行基于密钥的认证”一节中，您回顾了 PuTTY 如何有用地用于基于 Windows 的客户端的基于密钥的认证。对于基于 Linux 的客户端，基于密钥的认证怎么样？答案又是油灰。
您可以从各种来源下载基于 Linux 的 PuTTY 版本。对于 CentOS 6.2 的最新 PuTTY 版本(0.63)，我使用了 rpm (Red Hat Package Manager，一种用于 Linux 域软件分发的包管理系统)；文件是putty-0.63-1.el6.rf.x86_64.rpm。您可以从各种来源下载 rpm 你只需要搜索你的操纵系统。下载文件后，安装 rpm:

rpm -Uvh putty-0.63-1.el6.rf.x86_64.rpm

复制代码

要在 PuTTY 的 Linux 版本中天生一对私有和公共密钥，您需要使用一个名为 PuTTYgen 的下令行实用步伐，它会在您通过 rpm 安装 PuTTY 时自动安装。要天生密钥对，请使用以下下令:

puttygen -t rsa -C "my key pair" -o bcl.ppk

复制代码

然后，PuTTYgen 会提示您输入一个暗码短语。请记下来，由于每次使用密钥对连接到主机时，您都需要指定雷同的暗码。
您可以将密钥保存在您的主目录中(容易记着位置)，然后使用以下下令将公钥导出到authorized_keys文件:

puttygen -L bcl.ppk >> $HOME/.ssh/authorized_keys

复制代码

接下来，将authorized_keys文件复制到需要连接的主机上(使用 PuTTY)。留意，如果您的主机在$HOME/.ssh目录中已经有一个authorized_keys文件，那么使用不同的名称复制您新创建的文件，并将其内容附加到现有的authorized_keys文件中。
接下来，通过在下令提示符下键入 putty 来调用 PuTTY。该界面看起来与基于 Windows 的界面完全雷同(图 B-1 )。

图 B-1 。具有基于密钥的认证的 Linux PuTTY
要连接到服务器，请单击选项 SSH 以打开下拉列表，然后单击该列表下的选项 Auth(授权)。在 PuTTY 界面的右侧，单击 Browse 并选择您之前保存的私钥文件(在本例中为/root/bcl.ppk)。单击“打开”打开一个新会话。
就是这样！现在，您已经准备好使用 PuTTY 进行基于密钥的认证了！图 B-2 显示了登录提示和暗码提示。

图 B-2 。使用带有暗码短语的 Linux PuTTY
使用 SSH 进行长途访问
您还可以使用 SSH 长途连接到主机。如果您想使用一个密钥对通过 SSH 进行认证，首先需要使用一个名为 ssh-keygen 的实用步伐来天生密钥。默认环境下，密钥以文件id_rsa(私钥)和id_rsa.pub(公钥)的形式保存在$HOME/.ssh目录中。图 B-3 显示了在默认位置天生的不带暗码短语的密钥对(您可以指定一个暗码短语以增长安全性)。

图 B-3 。使用 ssh-keygen 为长途访问天生密钥对
可以将公钥复制到适当的主机，并附加到$HOME/.ssh目录中现有的authorized_keys文件中。要使用私钥文件连接到主机，请使用以下语法:

ssh -i ~/.ssh/id_rsa root@Master

复制代码

这里，root是用户，Master是您试图连接的服务器。
如果您有多个主机，并且您想要组织连接到它们的过程，您可以在目录$HOME/.ssh中的一个名为config的文件中创建主机条目。使用以下格式创建条目:

Host Master
User root
HostName Master
IdentityFile ~/.ssh/id_rsa

复制代码

然后，您可以简单地连接为:

ssh -f -N Master

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

		自动登录	找回密码
密码			立即注册

Hadoop 安全实践指南（二）

本帖子中包含更多资源

0 个回复

快速回复

楼主热帖

标签云