访问控制列表 (ACL)

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

您是否应该使用访问控制列表?

大多数情况下,我们建议您使用 Cloud Identity and Access Management (IAM) 来控制对资源的访问。若要授予对您的存储分区和对象的访问权限,则需配合使用 Cloud IAM 和 ACL:用户只需具有 Cloud IAM 或 ACL 中提供的权限即可访问存储分区或对象。

如果您需要自定义对存储分区中各个对象的访问权限,则最适合使用 ACL,因为 Cloud IAM 权限适用于存储分区中的所有对象。但对于通用于存储分区中所有对象的任何访问权限,您仍应使用 Cloud IAM,因为这可为您减轻需要完成的微观管理工作量。

什么是访问控制列表?

访问控制列表 (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 允许用户列出、创建、覆盖和删除存储分区对象1 不适用。您不能将此权限应用于对象。
OWNER 为用户授予存储分区的 READERWRITER 权限。还允许用户读取和写入存储分区元数据(包括 ACL)。 为用户授予 READER 访问权限。还允许用户读取和写入对象元数据(包括 ACL)。
默认 创建存储分区时,系统会对存储分区应用预定义的项目专用 ACL。存储分区的所有权始终属于 project-owners 组。 上传对象时,系统会对对象应用预定义的项目专用 ACL。对象的所有权始终属于上传了相应对象的原始请求者。

1 以下存储分区元数据属性无法更改:aclcorsdefaultObjectAcllifecycleloggingversioningwebsite

在本页面中,我们所说的权限通常是指 READERWRITEROWNER,这也是这些权限在 JSON APIGoogle Cloud Platform Console 中的指定方式。如果您使用的是 XML API,则等效权限分别为 READWRITEFULL_CONTROL。如果您使用 OAuth 2.0 身份验证来对代表您访问 Google Cloud Storage API 的工具和应用进行身份验证(为其授予权限),则访问权限会被限制在 OAuth 范围 devstorage.read_onlydevstorage.read_writedevstorage.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
G Suite 网域 网域 [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 群组,请参阅 Google 群组主页

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

  • 为项目方便而使用的值

    为方便而使用的值 owners-<project-number>editors-<project-number>viewers-<project-number> 分别代表项目编号为 <project-number> 的项目的所有者、编辑者和查看者列表。

  • G Suite 或 Cloud Identity

    G SuiteCloud Identity 客户可以将其电子邮件帐号与互联网域名关联起来。若要执行此操作,每个电子邮件帐号均应采用 [USERNAME]@[YOUR_DOMAIN].com 形式。您可以使用与 G Suite 或 Cloud Identity 关联的任何 Internet 域名指定范围。

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

    此特殊范围标识符代表所有使用 Google 帐号进行身份验证的人。适用于所有 Google 帐号拥有者的特殊范围标识符为 allAuthenticatedUsers

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

    此特殊范围标识符代表互联网上的任何人(无论是否拥有 Google 帐号)。适用于所有用户的特殊范围标识符为 allUsers

同心权限和范围

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

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

在 XML API 中,无法为同一范围提供两个 ACL 条目。例如,同时向某一用户授予存储分区的 READ 权限和 WRITE 权限将会引发错误。而是应为该用户授予 WRITE 权限(READ 权限会随之一起提供)。

预定义 ACL

预定义或“预设”ACL 是一组特定 ACL 条目的别名,可用于对一个存储分区或对象一次性快速应用多个 ACL 条目。预定义 ACL 是针对常见场景定义的,例如,撤消除所有者权限以外的所有访问权限(预定义 ACL private),或将对象设为可公开读取(预定义 ACL publicRead)。

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

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

  • 此表采用的是 JSON API 中对权限的描述方式,即 OWNERWRITERREADER。等效的 XML API 范围为 FULL_CONTROLWRITEREAD

    JSON API XML API/gsutil 说明
    private private 为存储分区或对象所有者授予相应存储分区或对象的 OWNER 权限,并移除其他所有访问权限。
    bucketOwnerRead bucket-owner-read 为对象所有者授予 OWNER 权限,为存储分区所有者授予 READER 权限。移除其他所有权限。此 ACL 仅适用于对象
    bucketOwnerFullControl bucket-owner-full-control 为对象和存储分区所有者授予 OWNER 权限。移除其他所有权限。此 ACL 仅适用于对象
    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 权限,并为所有用户(包括已通过身份验证的用户和匿名用户)授予 READERWRITER 权限。此 ACL 仅适用于存储分区。对某一存储分区应用此 ACL 时,互联网上的任何人都可以在不进行身份验证的情况下列出、创建、覆盖和删除对象。

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

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

默认 ACL

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

默认存储分区 ACL

所有存储分区的所有权均属于项目所有者群组。系统会自动为项目所有者授予其项目中所有存储分区的 OWNER 权限。当您创建项目时,系统会自动将您作为项目所有者而添加。

如果您在创建某个存储分区时使用的是默认存储分区 ACL,也就是说,您在创建该存储分区时没有指定预定义 ACL,系统会对您的存储分区应用预定义 projectPrivate ACL。projectPrivate ACL 会根据角色为项目团队成员授予额外权限。这些额外权限的定义如下所示:

  • 项目查看者

    projectPrivate ACL 会为项目查看者提供项目所含存储分区的 READER 访问权限。对于所有项目团队成员而言,他们不但可以列出存储分区中的对象,而且还可以列出项目中的存储分区(不考虑存储分区 ACL)。

  • 项目编辑者

    projectPrivate ACL 会为项目编辑者提供项目所含存储分区的 OWNER 权限。对于项目编辑者而言,他们不但可以列出存储分区的内容以及创建、覆盖或删除存储分区对象,而且还可以列出、创建和删除存储分区(不考虑存储分区 ACL)。

  • 项目所有者

    projectPrivate ACL 会为项目所有者提供 OWNER 权限。项目所有者不但可以执行管理任务(例如,添加和移除团队成员或更改结算信息),还可以执行项目编辑者可执行的全部任务。

要标识项目查看者、项目编辑者和项目所有者,可以将其各自的角色与关联的项目编号结合使用。例如,在项目 867489160491 中,编辑者可标识为 project-editors-867489160491。您可以在 Google Cloud Platform Console 的主页上找到您的项目编号。

默认对象 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 群组授予 WRITEROWNER 权限,就可能发生这种情况),系统则会对相应对象应用默认的存储分区 ACL(如上所述)。

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

最佳做法

与任何其他管理设置一样,您必须对 ACL 进行主动管理以使之生效。在允许其他用户访问某一存储分区或对象之前,请务必明确您想要与谁分享该存储分区或对象以及您希望他们分别扮演什么角色。一段时间后,如果项目管理、使用规律和组织所有权发生了变化,您可能需要修改存储分区和对象的 ACL 设置,特别是在您所管理的存储分区和对象面向的是大型组织或大规模用户的情况下。在评估和规划访问权限控制设置时,请谨记以下最佳做法:

  • 授予存储分区和对象访问权限时,请遵循最小权限原则。

    最小权限原则是关于授予特权或权限的一项安全准则。根据最小权限原则授予访问权限时,您将为用户授予其完成所分配任务而需要的最小权限。例如,如果您想要与他人分享一个文件,应为其授予 READER 权限,而不是 OWNER 权限。

  • 避免向陌生人授予 OWNER 权限。

    授予 OWNER 权限就是允许用户更改 ACL 和控制数据。只有在您希望将对象和存储分区的管理控制权委托给他人时,您才应使用 OWNER 权限。

  • 向匿名用户授予权限时请务必注意方式方法。

    只有允许互联网上的任何人读取和分析您的数据时,才应使用 allUsersallAuthenticatedUsers 范围。虽然在某些应用和使用场景中使用这些范围会非常有用,但我们建议您一般情况下最好不要向所有用户授予 OWNER 权限。

  • 设置 ACL 时请避免导致对象无法访问。

    无法访问的对象是指无法下载(读取)而只能删除的对象。如果某个对象的所有者离开了项目,但他没有向任何人授予对象的 OWNERREADER 权限,此时就可能发生这种情况。要避免发生这种问题,您可以在自己或其他任何人向您的存储分区上传对象时使用 bucket-owner-readbucket-owner-full- control 预定义 ACL。

  • 请确保您存储分区的管理控制权可委托给他人。

    默认情况下,项目所有者群组是在存储分区创建之时对该存储分区拥有 OWNER 权限的唯一实体。在任何时候,项目所有者群组都应至少具有两个成员,这样一来,即使某位团队成员离开了该群组,您的存储分区仍可由其他项目所有者进行管理。

  • 请注意 Cloud Storage 的互操作行为。

    使用 XML API 与其他存储服务(如 Amazon S3)进行互操作访问时,签名标识符决定了 ACL 语法。例如,如果您使用的工具或库向 Cloud Storage 发出检索 ACL 的请求,并且该请求使用其他存储服务商的签名标识符,则 Cloud Storage 将返回一个使用相应存储服务商的 ACL 语法的 XML 文档。如果您使用的工具或库向 Cloud Storage 发出应用 ACL 的请求,并且该请求使用其他存储服务商的签名标识符,则 Cloud Storage 应会收到一个使用相应存储服务商的 ACL 语法的 XML 文档。

    如需详细了解如何使用 XML API 与 Amazon S3 进行互操作访问,请参阅从 Amazon S3 迁移到 Google Cloud Storage

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

  • 您应用的 ACL 不能指定不同的存储分区或对象所有者。

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

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

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

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

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

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Cloud Storage
需要帮助?请访问我们的支持页面