博客作者正在寻找一种方法，让Cognito授权的组织用户能够访问特定S3存储桶中的文件。他们考虑了预签名URL和直接通过API流式传输文件，但都有安全性和效率顾虑。作者寻求一种既能确保安全性又能避免过度使用后端资源的解决方案，同时希望URL访问权限基于Cognito用户所属的组织。目前，没有找到完全符合需求的最佳实践。
我正在创建一个Web应用程序，该应用程序需要将S3存储桶中的大文件提供给用户以供下载。我们应用程序中的用户由Cognito授权。我想要一个带有文件的S3存储桶，以使某些Cognito用户只能下载某些文件。从我的研究中，我发现了几种方法。据我所知，这些似乎都不完全适合我的用例。
AWS允许Cognito用户允许S3存储桶。这是如此接近我所需要的，但实际上似乎并不可用。在我们应用程序的安全性方案中，Cognito登录属于组织。每个组织都在后端共享其所有数据。因此，我需要允许数据库定义的组织中的所有登录名都能访问S3存储桶，而不是按名称登录用户。
从某种意义上说，预签名URL似乎是典型的用例，但我认为仍然不是我真正需要的。预先签名的URL将为我提供一个到期URL，供用户下载文件。很好，所以我可以给每个用户一个可能是用户自定义的URL，但是我可以在后端发出多个URL。但是我真的不希望URL过期，我希望它能永远持续下去。这不是什么大问题，因为永久URL可能是API端点，可以重定向到动态创建的预签名URL(可能在一分钟后到期)。但是该URL将允许拥有它的任何人访问。这与我们的安全性模型不符，该模型通过登录将URL限制为Cognito用户。如果该URL通过用户剪切和粘贴或数据包嗅探器发出，则似乎安全性下降了。确定URL已过期，但对于该项目而言似乎并不完全正确。
我考虑过的另一种选择是自己编写代码，方法是使API端点创建可下载的文件流，该端点通过将S3对象也作为文件流访问而创建。它将文件读入内存并将其流式传输给用户。此安全性似乎完全符合我们的需求，因为该API端点当然可以验证Cognito用户的auth令牌。但是，从S3存储桶读取数据到我的后端，然后再读取给用户，这是不必要的网络流量，它可能会变慢，并且在后端过程中可能需要大量内存。
似乎有一个中间人，尽管有正确的用户权限限制，但允许用户直接访问S3存储桶是最好的解决方案。我可以找到以适合我的项目的最佳实践推荐方式完成此任务的任何项目或教程。我认为我的项目有一个非常普遍的用例。有更好的方法吗？
扫一扫
1144
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
