第 15 章 网络绑定磁盘加密 (NBDE)
15.1. 关于磁盘加密技术
通过 Network-Bound Disk Encryption (NBDE)，您可以加密物理和虚拟机上的硬盘驱动器的根卷，而无需在重启机器时手动输入密码。
15.1.1. 磁盘加密技术比较
要了解 Network-Bound Disk Encryption (NBDE) 对于在边缘服务器中静态数据的安全，请在运行 Red Hat Enterprise Linux (RHEL) 的系统上将密钥托管和 TPM 磁盘加密与 NBDE 进行对比。
下表提供了需要考虑威胁模型和每个加密解决方案复杂性的一些权衡。
| 场景 | 密钥托管 | TPM 磁盘加密（没有 Clevis） | NBDE |
|---|---|---|---|
| 针对单磁盘失窃的保护 | X | X | X |
| 针对整个服务器偏移的保护 | X | X | |
| 系统可以独立于网络重启 | X | ||
| 没有定期重新密钥 | X | ||
| 密钥永远不会通过网络传输 | X | X | |
| OpenShift 支持 | X | X |
15.1.1.1. 密钥托管
密钥托管是用于存储加密密钥的传统系统。网络上的密钥服务器存储具有加密引导磁盘节点的加密密钥，并在查询时返回。关键管理、传输加密和身份验证的复杂性不能成为引导磁盘加密的合理选择。
虽然在 Red Hat Enterprise Linux (RHEL) 中可用，但基于托管的磁盘加密设置和管理是一个手动过程，不适用于 OpenShift Container Platform 的自动化操作，包括自动添加节点，且当前不受 OpenShift Container Platform 支持。
15.1.1.2. TPM 加密
受信任的平台模块 (TPM) 磁盘加密最适合在远程保护位置的数据中心或安装。dm-crypt 和 BitLocker 使用 TPM 绑定密钥加密磁盘，然后将 TPM 绑定密钥存储在 TPM 中（附加到节点的主板）中。这种方法的主要优点是没有外部依赖项，节点可以在引导时解密自己的磁盘，而无需任何外部交互。
如果磁盘被从节点盗取并被外部分析，TPM 磁盘加密可以防止数据解密。但是，对于不安全的位置，这可能是不够的。例如，如果攻击者窃取整个节点，攻击者可以在打开节点电源时截获数据，因为节点会解密自己的磁盘。这适用于具有物理 TPM2 芯片的节点，以及具有虚拟可信平台模块 (VTPM) 访问的虚拟机。
15.1.1.3. 网络绑定磁盘加密 (NBDE)
网络绑定磁盘加密 (NBDE) 通过网络以安全匿名的方式将加密密钥与外部服务器或一组服务器有效连接。这不是一个关键托管项，因为节点不存储加密密钥或将其传送到网络上，否则行为方式类似。
Clevis 和 Tang 是通用客户端和服务器组件，提供网络绑定加密。Red Hat Enterprise Linux CoreOS (RHCOS) 将这些组件与 Linux Unified Key Setup-on-disk-format (LUKS) 结合使用来加密和解密 root 和非 root 存储卷，以完成 Network-Bound Disk Encryption。
当节点启动时，它会尝试通过执行加密握手来联系预定义的 Tang 服务器集合。如果它可以访问所需的 Tang 服务器数量，节点可以构建其磁盘解密密钥并解锁磁盘以继续启动。如果节点因为网络中断或服务器不可用而无法访问 Tang 服务器，则该节点无法引导并继续无限期重试，直到 Tang 服务器再次可用为止。由于密钥有效与网络中节点的存在相关联，因此尝试获得静态数据的攻击者需要同时获取节点上的磁盘，以及访问 Tang 服务器的网络访问权限。
下图演示了 NBDE 的部署模型。
下图说明了重启期间 NBDE 的行为。
15.1.1.4. Secret 共享加密
Shamir 的机密共享 (ss) 是一种加密算法，用于安全地划分、分发和重新集合密钥。使用这个算法，OpenShift Container Platform 可以支持更复杂的密钥保护组合。
当您将集群节点配置为使用多个 Tang 服务器时，OpenShift Container Platform 使用 ss 来设置解密策略，该策略将在至少一个指定服务器可用时成功。您可以创建层以提高安全性。例如，您可以定义一个策略，其中 OpenShift Container Platform 需要 TPM 和给定的 Tang 服务器列表之一来解密磁盘。
15.1.2. Tang 服务器磁盘加密
以下组件和技术实施网络绑定磁盘加密 (NBDE)。
Tang 是一个将数据绑定到网络存在的服务器。它使得当节点绑定到特定安全网络时，包含可用数据的节点。Tang 是无状态的，不需要传输层安全 (TLS) 或身份验证。与基于 escrow 的解决方案不同，密钥服务器存储所有加密密钥并了解每个加密密钥，Tang 永远不会与任何节点密钥交互，因此它永远不会从节点获得任何识别信息。
Clevis 是一种可自动解密的可插入框架，提供 Linux Unified Key Setup-on-disk-format (LUKS) 卷的自动解锁。Clevis 软件包在节点上运行，并提供功能的客户端。
Clevis pin 是 Clevis 框架的一个插件。有三个固定类型：
- TPM2
- 将磁盘加密绑定到 TPM2。
- tang
- 将磁盘加密绑定到 Tang 服务器以启用 NBDE。
- Shamir 的机密共享 (sss)
允许其他固定的更复杂的组合.它允许更多细微的策略，例如：
- 必须能够访问这三个 Tang 服务器中的一个
- 必须能够访问这五个 Tang 服务器中的三个
- 必须能够访问这三个 Tang 服务器中的至少一个 TPM2 和D
15.1.3. Tang 服务器位置规划
在规划 Tang 服务器环境时，请考虑 Tang 服务器的物理和网络位置。
- 物理位置
Tang 服务器的地理位置相对而言并不重要，只要它们能够适当保护不受未授权访问或失窃的影响，并提供运行关键服务所需的可用性和可访问性。
具有 Clevis 客户端的节点不需要本地 Tang 服务器，只要 Tang 服务器始终可用。灾难恢复需要冗余电源和冗余网络连接，而不管其位置如何。
- 网络位置
任何可通过网络访问 Tang 服务器的节点都可以解密自己的磁盘分区，或者由同一 Tang 服务器加密的任何其他磁盘。
为 Tang 服务器选择网络位置，以确保给定主机存在或不存在网络连接允许解密。例如，防火墙保护可能已实施，以禁止从任何类型的虚拟客户机或公共网络或位于该建筑不安全区域的任何网络jack的访问。
此外，还要维护生产和开发网络之间的网络隔离。这有助于定义适当的网络位置，并添加额外的安全层。
不要在同一资源上部署 Tang 服务器，如在同一个
rolebindings.rbac.authorization.k8s.io集群，它们负责解锁。但是，Tang 服务器和其他安全资源集群可能是一个有用的配置，以启用对多个额外集群和集群资源的支持。
15.1.4. Tang 服务器大小要求
围绕可用性、网络和物理位置的要求推动了要使用多少 Tang 服务器的决策，而不是服务器容量的担忧。
Tang 服务器不维护使用 Tang 资源加密的数据状态。Tang 服务器可以完全独立，或者仅共享其关键材料，从而可以很好地扩展。
Tang 服务器可以通过两种方式处理关键资料：
多个 Tang 服务器共享关键资料：
- 您必须对同一 URL 后面的 Tang 服务器共享密钥进行负载均衡。配置可以像循环 DNS 一样简单，也可以使用物理负载均衡器。
- 您可以从单个 Tang 服务器扩展到多个 Tang 服务器。当 Tang 服务器共享密钥资料和相同的 URL 时，扩展 Tang 服务器不需要在节点上重新密钥或客户端重新配置。
- 客户端节点设置和密钥轮转只需要一个 Tang 服务器。
多个 Tang 服务器生成自己的关键资料：
- 您可以在安装时配置多个 Tang 服务器。
- 您可以在负载均衡器后面扩展单个 Tang 服务器。
- 所有 Tang 服务器都必须在客户端节点设置或密钥轮转过程中可用。
- 当客户端节点使用默认配置引导时，Clevis 客户端会联系所有 Tang 服务器。只有 n 个 Tang 服务器必须在线才能进行解密。n 的默认值是 1。
- 红帽不支持会更改 Tang 服务器行为的安装后配置。
15.1.5. 日志记录注意事项
集中记录 Tang 流量具有优势，因为您可以发现意外的解密请求等事件。例如：
- 请求解密与其引导序列不匹配的密码短语的节点
- 在已知维护活动之外请求解密的节点，如循环密钥
