云加密技术解析：亚马逊云服务

本文是云加密系列文章的一部分，概述了亚马逊云服务（AWS）提供的加密服务：何时使用、何时避免使用以及重要注意事项。敬请关注本系列后续文章，涵盖其他云服务。

在Trail of Bits，我们经常遇到利用云提供商加密服务来实现安全目标的产品和服务。然而，一些云提供商的加密工具和服务名称晦涩或使用场景不明确。AWS尤其如此，其大量服务针对多种用例定制，但对于经验有限的开发人员来说可能令人不知所措。本指南基于Trail of Bits广泛的审计经验以及我在AWS担任开发人员的经验，深入探讨这些服务之间的差异，解释重要注意事项，帮助您选择正确的解决方案以增强项目安全性。

引言

云计算提供商提供的加密技术可分为两个有重叠的大类：加密服务和客户端加密软件。在AWS的情况下，两者之间的界限大多清晰。

所谓客户端，是指服务在您的应用程序（客户端）中运行，而不是在相关服务中运行。这并不意味着服务一定在Web浏览器或用户设备上运行。即使客户端在EC2的虚拟机上运行，加密也不在后端服务级别进行，因此是客户端的。

AWS加密服务的一些示例包括密钥管理服务（KMS）和云硬件安全模块（CloudHSM）。另一方面，AWS的客户端加密软件（即工具）包括AWS加密SDK、AWS数据库加密SDK和S3加密客户端。

AWS的一个产品模糊了这两个类别之间的界限：清洁房间加密计算（C3R）：一个紧密集成到AWS清洁房间服务中的客户端工具。另一个是Secrets Manager，它在客户端运行但本身是一项服务。（一些使用加密技术的强大功能，如AWS Nitro，将在未来的博客文章中详细探讨。）

让我们探索一些AWS产品，包括它们最有用的时候以及我们在审计中经常发现的一些尖锐问题。

AWS加密服务

AWS CloudHSM

您想使用CloudHSM的情况： 如果行业或政府法规要求您为特定用例直接使用HSM。否则，优先考虑KMS。

您不想使用CloudHSM的情况： 如果KMS可以接受。

CloudHSM只是您在云环境中可访问的AWS配置的HSM。如果您没有法律要求直接在架构中使用HSM，您可以完全跳过CloudHSM。

AWS KMS

您想使用KMS的情况： 任何时候使用亚马逊的服务（甚至非加密服务）或客户端库。

您不想使用KMS的情况： 用于加密或解密大消息（改用KMS进行密钥包装）。

AWS KMS可以被视为围绕FIPS验证的HSM的可用性包装器。它提供数字签名、对称HMAC以及加密/解密功能，密钥从不离开HSM。然而，KMS加密旨在用于信封加密设置中的密钥包装，而不是用于实际数据的加密或解密。

KMS的一个重要但未充分强调的功能是加密上下文。当您在加密调用期间将加密上下文传递给KMS时，它会在CloudTrail中记录加密上下文，并且只有在后续解密调用中提供相同的加密上下文时，加密数据才有效。

需要注意的是，加密上下文不作为加密数据的一部分存储在KMS中。如果您直接使用KMS，您负责存储和管理这些额外数据。

这两个考虑都可以通过使用AWS的客户端软件来解决，下文将讨论。

最近，KMS添加了对外部密钥存储的支持，其中KMS将调用您数据中心中的HSM作为其正常操作的一部分。此功能存在是为了遵守一些国家的数据主权要求，应仅在法律要求时使用。您通过此功能获得的合规性，会牺牲持久性、可用性和性能。通常不值得这种权衡。

AWS客户端加密软件

AWS加密SDK

您想使用AWS加密SDK的情况： 用于在基于云的应用程序中加密任意长度的秘密。

您不想使用AWS加密SDK的情况： 如果您正在为关系型或NoSQL数据库加密数据。应改用AWS数据库加密SDK。

