我想我可以通过添加Principal来做到这一点:arn:iam:cloudfront ....
但这允许直接S3访问,而不是HTTP端点访问。
当我将Cloudfront配置为直接提供S3存储桶时,它不会显示子目录index.htmls。为了访问mysite.com/blog/,我必须输入mysite.com/blog/index.html
出于这个原因,我必须使用S3的HTTP端点,就好像该站点不在S3上而是在Apache服务器上。
现在我不能通过arn限制访问:iam:cloudfront。由于Cloudfront成为另一个Web爬网程序,因此S3成为另一个Web服务器。
他们建议添加自定义标头,以便服务器了解它是云端。但S3不支持自定义标头。
将用户代理限制为CloudFront,将Principal限制为AWS:*做了一个简短的工作,但它不会阻止UserAgent欺骗。
我该如何解决这个问题?
答案 0 :(得分:3)
根本不要将源配置为S3 - 将其配置为自定义源,然后使用存储桶的网站端点主机名作为源服务器主机名。
此时,您应该能够配置CloudFront将发送到原点的Origin Custom Header - 恰好是存储桶的网站端点。
User-Agent
不在list of custom headers that CloudFront won't forward上,因此您应该能够在从CloudFront到S3的请求中发送自定义用户代理字符串 - 有点像静态密码 - 并配置您的存储桶只允许该自定义用户代理。
理论上它仍然可以被欺骗,但由于它是一个随机字符串,所以没有人知道除了你,S3和CloudFront之外的其他值,并且对某人来说欺骗未知值会非常棘手,特别是因为S3简单地拒绝访问,没有解释。
答案 1 :(得分:1)
你试过这种方法吗?
确保您的用户仅使用CloudFront访问您的对象 无论URL是否已签名,URL都会执行以下操作 任务:
创建原始访问标识,这是一个特殊的CloudFront用户, 并将原始访问标识与您的分发相关联。 (对于 Web分发,您将原始访问标识与 起源,因此您可以保护所有或部分Amazon S3 内容。)您还可以创建原始访问标识并将其添加到 创建分发时的分发。
更改Amazon S3存储桶或其上的权限 存储桶中的对象,因此只读取了原始访问标识 许可(或读取和下载权限)。当您的用户访问时 您的Amazon S3对象通过CloudFront,即CloudFront原点 访问标识获取用户的对象'代表。如果您的用户 通过使用Amazon S3 URL直接请求对象,它们被拒绝 访问。原始访问标识具有访问对象的权限 您的Amazon S3存储桶,但用户不知道。