本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 基础最佳实践
<a name="foundational-best-practices"></a>

有效控制其他 AWS API 请求的一般最佳做法也适用于预签名请求。本节回顾了两种最相关的做法：最低权限和数据边界。这些做法创造了其他实践所扩展的控制深度。

## 采用最低权限原则
<a name="least-privilege"></a>

限制使用预签名请求的第一步是总体上限制对 Amazon S3 的访问。预签名 URL 无法提供对未授予为预签名 URL 生成签名的委托人的资源的访问权限。它也不能以未授予该委托人的方式提供对资源的访问权限。因此，应用最佳实践来授予这些校长最少的特权是一种有效的保护措施。

创建预签名 URL 的过程是一种基于已发布的签名生成标准（签名版本 4）的算法操作。因此，不可能限制预签名 URL 的生成。但是，为了保持相关性，预签名 URL 必须有效并提供对资源的访问权限，因此预签名 URL 的有效性也是一个有效的保护措施。

有关最低权限的更多信息，请参阅 Fr AWS Well-Architected amework 的 “安全” 支柱中的[授予最低权限访问权限](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)。预签名 URL 与数据边界兼容。 与其他请求一样，预签名 URL 请求的有效性是在请求时评估的。如果[网络、资源、角色会话和主体的属性](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)发生变化，则在接收请求时使用接收请求的方法对其进行评估。

例如，假设在亚马逊 Elastic Kubernetes Service（Amazon EKS）容器中运行的服务签署了请求。该请求随后由连接到互联网的用户的个人计算机系统发送。在本例中，aws[: SourceIp 条件评估的是来自用户个人系统的请求的可见公有 IP 地址，而不是 Amazon EKS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip) 容器中服务的 IP 地址。

同样，如果委托人或资源的标签在发送请求之前发生了变化，则更新后的值（不是原始值）将通过 aws[: PrincipalTag/tag-key 和 aws[: ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) 条件应用于请求。