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

基礎最佳實務

其他 AWS API 請求的有效控制的一般最佳實務也適用於預先簽章的請求。本節會檢閱兩個最相關的實務：最低權限和資料周邊。這些實務可建立其他實務延伸的控制深度。

套用最低權限準則

限制預先簽章請求使用的第一步是一般限制對 Amazon S3 的存取。預先簽章的 URL 無法提供未授予產生預先簽章 URL 之簽章的委託人之資源的存取權。也無法以未授予該委託人的方式提供資源的存取權。因此，套用最佳實務來授予這些委託人最低權限是有效的護欄。

建立預先簽章 URL 的程序是一種演算法操作，以用於產生簽章的已發佈標準 （簽章第 4 版） 為基礎。因此，您無法限制產生預先簽章URLs。不過，為了相關起見，預先簽章的 URL 必須是有效的，並提供 資源的存取權，因此預先簽章的 URL 的有效性也是有效的護欄。

如需最低權限的詳細資訊，請參閱 AWS Well-Architected Framework 安全支柱中的授予最低權限存取。

實作資料周邊

最低權限的延伸是維護符合組織需求的資料周邊。預先簽章URLs 與資料周邊相容。 如同其他請求，預先簽章的 URL 請求的有效性會在請求時間進行評估。如果網路、資源、角色工作階段和主體的屬性變更，則會在接收請求時使用 方法進行評估。

例如，假設在 Amazon Elastic Kubernetes Service (Amazon EKS) 容器中執行的服務簽署請求。請求稍後會從連線至網際網路的使用者個人電腦系統傳送。在此情況下，aws：SourceIp 條件會從使用者的個人系統評估請求的可見公有 IP 地址，而不是 Amazon EKS 容器中的服務 IP 地址。

同樣地，如果委託人或資源的標籤在傳送請求之前變更，則更新而非原始值將透過 aws：PrincipalTag/tag-key 和 aws：ResourceTag/tag-key 條件套用至請求。