

# 访问控制列表 (ACL) 概述
<a name="acl-overview"></a>

Amazon S3 访问控制列表（ACL）使您可以管理存储桶和对象的访问权限。每个存储桶和对象都有一个作为子资源而附加的 ACL。它定义了哪些 Amazon Web Services 账户或组将被授予访问权限以及访问的类型。收到针对某个资源的请求后，Amazon S3 将检查相应的 ACL 以验证请求者是否拥有所需的访问权限。

S3 对象所有权是 Amazon S3 存储桶级别的设置，您可以使用该设置来控制上传到存储桶的对象的所有权和禁用或启用 ACL。默认情况下，对象所有权设为强制存储桶拥有者设置，并且所有 ACL 均处于禁用状态。禁用 ACL 后，存储桶拥有者拥有存储桶中的所有对象，并使用访问管理策略来专门管理对这些对象的访问权限。

 Amazon S3 中的大多数现代使用案例不再需要使用 ACL。我们建议您将 ACL 保持为禁用状态，除非有需要单独控制每个对象的访问权限的情况。禁用 ACL 后，您可以使用策略来控制对存储桶中所有对象的访问权限，无论是谁将对象上传到您的存储桶。有关更多信息，请参阅 [为您的存储桶控制对象所有权和禁用 ACL。](about-object-ownership.md)。

**重要**  
如果通用存储桶针对 S3 对象所有权使用强制存储桶拥有者设置，则必须使用策略来授予对通用存储桶及其中对象的访问权限。启用强制存储桶拥有者设置后，设置访问控制列表（ACL）或更新 ACL 的请求将失败并返回 `AccessControlListNotSupported` 错误代码。仍然支持读取 ACL 的请求。

创建存储桶或对象时，Amazon S3 将创建一个默认 ACL 以授予资源拥有者对资源的完全控制权限。这显示在下面的示例存储桶 ACL 中（默认对象 ACL 具有相同的结构）：

**Example**  

```
 1. <?xml version="1.0" encoding="UTF-8"?>
 2. <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
 3.   <Owner>
 4.     <ID>*** Owner-Canonical-User-ID ***</ID>
 5.   </Owner>
 6.   <AccessControlList>
 7.     <Grant>
 8.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 9.                xsi:type="Canonical User">
10.         <ID>*** Owner-Canonical-User-ID ***</ID>
11.       </Grantee>
12.       <Permission>FULL_CONTROL</Permission>
13.     </Grant>
14.   </AccessControlList>
15. </AccessControlPolicy>
```

