了解 Snowflake 中的加密密钥管理

本主题提供与 Snowflake 管理的密钥和客户管理的密钥相关的概念。

本主题内容:

概述

Snowflake 管理数据加密密钥以保护客户数据。这种管理可以自动进行,无需客户干预。

客户还可以使用托管其 Snowflake 账户的云平台中的密钥管理服务来维护自己的额外加密密钥。

Snowflake 管理的密钥

默认情况下,所有 Snowflake 客户数据都经过加密。Snowflake 使用强 AES 加密和基于云提供商托管的硬件安全模块的分层密钥模型。

Snowflake 服务会定期自动轮换密钥,并且客户数据可以定期自动重新加密(“更新密钥”)。客户数据加密和密钥管理无需配置或管理。

分层密钥模型

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

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

  • 根密钥

  • 账户主密钥

  • 表主密钥

  • 文件密钥

每个客户账户都有一个单独的密钥层次结构(账户级、表级和文件级密钥),如下图所示:

Snowflake 的分层密钥模型

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

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

加密密钥轮换

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

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

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

单个表主密钥 (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) `建议<https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final>`_ 对密钥的生命周期进行限制,以提高安全性。

定期密钥更新

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

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

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

备注

对于 Enterprise Edition 账户,具有 ACCOUNTADMIN 角色的用户(即您的账户管理员)可以使用 ALTER ACCOUNTPERIODIC_DATA_REKEYING 参数启用密钥更新:

ALTER ACCOUNT SET ENABLE_TRI_SECRET_AND_REKEY_OPT_OUT_FOR_IMAGE_REPOSITORY = TRUE;

ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = TRUE;
Copy

这将启用 Tri-Secret Secure,但不会对存储在 Snowpark 镜像仓库中的任何图像应用其他安全性。

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

一年后更新单个表主密钥 (TMK)

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

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

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

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

  • 以此类推。

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

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

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

密钥更新对 Time Travel 和故障安全的影响

Time Travel故障安全 保留期不受密钥更新的影响。但是,对于故障安全中的客户数据更新密钥会产生一些额外的存储费用(请参阅下一节)。

密钥更新对存储利用率的影响

Snowflake 客户 需要 支付额外的存储费用,以对更新密钥的客户数据文件进行故障安全保护。对于这些文件,需支付 7 天的故障安全保护费用。

例如,Amazon S3 上具有旧密钥的客户数据文件已经受到故障安全保护,而 Amazon S3 上具有新密钥的客户数据文件也被添加到故障安全中,从而导致第二次收费(仅限 7 天)。

硬件安全模块

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、账户主密钥、表主密钥和文件密钥之间的关系:

基于硬件安全模块的密钥层次结构

客户管理的密钥

客户管理的密钥 (CMK) 是客户在托管客户的 Snowflake 账户的云提供商的密钥管理服务中维护的主加密密钥。以下是各个平台的密钥管理服务:

  • AWS: AWS Key Management Service (KMS) (https://aws.amazon.com/kms/)

  • Google Cloud: Cloud Key Management Service (Cloud KMS) (https://cloud.google.com/kms)

  • Microsoft Azure: Azure Key Vault (https://azure.microsoft.com/en-us/services/key-vault/)

您可以在 Snowflake 账户中调用这些系统函数来获取有关密钥的信息:

Snowflake 支持以下操作:

  • 在您的云服务提供商中配置自动密钥轮换。 配置密钥轮换将创建包含更新的加密材料的同一 CMK 的新版本。您可以使用特定于您的云提供商的密钥轮换功能启用自动密钥轮换,而无需在 Snowflake 中执行任何操作。CMK 轮换后,Snowflake 会使用现有的密钥版本保护现有数据。

    重要

    请勿 删除、更改或撤销任何云服务提供商的旧 CMK 版本的权限。删除轮换密钥可能会导致数据丢失。Snowflake 无法解密使用已删除密钥加密的数据。

    有关在支持 Snowflake 账户的云平台中为客户管理的密钥配置自动密钥轮换的详细信息,请参阅:

    • AWS KMS Snowflake Tri-Secret Secure 使用的客户管理密钥的自动密钥轮换策略 (https://community.snowflake.com/s/article/Does-enabling-AWS-automatic-key-rotation-CMKs-feature-impact-the-snowflake-account-which-has-tri-secret-secure-enabled)

    • Snowflake Tri-Secret Secure 使用的客户管理密钥的 Microsoft Azure 自动密钥轮换策略 (https://community.snowflake.com/s/article/azure-automatic-key-rotation-tss)

    • GCP KMS Snowflake Tri-Secret Secure 使用的客户管理密钥的自动密钥轮换策略 (https://community.snowflake.com/s/article/GCP-KMS-automatic-key-rotation-tri-secret-secure)

  • Manually changing the CMK used by Tri-Secret Secure. Changing your CMK for Tri-Secret Secure requires creating and self-registering a new CMK, and then updating Tri-Secret Secure to use it. Follow the self-registration steps in Tri-Secret Secure and reach out to Snowflake Support to coordinate the key change.

    重要

    Don't revoke access to or delete the current CMK until Snowflake Support confirms it is safe to do so.

有关使用 Snowflake 系统函数更改 CMK 的更多信息,请参阅 Understanding Tri-Secret Secure self-serviceChange the CMK for Tri-Secret Secure

客户管理的密钥的优势

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

控制客户数据访问:

您可以完全控制密钥管理服务中的主密钥,从而完全控制 Snowflake 中的客户数据。您必须释放此密钥才能解密存储在 Snowflake 账户中的数据。

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

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

客户数据生命周期的所有权:

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

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

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

保密性:

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

完整性:

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

可用性:

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

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

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

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

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

语言: 中文