本文固定链接：https://www.askmac.cn/archives/hdfs-transparent-encryption.html

原文地址：http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/TransparentEncryption.html

 

1 简介

 

HDFS 实现透明的，端到端的加密。一旦配置，从指定的HDFS读取和写入数据都会透明的进行加密和解密，不需要用户应用程序代码的变更。这个加密是端到端的，也就意味着数据只能被客户端加密和解密。HDFS从来不会存储或访问未加密的数据或者为加密的加密key。这满足了2个典型的加密要求：静态加密（意思是数据在永久存储上，例如磁盘）以及在传输加密（例如当数据在网络中传输时）。

 

 

2 背景

 

加密可以在传统的数据管理软件/硬件栈的不同层级中完成。选择一个给定的层进行加密，有不同的优缺点。(www.askmac.cn)

1.应用程序层加密。这是最安全和最灵活的方法。该应用程序最终控制什么被加密，并且可以准确的反映用户的需求。但是，写应用程序做这个比较困难。对于现有的那些不支持加密的应用程序这也不是个选项。

2.数据库层面加密。在性质方面和应用程序层很相似。大多数数据库供应商提供某种形式的加密。然而，可能会有性能问题。例如，索引是不能被加密的。

3.文件系统层面加密。这个选项提供了很高的性能，对应用程序透明，并且通常很容易部署。但是其无法模拟一些应用程序的策略。例如，多租户的应用程序可能想在基于最终用户的基础上进行加密。数据库可能想对存储在单一文件中的每个字段进行不同的加密设置。

4.磁盘级别加密。很容易实施 并且有很高的性能。但是很死板。只能真正保护物理盗窃。

HDFS层级加密适合在数据库级别和文件系统级别之间的栈进行加密。其有很多积极的效果。HDFS加密能够提供很好的性能，并且现有的hadoop应用程序可以在加密数据上透明的运行。当其进行策略决定时，HDFS也比传统的文件系统有更多的上下文。(www.askmac.cn)

HDFS级别加密也可以防止在文件系统和其之下的攻击（OS-level攻击）。操作系统和磁盘只用加密字节交互，因为数据已经被HDFS加密。

 

 

3 使用场景

 

数据加密被不同的政府，金融和管理体系所需要。例如，医疗产业有HIPAA法规，卡支付行业的PCI DSS法规和美国FISMA规定。具有透明加密内置到HDFS使得组织遵守这些法规更容易。

加密也可以在应用层面进行，但是是整合到HDFS，现有的应用程序可以操作加密数据不需要任何变更。这种集成架构意味着更强的加密文件语义和更好的于其他HDFS功能协调。(www.askmac.cn)

 

 

4.结构

4.1 概述

 

透明加密，我们在HDFS中引入一个新的抽象概念：加密区。一个加密区是一个特殊的目录，其中内容将在写的时候被透明的加密，读的时候被透明的解密。当每个加密空间被创建的时候会被分配一个单独的加密空间key。每个加密空间中的文件都有其唯一的数据加密key（DEK）。DEKs永远不会被DHFS直接处理。想法，HDFS只处理被加密数据的加密key（EDKEK）。客户端解密一个EDEK，然后使用DEK来读取和写入数据，HDFS datanodes仅仅看到的是一个加密的字节流。

 

一个新的集群服务被用来管理加密keys：hadoop key 管理服务（KMS）。在HDFS加密情况中，KMS执行3个基本工作：

1.提供访问到存储的加密空间key

2.生成新的被加密数据的加密key到namenode上存储(www.askmac.cn)

3.解密被HDFS客户端使用的被加密数据的加密key

 

KMS将会在下面进行更详细的描述

 

4.2 在加密空间中访问数据

当在加密空间中创建一个新文件时，NameNode询问 KMS来生成新的EDEK其被加密空间的key加密。这个EDEK作为文件的元数据一部分持久的存储在namenode上。

当在一个加密空间读取一个文件时，namenode为客户端提供文件的EDEK和用来加密EDEK的加密空间key版本。然后客户端会要求KMS解密EDEK，其会调用检查客户端访问加密空间key版本的权限。假设均成功，客户端会使用EDK来解密文件的内容。

