《Hadoop安全》试读：1.1　安全概览

早在2003 年，谷歌就发表了一篇论文（http://research.google.com/archive/gfs.html），阐述了基于服务器集群的、面向海量数据存储的可扩展系统架构，该架构称为谷歌文件系统（GFS）。一年后，谷歌发表了另一篇论文（http://research.google.com/archive/mapreduce.html），阐述了一个名为MapReduce 的编程模型。该模型利用GFS 并行处理数据，实现了处理程序在数据存储处的本地化运行。几乎同时，Doug Cutting 与其他合作者也在搭建一个开源的网络爬虫，如今这个工具被称为Apache Nutch（http://nutch.apache.org）。Nutch的开发者们意识到，MapReduce 编程模型和GFS 是很完美的分布式网络爬虫构建模块，于是他们着手实现基于这两个项目的新爬虫版本。这些组件后来从Nutch 脱离，并组成了Apache Hadoop 项目。围绕Hadoop 可扩展架构形成的生态系统1 允许用户存储和处理所有重要的事务数据，提供了解决问题的另一种方法。 当所有这些崭新且令人激动的处理、存储数据的方法在Hadoop 生态系统中被广泛使用时，使用单一的集中式集群管理这些PB 级数据明显是有风险的。成百上千的服务器在同一个通用应用栈中互连，给如何保护这些重要资源提出了很多难题。其他书籍侧重于介绍如何编写MapReduce 代码、如何设计最优的导入框架，以及如何在Hadoop 生态系统上搭建复杂的低延迟处理系统，而本书专注于讨论在Hadoop 的安全架构下，如何利用众多安全特性保护上述所有事务的安全性。 注1： Apache Hadoop 本身由4 个子项目组成：HDFS、YARN、MapReduce 和Hadoop Common。然而，Hadoop 生态系统、Hadoop 和其他在Hadoop 基础上创建或集成的相关项目通常均被简称为Hadoop。我们此处使用Hadoop 项目和Hadoop 生态系统以示区分。 1.1　安全概览 开始讨论Hadoop 专有内容之前，有必要先了解一些信息安全相关的关键理论和术语。信息安全理论 的核心是CIA 模型，即机密性（confidentiality）、完整性（integrity）和可用性（availability）。该模型的这3 个组件是高层次概念，能够广泛应用于信息系统、计算平台以及（更适用于本书的）Hadoop。我们还将进一步了解验证、授权和审计这3 个安全计算领域的要素，并将在全书深入探讨。 虽然CIA 模型能够帮助建立一些信息安全原则，但需要指出的是，该模型并不是一个需要严格遵循的规范。Hadoop 平台的安全特性既有可能涉及多个CIA 模型组件，也有可能连一个CIA 组件也覆盖不到。 1.1.1　机密性 机密性这个安全原则强调，信息只应该被期望的接收者看到。例如，假设Alice 通过邮件向Bob 发送了一封信，那么只有当Bob 是唯一能够阅读这封信的人时，才能认为这封信是机密的。尽管这看起来很简单，不过要保证机密性，还需要几个重要的安全概念。比如，如何使Alice 知道她发送的信件被Bob 本人读了？如果Bob 本人读了信件，他如何确认自己所读的信是Alice 本人发的？为了使Alice 和Bob 都参与机密信息的传递，他们需要持有能够将自己和其他人区别开来的唯一身份标识。此外，Alice 和Bob 需要通过一个身份验证的过程证明自己的身份。身份和验证是Hadoop 安全的核心组件，这部分将在第5 章详细介绍。 机密性的另一个重要概念是加密。加密是这样一种机制，它将数学算法应用于信息片段，使加密后的输出内容对于非预期接收者不可读。只有期望的接收者能对加密消息进行解密，从而得到原始信息。数据加密有两种方式：静态加密和动态加密。静态加密是指，数据在非访问状态下就处于加密状态。例如，存储在硬盘上的加密文件就是静态加密的一个例子。动态加密也称在线加密，即在数据通过网络从一个地方发送到另外一个地方时进行加密。两种加密方式可以各自独立使用，也可以混合使用。第9 章将介绍Hadoop 的静态加密，而动态加密会在第10 章和第11 章进行介绍。 1.1.2　完整性 完整性是信息安全的重要组成部分。之前的例子中，当Alice 发送信件给Bob 时，如果Charles 在Alice 和Bob 毫不知情的情况下，于传输过程中截获了信件，并对其内容进行了修改，这会怎样呢？ Bob 如何保证他接收到的信件和Alice 发送的是完全一样的呢？这就是数据完整性的概念。数据完整性是信息安全的关键要素，尤其在包含高度敏感数据的行业中。设想一下，如果银行没有机制能够验证客户账户余额完整性，会发生什么？医院没有机制能够验证病人病历完整性，又会发生什么？政府没有验证情报秘密完整性的机制，可能会发生什么？即使机密性得到保证，但完整性得不到保证的数据也有被损坏的风险。完整性将在第9 章和第10 章讲解。 1.1.3　可用性 可用性与前两个要素不属于同一类规范。机密性和完整性同是众所周知的安全概念，而可用性更多 涉及的是操作准备。例如，如果Alice 试图向Bob 发信，但邮局关门了，那么信件就无法被送达。这样对于Bob 来说，信件就是不可用的。数据或服务的可用性能够被普通的行为影响，如计划内的停工升级或应用安全补丁，同时也可能被诸如分布式拒绝服务攻击（DDoS）等安全事件影响。《Hadoop 技术详解》和《Hadoop 权威指南》介绍了如何对高可用性进行配置，本书将从安全视角介绍这些概念，参见第3 章和第10 章。 1.1.4　验证、授权和审计 验证、授权和审计（通常缩写为AAA）指计算机安全领域的一个架构模式。在该模式中，使用服务的用户先要证明自己的身份，然后根据规则被授予权限，同时其操作被记录下来留待审计。与AAA 紧密相联的一个概念是身份。身份是指系统如何将不同的实体、用户和服务区分开来，典型的代表是一个任意字符串，例如用户名或者诸如用户ID（UID）的唯一号码。 深入了解Hadoop 如何支持身份、认证、授权和审计之前，先考虑在一个很简单的情况下运用这些概念：在单台Linux 服务器上使用sudo 命令。我们来看看两个不同用户Alice 和Bob 进行的终端会话。在这台服务器上，Alice 的用户名是alice，Bob 的用户名是bob。如示例1-1 所示，Alice 先登录。 示例1-1　验证和授权 $ ssh alice@hadoop01 alice@hadoop01's password: Last login: Wed Feb 12 15:26:55 2014 from 172.18.12.166 [alice@hadoop01 ~]$ sudo service sshd status openssh-daemon (pid 1260) is running... [alice@hadoop01 ~]$ 示例1-1 中，Alice 通过SSH 登录，并且立即被提示输入她的口令。她的用户名/ 口令对被用于在/etc/passwd 密码文件中验证其登录。完成这一步后，Alice 便被成功验证了用户名alice 的身份。Alice 的下一步是使用sudo 命令获得sshd 服务，这需要超级用户的权限。这个命令执行成功，说明Alice 被授权可以执行该命令。对于sudo 命令，控制哪些用户能够被授予超级用户权限的规则存储在/etc/sudoers 文件中，如示例1-2 所示。 示例1-2　/etc/sudoers [root@hadoop01 ~]# cat /etc/sudoers root ALL = (ALL) ALL %wheel ALL = (ALL) NOPASSWD:ALL [root@hadoop01 ~]# 示例1-2 中，用户root 被授予使用sudo 执行任何命令的权限，用户组wheel 被授予可无密码使用sudo 执行任何命令的权限。这个例子中，系统的验证依赖于登录，而非一次新的验证要求。最后一个问题是，系统怎么知道Alice 是wheel 用户组的一员呢？在UNIX 和Linux 系统中，这通常由文件/etc/group 控制。 现在，我们知道控制Alice 的身份标识的有两个文件：/etc/passwd（示例1-4）和/etc/group（示例1-3）。/etc/passwd 文件为她的用户名分配一个特有的UID 和主目录，/etc/group 文件更 进一步定义了系统的组标识以及用户和组的从属关系。这些身份标识信息文件会在执行sudo 命令时用到，同时用到的还有/etc/sudoers 文件中定义的权限规则，它们用于验证Alice 是否有权限执行请求的命令。 示例1-3　/etc/group [root@hadoop01 ~]# grep wheel /etc/group wheel:x:10:alice [root@hadoop01 ~]# 示例1-4　/etc/passwd [root@hadoop01 ~]# grepalice /etc/passwd alice:x:1000:1000:Alice:/home/alice:/bin/bash [root@hadoop01 ~]# 现在看看示例1-5 中Bob 的会话。 示例1-5　授权失败 $ ssh bob@hadoop01 bob@hadoop01's password: Last login: Wed Feb 12 15:30:54 2014 from 172.18.12.166 [bob@hadoop01 ~]$ sudo service sshd status We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for bob: bob is not in the sudoers file. This incident will be reported. [bob@hadoop01 ~]$ 本示例中，Bob 能够使用与Alice 类似的方法进行身份验证，但当他试图使用sudo 命令时，遇见了截然不同的状况。首先，Bob 执行命令时被系统再次要求输入口令；成功提交口令后，被系统拒绝以超级用户的权限执行该service 命令。这是由于与Alice 不同，Bob不是wheel 组的成员，因而不被授权执行sudo 命令。 了解了身份、验证和授权，我们再来关注审计。对于用户与诸如SSH 和sudo 等安全服务的互动行为，Linux 会创建一个名为/var/log/secure 的日志文件。该文件能够记录一个账户的某些行为，无论这些行为成功还是失败。若我们在Alice 和Bob 各自完成上述操作后查看该日志，能够看到示例1-6 所示的输出（按照方便阅读的形式组织）。 示例1-6　/var/log/secure [root@hadoop01 ~]# tail -n 6 /var/log/secure Feb 12 20:32:04 ip-172-25-3-79 sshd[3774]: Accepted password for alice from 172.18.12.166 port 65012 ssh2 Feb 12 20:32:04 ip-172-25-3-79 sshd[3774]: pam_unix(sshd:session): session opened for user alice by (uid=0) Feb 12 20:32:33 ip-172-25-3-79 sudo: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/sbin/service sshd status Feb 12 20:33:15 ip-172-25-3-79 sshd[3799]: Accepted password for bob from 172.18.12.166 port 65017 ssh2 Feb 12 20:33:15 ip-172-25-3-79 sshd[3799]: pam_unix(sshd:session): session opened for user bob by (uid=0) Feb 12 20:33:39 ip-172-25-3-79 sudo: bob : user NOT in sudoers; TTY=pts/2 ; PWD=/home/bob ; USER=root ; COMMAND=/sbin/service sshd status [root@hadoop01 ~]# 对于Alice 和Bob，他们通过SSH 成功登录的事实均被记录下来，包括他们对sudo 的使用记录。Alice 的例子中，系统记录了她成功使用sudo 以root 权限执行了/sbin/servicesshd status 命令。而Bob 的例子中，系统则记录了他试图以root 权限执行/sbin/servicesshd status 命令，但由于他不在/etc/sudoer 用户组里，以致被系统拒绝执行。 该例子展示了身份、验证、授权和审计的概念如何运用在相对简单的单台Linux 服务器上，并维持系统安全。这些概念将在第二部分的Hadoop 相关章节中予以详细阐述。