API网关授权者和注销(性能/安全注意事项)

Jie*_*eng 1 amazon-web-services aws-lambda aws-api-gateway serverless

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

我知道授权者是将身份验证逻辑放在一个地方的好方法,并且应用程序可以假定用户已被授权。但是,我对此表示怀疑。

渗透测试报告建议,一旦注销,令牌就不能使用。因此,为了安全起见,我不应该启用授权者缓存吗?这也意味着所有经过身份验证的API都要经过一个lambda授权者的开销...

同样从编码的角度来看,使用很难进行端到端测试的授权者真的是一个好主意吗?我可以将lambda函数作为一个单元进行测试。但是对我来说更重要的是它们已连接到正确的API。我目前无法看到可以轻松测试的方法。

另一个问题是查看代码,我再也无法轻易分辨出需要什么授权……我必须查看应该附加哪个授权者(例如CloudFormation),然后查看lambda代码本身。

使用授权者有什么好处吗?或实际上最佳做法是什么?

Min*_*gar 5

为了安全起见,我不应该启用授权者缓存

如果您有严格的安全要求(例如,一旦令牌失效,所有请求都将失败),需要关闭授权者缓存。请参阅https://forums.aws.amazon.com/thread.jspa?messageID=703917的答案:

当前,授权者缓存只有一个TTL,因此在您呈现的方案中,API令牌将继续为缓存TTL返回相同的缓存策略(生成200),而不考虑令牌是否已过期。您可以将缓存TTL调低到自己喜欢的级别,但这是在授权者级别设置的,而不是基于每个令牌设置的。

我们已经在考虑自定义授权者功能的更新,并且在我们迭代该功能时,一定会考虑您的反馈和用例。


这也意味着所有经过身份验证的API都要经过Lambda授权者的一项开销...

确实如此。但是,实际上,我的团队在Lambda冷启动和ENI附加方面比在性能方面要付出更多的努力,因此授权人添加的开销最终可以忽略不计。这并不意味着性能下降是无法衡量的,但是与直接将授权者代码放置在Lambda中相比,最终导致延迟增加了毫秒级,这在我们的应用程序中很有意义。与之形成鲜明对比的是,Lambda冷启动通常可能需要30秒钟。


同样从编码的角度来看,使用很难进行端到端测试的授权者真的是一个好主意吗?

在许多基于面向服务的体系结构上构建的应用程序中,您将拥有跨多个代码库且只能在已部署环境中进行测试的“端到端”方案。此级别的测试显然是昂贵的,因此您应避免使用较低级别(单元,集成等)测试可以涵盖的测试功能。但是,测试应用程序的内聚性仍然非常重要,并且您将需要进行此类测试的事实并不一定会严重损害SOA。


我可以将Lambda函数作为一个单元进行测试。但是对我来说更重要的是它们已连接到正确的API。我目前无法看到可以轻松测试的方法。

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

例如,

[ HTTP Request ] -> [ API Gateway ] -> [ Authorizer 1 ] -> [ Lambda 1 ] -> [ HTTP Response ]
                                       Payload:                            Payload:
                                       user identity                       status: ok
                                       authorizer: 1                       authorizer: 1
Run Code Online (Sandbox Code Playgroud)

实际上,我的团队每个服务只有一个授权者,这使得对该配置的测试变得不重要(我们只需要确保应该保护的端点是安全的)即可。


另一个问题是。查看代码,我再也无法轻易分辨出需要什么授权...我必须查看应该附加哪个授权者(例如CloudFormation),然后查看Lambda代码本身。

是的,这是事实,而高度分离的环境的本质却很难在本地进行测试,这是我的团队在使用AWS基础设施时最大的困扰之一。但是,我认为在处理AWS空间时,这主要是学习曲线。对于AWS公开的许多概念(例如代码或微服务的基础结构),整个开发社区还是一个相对较新的概念,因此与传统的整体开发相比,我们在该领域缺乏工具和教育。

这是适合您的应用程序的正确解决方案吗?没有深入的分析,我无法告诉您。在更广泛的社区中,有很多观点都是双向的,但是我想向您指出这篇文章,特别是对于列出的谬论:微服务–请不要。使用微服务是因为您已经为它们开发了可靠的用例,而不必仅仅因为它们是计算机科学中的最新流行语。


使用授权者有什么好处吗?或实际上最佳做法是什么?

我的团队使用AuthN的授权者(通过自定义身份验证服务),并在各个Lambda层上(通过不同的自定义身份验证服务)处理AuthZ。这对我们的体系结构非常有益,因为它使我们能够将通常极其复杂的特定于对象的安全规则与简单的身份问题隔离开来。您的用例可能有所不同,我当然不会声称知道最佳实践。但是,我将为您提供API Gateway Authorizer示例,以获取有关如何将该服务集成到应用程序中的更多想法。


祝你好运。