云加密解密：Google Cloud Platform

本文是我们云加密系列的第二篇，概述了 Google Cloud Platform（GCP）提供的云加密服务：何时使用、何时不使用以及重要的使用注意事项。敬请关注本系列后续文章，涵盖其他云服务。

在 Trail of Bits，我们经常遇到使用云提供商加密产品和服务以满足安全目标的产品和服务。然而，一些云提供商的加密工具和服务名称不透明或使用场景不明显。本指南基于 Trail of Bits 广泛的审计经验，深入探讨这些服务之间的差异，并解释重要注意事项，帮助您选择正确的解决方案以增强项目的安全性。

引言

在本文发布时，Google Cloud Platform 的加密产品明显少于 Amazon Web Services，我们在本系列的前一篇文章中讨论过后者。

直观上，产品少可能是好事：需要跟踪的服务和软件更少，用户的复杂性和认知负担最小化。然而，这确实伴随着您的服务或软件成为某种瑞士军刀的风险：在几件事上足够好，但在任何事上都不出色。

我们将探讨 Google Cloud Platform 中的三种加密产品以及 Google 推荐的客户端加密解决方案。

Google Cloud 服务

Cloud KMS

您应该使用 Cloud KMS： 如果您以任何方式使用 Google Cloud Platform。

您可以将 Cloud KMS 视为实际上是三种不同产品的集合，通过一个方便的 API 提供不同级别的保护：

使用软件密钥的 Cloud KMS
Cloud HSM，在 HSM 硬件中执行所有加密操作
Cloud EKM，密钥存储在外部提供商中，适用于需要保持对其加密材料主权的客户

无论您最终使用这三种产品中的哪一种，都可以通过 Google KMS API 使用它。反过来，您可以将您的密钥用于所有其他 GCP 服务，这些服务原本会使用 Cloud KMS 进行密钥管理。

除非另有说明，您几乎肯定不需要 Cloud HSM 或 Cloud EKM。

何时使用 Google Cloud HSM

如果您关心 FIPS 140 验证级别大于 1，那么 Cloud HSM 对您的用例至关重要。否则，您不需要它。

如果您不确定是否关心这一点，请记住，FIPS 140 级别 1 本质上是通过 FedRAMP 向美国政府销售的服务中使用的任何加密模块必须达到的最低标准，并且不会显著影响加密安全性。

有些客户关心级别 1 与级别 3，但如果您正在处理这种情况，您可能会知道。

何时使用 Google Cloud EKM

如果您所在国家的监管机构坚持要求您保持对加密材料的控制，您可以使用 Cloud EKM 满足他们的要求，而无需完全拆除您的云架构。

否则，仅使用带有软件密钥的 Cloud KMS 即可完成任务。

Secret Manager

您应该使用 Google Cloud Secret Manager： 如果您需要管理和轮换服务密码（例如，访问关系数据库）。

您不应该使用 Google Cloud Secret Manager： 如果您想存储您的在线银行密码。

如果您曾经使用过密码管理器，Secret Manager 应该是一个熟悉的体验。它存储您的应用程序在 Google Cloud 环境中运行所需的机密信息——例如数据库密码、API 密钥和其他敏感信息，您真的不应该直接提交到源代码中。

Secret Manager 使用版本控制机制来维护过去凭据的历史记录，这对于在密钥轮换期间避免操作事件非常有用。

Confidential Computing

您应该使用 Confidential Computing： 如果您确定它适合您的威胁模型。

您不应该使用 Confidential Computing： 如果您不确定，甚至没有威胁模型。（Trail of Bits 进行轻量级和传统威胁模型；如果您需要帮助，请联系我们！）

广义上说，Confidential Computing 就像 DRM，但权力动态是颠倒的。

Confidential Computing 旨在让您进行计算，而您的服务提供商不知道您正在运行什么软件或该软件正在处理什么数据。

这不仅仅是一种技术，而是一套不同的工具和技术，致力于实现这一目标。学术研究人员提出的一些技术依赖于同态加密。其他技术依赖于可信执行环境。

Google 在这方面有多项投入，因此我们预计随着新技术的出现，这种情况会发生变化，但他们当前的产品依赖于 AMD SEV 作为可信执行环境。不幸的是，过去几年中针对 AMD SEV 存在侧信道攻击（即 CVE-2021-46744 和 CVE-2023-20575）。

在没有关于您可能构建什么或您试图防范什么威胁的任何上下文的情况下，很难在一篇普遍可用的博客文章中提炼出清晰的指导，但如果我必须在这里说一些简短而精辟的话：谨慎行事并咨询专家。

GCP 的客户端加密

三工具为零信任基础设施炒作，七工具为产品团队设定的无代码，九工具为各种类型的 DBA，一工具为数学极客保护数据流在 Google 云中容器所在之处。

一 Tink 加密所有，一 Tink 用于签名，一 Tink 管理密钥，并确保上下文绑定在 Google 云中容器所在之处。

（向托尔金致歉）

Tink 是 Google 开发的唯一加密库，鼓励 GCP 客户用于 Google 云产品的客户端加密。

Tink 的优点

正如人们所期望的那样，Tink 提供了客户端加密库所需的所有基本功能：Tink 加密和解密数据；签名消息和验证签名；甚至提供用于确定性加密和处理结构化数据的专用实用程序。

但 Tink 还提供了一个 JSON Web Tokens（JWT）模块，成功地忽略了 JOSE 标准的不安全部分。

除了拒绝支持完全不安全的选项（如 alg=none）之外，Tink 的 JWT 库比大多数库更安全的最大原因归结为一个加密工程原则：Tink 中的密钥不仅仅是原始字节字符串。

Tink 强制执行一个原则：加密密钥的身份既是原始字节，也是密钥要用于的算法的参数选择。

作为一个具体示例，基于非对称签名（即 ECDSA）解析 JWT 所需的代码与基于对称消息认证码（即 HMAC）解析 JWT 所需的代码不同。

因此，开发人员很难意外地将任何常见的 JWT 漏洞引入到使用 Tink 的应用程序中。

Tink 可以改进的地方

Tink 目前不包括任何可搜索加密的实用程序。因此，虽然您可以成功使用 Tink 加密 GCP 中的 SQL 记录，但没有简单的方法使用 Tink 搜索客户端加密的数据。

缺乏机制意味着在使用客户端加密与关系数据库时，您面临一个 Catch-22：要么加密给定字段，要么能够在 SQL 查询中使用所述字段值。您不能同时做这两件事。

总结

我们希望这个简要概述能澄清 Google 的一些加密产品，并帮助您为项目选择最佳方案。敬请关注本博客系列的后续文章，涵盖其他云加密服务！

同时，如果您想更彻底地探索这些产品和服务，以评估它们是否适合您的安全目标，请随时联系我们的加密团队。我们定期举行办公时间，持续约一小时，让您与我们的密码学家会面并提出任何问题。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

深入解析 Google 云平台加密服务：选择与安全考量

本文详细解析了 Google Cloud Platform 提供的加密服务，包括 Cloud KMS、Secret Manager 和 Confidential Computing，以及客户端加密库 Tink 的使用场景与安全优势，帮助开发者根据项目需求选择合适的安全解决方案。