AWS加密SDK是用于在云中运行的应用程序的通用加密实用程序。如果您只需要“包装KMS以加密文本块”而没有进一步考虑，它的功能集可以如此简单，或者支持分层密钥管理以在多密钥环设置中最小化对KMS的网络调用。

无论您的加密材料如何管理，AWS加密SDK都将传递给KMS的加密上下文存储在加密消息头中，因此您不需要记住单独存储它。

此外，如果您使用包含ECDSA的算法套件，它将为每条消息生成一个临时密钥对，公钥将存储在加密上下文中。这有两个含义：

• 由于加密上下文由KMS记录在CloudTrail中，服务操作员可以在不解密的情况下跟踪消息在其集群中的流动。
• 由于每个ECDSA密钥对仅使用一次然后丢弃密钥，您可以保证给定消息在创建后从未被修改，即使使用了多个密钥环。

AWS加密SDK用户的一个重要考虑是确保指定您的包装密钥而不使用KMS发现。发现是一种仅用于向后兼容的反模式。

如果您不使用分层密钥环，您还需要查看数据密钥缓存以减少KMS调用次数并降低云应用程序中的延迟。

AWS数据库加密SDK

您想使用AWS数据库加密SDK的情况： 如果您在数据库中存储敏感数据，并且希望从不向数据库透露明文。

您不想使用AWS数据库加密SDK的情况： 如果您不这样做。

截至本文撰写时，AWS数据库加密SDK仅适用于Java的DynamoDB。文档暗示未来将支持更多语言和数据库后端。

AWS数据库加密SDK（DB-ESDK）是DynamoDB加密客户端的后继者。尽管它是向后兼容的，但新消息格式提供了显著改进，并且能够使用称为信标（Beacons）的机制对加密字段执行查询，而不向数据库服务透露您的明文。

信标的核心是HMAC函数的截断实例。给定相同的密钥和明文，HMAC是确定性的。如果您将HMAC的输出截断到几位，您可以将查找时间从全表扫描减少到少量可容忍的误报。

使用信标时应格外小心。如果您将它们截得太短，您可能会在误报拒绝上浪费大量资源。如果您截得不够短，访问您加密数据库的攻击者可能能够推断信标之间的关系，进而推断它们计算自的明文值。（请注意，关系泄漏的风险并非信标独有，而是任何允许查询加密数据库的技术共有的。）

AWS根据PRF的生日界限提供规划信标的指导，以确保数据集中误报的健康分布。

免责声明： 我在亚马逊任职期间设计了AWS数据库加密SDK使用的加密技术。

其他库和服务

AWS Secrets Manager

您想使用AWS Secrets Manager的情况： 如果您需要管理和轮换服务密码（例如，访问关系数据库）。

您不想使用AWS Secrets Manager的情况： 如果您想存储您的在线银行密码。

AWS Secrets Manager可以被视为像1Password这样的密码管理器，但用于云应用程序。与面向消费者的密码管理器不同，Secrets Manager的安全模型基于对AWS凭证的访问，而不是主密码或其他客户端管理的秘密。此外，您的秘密是版本化的，以防止轮换期间的操作问题。

Secrets Manager可以配置为定期自动轮换一些AWS密码。

除了数据库凭证，AWS Secrets Manager还可用于API密钥和其他可能被提交到源代码的敏感值。

AWS清洁房间加密计算（C3R）

您想使用AWS C3R的情况： 如果您和几个行业合作伙伴想弄清楚你们有多少数据库条目是共同的，而不向彼此透露你们独家数据库条目的内容。

您不想使用AWS C3R的情况： 如果您不这样做。

C3R使用服务器辅助的私有集合交集，允许多个参与者找出他们有多少共同记录，而不向彼此透露不相关的记录。

例如：如果两个或更多医疗提供者想弄清楚他们是否有任何共同患者（即，因为他们提供的服务在临床上一起不安全，但分开通常是安全的），他们可以使用C3R计算他们私有集合的交集，而不侵犯仅由一个提供者服务的患者的隐私。

C3R的主要缺点是它的用例相当狭窄。

总结

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

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

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