本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 预签名概述 URLs
预签名网址是一种由 [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 服务识别的 HTTP 请求。这种类型的请求与所有其他 AWS 请求的区别在于[X-Amz-Expires 查询参数](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html)。与其他经过身份验证的请求一样，预签名 URL 请求也包含签名。对于预签名 URL 请求，此签名将传入。`X-Amz-Signature`签名使用签名版本 4 加密操作对所有其他请求参数进行编码。
**注意**
[Signature 版本 2 目前正在被弃用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAWSSDK.html#UsingAWSSDK-sig2-deprecation)，但某些 AWS 区域版本仍支持该版本。本指南适用于签名版本 4 签名。
接收服务可以处理未签名的标头，但根据最佳实践，对该选项的支持有限且有针对性。除非另有说明，否则假设所有标头都必须经过签名才能被接受。
该`X-Amz-Expires`参数允许将签名视为有效，但与编码的日期时间偏差更大。 签名有效性的其他方面仍在评估中。 签名凭证（如果是临时证书）在处理签名时不得过期。 签名证书必须附加到在处理时拥有足够授权的 IAM 委托人。
**预签名 URLs 是预签名请求的子集**
预签名 URL 并不是将来签署请求的唯一方法。Amazon S3 还支持 POST 请求，这些请求通常也是预签名的。 预签名的 POST 签名允许上传符合已签名政策且该政策中包含有效期的上传。
请求的签名可能是 future 日期，尽管这种情况并不常见。 只要底层凭证有效，签名算法就不会禁止将来的约会。 但是，这些请求要等到有效的计时窗口才能成功处理，这使得对于大多数用例来说，future dating 是不切实际的。
**预签名请求允许什么？**
预签名的请求只能允许用于签署请求的凭据所允许的操作。如果凭证隐式或显式拒绝预签名请求指定的操作，则预签名请求在发送时将被拒绝。这适用于以下情况：
+ 与凭证关联的会话策略
+ 与与证书关联的委托人关联的基于身份的策略
+ 影响会话或委托人的资源策略
+ 影响会话或主体的服务控制策略
+ 影响会话或委托人的资源控制策略
## 使用预签名请求的动机
作为一名安全工程师，你应该了解是什么促使解决方案构建者使用预 URLs签名。 了解什么是必要的，哪些是可选的，将有助于你与解决方案构建者沟通。动机可能包括以下几点：
+ 支持非 IAM 身份验证机制，同时受益于 Amazon S3 的可扩展性。核心动机是直接与 Amazon S3 通信，以便从该服务提供的内置可扩展性中受益。如果没有这种直接通信，解决方案就需要支持重新传输传入的字节**PutObject**和**GetObject**调用的负载。根据总负载，此要求增加了解决方案构建者可能希望避免的扩展挑战。
其他直接与 Amazon S3 通信的方式，例如在 AWS Security Token Service (AWS STS) 中使用临时凭证或在外部使用签名版本 4 签名 URLs，可能不适合您的用例。Amazon S3 通过 AWS 证书识别用户，而预签名的请求则假定通过证书以外的 AWS 机制进行身份识别。通过预签名的请求，可以弥合这种差异，同时保持数据的直接通信。
+ 从浏览器的原生理解中受益 URLs. URLs 浏览器可以理解，而 AWS STS 凭据和签名版本 4 的签名却无法理解。这在与基于浏览器的解决方案集成时非常有用。替代解决方案需要更多的代码，将占用更多内存来存储大文件，恶意软件和病毒扫描程序等扩展程序可能会以不同的方式对待。
### 与临时 AWS STS 证书的比较
临时证书与预签名请求类似。 它们都过期，允许限制访问范围，并且通常用于将非 IAM 证书与需要 AWS 证书的使用联系起来。
您可以将临时 AWS STS 凭证的范围严格限定为单个 S3 对象和操作，但由于 AWS STS APIs 存在限制，这可能会导致扩展方面的挑战。（有关更多信息，请参阅 AWS re: Post AWS STS网站上的 [“如何解决 IAM 的 API 限制或 “超出速率” 错误](https://repost.aws/knowledge-center/iam-sts-throttling-error)的文章。） 此外，生成的每个凭证都需要一个 AWS STS API 调用，这会增加延迟和可能影响弹性的新依赖关系。 临时 AWS STS 凭证的最短到期时间也为 15 分钟，而预签名的请求可以支持更短的持续时间。（如果条件合适，60 秒是可行的。）
### 与仅限签名的解决方案的比较
预签名请求中唯一固有的秘密部分是其签名版本 4 签名。 如果客户知道请求的其他详细信息并且获得了与这些详细信息相匹配的有效签名，则它可以发送有效的请求。如果没有有效的签名，则不能。
预签名 URLs 和仅限签名的解决方案在密码学上是相似的。但是，仅限签名的解决方案具有实际优势，例如能够使用 HTTP 标头而不是查询字符串参数来传输签名（请参阅[日志交互和缓解措施](logging-interactions.md)部分）。 管理员还应考虑到，查询字符串通常被视为元数据，而标头则不太常被当作元数据对待。
另一方面， AWS SDKs 对直接生成和使用签名的支持较少。构建仅限签名的解决方案需要更多的自定义代码。从实际角度来看，为了安全起见，使用库代替自定义代码是一种一般的最佳做法，因此仅限签名的解决方案的代码需要额外的审查。
仅限签名的解决方案不使用`X-Amz-Expires`查询字符串，也没有提供明确的有效期。IAM 管理没有明确到期时间的签名的隐式有效期。那些隐含的时期没有公布。它们通常不会更改，但是在管理时考虑到了安全性，因此您不应该依赖有效期。 在明确控制到期日期和让 IAM 管理到期日之间需要权衡。
作为管理员，您可能更喜欢仅限签名的解决方案。但是，从实际意义上讲，您需要支持已构建的解决方案。