存取控制清單 (ACL)

用量

本頁提供存取控制清單 (ACL) 總覽，可讓您控管個別值區或物件的存取權。如要瞭解控制值區和物件存取權的其他方式，請參閱「存取權控制總覽」。

您應該使用存取控制清單嗎？

在大部分情況下，您應避免使用 ACL，並為值區啟用統一值區層級存取權，這樣就能防止使用 ACL：

  • 您無法單獨使用 ACL 控制資源存取權，因為無法在整體專案或 Cloud Storage 以外的資源上設定 ACL。 Google Cloud
  • 啟用統一值區層級存取權後，存取權控管介面會變得更簡單，您也能使用其他 Google Cloud 功能。詳情請參閱「是否應使用統一 bucket 層級存取權」一文。
  • 「網域限定共用」機構政策和自訂機構政策不會禁止 ACL 授予的存取權，因此可能會導致非預期的存取權。
  • 在專案層級或以上設定 IAM 條件的專案中使用 ACL 時，可能會發生非預期的行為和存取權問題。

在下列情況下，您可能要使用 ACL：

  • 您需要自訂值區中個別物件的存取權，例如希望物件上傳者擁有該物件的完整控制權，但減少該使用者對值區內其他物件的存取權。
  • 您只使用 XML API，或需要與 Amazon S3 互通。

什麼是存取控制清單？

您可以使用存取控制清單 (ACL) 機制來定義有權存取值區和物件的對象和存取層級。在 Cloud Storage 中，您可以將 ACL 套用於個別值區和物件。每個 ACL 都是由一或多個「項目」組成。這類項目可讓特定使用者 (或群組) 執行特定動作。每個項目都含有兩種資訊：

  • 權限，定義可以執行「什麼」動作 (例如，讀取或寫入)。

  • 範圍 (亦稱為「授予對象」)，定義「誰」可以執行指定動作 (例如，特定使用者或使用者群組)。

舉例來說，假設您有一個值區，且您希望任何人都可以存取該值區中的物件，但也希望您的協作者能夠在值區中新增或移除物件。在此情況下，您的 ACL 會包含兩個項目：

  • 在其中一個項目中，您要將 READER 權限授予 allUsers 範圍。

  • 在另一個項目中，您要將 WRITER 權限授予協作者範圍 (有幾種方式可以指定此人，例如透過這個人的電子郵件)。

您最多可以為值區或物件建立 100 個 ACL 項目。若項目範圍是群組或網域，不論該群組或網域中有多少使用者，都算成一個 ACL 項目。

當使用者要求存取某個值區或物件時，Cloud Storage 系統即會讀取該值區或物件的 ACL，判斷要允許或拒絕該存取要求。如果 ACL 授予使用者執行作業的權限，系統就會允許要求。如果 ACL 未授予使用者執行作業的權限，則要求會失敗，且會傳回 403 Forbidden 錯誤。

請注意，雖然 ACL 可以用來管理大部分與值區和物件有關的動作，但是否可以「建立」值區則取決於是否擁有適當的專案權限。

權限

「權限」說明可以對指定物件或值區執行「什麼」操作。

Cloud Storage 可讓您指派值區和物件的同心圓權限，如下表所示：

值區 物件
READER 允許使用者列出值區的內容。也允許使用者讀取值區的中繼資料，但 ACL 除外。 允許使用者下載物件資料。
WRITER 授予使用者 READER 權限所允許的所有存取權。此外，還允許使用者在值區中建立、取代及刪除物件，包括使用多部分上傳作業建立物件。 不適用。您無法將此權限套用到物件。
OWNER 授予使用者 WRITER 權限所允許的所有存取權。也允許使用者讀取和寫入包括 ACL 在內的值區中繼資料，以及處理值區上的標記。 授予使用者 READER 權限所允許的所有存取權。也允許使用者讀取和寫入包括 ACL 在內的物件中繼資料。
預設 值區在建立時已套用預先定義的 project-private ACL。值區一律由 project-owners 群組所擁有。 物件在上傳時已套用預先定義的 project-private ACL。物件一律由上傳物件的原始要求者所擁有。

在本頁中，我們通常將權限稱為 READER、WRITER 及 OWNER，這些是 JSON API 和 Google Cloud console 中的角色。如果您使用的是 XML API，對應的權限分別是 READ、WRITE 和 FULL_CONTROL。

範圍

