存取控制清單 (ACL)

本頁提供存取控制清單 (ACL) 總覽。若要瞭解如何設定和管理 ACL,請參閱建立及管理存取控制清單。若要瞭解控制值區和物件存取權的其他方式,請參閱存取權控制總覽

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

在大部分情況下,我們建議您使用 Cloud Identity and Access Management (Cloud IAM) 來控制資源的存取權。Cloud IAM 與 ACL 同時使用可以授予值區和物件的存取權:使用者只需要有 Cloud IAM 或 ACL 的權限就可以存取值區或物件。

如果您必須自訂值區內個別物件的存取權,可能就要使用 ACL,因為 Cloud IAM 的權限會套用到值區內所有物件。不過針對值區內所有物件通用的存取權,您仍應使用 Cloud IAM,這樣可以減少微型管理工作。

什麼是存取控制清單?

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

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

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

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

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

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

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

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

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

權限

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

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

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

1您不能變更下列值區中繼資料屬性:aclcorsdefaultObjectAcllifecycleloggingversioningwebsite

在本頁中,我們通常將權限稱為 READERWRITEROWNER,這些是 JSON APIGoogle Cloud Platform 主控台中的角色。如果您使用的是 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 帳戶持有人的特殊 ID 使用者 allAuthenticatedUsers
適用於所有使用者的特殊 ID 使用者 allUsers
  • Google 帳戶電子郵件地址

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

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

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

    每個 Google 網路論壇的群組都有與該群組相關聯的專屬電子郵件地址。例如 Cloud Storage Announce 群組即擁有下列電子郵件地址:gs-announce@googlegroups.com。如要查看與 Google 網路論壇關聯的電子郵件地址,請在每個 Google 網路論壇的首頁上按一下 [關於]。如要進一步瞭解 Google 網路論壇的相關資訊,請參閱 Google 網路論壇的首頁

    與 Google 帳戶電子郵件地址一樣,當您在 ACL 中提供群組的電子郵件地址時,Cloud Storage 會記住這些電子郵件地址,直到這些項目遭到移除或覆寫為止。由於 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 相關聯的任何網際網路網域名稱指定範圍。

  • 適用於所有 Google 帳戶持有人的特殊 ID

    這種特殊範圍 ID 代表任何已使用 Google 帳戶通過驗證的使用者。適用於所有 Google 帳戶持有人的特殊範圍 ID 為 allAuthenticatedUsers

  • 適用於所有使用者的特殊 ID

    這種特殊範圍 ID 代表網際網路上的所有使用者,無論該使用者是否有 Google 帳戶。適用於所有使用者的特殊範圍 ID為 allUsers

同心圓權限和範圍

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

使用 Google Cloud Platform 主控台、JSON API 或 gsutil 指定 ACL 時,您可以為相同項目指定多個範圍。最寬鬆的權限是授予範圍的存取權。例如,如果您為使用者提供兩個項目,一個具有 READER 權限,另一個具有值區的 WRITER 權限,則使用者將具備值區的 WRITER 權限。

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

預先定義的 ACL

預先定義或「制式」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 權限授予值區或物件擁有者,並將 READER 權限授予所有經過驗證的 Google 帳戶持有人。移除所有其他權限。
    publicRead public-read OWNER 權限授予值區或物件擁有者,並將 READER 權限授予所有經過驗證和匿名的使用者。如果您將這個 ACL 套用於物件,則網際網路上的所有使用者都可以讀取該物件,不需經過驗證。如果將這個 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 維持不變。

預設值區 ACL

所有值區皆為專案擁有者群組所擁有。系統會將專案中所有值區的 OWNER 權限自動授予專案擁有者。當您建立專案時,系統即會自動將您新增為專案擁有者。

如果您使用預設值區 ACL 建立值區,亦即您在建立值區時未指定預先定義的 ACL,您的值區會套用預先定義的 projectPrivate ACL。projectPrivate ACL 會根據專案小組成員的角色,將額外的權限授予成員。這些額外權限的定義如下:

  • 專案檢視者

    projectPrivate ACL 會將專案中值區的 READER 權限授予專案檢視者。所有專案小組成員均可列出值區中的物件。此外,所有專案小組成員也可以列出專案內的值區,不受值區 ACL 的限制。

  • 專案編輯者

    projectPrivate ACL 會將專案中值區的 OWNER 權限授予專案編輯者。專案編輯者可列出值區內容,以及建立、覆寫或刪除值區中的物件。此外,專案編輯者也可列出、建立及刪除值區,不受值區 ACL 的限制。

  • 專案擁有者

    projectPrivate ACL 會將 OWNER 權限授予專案擁有者。專案擁有者除了執行多項管理工作之外,還可以執行專案編輯者可執行的所有工作,例如新增及移除小組成員或變更帳單資訊。

我們將角色與相關聯的專案編號結合在一起,來識別專案檢視者、專案編輯者及專案擁有者。例如,在 867489160491 專案中,編輯者 ID 為 project-editors-867489160491。您可以在 Google Cloud Platform 主控台首頁找到您的專案編號。

預設物件 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 權限。

  • 匿名上傳項目

    如果值區將 WRITEROWNER 權限授予 allUsers 群組,在此情況下,未經驗證 (匿名) 的使用者可以上傳物件,而系統會將預設值區 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 傳回的 XML 文件會使用對應儲存空間供應商的 ACL 語法。如果您使用的工具或程式庫向 Cloud Storage 發出套用 ACL 的要求,而要求使用其他儲存空間供應商的簽名識別碼,則 Cloud Storage 收到的 XML 文件會使用對應儲存空間供應商的 ACL 語法。

    如要進一步瞭解如何使用 XML API 與 Amazon S3 進行互通存取,請參閱從 Amazon S3 遷移至 Google Cloud Storage 一文。

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

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

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

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

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

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

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

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Storage
需要協助嗎?請前往我們的支援網頁