Vault 的安全模型

由于 Vault 的性质及其管理的数据的机密性，Vault 的安全模型非常关键。 Vault 安全模型的总体目标是提供机密性、完整性、可用性、问责制和身份验证。

这意味着数据在传输中以及落盘后都必须是安全的，不会被窃听或篡改。客户端必须经过适当的身份验证和授权才能访问数据或修改策略。所有交互都必须是可审计的，并且可以唯一地追溯到原始实体。系统必须能够抵御故意绕过其访问控制的任何尝试。

威胁模型

以下是 Vault 威胁模型的各个部分：

• 对 Vault 通信的窃听。客户端与 Vault 的通信，以及从 Vault 到其存储后端，或 Vault 集群节点之间的通信应该是安全的，不会被窃听。
• 篡改已存储的或传输中的数据。任何篡改都应该是可检测的，并导致 Vault 中止事务处理。
• 未经身份验证以及授权的数据访问或是系统控制。所有的请求都必须按照相关的安全策略进行。
• 对数据的访问或管理系统的行为无法审计。如果启用审计日志，所有的请求与响应都必须在客户端接收到任何机密材料之前被记录下来。
• 系统存储的机密的机密性。任何通过 Vault 保存在存储后端的数据都必须是安全的，不会被窃听。实际上，这意味着所有落盘数据都必须加密。
• 系统发生故障时机密材料的可用性。Vault 支持在高可用性配置中运行，以避免失去可用性。

以下部分不在 Vault 威胁模型范围内：

• 防止对存储后端的随意控制。可以对存储后端执行任意操作的攻击者可以通过多种难以或不可能防御的方式破坏安全性。例如，攻击者可以删除或破坏存储后端的所有内容，从而导致 Vault 的全部数据丢失。控制读取的能力将允许攻击者以众所周知的状态进行快照并回滚状态更改，如果这对他们有利的话。
• 防止机密材料的存在性的泄露。可以读取存储后端的攻击者可能会观察到机密材料的存在和存储，即使它是保密的。
• 防止对正在运行的 Vault 进行内存分析。如果攻击者能够检查正在运行的 Vault 实例的内存状态，那么数据的机密性可能会受到威胁。
• 防止 Vault 使用的外部系统或服务中的缺陷。一些身份验证方法或机密引擎将敏感操作委托给 Vault 外部的系统。如果攻击者可以破坏凭据或以其他方式利用这些外部系统中的漏洞，则数据的机密性或完整性可能会受到损害。
• 防止底层主机上的恶意插件或代码执行。如果攻击者可以获得对底层主机的代码执行或写入权限，那么数据的机密性或完整性可能会受到损害。

外部威胁综述

鉴于 Vault 的架构，我们关注 3 个不同的 Vault 系统。

• 客户端，它通过 API 与 Vault 对话
• Vault 服务，它提供 API 和服务请求
• 存储后端，服务器利用它来读取和写入数据

Vault 客户端和服务器之间没有默认的相互信任。客户端使用 TLS 来验证服务器的身份并建立安全的通信通道。服务器要求客户端为用于识别客户端的每个请求提供客户端令牌。只允许没有令牌的客户端发出登录请求。

集群内 Vault 实例之间的所有服务器之间的流量（即高可用性、企业复制或集成存储）都使用相互验证的 TLS 来确保传输中数据的机密性和完整性。节点在加入集群之前通过解封质询或一次性激活令牌进行身份验证。

Vault 使用的存储后端在设计上也是不受信任的。 Vault 对向后端发出的所有请求使用安全屏障(Security Barrier)。安全屏障使用具有 96 位随机数的 Galois Counter Mode (GCM) 的 256 位高级加密标准 (AES) 密码自动加密离开 Vault 的所有数据。随机数是为每个加密对象随机生成的。当从安全屏障读取数据时，在解密过程中验证 GCM 身份验证标签以检测数据有无篡改。

使用某些后端时，Vault 可能会通过 TLS 与后端通信，以提供额外的安全层。在某些情况下，例如文件后端不需要这样做。由于存储后端是不可信的，即使与后端的通信被拦截，窃听者也只能访问加密数据。

内部威胁综述

在 Vault 系统中，一个关键的安全问题是攻击者试图访问他们无权访问的机密材料。如果攻击者已被允许对 Vault 进行某种级别的访问并且能够进行身份验证，则这是一种内部威胁。

当客户端首次通过 Vault 进行身份验证时，auth 身份验证方法用于验证客户端的身份并返回关联的 ACL 策略列表。该关联是由 Vault 的运维团队提前配置的。例如，"engineering" 团队中的 GitHub 用户可能会映射到 "engineering" 和 "ops" Vault 策略。然后 Vault 生成一个客户端令牌，它是一个随机生成的序列化值，并将其映射到策略列表，然后将此客户端令牌返回给客户端。

在每个请求中，客户端都会提供此令牌。然后 Vault 使用它来检查令牌是否有效并且没有被吊销或过期，并根据关联的策略生成 ACL。 Vault 使用严格的默认拒绝执行策略。这意味着除非相关策略允许给定操作，否则它将被拒绝。每个策略都指定了授予 Vault 中路径的访问级别。合并策略时（如果多个策略与客户端相关联），则使用允许的最高访问级别。例如，如果 "engineering" 策略允许对"eng/" 路径进行读或者更新操作，而 "ops" 策略允许对 "ops/" 路径进行读访问，则用户将获得这些路径的并集。使用最具体的定义策略匹配策略，可能是完全匹配或最长前缀匹配 glob 模式。有关详细信息，请参阅策略语法。

某些操作仅允许 "root" 用户操作，这是 Vault 中内置的一项杰出策略。这类似于 Unix 系统上的 root 用户或 Windows 上的管理员的概念。尽管可以为客户端提供根令牌或与根策略相关联，但 Vault 支持 "sudo" 特权的概念。作为策略的一部分，用户可能会被授予某些路径的 "sudo" 权限，这样他们仍然可以执行安全敏感操作，而无需被授予对 Vault 的全局 root 访问权限。

最后，Vault 支持通过 Shamir 算法支持双人规则解封。当 Vault 启动时，它以密封状态启动。这意味着 Vault 此时并不知晓从存储后端读取和写入所需的加密密钥。解封过程需要提供主密钥，以便可以获取加密密钥。分发主密钥的风险在于，有权访问它的单个恶意行为者可以解密整个 Vault。相反，Shamir 算法允许我们将主密钥拆分为多个分片或多个部分。分片的数量和所需的阈值是可配置的，但默认情况下，Vault 会生成 5 个分片，必须提供其中的任意 3 个才能重建主密钥。

通过使用机密分片算法，我们避免了对主密钥持有者的绝对信任，并完全避免存储主密钥。只能通过重建分片来检索主密钥。这些分片对向 Vault 提出任何请求没有用处，只能用于解封。解封后，标准 ACL 机制将用于所有请求。

打个比方，银行将保险箱放在保险库内。每个保险箱都有一把钥匙，而金库门既有密码也有钥匙。拱顶被钢和混凝土包裹着，所以门是唯一可以通行的入口。类似于 Vault，加密算法是保护数据的钢筋混凝土。虽然可以通过混凝土隧道或暴力破解加密密钥，但这将非常耗时。打开银行金库需要两个因素：钥匙和组合。同样，Vault 需要提供多个分片来重建主密钥。解封后，每个保险箱仍然需要所有者提供密钥，同样，Vault ACL 系统会保护所有存储的机密。