本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 預先簽章URLs 概觀
預先簽章的 URL 是一種 HTTP 請求，由 [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 服務識別。這類請求與所有其他 AWS 請求的差異在於 [X-Amz-Expires 查詢參數](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html)。如同其他已驗證的請求，預先簽章的 URL 請求包含簽章。對於預先簽章的 URL 請求，此簽章會在 中傳輸`X-Amz-Signature`。簽章使用 Signature 第 4 版密碼編譯操作來編碼所有其他請求參數。
**備註**
[Signature 第 2 版目前正在淘汰](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAWSSDK.html#UsingAWSSDK-sig2-deprecation)，但有些版本仍然支援。 AWS 區域本指南適用於 Signature 第 4 版簽署。
接收服務可以處理未簽署的標頭，但該選項的支援有限且具有目標性，符合最佳實務。除非另有說明，否則假設必須簽署所有標頭，才能接受請求。
`X-Amz-Expires` 參數允許將簽章處理為有效，且與編碼日期時間的偏差較大。仍會評估簽章有效性 的其他層面。 如果是暫時的，則簽署憑證在處理簽章時不得過期。簽署憑證必須連接到在處理時具有足夠授權的 IAM 主體。
**預先簽章URLs 是預先簽章請求的子集**
預先簽章的 URL 不是未來簽署請求的唯一方法。Amazon S3 也支援 POST 請求，這些請求通常也會預先簽章。預先簽章的 POST 簽章允許上傳符合已簽章政策，且具有內嵌在該政策中的過期日期。
請求的簽章可以是未來的日期，雖然這不常見。 只要基礎登入資料有效，簽章演算法就不會禁止未來的日期。 不過，在它們的有效時間時段之前，這些請求都無法成功處理，這使得未來日期對大多數使用案例來說是不切實際的。
**預先簽章的請求允許什麼？**
預先簽章的請求只能允許用於簽署請求的登入資料所允許的動作。如果登入資料隱含或明確拒絕預先簽章請求指定的動作，則傳送預先簽章請求時會遭到拒絕。這適用於下列項目：
+ 與登入資料相關聯的工作階段政策
+ 與登入資料相關聯之主體相關聯的身分型政策
+ 影響工作階段或主體的資源政策
+ 影響工作階段或主體的服務控制政策
+ 影響工作階段或主體的資源控制政策
## 使用預先簽章請求的動機
身為安全工程師，您應該了解什麼會促使解決方案建置器使用預先簽章URLs。 了解必要項目和選用項目可協助您與解決方案建置器通訊。動機可能包括下列項目：
+ 支援非 IAM 身分驗證機制，同時受益於 Amazon S3 中的可擴展性。核心動機是直接與 Amazon S3 通訊，以受益於此服務提供的內建可擴展性。如果沒有此直接通訊，解決方案將需要支援在 **PutObject** 和 **GetObject** 呼叫中重新傳輸位元組的負載。根據總負載，此需求會增加解決方案建置器可能想要避免的擴展挑戰。
其他直接與 Amazon S3 通訊的方法，例如在 URLs 外部使用臨時登入資料 AWS Security Token Service (AWS STS) 或 Signature 第 4 版簽章，可能不適用於您的使用案例。Amazon S3 透過 AWS 登入資料識別使用者，而預先簽章的請求則假設透過 AWS 登入資料以外的機制進行識別。消除此差異，同時維持資料的直接通訊可透過預先簽章的請求實現。
+ 受益於瀏覽器對 URLs 的原生理解。瀏覽器會了解 URLs，而 AWS STS 登入資料和 Signature 第 4 版簽章則不會。這在與瀏覽器型解決方案整合時很有幫助。替代解決方案需要更多程式碼、將更多記憶體用於大型檔案，並且可能會受到惡意軟體和病毒掃描器等延伸模組的不同處理。
### 與臨時 AWS STS 登入資料的比較
暫時登入資料類似於預先簽章的請求。 它們都會過期，允許存取範圍，並且通常用於將非 IAM 登入資料橋接到需要 AWS 登入資料的用量。
您可以緊密地將臨時 AWS STS 憑證範圍限定為單一 S3 物件和動作，但這可能會導致擴展挑戰，因為 AWS STS APIs具有限制。（如需詳細資訊，請參閱 AWS re：Post 網站上的[文章如何解決 IAM 和 的 API 限流或「超過速率」錯誤 AWS STS](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 管理過期之間 存在權衡。
身為管理員，您可能偏好純簽章解決方案。不過，從實際意義上來說，您需要支援建置的解決方案。