了解 Snowflake 中的加密密钥管理¶

分层密钥模型¶

分层密钥模型为 Snowflake 的加密密钥管理提供了框架。该层次结构由多层密钥组成，其中每个上层密钥（父密钥）可对下层密钥（子密钥）进行加密。在安全术语中，使用父密钥对所有子密钥进行加密被称为“包装”。

Snowflake 的分层密钥模型由四个级别的密钥组成：

• 根密钥

• 账户主密钥

• 表主密钥

• 文件密钥

每个客户账户都有一个单独的密钥层次结构（账户级、表级和文件级密钥），如下图所示：

在像 Snowflake 这样的多租户云服务中，分层密钥模型使用单独的账户主密钥来隔离每个账户。除了可将客户数据分开存储的 访问控制模型 之外，分层密钥模型还提供了另一层账户隔离。

分层密钥模型缩小了每层密钥的范围。例如，表主密钥可加​​密单个表。文件密钥可加密单个文件。分层密钥模型限制了每个密钥保护的数据量及其可用时长。

加密密钥轮换¶

所有 Snowflake 管理的密钥在超过 30 天后都会由 Snowflake 自动轮换。届时，活动密钥停用，新密钥得以创建。当 Snowflake 确定不再需要已停用的密钥时，会自动将其销毁。处于活动状态时，密钥用于加密数据并可供客户使用。停用后，密钥仅用于解密数据且仅可用于访问数据。

在密钥层次结构中包装子密钥或将数据插入表中时，仅可使用当前的活动密钥来加密数据。密钥被销毁后，不能用于加密或解密。定期密钥轮换将密钥的生命周期限制在有限的时间内。

下图说明了一个表主密钥 (TMK) 在三个月内的密钥轮换过程：

TMK 轮换的工作原理如下：

• 第 1 版 TMK 在 4 月处于活动状态。4 月插入此表的数据受 TMK v1 保护。

• 5 月，该 TMK 轮换： TMK v1 停用，一个完全随机的新密钥 TMK v2 得到创建。TMK v1 现在仅用于解密 4 月的数据。插入表中的新数据使用 TMK v2 进行加密。

• 6 月，该 TMK 再次轮换： TMK v2 停用，新的 TMK v3 得到创建。TMK v1 用于解密 4 月的数据， TMK v2 用于解密 5 月的数据，而 TMK v3 用于对 6 月插入表中的新数据进行加密和解密。

如前所述，密钥轮换限制了密钥用于加密数据的有效时长。结合分层密钥模型，密钥轮换进一步限制了某一密钥版本保护的数据量。美国国家标准与技术研究院 (NIST) `建议<http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf>`_ 对密钥的生命周期进行限制，以提高安全性。

定期更新密钥¶

本节继续解释账户主密钥和表主密钥的生命周期。加密密钥轮换 描述了密钥轮换，即定期用新密钥替换活动密钥并停用旧密钥。定期的数据密钥更新使生命周期得以完整。

密钥轮换可确保密钥从活动状态转为停用状态，而更新密钥可确保密钥从停用状态转为销毁状态。

如果启用定期更新密钥，则当表的加密密钥停用超过一年时，Snowflake 会自动创建新的加密密钥，并使用新密钥对此前由已停用密钥保护的所有数据进行重新加密。新密钥将用于解密后续的表数据。

下图显示了单个表的 TMK 如何定期更新密钥：

定期更新密钥的工作原理如下：

• 次年 4 月， TMK v1 停用一整年后，系统使用全新的随机密钥更新密钥（第 2 代）。

  由 TMK v1 第 1 代保护的数据文件将使用 TMK v1 第 2 代解密并重新加密。由于没有进一步的目的， TMK v1 第 1 代将被销毁。

• 5 月，Snowflake 对受 TMK v2 保护的表数据执行相同的密钥更新过程。

• 以此类推。

在此示例中，密钥的生命周期限制为一年。

根据 NIST 建议，更新密钥限制了密钥可供接收者使用的总时长。此外，对数据更新密钥时，Snowflake 可以增加加密密钥的大小并利用更好的加密算法，这些算法自上一代密钥创建以来可能已标准化。

因此，更新密钥可确保所有新旧客户数据均使用最新的安全技术进行加密。

Snowflake 在后台对数据文件在线更新密钥，不会对当前正在运行的客户工作负载产生任何影响。您始终可以使用正在更新密钥的数据。无需停机即可对数据更新密钥，并且不会对工作负载造成性能影响。这一优势是 Snowflake 存储和计算资源分离架构的直接结果。

硬件安全模块¶

Snowflake 依赖云托管的硬件安全模块 (HSMs) 来确保密钥存储和使用的安全。每个云平台都有不同的 HSM 服务，影响着 Snowflake 如何使用各平台的 HSM 服务：

• 在 AWS 和 Azure 上，Snowflake 使用 HSM 创建并存储根密钥。

• 在 Google Cloud 上， HSM 服务通过 Google Cloud KMS （密钥管理服务） API 提供。Snowflake 使用 Google Cloud KMS 在多租户 HSM 分区中创建并存储根密钥。

对于所有云平台和密钥层次结构中的所有密钥，存储在 HSM 中的密钥用于展开层次结构中的密钥。例如，要解密表主密钥，则需使用 HSM 中的密钥来展开账户主密钥。该过程发生在 HSM 中。该过程完成后，软件操作将使用账户主密钥来解密表主密钥。

下图显示了 HSM、账户主密钥、表主密钥和文件密钥之间的关系：

客户管理的密钥的优势¶

客户管理的密钥的优势包括：

控制数据访问:

您可以完全控制密钥管理服务中的主密钥，从而完全控制 Snowflake 中的数据。如果您不释放此密钥，则您的 Snowflake 账户中存储的数据将无法解密。

由于数据泄露而禁用访问:

如果遇到安全漏洞，您可以禁用对密钥的访问，并停止 Snowflake 账户中正在运行的所有数据操作。

数据生命周期的所有权:

使用客户管理的密钥，您可以使数据保护要求与业务流程保持一致。对密钥的显式控制可以为整个数据生命周期（从创建到删除）提供保护。

对客户管理的密钥的重要要求¶

客户管理的密钥具备显著的安全优势，但也有一些关键的基本要求，您必须:emph:不断 遵守这些要求才能保护您的主密钥：

保密性:

您必须始终确保密钥的安全和保密。

完整性:

您必须确保密钥受到保护，免遭不当修改或删除。

可用性:

要执行查询并访问数据，您必须确保密钥始终可供 Snowflake 使用。

根据设计，无效或不可用的密钥将导致 Snowflake 数据操作中断，直到有效密钥再次可供 Snowflake 使用。

但是，Snowflake 能够处理由常见问题（例如网络通信故障）引起的临时可用性问题（最多 10 分钟）。10 分钟后，如果密钥仍然不可用，您的 Snowflake 账户中的所有数据操作将完全停止。对密钥的访问恢复后，数据操作即可重新开始。

不遵守这些要求可能会严重危害数据的完整性，轻则数据 暂时 无法访问，重则数据被 永久 禁用。此外，对于您的组织在维护密钥过程中产生的第三方问题或管理失误，Snowflake 概不负责。

例如，如果密钥管理服务出现问题导致密钥不可用，您的数据操作将会受到影响。这些问题必须由您和密钥管理服务的支持团队来解决。同样，如果密钥被篡改或破坏，您的 Snowflake 账户中的所有现有数据将不可读取，直至密钥恢复。