原始访问身份和CloudFront签名的URL之间的关系

Question

因此，我一直在关注CloudFront和S3上的指南，我觉得Im仍然缺少原始访问身份和CloudFront签名URL之间的关系中的核心信息。

我想要的是：一个专用CDN来托管音频片段（长度为几秒钟）和低分辨率图像。我只希望从特定域（Web应用程序将驻留的域）以及测试服务器发出请求时才能访问这些文件。因此，我的Web应用程序可以获取文件，但用户只能通过Webapp才能访问它们

我感到困惑的是：我对CloudFront原始访问身份和签名的CloudFront Urls之间的关系（如果有）感到困惑。

我目前已经创建了一个私有S3，这是我的Cloudfront发行版的OAI，并且已经通过Cloudfront生成了一个指向图像的URL。但是我看不到这些东西是如何关联的，以及它们如何防止他人访问CDN文件（如果他们能够执行检查和元素并获得签名的URL）。

这样做是为了确保签名的URL快速过期？如果是这样，OAI将如何发挥作用？这是在CORS中设置的吗？

Answer 1

原始访问身份是CloudFront内部的一个实体，可以由存储桶策略授权以访问存储桶中的对象。当CloudFront使用原始访问身份访问存储桶中的内容时，CloudFront使用OAI的凭据生成已签名的请求，并将其发送到存储桶以获取内容。查看者无法访问此签名。

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

源访问身份与访问仅限于包含特定Origin或Referer标头的请求无关。

一旦签名的URL被CloudFront验证为与与您的AWS账户（或您指定为受信任签名者的另一个账户）相关联的CloudFront签名密钥匹配，便使用已在其处授予原始访问身份的任何权限从存储桶中提取对象。桶。

这样做是为了确保签名的URL快速过期？

从本质上讲，是的。

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

相比之下，签名的URL在计算不可行的方面具有极强的防篡改性。

如果使用自定义策略，则签名的URL不仅仅在过期之前才有效，而且还可以选择将访问权限限制为具有与策略文档中包含的IP地址相同的IP地址的人员。签名后，对URL的任何更改（包括策略声明）都会使整个URL无法使用。

OAI仅与CloudFront签名URL间接连接-它们可以单独使用，也可以一起使用-但是如果没有OAI，CloudFront无法证明已被授权从存储桶中请求对象，因此存储桶需要公开，这将使CloudFront上签名URL的许多目的无法实现。