我想在Amazon S3上上传一些图像，并根据用户的订阅，让他们可以查看这些图像的某些部分。阅读完Amazon S3文档后，我提出了以下解决方案：
将我的应用程序中的每个用户分配给Amazon S3中的一个IAM用户，然后定义用户策略或存储桶策略以管理谁有权访问哪些用户。但是有两个缺点：首先，用户或存储桶策略对其大小有限制，并且由于用户和图像的数量非常大，我很可能需要超过该限制。其次，每个AWS账户的IAM用户数量限制为5000，我的应用程序中会有更多用户。
Amazon S3可以定义一些与IAM用户相同的临时安全凭证。我可以要求客户端向我的服务器发出请求，然后使用特殊策略为他们创建临时IAM用户并将他们的凭据传递给他们，然后他们可以使用他们的凭据直接向S3发送请求。有权访问他们的资源。但问题是这些用户将持续15分钟到1小时，因此客户端需要至少每1小时请求我的服务器为他们创建一个临时IAM用户。
由于我想提供一些图像，因此最好使用Amazon Cloudfront和S3的组合尽快提供内容。我还阅读了有关提供私有内容的Cloudfront文档，我发现他们的解决方案是使用签名URL或签名cookie。我将拒绝任何对S3资源的访问，并且cloudfront将是唯一有权从S3读取数据的人，每次用户登录我的应用程序时，我都会向他们发送他们需要签名的凭据URL或我会向他们发送必要的cookie。他们可以使用他们拥有的信息请求所需的资源，这些信息将持续到他们登录我的应用程序。但我有一些安全问题。由于几乎所有关于访问控制的信息都被发送到客户端（例如在cookie中），因此他们可以轻松地修改它并为自己授予更多权限。然而，这是一个很大的问题，但我认为我必须使用cloudfront来减少加载资源时间。
我想知道您认为哪些解决方案比其他解决方案更合理，更好，以及是否有其他解决方案可能使用其他亚马逊网络服务。
答案 0 :(得分：2)
我自己在S3上提供私人内容的方法是将CloudFront与已签名的网址或已签名的Cookie （或有时两者）一起使用。您不应为大量用户使用IAM用户或临时凭证，如您的情况。
您可以在此处详细了解此主题： Serving Private Content through CloudFront
您选择使用签名网址还是签名Cookie取决于以下内容。
Choosing Between Signed URLs and Signed Cookies
CloudFront签名网址和签名Cookie提供相同的基本功能 功能：它们允许您控制谁可以访问您的内容。 如果您想通过CloudFront提供私人内容，那么您就是这样 试图决定是使用签名的URL还是签名的cookie， 请考虑以下事项。
在以下情况下使用签名网址：
- 您想使用RTMP分发。签名的cookie不受支持 对于RTMP发行版。
- 您希望限制对单个文件的访问，例如，为您的应用程序安装下载。
- 您的用户正在使用客户端（例如，自定义HTTP客户端） 不支持cookies。
在以下情况下使用签名的cookie：
- 您希望提供对多个受限文件的访问权限，例如， HLS格式的视频的所有文件或者所有文件 用户＆＃39;网站的区域。
- 您不想改变现状 网址。
至于您的安全问题，CloudFront使用公钥验证签名Cookie中的签名，并确认Cookie未被篡改。如果签名无效，请求将被拒绝。
您还可以遵循this page末尾的指南，以防止滥用已签名的Cookie。