监控、优化和保护 Amazon Cognito 机器间授权

关键要点

Amazon Cognito 是一个针对开发者和安全的重要 客户身份和访问管理 (CIAM) 服务，简化了用户注册、登录和访问控制的过程。使用 OAuth 20 客户端凭证授权，可以实现机器间M2M授权，支持对 API 和工作负载的安全访问。应当对访问令牌的发放进行监控和优化，同时保障安全最佳实践。通过使用 Amazon API Gateway 集成和令牌缓存，可以减轻访问令牌请求的负担，提升性能和安全性。

在这篇文章中，我们将探讨监控、优化和保护 Amazon Cognito M2M 授权的策略。我们将首先学习一些有效的监控技术，以跟踪使用情况，然后深入理解使用 API Gateway 和令牌缓存的优化策略。最后，我们将介绍安全最佳实践和建议，以提升 M2M 用例的安全性。

机器间授权

Amazon Cognito 使用 OAuth 20 客户端凭证授权 来处理 M2M 授权。Cognito 用户池可以发布客户端 ID 和客户端密钥，从而允许服务请求 JSON Web 令牌 (JWT) 兼容的访问令牌，以访问受保护的资源。下图示意了应用客户端如何使用客户端凭证授权流请求访问令牌的过程。

客户端凭证授权流步骤：

应用客户端向 Amazon Cognito 用户池 /token 端点发送一个 HTTP POST 请求，该请求包含客户端 ID 和客户端密钥的授权标头，以及授权类型、客户端 ID 和范围的请求参数。Cognito 验证请求后，将返回一个 JWT 兼容的访问令牌。客户端可以使用 Cognito 发放的访问令牌请求下游资源服务器。资源服务器从 Cognito 用户池获取一个 JSON Web 密钥集 (JWKS)，其包含用户池的公钥，用于验证令牌签名。资源服务器使用公钥验证访问令牌的签名是否有效证明令牌未被篡改，同时确认令牌未过期并包含所需的声明和范围。资源服务器应使用 awsjwtverify 库 来验证访问令牌的有效性。

你可以在如何使用 OAuth 20 在 Amazon Cognito 中学习不同的授权中了解更多关于 Amazon Cognito 对 OAuth 20 客户端凭证授权的支持和其他认证流程的信息。

接下来，让我们深入探讨围绕 M2M 授权的监控、优化和安全注意事项。

监控使用情况和成本

2024年5月，Amazon Cognito 引入了 M2M 授权计费，以支持持续增长和扩展 M2M 功能。5月9日之前使用 Cognito 进行 M2M 的客户账户将于2025年5月9日前免于 M2M 计费有关详细信息，请参见 Amazon Cognito 引入 M2M 使用的分级计费。

为了更好地了解你现有的 Amazon Cognito 使用情况，你可以使用 成本和使用仪表板操作解决方案 (CUDOS) 的 安全 标签。

此仪表板是 Cloud Intelligence Dashboard 的一部分，这是一个开放源代码框架，为 AWS 客户提供可操作的洞察力和优化机会。如下图所示，CUDOS 仪表板的安全标签提供可视化效果，展示了各种使用类型的 Amazon Cognito 成本和支出，以及在免除期后的 M2M 应用客户端和令牌请求的预期费用，按日颗粒度统计。

同时，你还可以查看每个 AWS 账户每种使用类型的月度支出，如下图所示。

加速器ios

此外，你可以查看贡献成本的用户池的资源 ID 的使用情况和支出，如下图所示。这样的资源级颗粒度使你能够识别出支出最多的用户池，从而优先安排使用和成本管理的工作。有关此仪表板的 交互式演示 可供使用。更多信息请参见 Cloud Intelligence Dashboards。

除了使用 CUDOS 仪表板来理解 Cognito M2M 的使用情况和费用外，你还可以请求详细的使用情况，以便于到应用客户端级别的分析。这可以包括每个应用客户端成功请求的访问令牌数量及最后一次使用该客户端发放令牌的时间。为了了解详细的应用客户端使用情况，需要确保令牌请求包括 clientid 请求查询参数。这样会导致一个包含客户端 ID 的 AWS CloudTrail 日志事件，该事件与客户端凭证令牌请求相关联，如下图所示。

