如果我将我的应用程序设置为生成用于访问S3媒体的预签名URL（以便可以将文件设置为私有，除非通过登录的用户访问），那么我是否可以这样说：有人可以访问URL（在有效期内），尽管文件是“私有”的，他们仍然可以看到该文件吗？
因此，如果有人将URL发送给其他人，那么它就不再是私有的。
我想没有别的办法了，但这对我来说似乎很奇怪。
答案 0 :(得分：1)
是的，您可以对“签名的URL”进行“共享”是正确的，因为在URL失效之前（或直到对其签名的凭据失效或无效之前，以先到者为准），它是有效的。
一种常见的解决方案是让您的应用程序在呈现页面时使用非常短的到期时间生成签名的URL。
另一种方法是，指向受保护内容的链接实际上是指向应用程序的链接，该链接将验证用户访问对象的权限，然后将HTTP重定向返回到具有较短到期时间的新生成的签名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的GenerateRandom API操作。）
有许多替代方法，包括Lambda @ Edge触发器的其他用法，例如检查对应用程序提供的cookie的请求，然后查询应用程序服务器以验证用户身份。
CloudFront还支持签名的cookie，它本身可以对其进行解析和解释，但是这些cookie提供了对与特定URL和路径（例如/images/*）匹配的所有资产的基于通配符的访问，并且没有阻止用户访问的内容。共享它们的cookie，因此这些cookie对您的用例可能没有用。
CloudFront签名URL确实支持仅在从特定源（客户端）IP地址使用签名URL时才允许访问的选项，但这存在潜在的问题，因为无法保证用户与用户之间存在1：1关联。 IP地址。许多用户可能在同一个地址后面（尤其是在公司网络环境中），或者单个用户的地址可以随时更改。
可能的实现方式的复杂性千差万别，您所需要的部分取决于内容的安全性。在许多情况下，更极端的解决方案除了劝阻诚实的用户外，还可以完成其他工作，因为用户仍然可以下载并通过其他方式共享资源。
答案 1 :(得分：0)
这就是签名URL的工作方式。
如果系统中的所有用户都具有相同的访问权限，则可以使用签名的cookie。
CDN的主要目的是提高性能，并且在Quora中有一篇很好的文章谈到了Facebook在私有映像上的安全性（CDN中的私有URL实际上是完全公开的）。 Facebook的方法是基于能力的安全性。
用户一旦看到URL，就可以轻松共享媒体文件。在CDN中建立完全访问控制的投资回报率太低。
答案 2 :(得分：-2)
那仍然是一个单独的用户请求内容。对于单独的用户，证书将不再有效。
来源：https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html