跳至主要內容
登雲學院 CloudOn 登雲學院.
ESC
跳到課程內容
安全與合規設計 資料安全與加密策略
0%
13 / 25 進階 30 分鐘 00:00

資料安全與加密策略

依資料生命週期選擇加密、金鑰、secret、資料邊界與偵測控制，並驗證失效時的系統行為

2026年3月13日 Updated: 2026年7月17日

從資料流程開始，而不是從 KMS 開始

一份有效的資料保護設計，會先回答：

  • 系統收集哪些資料？哪些欄位是個資、付款資料、商業機密或公開資料？
  • 資料在哪裡產生、傳輸、暫存、處理、備份和刪除？
  • 哪些人、workload 和 Google Cloud services 需要讀取？
  • 資料離開信任邊界時，應阻擋、遮罩、聚合，還是經過核准？
  • 金鑰、secret 或安全服務不可用時，系統應停止、降級還是排隊？

沒有這張 data flow，CMEK、VPC Service Controls 和 DLP 很容易變成昂貴但互不相連的勾選項目。

資料從收集、傳輸、儲存、處理到分享時套用多層防禦控制的生命週期圖

圖解：資料在傳輸、靜態與使用中需要不同保護；身分、金鑰、secret、服務邊界、敏感資料偵測與異常監控要沿著同一條資料生命週期互相補位。

靜態、傳輸中與使用中的保護

靜態資料

Google Cloud 儲存的 customer data 預設會加密。若需要更多金鑰控制，再評估服務是否支援以下方式：

  • CMEK：在 Cloud KMS 管理 key，Google Cloud service 用它包裝保護資料的 data encryption keys。可控制 IAM、rotation、disable 和 destruction。
  • Cloud HSM key：key operations 在 FIPS 驗證的 HSM 中執行，適合明確要求硬體保護的情境。
  • Cloud EKM：key material 留在支援的外部 key manager，Google 需要透過 EKM 連線完成操作。
  • CSEK：客戶在每次支援的 API operation 提供 key；只有部分服務和操作支援，營運風險高，不能當成通用的「最高安全」選項。

選 CMEK 前要確認服務、resource type、location、建立時機與 key rotation behavior。不是所有 Google Cloud resource 都能事後補 CMEK，也不是 rotation 後所有既有資料都會自動以新版本重加密。

傳輸中的資料

Google Cloud API 一般使用 TLS，Google infrastructure 也有自己的傳輸保護。應用架構仍要逐段確認：client 到 load balancer、load balancer 到 backend、service-to-service、hybrid link、database connection 和第三方 API。

例如 Cloud Interconnect 預設不等於 IPsec 加密；內部 IP 也不等於應用身分已驗證。若 threat model 要求雙向服務身分，可評估 mTLS、Cloud Service Mesh 或應用層憑證。

使用中的資料

Confidential Computing 可以在支援的 machine、GKE node 或服務上保護使用中的 memory，降低 host／hypervisor 層威脅。實際機密運算技術、machine family、accelerator、live migration 和功能限制會不同。

它不會保護應用自己把明文寫進 log，也不會取代 IAM、資料最小化與程式安全。採用前應先明確說明要降低哪一種威脅，再確認 workload 相容性和效能。

Cloud KMS：輪替不等於資料全部換鎖

KMS 的主要階層是：

Key ring → CryptoKey → CryptoKey version

Key ring 和 key 有 location 與 purpose；真正執行 cryptographic operation 的是 key version。治理時要處理：

  • Key admin 和 key user 的職責分離。
  • Key location 是否和受保護 resource 的要求相容。
  • Rotation schedule、事件觸發的 manual rotation 和 asymmetric key 的額外步驟。
  • Disable／destroy 前的 key usage inventory、復原期和核准。
  • KMS quota、latency 和跨專案 service agent 權限。

Symmetric key 可以設定 automatic rotation，但輪替只是建立新的 primary version。對 CMEK-integrated service 而言，之後可能是：所有 DEKs 逐步換成新版本、只有新資料使用新版本，或 resource 繼續使用原本版本。應查 CMEK rotation behavior，不能看到 primary 換了就刪舊 version。

EKM 帶來的是控制，也帶來依賴

Cloud EKM 適合 key material 必須留在外部系統的要求，但外部 key manager、網路或授權失效時，Google Cloud service 可能無法解密資料並造成 outage。要把 EKM availability、quota、latency、emergency access、rotation 和復原一起納入 SLO，不應只寫「key 不在 Google」。

Secret Manager：保存機密值，不是加密整個資料庫

Secret Manager 適合 API credential、password、certificate material 或其他小型 secret。每次新增內容會建立版本，consumer 可指定版本或 alias。

一個完整的 secret lifecycle 包括：

  1. 由哪個系統產生 secret。
  2. 哪個 runtime identity 能讀取。
  3. Consumer 如何快取，以及輪替後多久重新載入。
  4. 新舊 credential 如何短暫共存並驗證。
  5. 舊版本何時 disable／destroy。
  6. Access log 與異常讀取如何告警。

Secret Manager 能保存版本，不代表外部資料庫密碼會自動輪替。Rotation 通常需要 workflow 同時更新來源系統、Secret Manager 和 consumers，並處理失敗回滾。

VPC Service Controls：控制受支援服務的資料跨界

VPC Service Controls（VPC SC）在支援的 Google-managed services 周圍建立 service perimeter，補上 IAM 之外的 context 與 egress 控制。常見目的包括：

  • 限制從未授權網路或身分存取 perimeter 內資源。
  • 阻擋透過受保護 service operation，把資料複製到 perimeter 外資源。
  • 用 ingress／egress rules 明確允許跨 perimeter 工作流。
  • 搭配 restricted VIP，限制 workload 能呼叫的 Google APIs。

它不是 VPC firewall，也不會攔住所有第三方網際網路流量；主要保護支援服務的 data movement，metadata 也可能有不同限制。IAM 仍決定 principal 是否能操作 resource，兩者要一起使用。

部署時先建立 data flow inventory，確認使用的 services 和 methods 受支援，再用 dry-run 查看違規請求。Dry-run 只預覽 perimeter policy，不會替你驗證 restricted／private VIP 的所有影響。不要固定等幾週才切換；應以完整業務週期、批次作業和故障流程都被觀察到為準。

Sensitive Data Protection：先發現，再決定怎麼處理

Cloud DLP API 現在屬於 Sensitive Data Protection。它可以在文字、圖片和支援的資料來源中偵測 infoTypes，並做 masking、redaction、tokenization、pseudonymization 或其他 de-identification。

使用前要處理兩類品質問題：

  • False positive：正常資料被誤判，導致流程阻塞或分析失真。
  • False negative：自訂格式、錯字或影像中的敏感資料沒有被找出。

因此要用自己的資料建立 sampling 和 validation，調整 likelihood、hotword、exclusion 和 custom infoType。De-identification 是否可逆、key 如何保存、researcher 是否能重新識別，也要納入 threat model。

偵測與供應鏈控制

Security Command Center

Security Command Center（SCC）彙整組織的 misconfiguration、vulnerability、threat 與其他 security findings。各 service tier 的功能持續調整，不宜用一張靜態勾選表做架構。實際規劃應問：

  • 哪些 detectors 和 Google Cloud services 要涵蓋？
  • Findings 要送到哪個 ticket、SIEM 或 automation？
  • 誰負責 triage，修復期限按什麼風險分級？
  • 如何處理 exception、duplicate 和已接受風險？

只有開啟 SCC、沒有人處理 findings，不算完成控制。

Binary Authorization

Binary Authorization 可以在支援的 GKE、Cloud Run 等部署路徑檢查 image 是否符合 policy。Attestation 應代表可驗證的 pipeline evidence，例如 source、tests、vulnerability policy 和簽署身分，而不是「build 跑完就無條件蓋章」。

正式環境還要定義 break-glass deployment、事後 review、policy update 權限，以及 image digest，不依賴可變 tag。

Model Armor

Model Armor 可在支援的生成式 AI request／response path 檢查 prompt injection、敏感資料或內容安全風險。是否使用、套哪些 template 和阻擋／記錄策略，要依應用 threat model、false positive 成本和資料處理要求決定。

它不保證回答正確，也不取代 retrieval ACL、tool authorization、模型評估和人工覆核。低風險內部摘要與能執行付款的公開 agent，需要的控制不會一樣。

情境練習：提供去識別化醫療資料

假設研究團隊需要分析病患紀錄，但不應接觸直接識別資訊：

  1. 先盤點 PHI 欄位、來源、derived data、backup 和研究輸出。
  2. Production project 以 IAM 和 VPC SC 限制原始資料；跨 perimeter export 只允許受控 pipeline。
  3. Pipeline 用 Sensitive Data Protection 加上業務規則做去識別化，驗證 false negative 與 re-identification risk。
  4. 研究資料輸出到獨立 project，授權給 researcher group，而不是讓研究者查 production。
  5. 若合規要求 CMEK，分離 key admin 與 data admin，測試 key disable 對 pipeline 和讀取的影響。
  6. Secrets 由 runtime identity 在執行時讀取，不寫進 image 或 notebook。
  7. Audit Logs、VPC SC violations 和 SCC findings 進入有 owner 與 response SLA 的流程。

這個方案的核心不是把每個安全產品都放進圖裡，而是原始資料只能沿著可審核的路徑，轉成風險較低的研究資料。

本課檢查清單

  • Google Cloud 預設加密靜態資料；CMEK 增加控制，也增加 key availability 責任。
  • CMEK support、location、設定時機與 rotation behavior 都是 service-specific。
  • Key rotation 不代表所有既有資料自動重加密，舊 version 不能貿然銷毀。
  • Secret rotation 是跨來源系統、Secret Manager 和 consumer 的 workflow。
  • VPC SC 控制受支援 Google-managed services 的資料跨界，不是通用網路 firewall。
  • Sensitive Data Protection 需要用真實資料驗證 false positive、false negative 和再識別風險。
  • SCC findings、Binary Authorization policy 和 Model Armor 都需要 owner、例外和回應流程。

延伸閱讀

下一步

下一課會把這些控制放進合規與稽核流程，釐清「有產品」和「有足夠證據證明控制有效」之間的差別。

徽章解鎖！