GCP國際帳號代開 GCP 儲存桶跨項目數據複製與授權步驟

第一章：為什麼「跨項目」會讓你卡住

在同一個 GCP 專案裡複製儲存桶資料通常很直覺：你有權限，你就能讀、你也能寫。但「跨項目」的情境會把問題分成兩層：第一層是 資料存取（讀取來源桶、寫入目標桶），第二層是 授權範圍（你用哪個身分去做、它被允許做哪些操作）。

很多人遇到的失敗其實不是複製工具壞了，而是 IAM 沒給對權限、或給了錯的身分。GCS 的權限模型精細：同一個帳號在不同專案可能被授予不同角色；同一個專案又可能因為你在命令列指定的憑證來源不同而落到另一個身分上。當你還沒把這些「決策點」釐清，就很容易在錯誤訊息裡迷路。

因此，這篇文章會用一個實務導向的方式，把跨項目複製拆成可驗證的步驟：先定義誰要做什麼，再把權限授予到正確的資源與正確的身分，最後才進入複製與驗證。

GCP國際帳號代開 第二章：需求澄清與設計原則

2.1 先回答三個問題

在動手前，建議你把問題寫在紙上（或筆記）：

• 來源桶在哪個專案？目標桶在哪個專案？（可能兩者都在不同專案）
• 你要複製哪些物件？整桶？只複製特定前綴（prefix）？
• 你想用哪種方式跑？臨時人工指令（gsutil）或自動化流程（Cloud Run/Workflows/自架腳本）。

這三個問題決定了後續你該怎麼授權、該用哪些權限範圍，以及怎麼驗證資料。

2.2 最小權限原則，不要先圖省事全開

跨項目時，最容易犯的錯是把角色直接給到寬鬆的層級，例如直接給「專案層級的 Owner」或「Storage Admin」。一旦你把權限放大，短期雖然能跑，但長期風險很高，而且你在排錯時也會更困難：權限過寬讓錯誤不明顯，直到真正出事時才來補救。

更好的策略是：只給複製所需的操作。通常跨桶複製至少要包含「讀來源桶」與「寫目標桶」。在 GCS 的語境下，這往往對應到 Storage Object Viewer/Creator 以及（依需求）List 權限。

2.3 你要的是「複製」還是「同步」

工具常常提供相似功能，但行為差異會影響你的資料正確性。常見差異：

• 複製（copy）：把指定物件複製到目標，但不一定會處理目標端多出來的舊檔。
• 同步（sync）：通常會讓目標端盡量等同來源端，可能會刪除多餘檔案。

若你是做備份、遷移、或只追加新檔，複製往往足夠；若你做的是鏡像目錄，則要更小心同步策略與刪除行為。

第三章：建立與確認儲存桶設定

3.1 檢查儲存桶存取層級

GCS 的「存取層級」會影響你能不能用預期方式存取資料。多數情況下，你應該讓桶保持私有，然後用 IAM 控制存取。

你需要確認：

• 來源桶是否為私有、是否啟用 Uniform bucket-level access（統一桶層級存取）。
• 目標桶是否同樣保持一致策略，以避免預期外的 ACL 行為。

如果你啟用 Uniform bucket-level access，那麼你應該主要依賴 IAM，不要依賴物件層級 ACL。跨項目時，這會讓授權邏輯更一致。

3.2 版本控制、生命週期規則與加密

如果來源桶或目標桶啟用了物件版本（Object Versioning），你在複製時需要理解「要複製目前版本」還是「要複製所有版本」。多數遷移只需要目前版本。

另外，GCS 支援不同加密設定（例如由 Google 管理的加密或客戶管理密鑰）。若目標桶使用客管金鑰（CMEK），你可能還需要額外授權才能寫入或讀取。這也是跨項目常見的卡點之一：你有 Storage 權限，但沒有使用 KMS key 的權限。

因此，複製前建議先確認：

• 是否使用 CMEK
• KMS key 屬於哪個專案
• 複製執行的身分是否被授權使用該 key

第四章：跨項目授權的核心邏輯（先決定身分）

4.1 你要授權給誰：人、服務帳號，還是某個工作負載

跨項目授權最關鍵是：你複製時的「執行身分」究竟是誰。常見三種：

• 你自己登入的使用者帳號（如用 gcloud/gsutil 指令操作）
• 服務帳號（Service Account）（例如在 Cloud Run、GKE、或腳本中跑）
• 自動化服務的預設服務帳號（例如某些服務會在幕後使用它的 runtime 身分）

你需要把權限授予到你真正用來存取 GCS 的那個身份。很多「授權明明有加」的案例，本質是你加的是 A 身分，但你指令實際使用的是 B 身分。

