amazon-web-services - API 网关授权和注销(性能/安全考虑)

Question

我正在使用 Cognito、API 网关和授权器。授权者被配置为缓存 5 分钟以提高性能。我觉得这是一个很好的功能。

我知道授权器是将授权逻辑保存在一个地方的好方法，应用程序可以假定用户已经获得授权。但是，我有疑问。

渗透测试报告建议，一旦登出， token 就不能再使用了。所以这意味着为了安全，我不应该启用授权缓存？这也意味着所有经过身份验证的 API 都将通过一个 lambda 授权方的开销......

同样从编码的角度来看，使用难以端到端测试的授权器真的是个好主意吗？我可以将 lambda 函数作为一个单元进行测试。但对我来说更重要的是它们附加到正确的 API。目前我看不出有什么方法可以让我轻松地进行测试。

另一个问题是查看代码，我无法再轻松判断需要什么授权......我必须查看应该附加的授权方(例如 CloudFormation)，然后是 lambda 代码本身。

使用授权器有好处吗？或者实际上最好的做法是什么？

Answer 1

For security, I should not enable authorizer caching

如果您有严格的安全要求(例如，一旦 token 失效，所有请求都应该失败)您将需要关闭授权缓存。从 https://forums.aws.amazon.com/thread.jspa?messageID=703917 中查看此答案:

Currently there is only one TTL for the authorizer cache, so in the scenario you presented API Gateway will continue to return the same cached policy (generating a 200) for the cache TTL regardless of whether the token may be expired or not. You can tune your cache TTL down to level you feel comfortable with, but this is set at level of the authorizer, not on a per token basis.

We are already considering updates to the custom authorizer features and will definitely consider your feedback and use case as we iterate on the feature.

It also means all authenticated APIs will have a go through one overhead of a Lambda authorizer...

确实如此。然而，在实践中，我的团队在 Lambda 冷启动和 ENI 附件方面比其他任何性能方面都更加努力，因此我们的授权者增加的开销最终可以忽略不计。这并不意味着性能损失不可衡量，但与将授权代码直接放在 Lambda 中相比，它最终增加了毫秒级的延迟，这种权衡在我们的应用程序中是有意义的。与之形成鲜明对比的是，Lambda 冷启动通常需要长达 30 秒。

Also from a coding perspective, is it really a good idea to use authorizers which are hard to test end to end?

在许多基于面向服务的架构构建的应用程序中，您将拥有跨多个代码库的“端到端”场景，并且只能在已部署的环境中进行测试。此级别的测试显然很昂贵，因此您应该避免测试可能被较低级别(单元、集成等)测试覆盖的功能。然而，测试应用程序的内聚性仍然非常重要，而且您需要此类测试这一事实并不一定会严重损害 SOA。

I could test the Lambda function as a unit. But what's more important to me is they are attached to the correct APIs. There's currently no way I see that allows me to test this easily.

如果您正在考虑多个授权者，测试是否连接了正确的授权者的一种方法是让每个授权者将指纹向下传递到端点。然后您可以 ping 您的端点并让它们返回健康检查状态。

例如，

[ HTTP Request ] -> [ API Gateway ] -> [ Authorizer 1 ] -> [ Lambda 1 ] -> [ HTTP Response ]
                                       Payload:                            Payload:
                                       user identity                       status: ok
                                       authorizer: 1                       authorizer: 1

在实践中，我的团队每项服务有一个授权者，这使得测试此配置变得非关键(我们只需要确保本应受到保护的端点是安全的)。

Another problem is. looking at the code, I can no longer tell what authorization is required easily... I have to look through which authorizer is supposed to be attached (eg. CloudFormation) then the Lambda code itself.

是的，这是真的，并且难以在本地测试的高度分离环境的性质是我的团队在使用 AWS 基础设施时遇到的最大问题之一。但是，我认为在处理 AWS 空间时，这主要是一个学习曲线。整个开发社区对于 AWS 公开的许多概念(例如基础设施即代码或微服务)仍然相对较新，因此与传统的单体开发相比，我们在这个领域缺乏工具和教育。

这是适合您应用的解决方案吗？如果没有深入分析，我无法告诉你。更广泛的社区中有很多意见都是双向的，但我想向您指出这篇文章，尤其是列出的谬论:Microservices – Please, don’t .使用微服务是因为您已经为它们开发了可靠的用例，而不仅仅是因为它们是计算机科学中的最新流行语。

Is there a good thing from using Authorizers? Or what's the best practice with this actually?

我的团队使用 AuthN 的授权方(通过自定义身份验证服务)，并在单独的 Lambda 层处理 AuthZ(通过不同的自定义身份验证服务)。这对我们的架构非常有益，因为它允许我们将通常极其复杂的特定于对象的安全规则与简单的身份问题隔离开来。您的用例可能有所不同，我当然不会声称知道最佳实践。但是，我会向您指出 API Gateway Authorizer examples有关如何将此服务集成到您的应用程序的更多想法。

祝你好运。