原始访问标识与CloudFront签名网址之间的关系

Question

所以我一直在关注CloudFront和S3的指南，我觉得我仍然缺少Origin Access Identities和CloudFront Signed URL之间关系的核心信息。

我想要什么：用于托管音频片段（长度为几秒）和低分辨率图像的私有CDN。我只希望在特定域（webapp将存在的域）和可能是测试服务器的请求时访问这些文件。因此，我的网络应用可以获取文件，但人们无法通过网络应用访问它们

我对此感到困惑：我对CloudFront Origin Access Identities和Signed CloudFront Urls之间的关系（如果有）感到模糊。

我目前创建了一个私有S3，一个用于我的云端分发的OAI，并通过cloudfront为图像生成了一个烧录的URL。但我不知道这些事情是如何相关的以及它们如何阻止其他人访问CDN文件（如果他们能够进行检查和元素并获得签名的URL）。

重点是确保签名的网址很快过期吗？如果是这样，OAI如何在其中发挥作用？这是在CORS中设置的吗？

Answer 1

原始访问标识是CloudFront内部的实体 可以通过存储桶策略授权访问存储桶中的对象。当CloudFront使用原始访问标识访问存储桶中的内容时，CloudFront会使用OAI的凭据生成签名请求，并将其发送到存储桶以获取内容。观众无法访问此签名。

单词＆＃34; origin＆＃34;的含义这里使用的不应该与＆＃34; origin＆＃34;正如在其他环境中使用的那样，例如CORS，其中＆＃34;起源＆＃34;是指允许访问内容的网站。

原始访问标识与访问仅限于包含特定Origin或Referer标头的请求无关。

CloudFront验证签名的URL与您的AWS账户（或您指定为可信签署者的其他账户）相关联的CloudFront签名密钥匹配时，将使用原始访问标识具有的任何权限从存储桶中获取对象。已被批准。

  

重点是确保签名的网址很快过期吗？

基本上，是的。

通过尝试根据找到链接的站点限制访问来验证和授权请求不是一种可行的安全措施。它可以防止来自其他站点的热链接，但不会阻止任何可以伪造请求标头的人。击败这样的措施是微不足道的。

相比之下，签名URL对计算不可行性非常篡改。

签名网址不仅有效，直到它过期，但如果您使用custom policy，也可以选择限制对策略文档中包含的IP地址相同的人的访问权限。签名后，对URL的任何更改（包括策略声明）都会使整个URL无法使用。

OAI仅与CloudFront签名URL间接关联 - 它们可以单独使用，也可以一起使用 - 但是没有OAI，CloudFront无法证明它有权从您的存储桶请求对象，因此存储桶需要公开，这将破坏CloudFront上签名URL的大部分目的。

Answer 2

添加指向CloudFront域的新CNAME条目。此条目应与CloudFront控制台中“备用域名”中输入的条目匹配。

默认情况下，CloudFront会自动生成域名（例如d3i29vunzqzxrt.cloudfront.net），但您可以定义替代域名。

您也可以保护Cloudfront Serving Private Content through CloudFront