访问控制列表 (ACL)

转到示例

本页面简要介绍访问控制列表 (ACL)。若要了解如何以其他方式控制对存储分区和对象的访问，请阅读访问权限控制概览。

您应该使用访问控制列表吗？

大多数情况下，我们建议您使用 Identity and Access Management (IAM) 来控制对您资源的访问：

  • IAM 提供跨所有 Google Cloud 的访问权限控制。
  • IAM 可以更好地控制用户可以执行的操作。
  • 授予父资源（例如项目）的 IAM 权限由子资源（如存储桶和对象）继承，可让您更轻松地管理对资源的访问权限。
  • ACL 不能仅用于控制对资源的访问权限，因为无法对整个项目或其他父级资源设置 ACL。

仅使用 IAM 并启用统一存储桶级访问权限可让您使用其他 Google Cloud 安全功能，例如网域限定共享、员工身份联合和 IAM Conditions。

您很可能在以下情况下使用 ACL：

  • 您需要自定义对存储桶中个别对象的访问权限。可以针对个别对象设置 ACL，而 IAM 权限只能在存储桶级层或更高级层授予。
  • 您仅使用 XML API，或者需要与 Amazon S3 进行互操作。

若要授予对您的存储桶和对象的访问权限，则需配合使用 IAM 和 ACL，也就是说，用户只需要来自上述任一系统的相关权限即可访问存储桶或对象。

什么是访问控制列表？

访问控制列表 (ACL) 是一种机制，可用于定义谁有权访问您的存储桶和对象，以及他们具有何种级别的访问权限。在 Cloud Storage 中，ACL 适用于个别存储桶和对象。每个 ACL 包含一个或多个条目。每个条目指定了特定用户（或组）可以执行的特定操作，其中包含两部分信息：

  • 权限，此部分信息定义可执行哪些操作（例如读取或写入）。

  • 范围（有时称为授予对象），此部分信息定义谁可以执行指定操作（例如，某一特定用户或一组用户）。

例如，假设您希望任何人都能够访问您存储分区中的对象，但您还希望协作者能够在此存储分区中添加或移除对象。在这种情况下，您的 ACL 应包含两个条目：

  • 一个条目为 allUsers 组授予 READER 权限。

  • 另一个条目在协作者范围内授予 WRITER 权限（可通过多种方式指定此用户，例如，通过其电子邮件）。

对于一个存储分区或对象，您最多可以创建 100 个 ACL 条目。如果条目适用的范围是一个组或网域，则无论组或网域中有多少用户，系统均计为一个 ACL 条目。

如果用户请求访问某一存储桶或对象，Cloud Storage 系统会读取该存储桶或对象 ACL，并确定是允许还是拒绝访问请求。如果 ACL 为该用户授予了请求操作所需的权限，系统会允许该请求。如果 ACL 未向该用户授予请求操作所需的权限，系统则会拒绝该请求并返回 403 Forbidden 错误。

请注意，虽然您可以使用 ACL 来管理大部分涉及存储分区和对象的操作，但能否创建存储分区取决于您是否具有适当的项目权限。

权限

权限描述针对给定对象或存储分区可以执行哪些操作。

通过 Cloud Storage，您可以分配存储分区和对象的以下同心权限，如下表所示：

存储分区 对象
READER 允许用户列出存储分区的内容。还允许用户读取存储分区元数据（不包括 ACL）。 允许用户下载对象的数据。
WRITER 为用户授予 READER 权限授予的所有访问权限。此外，还允许用户创建、替换和删除存储桶中的对象，包括使用分段上传创建对象。 不适用。您不能将此权限应用于对象。
OWNER 为用户授予 WRITER 权限授予的所有访问权限。还允许用户读取和写入存储桶元数据（包括 ACL），并在存储桶上使用标记。 为用户授予 READER 权限授予的所有访问权限。还允许用户读取和写入对象元数据（包括 ACL）。
默认 创建存储桶时，系统会对存储桶应用预定义的项目专用 ACL。存储桶的所有权始终属于 project-owners 组。 上传对象时，系统会对对象应用预定义的项目专用 ACL。对象的所有权始终属于上传了相应对象的原始请求者。