4.2 建議的角色配置（依最小權限）

假設你要從來源桶讀取並複製到目標桶，一般會用到：

• GCP國際帳號代開 來源桶：需要列出物件與讀取物件內容
• 目標桶：需要寫入物件（必要時也需要管理或覆寫策略）

常見做法（以「桶級別」IAM 為主）是：

• 來源桶：授予 Storage Object Viewer（可讀取物件）。若你的指令需要列出物件清單，通常還需要 Storage Object Viewer + 能夠列出（有時在特定行為下，List 权限會以不同方式反映）。
• 目標桶：授予 Storage Object Creator（可建立/寫入物件）。若需要覆寫或刪除，則可能還需要相對應的角色。

若你需要同步並刪除目標端多餘檔案，通常需要更多管理權限（例如 Storage Object Admin 或額外刪除權限）。但如果你只是「copy 指定 prefix」而不做刪除，權限可以維持更窄。

4.3 IAM 授權的位置：桶層級 vs 專案層級

最穩健的方式是：把角色授予到「特定桶」的 IAM，而不是整個專案。原因很簡單：跨項目時你需要精準控制範圍，避免不相關的桶也被授權。

因此，建議流程是：

• 在來源專案中，對來源桶加上執行身分的讀取角色
• 在目標專案中，對目標桶加上執行身分的寫入角色

這樣做能降低日後資料面曝露的風險，也讓你排錯時更集中。

第五章：具體授權步驟（以常見 gsutil 操作為例）

下面以「你在本機端用 gsutil 複製」的情境描述授權步驟。若你在雲端自動化跑腳本，你可以把「身份」換成該工作負載使用的服務帳號。

5.1 確認你將使用的帳號（或服務帳號）

如果你使用人帳號：

• GCP國際帳號代開 確保你本機已使用正確的帳號登入
• 確認 gsutil 指向正確的憑證

如果你使用服務帳號：

• 確認服務帳號的 email
• 確認你的執行環境是否確實以該服務帳號取得憑證（例如在 Cloud Run/VM 要配置正確的 service account）

5.2 在來源桶授予讀取權限

進入來源桶所在專案的 GCS 管理頁面（或用命令列），對來源桶新增 IAM 成員。

你要做的事情是：把執行身分加入，並授予能夠「讀取物件」的角色。

實務上你可能會選擇：

• Storage Object Viewer

若你複製時需要列出前綴（例如要自動掃描所有符合 prefix 的物件），你仍需確保你對列出操作有權限。某些場景下，角色組合會讓行為更穩定。

5.3 在目標桶授予寫入權限

進入目標桶所在專案，同樣對目標桶新增 IAM 成員。

建議授予能夠「寫入物件」的角色，例如：

• Storage Object Creator

如果你的複製策略需要覆寫既有物件或處理特定狀況，你可以在測試後再評估是否需要更高權限。但盡量不要一開始就用最寬鬆角色。

5.4 若使用 CMEK：補上 KMS 的權限

若目標桶採用客管密鑰（CMEK），你還需要對應 KMS key 的權限，否則會出現看似是「存取被拒」但實際原因在 KMS。

通常要確保執行身分具備：

• 對該 KMS key 的使用權（例如 encrypt/decrypt 或對應權限）

若來源桶也使用 CMEK，可能還要對讀取端的 KMS key 授權。這部分常被忽略，導致你在 GCS 層權限全都對了，但仍寫入失敗。

第六章：選擇複製工具與正確做法

6.1 gsutil：最常用、也最容易排錯

gsutil 是最常被採用的工具。它的優點在於錯誤訊息相對明確，你也能觀察進度與重試行為。

假設你要把來源桶某個前綴下的物件複製到目標桶：

• 你要先確定來源路徑的格式（是否包含 trailing slash）
• 確定目標路徑是否要保留原始前綴結構
• 決定是否需要同步（可能涉及刪除行為）

在跨項目情境，gsutil 最終會以你當前憑證作業，所以你只要確保授權給的身分對得上即可。

6.2 遷移大量資料：考量一致性與重試策略

大型遷移要注意：

• GCP國際帳號代開 複製過程中來源桶是否仍在寫入？若仍有變動，你需要決定是否要「分批」或使用多輪複製。
• 目標端是否允許覆寫？覆寫策略不同會影響結果一致性。
• 網路中斷與重試：工具是否能自動續傳或以檔案層級判斷重做。

對於一致性要求高的任務，常見做法是：先進行第一次大批量拷貝，再做第二輪增量複製，最後用清單或 hash 檢查來驗證。

6.3 rclone / 傳輸服務：適合更複雜的場景

