透過組織策略實現合規性簡介
對於 專業雲端安全工程師 (PSE) 而言，組織策略服務（Organization Policy Service）是實現「合規即代碼」(Compliance as Code) 的主要機制。IAM 控制「誰」可以訪問資源，而組織策略則強制執行「如何」配置這些資源，以滿足 PCI DSS、HIPAA 或 GDPR 等監管標準。
透過使用組織策略，您可以創建一個「安全登陸區」(Secure Landing Zone)，讓每個專案自動繼承必要的安全護欄，防止配置漂移並降低人為錯誤的風險。
白話文解釋（Plain English Explanation）
類比一：城市的建築法規
把 Organization Policy 想成 GCP 帝國裡的市政建築法規。IAM 是決定「誰拿到鑰匙」的鎖匠，但建築法規決定「什麼東西可以合法蓋出來」。即使工程師（建築師）對某個 project 擁有完整的 roles/owner 權限，只要 constraints/gcp.resourceLocations 設為 in:eu-locations，在 us-central1 蓋一個 GCS bucket 就是違法的。Policy engine 就像市政稽查員，在 API call 階段就駁回藍圖，水泥（資源）根本沒機會倒下去。
類比二：機場海關與禁飛名單
boolean constraint 像是 constraints/compute.vmExternalIpAccess: enforced=true，運作方式就是機場海關：每個對外的封包（external IP 請求）都在邊境被擋下。list constraint 像 constraints/serviceuser.services 則是禁飛名單——只有清單上的航空公司（API）能在境內（organization）營運航班（被啟用）。在 HIPAA 限制的 folder 裡嘗試啟用 gemini.googleapis.com，待遇就跟拿過期簽證想登機的乘客一樣：在登機門被拒，違規行為被記錄下來。
類比三：餐廳衛生稽查的演習
dryRunSpec 就是正式稽查前的模擬衛生檢查。想像一間餐廳準備執行新的「禁售貝類」規則（constraints/gcp.restrictCmekCryptoKeyProjects）。在真的拒絕出餐前，店長先跑一週的「影子稽查」——每盤貝類菜色都被標記為「本來會被駁回」，但客人還是吃得到。看完 log 後，店長就知道哪些菜單品項（legacy GCE VM、BigQuery dataset）必須在切換到 enforce=true 之前先 migrate。不會有預料外的停擺，也不會有客訴。
使用資源位置強制執行數據駐留
數據駐留（Data Residency）是許多合規框架的核心要求（例如 GDPR 要求某些數據必須保留在歐盟境內）。
constraints/gcp.resourceLocations 限制條件是實現此目的最強大的工具。
- 功能： 限制 Google Cloud 資源（如 GCS 存儲桶、BigQuery 數據集、GKE 集群等）的物理位置。
- 範圍： 可應用於組織、資料夾或專案層級。
- 值： 可以是單個區域（如
us-east1）、多區域（eu）或值組（is:global）。
resourceLocations 限制條件僅影響 新創建 的資源。它不會追溯移動現有數據。請使用雲端資產庫（Cloud Asset Inventory）來識別違反新位置策略的遺留資源。
boolean 與 list constraint 行為不同。iam.disableServiceAccountKeyCreation 是 boolean constraint——你只能選 enforce: true|false，沒有 values list。gcp.resourceLocations 則是 list constraint——你必須填 allowedValues 或 deniedValues（例如 in:us-locations），否則整個 policy 等於空轉。考試題目最愛混淆這兩種（例如在 boolean constraint 上設 allowedValues），是經典的干擾選項。
為合規性限制允許的服務
許多合規標準要求您禁用不在「範圍內」或尚未針對特定安全級別進行審核的服務。
- 限制條件：
constraints/serviceuser.services - 用法： 您可以創建一個禁用服務的「拒絕清單」（例如在高度安全的環境中禁用消費級 AI 服務），或一個僅限制專案使用一組核心核准服務的「允許清單」（例如 GCE、GCS 和 BigQuery）。
服務限制條件 (Service Restricting Constraints) 允許管理員定義在資源階層的特定節點內具體可以啟用哪些 Google Cloud API。
強制執行加密要求 (CMEK)
為了滿足嚴格的數據主權或合規標準（如 FIPS 140-2 Level 3），您可能被要求對所有靜態數據使用 客戶管理的加密金鑰 (CMEK)。
關鍵限制條件包括：
- 要求 CMEK： (
constraints/gcp.restrictCmekCryptoKeyProjects) 限制哪些專案可以提供金鑰，從而有效強制使用經過核准的 KMS 金鑰。 - 特定服務的 CMEK： 許多服務都有特定的限制條件（例如
constraints/cloudfunctions.allowedCmekCryptoKeys），以確保函式代碼和機密使用特定金鑰加密。
限制外部訪問
合規框架通常要求內部系統絕不能暴露於公共互聯網。
- 禁用外部 IP：
constraints/compute.vmExternalIpAccess防止 VM 被分配公共 IP。 - 限制外部負載平衡器：
constraints/compute.restrictLoadBalancerCreationForTypes可用於僅允許 內部 HTTP(S) 負載平衡器，從而有效防止創建面向公眾的端點。 - 基於 IP 的限制： 結合使用 Access Context Manager 和組織策略，確保只有特定的來源 IP 範圍可以與某些 API 交互。
針對行業標準的託管組織策略限制條件
Google Cloud 提供與行業標準（如 CIS Google Cloud Computing Foundations Benchmark）保持一致的 策略包 (Policy Bundles) 或「託管限制條件」。
與其手動查找每個單獨的限制條件，您可以應用一組已知可滿足特定合規性檢查的限制條件。這通常整合在 Security Command Center (SCC) 合規性儀表板 中。
針對特定合規需求的自定義組織策略
當預定義的限制條件過於寬泛時，PSE 可以使用 CEL (Common Expression Language) 編寫 自定義組織策略。
示例：為合規性強制執行標籤
您可能要求每個 BigQuery 數據集都必須具有 compliance_level 標籤。
# 自定義限制條件示例
name: organizations/123/customConstraints/custom.requireComplianceTag
resourceTypes: [bigquery.googleapis.com/Dataset]
methodTypes: [CREATE, UPDATE]
condition: "resource.labels.exists(l, l == 'compliance_level')"
actionType: ALLOW
多租戶環境中的策略繼承
在多租戶環境中（例如不同部門共享一個 GCP 組織）：
- 組織層級： 應用「基準」策略（例如禁用序列埠訪問）。
- 資料夾層級： 應用「部門特定」策略（例如財務資料夾要求 CMEK）。
- 專案層級： 應用「例外情況」（例如某個特定專案需要外部 IP 來建立公共網站）。
使用 標籤 (Tags) 來動態管理繼承。您可以設置一個僅適用於標記為 environment: production 的專案的組織策略。
報告和審核組織策略違規行為
- SCC 合規性儀表板： 提供哪些專案根據當前組織策略處於「合規」或「不合規」狀態的高級視圖。
- Cloud Logging： 搜尋
protoPayload.status.code=7（權限遭拒）或特定的constraint_violation項目，查看誰試圖繞過策略。 - 試執行模式 (Dry-run Mode)： 對於 PSE 而言至關重要。先在試執行模式下應用新的合規策略，以在強制執行前查看哪些生產系統會受到影響。
常見的 production 災難：在 organization 層級直接啟用 constraints/iam.disableServiceAccountKeyCreation，但沒先跑 dry-run。所有仍然依賴 JSON service account key（gcloud iam service-accounts keys create）的 CI/CD pipeline，會在金鑰輪替當天瞬間全部炸掉。正確做法是先用 dryRunSpec 跟 live spec 並行 deploy，到 Cloud Logging 監控 orgpolicyViolationsPreview 日誌 1–2 週，把違規 workload 遷移到 Workload Identity Federation，再切換 enforce。陷阱在於誤以為「deny」就是 safe default——對於影響運行中工作負載的 guardrail，dry-run 才是真正的 safe default。
PSE 考試 Org Policy 速記口訣：「Boolean = on/off、List = allow/deny values、Custom = CEL on resource methods、DryRun = preview 不 enforce」。記住這四個招牌 constraint：gcp.resourceLocations（資料駐留，list）、iam.disableServiceAccountKeyCreation（殺 SA key，boolean）、storage.publicAccessPrevention（殺公開 bucket，boolean）、以及透過 resourceTypes + methodTypes + CEL condition 寫的 custom constraint（例如強制必填 label）。題目只要提到「在全組織強制執行前先測試」，答案永遠是 dryRunSpec。
Shielded VM 和受信任啟動強制執行
為了符合高完整性標準（如 FedRAMP High），您必須確保啟動層級的安全。
- 限制條件：
constraints/compute.requireShieldedVm - 限制條件：
constraints/compute.requireMeasuredBoot - 影響： 防止創建任何不支持安全啟動 (Secure Boot)、vTPM 和完整性監控的 VM。
PSE 考試場景
場景 1：符合 GDPR 的全球擴展
「一家公司正在從美國擴展到德國。他們需要確保為德國客戶存儲的任何新數據都保留在 europe-west3 區域。您如何實現這一點？」
答案： 為德國業務部門創建一個新的 資料夾 (Folder)。將 constraints/gcp.resourceLocations 策略應用於該資料夾，並限制為 europe-west3。
場景 2：防止意外的公共暴露
「您的組織有嚴格的『禁止公共數據』政策。您如何確保開發人員不會意外創建公共 Cloud Storage 存儲桶？」
Answer: 在組織層級強制執行 constraints/storage.publicAccessPrevention 限制條件。這可以防止將 "allUsers" 或 "allAuthenticatedUsers" IAM 成員添加到任何存儲桶。
總結清單
- 使用
resourceLocations強制執行數據駐留。 - 區分服務的允許清單和拒絕清單。
- 透過組織策略實施 CMEK 強制執行。
- 使用試執行模式測試合規護欄。
- 透過 SCC 和 Cloud Logging 監控違規行為。