OpenZFS本地加密的快速入门指南

OpenZFS带来的众多特性之一是ZFS本机加密。本机加密最初是在OpenZFS 0.8中引入的，它允许系统管理员在ZFS本身中透明地加密静止数据。这就不需要像陆，VeraCrypt,或磁盘加密．

OpenZFS的加密算法默认为两者之一aes - 256 - ccm(在0.8.4之前)或aes - 256 gcm(> = 0.8.4)时加密上=是集。但也可以直接指定。目前支持的算法有:

• aes - 128 - ccm
• aes - 192 - ccm
• aes - 256 - ccm(默认在OpenZFS < 0.8.4)
• aes - 128 gcm
• aes - 192 gcm
• aes - 256 gcm(默认在OpenZFS >= 0.8.4)

但是，OpenZFS原生加密的内容比使用的算法更多——因此，我们将尝试从系统管理员的角度对“为什么”和“什么”以及简单的“如何”提供简短但坚实的基础。

为什么(或者为什么不)OpenZFS本地加密?

显然，想要提供静止加密的聪明的系统管理员实际上并不需要OpenZFS本机加密。正如引言中提到的，陆，VeraCrypt，以及许多其他可用的方案，可以在OpenZFS本身的下面或上面进行分层。

首先，“为什么不”

把Linux之类的东西放在一起陆在OpenZFS下面有一个优势——使用整个磁盘加密后，攻击者将无法看到ZFS的名称、大小或属性数据集而且zvols不能拿到钥匙。事实上，攻击者根本不可能看到ZFS正在被使用!

但它也有明显的缺点陆(或类似)在OpenZFS之下。其中最棘手的是每一个个人必须对将成为池一部分的磁盘进行加密，在ZFS池之前加载和解密每个卷进口阶段。对于具有许多磁盘(在某些情况下，有许多磁盘)的ZFS系统来说，这可能是一个明显的挑战数以千万计的磁盘。ZFS下加密的另一个问题是，额外的层是一个容易出错的额外的东西，它可以撤销ZFS的所有正常完整性保证。

把陆或类似的在OpenZFS之上的解决了前面提到的问题—a陆加密zvol无论涉及多少磁盘，都只需要一个键陆层不能从这里撤销OpenZFS的完整性保证。不幸的是，在zfs上加密引入了一个新问题——它有效地削弱了OpenZFS的内联压缩，因为加密的数据通常是不可压缩的。这种方法也需要一个的使用zvol每个加密的文件系统，以及一个来宾文件系统(例如，ext4)以格式化陆体积本身。

现在,“为什么”

OpenZFS原生加密解决了这一问题:它运行在普通ZFS存储层之上，因此不会削弱ZFS自身的完整性保证。但它也不会干扰ZFS压缩—数据在保存到加密文件之前会被压缩数据集或zvol．

选择OpenZFS原生加密还有一个更令人信服的理由——所谓的“原始发送”。ZFS复制的速度和效率惊人地高——通常比文件系统无关的工具快好几个数量级rsync- raw send不仅可以加密复制数据集年代和zvolS，但这样做不会将密钥暴露给远程系统。

这意味着您可以使用ZFS复制将数据备份到不可信的位置，而不必担心您的私人数据被读取。使用原始发送，您的数据被复制而无需解密—备份目标根本无法解密它。这意味着你可以把你的异地备份复制到朋友的家里或商业服务rsync.net或zfs.rent在不损害您的隐私的情况下，即使服务(或朋友)本身受到损害。

如果需要恢复站点外备份，可以简单地复制它回来去你自己的地方——然后，然后只有然后，加载解密密钥来实际访问数据。这既适用于全复制(跨线移动每一个块)，也适用于异步增量复制(从一个通用的快照开始，只移动自该快照以来已更改的块)。

什么是加密的，什么不是?

OpenZFS原生加密不是一个全磁盘加密方案——它是在每个数据集/每个zvol的基础上启用或禁用的，而且不能对整个池作为一个整体启用它。加密数据集或zvols的内容不受静止监视的保护，但描述数据集/zvols本身的元数据却没有。

