• 2026-01-27 13:52:31

在 API 网关中大规模实施客户端证书吊销列表检查

关键要点

在这篇文章中，我们将探讨如何在 API 网关中实现客户端证书的吊销列表CRL检查，以确保安全的双向身份验证。通过结合高效的 AWS 服务及 Lambda 函数，要实现这一目标，我们会遵循一系列具体的实施步骤。以下是主要内容的总结：

为了支持使用亚马逊 API 网关 的双向证书认证 (mTLS)，你需要考虑如何验证客户端证书的吊销状态。在设计过程中，配置你的验证机制以确保应用程序网页的性能和可用性至关重要。

本文将展示一种架构，帮助您在 API 网关上实现针对证书吊销列表的自定义验证检查。你还将学习一些高级的亚马逊简单存储服务 (Amazon S3)和AWS Lambda 技术，以实现更高的性能和可扩展性。

选择合适的证书验证方法

首先要考虑你应该使用证书吊销列表CRL或在线证书状态协议OCSP，前提是你的证书授权机构CA提供此选项。关于这两种选择的详细分析，请参见我之前的博文在 ACM 私有 CA 中选择合适的证书吊销方法。在那篇文章中，我展示了在你的应用程序能够容忍高延迟或由于 TLS 服务与 OCSP 连接失败的情况下，OCSP 是一个不错的选择。然而，如果你在高交易率的环境中依赖于 mTLS 认证，延迟或 OCSP 可达性故障可能会影响应用程序的性能。因此，我们强烈建议验证你的 mTLS 证书的吊销状态。将客户端证书状态与 CRL 验证，这是满足可靠性和降低可预测延迟的正确方法。

使用亚马逊证书管理器私有证书授权中心AWS Private CA配合托管在AWS CloudFront上的 OCSP 响应者可以降低网络和延迟问题的风险，此文主要针对来自任意 CA 的 CRL 解决方案。如果你使用 AWS Private CA 的 OCSP 响应者，建议在你的Lambda 授权器中生成 OCSP 请求。

API 网关的双向认证

API Gateway 的 mTLS 认证需要定义一个信任根，其中包含你的 CA 公钥。在双向 TLS 认证过程中，API Gateway 会自动处理证书验证和协商过程。在认证过程中，API Gateway 验证证书的有效性，包括其是否被信任、日期是否有效以及是否使用支持的算法。如需了解更多关于 API 网关的 mTLS 认证流程的细节，请参阅API 网关文档及相关博客文章。

实施 API 网关的 mTLS 证书验证

在接下来的部分中，我将描述针对 API 网关实现客户端证书验证机制的可扩展架构。此证书的 CRL 验证过程依赖于一个自定义的 Lambda 授权器，负责根据 CRL 验证证书的吊销状态。Lambda 授权器会缓存 CRL 数据，以便优化后续请求的查询时间，同时允许你定义超出 CRL 验证的自定义业务逻辑。

实施机制

本节将描述帮助你在 API 网关的 mTLS 认证过程中创建高性能扩展的实施机制。

API 网关的 mTLS 配置使用 Amazon S3 作为信任根的存储库。本示例实现的设计扩展了 S3 存储桶的使用，以存储 CRL 和签署 CRL 的 CA 公钥。

我们强烈建议维护更新的 CRL，并在数据处理之前验证其签名。如果使用 AWS Private CA，CRL 将在吊销时自动更新，此过程自动化。此外，AWS Private CA 还允许你通过 API 调用检索 CA 的公钥。

我的示例实现架构使用 API Gateway 的Lambda 授权器来验证在 mTLS 认证会话中使用的客户端证书的序列号与发布到 S3 存储桶中的 CRL 的序列号列表。过程中，API Gateway 自定义授权器将读取客户端证书的序列号，读取并验证 CRL 的数字签名，在 CRL 中查找客户端证书的序列号，并基于查找结果返回授权策略。

实现可预测、低延迟性能的机制包括 CRL 预处理和缓存。你的 CRL 是 ASN1 数据结构，解析所需的计算时间相对较高。将 CRL 预处理成简单易解析的数据结构可以降低每次验证所需的计算成本；同时缓存 CRL 将进一步减少验证延迟并改善可预测性。

性能优化

解析和验证 CRL 的过程计算成本高。对于大型 CRL 文件，在每个请求中都在 Lambda 授权器中解析 CRL 可能会导致高延迟和超时。为提高延迟并降低计算成本，本解决方案通过 CRL 预处理和函数级缓存来优化性能。

预处理和生成缓存的 CRL 文件

