儲存安全性簡介
保護靜態資料不僅僅涉及加密。在 Google Cloud 中，Cloud Storage 與 Secret Manager 是儲存持續性物件與敏感配置資料（如 API 金鑰與資料庫密碼）的兩個主要服務。
對於 PSE 而言，您必須了解如何透過保留政策強制執行合規性、透過精細的 IAM 管理存取權限，並防止資料遺失或未經授權的披露。
白話文解釋
Bucket Lock 像銀行金庫的時間鎖
銀行金庫的時間延遲鎖只有在計時器到期後才能開啟——即便是行長也無法提前打開。設定 7 年保留政策的 Bucket Lock 運作方式完全相同：一旦執行 gsutil retention lock 提交鎖定，無論是專案擁有者 (Project Owner)、組織管理員 (Org Admin)，甚至 Google 技術支援都無法縮短或移除該政策。在儲存桶中每一個物件都通過保留期限之前，儲存桶本身都無法被刪除。這正是 SEC Rule 17a-4 與 FINRA 等監管機關對 WORM (Write Once, Read Many) 合規的具體要求。
Secret Manager 像銀行保管箱（Safe Deposit Box）
銀行保管箱有三種角色：銀行經理可以租用或銷毀箱子（對應 Secret Manager Admin）、持鑰人可以開箱讀取內容（對應 Secret Manager Secret Accessor）、大廳訪客只能看到箱號目錄但無法開啟任何一個（對應 Secret Manager Viewer）。生產環境中常見的錯誤是當應用程式只需要讀取酬載時，卻授予了 roles/secretmanager.admin——應該只給 Compute Engine 預設服務帳戶 secretAccessor 角色，且範圍要鎖定到單一密鑰資源，而不是整個專案。
Signed URL 像演唱會電子票
簽署網址 (Signed URL) 就像演唱會某個特定座位的電子票——它只在數小時內有效、讓一個人入場、然後過期作廢。您可以使用 gsutil signurl -d 1h key.json gs://bucket/object 產生，或透過服務帳戶支援的 V4 簽署流程。收件人不需要有 Google 帳戶，但他們也無法延長到期時間或在過期後重複使用該網址。簽署政策文件 (Signed Policy Document) 則是上傳版本：讓瀏覽器直接 POST 檔案到儲存桶，並可附加大小、MIME 類型等限制，全程不需要經過您的後端伺服器。
Cloud Storage：強化儲存桶安全性
1. 存取控制：統一 vs. 精細
- 統一儲存桶層級存取 (Uniform Bucket-Level Access)： 停用 ACL 並僅使用 IAM 進行存取控制。這是簡化且一致化安全管理的推薦做法。
- 精細 (ACLs)： 允許針對個別物件設定權限。這可能導致「混淆代理人 (Confused Deputy)」問題，且難以稽核。
使用組織政策 (Organization Policy) storage.uniformBucketLevelAccess 來強制整個專案或組織實施統一存取控制。
2. 防止公開存取 (Public Access Prevention)
意外的公開暴露是資料外洩的主要原因。
- 防止公開存取 (PAP)： 一項儲存桶層級的設定，即使 ACL 或 IAM 角色允許，也會封鎖所有公開存取。
- 組織政策：
storage.publicAccessPrevention可以全域強制執行此設定。
將 allUsers 或 allAuthenticatedUsers 授予 roles/storage.objectViewer 角色並不會追溯觸發 PAP——PAP 僅會阻擋啟用後新增的公開繫結。請先以 gcloud projects get-iam-policy 稽核現有繫結，並在啟用 PAP 前移除舊有的公開 ACL，否則只是製造虛假的安全感。
3. 簽署網址與簽署政策文件
當您需要為沒有 Google 帳戶的使用者提供臨時存取權時：
- 簽署網址 (Signed URL)： 為特定物件提供限時存取（例如 1 小時）。
- 簽署政策文件 (Signed Policy Document)： 允許使用者在有限時間內，根據特定限制（大小、類型）將檔案上傳到儲存桶。
資料完整性與合規性
儲存桶鎖定與保留政策
為了滿足監管合規性（如 SEC Rule 17a-4），您可以使用儲存桶鎖定 (Bucket Lock)。
- 保留政策 (Retention Policy)： 指定物件必須保留的最短時間（例如 7 年）。
- 儲存桶鎖定： 一旦鎖定，保留政策將無法縮短或移除，且在所有物件都達到保留期限之前，無法刪除該儲存桶。
儲存桶鎖定是不可逆的。 即使是專案擁有者或組織管理員，也無法刪除含有仍處於保留期內物件的已鎖定儲存桶。
物件版本控制與勒索軟體防護
- 物件版本控制 (Object Versioning)： 保留變更歷史記錄。如果物件被意外刪除或被勒索軟體覆寫，您可以還原先前的版本。
- 非目前版本保留： 您可以將版本控制與生命週期管理結合，將舊版本保留特定時間。
Secret Manager：管理敏感資料
Secret Manager 是密鑰的集中式「單一事實來源 (Source of Truth)」。
1. 版本控制與生命週期
密鑰是具備版本的。應用程式理想上應指向特定版本，或使用 latest 別名（儘管在生產環境中如果不謹慎處理，latest 可能存在風險）。
- 輪替 (Rotation)： 您可以設定 Secret Manager 透過 Cloud Functions 自動輪替密鑰（例如更新資料庫密碼）。
2. Secret Manager 的 IAM 權限
- Secret Manager 管理員 (Secret Manager Admin)： 可以管理密鑰本身（刪除/輪替）。
- Secret Manager 密鑰存取者 (Secret Manager Secret Accessor)： 可以讀取密鑰酬載 (Payload)。
- Secret Manager 檢視者 (Secret Manager Viewer)： 可以查看元數據但無法查看密鑰值。
Secret Manager 是一個安全且便利的儲存系統，用於儲存 API 金鑰、密碼、憑證及其他敏感資料。它為整個 Google Cloud 的密鑰提供了單一事實來源。
與運算服務整合
- Cloud Run / Functions： 可以將密鑰掛載為環境變數或磁碟區。通常將其掛載為磁碟區 (Volume) 比環境變數更安全。
- GKE： 使用 External Secrets Operator 或 Secret Store CSI Driver 將 Secret Manager 中的密鑰同步到 Kubernetes Secrets 中，而無需將其儲存在
etcd中。
存取稽核
對密鑰或儲存物件的每次存取都會記錄在 Cloud Audit Logs 中（如果啟用了資料存取記錄）。
- Storage：
storage.objects.get、storage.objects.create。 - Secret Manager：
secretmanager.versions.access。
Bucket Lock、保留政策與 WORM 合規深度解析
保留政策 vs. 物件保留 vs. Bucket Lock
三個獨立的機制各自強制執行不可變性——考題的關鍵就在於辨別該用哪一個：
| 機制 | 適用範圍 | 是否可逆？ | 使用情境 |
|---|---|---|---|
| 保留政策 (未鎖定) | 儲存桶 | 是，可縮短 | 內部資料治理 |
| Bucket Lock | 儲存桶 | 否 | SEC 17a-4、FINRA、MiFID II |
| 事件型保留 (Event-Based Hold) | 個別物件 | 是 (依事件釋放) | 訴訟待決事件 |
| 臨時保留 (Temporary Hold) | 個別物件 | 是 | 調查中保留 |
Signed URL 內部原理
V4 簽署網址是透過簽署服務帳戶的私鑰，對標準化請求（HTTP 方法、標頭、到期時間）進行雜湊產生。兩個重要特性：
- 簽署者的 IAM 權限決定授權範圍——若簽署 SA 之後失去
storage.objects.get，已發出的網址在到期前仍可繼續使用（簽章已產生）。 - 若不想下載金鑰檔，呼叫方需具備簽署 SA 上的
iam.serviceAccounts.signBlob權限，並呼叫iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<sa>:signBlob。
為何 Bucket Lock 比 Object Lifecycle 更適合合規
物件生命週期管理 (Object Lifecycle Management) 可以隨時被編輯或停用——稽核人員不會接受它作為合規控制項。鎖定保留政策的 Bucket Lock 是 Cloud Storage 中唯一通過 SEC Rule 17a-4(f) WORM 電子記錄認證的功能，這已由 Google 委託 Cohasset Associates 第三方評估確認。
一旦透過 gsutil retention lock gs://my-bucket 將保留政策鎖定，唯一能刪除該儲存桶的方法就是等待每一個物件都通過保留期限。請審慎規劃容量——對 100 TB 的儲存桶執行 7 年鎖定，意味著至少 7 年的儲存成本將被鎖死。
Secret Manager 版本、副本與 CMEK
版本生命週期狀態
每個密鑰都是由一連串版本組成，每個版本處於以下三種狀態之一：
- ENABLED（已啟用）： 可透過
secretmanager.versions.access讀取。新建版本的預設狀態。 - DISABLED（已停用）： 無法讀取，但密文仍被保留。可逆——能再切回 ENABLED。
- DESTROYED（已銷毀）： 底層密鑰材料被永久抹除。不可逆。 元數據仍會保留供稽核。
latest 別名會解析為已啟用版本中編號最高者。若您停用 v5，latest 會回退到 v4——這對於輪替失敗後的即時回滾非常實用。
副本機制：自動 vs. 使用者管理
密鑰建立時必須選擇副本政策，且事後無法變更：
- 自動副本 (Automatic Replication)： Google 自動為您挑選多個區域儲存密鑰。適合全球性應用程式；操作最簡單。
- 使用者管理副本 (User-Managed Replication)： 您明確列出特定區域（例如
us-central1、europe-west4）。當需要符合資料居留 / 資料主權法規（GDPR、FedRAMP、各國資料在地化法律）且密鑰酬載不得離開特定地理範圍時，這是必選項。
客戶管理加密金鑰 (CMEK)
預設情況下 Secret Manager 使用 Google 管理金鑰加密酬載。若要滿足更嚴格的合規要求：
- 搭配使用者管理副本時，您可以為每個副本區域指定一把 Cloud KMS 金鑰。KMS 金鑰必須與副本位於同一區域，否則 Secret Manager 會拒絕綁定。
- 必須將
roles/cloudkms.cryptoKeyEncrypterDecrypter授予 Secret Manager 服務代理 (service-<project-number>@gcp-sa-secretmanager.iam.gserviceaccount.com)，且每把金鑰都要授予一次。 - 停用或銷毀 KMS 金鑰會使所有依賴的密鑰版本無法存取——銷毀 KMS 金鑰等同於銷毀密鑰本身，操作前務必三思。
IAM secretAccessor 範圍
請將 roles/secretmanager.secretAccessor 套用於密鑰資源層級，而非專案層級：
gcloud secrets add-iam-policy-binding db-password \
--member="serviceAccount:[email protected]" \
--role="roles/secretmanager.secretAccessor"
在專案層級授權會讓主體能讀取專案內每一個密鑰——這是典型的最小權限違規，會被 Security Command Center 的 IAM_SCANNER 偵測器標記。
PSE 必背 WORM 三件套： 保留政策（計時器） + Bucket Lock（不可逆性） + 物件版本控制（回滾機制）。三者搭配才能形成防勒索軟體的合規封存。少了版本控制，取得寫入權的攻擊者仍可在保留期限內就地覆寫物件內容。
PSE 考試情境
情境 1：防止意外刪除
「一家公司需要確保儲存在 GCS 中的財務記錄在 5 年內不能被任何人（包括管理員）刪除，以滿足法律要求。您應該怎麼做？」 解答： 建立一個 Cloud Storage 儲存桶，設定 5 年的保留政策 (Retention Policy)，然後執行儲存桶鎖定 (Lock the Bucket)。
情境 2：安全地向 GKE 傳遞密鑰
「如何以最安全的方式將儲存在 Secret Manager 中的資料庫密碼提供給在 GKE 上執行的容器化應用程式？」 解答： 使用 Secret Store CSI Driver。這允許 GKE Pod 以掛載磁碟區的形式直接從 Secret Manager 存取密鑰，確保密鑰不會寫入 GKE 節點的磁碟或不安全地儲存在 Kubernetes API 中。
總結檢查表
- 對比統一儲存桶層級存取與 ACL 的差異。
- 解釋儲存桶鎖定如何強制執行 WORM (一寫多讀) 合規性。
- 描述簽署網址 (Signed URL) 的使用情境。
- 識別讀取密鑰值所需的 IAM 角色。
- 解釋搭配 Cloud Functions 進行密鑰輪替的好處。
- 列出保護 GCS 免受勒索軟體攻擊的技術。