存取控制清單 (ACL)

用量

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

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

在多數情況下，您應避免使用 ACL，並為 bucket 啟用統一 bucket 層級存取權，以防止使用 ACL：

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

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

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

什麼是存取控制清單？

您可以使用存取控制清單 (ACL) 機制，定義有權存取 bucket 和物件的對象和存取層級。在 Cloud Storage 中，您可以將 ACL 套用至個別 bucket 和物件。每個 ACL 都含有一或多個項目。項目可讓特定使用者 (或群組) 執行特定動作。每個項目都包含兩項資訊：

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

  • 「範圍」 (有時稱為「受益人」)，定義「誰」可以執行指定動作 (例如特定使用者或使用者群組)。

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

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

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

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

當使用者要求存取 bucket 或物件時，Cloud Storage 系統會讀取 bucket 或物件 ACL，並決定要允許或拒絕存取要求。如果 ACL 授予使用者執行作業的權限，系統就會允許要求。如果 ACL 未授予使用者執行所要求作業的權限，要求就會失敗並傳回 403 Forbidden 錯誤。

請注意，雖然 ACL 可用來管理大部分涉及值區和物件的動作，但建立值區的權限來自適當的專案權限。

權限

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

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

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

在本頁中，我們通常會將權限稱為 READER、WRITER 和 OWNER，這也是 JSON API 和 Cloud de Confiance 控制台中的指定方式。如果您使用的是 XML API，則對應的權限分別為 READ、WRITE 和 FULL_CONTROL。

範圍

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

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

範圍 (「授予對象」) 實體類型 範例
所有實體的特殊 ID 使用者 allUsers
所有有效帳戶的特殊 ID 使用者 allAuthenticatedUsers
服務帳戶電子郵件地址 使用者 my-service-account@my-project.s3ns.iam.gserviceaccount.com
方便識別專案的值 專案 owners-123456789012

  • 所有實體的特殊 ID：

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

  • 所有有效帳戶的特殊 ID：

    特殊範圍 ID allAuthenticatedUsers 代表任何服務帳戶。詳情請參閱「IAM 主體」。請注意，雖然這個 ID 是 User 實體類型，但在使用Cloud de Confiance 控制台時，會標示為 Public 實體類型。

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

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

  • 方便識別專案的值：

    便利值可讓您將專案的檢視者、編輯者和擁有者權限大量授予使用者。便利值會結合專案角色和相關聯的專案編號。舉例來說，在專案 867489160491 中，編輯者會識別為 editors-867489160491。您可以在 Cloud de Confiance console的首頁找到專案編號。

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

同心圓權限和範圍

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

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

在 XML API 中，無法提供兩個範圍相同的 ACL 項目。舉例來說，如果對 bucket 授予使用者 READ 權限和 WRITE 權限，就會發生錯誤。請改為授予使用者 WRITE 權限，這樣使用者也會獲得 READ 權限。

ACL 和 IAM

身分與存取權管理 (IAM) 和 ACL 會共同運作，授予值區和物件的存取權，也就是說，使用者只要在這兩個系統中取得相關權限，就能存取值區或物件。一般來說，IAM 政策授予的權限不會出現在 ACL 中，而 ACL 授予的權限也不會出現在 IAM 政策中。詳情請參閱「IAM 與 ACL 的關係」。

IAM 拒絕政策的行為

如果拒絕政策和存取控制清單 (ACL) 針對相同權限，則當拒絕政策適用時，會覆寫您設定的 ACL 授予的任何適用存取權。IAM 拒絕政策

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

預先定義的 ACL

預先定義的 ACL (有時也稱為罐裝 ACL) 是一組特定 ACL 項目的別名，可用來快速將多個 ACL 項目一次套用至 bucket 或物件。

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

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

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

    JSON API/gcloud storage XML API 說明
    private private 為 bucket 或物件授予 bucket 或物件擁有者 OWNER 權限。
    bucketOwnerRead bucket-owner-read 授予物件擁有者 OWNER 權限，並授予 bucket 擁有者 READER 權限。這項屬性僅適用於物件。
    bucketOwnerFullControl bucket-owner-full-control 授予物件和 bucket 擁有者 OWNER 權限。 這項屬性僅適用於物件。
    projectPrivate project-private 根據專案小組的成員角色將權限授予成員。凡是小組成員均具有 READER 權限。專案擁有者和專案編輯者具有 OWNER 權限。這是新建值區的預設 ACL，此外也是新建物件的預設 ACL，除非您已變更該值區的預設物件 ACL。
    authenticatedRead authenticated-read 將 OWNER 權限授予 bucket 或物件擁有者，並將 READER 權限授予所有已驗證的使用者帳戶持有人。
    publicRead public-read 將 OWNER 權限授予值區或物件擁有者，並將 READER 權限授予所有經過驗證和匿名的使用者。如果您將這個 ACL 套用於物件，則網際網路上的所有使用者都可以讀取該物件，不需經過驗證。如果將這個 ACL 套用於值區，則網際網路上的任何使用者都可以列出物件，不需經過驗證。

    * 請參閱表格結尾關於快取的說明。
    publicReadWrite public-read-write 將 OWNER 權限授予值區擁有者，並將 READER 和 WRITER 權限授予所有經過驗證和匿名的使用者。這個 ACL 僅適用於值區。將這項設定套用至 bucket 後，網際網路上的所有使用者都能列出、建立、取代及刪除物件，無須驗證身分。

    * 請參閱表格結尾關於快取的說明。

