Amazon S3 预签名 URL

Question

如果我将我的应用程序设置为生成用于访问 S3 媒体的预签名 URL（以便我可以将文件设置为私有，除非通过登录用户访问），那么如果有人有权访问，那么我这样说是否正确到 URL（在到期时间内）他们可以看到该文件，尽管它是“私有”的？

因此，如果有人将 URL 发送给其他人，那么它就不再是真正的隐私了。

我想没有其他办法，但这对我来说似乎很奇怪。

Answer 1

是的，您是对的，签名的 URL 可以“共享”，因为它在过期之前一直有效（或者在签名的凭据过期或以其他方式失效之前，以先到者为准）。

一种常见的解决方案是应用程序在呈现页面时使用非常短的过期时间生成签名 URL。

另一种是指向受保护内容的链接实际上是返回应用程序的链接，该链接验证用户访问该对象的权限，然后将 HTTP 重定向返回到新生成的签名 URL，该 URL 具有较短的过期时间（例如 5秒）。

HTTP/1.1 302 Found
Location: https://example-bucket.s3.amazonaws.com/...?X-Amz-...

使用当前可行的计算能力无法篡改签名 URL，因此恶意用户不可能修改签名 URL 是不切实际的。

另请注意，签名 URL（适用于 S3 或 CloudFront）只需在下载开始时尚未过期。下载实际完成所需的时间可以是任意长，并且下载不会中断。

以下选项没有现成的服务，但使用 CloudFront Lambda@Edge 触发器和 DynamoDB 的组合，可以创建真正的一次性 URL，该 URL 由存储在 Dynamo 中的随机生成的“令牌”组成表并与目标对象关联。访问 URL 时，您可以在 Lambda 触发器中使用 DynamoDB 条件更新将（例如）“view_count”值从 0 更新为 1。如果令牌不在表中或视图计数不为 0，则条件更新失败，因此访问被拒绝；否则，CloudFront 允许请求继续进行——仅一次。CloudFront 使用源访问身份访问 S3 内容，这一切都在幕后发生，因此用户无法访问与 CloudFront 和 S3 之间请求的实际身份验证相关的任何内容。（对于加密质量的随机令牌生成，您还可以使用 KMS 的GenerateRandomAPI 操作。）

有许多替代方法，包括使用 Lambda@Edge 触发器来执行某些操作，例如检查对应用程序提供的 cookie 的请求，然后查询应用程序服务器以对用户进行身份验证。

CloudFront 还支持它本身解析和解释的签名 cookie，但这些提供了对与特定 URL 和路径匹配的所有资产的基于通配符的访问（例如/images/*）匹配的所有资产的基于通配符的访问，并且没有什么可以阻止用户共享他们的 cookie，因此这些可能是对您的用例没有用。

CloudFront 签名 URL 确实支持仅当从特定源（客户端）IP 地址使用签名 URL 时才允许访问的选项，但这存在潜在问题，因为无法保证用户和 IP 地址之间存在 1:1 关联。许多用户可能位于同一地址（特别是在企业网络环境中），或者单个用户的地址可能随时发生变化。

可能的实现的复杂性差异很大，您的需求部分取决于您需要的内容安全程度。在许多情况下，更极端的解决方案只不过是阻止诚实的用户，因为用户仍然可以下载资源并通过其他方式共享它。

Answer 2

那仍然是请求内容的单独用户。对于单独的用户，证书将不再有效。

来源：https ://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html