示例 ACL 包含一个可通过 Amazon Web Services 账户的规范用户 ID 识别拥有者的 `Owner` 元素。有关查找规范用户 ID 的说明，请参阅[查找 Amazon Web Services 账户规范用户 ID](#finding-canonical-id)。`Grant` 元素将识别被授权者（Amazon Web Services 账户或预定义的组）和所授予的权限。此默认的 ACL 拥有一个适用于所有者的 `Grant` 元素。您可以通过添加 `Grant` 元素授予权限，每个授权都将识别被授权者和权限。

**注意**  
ACL 可以拥有最多 100 个授权。

**Topics**
+ [谁是被授权者？](#specifying-grantee)
+ [我能授予哪些许可？](#permissions)
+ [常见 Amazon S3 请求的 `aclRequired` 值](#aclrequired-s3)
+ [示例 ACL](#sample-acl)
+ [标准 ACL](#canned-acl)

## 谁是被授权者？
<a name="specifying-grantee"></a>

授予访问权限时，可以将每个被授权者指定为一个 `type="value"` 对，其中 `type` 为以下值之一：
+ `id` – 如果指定的值是 Amazon Web Services 账户的规范用户 ID
+ `uri` – 如果您正在向预定义组授予权限

**警告**  
当您需要向其他 Amazon Web Services 账户授权访问您的资源时，注意 Amazon Web Services 账户可以向其账户下的用户授予权限。这称为*跨账户访问*。有关使用跨账户访问的信息，请参阅 *IAM 用户指南*中的[创建角色以向 IAM 用户委派权限](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_create_for-user.html)。

### 查找 Amazon Web Services 账户规范用户 ID
<a name="finding-canonical-id"></a>

规范用户 ID 与您的 Amazon Web Services 账户关联。此 ID 是一个长串字符，例如：

`79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be`

有关如何查找您账户的规范用户 ID 的信息，请参阅《Amazon 账户管理参考指南》**中的 [Find the canonical user ID for your Amazon Web Services 账户](https://docs.amazonaws.cn/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId)。

您也可以通过读取 Amazon Web Services 账户 有权访问的存储桶或对象的 ACL，查找 Amazon Web Services 账户 的规范用户 ID。如果某个 Amazon Web Services 账户通过授权请求被授予了许可，ACL 中将新增一个授权条目和账户的规范用户 ID。

**注意**  
如果您公开存储桶（不建议），则任何未经身份验证的用户都可以将对象上传到该存储桶。这些匿名用户没有 Amazon Web Services 账户。当匿名用户将对象上传到您的存储桶时，Amazon S3 会在 ACL 中添加特殊的规范用户 ID（`65a011a29cdf8ec533ec3d1ccaae921c`）作为对象拥有者。有关更多信息，请参阅 [Amazon S3 存储桶和对象所有权](access-policy-language-overview.md#about-resource-owner)。

### Amazon S3 预定义的组
<a name="specifying-grantee-predefined-groups"></a>

Amazon S3 拥有一系列预定义的组。将账户访问权限授予某个组时，您可以指定我们的一个 Amazon S3 URI，而不是规范用户 ID。Amazon S3 提供以下预定义组：
+ ****“经身份验证的用户”组**** – 由 `http://acs.amazonaws.com/groups/global/AuthenticatedUsers` 表示。

  该组代表了所有 Amazon Web Services 账户。**该组的访问权限允许任何 Amazon Web Services 账户 访问资源。**但是，所有的请求必须是已签名的 (经身份验证)。
**警告**  
在您向**经身份验证的用户组**授予访问权限后，世界上任何经身份验证的 Amazon 用户都可以访问您的资源。
+ ****“所有用户”组**** – 由 `http://acs.amazonaws.com/groups/global/AllUsers` 表示。

  **授予此组的访问权限将允许世界上的任何人访问资源。**请求可以是已签名的 (经身份验证)，也可以是未签名的 (匿名)。未签名的请求将省略请求中的 Authentication 标头。
**警告**  
强烈建议您绝不要向 **All Users 组**授予 `WRITE`、`WRITE_ACP` 或 `FULL_CONTROL` 权限。例如，尽管 `WRITE` 权限拒绝非拥有者覆盖或删除现有对象的功能，但 `WRITE` 权限仍支持任何人在您的存储桶中存储对象，而您需要为此付费。有关这些权限的详细信息，请参阅下一节 [我能授予哪些许可？](#permissions)。
+ ****“日志传输”组**** – 由 `http://acs.amazonaws.com/groups/s3/LogDelivery` 表示。

  对于存储桶的 `WRITE` 权限使该组可以将服务器访问日志（请参阅[使用服务器访问日志记录来记录请求](ServerLogs.md)）写入存储桶。

**注意**  
使用 ACL 时，被授权者可以是 Amazon Web Services 账户或者某个预定义的 Amazon S3 组。但是，被授权者不能是 IAM 用户。有关 IAM 中 Amazon 用户和权限的更多信息，请参阅[使用 Amazon Identity and Access Management](https://docs.amazonaws.cn/IAM/latest/UserGuide/)。

## 我能授予哪些许可？
<a name="permissions"></a>

下表列出了 Amazon S3 在 ACL 中支持的权限集。对于对象 ACL 和存储桶 ACL，ACL 权限集相同。但是，根据上下文（存储桶 ACL 或对象 ACL），这些 ACL 权限将授予针对特定存储桶或对象操作的权限。下表列出了权限并描述这些权限在对象和存储桶上下文中的意义。

有关使用 Amazon S3 控制台 ACL 权限的更多信息，请参阅 [配置 ACL](managing-acls.md)。


| 许可 | 在存储桶上授权的时间 | 在对象上授权的时间 | 
| --- | --- | --- | 
| READ | 允许被授权者列出存储桶中的对象 | 允许被授权者读取对象数据及其元数据 | 
| WRITE | 允许被授权者在存储桶中创建新对象。对于现有对象的存储桶和对象拥有者，还允许删除和覆写这些对象 | 不适用 | 
| READ\$1ACP | 允许被授权者读取存储桶 ACL | 允许被授权者读取对象 ACL | 
| WRITE\$1ACP | 允许被授权者为适用的存储桶编写 ACL | 允许被授权者为适用的对象编写 ACL | 
| FULL\$1CONTROL | 允许被授予者对存储桶拥有 READ、WRITE、READ\$1ACP 和 WRITE\$1ACP 权限 | 允许被授予者对于对象拥有 READ、READ\$1ACP 和 WRITE\$1ACP 权限 | 

**警告**  
在授予对您的 S3 存储桶和对象的访问权限时应谨慎使用。例如，授予对存储桶的 `WRITE` 权限将允许被授权者创建存储桶中的任何对象。我们强烈建议您在授予权限之前通读整个[访问控制列表 (ACL) 概述](#acl-overview)部分。

### ACL 权限和访问策略权限的映射
<a name="acl-access-policy-permission-mapping"></a>

如先前表中所示，相比于在访问策略中可设置的权限数目（请参阅[Amazon S3 的策略操作](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-actions)），ACL 仅允许授予有限数量的权限。其中的每个权限允许一个或多个 Amazon S3 操作。

下表显示每个 ACL 权限如何映射到相应的访问策略权限。正如您所见，与 ACL 相比，访问策略允许的权限更多。您可以将 ACL 主要用于授予基本的读/写权限（类似于文件系统权限）。有关何时使用 ACL 的更多信息，请参阅 [Amazon S3 的身份和访问管理](security-iam.md)。

有关使用 Amazon S3 控制台 ACL 权限的更多信息，请参阅 [配置 ACL](managing-acls.md)。


| ACL 权限 | 当在存储桶上授予 ACL 权限时的相应访问策略  | 当在对象上授予 ACL 权限时的相应访问策略 | 
| --- | --- | --- | 
| READ | s3:ListBucket、s3:ListBucketVersions 和 s3:ListBucketMultipartUploads  | s3:GetObject 和 s3:GetObjectVersion | 
| WRITE |  `s3:PutObject` 存储桶拥有者可以创建、覆写和删除存储桶中的任何对象，而对象拥有者对其对象拥有 `FULL_CONTROL`。 此外，如果被授权者是存储桶拥有者，使用存储桶 ACL 来授予 `WRITE` 许可将允许对该存储桶中的任意版本执行 `s3:DeleteObjectVersion` 操作。  | 不适用 | 
| READ\$1ACP | s3:GetBucketAcl  | s3:GetObjectAcl 和 s3:GetObjectVersionAcl | 
| WRITE\$1ACP | s3:PutBucketAcl | s3:PutObjectAcl 和 s3:PutObjectVersionAcl | 
| FULL\$1CONTROL | 等同于授予 READ、WRITE、READ\$1ACP 和 WRITE\$1ACP ACL 权限。因此，此 ACL 权限将映射到相应访问策略权限的组合。 | 等同于授予 READ、READ\$1ACP 和 WRITE\$1ACP ACL 权限。因此，此 ACL 权限将映射到相应访问策略权限的组合。 | 

### 条件键
<a name="acl-specific-condition-keys"></a>

授予访问策略权限时，您可以使用条件键通过存储桶策略对某个对象限制 ACL 的值。以下上下文键对应于 ACL。您可以使用这些上下文键强制在请求中使用特定 ACL：
+ `s3:x-amz-grant-read` ‐ 需要读取访问权限。
+ `s3:x-amz-grant-write` ‐ 需要写入访问权限。
+ `s3:x-amz-grant-read-acp` ‐ 需要对存储桶 ACL 的读取访问权限。
+ `s3:x-amz-grant-write-acp` ‐ 需要对存储桶 ACL 的写入访问权限。
+ `s3:x-amz-grant-full-control` ‐ 需要完全控制权限。
+ `s3:x-amz-acl` ‐ 需要一个 [标准 ACL](#canned-acl)。

有关涉及 ACL 特定标头的策略示例，请参阅[授予 s3:PutObject 权限，指定了要求存储桶拥有者获得完全控制的条件](example-bucket-policies-condition-keys.md#grant-putobject-conditionally-1)。有关 Amazon S3 特定条件键的完整列表，请参阅《Service Authorization Reference》**中的 [Actions, resources, and condition keys for Amazon S3](https://docs.amazonaws.cn/service-authorization/latest/reference/list_amazons3.html)。

有关按 S3 资源类型对 S3 API 操作的权限的更多信息，请参阅 [Amazon S3 API 操作所需的权限](using-with-s3-policy-actions.md)。

## 常见 Amazon S3 请求的 `aclRequired` 值
<a name="aclrequired-s3"></a>

要识别需要 ACL 进行授权的 Amazon S3 请求，您可以使用 Amazon S3 服务器访问日志或 Amazon CloudTrail 中的 `aclRequired` 值。CloudTrail 或 Amazon S3 服务器访问日志中显示的 `aclRequired` 值取决于调用了哪些操作以及有关请求者、对象拥有者和存储桶拥有者的某些信息。如果不需要 ACL，或者您正在设置 `bucket-owner-full-control` 标准 ACL，或者如果您的存储桶策略允许请求，则 Amazon S3 服务器访问日志中的 `aclRequired` 值字符串为“`-`”，但 CloudTrail 中不存在该值字符串。

下表列出了 CloudTrail 或 Amazon S3 服务器访问日志中各种 Amazon S3 API 操作的预期 `aclRequired` 值。您可以使用此信息来了解哪些 Amazon S3 操作依赖于 ACL 进行授权。在下表中，A、B 和 C 代表与请求者、对象拥有者和存储桶拥有者关联的不同账户。带有星号（\$1）的条目表示账户 A、B 或 C 中的任意一个。

**注意**  
除非另有说明，否则下表中的 `PutObject` 操作表示未设置 ACL 的请求，除非该 ACL 是 `bucket-owner-full-control` ACL。`aclRequired` 为 null 值表示 Amazon CloudTrail 日志中不存在 `aclRequired`。

 下表显示 CloudTrail 的 `aclRequired` 值。


| 操作名称 | 请求者 | 对象拥有者 | 存储桶拥有者  | 存储桶策略授予访问权限 | `aclRequired` 值 | Reason | 
| --- | --- | --- | --- | --- | --- | --- | 
| GetObject | A | A | A | 是或否 | null | 同一账户的访问 | 
| GetObject | A | B | A | 是或否 | null | 强制存储桶拥有者的同账户访问 | 
| GetObject | A | A | B | 是 | null | 存储桶策略授予的跨账户访问 | 
| GetObject | A | A | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| GetObject | A | A | B | 是 | null | 存储桶策略授予的跨账户访问 | 
| GetObject | A | B | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| GetObject | A | B | C | 是 | null | 存储桶策略授予的跨账户访问 | 
| GetObject | A | B | C | 否 | 是 | 跨账户访问依赖于 ACL | 
| PutObject | A | 不适用 | A | 是或否 | null | 同一账户的访问 | 
| PutObject | A | 不适用 | B | 是 | null | 存储桶策略授予的跨账户访问 | 
| PutObject | A | 不适用 | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| 使用 ACL 的 PutObject（bucket-owner-full-control 除外） | \$1 | 不适用 | \$1 | 是或否 | 是 | 请求授予 ACL | 
| ListObjects | A | 不适用 | A | 是或否 | null | 同一账户的访问 | 
| ListObjects | A | 不适用 | B | 是 | null | 存储桶策略授予的跨账户访问 | 
| ListObjects | A | 不适用 | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| DeleteObject | A | 不适用 | A | 是或否 | null | 同一账户的访问 | 
| DeleteObject | A | 不适用 | B | 是 | null | 存储桶策略授予的跨账户访问 | 
| DeleteObject | A | 不适用 | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| PutObjectAcl | \$1 | \$1 | \$1 | 是或否 | 是 | 请求授予 ACL | 
| PutBucketAcl | \$1 | 不适用 | \$1 | 是或否 | 是 | 请求授予 ACL | 

 

**注意**  
除非另有说明，否则下表中的 `REST.PUT.OBJECT` 操作表示未设置 ACL 的请求，除非该 ACL 是 `bucket-owner-full-control` ACL。`aclRequired` 值字符串为“`-`”表示 Amazon S3 服务器访问日志中的 null 值。

 下表显示 Amazon S3 服务器访问日志的 `aclRequired` 值。


| 操作名称 | 请求者 | 对象拥有者 | 存储桶拥有者  | 存储桶策略授予访问权限 | `aclRequired` 值 | Reason | 
| --- | --- | --- | --- | --- | --- | --- | 
| REST.GET.OBJECT | A | A | A | 是或否 | - | 同一账户的访问 | 
| REST.GET.OBJECT | A | B | A | 是或否 | - | 强制存储桶拥有者的同账户访问 | 
| REST.GET.OBJECT | A | A | B | 是 | - | 存储桶策略授予的跨账户访问 | 
| REST.GET.OBJECT | A | A | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| REST.GET.OBJECT | A | B | B | 是 | - | 存储桶策略授予的跨账户访问 | 
| REST.GET.OBJECT | A | B | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| REST.GET.OBJECT | A | B | C | 是 | - | 存储桶策略授予的跨账户访问 | 
| REST.GET.OBJECT | A | B | C | 否 | 是 | 跨账户访问依赖于 ACL | 
| REST.PUT.OBJECT | A | 不适用 | A | 是或否 | - | 同一账户的访问 | 
| REST.PUT.OBJECT | A | 不适用 | B | 是 | - | 存储桶策略授予的跨账户访问 | 
| REST.PUT.OBJECT | A | 不适用 | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| 使用 ACL 的 REST.PUT.OBJECT（bucket-owner-full-control 除外） | \$1 | 不适用 | \$1 | 是或否 | 是 | 请求授予 ACL | 
| REST.GET.BUCKET | A | 不适用 | A | 是或否 | - | 同一账户的访问 | 
| REST.GET.BUCKET | A | 不适用 | B | 是 | - | 存储桶策略授予的跨账户访问 | 
| REST.GET.BUCKET | A | 不适用 | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| REST.DELETE.OBJECT | A | 不适用 | A | 是或否 | - | 同一账户的访问 | 
| REST.DELETE.OBJECT | A | 不适用 | B | 是 | - | 存储桶策略授予的跨账户访问 | 
| REST.DELETE.OBJECT | A | 不适用 | B | 否 | 是 | 跨账户访问依赖于 ACL | 
| REST.PUT.ACL | \$1 | \$1 | \$1 | 是或否 | 是 | 请求授予 ACL | 

## 示例 ACL
<a name="sample-acl"></a>

下面的存储桶上的示例 ACL 可识别资源所有者和一系列的授权。格式是指 Amazon S3 REST API 中的 ACL 的 XML 表示形式。存储桶拥有者拥有资源的 `FULL_CONTROL`。此外，ACL 还演示了如何将对于某个资源的权限授予两个 Amazon Web Services 账户（由规范用户 ID 标识）以及上一节讨论的两个预定义 Amazon S3 组。

**Example**  

```
 1. <?xml version="1.0" encoding="UTF-8"?>
 2. <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
 3.   <Owner>
 4.     <ID>Owner-canonical-user-ID</ID>
 5.   </Owner>
 6.   <AccessControlList>
 7.     <Grant>
 8.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
 9.         <ID>Owner-canonical-user-ID</ID>
10.       </Grantee>
11.       <Permission>FULL_CONTROL</Permission>
12.     </Grant>
13.     
14.     <Grant>
15.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
16.         <ID>user1-canonical-user-ID</ID>
17.       </Grantee>
18.       <Permission>WRITE</Permission>
19.     </Grant>
20. 
21.     <Grant>
22.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
23.         <ID>user2-canonical-user-ID</ID>
24.       </Grantee>
25.       <Permission>READ</Permission>
26.     </Grant>
27. 
28.     <Grant>
29.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
30.         <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> 
31.       </Grantee>
32.       <Permission>READ</Permission>
33.     </Grant>
34.     <Grant>
35.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
36.         <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI>
37.       </Grantee>
38.       <Permission>WRITE</Permission>
39.     </Grant>
40. 
41.   </AccessControlList>
42. </AccessControlPolicy>
```

## 标准 ACL
<a name="canned-acl"></a>

Amazon S3 支持一系列预定义的授权，称为*标准 ACL*。每个标准 ACL 都有一组预定义的被授权者和许可。下表列出了一系列标准 ACL 和相关联的预定义授权。


| 标准 ACL | 适用于 | 添加到 ACL 的权限 | 
| --- | --- | --- | 
| private | 存储桶和对象 | 所有者将获得 FULL\$1CONTROL。其他人没有访问权限 (默认)。 | 
| public-read | 存储桶和对象 | 所有者将获得 FULL\$1CONTROL。AllUsers 组 (参阅 [谁是被授权者？](#specifying-grantee)) 将获得 READ 访问权限。 | 
| public-read-write | 存储桶和对象 | 所有者将获得 FULL\$1CONTROL。AllUsers 组将获得 READ 和 WRITE 访问权限。通常不建议在存储桶上授予该权限。 | 
| aws-exec-read | 存储桶和对象 | 所有者将获得 FULL\$1CONTROL。Amazon EC2 从 Amazon S3 获取对 READ Amazon Machine Image (AMI) 服务包的 GET 访问权限。 | 
| authenticated-read | 存储桶和对象 | 所有者将获得 FULL\$1CONTROL。AuthenticatedUsers 组将获得 READ 访问权限。 | 
| bucket-owner-read | 对象 | 对象所有者将获得 FULL\$1CONTROL。存储桶拥有者将获得 READ 访问权限。如果您在创建存储段时指定此标准的 ACL，Amazon S3 将忽略它。 | 
| bucket-owner-full-control | 对象  | 对象所有者和存储桶拥有者均可获得对对象的 FULL\$1CONTROL。如果您在创建存储段时指定此标准的 ACL，Amazon S3 将忽略它。 | 
| log-delivery-write | 存储桶  | LogDelivery 组将获得针对存储桶的 WRITE 和 READ\$1ACP 许可。有关日志的更多信息，请参阅（[使用服务器访问日志记录来记录请求](ServerLogs.md)）。 | 

**注意**  
您可以在请求中仅指定这些标准 ACL 中的一个。

您可以使用 `x-amz-acl` 请求标头在请求中指定标准 ACL。当 Amazon S3 收到包含标准 ACL 的请求时，它会向资源的 ACL 添加预定义的授权。