* 根據預設，可公開讀取的物件會以 Cache-Control 標頭提供，允許物件快取 3600 秒。如要確保更新內容立即顯示，請 將物件的 Cache-Control中繼資料設為 Cache-Control:private, max-age=0, no-transform。

預設 ACL

建立值區或上傳物件時，如果您沒有明確指派 ACL 給值區或物件，系統會提供預設的 ACL。您可以變更物件的預設 ACL，操作說明請參閱變更預設物件 ACL。請注意，當您變更預設的 ACL 時，已經存在於值區中的物件 ACL 或已經存在於專案中的值區 ACL 維持不變。

預設值區 ACL

所有值區皆為專案擁有者群組所擁有。此外，如果專案中的任何 bucket 使用預先定義的 ACL，專案擁有者也會獲得 OWNER 權限。

如果您使用預設值區 ACL 建立值區 (也就是在建立值區時未指定預先定義的 ACL)，則值區會套用預先定義的 projectPrivate ACL。

預設物件 ACL

根據預設，只要具備 bucket 的 OWNER 權限或 WRITER 權限，即可將物件上傳至該 bucket。上傳物件時，您可以提供預先定義的 ACL，也可以完全不指定 ACL。如未指定 ACL，Cloud Storage 會將 bucket 的預設物件 ACL 套用至物件。每個 bucket 都有預設物件 ACL，如果上傳至 bucket 的物件沒有預先定義的 ACL，或要求中指定的 ACL (僅限 JSON API)，系統就會套用這個 ACL。每個值區的預設物件 ACL 初始值為 projectPrivate。

根據物件的上傳方式，系統會套用相應的物件 ACL：

  • 已驗證的上傳項目

    如果您提出經過驗證的要求來上傳物件，且上傳時未指定任何物件 ACL，系統會將您列為物件擁有者，並預設將預先定義的 projectPrivate ACL 套用至物件。也就是說：

    • 您 (上傳物件的人) 會列為物件擁有者。 您無法透過修改 ACL 來變更物件擁有權，如要變更物件擁有權，只能替換物件。

    • 系統會將物件的 OWNER 權限授予您 (物件擁有者)。如果您嘗試授予擁有者低於 OWNER 的權限，Cloud Storage 會自動將權限提升至 OWNER。

    • 專案擁有者和專案編輯者群組對物件具備 OWNER 權限。

    • 專案小組成員群組擁有物件的 READER 權限。

  • 匿名上傳項目

    如果未通過驗證 (匿名) 的使用者上傳物件 (如果 bucket 授予 allUsers 群組 WRITER 或 OWNER 權限，就可能發生這種情況)，系統會將預設 bucket ACL 套用至物件，如先前所述。

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

ACL 行為

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

  • 您無法套用指定不同值區或物件擁有者的 ACL。

    您無法透過修改 ACL 來變更物件擁有權。如果您對值區或物件套用新的 ACL，請務必確保值區或物件擁有者在新的 ACL 中保持不變。

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

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

    將新的 ACL 套用至 bucket 或物件時，如果您省略授權，Cloud Storage 會分別將 OWNER 權限新增至 bucket 或物件擁有者。這項角色不會授予專案擁有者群組OWNER物件權限 (除非物件是由匿名使用者建立)，因此您必須明確加入這項角色。

您不能套用會變更值區或物件「擁有權」的 ACL (擁有權與 OWNER 權限不同)。在 Cloud Storage 中建立後，值區和物件擁有權即為永久擁有權。不過，您可以透過替換物件 (而非 bucket) 的方式，有效變更物件的擁有權。更換基本上就是先刪除，然後立即上傳。上傳作業期間，執行上傳作業的人員會成為物件的擁有者。請注意，如要取代物件，執行取代作業 (並藉此取得物件擁有權) 的使用者必須具備上傳物件所在值區的 WRITER 或 OWNER 權限。

後續步驟