保护 Amazon S3 中的私有数据

Question

我想在 Amazon S3 上上传一些图像，并根据用户的订阅授予他们查看这些图像的某些部分的权限。在阅读了 Amazon S3 文档后，我提出了以下解决方案：

1. 将我的应用程序中的每个用户分配给 Amazon S3 中的一个 IAM 用户，然后定义用户策略或存储桶策略来管理谁可以访问什么。但是有两个缺点：首先，用户或存储桶策略对其大小有限制，并且由于用户和图像的数量非常大，我很可能需要超过该限制。其次，每个 AWS 账户的 IAM 用户数限制为 5000，我的应用程序中会有更多用户。

2. Amazon S3 可以定义一些与 IAM 用户相同的临时安全凭证。我可以要求客户端向我的服务器发出请求，然后我使用特殊策略为他们创建一个临时 IAM 用户并将他们的凭证传递给他们，然后他们可以使用他们的凭证直接向 S3 发送请求并可以访问他们的资源。但问题是这些用户会持续 15 分钟到 1 小时，因此客户端需要至少每 1 小时请求一次我的服务器才能为他们创建一个临时 IAM 用户。

3. 由于我想提供一些图像，因此最好结合使用 Amazon Cloudfront 和 S3 来尽快提供内容。我还阅读了用于提供私有内容的 Cloudfront 文档，我发现他们的解决方案是使用签名 URL 或签名 cookie。我将拒绝对 S3 资源的任何访问，而云端将是唯一有权从 S3 读取数据的人，并且每次用户登录我的应用程序时，我都会向他们发送他们需要进行签名的凭据URL 或者我会向他们发送必要的 cookie。他们可以使用他们拥有的信息请求所需的资源，并且这些信息将持续到他们登录到我的应用程序。但我有一些安全问题。由于几乎所有有关访问控制的信息都发送给客户端（例如在 cookie 中），因此他们可以轻松地对其进行修改并授予自己更多权限。然而，这是一个大问题，但我认为我必须使用 cloudfront 来减少加载资源时间。

我想知道您认为哪些解决方案比其他解决方案更合理和更好，以及是否有其他解决方案可能使用其他亚马逊网络服务。

Answer 1

我自己在 S3 上提供私有内容的方法是将 CloudFront 与 signed URLs 或 signed cookie（或有时同时使用两者）结合使用。您不应该对大量用户使用 IAM 用户或临时凭证，就像您的情况一样。

您可以在此处阅读有关此主题的更多信息： Serving Private Content through CloudFront

您选择使用签名 URL 还是签名 cookie 取决于以下因素。

Choosing Between Signed URLs and Signed Cookies

CloudFront 签名 URL 和签名 cookie 提供相同的基本 功能：它们允许您控制谁可以访问您的内容。 如果您想通过 CloudFront 提供私有内容并且您正在 试图决定是使用签名 URL 还是签名 cookie， 考虑以下。

在以下情况下使用签名 URL：

• 您想使用 RTMP 分发。不支持签名的 cookie 用于 RTMP 分发。
• 您希望限制对单个文件的访问，例如，您的应用程序的安装下载。
• 您的用户正在使用的客户端（例如，自定义 HTTP 客户端） 不支持 cookie。

在以下情况下使用签名 cookie：

• 您希望提供对多个受限文件的访问权限，例如， HLS 格式的视频的所有文件或 网站的订阅者区域。
• 您不想更改当前的 网址。

出于您的安全考虑，CloudFront 使用公钥来验证签名 cookie 中的签名并确认 cookie 未被篡改。如果签名无效，则请求被拒绝。

您还可以遵循this page 末尾的指南，以防止滥用已签名的 cookie。