預先簽署的 URL 概觀 - AWS 方案指引
使用預先簽署要求的動機

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

預先簽署的 URL 概觀

預先簽署的 URL 是一種由 AWS Identity and Access Management (IAM) 服務辨識的 HTTP 要求類型。什麼區別於所有其他 AWS 請求這種類型的請求是 X-AMZ Expires 查詢參數。與其他已驗證的要求一樣，預先簽署的 URL 要求會包含簽章。對於預先簽署的 URL 要求，會傳輸此簽章。X-Amz-Signature簽章使用簽章版本 4 密碼編譯作業來編碼所有其他要求參數。

備註

  • 簽名版本 2 目前正在被棄用，但在某些情況下仍然受到支持 AWS 區域。本指南適用於簽名版本 4 簽署。

  • 接收服務可以處理未簽署的標頭，但對該選項的支援受到限制且鎖定目標，符合最佳作法。除非另有說明，否則假設所有標頭都必須簽署才能接受請求。

此X-Amz-Expires參數允許將簽章處理為有效，且與編碼日期時間有較大的偏差。 仍會評估簽名有效性的其他方面。 簽署認證 (如果是暫時的) 不得在處理簽章時過期。 簽署登入資料必須附加至在處理時具有足夠授權的 IAM 主體。

預先簽署的 URL 是預先簽署要求的子集

預先簽署的 URL 並不是 future 簽署要求的唯一方法。Amazon S3 也支援 POST 請求，這些請求通常也是預先簽署的。 預先簽署的 POST 簽名允許上傳符合已簽署政策，且該原則中內嵌的到期日。

請求的簽名可能是 future 的日期，儘管這是罕見的。 只要基礎憑據有效，簽名算法就不會禁止 future 的約會。 但是，在有效的時間窗口之前，這些請求才能成功處理，這使得 future 的約會對大多數用例不切實際。

預先簽署的要求允許什麼？

預先簽署的要求只能允許用來簽署要求的認證所允許的動作。如果認證隱含或明確拒絕預先簽署要求所指定的動作，預先簽署的要求會在傳送時遭到拒絕。這適用於以下內容：

  • 與認證相關聯的階段作業原則

  • 與認證相關聯的主參與者相關聯的原則

  • 影響工作階段或主參與者的資源策略

  • 影響工作階段或主體的服務控制原則

使用預先簽署要求的動機

身為安全性工程師，您應該瞭解是什麼促使解決方案建置者使用預先簽署的 URL。 了解什麼是必要的，什麼是可選項將有助於您與解決方案建置者溝通。動機可能包括以下內容：

  • 支援非 IAM 身份驗證機制，同時受益於 Amazon S3 的可擴展性。核心動機是直接與 Amazon S3 通訊，以便從此服務提供的內建可擴展性中獲益。如果沒有這種直接通信，解決方案將需要支持重新傳輸發送PutObject和GetObject調用的字節的負載。根據總負載，此需求增加了解決方案建置器可能想要避免的擴展挑戰。

    其他直接與 Amazon S3 通訊的方式，例如在 AWS Security Token Service (AWS STS) 中使用臨時登入資料或 URL 之外的簽名版本 4 簽名，可能不適合您的使用案例。Amazon S3 透過 AWS 登入資料識別使用者，而預先簽署的請求則假設透過登入資料以外 AWS 的機制進行識別。橋接這種差異，同時保持數據的直接通信可以通過預先簽名的請求來實現。

  • 從瀏覽器對 URL 的本機理解中受益。瀏覽器可以理解 URL，而 AWS STS 憑證和簽名版本 4 簽名則不能理解。與基於瀏覽器的解決方案集成時，這是有益的。替代解決方案需要更多程式碼、大型檔案會使用更多記憶體，而且惡意程式碼和病毒掃描程式等擴充功能可能會有所不同處理。

與臨時 AWS STS 登入資料比較

臨時登入資料類似於預先簽署的要求。 它們都會過期、允許存取範圍，並且通常用於將非 IAM 登入資料橋接到需要 AWS 登入資料的用量。 

您可以將暫時 AWS STS 登入資料的範圍嚴格限定為單一 S3 物件和動作，但這可能會導致擴展挑戰，因為 AWS STS API 有限制。如需詳細資訊，請參閱如何解決 IAM 和 AWS RE: Post 網站 AWS STS上的 API 節流或「超過速率」錯誤一文。) 此外，每個生成的憑據都需要 AWS STS API 調用，這會增加延遲和可能影響恢復性的新依賴關係。 臨時 AWS STS 憑證的到期時間下限也為 15 分鐘，而預先簽署的要求可以支援較短的持續時間。(在適當的條件下，60 秒是可行的)。

與僅限簽名的解決方案比較

預先簽署要求的唯一固有機密元件是其簽章版本 4 簽章。 如果客戶端知道請求的其他詳細信息，並提供與這些詳細信息匹配的有效簽名，則可以發送有效的請求。沒有有效的簽名，它不能。

預先簽署的 URL 和僅限簽名的解決方案與密碼編譯類似。但是，僅限簽名的解決方案具有實際的優勢，例如能夠使用 HTTP 標頭而不是查詢字符串參數來傳輸簽名（請參閱記錄交互和緩解措施一節）。 系統管理員也應該將查詢字串視為中繼資料較常被視為中繼資料，而標頭則較不常被視為這類。

另一方面， AWS SDK 對直接生成和使用簽名提供的支持較少。建立僅限簽名的解決方案需要更多的自訂程式碼。從實際的角度來看，使用庫而不是自定義代碼來實現安全性是一般的最佳實踐，因此僅簽名解決方案的代碼需要額外的審查。

僅限簽名的解決方案不使用X-Amz-Expires查詢字符串，並且不提供明確的有效期。IAM 管理沒有明確到期時間的簽名隱含有效期。這些隱含期間不會發佈。它們通常不會改變，但它們是在考慮到安全性的情況下進行管理，因此您不應該依賴於有效期。 在明確控制到期日和讓 IAM 管理到期日之間有一個權衡。

身為管理員，您可能更喜歡僅簽名的解決方案。但是，從實際意義上說，您需要支持內置的解決方案。