在本页面中，我们通常将权限称为 READER、WRITER 和 OWNER，在 JSON API 和 Google Cloud Console 中这些权限也是这样指定的。如果您使用的是 XML API，则等效权限分别为 READ、WRITE 和 FULL_CONTROL。如果您使用 OAuth 2.0 身份验证来对代表您访问 Google Cloud Storage API 的工具和应用进行身份验证（为其授予权限），则访问权限会被限制在 OAuth 范围 devstorage.read_only、devstorage.read_write 和 devstorage.full_control。下表总结了您会经常遇到的权限方面的一些术语：

JSON API XML API OAuth2 范围
READER READ https://www.googleapis.com/auth/devstorage.read_only
WRITER WRITE https://www.googleapis.com/auth/devstorage.read_write
OWNER FULL_CONTROL https://www.googleapis.com/auth/devstorage.full_control

范围

范围指定谁具有指定权限。

ACL 由一个或多个条目组成，其中的每个条目会向某一范围授予权限。您可以使用以下任何实体指定 ACL 范围：

范围（“受益者”） 实体类型 示例
Google 帐号电子邮件地址 用户 collaborator@gmail.com
Google 群组电子邮件设置 群组 work-group@googlegroups.com
为项目方便而使用的值 项目 owners-123456789012
Google Workspace 网域 网域 USERNAME@YOUR_DOMAIN.com
Cloud Identity 网域 网域 USERNAME@YOUR_DOMAIN.com
适用于所有 Google 帐号拥有者的特殊标识符 用户 allAuthenticatedUsers
适用于所有用户的特殊标识符 用户 allUsers

  • Google 帐号电子邮件地址：

    所有拥有 Google 帐号的用户都必须拥有一个与该帐号相关联的唯一电子邮件地址。您可以使用与 Google 帐号关联的任何电子邮件地址（如 gmail.com 地址）指定范围。

    Cloud Storage 会识别 ACL 中提供的电子邮件地址，除非相应条目被移除或替换。如果用户更改了电子邮件地址，您应对 ACL 条目进行更新以反映这些更改。

  • Google 群组电子邮件地址：

    每个 Google 群组都有一个关联的唯一电子邮件地址。例如，Cloud Storage Announce 群组具有以下电子邮件地址：gs-announce@googlegroups.com。您可以通过点击任意 Google 群组主页上的关于来找到与 Google 群组关联的电子邮件地址。

    与 Google 帐号电子邮件地址一样，Cloud Storage 会识别 ACL 中提供的群组电子邮件地址，除非相应条目被移除。您不必担心更新 Google 群组电子邮件地址，因为 Google 群组电子邮件地址是永久性的，不太可能更改。

  • 为项目方便而使用的值：

    便利值使您可以向项目的查看者、编辑者和所有者授予批量访问权限。便利值结合了项目角色和关联的项目编号。例如，在项目 867489160491 中，编辑者可标识为 editors-867489160491。您可以在 Google Cloud Console 主页上找到您的项目编号。

    您通常应该在生产环境中避免使用便利值，因为它们需要授予基本角色，不建议在生产环境中执行这样的操作。

  • Google Workspace 或 Cloud Identity：

    Google Workspace 和 Cloud Identity 客户可以将其电子邮件帐号与互联网域名相关联。若要执行此操作，每个电子邮件帐号均应采用 USERNAME@YOUR_DOMAIN.com 形式。您可以使用与 Google Workspace 或 Cloud Identity 关联的任何互联网域名指定范围。

  • 适用于所有 Google 帐号拥有者的特殊标识符：

    此特殊范围标识符代表所有使用 Google 帐号进行身份验证的人。适用于所有 Google 帐号拥有者的特殊范围标识符为 allAuthenticatedUsers。请注意，虽然此标识符是 User 实体类型，但是在使用 Google Cloud 控制台时，它会被标记为 Public 实体类型。

  • 适用于所有用户的特殊标识符：

    此特殊范围标识符代表互联网上的任何人（无论是否拥有 Google 帐号）。适用于所有用户的特殊范围标识符为 allUsers。请注意，虽然此标识符是 User 实体类型，但是在使用 Google Cloud 控制台时，它会被标记为 Public 实体类型。