你还可以使用 Amazon CloudWatch 日志组捕获并存储 CloudTrail 日志，以便进行更长时间的保留和分析。然后，使用 CloudWatch Logs Insights，你可以使用以下示例查询收集应用客户端的使用情况。

sqlfields additionalEventDatauserPoolId as userpoolid additionalEventDatarequestParametersclientid0 as clientid eventName additionalEventDataresponseParametersstatus filter additionalEventDatarequestParametersgranttype0=clientcredentials and eventName=TokenPOST and additionalEventDataresponseParametersstatus=200 stats count() as count latest(eventTime) as lastused by userpoolid clientid sort count desc

下面展示了上述 CloudWatch Logs Insights 查询的示例结果。结果包括 userpoolid、clientid、count 和 lastused 列。成功的令牌请求总数按用户池和客户端 ID 分组，显示在 count 列中，而最后一次成功发放访问令牌的时间显示在 lastused 列中。

优化令牌请求

现在你知道如何更好地监控 Amazon Cognito 的使用情况和成本，接下来我们深入讨论如何优化令牌请求的使用。对于 M2M，建议客户端使用机制来本地缓存访问令牌以进行授权。这样可以减少客户端请求新访问令牌的需求，直到先前发放的令牌不再有效。然而，客户端运行的环境可能由外部第三方托管，或者属于不同的团队，作为资源所有者，你将无法控制此第三方是否在客户端实现令牌缓存。如果面临这种情形，您可以使用 HTTP 代理集成 来通过 API Gateway 缓存访问令牌。由于 M2M 使用场景遵循 OAuth 20 规范的客户端凭证授权流，因此你的用户池的 /token 端点将与 API Gateway 代理集成进行配置。此代理集成就是可以使用的 API Gateway 中的缓存。通过缓存，你可以减少向用户池 /token 端点发出的令牌请求数量，并改善客户端在响应中接收缓存令牌的延迟。缓存的优点还包括成本优化、性能效率提升、更高的可用性和自定义域灵活性。

解决方案概述

解决方案如图 7 所示包括以下步骤：

客户端向 API Gateway REST API 发送一个 HTTP POST 请求。API Gateway 方法请求将 scope URL 查询字符串参数和 Authorization HTTP 请求标头缓存为缓存键。集成请求配置为代理到 Amazon Cognito 用户池的 /oauth2/token 端点。Cognito 验证请求，确保客户端 ID 和客户端密钥在授权标头中是正确的，并且提供了有效的客户端 ID 查询字符串参数，且客户端被授权访问请求的范围。如果请求有效，Cognito 将通过集成响应返回访问令牌。开启缓存后，HTTP 集成Cognito 令牌端点的响应会在指定的生存时间 (TTL) 内被缓存。网关的方法响应会将访问令牌返回给客户端。随后的令牌请求在剩余缓存 TTL 内，会直接返回缓存的访问令牌，使用授权标头和范围作为缓存键。

要设置令牌缓存，请遵循 管理用户池令牌到期和缓存的步骤。在通过 API Gateway 代理集成返回有效的令牌请求并缓存后，随后的请求，只要与缓存键授权标头和范围参数匹配，将返回相同的访问令牌，直到缓存的令牌 TTL 到期。建议将缓存的 TTL 设置为稍低于 Amazon Cognito 发放的访问令牌的 TTL。例如，如果你的安全策略要求访问令牌有效期为1小时，那么将页缓存 TTL 设置为略低于 1 小时的几分钟。同时，了解理想的缓存容量对于你的使用场景也很重要。缓存容量会影响网关内缓存实例的 CPU、内存和网络带宽，从而可能影响缓存的性能。有关更多信息，请参见 启用 Amazon API Gateway 缓存。有关如何确定理想缓存容量的信息，请参见 如何选择最佳的 Amazon API Gateway 缓存容量以避免达到速率限制？。接下来让我们探讨一些安全最佳实践和考虑事项，以提升 M2M 使用案例的安全性。