假设我们创建了一个名为池/加密，在它下面我们创建了更多的子数据集。的加密属性默认从父数据集继承，所以我们可以看到以下内容:

root@banshee:~# zfs create -o encryption=on -o keylocation=prompt -o keyformat=passphrase banshee/encrypted Enter passphrase: Re-enter passphrase:zfs root@banshee: ~ #创建女妖/加密/ child1 root@banshee: ~ # zfs创建女妖/加密/ child2 root@banshee: ~ # zfs创建女妖/加密/格root@banshee: ~ #效果参考使用zfs - r女妖/加密列表名称挂载点女妖/加密1.58米848克432 k /女妖/加密的女妖/加密/ child1 320 k 848克320 k /女妖/加密/ child1女妖/加密/ child2 320 k 848克320 k /女妖/加密/ child2女妖/加密/格320 k 848克320 k /女妖/加密/格root@banshee:~# zfs get encryption banshee/encrypted/child1 NAME属性值SOURCE banshee/encrypted/child1 encryption aes-256-gcm - .

目前，我们的加密数据集都已经安装好了。但是，即使我们卸载它们并卸载加密密钥——使它们无法访问——我们仍然可以看到它们存在，以及它们的属性:

root@banshee:~# wget -qO /banshee/encrypted/child2/ huckfin .txt http://textfiles.com/etext/AUTHORS/TWAIN/huck_finn root@banshee:~# zfs unmount banshee/encrypted root@banshee:~# zfs uninstall -key -r banshee/encrypted 1 / 1 key(s) successfully unloaded root@banshee:~# zfs mount banshee/encrypted cannot mount 'banshee/encrypted': encryption key not loaded root@banshee:~# ls /banshee/encrypted/child2 ls: cannot access '/banshee/encrypted/child2':没有这样的文件或目录root@banshee:~# zfs list -r banshee/encrypted NAME USED AVAIL REFER MOUNTPOINT banshee/encrypted 2.19M 848G 432K /banshee/encrypted banshee/encrypted/child1 banshee/encrypted/child2 944K 848G 720K /banshee/encrypted/child2 banshee/encrypted/child3 320K 848G 320K /banshee/encrypted/child3

正如我们在上面看到的，卸载加密密钥后，我们再也看不到我们新下载的拷贝《哈克贝利·费恩历险记》在/女妖/加密/ child2 /．我们可以仍然可以看到我们整个zfs加密树的存在和结构。我们还可以看到每个加密数据集的属性，包括但不限于使用，效果,请参考每个数据集。

值得注意的是，尝试ls未加载密钥的加密数据集不一定会产生错误:

root@banshee:~# zfs get keystatus banshee/encrypted NAME PROPERTY VALUE SOURCE banshee/encrypted keystatus unavailable - root@banshee:~# ls /banshee/encrypted root@banshee:~#

这是因为主机上存在一个裸目录，即使实际的数据集没有挂载。重新加载键也不会自动重新挂载数据集:

root@banshee:~# zfs load-key -r banshee/encrypted Enter passphrase for 'banshee/encrypted': 1 / 1 key(s) successfully loaded root@banshee:~# zfs mount | grep encr root@banshee:~# ls /banshee/encrypted/child2 ls: cannot access '/banshee/encrypted/child2': No such file or directory

以便获得我们最新的《哈克贝利·费恩历险记》，我们还需要实际挂载新键重新加载的数据集:

root@banshee:~# zfs get keystatus banshee/encrypted/child2 keystatus available - root@banshee:~# ls -l /banshee/encrypted/child2 ls: cannot access '/banshee/encrypted/child2': No such file or directory root@banshee:~# zfs mount -a root@banshee:~# ls -lh /banshee/encrypted/child2 total 401K -rw-r——r——1 root root 554K Jun 13 2002 huckfin .txt . NAME属性值SOURCE banshee/encrypted/child2 keystatus available -

既然我们都装了必要的钥匙而且装上数据集，我们可以再次看到加密的数据。