原始访问身份（OAI）与CloudFront签名URL之间的关系 [英] Relationship between Origin Access Identities (OAIs) and CloudFront Signed URLs

问题描述

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

So I've been following guides on CloudFront and S3 and I feel like I am still missing a core piece of information in the relationship between Origin Access Identities (OAIs) and CloudFront Signed URLs.

我想要的：私有CDN，用于托管音频片段（长度为几秒钟）和低分辨率图像。我只希望从特定域（即Web应用程序将要驻留的域）以及测试服务器发出请求时访问这些文件，以便我的Web应用程序可以获取文件，但其他任何人都无法访问它们通过网络应用程序。

What I want: a private CDN to host audio snippets (of a few seconds in length) and low-resolution images. I only want these files to be accessible when requested from a specific domain (i.e. the domain the web app will live on) and maybe a testing server, so that my web app can get the files but anyone else just can't access them without going through the web app.

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

What I'm confused about: I'm fuzzy on the relationship (if there is any) between CloudFront Origin Access Identities (OAIs) and Signed CloudFront URLs.

我目前已经创建了一个私有S3存储桶，这是我的CloudFront发行版的OAI，并且已经通过CloudFront生成了指向图像的签名URL。但是我看不到这些东西之间的关系，以及它们如何阻止他人访问CDN文件（例如，他们是否能够检查元素并获取签名的URL）。

I have currently created a private S3 bucket, an OAI for my CloudFront distribution, and have generated a signed URL to an image through CloudFront. But I don't see how these things are related and how they prevent someone else from accessing CDN files (e.g. if they were able to inspect an element and get the signed URL).

是否要确保签名的URL快速过期？如果是这样，OAI将如何发挥作用？

Is the whole point to make sure the signed URLs expire quickly? And if so, how does the OAI play a role in it? Is this something set in CORS?

推荐答案

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

An origin access identity is an entity inside CloudFront that can be authorized by bucket policy to access objects in a bucket. When CloudFront uses an origin access identity to access content in a bucket, CloudFront uses the OAI's credentials to generate a signed request that it sends to the bucket to fetch the content. This signature is not accessible to the viewer.

此处使用的起源一词的含义不应与其他情况下使用的起源一词混淆，例如CORS，其中来源是指允许访问内容的网站。

The meaning of the word "origin" as used here should not be confused with the word "origin" as used in other contexts, such as CORS, where "origin" refers to the site that is allowed to access the content.

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

The origin access identity has nothing to do with access being restricted to requests containing a specific Origin or Referer header.

一旦CloudFront验证了已签名的URL是否与与您的AWS账户（或您指定为受信任签名者的另一个账户）相关联的CloudFront签名密钥相匹配，便使用原始权限从存储桶中提取对象

Once a signed URL is validated by CloudFront as matching a CloudFront signing key associated with your AWS account (or another account that you designate as a trusted signer) the object is fetched from the bucket, using whatever permissions the origin access identity has been granted at the bucket.

是否要确保签名网址迅速过期？

Is the whole point to make sure the signed url's expire quickly?

从本质上讲，是的。

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

Authentication and Authorization of requests by trying to restrict access based on the site where the link was found is not a viable security measure. It prevents hot-linking from other sites, but does nothing to protect against anyone who can forge request headers. Defeating a measure like that is trivial.

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

Signed URLs, by contrast, are extremely tamper resistant to the point of computational infeasibility.

签名的URL不仅仅在到期之前有效，而且如果使用自定义政策。签名后，对URL的任何更改（包括策略声明）都会使整个URL无法使用。

A signed URL is not only valid only until it expires, but can optionally also restrict access to a person having the same IP address that's included in the policy document, if you use a custom policy. Once signed, any change to the URL, including the policy statement, makes the entire URL unusable.

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

The OAI is only indirectly connected with CloudFront signed URLs -- they can be used individually, or together -- but without an OAI, CloudFront has no way to prove that it is authorized to request objects from your bucket, so the bucket would need to be public, which would defeat much of the purpose of signed URLs on CloudFront.

这篇关于原始访问身份（OAI）与CloudFront签名URL之间的关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！