你好,游客 登录 注册 搜索
背景:
阅读新闻

【dbdao Hadoop 大数据学习】HDFS中的传输加密

[日期:2016-06-13] 来源:dbDao IT技术玩家博客  作者:郭, 兆伟 [字体: ]

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

Hadoop

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

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

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

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

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

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

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

3 使用场景

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

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

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上存储(t.dbdao.com)

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 存储的,这并不构成安全威胁。(t.dbdao.com)

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。(t.dbdao.com)

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

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

5.1 配置集群KeyProvider

dfs.encryption.key.provider.uri

当读取和写入加密空间时,使用KeyProvider 和加密key进行交互。(t.dbdao.com)

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逗号分隔的编码解码列表。第一个如果可用的话将实现,其他的回退。(t.dbdao.com)

hadoop.security.crypto.cipher.suite

默认值:AES/CTR/NoPadding

对于编码解码的套件

hadoop.security.crypto.jce.provider

默认:None

在CryptoCodec中用的JCE提供者名称

hadoop.security.crypto.buffer.size

默认:8192

被CryptoInputStream 和CryptoOutputStream.使用的缓存大小(t.dbdao.com)

5.3 命名空间配置

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

默认:100

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

6.crypto 命令行接口

6.1 createZone

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

创建一个新的加密空间

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

6.2 listZones

用法:[-listZones]

列出所有加密空间,需要有超级用户权限(t.dbdao.com)

7使用的例子

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

# As the normal user, create a new encryption key
hadoopkeycreatemyKey
 
 
 
# As the super user, create a new empty directory and make it an encryption zone
 
hadoopfs -mkdir /zone
 
hdfscrypto -createZone -keyNamemyKey -path /zone
 
 
 
# chown it to the normal user
 
hadoopfs -chownmyuser:myuser /zone
 
 
 
# As the normal user, put a file in, read it out
 
hadoopfs -puthelloWorld /zone
 
hadoopfs -cat /zone/helloWorld

8. distcp 注意事项

8.1 作为超级用户运行

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

在使用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文件。(t.dbdao.com)

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

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

2.访问被加密的块文件

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

9.2 root 访问漏洞

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

1.访问被加密块文件

就其本身而言,其并未明文,它还需要访问加密keys。(t.dbdao.com)

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

不能缓解

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

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

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

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

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

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

9.3 HDFS管理漏洞

这些漏洞假设攻击者入侵HDFS,但是没有root或HDFS 用户shell访问。(t.dbdao.com)

1.访问加密的块文件

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

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

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

9.4 流氓用户漏洞

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

本文固定链接:http://t.dbdao.com/archives/hdfs-transparent-encryption.html

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





收藏 推荐 打印 | 录入:elainebo | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款