GCP 資安怎麼分層？從 IAM 到資料邊界與稽核

假設公司把客戶資料放進 Cloud Storage：資料沒有公開，IAM 也只授權幾位工程師。這樣就夠安全了嗎？還要問工程師的帳號若被盜會怎樣、金鑰停用後資料能不能讀、可疑存取有沒有留下紀錄，以及資料能否被複製到公司以外的專案。

這篇沿著同一份資料，看看身分、偵測、加密和服務邊界各守哪一段。內容會碰到一些比 ACE 考綱深的東西；考試先分清服務用途，真要上線則必須依自己的資料流和合規要求逐項驗證。

先問「誰能做什麼」，再問「他怎麼進來」

IAM 決定身分可以對哪些資源執行哪些操作。常見的問題不是完全沒設權限，而是為了趕進度，把專案層級的 Editor 或 Owner 給了只需要讀取單一 bucket 的帳號。做權限盤點時，先列出工作實際需要的動作，再找合適的預先定義角色與授權層級；不要只把 Owner 換成 Editor，就當作完成最小權限。

IAM 之外還有一層組織政策（Organization Policy）。IAM 管「誰」能對資源做什麼；組織政策管資源「能被怎麼設定」，例如新資源只能建在哪些地區、資源能不能分享給公司網域以外的身分。有 IAM 權限的人一樣要遵守這些限制，兩者怎麼搭配可看 GCP-105：IAM 入門。

那登入公司內部網站呢？如果只憑「人在 VPN 裡」就放行，一組被盜的憑證可能拿到不必要的入口。Identity-Aware Proxy（IAP）可以替受支援的應用加上身分驗證與授權；需要再看裝置或來源情境時，可搭配 Access Context Manager 設定條件。IAP 的作用與適用資源、Chrome Enterprise Premium 的存取保護都有各自的前提，不能拿一段示意 YAML 就宣稱「已啟用零信任」。

這也不是「IAP 比 VPN 安全，所以所有 VPN 都該換掉」。有些私有應用仍需要網路連通性；多雲或地端環境可能還要 VPN、Interconnect 或其他連線方式。兩者回答的問題不同：網路怎麼通，以及誰在什麼情境下能使用應用。做選型時，先畫出使用者和應用實際在哪裡，再談產品。

雲端服務商會維護其基礎設施；客戶仍要負責自己的身分、設定、資料和應用。責任分工還會隨使用的服務而變，不能靠一句「Google 顧雲、我顧資料」解決所有問題。Google Cloud 的共同責任說明可作為盤點起點。

有告警，還要有人接手

Security Command Center（SCC）會彙整安全發現結果（finding），例如資源設定風險或偵測到的威脅。看到 finding 時，不要只看紅色嚴重度標籤。先確認受影響的是正式環境還是測試環境、有沒有對外入口、資料敏感度多高、誰能修、修完怎麼驗證。關閉告警不等於風險已消失。

SCC 的方案和偵測能力近年變動很快。官方服務層級目前區分 Standard、Premium 與已標示棄用的 Enterprise；同名功能也可能因啟用時間或遷移歷史而不同。尤其不能只憑「Premium」就推定某組 Security Health Analytics 偵測器一定可用；官方的功能說明要求先看環境的啟用方式，新的環境也可能改用 Compliance Manager。選方案前，直接核對自己環境中的可用服務與定價，別背一張固定勾選表。

稽核紀錄和 SCC 也不是同一件事。Cloud Audit Logs 記下受支援服務中的管理、存取等操作；SCC 幫你整理特定風險與威脅。稽核日誌本身也分類型：Admin Activity 記錄誰改了資源設定，一律寫入、不能停用；Data Access 記錄誰讀寫了資料，卻不一定有開。若要追查「誰讀了客戶表」，先確認那個服務的 Data Access 稽核日誌是否有開、記錄保存在哪裡、誰能讀。官方最佳實務指出，除了 BigQuery，Data Access 日誌通常預設關閉。沒有先打開，事後不能靠 SCC 把缺失的存取紀錄補回來。各類日誌怎麼查，見 GCP-106：監控與日誌入門。

遇到高風險 finding，我會用這個順序處理：確認它不是誤判、找出暴露路徑與受影響資料、指定處置人、修正設定，再重新檢查同類資源。需要即時通知時，可按官方匯出方式把符合條件的 finding 送往 Pub/Sub；但通知送到 Slack，只表示有人收到訊息，還不代表有人處理。

金鑰、密碼和資料加密，不要混成一件事

Google Cloud 對儲存中的客戶資料有預設加密。Cloud KMS 的 CMEK 是額外的控制：在支援的服務中，由你管理用來保護資料的金鑰及其存取權，而不是把未加密資料「升級」為有加密。CMEK 的服務整合需要逐一確認服務、區域和授權條件。

金鑰輪替特別容易被一句話帶過。Cloud KMS 文件說得很明白：輪替會建立新版本，但既有密文不會因為按下輪替就自動重新加密，舊版本也不會自動停用。各 CMEK 整合服務對舊資料的處理還可能不同。要停用或銷毀舊版本前，先確認仍有哪些資料依賴它；做錯可能讓資料無法復原。