「範圍」指定「誰」具備特定權限。

ACL 由一或多個項目所構成，其中每個項目都會將權限授予某個範圍。您可以使用下列任一實體指定 ACL 範圍：

範圍 (「授予對象」) 實體類型 範例
適用於所有實體的特殊 ID 使用者 allUsers
適用於所有有效帳戶的特殊 ID 使用者 allAuthenticatedUsers
使用者帳戶電子郵件地址 使用者 jeffersonloveshiking@gmail.com
服務帳戶電子郵件地址 使用者 my-service-account@my-project.iam.gserviceaccount.com
Google 網路論壇電子郵件地址 群組 work-group@googlegroups.com
方便識別專案的值 專案 owners-123456789012
Google Workspace 網域 網域 dana@example.com
Cloud Identity 網域 網域 dana@example.com

  • 適用於所有實體的特殊 ID：

    特殊範圍 ID allUsers 代表網際網路上的任何實體。請注意，雖然這個 ID 是 User 實體類型，但使用 Google Cloud 控制台時，會標示為 Public 實體類型。

  • 適用於所有有效帳戶的特殊 ID：

    特殊範圍 ID allAuthenticatedUsers 代表大多數已通過驗證的帳戶，包括服務帳戶。詳情請參閱「IAM 主體」。請注意，雖然這個 ID 是 User 實體類型，但在使用 Google Cloud 控制台時，會標示為 Public 實體類型。

  • 使用者帳戶電子郵件地址：

    每位擁有使用者帳戶的使用者都要有一個與該帳戶相關聯的專屬電子郵件地址。您可以使用任何與使用者帳戶相關聯的電子郵件地址來指定範圍。

    您在 ACL 中提供電子郵件地址時，Cloud Storage 會記住這些電子郵件地址，直到這些項目遭到移除或取代為止。如果使用者變更電子郵件地址，您應更新 ACL 項目以反映這些變更。

  • 服務帳戶電子郵件地址：

    每個服務帳戶都有專屬的電子郵件地址。 您可以使用與服務帳戶相關聯的電子郵件地址來指定範圍。

  • Google 網路論壇電子郵件地址：

    每個 Google 群組都有與該群組相關聯的專屬電子郵件地址。例如 Cloud Storage Announce 群組的電子郵件地址為 gs-announce@googlegroups.com。如要查看與 Google 網路論壇相關聯的電子郵件地址，請在每個 Google 網路論壇的首頁上按一下「關於」。

    與使用者帳戶電子郵件地址一樣，當您在 ACL 中提供群組的電子郵件地址時，Cloud Storage 會記住這些電子郵件地址，直到這些項目遭到移除為止。由於 Google 網路論壇電子郵件地址為永久地址且不太會變更，因此您無需煩惱這些電子郵件地址的更新問題。

  • 方便識別專案的值：

    方便識別的值可讓您大量授予專案檢視者、編輯者和擁有者存取權。方便識別的值會結合專案角色和相關聯的專案編號。例如，在 867489160491 專案中，編輯者 ID 為 editors-867489160491。您可以在 Google Cloud console首頁找到專案編號。

    一般來說，請避免在正式環境中使用便利值，因為這需要授予基本角色，而這在正式環境中並不建議。

  • Google Workspace 或 Cloud Identity：

    Google Workspace 和 Cloud Identity 客戶可將自己的電子郵件帳戶與網際網路網域名稱建立關聯。建立關聯後，每個電子郵件帳戶即會採用 USERNAME@YOUR_DOMAIN.com 格式。您可以使用與 Google Workspace 或 Cloud Identity 相關聯的任何網際網路網域名稱指定範圍。

同心圓權限和範圍

在 Cloud Storage 中指定 ACL 時，您不需要列出多個範圍以授予多個權限。Cloud Storage 採用同心圓權限，因此當您授予 WRITER 權限時，也會授予 READER 權限；而當您授予 OWNER 權限時，也會同時授予 READER 和 WRITER 權限。

指定 ACL 時，大多數工具都允許您為同一個項目指定多個範圍。最寬鬆的權限是授予範圍的存取權。舉例來說，如果您為使用者提供兩個項目，一個具有 READER 權限，另一個具有值區的 WRITER 權限，則使用者將具備值區的 WRITER 權限。

