我们正在开发一个networking应用程序，其中（其他function）用户可以上传文件。 但是，由于存储空间有限，我们无法将这些文件存储在我们的VPS上，因此我们决定使用S3。
主要的问题是我们必须确保用户只能访问他们自己的数据。 所以我们保留数据库中的文件列表，以及有权访问的用户列表。 我们的服务器可以很容易地决定用户是否有权访问文件。 但是如何实际向用户提供文件呢？
我已经考虑过一些可能性，但是其中没有一个似乎是最好的。
这是一个非常简单的方法，速度也很快，但是会导致非常非常非常丑陋和长期的结果。
以下是如何做到这一点 。
这意味着，我们将这些文件公开在S3上进行读取，但是所有文件都存储在难以猜测的命名文件夹中，例如： 24fa0b8ef0ebb6e99c64be8092d3ede20000 。 不过，也许这不是最安全的方法。 即使你永远不会猜到一个文件夹名称，当你知道它（因为你实际上有权访问它），你可以与任何人（任何未经授权的人）分享该链接。
这意味着这些文件不是由S3直接提供的，而是我们的服务器首先安全地读取文件并提供服务。 我们真的不想要这个:)
可以通过“确保”请求来自我们的服务器（您可以设置S3来检查引用者）来改进混淆url解决scheme。 然而，这将是一个非常不可靠的解决scheme，因为不是所有的浏览器发送引用数据，它也可以是伪造的。
从不同的客户端安全地向Amazon S3提供文件的好方法是什么？
这实际上与你的“为我的系统架构”接壤，但是你的四个想法是可变安全性的有趣的案例研究，所以让我们运行你的select，看看他们如何：
引荐者由客户提供。 信任客户端提供的authentication/授权数据几乎没有安全性（我可以声称已经从你期望的我来自哪里发送）。
判决： TERRIBAD的想法 – 绕过小事。
不是一个坏主意，只要你愿意花费带宽来实现，而你的服务器是可靠的。
假设您已经解决了普通服务器/应用程序的安全问题，这是您提供的最安全的选项。
判决：好的解决scheme。 非常安全，但如果带宽是一个因素，可能不是最理想的。
安全通过默默无闻 ？ 真？ 没有。
我甚至不会去分析它。 就是不行。
结论：如果＃4是TERRIBAD这是TERRIWORSE，因为人们甚至不需要通过伪造引用标题的努力。 猜string，赢得所有的数据！
这个选项有一个相当低的吸商。
任何人都可以点击这个URL并且打开这个数据，这是一个安全的no-no，但是你可以通过使链接到期（只要链接的生命期足够短，漏洞窗口很小）来缓解这个问题。
URL过期可能会让一些想要长时间挂在下载链接的用户感到不便，或者没有及时获得链接 – 这是一种用户体验的吸引，但这可能是值得的。
结论 ：不如＃3，但如果带宽是一个主要关切，它肯定比＃4或＃2更好。
鉴于这些选项，我会去＃3 – 通过你自己的前端服务器传递文件，并authentication你的应用程序通常的方式。 假设你的正常安全是相当不错的，从安全的angular度来看这是最好的select。
是的，这意味着更多的带宽使用你的服务器，更多的资源播放中间人 – 但你总是可以收取一点点更多的。
使用Amazon S3预先签名的查询 ，在您进行任何您想要的用户validation后，直接向用户提供S3对象。 此方法会创build一个有时间限制的URL，您可以将其redirect到用户。