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

Question

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

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

令我困惑的是：我对CloudFront Origin Access Identities和Signed CloudFront Urls之间的关系（如果有的话）很模糊。

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

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

Answer 1

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

此处使用的“origin”一词的含义不应与其他上下文中使用的“origin”一词混淆，例如CORS，其中“origin”是指允许访问内容的站点。

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

一旦CloudFront将签名URL验证为与您的AWS账户（或您指定为可信签署者的另一个账户）关联的CloudFront签名密钥匹配，就会使用原始访问身份授予的任何权限从存储桶中获取对象。斗。

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

基本上，是的。

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

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

签名URL不仅在其到期之前有效，而且如果使用custom policy，也可以选择性地限制对具有与策略文档中包含的IP地址相同的人的访问。签名后，对URL的任何更改（包括策略声明）都会使整个URL无法使用。

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

Answer 2

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

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