如果政策要求金鑰由硬體安全模組保護，可以研究 Cloud HSM；如果金鑰材料必須留在外部系統，則評估 Cloud EKM。但外部金鑰不是免費的「安全加分」：外部服務失聯時，受保護資料也可能讀不到。Cloud EKM 的限制與風險應和可用性、事故應變一起評估。

資料庫密碼、API token 又是另一類東西。它們是應用要使用的機密值，適合放在 Secret Manager，以版本和 IAM 控制存取，而不是當作 KMS 金鑰管理。應用拿到密碼後，仍可能把它印進日誌或錯誤訊息；搬進 Secret Manager 只是降低暴露面，不會替程式消除外洩風險。

至於傳輸中的資料，要看連線是否依服務要求使用 TLS 等保護；有特別的使用中資料保護需求，再評估 Confidential Computing。不要把「靜態、傳輸中、使用中」排成人人都要買齊的三階方案。先找出實際威脅與資料流，再決定要補哪一層。

把這一節的分工收成一張表：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

VPC Service Controls：限制特定服務的跨界請求

回到那個客戶資料 bucket。如果帳號本來就有讀取權，卻被人拿來把資料複製到公司以外的 Cloud Storage 資源，單看 IAM 可能仍是合法操作。VPC Service Controls 可以替支援的 Google Cloud 服務設定 service perimeter，限制某些跨邊界的請求，降低這類外洩風險。

它不是網路防火牆，也不取代 IAM。IAM 問「這個身分能不能讀」；服務邊界再問「這次對受保護服務的請求，能不能跨越指定範圍」。如果服務沒納入邊界、API 不受支援，或資料已經進入其他可用的外送路徑，不能預設 VPC Service Controls 仍會擋住。也不要把資料外洩防護說成「開了就萬無一失」。

實際規劃時，先列出邊界內的專案與受限服務，再畫出合法的跨界流程：外部管理員需要讀哪些資料？備份要去另一個專案嗎？CI/CD 是否跨專案部署？需要放行時，才設計 ingress 與 egress 規則。這些規則和 IAM 要一起成立，不能只放寬其中一邊就期待工作正常。

正式強制之前，先用 dry run 觀察哪些請求會被擋，找出合法流量並修正設定。Dry run 只記錄、不阻擋；要看見被拒絕的請求，還得檢查相關日誌與監控。這一步不適合用「照範例貼一份 YAML」取代，因為每個組織的專案、服務和對外工作流程都不同。

合規：工具可以提供證據，不能替你作法律判斷

最容易出錯的寫法，是把 GDPR、SOC 2、HIPAA 各配幾個 Google Cloud 產品，就宣稱「已符合」。實際上，適用法規、合約、資料類型、處理目的、保存期限與組織流程都會改變要求。這裡只談技術盤點，不提供法律或稽核結論；正式專案應由法務、資安及稽核團隊確認。

例如涉及 GDPR 的個人資料，先問資料在哪些區域處理、誰能存取、如何回應當事人請求，以及與供應商之間的資料處理條款。Google 的資料處理附錄是合約的一部分，但選一個歐洲區域 bucket 或 KMS 金鑰，並不能單獨證明所有資料都只留在歐盟，也不能取代刪除與權利請求流程。

要準備 SOC 2 稽核，就把控制與證據對起來：誰核准權限？變更如何經過審查？事故由誰處理？IAM 清單、稽核日誌與 SCC finding 能提供素材，但一份匯出檔本身不能證明控制長期有效。保存多久，也應依組織適用要求決定，不能照文章抄「一律保留一年」。

若處理美國受保護健康資訊（PHI），先確認組織是否適用 HIPAA、是否需要與 Google 簽訂 BAA，並逐一核對資料經過的產品是否在當前 BAA 涵蓋範圍。Google 官方 HIPAA 指南明確說明：BAA 和受涵蓋產品只是條件之一，客戶仍要配置和保護自己建的系統。把特定產品一概列為「禁止存放」的對照表並不可靠，應以當期官方清單和已簽合約為準。

用一份資料做最後檢查

現在把客戶資料的路徑從頭走一次，比在檢查清單上全部打勾有用：

1. 誰會碰到資料？ 列出人員、服務帳號與供應商，檢查每個身分的角色與授權範圍。
2. 入口在哪裡？ 管理介面、API、批次工作各從哪裡進來；該做身分驗證的地方是否真的受保護。
3. 資料放在哪裡？ 原始資料、備份、匯出檔和機密值是否都在盤點中；需要 CMEK 時，支援、區域與金鑰權限是否驗過。
4. 資料能去哪裡？ 跨專案、跨組織與外部系統的流向是否必要；若設 VPC Service Controls，合法路徑有沒有先在 dry run 測過。
5. 出了事怎麼知道？ 需要的 Data Access 日誌是否啟用；SCC finding、通知與人工處置之間有沒有負責人和回報期限。

備考時可以把它拆成幾個小問題：問最小權限，先看 IAM 的角色與授權範圍；問密碼存放，想到 Secret Manager；問客戶控管加密金鑰，查 Cloud KMS／CMEK；問受支援服務的跨界資料存取，才看 VPC Service Controls。考題可以用關鍵字快速判斷，正式環境還是要把整條資料流走完。

下一篇 ACE-301：搬上 Google Cloud 前，先把遷移計畫排清楚會從資產和相依關係的盤點開始。