安全最佳实践

现在你知道如何监控 Amazon Cognito M2M 的使用情况和成本，以及如何优化访问令牌请求，接下来让我们复习一些安全最佳实践和注意事项。使用 OAuth 20 客户端凭证授权进行 M2M 授权可以帮助保护你的 API。关键因素之一是客户端连接到资源服务器所使用的访问令牌是临时的，并且具有时间限制。客户端在先前的令牌过期后必须获得新的访问令牌，因此无需发布持久有效的凭据，避免直接在客户端和资源服务器之间使用。客户端 ID 和客户端密钥保存在客户端中，并且仅在客户端与 Amazon Cognito 用户池之间请求访问令牌时使用。

使用 AWS Secrets Manager

如果工作负载运行在 AWS 上，请使用 AWS Secrets Manager，这样你就不必担心把凭据硬编码到工作负载和应用程序中。如果工作负载在本地或通过其他提供商运行，那么请使用类似的秘密库或特权访问管理解决方案来存放工作负载凭据。工作负载在运行时应只获取凭据以进行身份验证。

使用 AWS WAF

使用 AWS WAF 保护你的 Amazon Cognito 用户池端点是一个安全最佳实践。这可以帮助保护你的用户池免受不必要的 HTTP 网络请求，选择性地将非机密头部、请求体、查询参数和其他请求组件转发到与用户池关联的 AWS WAF 网络访问控制列表 (ACL)。通过使用 AWS WAF，你还可以为你的用户池添加托管规则组，例如 AWS 托管的 Bot Control 规则组，以防止自动化机器人消耗过多资源、导致停机或进行恶意活动。更多关于如何 将 AWS WAF Web ACL 与 Cognito 用户池关联 的信息。

始终验证令牌

获取访问令牌后，重要的是确保客户端被授权访问所请求的资源。如果资源使用的是 API Gateway 和内置的 Amazon Cognito 授权者，那么令牌的完整性、签名和到期会进行检查和验证。然而，如果你需要通过 API Gateway 进行更自定义的授权决策，可以使用 AWS Lambda 授权者，同时利用 awsjwtverify 库。这样，你可以验证 JWT 令牌的签名是否有效，确保令牌未过期，并且必需和预期的声明包括必要的范围是存在的。要进行更精细的授权决策，可以考虑与资源服务器或甚至在 Lambda 授权者 中使用 Amazon Verified Permissions。如果资源服务器是外部系统例如不在 AWS 上或一个自定义资源服务器，则需要确保在返回请求的资源之前验证和验证访问令牌是否有效。

在应用客户端级别定义范围

务必要仔细定义并限制每个应用客户端的访问范围，以符合最小权限原则。通过将每个客户端 ID 仅限制于必要的范围，组织可以最小化发放超出所需权限和访问的访问令牌的风险。如果你的用例符合 M2M 多租户的要求，考虑为每个租户创建一个专用应用客户端，并使用为该租户定义的自定义范围。请记住，M2M 的应用客户端数量是一个定价维度，将会产生费用。有关更多信息，请查看 基于自定义范围的多租户最佳实践。

安全考虑事项

如果你使用 API Gateway 作为代理请求和缓存访问令牌，以下是一些安全考虑事项，可以提升 M2M 工作负载的安全性。

仅允许通过 API Gateway 代理发起令牌请求

在你的 API Gateway 代理集成配置完成并进行优化后，并且你为用户池配置了 AWS WAF，可以通过使用白名单，以增加一层安全性，确保只有来自 API Gateway 代理到 Amazon Cognito 用户池的请求被接受。为此，在 POST 方法执行的集成请求中注入自定义 HTTP 头，并在你的网络 ACL 中创建允许规则以查找该特定头。你还需要创建