云加密揭秘：亚马逊云服务

本文是云加密系列文章的一部分，重点介绍亚马逊云服务（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

适用场景：当行业或政府法规要求您为特定用例直接使用HSM时。否则应优先考虑KMS。

不适用场景：如果KMS可替代使用。

CloudHSM本质上是AWS在云环境中提供的HSM。如果您的架构没有法律要求直接使用HSM，可以完全跳过CloudHSM。

AWS KMS

适用场景：任何使用亚马逊服务（包括非加密服务）或客户端库的情况。

不适用场景：加密或解密大型消息（应使用KMS进行密钥包装）。

AWS KMS可视为经过FIPS验证的HSM的易用性封装。它提供数字签名、对称HMAC以及密钥永不离开HSM的加密/解密功能。但KMS加密旨在用于信封加密设置中的密钥包装，而非实际数据的加密/解密。

KMS一个重要但未充分强调的功能是加密上下文（Encryption Context）。当您在加密调用中向KMS传递加密上下文时，它会在CloudTrail中记录该上下文，且后续解密调用必须提供完全相同的加密上下文才能生效。

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

以上问题均可通过使用AWS客户端软件解决，下文将讨论。

近期KMS新增了外部密钥库支持，KMS会调用您数据中心的HSM作为其正常操作的一部分。此功能旨在满足某些国家的数据主权要求，仅应在法律要求时使用。您通过此功能获得合规性，但会牺牲持久性、可用性和性能。通常得不偿失。

AWS客户端加密软件

AWS加密SDK

适用场景：在云应用中加密任意长度的密钥。

不适用场景：如果需加密关系型或NoSQL数据库数据，应改用AWS数据库加密SDK。

AWS加密SDK是用于云中运行的应用程序的通用加密工具。如果您仅需“封装KMS以加密文本块”的基本功能，其特性可简单至此；若需更灵活方案，它支持分层密钥管理，以在多密钥环设置中最小化对KMS的网络调用。

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

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

• 由于KMS在CloudTrail中记录加密上下文，服务运营商可追踪消息在集群中的流转而无需解密。
• 由于每个ECDSA密钥对仅使用一次后即丢弃私钥，可保证给定消息在创建后从未被篡改，即使使用多个密钥环。

AWS加密SDK用户需确保指定包装密钥而非使用KMS发现（Discovery）模式。发现模式仅为向后兼容而存在，属于反模式。

如果不使用分层密钥环，建议关注数据密钥缓存功能，以减少KMS调用次数并降低云应用延迟。

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可视为类似1Password的密码管理器，但面向云应用。与面向消费者的密码管理器不同，Secrets Manager的安全模型基于AWS凭证而非主密码或其他客户端管理密钥。此外，您的密钥会进行版本控制以防轮换期间的操作问题。

Secrets Manager可配置为定期自动轮换部分AWS密码。

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

AWS加密计算清洁室（C3R）

适用场景：若您与多个行业伙伴希望计算共有数据库条目数量，而不相互暴露各自独有条目内容。

不适用场景：非上述情况。

C3R使用服务器辅助的私有集合交集（Private Set Intersection），允许多个参与者计算共有记录数，而不相互暴露无关记录。

例如：若两个或多个医疗机构希望确定是否有共同患者（如因各自提供的服务单独安全但联合使用临床不安全），可使用C3R计算私有集合交集，且不侵犯仅由单一机构服务的患者隐私。

C3R主要缺点在于适用场景较为狭窄。

总结

希望本篇概述能澄清部分AWS加密产品，助您为项目选择最佳方案。请持续关注本系列后续文章，我们将探讨其他云加密服务！

同时，若需深入评估这些产品和服务是否适合您的安全目标，欢迎联系我们的加密团队。我们定期举办办公时间，安排约一小时供您与密码学家会面并提问。

若喜欢本文，请分享至： Twitter LinkedIn GitHub Mastodon Hacker News