GCP國際帳號代開 若你需要更細的傳輸控制（例如多來源、多目的地、速率限制、或結合現有備份系統），rclone 可能更合適。但不管工具怎麼換，授權原理不變：你仍要確保用到的身分在來源端有讀、目標端有寫，且需要時具備 KMS 權限。

因此，工具差異更多體現在操作參數與行為一致性，而不是授權模型。

第七章：資料驗證與驗收（不要跳過）

7.1 驗證什麼：清單、大小、與內容一致性

複製完成後的驗證建議至少包含三層：

• 清單一致：來源與目標在指定 prefix 下，物件數量是否一致。
• 大小與時間戳：通常可以快速排除明顯缺檔或錯位。
• 內容一致性：高要求時可用 hash（例如 md5）或以工具提供的校驗機制。

GCP國際帳號代開 如果你能接受某種低風險（例如只是備份，不需要每 byte 完全一致），可以降低驗證強度。但若你做的是正式遷移，尤其涉及資料一致性或法規要求，內容校驗就很值得做。

7.2 用「差異」來定位問題，而不是用情緒

遇到缺檔時，別急著假設是授權問題。更有效的方式是先找差異：

• 哪些物件在來源有、目標沒有？（可能是前綴匹配錯誤或複製指令範圍設定錯）
• 哪些物件目標有但來源沒有？（可能是第二輪同步刪除策略不同）
• 哪些物件大小不同？（可能是覆寫策略或中途中斷）

用差異縮小範圍，你才能把修復時間降下來。

7.3 讓驗證腳本化：避免下一次再重來

如果你預期未來也會做類似跨項目複製，建議把「清單比對 + 基本一致性檢查」做成腳本。這能避免每次靠人工判斷。

驗證流程的核心不是工具厲害，而是你要把「驗收標準」寫清楚：例如物件數量一致、總大小一致、或對特定抽樣做 hash。

第八章：常見錯誤與排查順序

8.1 403 Forbidden：先看身分，再看權限

跨項目最常遇到的是 403。排查順序建議如下：

• 第一步：確認你使用的身分是否正確（人？服務帳號？）。
• GCP國際帳號代開 第二步：確認授權是否在正確的桶上（來源桶 vs 目標桶）。
• 第三步：確認角色是否涵蓋你使用的操作（List/Read/Write/Overwrite）。
• 第四步：若有 CMEK，確認 KMS 權限。

不要一開始就調整大量權限。先把身分與授權粒度對齊，通常問題就能快速定位。

8.2 404 Not Found：多半是路徑或前綴不對

404 在跨項目常見原因是路徑或前綴寫法錯誤。例如桶名拼錯、object prefix 少了或多了斜線、目標路徑格式導致工具找不到匹配物件。

這種問題通常不是 IAM；你應該優先檢查命令參數、prefix 展開結果與目標路徑。

8.3 中途失敗：超時、限速或重試策略

若複製量大、網路波動或工具沒有適合的重試參數，你可能看到中途失敗。排查要點：

• 是否需要調整並行度或重試次數
• 是否有速率限制或配額問題（配額與限流可能在專案層級）
• 是否在來源桶仍持續寫入，導致某些物件狀態變動

這類問題通常不是「權限」本身，而是傳輸策略與環境限制。

第九章：把流程落地成可重複的作業清單

9.1 文字化你的 SOP

你可以把跨項目複製整理成一份 SOP（標準作業程序），每次照做就能降低踩雷。建議包含以下欄位：

• 來源桶與目標桶（含前綴）
• GCP國際帳號代開 執行身分（人/服務帳號）
• 來源桶授權角色
• 目標桶授權角色
• 是否 CMEK 與 KMS 授權
• 複製命令的參數與預期行為（copy/sync、是否覆寫）
• 驗證標準（物件數、大小、hash 抽樣）

9.2 授權後做小測試，再做全量

很實際的一點：不要一上來就全量。先複製少量物件（例如 prefix 下前 50 個或特定測試檔），驗證：

• 是否能成功讀取與寫入
• GCP國際帳號代開 目標端路徑結構是否正確
• 覆寫策略是否符合預期
• 若用 CMEK 是否寫入成功

測通了再跑全量，你會省下大量時間。

第十章：結語——跨項目複製真正難的是「一致性」與「可驗證」

跨項目複製看似是工具問題，其實核心是授權與驗證。GCS 的權限不是一句「加存取」就能解決；你必須知道執行身分是誰、授權在哪個桶、覆蓋哪些操作，必要時還要把 KMS 跟上。另一方面，複製完成並不等於資料正確。只有把清單一致性與內容一致性驗證納入流程，你才能真正完成遷移或備份。

把上述步驟變成可重複的清單，你每次遇到跨項目需求都會更快、更穩，也更安心。