☰

2.2 分区或原始磁盘上的 LUKS？RAID 怎么样？

tag-icon • tag-icon partitioning hard-drive encryption luks
2.2 分区或原始磁盘上的 LUKS？RAID 怎么样？

我已经设置了一些 LUKS 加密驱动器，并注意到我一直在“原始”（？）驱动器（即 /dev/sdb）上直接创建加密磁盘，而谷歌的许多示例都显示它是在 /dev/sdb1 上创建的

使用 /dev/sdb 的示例：

# cryptsetup luksFormat /dev/sdb
# cryptsetup luksOpen /dev/sdb lvm_backup

..然后继续创建卷组和逻辑卷，如下所示：

# vgcreate vg_backup /dev/mapper/lvm_backup
# lvcreate -l +100%FREE lvm_backup -n backup
# mkfs.ext4 /dev/mapper/vg_backup-backup

最后安装驱动器。

这让我的 lsblk 看起来像这样：

sdb                              8:16   0   2.7T  0 disk  
  lvm_backup (dm-3)            252:3    0   2.7T  0 crypt 
    vg_backup-backup (dm-5)    252:5    0     2T  0 lvm   /backup

相比之下，其他 lsblk 输出如下所示：

sdb                              8:16   0   2.7T  0 disk  
  sdb1                           #:#     0    2.7T 0 part
    lvm_backup (dm-3)            252:3    0   2.7T  0 crypt 
      vg_backup-backup (dm-5)    252:5    0     2T  0 lvm   /backup

直接在磁盘（/dev/sdb）上操作与先创建分区（/dev/sdb1）相比有哪些优点/缺点？

我假设这可能与以下内容相关： https://serverfault.com/questions/338937/differences-between-dev-sda-and-dev-sda1

答案1

顺便说一下，我在想如果你使用整个设备（/dev/sdb）并且你的 LUKS 标头位于驱动器的开头，并且如果其他一些工具或操作系统“有帮助地”决定你的磁盘未格式化且没有 MBR 或 GPT，如果它覆盖你的 LUKS 标头，那将是坏的。如果您正在为 LUKS 使用分区，那么至少新的 MBR 或 GPT 不会造成那么大的破坏。

你应该总是备份 LUKS 头无论如何，正如cryptsetup手册页所建议的那样。

这就是cryptsetup 常见问题解答说关于使用“分区或原始磁盘上的 2.2 LUKS？RAID 怎么样？”并建议“2.8 在 RAID 之上加密还是反过来？”（它很长，但我只粘贴它，提到 RAID 和 LVM 会使事情变得非常复杂，您可能需要重新考虑在 LUKS 上使用 LVM）：

2.2 分区或原始磁盘上的 LUKS？RAID 怎么样？

另请参阅第 2.8 项。

这是一个复杂的问题，而且由于 RAID 和 LVM 的出现，这个问题变得更加复杂。我将尝试给出一些场景并讨论其优缺点。请注意，我使用 LUKS 是为了简单起见，但您也可以使用普通的 dm-crypt 完成所描述的所有操作。还请注意，您的特定场景可能非常特殊，以至于我下面说的大多数甚至所有事情都不适用。

请注意，如果将 LVM 添加到组合中，事情会变得非常复杂。RAID 也是如此，但情况没那么复杂。特别是，数据恢复会变得极其困难。只有在有充分理由的情况下才添加 LVM，并始终记住 KISS 是区分工程师和业余爱好者的标志。当然，如果您真的需要增加复杂性，KISS 可以满足您的需求。但要非常确定，因为这是要付出代价的。在工程学中，复杂性始终是敌人，遇到时需要毫不留情地与之抗争。

还请考虑使用 RAID 而不是 LVM，因为至少对于旧版超级块格式 0.90，RAID 超级块位于损坏 LUKS 标头的风险最小的位置（磁盘末尾），您可以让 RAID 控制器（即内核）组装阵列，这是理所当然的。为此，请使用分区类型 0xfd。我建议远离超级块格式 1.0、1.1 和 1.2，除非您真的需要它们。

场景：