同心权限和范围

如果在 Cloud Storage 中指定了 ACL，您无需列出多个范围也能授予多项权限。Cloud Storage 使用同心权限，因此，授予 WRITER 权限时，READER 权限也会一起提供；授予 OWNER 权限时，READER 和 WRITER 权限也会一起提供。

如果使用 Google Cloud Console、JSON API 或 gsutil 指定 ACL，您可以为同一条目指定多个范围。其中最为宽松的权限就是授予给该范围的访问权限。例如，如果您为某个用户提供了两个条目（分别对应存储桶的 READER 权限和 WRITER 权限），该用户将拥有存储桶的 WRITER 权限。

在 XML API 中，无法为同一范围提供两个 ACL 条目。例如，同时向某一用户授予存储桶的 READ 权限和 WRITE 权限将会引发错误。正确的做法是为该用户授予 WRITE 权限（READ 权限会随之一起提供）。

预定义 ACL

预定义或“预设”ACL 是一组特定 ACL 条目的别名，可用于对一个存储分区或对象一次性快速应用多个 ACL 条目。

下表列出了预定义 ACL，同时还提供了适用于每个预定义 ACL 的 ACL 条目。使用下表时，请注意以下事项：

  • 项目所有者群组拥有项目中存储分区的所有权，而创建某个对象的用户拥有该对象的所有权。如果某个对象是由匿名用户创建的，则项目所有者群组拥有该对象的所有权。

  • 此表采用的是 JSON API 中对权限的描述方式，即 OWNER、WRITER 和 READER。等效的 XML API 范围为 FULL_CONTROL、WRITE 和 READ。

    JSON API XML API/gsutil 说明
    private private 为存储分区或对象所有者授予相应存储分区或对象的 OWNER 权限。
    bucketOwnerRead bucket-owner-read 为对象所有者授予 OWNER 权限，为存储分区所有者授予 READER 权限。 这仅适用于对象。
    bucketOwnerFullControl bucket-owner-full-control 为对象和存储分区所有者授予 OWNER 权限。 这仅适用于对象。
    projectPrivate project-private 根据角色为项目团队授予权限。所有团队成员都具有 READER 权限。项目所有者和项目编辑者具有 OWNER 权限。这不但是新创建存储分区的默认 ACL，也是新创建对象的默认 ACL（除非该存储分区的默认对象 ACL 发生了更改）。
    authenticatedRead authenticated-read 为存储分区或对象所有者授予 OWNER 权限，为所有已通过身份验证的 Google 帐号拥有者授予 READER 权限。
    publicRead public-read 为存储分区或对象所有者授予 OWNER 权限，为所有用户（包括已通过身份验证的用户和匿名用户）授予 READER 权限。对某个对象应用此 ACL 时，互联网上的任何人都可以在不进行身份验证的情况下读取该对象。对某个存储分区应用此选项时，互联网上的任何人都可以在不进行身份验证的情况下列出对象。

    * 请参阅表格末尾有关缓存的注释。
    publicReadWrite public-read-write 为存储分区所有者授予 OWNER 权限，并为所有用户（包括已通过身份验证的用户和匿名用户）授予 READER 和 WRITER 权限。此 ACL 仅适用于存储分区。对某一存储分区应用此 ACL 时，互联网上的任何人都可以在不进行身份验证的情况下列出、创建、替换和删除对象。

    * 请参阅表格末尾有关缓存的注释。

* 默认情况下，可公开读取的对象使用 Cache-Control 标头提供，带有此标头的对象可在系统中缓存 3600 秒。如果需要确保立即显示更新，应将对象的 Cache-Control 元数据设置为 Cache-Control:private, max-age=0, no-transform。

默认 ACL