以上的步骤在读取和写入路径自动地发生，通过与DFS客户端，NameNode和KMS交互。

访问被加密的文件数据和元数据被普通HDFS文件系统权限控制。这意味着，如果HDFS是抵抗力弱的（例如，通过获得未授权的HDFS超级用户），恶意用户只能访问密文和加密 key。但是，由于访问加密空间keys 是由在KMS上单独配置的权限控制和key 存储的，这并不构成安全威胁。(www.askmac.cn)

 

4.3 KMS, KeyProvider, EDEKs

 

KMS是一个代理，是HDFS后台进程和客户端支持key存储的接口。支持key存储和KMS实施的hadoop KeyProvider的API，查看KMS文档获取更多的信息。

在KeyProvider API中，每个加密key有一个唯一的key 名称。因为key可以被循环，一个key可以有多个key版本，每个key版本有其自己的key material（在加密和解密过程中实际使用的秘密字节）。一个加密key可以被其key名称捕获，返回最新的key版本，或者通过指定key版本。

KMS实现额外的功能，可以创建和解密EEKs。创建和解密KEES完全发生在KMS中。重要的是，客户端需要创建或解密一个EEK，从不处理EEK的加密key。为了创建一个新的EEK，这个KMS生成一个新的随机key，使用指定的key加密它，并且返回EEK给客户端。为了解密一个EEK，KMS检查用户访问加密key，使用其来解密EEL，并范文被解密的加密key。

在HDFS加密情况中，EEKs是加密数据的加密key（EDEKS），DEK用其来加密和解密文件数据。通常情况下，key存储只被最终用户控制用来解密DEK。这就意味着EDEKS可以被HDFS安全的存储和出来，因为HDFS用户将无法访问未加密的加密key。(www.askmac.cn)

 

5.配置

一个必要的前提是一个KMS的实例，以及一个支持KMS key存储。更多的信息参考KMS文档。

一旦一个KMS被设置，并且NameNode和HDFS客户端被正确的配置，一个管理员可以使用hadoop key 和hdfs crypto命令行工具来创建加密key和设置新的加密空间。已经存在的数据可以通过使用工具例如distcp，拷贝其到新的加密空间来加密。

 

 

5.1 配置集群KeyProvider

dfs.encryption.key.provider.uri

当读取和写入加密空间时，使用KeyProvider 和加密key进行交互。(www.askmac.cn)

 

5.2 设置一个加密算法和编码器

 

hadoop.security.crypto.codec.classes.EXAMPLECIPHERSUITE

对于一个给定的密码前缀编码，对于一个给定的密码编解码器包含一个以逗号分隔的列表实现的类（例如：EXAMPLECIPHERSUITE）。第一个如果可用的话将实现，其他的回退。

 

hadoop.security.crypto.codec.classes.aes.ctr.nopadding

默认值：org.apache.hadoop.crypto.OpensslAesCtrCryptoCodec,org.apache.hadoop.crypto.JceAesCtrCryptoCodec

AES/CTR/NoPadding逗号分隔的编码解码列表。第一个如果可用的话将实现，其他的回退。(www.askmac.cn)

 

hadoop.security.crypto.cipher.suite

默认值：AES/CTR/NoPadding

对于编码解码的套件

 

hadoop.security.crypto.jce.provider

默认：None

在CryptoCodec中用的JCE提供者名称

 

hadoop.security.crypto.buffer.size

默认：8192

被CryptoInputStream 和CryptoOutputStream.使用的缓存大小(www.askmac.cn)

 

 

5.3 命名空间配置

 

dfs.namenode.list.encryption.zones.num.responses

默认：100

当列出加密空间是，在批处理中最大返回的空间数目。逐渐的在在这个批处理中获取到列表可以提升namenode的性能(www.askmac.cn)

 

 

6.crypto 命令行接口

6.1 createZone

 

用法：[-createZone -keyName <keyName> -path <path>]

创建一个新的加密空间

Path	创建的加密空间的路径。这个必须是空目录
Keyname	被加密空间使用key的名称

 

6.2 listZones

用法：[-listZones]

列出所有加密空间，需要有超级用户权限(www.askmac.cn)

 

 

7 使用的例子

 

