# Amazon Identity and Access Management 中的策略和权限
在 Amazon 中通过创建策略并将其附加到 IAM 身份（用户、用户组或角色）或 Amazon 资源来管理访问权限。策略是 Amazon 中的对象；在与身份或资源相关联时，策略定义它们的权限。在某个 IAM 主体（用户或角色）发出请求时，Amazon 将评估这些策略。策略中的权限确定是允许还是拒绝请求。大多数策略作为 JSON 文档存储在 Amazon 中。Amazon 支持七种类型的策略：基于身份的策略、基于资源的策略、权限边界、Amazon Organizations 服务控制策略（SCP）、Amazon Organizations 资源控制策略（RCP）、访问控制列表（ACL）和会话策略。
IAM 策略定义操作的权限，无关乎您使用哪种方法执行操作。例如，如果一个策略允许 [GetUser](https://docs.amazonaws.cn/IAM/latest/APIReference/API_GetUser.html) 操作，则具有该策略的用户可以从 Amazon Web Services 管理控制台、Amazon CLI 或 Amazon API 获取用户信息。在创建 IAM 用户时，您可以选择允许控制台或编程访问。如果允许控制台访问，则 IAM 用户可以使用其登录凭证登录到控制台。如果允许编程访问，则用户可以通过访问密钥来使用 CLI 或 API。
## 策略类型
以下策略类型按从最常用到不常用的顺序列出，可在 Amazon 中使用。有关更多详细信息，请参阅下面有关各种策略类型的各部分。
+ **[基于身份的策略](#policies_id-based)** – 将[托管](#managedpolicy)策略和[内联](#inline)策略附加到 IAM 身份（用户、用户所属组或角色）。基于身份的策略向身份授予权限。
+ **[基于资源的策略](#policies_resource-based)** - 将内联策略附加到资源。基于资源的策略的最常见示例是 Amazon S3 存储桶策略和 IAM 角色信任策略。基于资源的策略向在策略中指定的主体授予权限。主体可以与资源位于同一个账户中，也可以位于其他账户中。
+ **[权限边界](#policies_bound)** - 使用托管策略作为 IAM 实体（用户或角色）的权限边界。该策略定义基于身份的策略可以授予实体的最大权限，但不授予权限。权限边界不定义基于资源的策略可以授予实体的最大权限。
+ **[Amazon Organizations SCP](#policies_scp)**：使用 Amazon Organizations 服务控制策略（SCP）为组织或组织单位（OU）的账户的 IAM 用户和 IAM 角色定义最大权限。SCP 限制基于身份的策略或基于资源的策略授予账户中的 IAM 用户或 IAM 角色的权限。SCP 不授予权限。
+ **[Amazon Organizations RCP](#policies_rcp)**：使用 Amazon Organizations 资源控制策略（RCP）为组织或组织单位（OU）中账户内的资源定义最大权限。RCP 限制了基于身份和基于资源的策略可以向组织内账户中的资源授予的权限。RCP 不授予权限。
+ **[访问控制列表 (ACL)](#policies_acl)** - 使用 ACL 来控制其他账户中的哪些主体可以访问 ACL 附加到的资源。ACL 类似于基于资源的策略，但它们是唯一不使用 JSON 策略文档结构的策略类型。ACL 是跨账户的权限策略，向指定的主体授予权限。ACL 不能向同一账户内的实体授予权限。
+ **[会话策略](#policies_session)** - 在您使用 Amazon CLI 或 Amazon API 担任某个角色或联合身份用户时，传递高级会话策略。会话策略限制角色或用户的基于身份的策略授予会话的权限。会话策略限制所创建会话的权限，但不授予权限。有关更多信息，请参阅[会话策略](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies.html#policies_session)。
### 基于身份的策略
基于身份的策略是 JSON 权限的策略文档，用于控制身份（用户、用户组和角色）可在什么样的条件下对哪些资源执行哪些操作。基于身份的策略可以进一步分类：
+ **托管策略** – 基于身份的独立策略，可附加到您的 Amazon Web Services 账户 中的多个用户、组和角色。有两种托管策略：
+ **Amazon 托管策略** - 由 Amazon 创建和管理的托管策略。
+ **客户管理型策略** – 您在 Amazon Web Services 账户 中创建和管理的管理型策略。与 Amazon 托管策略相比，客户托管策略可以更精确地控制策略。
+ **内联策略** — 直接添加到单个用户、组或角色的策略。内联策略维持策略与身份之间严格的一对一关系。当您删除身份时，它们将会被删除。
要了解如何在托管策略或内联策略之间选择，请参阅 [在托管策略与内联策略之间进行选择](access_policies-choosing-managed-or-inline.md)。
### 基于资源的策略
基于资源的策略是附加到资源（如 Amazon S3 存储桶）的 JSON 策略文档。这些策略授予指定的主体对该资源执行特定操作的权限，并定义这在哪些条件下适用。基于资源的策略是内联策略。没有基于托管资源的策略。
要启用跨账户存取，您可以将整个账户或其它账户中的 IAM 实体指定为基于资源的策略中的主体。将跨账户主体添加到基于资源的策略只是建立信任关系工作的一半而已。当主体和资源位于单独的 Amazon Web Services 账户 中时，还必须使用基于身份的策略来授予对资源的主体访问权限。但是，如果基于资源的策略向同一个账户中的主体授予访问权限，则不需要额外的基于身份的策略。有关授予跨服务访问权限的分步说明，请参阅 [IAM 教程：使用 IAM 角色委托跨 Amazon 账户的访问权限](tutorial_cross-account-with-roles.md)。
IAM 服务仅支持一种类型的基于资源的策略（称为角色*信任策略*），这种策略附加到 IAM 角色。IAM 角色既是身份，又是支持基于资源的策略的资源。因此，您必须将信任策略和基于身份的策略同时附加到 IAM 角色。信任策略定义哪些主体实体（账户、用户、角色和联合身份用户）可以代入该角色。要了解 IAM 角色如何与其他基于资源的策略不同，请参阅 [IAM 中的跨账户资源访问](access_policies-cross-account-resource-access.md)。
要了解哪些其他服务支持基于资源的策略，请参阅[使用 IAM 的 Amazon 服务](reference_aws-services-that-work-with-iam.md)。要了解基于资源的策略的更多信息，请参阅 [基于身份的策略和基于资源的策略](access_policies_identity-vs-resource.md)。要了解您信任区域之外的账户（受信任的企业或账户）中的主体是否有权承担您的角色，请参阅[什么是 IAM Access Analyzer？](https://docs.amazonaws.cn/IAM/latest/UserGuide/what-is-access-analyzer.html)。
### IAM 权限边界
权限边界是一项高级功能，借助该功能，您可以设置基于身份的策略可以授予 IAM 实体的最大权限。当您设置实体的权限边界时，该实体只能执行其基于身份的策略和其权限边界同时允许的操作。如果您在基于资源的策略的主体元素中指定角色会话或用户，则无需在权限边界内显式允许。但是，如果您在基于资源的策略的主体元素中指定角色 ARN，则需要在权限边界内显式允许。在这两种情况下，在权限边界内显式拒绝都是有效的。任一项策略中的显式拒绝将覆盖允许。有关权限边界的更多信息，请参阅[IAM 实体的权限边界](access_policies_boundaries.md)。
### Amazon Organizations 服务控制策略（SCP）
如果在组织内启用了所有特征，则可对任意或全部账户应用服务控制策略（SCP）。SCP 是为组织或组织单位（OU）的账户内的 IAM 用户和 IAM 角色指定最大权限的 JSON 策略。SCP 限制成员账户中主体（包括每个 Amazon Web Services 账户根用户）的权限。任一项策略中的显式拒绝将覆盖其他策略中的允许。
有关 Amazon Organizations 和 SCP 的更多信息，请参阅*《Amazon Organizations 用户指南》*中的[服务控制策略 (SCP)](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps.html)。
### Amazon Organizations 资源控制策略（RCP）
如果在组织内启用了所有功能，则可使用资源控制策略（RCP）在多个 Amazon Web Services 账户内对资源集中应用访问控制。RCP 是 JSON 策略，您可以使用它们设置账户中资源的最大可用权限，而无需更新附加到您拥有的每个资源的 IAM 策略。RCP 限制了成员账户中资源的权限，并可能影响身份（包括 Amazon Web Services 账户根用户）的有效权限，无论这些身份是否属于您的组织。任何适用的 RCP 中的显式拒绝将覆盖可能附加到个人身份或资源的其他策略中的允许。
有关 Amazon Organizations 和 RCP（包括支持 RCP 的 Amazon Web Services 服务 列表）的更多信息，请参阅*《Amazon Organizations 用户指南》*中的[资源控制策略 (RCP)](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_rcps.html)。
### 访问控制列表（ACL）
访问控制列表 (ACL) 是一种服务策略，允许您控制另一个账户中的哪些主体可以访问资源。不能使用 ACL 控制同一账户中的主体的访问权限。ACL 类似于基于资源的策略，但它们是唯一不使用 JSON 策略文档格式的策略类型。Amazon S3、Amazon WAF 和 Amazon VPC 是支持 ACL 的服务示例。要了解有关 ACL 的更多信息，请参阅《Amazon Simple Storage Service 开发人员指南》**中的[访问控制列表（ACL）概述](https://docs.amazonaws.cn/AmazonS3/latest/userguide/acl-overview.html)。
### 会话策略
会话策略是当您以编程方式为角色或 Amazon STS 联合用户主体创建临时会话时作为参数传递的高级策略。会话的权限是用于创建会话的 IAM 实体（用户或角色）的基于身份的策略与会话策略的交集。权限也可以来自基于资源的策略。任一项策略中的显式拒绝将覆盖允许。
您可以使用 `AssumeRole`、`AssumeRoleWithSAML` 或 `AssumeRoleWithWebIdentity` API 操作以编程方式创建角色会话和传递会话策略。您可以使用 `Policy` 参数传递单个 JSON 内联会话策略文档。您可以使用 `PolicyArns` 参数指定最多 10 个托管会话策略。有关创建角色会话的更多信息，请参阅 [临时安全凭证的权限](id_credentials_temp_control-access.md)。
当您创建 Amazon STS 联合用户主体会话时，您使用 IAM 用户的访问密钥以编程方式调用 `GetFederationToken` API 操作。您还必须传递会话策略。生成的会话的权限是基于身份的策略与会话策略的交集。有关创建联合身份用户的更多信息，请参阅 [通过自定义身份凭证代理程序请求凭证](id_credentials_temp_request.md#api_getfederationtoken)。
基于资源的策略可以将用户或角色的 ARN 指定为主体。在这种情况下，在创建会话之前，将在角色或用户的基于身份的策略中添加基于资源的策略中的权限。会话策略限制由基于资源的策略和基于身份的策略授予的总权限。生成的会话权限是会话策略与基于资源的策略的交集以及会话策略与基于身份的策略的交集。
![\[评估会话策略以及指定实体 ARN 的基于资源的策略\]](http://docs.amazonaws.cn/IAM/latest/UserGuide/images/EffectivePermissions-session-rbp-id.png)
基于资源的策略可以将会话的 ARN 指定为主体。在这种情况下，在创建会话后，将添加基于资源的策略中的权限。基于资源的策略权限不受会话策略限制。生成的会话具有基于资源的策略中的所有权限*以及* 基于身份的策略与会话策略的交集。
![\[评估会话策略以及指定会话 ARN 的基于资源的策略\]](http://docs.amazonaws.cn/IAM/latest/UserGuide/images/EffectivePermissions-session-rbpsession-id.png)
权限边界可以设置用于创建会话的用户或角色的最大权限。在这种情况下，生成的会话的权限是会话策略、权限边界和基于身份的策略的交集。不过，权限边界不会限制指定生成的会话 ARN 基于资源的策略授予权限。
![\[评估会话策略以及权限边界\]](http://docs.amazonaws.cn/IAM/latest/UserGuide/images/EffectivePermissions-session-boundary-id.png)
## 策略和根用户
Amazon Web Services 账户根用户 会受到一些策略类型的影响，但不会受其他策略类型的影响。您不能将基于身份的策略附加到根用户，也不能为根用户设置权限边界。不过，您可以在基于资源的策略或 ACL 中将根用户指定为主体。根用户仍然是账户的成员。如果该账户是 Amazon Organizations 中的组成成员，则根用户受账户的 SCP 和 RCP 影响。
## JSON 策略概述
大多数策略在 Amazon 中存储为 JSON 文档。基于身份的策略和用于设置权限边界的策略是您附加到用户或角色的 JSON 策略文档。基于资源的策略是附加到资源的 JSON 策略文档。SCP 和 RCP 是附加到 Amazon Organizations 的组织根、组织单位（OU）或账户的使用限制语法的 JSON 策略文档。ACL 也可附加到资源，但必须使用不同的语法。会话策略是您在创建角色或联合身份用户会话时提供的 JSON 策略。
您无需了解 JSON 语法。您可以使用 Amazon Web Services 管理控制台中的可视化编辑器创建和编辑客户托管策略，而无需使用 JSON。不过，如果在组中使用内联策略或复杂的策略，您还必须使用控制台在 JSON 编辑器中创建和编辑这些策略。有关使用可视化编辑器的更多信息，请参阅[使用客户管理型策略定义自定义 IAM 权限](access_policies_create.md)和[编辑 IAM 策略](access_policies_manage-edit.md)。
当您创建或编辑 JSON 策略时，IAM 可以执行策略验证以帮助您创建有效的策略。IAM 可识别 JSON 语法错误，而 IAM Access Analyzer 将提供额外的策略检查和建议，以帮助您进一步优化策略。要了解策略验证的更多信息，请参阅 [IAM 策略验证](access_policies_policy-validator.md)。要了解有关 IAM Access Analyzer 策略检查和可执行建议的更多信息，请参阅 [IAM Access Analyzer 策略验证](https://docs.amazonaws.cn/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。
### JSON 策略文档结构
如下图所示，JSON 策略文档包含以下元素：
+ 文档顶部的可选策略范围信息
+ 一个或多个单独语句**
每个语句都包含有关单个权限的信息。如果一个策略包含多个语句，则 Amazon 会在评估它们时跨这些语句应用逻辑 `OR`。如果有多个策略应用于请求，则 Amazon 会在评估它们时跨所有这些策略应用逻辑 `OR`。
![\[JSON 策略文档结构\]](http://docs.amazonaws.cn/IAM/latest/UserGuide/images/AccessPolicyLanguage_General_Policy_Structure.diagram.png)
语句中的信息均含在一系列的元素内。
+ **Version** - 指定要使用的策略语言版本。建议您使用最新的 `2012-10-17 ` 版本。有关更多信息，请参阅 [IAM JSON 策略元素：Version](reference_policies_elements_version.md)。
+ **Statement** - 将该主要策略元素作为以下元素的容器。可以在一个策略中包含多个语句。
+ **Sid**（可选） - 包括可选的语句 ID 以区分不同的语句。
+ **Effect** - 使用 `Allow` 或 `Deny` 指示策略是允许还是拒绝访问。
+ **Principal**（在某些情况下需要）- 如果创建基于资源的策略，则必须指示要允许或拒绝访问的账户、用户、角色或 Amazon STS 联合用户主体。如果要创建 IAM 权限策略以附加到用户或角色，则不能包含该元素。主体暗示为该用户或角色。
+ **Action** - 包括策略允许或拒绝的操作列表。
+ **Resource**（在某些情况下需要）- 如果创建 IAM 权限策略，则必须指定操作适用的资源列表。如果创建基于资源的策略，则是否需要此元素取决于您使用的资源。
+ **Condition**（可选） - 指定策略在哪些情况下授予权限。
要了解上述及其他更高级的策略元素，请参阅[IAM JSON 策略元素参考](reference_policies_elements.md)。
### 多个声明和多个策略
如果要为实体（用户或角色）定义多个权限，您可以在单个策略中使用多个语句。您也可以附加多个策略。如果您尝试在单个语句中定义多个权限，则策略可能没有授予预期访问权限。建议您按资源类型分解策略。
由于[策略的大小有限](reference_iam-quotas.md)，可能需要对更复杂的权限使用多个策略。在单独的客户托管策略中创建权限的功能分组也是个好主意。例如，为 IAM 用户管理创建一个策略，为自我管理创建一个策略，并为 S3 存储桶管理创建另一个策略。无论多个语句和多个策略如何组合，Amazon 都会以相同方式[评估](reference_policies_evaluation-logic.md)您的策略。
例如，以下策略具有三个语句，其中每个语句在单个账户中定义一组单独的权限。这些语句定义以下权限：
+ `Sid`（语句 ID）为 `FirstStatement` 的第一个语句让具有附加策略的用户更改自己的密码。该语句中的 `Resource` 元素是“`*`”（这表示“所有资源”）。但实际上，`ChangePassword` API 操作（或等效的 `change-password` CLI 命令）仅影响发出请求的用户的密码。
+ 第二个语句使用户可以列出其 Amazon Web Services 账户 中的所有 Amazon S3 存储桶。该语句中的 `Resource` 元素是 `"*"`（这表示“所有资源”）。但由于策略没有为其他账户中的资源授予访问权限，因此，用户只能列出自己的 Amazon Web Services 账户 中的存储桶。
+ 第三个语句允许用户列出和检索名为 `amzn-s3-demo-bucket-confidential-data` 的存储桶中的任何对象，但是仅当使用 Multi-Factor Authentication (MFA) 对用户进行了身份验证时才能如此。策略中的 `Condition` 元素将强制实施 MFA 身份验证。
如果策略语句包含 `Condition` 元素，则仅当 `Condition` 元素计算为 true 时，语句才有效。在此示例中，`Condition` 在用户进行了 MFA 身份验证时计算为 true。如果用户没有进行 MFA 身份验证，则此 `Condition` 计算为 false。在这种情况下，此策略中的第三个语句不会应用，因此用户将无法访问 `amzn-s3-demo-bucket-confidential-data` 存储桶。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FirstStatement",
"Effect": "Allow",
"Action": ["iam:ChangePassword"],
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data",
"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}
```
------
### JSON 策略语法示例
以下基于身份的策略允许暗示的主体列出名为 `amzn-s3-demo-bucket` 的单个 Amazon S3 存储桶：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
```
------
以下基于资源的策略可附加到 Amazon S3 存储桶。此策略允许特定 Amazon Web Services 账户 的成员在名为 `amzn-s3-demo-bucket` 的存储桶中执行任何 Amazon S3 操作。它允许可对存储桶或其中的对象执行的任何操作。(因为该策略仅向该账户授予信任，所以仍必须向该账户中的各个用户授予执行指定 Amazon S3 操作的权限。)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}
```
------
要查看常见方案的示例策略，请参阅[IAM 基于身份的策略示例](access_policies_examples.md)。
## 授予最低权限
创建 IAM policy 时，请遵循授予*最小权限*这一标准安全建议，或仅授予执行任务所需的权限。确定用户和角色需要执行的操作，然后制订允许他们*仅*执行这些任务的策略。
最开始只授予最低权限，然后根据需要授予其它权限。这样做比起一开始就授予过于宽松的权限而后再尝试收紧权限来说更为安全。
作为最低权限的替代方案，您可以使用 [Amazon 托管策略](access_policies_managed-vs-inline.md#aws-managed-policies) 或带通配符 `*` 权限的策略开始使用策略。考虑授予您的主体超出其完成工作所需的更多权限所带来的安全风险。监控这些主体以了解他们正在使用哪些权限。然后写入最低权限策略。
IAM 提供了多个选项来帮助您优化授予的权限。
+ **了解访问级别分组** - 您可以使用访问级别分组来了解策略授予的访问级别。[策略操作](reference_policies_elements_action.md)被归类为 `List`、`Read`、`Write`、`Permissions management` 或 `Tagging`。例如，您可以从 `List` 和 `Read` 访问级别中选择操作，以向您的用户授予只读访问权限。要了解如何使用策略摘要来了解访问级别权限，请参阅 [策略摘要中的访问级别](access_policies_understand-policy-summary-access-level-summaries.md)。
+ **验证您的策略** — 您可以在创建和编辑 JSON 策略时使用 IAM Access Analyzer 执行策略验证。我们建议您查看和验证所有现有策略。IAM Access Analyzer 提供 100 多项策略检查来验证您的策略。当您策略中的语句允许我们认为过于宽容的访问时，它会生成安全警告。在授予最小权限时，您可以使用通过安全警告提供的可操作建议。要了解有关 IAM Access Analyzer 提供的策略检查的更多信息，请参阅 [IAM Access Analyzer 策略验证](https://docs.amazonaws.cn/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。
+ **基于访问活动生成策略** — 为了帮助您优化授予的权限，您可以根据 IAM 实体（用户或角色）的访问活动生成 IAM policy。IAM 访问分析器会查看您的 Amazon CloudTrail 日志并生成一个策略模板，其中包含实体在指定时间框架内使用的权限。您可以使用模板创建具有精细权限的托管策略，然后将其附加到 IAM 实体。这样，您仅需授予用户或角色与特定使用案例中的 Amazon 资源进行交互所需的权限。有关更多信息，请参阅 [IAM Acess Analyzer 策略生成](https://docs.amazonaws.cn/IAM/latest/UserGuide/access-analyzer-policy-generation.html)。
+ **使用上次访问的信息** — 另一项可帮助提供最低权限的功能是*上次访问的信息*。可以在 IAM 控制台详细信息页面上的**访问顾问**选项卡中查看此信息，以了解 IAM 用户、组、角色或策略。上次访问的信息还包括有关上次访问某些服务（如 Amazon EC2、IAM、Lambda 和 Amazon S3）的操作的信息。如果您使用 Amazon Organizations 管理账户凭证登录，则可以在 IAM 控制台的 **Amazon Organizations** 部分查看上次访问的服务信息。也可以使用 Amazon CLI 或 Amazon API 为 IAM 或 Amazon Organizations 中的实体或策略检索上次访问的信息报告。您可以使用此信息确定不必要的权限，从而优化 IAM 或 Amazon Organizations 策略以更好地遵循最低权限原则。有关更多信息，请参阅 [使用上次访问的信息优化 Amazon 中的权限](access_policies_last-accessed.md)。
+ **查看 Amazon CloudTrail 中的账户事件** — 要进一步减少权限，您可以在 Amazon CloudTrail **Event history**（事件历史记录）中查看您的账户事件。CloudTrail 事件日志包含详细的事件信息，您可以用来减少策略的权限。这些日志仅包含 IAM 实体所需的操作和资源。有关更多信息，请参阅 *Amazon CloudTrail 用户指南*中的[在 CloudTrail 控制台中查看 CloudTrail 事件](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html)。
有关更多信息，请参阅以下单个服务的策略主题，其中提供了如何针对特定产品的资源编写策略的示例。
+ 《Amazon DynamoDB 开发人员指南》**中的[将基于资源的策略用于 DynamoDB](https://docs.amazonaws.cn/amazondynamodb/latest/developerguide/access-control-resource-based.html)
+ 《Amazon Simple Storage Service 用户指南》**中的 [Amazon S3 的存储桶策略](https://docs.amazonaws.cn/AmazonS3/latest/userguide/bucket-policies.html)
+ 《Amazon Simple Storage Service 用户指南》**中的[访问控制列表（ACL）概述](https://docs.amazonaws.cn/AmazonS3/latest/userguide/acl-overview.html)