在 XML API 中，無法提供範圍相同的兩個 ACL 項目。例如，將值區的 READ 權限和 WRITE 權限授予同一位使用者會造成錯誤。不過您可以改為將 WRITE 權限授予使用者，這樣也會一併授予 READ 權限。

存取控制清單和 IAM

Identity and Access Management (IAM) 與 ACL 同時使用可以授予值區和物件的存取權，也就是說，使用者只需要有其中一個系統的相關權限，就可以存取值區或物件。一般來說，IAM 政策授予的權限不會出現在 ACL 中，而透過 ACL 授予的權限也不會出現在 IAM 政策中。詳情請參閱「IAM 與 ACL 的關係」。

身分與存取權管理拒絕政策的行為

如果 IAM 拒絕政策和您設定的 ACL 針對相同權限，拒絕政策會覆寫 ACL 授予的任何適用存取權。

舉例來說，如果值區的拒絕政策禁止使用者擁有 storage.objects.get 權限，而您建立的 ACL 授予使用者值區內物件的 READER 角色，使用者就無法查看值區中的物件。不過，如果拒絕政策指定 storage.buckets.get 權限，且 ACL 授予值區的 WRITER 角色，使用者就無法擷取值區的中繼資料，但仍可列出、建立及刪除值區中的物件。

預先定義的 ACL

預先定義的 ACL (有時也稱為罐頭 ACL) 是一組特定 ACL 項目的別名。使用預先定義的 ACL 可以讓您將許多 ACL 項目一次快速套用到值區或物件。

下表列出預先定義的 ACL，並說明每個預先定義的 ACL 所套用的 ACL 項目。使用下表時，請注意：

  • 專案擁有者群組具備專案中值區的擁有權，而建立物件的使用者具備該物件的擁有權。如果物件是由匿名使用者建立，則專案擁有者群組會具備該物件的擁有權。

  • 此表格採用 JSON API 的 OWNER、WRITER 及 READER 權限說明。對應的 XML API 範圍是 FULL_CONTROL、WRITE 和 READ。

    JSON API/gcloud storage XML API 說明
    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 權限授予值區或物件擁有者，並將 READER 權限授予所有經過驗證的使用者帳戶持有人。
    publicRead public-read 將 OWNER 權限授予值區或物件擁有者，並將 READER 權限授予所有經過驗證和匿名的使用者。如果您將這個 ACL 套用於物件，則網際網路上的所有使用者都可以讀取該物件，不需經過驗證。如果將這個 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

所有值區皆為專案擁有者群組所擁有。此外，如果專案中的值區使用預先定義的 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 權限。

  • 匿名上傳項目

    如果值區將 WRITER 或 OWNER 權限授予 allUsers 群組，在此情況下，未經驗證 (匿名) 的使用者可以上傳物件，而系統會將預設值區 ACL 套用到該物件，如上所述。

    匿名使用者無法在物件上傳期間指定預先定義的 ACL。

ACL 行為

Cloud Storage 會強制執行某些 ACL 修改規則，協助您遵守最佳做法，防止您設定會導致資料無法存取的 ACL：

  • 如果 ACL 指定其他值區或物件擁有者，您將無法套用該 ACL。

    您無法透過修改 ACL 來變更物件擁有權。如果您將新的 ACL 套用至值區或物件，請確認新 ACL 中的值區或物件擁有者維持不變。

  • 值區或物件擁有者一律具備該值區或物件的 OWNER 權限。

    值區的擁有者是專案擁有者群組，而物件的擁有者是上傳物件的使用者，或如果物件是由匿名使用者上傳，則是專案擁有者群組。

    將新的 ACL 套用於值區或物件時，如果您略過授權步驟，Cloud Storage 會分別為值區或物件擁有者加入 OWNER 權限。系統「不」會將物件的 OWNER 權限授予專案擁有者群組 (除非物件是由匿名使用者建立)，因此您必須明確納入此權限。

您不能套用會變更值區或物件「擁有權」的 ACL (擁有權與 OWNER 權限不同)。在 Cloud Storage 中建立後，值區和物件擁有權即為永久擁有權。但您可以透過取代物件來有效變更物件的擁有權，但值區無法這樣做。基本上，取代就是一個刪除作業，之後緊接著上傳作業。在上傳作業期間，執行上傳的使用者就會成為物件的擁有者。請注意，如要取代物件，執行取代作業 (並藉此獲得物件擁有權) 的使用者必須具備上傳物件所在值區的 WRITER 或 OWNER 權限。

後續步驟