假设你运行的用户是正常用户或者HDFS超级用户。为需要的环境使用sudo(www.askmac.cn)

 

# As the normal user, create a new encryption key
hadoop key create myKey



# As the super user, create a new empty directory and make it an encryption zone

hadoop fs -mkdir /zone

hdfs crypto -createZone -keyName myKey -path /zone



# chown it to the normal user

hadoop fs -chown myuser:myuser /zone



# As the normal user, put a file in, read it out

hadoop fs -put helloWorld /zone

hadoop fs -cat /zone/helloWorld

 

 

8. distcp 注意事项

8.1 作为超级用户运行

 

一个场景的使用场景是distcp用于备份和灾难恢复目的，在集群间复制数据。这通常是由集群管理员执行，HDFS超级用户。(www.askmac.cn)

在使用HDFS加密时，为了启用这个相同的工作流程，我们引入了一个新虚拟路径的前缀/.reserved/raw/，这个给超级用户直接访问在文件系统中底层的数据块。其允许超级用户distcp数据而不需要访问加密key，也避免了重新加密数据和解密的开销。这也意味着源和目标的数据将是完全一样的字节，如果数据被一个新EDEK解密将不正确。

当使用/.reserved/raw/来distcp加密数据，重要的是使用-px标记保持拓展属性。这是因为加密文件的属性（例如EDEK），是通过拓展属性被暴露在/.reserved/raw/，并且必须能够保证解码文件。这就意味着如果distcp在加密空间root或之上开始，其将自动地在目标创建一个加密空间（如果其不存在）。但是，我们还是建议管理员首先在目标集群创建相同的加密区，以免潜在的问题。

8.2 在被加密和被解密位置之间拷贝

 

默认情况下，distcp 比较由文件提供的校验码，来验证数据是否被成功拷贝到目标端。当在被解密和加密位置之间进行拷贝时，文件系统的校验码将不匹配，因为底层的数据块是不同的。在这种情况下，指定-skipcrccheck和-update distcp标记来避免校验码验证。

 

9.攻击防范

9.1 硬件访问漏洞

这些漏洞假设攻击者已经获得了从集群机硬盘驱动器的物理访问。例如，datanodes和namenodes

1. 访问包含数据加密密钥的进程的swap文件。(www.askmac.cn)

就其本身而言，并不是明文暴露的，其也需要访问加密块文件。

这个可以通过禁止swap来减轻，使用加密的swap或者使用mlock来防止keys被swap出去。

2.访问被加密的块文件

就其本身来说，并不是明文暴露的，它还需要访问DEKs

 

9.2 root 访问漏洞

这些漏洞假设攻击者已经获得了集群机器的root shell访问，例如datanodes和namenodes。大多数漏洞不能再HDFS中解决，因为一个恶意的root用户可以访问那些拥有加密key和明文存储的进程在内存中的状态。对于这些漏洞，唯一的缓解技术是仔细的限制和监测root shell访问。

 

1.访问被加密块文件

就其本身而言，其并未明文，它还需要访问加密keys。(www.askmac.cn)

 

2.转储客户端进程内存来获得DEKs，代表的tokens，明文。

不能缓解

 

3.记录网络流量以嗅探加密keys和传输的加密数据

本身不能在没有EDEK加密key的情况下读取明文。

 

4.转储datanode进程内存来获得加密的数据块

就本身而言，无DEK无法读取明文

 

5.转储namenode进程内存来获得被加密数据加密keys

就本身而言，在没有EDEK的加密key和加密块文件下不能读取明文

 

9.3 HDFS管理漏洞

 

这些漏洞假设攻击者入侵HDFS，但是没有root或HDFS 用户shell访问。(www.askmac.cn)

1.访问加密的块文件

就本身而言，没有EDEK和EDEK加密key不能读取明文

2.访问加密空间和被加密的文件元数据（包含被加密数据加密keys），通过捕获 image。

就本身而言，没有EDEK加密key不能读取明文

 

9.4 流氓用户漏洞

一个流氓用户可以收集他们能够访问的文件keys，并用它们随后来解密这些加密的文件。当用户访问这些文件时，他们已经访问了这些内容。这可以通过周期性的滚动key来缓解。