第一个优化在 S3 接收到新的 CRL 对象时发生。如下图 1 所示，S3 PutObject 事件会调用一个预处理 Lambda，该 Lambda 验证上传 CRL 的签名并解码其 ASN1 格式。预处理 Lambda 函数的输出是包含已吊销证书序列号的列表，形成一种更容易被所选编程语言读取的数据结构，这样你的 Lambda 授权器就无需大量解析原始 CRL。异步处理方式缓解了 CRL 处理对 API Gateway 工作负荷的影响。

在 CRL 中寻找客户端证书

该优化发生在 Lambda 授权器中，授权器检索来自第一步生成的预处理 CRL 数据，并在该数据结构中搜索客户端证书序列号。如果 Lambda 授权器发现客户端的证书序列号在 CRL 中，则授权请求失败，Lambda 授权器生成“拒绝”策略。通过预处理步骤准备的优先读取优化的数据结构进行搜索，这一优化减少了查找时间和计算需求。

函数级缓存

由于预处理，Lambda 授权器代码无需再执行解码原始 CRL 的 ASN1 数据结构的高成本操作；但网络传输延迟依然存在，可能会影响应用程序的性能。

为了改善性能，并作为第三个优化，Lambda 服务保持最近运行函数的运行时环境一段不确定的时间。如果在此期间再次调用该函数，Lambda 函数无需初始化可以立即开始运行。这被称为“温启动”。函数级缓存利用这一温启动将 CRL 数据结构在函数调用之间持久保持在内存中，从而不再每次请求都需要从 S3 下载预处理 CRL 数据结构。

Lambda 容器的温存状态持续时间取决于多个因素，例如使用模式和你的函数处理的并行请求数。如果 API 使用不频繁或使用模式存在波动，使用预配置并发则是另一种可以进一步降低 Lambda 启动时间和温缓存持续时间的技术。虽然预配置并发存在额外费用，但我建议根据你的具体环境评估其收益。你也可以参考专门讨论该主题的博客，调度 AWS Lambda 预配置并发以应对周期性高使用量。

为了验证 Lambda 授权器拥有最新的 CRL 数据结构副本，使用 S3 的 ETag 值来判断对象是否发生变化。预处理 CRL 对象的 ETag 值存储为 Lambda 全局变量，因此其值在相同的运行时环境中保留。当 API Gateway 调用 Lambda 授权器时，函数检查现有全局预处理 CRL 数据结构和 ETag 变量。如果 ETag 变量不存在或其值与 S3 中预处理 CRL 对象的 ETag 不同，则该过程将重新检索读取优化的 CRL。

图 2 演示了该过程流。

总之，通过以下方式将 CRL 查找数据结构持久保留在 Lambda 容器内存中：

图 3 中的示例实现流量图展示了解决方案的整体架构。

解决方案的整体工作流程如下：

示例实现

如果您对本文所描述的架构的示例实现感兴趣，可以在 AWS Samples 公共存储库中找到apigatewaycrlverification。该存储库包括文中提及组件的示例代码、AWS CloudFormation 模板，以及帮助您在开发环境中部署示例的额外图表。

结论

在这篇文章中，我提出了一种验证 API Gateway mTLS 客户端证书与 CRL 之间的设计，支持超大的证书吊销文件。这种方法将帮助您按照最佳安全实践来验证客户端证书，并利用高级 S3 访问及 Lambda 缓存技术来最小化验证所需的时间和延迟。

如果您对本文有任何反馈，请在评论区留言。如果您对本文有问题，请在AWS 安全、身份和合规 rePost上启动新的讨论，或联系 AWS 支持。

Arthur Mnev

Arthur 是 AWS 行业高级安全架构师。他的工作日常与客户合作，设计创新方法以帮助客户推进其计划、改善安全态势并减少云路径中的安全风险。在工作之外，Arthur 喜欢做父亲、滑雪、潜水和克拉夫玛卡。

Venkat Donavalli

Venkat 是 AWS 全球战略合作伙伴的首席解决方案架构师和技术领袖。他帮助战略合作伙伴最大限度地利用 AWS 服务，并制定云战略和架构。

Rafael Cassolato de Meneses

Rafael Cassolato 是一名解决方案架构师，在 IT 领域拥有超过 20 年的经验，拥有计算机科学的学士和硕士学位，并持有 10 个 AWS 认证。专注于迁移和现代化，Rafael 帮助战略 AWS 客户实现其业务目标，解决技术挑战。

标签 亚马逊 API 网关 API 网关 证书吊销 CRL OCSP 安全博客 TLS