(1) 加密分区：只需根据自己的喜好创建一个分区，然后将 LUKS 放在其上，并将文件系统放入 LUKS 容器中。这样就可以隔离不同任务的数据区域，就像普通分区一样。您可以拥有机密数据、非机密数据、某些特定应用程序的数据、用户主目录、根目录等。优点是简单，因为分区和文件系统之间存在 1:1 映射、明确的安全功能以及将数据分离到不同的独立 (!) 容器中的能力。

请注意，您无法对加密的根执行此操作，因为这需要 initrd。另一方面，对于有能力的攻击者来说，initrd 的攻击能力与非加密的根一样脆弱，因此这样做实际上没有任何安全优势。想要破坏您的系统的攻击者只会破坏 initrd 或内核本身。处理此问题的更好方法是确保根分区不存储任何关键数据，并将其移动到其他加密分区。如果您真的担心您的根分区可能会被具有物理访问权限的人破坏（但奇怪的是，他们不会破坏您的 BIOS、键盘等），请以其他方式保护它。PC 并没有设置真正安全的启动链（无论有些人声称如何）。

也就是说，如果您想要一个加密的根分区，则必须将带有 cryptsetup 的 initrd 存储在其他地方。传统方法是在 /boot 下为此设置一个单独的分区。您也可以将该 initrd 放在可启动的记忆棒、可启动 CD 或可启动的外部驱动器上。内核和 Grub 通常与该 initrd 位于同一位置。第 9 节给出了此类 initrd 的最小示例。

(2) 完全加密的原始块设备：为此，将 LUKS 放在原始设备（例如 /dev/sdb）上，并将文件系统放入 LUKS 容器中，无需进行任何分区。这非常适合用于备份或离线数据存储的外部 USB 磁盘等。

(3) 加密 RAID：从分区和/或完整设备创建 RAID。将 LUKS 放在 RAID 设备之上，就像它是一个普通的块设备一样。应用程序与上面的一样，但您获得了冗余。（附注：许多人似乎不知道这一点：您可以在 Linux 中使用任意数量的组件来执行 RAID1。）另请参阅第 2.8 条。

(4) 现在，有些人主张在 RAID 层以下进行加密。这有几个严重的问题。一个是突然间调试 RAID 问题变得更加困难。您无法再进行自动 RAID 组装。您需要保持不同 RAID 组件的加密密钥同步或以某种方式管理它们。唯一可能的优势是，随着更多 CPU 进行加密，事情可能会运行得更快一些，但如果速度优先于安全性和简单性，那么您这样做无论如何都是错误的。缓解速度问题的一个好方法是获得一个执行硬件 AES 的 CPU，就像今天大多数 CPU 一样。

2.8 在 RAID 之上加密还是反过来？

另请参阅第 2.2 项。

除非您有特殊需要，否则请将加密置于 RAID 和文件系统之间，即在 RAID 之上进行加密。您可以反过来做，但您必须注意，您需要为每个单独的磁盘提供密码，并且 RAID 自动检测将不再起作用。因此，最好加密 RAID 设备，例如 /dev/dm0 。

这意味着典型的分层如下所示：

  Filesystem     <- top
  |
  Encryption (LUKS)
  |
  RAID
  |
  Raw partitions (optional)
  |
  Raw disks      <- bottom

这样做的一大优势是，您可以像管理任何其他常规 RAID 容器一样管理 RAID 容器，它不关心其内容是否加密。这大大降低了复杂性，这是存储加密非常有价值的一点。

尽量避免使用所谓的假 RAID（从 BIOS 配置但由专有驱动程序处理的 RAID）。请注意，如果启用，某些假 RAID 固件会自动在磁盘上写入签名。这会导致 LUKS 元数据损坏。如果您不使用 RAID 选项，请务必在 BIOS 中将其关闭。

如果您调整（扩大）底层设备的大小，并且一些剩余的元数据出现在调整大小的设备末尾附近（如 GPT 表的辅助副本），则可能会发生另一次数据损坏。您可以使用 wipefs 命令来检测和擦除此类签名。

相关内容