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

# 基礎最佳實務
<a name="foundational-best-practices"></a>

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

## 套用最低權限準則
<a name="least-privilege"></a>

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

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

如需最低權限的詳細資訊，請參閱 AWS Well-Architected Framework 安全支柱中的[授予最低權限存取權](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)。

## 實作資料周邊
<a name="data-perimeters"></a>

最低權限的延伸是維護符合組織需求[的資料周邊](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)。預先簽章URLs 與資料周邊相容。 如同其他請求，預先簽章的 URL 請求的有效性會在請求時間進行評估。如果[網路、資源、角色工作階段和主體的屬性](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)變更，則會在接收請求時使用 方法進行評估。

例如，假設在 Amazon Elastic Kubernetes Service (Amazon EKS) 容器中執行的服務簽署請求。請求稍後會從連線至網際網路的使用者個人電腦系統傳送。在此情況下，[aws：SourceIp 條件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip)會從使用者的個人系統評估請求的可見公有 IP 地址，而不是 Amazon EKS 容器中的服務 IP 地址。

同樣地，如果主體或資源的標籤在傳送請求之前發生變更，則更新而非原始值將透過 [aws：PrincipalTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) 和 [aws：ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) 條件套用至請求。