创建存储分区或上传对象时，如果您没有为这些存储分区或对象明确分配一个 ACL，系统会为其指定默认 ACL。您可以更改系统为对象指定的默认 ACL；具体方法请参阅更改默认对象 ACL。请注意，当您更改默认 ACL 时，存储分区中的现有对象或项目中的现有存储分区的 ACL 保持不变。

默认存储分区 ACL

所有存储分区的所有权均属于项目所有者群组。此外，项目所有者被授予其项目中使用预定义 ACL 的任何存储桶的 OWNER 权限。

如果您在创建某个存储分区时使用的是默认存储分区 ACL，也就是说，您在创建该存储分区时没有指定预定义 ACL，系统会对您的存储分区应用预定义 projectPrivate ACL。

默认对象 ACL

默认情况下，任何对某一存储桶具有 OWNER 权限或 WRITER 权限的人都可以将对象上传至该存储桶。上传对象时，您可以提供预定义 ACL，也可以不指定任何 ACL。如果您没有指定 ACL，Cloud Storage 则会对该对象应用相应存储桶的默认对象 ACL。每个存储桶都有一个默认对象 ACL，如果您没有预定义的 ACL 或没有在请求中指定 ACL（仅限于 JSON API），系统则会对上传至该存储桶的所有对象应用此 ACL。每个存储分区的初始默认对象 ACL 值为 projectPrivate。

系统会根据对象的上传方式应用相应的对象 ACL：

  • 基于身份验证上传

    如果您是通过身份验证方式请求上传某一对象，且在上传时没有指定任何对象 ACL，那么系统会将您列为该对象的所有者，并对该对象默认应用预定义的 projectPrivate ACL。也就是说：

    • 您（上传该对象的人）将被列为对象所有者。 对象所有权不能通过修改 ACL 来更改，只能通过替换对象更改对象所有权。

    • 您（对象所有者）将被授予对象 OWNER 权限。如果您尝试向所有者授予低于 OWNER 的权限，Cloud Storage 会自动将此权限升级为 OWNER。

    • 项目所有者和项目编辑者群组拥有对象 OWNER 权限。

    • 项目团队成员群组拥有对象 READER 权限。

  • 匿名上传

    当未经过身份验证（匿名）的用户上传对象时（如果存储分区为 allUsers 群组授予 WRITER 或 OWNER 权限，就可能发生这种情况），系统则会对相应对象应用默认的存储分区 ACL（如上所述）。

    匿名用户无法在对象上传期间指定预定义的 ACL。

ACL 行为

Cloud Storage 会强制执行一些 ACL 修改规则来阻止您设置会导致数据无法访问的 ACL，从而帮助您遵守最佳做法：

  • 您应用的 ACL 不能指定不同的存储桶或项目所有者。

    存储分区和对象所有者不能通过修改 ACL 来更改。如果您对某个存储分区或对象应用新的 ACL，请确保该存储分区或对象所有者在新的 ACL 中保持不变。

  • 存储分区或对象所有者始终拥有相应存储分区或对象的 OWNER 权限。

    存储分区的所有者是指项目所有者群组，对象的所有者是指上传了该对象的用户或项目所有者群组（如果对象是由匿名用户上传的）。

    当您对某个存储分区或对象应用新的 ACL 时，Cloud Storage 会分别为该存储分区或项目所有者添加 OWNER 权限（如果您没有授予此权限）。Cloud Storage 不会向项目所有者群组授予对象的 OWNER 权限（除非该对象是由匿名用户创建的），因此您必须明确包含此权限。

您应用的 ACL 不能更改存储分区或对象的所有权（不要与 OWNER 权限混淆）。在 Cloud Storage 中创建存储分区和对象后，该存储分区和对象的所有权将无法更改。但是，您可以通过替换对象有效地更改对象（而非存储分区）的所有权。替换过程基本上是先执行删除操作，然后立即执行上传操作。在上传操作期间，执行上传的人将成为对象的所有者。请记住，要替换某个对象，执行替换操作（并将因此而获得对象所有权）的人必须对对象上传的存储分区具有 WRITER 或 OWNER 权限。

后续步骤