Google ACE: 安全性、合規性與資料保護 — 學習指南
屬於 Google Associate Cloud Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.
總覽
Google Cloud 上的安全性、合規性與資料保護，仰賴的是共同責任模型以及預設安全、縱深防禦的方法。Google 負責保護實體基礎設施、基礎服務和預設加密；而您則負責保護身分與存取、資料分類與保留、應用程式組態以及維運流程。在整個資源階層中，應依循最小權限原則進行設計，多使用群組而非個人、偏好使用受控身分與短期憑證，並採用分層控制，如此一來，任何單一控制的失效都不會導致系統被攻陷。從一開始就建立可觀測性與應變工作流程，以便能持續衡量並改善安全態勢。
身分與存取基礎
- 共同責任與最小權限原則
- 將專案組織在單一機構底下，並使用資料夾來對應信任邊界。套用機構政策 (Organization Policy) 的限制條件來強制執行安全預設值 (例如，不允許公開 IP、限制位置、防止建立服務帳戶金鑰)。
- 將 IAM 角色授予 Google Groups 而非使用者，並優先選用預先定義角色 (predefined roles) 而非基本角色 (basic roles)。定期審查角色繫結 (role bindings) 並移除未使用的權限。
啟用稽核性與歸因性。對於 VM 的管理員作業系統存取，請使用 OS Login 搭配個別使用者的 SSH 金鑰；將 roles/compute.osLogin 或 roles/compute.osAdminLogin 角色授予群組。範例如下：
undefined
-
undefined
常見的失敗模式：將 owner 或 editor 角色授予使用者、使用專案層級的 SSH 金鑰，以及建立長期有效的服務帳戶金鑰。
使用 BeyondCorp 和 Identity-Aware Proxy (IAP) 保護應用程式存取
- IAP 在 Google 的網路邊緣終止對 HTTPS 應用程式和 TCP 轉送 (SSH/RDP) 的身分感知存取，從而無需將應用程式或堡壘主機暴露於網際網路。搭配情境感知存取政策 (Access Context Manager) 來要求裝置狀態、IP 範圍或使用者群組。
- 優點：集中式的驗證 (authN) 與授權 (authZ)、強大的歸因性、縮小的攻擊面，以及簡化的防火牆政策 (拒絕除了負載平衡器/IAP 以外的傳入流量)。
- 權衡取捨：設定錯誤可能會將管理員鎖在門外；保留一條緊急應變路徑 (例如，受限制的專案擁有者、帶外主控台存取)。某些舊版協定或非 HTTP 服務可能需要 IAP TCP 轉送或其他替代控制措施。
服務帳戶與工作負載身分
- 優先將服務帳戶附加到 Compute Engine、使用 Workload Identity 的 GKE、Cloud Run 和 Cloud Functions，讓工作負載能自動取得短期權杖。避免嵌入金鑰；使用機構政策停用服務帳戶金鑰的建立。嚴格限制服務帳戶的 IAM 範圍 (最小權限原則)。
- 失敗模式：廣泛授予 roles/iam.serviceAccountUser 角色，這允許身分模擬；權限過大的服務帳戶成為橫向移動的目標。
資料保護與金鑰管理
- 加密、Cloud KMS、CMEK 與信封加密
- Google 預設會對所有靜態和傳輸中的資料進行加密。若要取得額外的控制權與職責分離，請使用 Cloud KMS 中的客戶自管加密金鑰 (CMEK)。許多服務 (BigQuery、Cloud Storage、Pub/Sub、Compute Engine 磁碟) 都支援 CMEK；這些服務使用信封加密，由您的 CMEK 來包裝每個物件或每個區塊的資料加密金鑰 (DEK)。
規劃金鑰階層：每個區域一個金鑰環 (key ring)、每個資料領域一個加密金鑰 (crypto key)，並根據風險每 90-365 天輪替一次。輪替範例如下：
undefined
存取控制：僅在必要的金鑰上，將 Cloud KMS CryptoKey Encrypter/Decrypter 角色授予服務帳戶。使用 Cloud KMS 使用日誌進行監控。
失敗模式與權衡取捨：停用或刪除 CMEK 會使相依的資料無法讀取；應規劃事件應變手冊、在輪替前仔細檢查 IAM，並在各個部署中維持金鑰的可用性。如果您需要在 Google Cloud 之外持有金鑰，可考慮使用 External Key Manager；但需考量到額外的延遲和外部依賴風險。
Secret Manager 與消除寫死的憑證
- 將 API 金鑰、資料庫密碼和權杖儲存在 Secret Manager 中，它具備自動版本控制和基於 IAM 的存取。透過 Cloud Scheduler → Pub/Sub → Cloud Functions/Run 整合輪替機制，以更新上游系統並寫入新的密鑰版本。應用程式在啟動時或依需求擷取密鑰，並進行最少量的快取。
- 最佳實踐：絕不將密鑰提交到程式碼或映像檔中；避免將密鑰印在日誌裡；將 roles/secretmanager.secretAccessor 角色授予工作負載身分；使用標籤來標記敏感度。
- 失敗模式：將密鑰嵌入環境變數中，導致在崩潰時被記錄到日誌；輪替後忘記更新下游應用程式；對密鑰授予過於寬鬆的 IAM 權限。
資料分類、保留與隱私
- 對資料進行分類 (公開、內部、機密、受監管)，並用標籤標記資產。使用 BigQuery 的資料欄層級安全性和資料列存取政策，以進行精細的控制。若要探索與遮蓋資料，請使用 Sensitive Data Protection (DLP)。
- 實作保留政策：Cloud Storage 物件生命週期 (基於存在時間的儲存級別轉換、刪除)、帶有鎖定的儲存桶保留政策 (bucket retention policies with holds)，以及 BigQuery 資料表或分割區的 TTL。讓保留政策符合法規需求；較長的保留時間會增加風險和成本。
- 隱私與落地：使用機構政策限制資源位置；根據主權與延遲需求，選擇多區域或區域性儲存。透過稽核日誌和 SCC 安全態勢儀表板來產出證明。
網路與邊緣安全 (Network and Edge Security)
網路的縱深防禦
- 使用 VPC 防火牆規則，並採取預設拒絕的姿態；僅允許必要的來源範圍與連接埠。優先使用 Private Google Access 與 Private Service Connect，讓 API 流量不經過公用網際網路。記錄 VPC Flow Logs 與 Firewall Rules Logging；定期檢視 egress 流量模式。
- 針對 egress 流量控制，先拒絕所有 egress 流量，然後透過 FQDN egress proxy 或 NAT 加上 proxy 的方式，明確允許必要的目的地。監控 Cloud NAT log 並設定 DNS logging。
VPC Service Controls (VPC SC)、服務邊界與存取層級
- 將支援的 Google API (例如 BigQuery、Storage、Pub/Sub) 包裹在服務邊界內，以降低資料外洩的風險，即使在憑證被盜用的情況下也能發揮作用。使用 Access Context Manager 依使用者群組、IP 或裝置狀態來定義存取層級，以啟用情境感知政策。
- 在需要時，為合法的跨邊界整合設定 egress 規則與邊界橋接器。在強制執行前，使用 VPC SC 的 dry-run (試運轉) 模式進行測試，以找出潛在的服務中斷點。
- 失敗模式：無意中阻擋了 CI/CD 或跨專案的工作、第三方整合失敗，或開發人員使用未受管理的裝置繞過管制。應將例外情況文件化並定期檢視。
Cloud Armor、DDoS 保護與 WAF 規則
- Google 的全球邊緣網路提供全天候的 L3/L4 DDoS 保護。Cloud Armor 為外部 HTTP(S) 負載平衡器增加了 L7 保護，包括速率限制、基於地理位置/IP 的存取控制、自訂表達式，以及預先設定的 WAF 規則集。
建立並附加一個基本 WAF 的範例：
undefined
-
undefined
- 將此政策附加到您的 HTTPS 負載平衡器後端服務上。
- 最佳實務：先以預覽模式啟動規則以減少誤判，為已知的正常流量新增允許規則，並在符合資格時啟用 adaptive protection。權衡取捨：Cloud Armor 強制執行於 HTTP(S) 與基於 proxy 的負載平衡器上；network load balancer 與內部 LB 則需要其他的控制措施。
安全維運與合規性
Security Command Center (SCC) 與安全態勢管理
- 使用 SCC 作為風險可視性的控制平面。Standard 層級會匯總錯誤設定的發現項目和漏洞資料；Premium 層級則新增威脅偵測 (例如 Event Threat Detection、VM and Container Threat Detection) 和攻擊路徑分析。
- 依嚴重性對發現項目進行分類、指派負責人，並追蹤至結案。將發現項目匯出至 BigQuery 或 Pub/Sub 以便與 SIEM 整合並作為證據。持續根據組織政策衡量安全態勢，並針對惡化情況設定警示。
Shielded VM、安全開機、vTPM、完整性監控與作業系統強化
- 啟用 Shielded VM 功能以阻擋 rootkit 和開機竄改：Secure Boot、vTPM 和 Integrity Monitoring 可偵測開機載入程式和核心的變更。某些自訂核心或未簽署的模組可能會導致 Secure Boot 失敗；在啟用前請先驗證映像檔。
- 使用 OS Config 強化作業系統，以符合修補程式合規性、遵循 CIS 標準的基準、最小化套件、不使用密碼的 SSH，並記錄 sudo 和 auth 事件。建議使用 IAP TCP forwarding 進行 SSH 連線，並限制來自 0.0.0.0/0 的傳入流量。
鑑識日誌、事件分類、圍堵與修復
- 可用於鑑識的日誌：Admin Activity 和 Data Access 稽核日誌、VPC Flow Logs、Firewall Rules Logging、Cloud DNS logs、負載平衡器日誌，以及 Cloud KMS 和 Secret Manager 存取日誌。將日誌匯出至集中化的日誌專案和 BigQuery，並設定適當的保留政策和存取控制。
- 分類與圍堵應變手冊：
- 透過 SCC 的發現項目和相關日誌來驗證指標。
- 透過撤銷可疑的 token、停用遭入侵的服務帳號、新增 deny 防火牆規則或使用標籤暫時隔離執行個體來進行圍堵。
- 保存證據：對磁碟進行快照、匯出日誌、若有需要則使用經核准的工具擷取記憶體，並記錄監管鏈 (chain-of-custody)。
- 進行修復：輪替密鑰和金鑰、修補漏洞、從已知的良好映像檔重建、新增偵測機制以防止再次發生，並執行事件後審查以強化控制措施。
實務問題情境
Nimbus Finance 在外部 HTTP(S) 負載平衡器後方執行網站和 API 工作負載，在 BigQuery 和 Cloud Storage 中處理受監管的資料，並允許工程師進行遠端管理存取。最近一次的紅隊演練顯示，存在因憑證遭竊而導致資料外洩和橫向移動的風險。維運團隊必須在不中斷交付的情況下，強化存取、保護資料並改善偵測能力。
- 透過 OS Login 強制執行管理員歸因
- 步驟：在整個專案啟用 OS Login；將
compute.osAdminLogin權限新增至工程師群組；移除專案層級的 SSH 金鑰。 - 理由：每個使用者的 SSH 金鑰和基於 IAM 的角色授予提供了清晰的歸因和簡單的撤銷方式。消除共用金鑰可減少橫向移動的風險。
- 透過 IAP 和情境感知存取來管制遠端存取
- 步驟：將管理介面置於受 IAP 保護的 HTTPS 負載平衡器後方；透過 Access Context Manager 要求使用者必須是維運群組的成員，且符合公司 IP/裝置的安全狀態。
- 理由：零信任存取消除了對外的公開曝險，並集中強制執行身分和裝置條件，從而降低釣魚和憑證填充攻擊的風險。
- 透過分階段強制執行來實作 Cloud Armor WAF
- 步驟：建立一個 Cloud Armor 政策；在預覽模式下啟用預先設定的 SQLi/XSS WAF 規則；為 /login 新增速率限制規則；監控日誌；然後強制執行。
- 理由：預覽模式可減少誤報；針對性的速率限制可在不影響合法流量的情況下，削弱憑證填充攻擊和機器人的活動。
- 將資料服務納入 VPC Service Controls 的保護範圍
- 步驟：為 BigQuery 和 Cloud Storage 專案建立一個服務邊界；為經核准的 CI/CD 和分析作業定義出口規則；要求存取層級需基於群組和網路。
- 理由：服務邊界透過限制受保護資料的存取位置和方式，來緩解使用有效憑證進行資料外洩的風險。
- 使用 Cloud KMS 套用 CMEK 並排定輪替時程
- 步驟：為 BigQuery 和 Storage 建立區域性金鑰環和加密金鑰；僅將
roles/cloudkms.cryptoKeyEncrypterDecrypter角色授予服務帳號；設定 180 天的輪替排程；監控金鑰使用日誌。 - 理由：CMEK 強制執行職責分離和受控的加密邊界；輪替則限制了金鑰一旦外洩時的影響範圍。
- 使用 Secret Manager 集中管理密鑰並自動化輪替
- 步驟：將資料庫和第三方 token 移至 Secret Manager；授予工作負載最低權限存取；實作一個 Cloud Scheduler → Pub/Sub → Cloud Run 的作業來輪替密鑰並建立新版本。
- 理由：消除寫死在程式碼中的憑證；版本控制和自動化確保了可預測、可稽核的輪替，並將停機時間降至最低。
- 透過 Shielded VM 和作業系統強化來加強主機安全性
- 步驟：在所有 Compute Engine 執行個體上啟用 Secure Boot、vTPM 和 Integrity Monitoring；強制執行不使用密碼的 SSH；使用 OS Config 每週進行修補並套用 CIS 基準。
- 理由：防止開機層級的竄改、偵測狀態偏離，並減少運算節點上可被利用的攻擊面。
- 透過 SCC 提升可觀測性與安全態勢管理
- 步驟：在整個組織啟用 SCC Premium；設定即時通知至 Pub/Sub；將發現項目和日誌匯出至 BigQuery；為關鍵 KPI (例如：未處理的高風險發現項目數量、平均修復時間) 建立儀表板。
- 理由：統一的可視性縮短了從偵測到回應的時間，並提供合規性證據。
- 準備並測試事件應變手冊
- 步驟：記錄分類步驟、特權緊急備用帳號，以及圍堵措施 (停用 IAM、防火牆隔離、撤銷 token)；每季演練一次；在證據專案中強制執行日誌保留和物件鎖定。
- 理由：經過演練的工作流程可減少壓力下的失誤，並保持鑑識的完整性，以利根本原因分析和法規報告。
- 驗證變更並將中斷降至最低
- 步驟：使用 VPC SC 的試運轉模式和 Cloud Armor 的預覽模式來偵測可能造成的中斷；透過金絲雀部署按環境推出；維持一個復原計畫和變更時間窗。
- 理由：受控的推出可緩解因強化安全性而帶來的可用性風險，同時達成降低資料外洩和存取風險的目標。
← 監控、日誌記錄與維運疑難排解 · 所有領域 · 可靠性、備份與災難復原 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →