Google PCA: 安全性、合規性與資料保護架構 — 學習指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

屬於 Google Professional Cloud Architect — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Google Cloud 的安全性、合規性與資料保護建立在共同責任與深度防禦的基礎之上。Google 保護底層的基礎架構，而您則負責建構安全的身份、網路、應用程式與資料處理方式。採用零信任 (Zero Trust) 作為指導模型：絕不隱性信任網路、持續驗證身份與情境，並嚴格執行最低權限。為入侵做好設計：假設憑證可能外洩、端點可能被探測、內部服務可能被濫用。透過多重控制措施（預防性、偵測性、回應性）、強大的密碼學與金鑰管理、強健的監控，以及熟練的事件應變來補強。

權衡取捨在所難免。更強的控制措施可能會增加延遲、營運複雜度與成本。您的架構應明確地權衡風險與可用性、效能，同時保持可證明的合規性與鑑識整備度。

身份與存取架構

• 原則與模型

  • 預設為最低權限：僅授予完成任務所需的最小權限集合，並優先使用預先定義的角色或自訂角色，而非基本角色（擁有者 Owner、編輯者 Editor、檢視者 Viewer）。
  • 職責分離：將角色劃分給建構者 (CI/CD)、部署者、維運者與安全人員。使用具備強大控制與日誌記錄的「Break-glass」緊急存取帳號，以供緊急情況使用。
  • 零信任的強制執行：使用情境感知存取來驗證使用者、裝置、位置與風險；要求強式多因素驗證 (MFA)；並持續評估會話情境。
  • 組織政策與 IAM 拒絕政策：將防護機制程式碼化（例如，禁止建立服務帳號金鑰、限制網域共用），並使用拒絕政策來強制執行不可協商的邊界。

• IAM 實作與服務帳號策略

  • 建立階層驅動的存取模型：資料夾反映業務線或環境（生產 prod、非生產 non-prod）；專案隔離爆炸半徑與計費；服務帳號 (SA) 代表工作負載。
  • 一個工作負載，一個服務帳號：避免在無關的服務之間共用 SA。將權限標記到部署範疇（專案）與資源範疇。
  • 優先透過 Service Account Impersonation 與 Workload Identity Federation 使用短期憑證。停用使用者管理的服務帳號金鑰；若無法避免，則應隔離使用、頻繁輪替，並透過稽核日誌進行監控。
  • 使用 Access Boundaries 來在請求時限制被模擬的 SA 可存取的內容（例如，限制 GCS 物件路徑），即使高權限的 SA 被濫用，也能控制爆炸半徑。
  • 條件式 IAM：套用資源層級的條件（時間、IP、主體屬性）來限制存取。例如：禁止從公司 IP 範圍之外或在變更窗口之外存取生產環境。

• 失敗模式與權衡取捨

  • 過度授權的角色（例如，專案範疇的 Editor）會擴大風險；優先使用更細緻的角色，並透過政策分析器進行驗證。
  • 在 CI/CD 與本地腳本中，服務帳號金鑰的氾濫是常見的入侵途徑；使用模擬功能時，某些舊版工具可能需要調整。
  • IAM 拒絕政策功能強大，但可能難以進行故障排除；在非生產環境中，透過明確的試運行 (dry run) 來分階段測試變更。

範例（不建立金鑰的模擬方式）：

undefined

安全性營運、監控與合規

• Security Command Center (SCC) 與威脅偵測

  • SCC 會彙總跨專案和組織的資產清單與發現項目。可用它來建立基準狀態（例如公開的 bucket、開放的防火牆規則）、追蹤狀態偏移，並推動修復工作流程。
  • Premium 威脅偵測功能包含 Event Threat Detection、VM Threat Detection 和 Container Threat Detection，用以識別惡意軟體、加密貨幣挖礦和異常行為。
  • 將發現項目與 ticketing 和 SOAR pipeline 整合；定義附帶到期日的抑制/例外政策，以避免警報疲勞。

• 漏洞與 artifact 安全性

  • 使用 Artifact Analysis 掃描容器映像檔中的 CVE；透過 Binary Authorization 和來自 CI 的簽署證明 (signed attestations)，在部署階段強制執行政策。
  • 透過 OS Config 進行修補程式管理；監控曝險窗口並透過 canary 版本自動化推出更新。

• 稽核日誌、隱私權與證據

  • Cloud Audit Logs 預設提供 Admin Activity 和 System Event 日誌；Data Access 日誌可依服務啟用，並且需要收費。將日誌路由到 BigQuery 進行分析，並路由到 Cloud Storage 以進行不可變的保留和訴訟資料扣留 (legal hold)。
  • 資料分類：使用 Cloud DLP 來探索和分類 PII，套用標籤 (labels and tags)，並對應到保護層級（CMEK、VPC SC、Confidential VMs）。
  • 隱私權與資料落地：透過組織政策限制位置；使 CMEK 和儲存位置符合法規要求。
  • 訴訟資料扣留與保留：啟用 bucket 的保留政策與扣留；在需要時使用物件版本控制 (Object Versioning)。記錄鑑識映像檔和日誌的監管鏈 (chain of custody)，以產出可供辯護的證據。

• 事件應變與鑑識整備

  • 準備 runbook、存取路徑和自動化。確保應變人員擁有最低權限存取，並在整個組織、資料夾和專案中啟用稽核。
  • 圍堵：透過將執行個體從負載平衡器中移除、套用拒絕出口流量的防火牆規則，或將專案移至更嚴格的組織政策下來隔離執行個體；停用遭入侵的服務帳戶，並輪替密鑰和金鑰。
  • 鑑識：對磁碟進行快照並匯出映像檔以進行離線分析；透過匯出保存日誌。在適用情況下使用封包鏡像 (packet mirroring)。避免修改證據；從副本開始作業。
  • 復原：從受信任的映像檔重建，重新注入密鑰，並透過 smoke test 和安全性測試進行驗證。進行事後檢討，並將經驗教訓回饋到防護機制和偵測規則中。

實務問題情境

NimbusPay 是一家金融科技 SaaS 公司，必須在 Google Cloud 上的多租戶微服務中處理標記為 PCI 的資料，強制執行資料必須落地於歐盟 (EU) 的規定，防範 API 層的攻擊，並產出可供稽核的控制措施證據。他們將推出新的 v2 API，同時在同一個主機名稱下維持 v1 的運作。

方法：

1. 分割專案與身分

• 為每個環境和微服務層級（擷取、處理、報告）建立獨立的專案。為每個服務指派一個獨特的 workload service account。理由：隔離爆炸半徑，並將最低權限對應到獨立的工作負載。

2. 強制執行零信任與最低權限

• 將預先定義/自訂的角色授予服務帳戶和 DevOps 群組；套用條件式 IAM，將生產環境的存取限制在公司 IP 和工作時間內。理由：減少橫向移動和意外變更。

3. 移除靜態服務帳戶金鑰

• 透過組織政策停用使用者管理的 SA 金鑰。對 CI/CD 和營運使用 Service Account Impersonation；套用 Access Boundaries，限制每個租戶的 GCS 路徑。理由：消除常見的憑證外洩途徑，並在 token 被盜時仍能限制資料存取。

4. 使用 CMEK 和區域控制來保護資料

• 在 europe-west 區域建立 Cloud KMS keyrings 和 keys；為 BigQuery datasets、GCS buckets 和 Persistent Disks 啟用 CMEK。設定排程輪替和版本監控。理由：提供可證明的加密控制，符合歐盟落地與 PCI 的要求。

5. 對卡號資料採用應用程式層級加密

• 使用信封加密 (Tink AEAD)，將每個租戶的資料金鑰用 CMEK 包覆；資料庫中只儲存密文。理由：提供欄位級別的保護，並在事件分類時最小化影響範圍。

6. 集中管理密鑰並自動輪替

• 將資料庫憑證和 API token 儲存在 Secret Manager 中，並為每個服務設定 IAM。實作由 Pub/Sub 觸發的輪替作業，以建立新版本並更新部署。在可能的情況下，改用 Cloud SQL 的 IAM DB authentication。理由：實現可稽核的密鑰生命週期，並將停機時間降至最低。

7. 分割網路並控制出口流量

• 使用階層式防火牆政策來強制執行 web→API→DB 的流程；直接拒絕 web→DB。為 Google API 啟用 Cloud NAT，並搭配出口流量允許清單和 Private Google Access (restricted)。理由：限制東西向移動，並阻擋未經批准的資料外洩。

8. 使用 VPC Service Controls 包覆資料服務

• 將 BigQuery、GCS 和 Secret Manager 專案放置在一個服務邊界 (service perimeter) 內；定義存取層級，要求必須來自公司 IP 和受控管的裝置。先以 dry-run 模式測試，然後再強制執行。理由：緩解因 token 被盜或客戶端設定錯誤造成的資料外洩風險。

9. 保護邊緣與 API

• 在 global HTTPS load balancer 前端使用 Cloud Armor 的託管規則和速率限制。使用基於路徑的路由將 /v1 和 /v2 分流到不同的後端服務，並為每個版本套用量身訂製的 WAF 政策。整合 Apigee 以進行驗證、配額和 schema 驗證。理由：提供分層的 API 保護、平順的 v1→v2 轉換，並最小化誤報。

10. 強化運算資源並驗證 artifact

• 為處理節點啟用 Shielded VMs 和 Confidential VMs；採用 CIS 強化的基礎映像檔。在 Artifact Registry 中掃描映像檔，並透過 Binary Authorization 要求 GKE 必須有簽署的證明。理由：保護開機鏈和使用中的資料，並強制執行供應鏈信任。

11. 使用 SCC 監控狀態與威脅

• 啟用 SCC Premium 以偵測有風險的設定和執行時威脅；與 ticketing 系統整合以設定 SLA。對已接受的風險設定附帶到期日的抑制規則。理由：提供持續的保證和可採取行動的信號。

12. 記錄、保留並產出證據

• 將 Admin Activity、Data Access 和 VPC Flow Logs 路由到 BigQuery 和 Cloud Storage，並設定保留政策和訴訟資料扣留。為資料集標記落地和敏感度標籤。理由：透過限定範圍的存取，支援調查和外部稽核。

13. 準備事件應變與鑑識

• 建立 runbook，透過將受感染的服務所在的專案移至具有更嚴格政策的隔離資料夾、停用相關的 SA，以及對磁碟進行快照以供離線分析，來隔離受感染的服務。理由：在保全證據的同時快速圍堵。

支援此部署的簡短指令：

undefined

undefined

undefined

透過這些步驟，NimbusPay 達成了分層保護（身分、加密、網路和邊緣）、可驗證的合規性、在單一主機名稱下受控的 API 演進，並準備好偵測、圍堵和從事件中復原。

← 網路、混合式連線與流量架構 · 所有領域 · 可靠性、災難復原與業務連續性 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →