云加密技术揭秘：Google云平台

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

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

引言

截至本文发布时，Google云平台的加密产品明显少于亚马逊网络服务（我们在本系列前一篇文章中讨论过）。直觉上，产品少可能是好事：需要跟踪的服务和软件越少，用户的复杂性和认知负担就越小。然而，这也带来风险，即您的服务或软件可能变成一种瑞士军刀：多项功能都够用，但没有一项是顶尖的。

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

Google云服务

Cloud KMS

您应该使用Cloud KMS的情况：如果您以任何方式使用Google云平台。

您可以将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云环境中运行所需的机密信息，例如数据库密码、API密钥和其他您真的不应该直接提交到源代码中的敏感信息。

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

机密计算

您应该使用机密计算的情况：如果您确定它适合您的威胁模型。

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

广义上说，机密计算就像DRM，只不过权力动态是颠倒的。

机密计算旨在让您能够在服务提供商不知道您运行什么软件或该软件处理什么数据的情况下进行计算。

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

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令牌（JWT）模块，成功忽略了JOSE标准的不安全部分。

除了拒绝支持完全 unsafe 的选项（如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