GCP Organization Policy 完全攻略：Google Cloud 安全工程師必備知識

GCP Organization Policy（組織政策）是 Google Cloud 提供的集中式資安政策管理工具，讓管理員統一設定「全公司的資源可以怎麼使用」，透過 Constraints（約束條件）在 Organization、Folder、Project 三層結構中強制執行安全限制。與 IAM 管理「誰能做什麼」不同，Organization Policy 管理「任何人都不能做什麼」——違規操作一律擋下，不受 IAM 角色影響。

如果說 IAM 是管理「誰可以做什麼」的工具，那 GCP Organization Policy 就是管理「全公司的資源可以怎麼使用」的守門員。兩者看起來很像，但扮演的角色完全不同。

1. 什麼是 GCP Organization Policy？

什麼是 Organization Policy？

GCP Organization Policy Service 是 Google Cloud 的集中式治理工具，透過定義 Constraints（約束條件），在整個雲端環境中統一規定哪些行為被允許、哪些行為被禁止。它是一種「護欄機制（Guardrail）」——不論操作者是誰、擁有什麼 IAM 角色，只要行為違反政策，一律擋下。

Organization Policy 的設定方式，是透過定義一系列的 Constraints（約束條件） 來實現。每個 constraint 對應一個特定的 Google Cloud 行為，例如：

可不可以建立有公開 IP 的 VM？
可不可以使用未受信任的 OS 映像檔？
Storage bucket 能不能公開存取？

這些 constraint 可以套用在組織（Organization）、資料夾（Folder）或專案（Project） 層級，並依照層級結構自動向下繼承。

為什麼 Organization Policy 比 IAM 更重要？

IAM 和 Organization Policy 是 Google Cloud 安全架構的兩個不同層次，不能互相取代：

比較項目	IAM	Organization Policy
管理對象	身分（人、服務帳戶）	對資源的操作與設定
設定粒度	個別資源或專案	組織、資料夾、專案
執行機制	授權或拒絕操作	允許或禁止特定行為
繼承方式	自動向下繼承	自動向下繼承
典型用途	誰能讀取 GCS bucket	所有 bucket 不能公開

Organization Policy 的優先層級高於 IAM 授權。就算某個使用者有 Compute Instance Admin 的 IAM 角色，如果組織政策規定「所有 VM 不得有外部 IP」，他一樣無法建立有外部 IP 的 VM。

用比喻來說：

IAM 是「員工識別證」——決定某個人能不能進入這棟大樓、使用這台機器。
Organization Policy 是「公司規章」——不管是誰，所有人都必須遵守，違規一律擋下。

2. Organization Policy 的資源層級繼承架構

它是怎麼運作的？

Google Cloud 的資源以樹狀結構組織：

Organization（組織）
    └── Folder（資料夾）
            └── Project（專案）
                    └── Resources（資源）

當在 Organization 層級設定一個 Organization Policy 時，這個政策會自動往下繼承到所有 Folder、Project 和資源。組織管理員可以用最少的設定，達到全面覆蓋的效果。

實際情境： 假設你在 Organization 層級設定政策，禁止任何 VM 使用外部 IP 位址，那麼整個組織底下的所有 Folder、所有 Project，都不能建立有外部 IP 的 VM——除非有特別的 Override 設定。

inheritFromParent 是什麼？為什麼重要？

inheritFromParent 是理解 Organization Policy 繼承機制的核心欄位。

預設（inheritFromParent: true）：子層節點（Folder 或 Project）從父層繼承政策。
設定 inheritFromParent: false：該節點完全切斷與父層的政策繼承，改用自己設定的政策。

一旦子節點設定 inheritFromParent: false，它的政策就完全獨立運作。即使 Organization 層級允許某個網域，這個允許對該 Folder 完全無效——Folder 只認自己設定的規則。這是安全架構設計中最容易踩到的陷阱之一。

具體案例：

Organization 層級：允許 abc.com 的成員
Apps Folder 層級：只允許 def.com 的成員，並設定 inheritFromParent: false

結果：嘗試把 peter@abc.com 加入 Apps Folder 底下某個 Project 的 IAM 政策，會直接失敗。因為 Apps Folder 已完全切斷繼承，只認 def.com。

3. 兩大核心 Constraint 類型：List vs Boolean

List Constraint（清單限制）

List Constraint 用「允許清單（Allow List）」或「拒絕清單（Deny List）」控制特定資源的使用範圍：

Allow（允許）操作：只有清單內的值才被允許，其他的全部拒絕
Deny（拒絕）操作：清單內的值被禁止，其他的則允許

例如：compute.trustedImageProjects 是一個 List Constraint，用 Allow 操作把特定 Project 列入白名單，代表整個組織只能從這個 Project 的映像檔建立 boot disk。

Boolean Constraint（布林限制）

Boolean Constraint 只有兩個選項：開（Enforced） 或 關（Not Enforced）。

例如：constraints/iam.disableServiceAccountCreation，設定為 Enforced 後，整個組織就無法建立新的服務帳戶。沒有白名單、沒有例外，就是一個開關。

4. 限制可信任映像檔來源：compute.trustedImageProjects

為什麼要控制 Boot Disk 映像檔來源？

在企業環境中，VM 使用的 OS 映像品質直接影響整體安全性。隨意使用公開市場上未經審核的映像檔，可能引入：

映像檔內含已知漏洞（CVE）
映像檔被植入惡意程式
不符合企業安全強化（Hardening）標準

企業安全團隊通常會維護一個「黃金映像（Golden Image）」專案，所有 VM 只能從這個專案中的映像建立。

如何設定？

要讓所有 VM 只使用安全強化的 OS 映像，需要同時完成兩個步驟：

設定 Organization Policy：在 Organization 層級啟用 compute.trustedImageProjects，以 Allow 操作列入受信任的 Project（例如 security-images-project）當你使用 Allow 動作，它就是白名單的方式，同時，會阻擋所有不在白名單的映像檔。

設定 IAM 權限：在 security-images-project 中，授予組織內使用者 compute.imageUser 角色，讓他們有讀取並使用映像的權限

Policy 確保大家只能用這個 Project 的映像；IAM 確保大家有權限存取這個 Project。兩個步驟缺一不可。

為什麼用 Allow 而不是 Deny？ 因為 Allow 的語義是「只有這些才被允許」，天然具有「排除其他所有選項」的效果。如果用 Deny，你只是拒絕了你列出的幾個專案，但其他未列出的公開映像仍然可以使用——這不是我們要的結果。

5. 限制專案建立權限：集中管理 Project Creator 角色

為什麼要集中控制專案建立？

當你建立好一個 GCP 的組織機構，你會看到任何在這個網域的人員都有這兩個權限，專案建立者和帳單帳戶建立者。

在大型企業中，如果所有人都能自由建立 GCP 專案，很快就會出現「專案蔓延（Project Sprawl）」——到處都是沒人管的孤兒專案，浪費資源又製造安全風險。

怎麼做？

只讓特定團隊建立專案，需要同時執行兩個步驟：

移除一般使用者的 Project Creator 角色：在 Organization 層級，把所有使用者從 Project Creator 角色中移除，一般使用者就無法自行建立新專案

授權指定團隊：把負責專案管理的 DevOps 團隊群組，加入 Organization 層級的 Project Creator 角色

注意：兩個步驟必須同時執行。只移除一般使用者但沒有指定誰來建立，專案建立會完全癱瘓；只授權 DevOps 但沒移除一般使用者，限制就沒有意義。

在 Organization Level 移除一般使用者的 Project Creator 角色

6. 控制 VM 的公開 IP 位址：保護生產環境安全

為什麼生產環境不應有公開 IP？

給 VM 一個公開 IP 位址，等於把它直接曝露在網際網路上。對於資料庫伺服器、內部 API 服務、或任何不需要對外的 VM 來說，這是巨大的安全風險——攻擊者可以直接掃描公開 IP，嘗試暴力破解 SSH 或進行 DDoS 攻擊。

如下圖你可以看到，當我建立好一臺虛擬機器時，隨時都有駭客在掃描我的外部 IP 並且嘗試登入。

如何同時保留前端 IP，鎖定其他 VM？

現實情況往往是：前端 Web 伺服器需要公開 IP，但後端應用程式和資料庫不應該有。

使用 constraints/compute.vmExternalIpAccess 這個 constraint，在政策中明確列出哪些 VM 實例可以使用外部 IP（以資源名稱方式列入 Allow 清單），其餘的 VM 自動被禁止。這比 VPC 分割更精準（VPC 分割以子網路為單位，無法做到 VM 層級的細粒度控制），也比移除 IAM 角色更直接，並且不依賴工程師手動記得不勾選外部 IP。

7. 服務帳戶安全管控：三大 IAM 約束條件

服務帳戶（Service Account）是 GCP 中機器身分的代表，也是許多安全事件的攻擊目標。Organization Policy 提供三個相關 constraint 加強管控：

三個 Constraint 快速比較

Constraint	作用	類型	適用場景
`iam.disableServiceAccountCreation`	禁止建立新服務帳戶	Boolean	生產環境集中管控
`iam.disableServiceAccountKeyCreation`	禁止建立服務帳戶金鑰	Boolean	CI/CD 安全加固
`iam.disableServiceAccountKeyUpload`	禁止上傳服務帳戶金鑰	Boolean	防止外部金鑰匯入

disableServiceAccountKeyCreation 和 disableServiceAccountCreation 是兩個功能完全不同的 constraint，不能混用。前者只限制「金鑰的建立」，服務帳戶本身還是存在的；後者才是直接禁止「服務帳戶的建立」。混淆這兩者，是企業安全配置中最常見的錯誤之一。

而 disableServiceAccountKeyUpload，是因爲用戶可以任意建立金鑰並且上傳到 GCP 上，聽起來很方便，但這個金鑰是怎麼產生的？密碼強度夠不夠？甚至不知道這個金鑰是不是每個人都有，或者甚至是駭客上傳的。因此，在資安上會造成潛在的威脅。

CI/CD 場景的最佳實務

在 CI/CD 場景中，建議：

為 CI/CD cluster 建立一個專屬的自訂服務帳戶
在 Project 層級啟用 constraints/iam.disableServiceAccountKeyCreation
讓 CI/CD 工具改用 Workload Identity Federation (如 Github) 或 Instance Metadata Service 取得短期憑證

這樣即使有人嘗試為服務帳戶建立金鑰，也會被 Policy 阻擋，從源頭消除靜態憑證洩漏的風險。

8. 保護 Shared VPC 主機專案不被誤刪

什麼是 Shared VPC？為什麼需要保護？

Shared VPC（又稱 XPN，Cross-Project Networking）讓多個專案共享同一個 VPC 網路。其中的 Host Project（主機專案） 負責提供 VPC 資源給其他 Service Projects 使用。如果 Host Project 被誤刪，所有依賴這個 VPC 的服務都會瞬間斷線。

Google Cloud 會自動為 Shared VPC Host Project 加上 **Lien（留置權）**防止被誤刪，但若使用者有足夠權限，可以手動移除這個 Lien 再刪除專案。啟用 compute.restrictXpnProjectLienRemoval 這個 constraint 後，就算使用者有 Project 刪除權限，也無法移除 Shared VPC Host Project 的 Lien，從根本保護關鍵網路資源不被誤刪。

9. 網域限制共用政策：iam.allowedPolicyMemberDomains

為什麼要限制外部網域存取資源？

在預設情況下，Google Cloud 的 IAM 允許把任何 Google 帳戶加入專案的 IAM 政策。如果工程師不小心把外部 Gmail 帳戶加入專案，外部人員就能存取企業的雲端資源。

constraints/iam.allowedPolicyMemberDomains 讓你指定哪些網域（以 Google Workspace 客戶 ID 或 Cloud Identity 客戶 ID 方式指定）才能被加入 IAM 政策，不在清單內的網域一律無法被授予任何權限。

如何為外部合作夥伴開設例外政策？

在維持 iam.allowedPolicyMemberDomains 政策的前提下，為外部合作夥伴開設例外的正確流程：

暫時關閉 iam.allowedPolicyMemberDomains 政策

將政策值設定為「Custom（自訂）」

把外部合作夥伴的 Cloud Identity 或 Google Workspace 客戶 ID 加入 constraint 的例外清單

確認設定正確後，重新啟用政策

注意：把合作夥伴帳號加入 Google Group 不能繞過這個限制。這個 constraint 是以客戶 ID為單位做網域驗證的。

10. Cloud Storage 安全防護：防止資料對外公開洩漏

什麼是 storage.publicAccessPrevention？

constraints/storage.publicAccessPrevention 是專門防止 Cloud Storage 資料外洩的 constraint。啟用後，組織內所有 Cloud Storage bucket（包含未來新建立的）都無法被設定為允許匿名的公開存取。

建立完整的 Cloud Storage 存取控制，建議搭配兩個設定的「黃金組合」：啟用 storage.publicAccessPrevention（防止 bucket 被匿名公開存取）+ 啟用 Uniform Bucket-Level Access（關閉 ACL，統一改用 IAM 管理 bucket 存取）。前者防止資料因設定疏漏而意外公開，後者防止因外部帳號被加入 IAM 而導致外洩。兩者相輔相成，缺一不可。

11. 強制使用 CMEK 加密：gcp.restrictNonCmekServices

什麼是 CMEK？

CMEK（Customer-Managed Encryption Keys，客戶自管加密金鑰） 是 Google Cloud 提供的加密機制。預設情況下，Google Cloud 使用自己管理的金鑰（GMEK）加密資料。CMEK 讓企業可以使用自己在 Cloud KMS 中管理的金鑰進行加密。

企業強制使用 CMEK 的主要原因：

法規合規：金融業、醫療業、GDPR 場景可能要求對加密金鑰有完整控制權
資料主權：企業可以隨時撤銷金鑰，確保資料的最終控制權在自己手中
審計要求：所有金鑰的使用記錄都可以在 Cloud KMS 中審計

如何強制使用 CMEK？Deny 才是正確做法

constraints/gcp.restrictNonCmekServices 的語義是「限制哪些服務可以不使用 CMEK」。要強制所有 Cloud Storage 資源必須使用 CMEK，正確設定是使用 Deny 操作，將 storage.googleapis.com 列入拒絕清單。如果誤用 Allow 操作，代表的是「允許 Cloud Storage 不用 CMEK」，效果完全相反。這是實務配置中最容易搞反的邏輯之一。

正確設定範例：

constraint: gcp.restrictNonCmekServices
binding at: org1
policy type: deny
policy value: storage.googleapis.com

12. 資源地理位置限制：GDPR 合規的利器

什麼時候需要 Resource Location Restriction？

當企業需要遵守 GDPR 或其他有資料落地要求的法規時，確保所有 Google Cloud 資源只建立在特定地理區域是非常重要的合規要求。

限制 Google Cloud 資源只能建立在特定地理區域，唯一正確的工具是 constraints/gcp.resourceLocations（Resource Location Restriction）。常見的錯誤做法包括：使用 IAM 自訂角色（IAM 沒有以地理位置為條件的授權機制）、使用 Identity-Aware Proxy（IAP 是管理使用者對應用程式的存取，和資源建立地點無關）、使用 Restrict Resource Service Usage（這個 constraint 是限制服務使用，不是限制地理位置）。

constraints/gcp.resourceLocations 支援以 Region、Multi-region 或具體的 Zone 為單位設定限制，能夠非常精確地控制資源的建立位置。

Resource Location Restriction 可以限制資源所在地以符合當地法規

13. 組織政策被繞過了怎麼辦？常見原因排查

為什麼政策對某個 Project 失效了？

假設你在 Folder 層級設定了政策，禁止所有 VM 使用外部 IP，但兩天後發現某個 Project 底下的 VM 竟然有外部 IP。

最常見原因： 該 Project 在 Project 層級對這個 constraint 設定了 Override，把政策值改成了「Allow」，因此 Folder 層級的禁止設定對這個 Project 失效了。

排查步驟

到 Google Cloud Console → Organization Policy，找到該 constraint
查看政策的繼承情況，確認各個層級的設定值
找出哪個層級有 Override，然後移除或修正

在 Google Cloud 的 Organization Policy 機制中，子層的 Policy 可以覆蓋父層的 Policy（除非父層政策設定了不允許 Override）。「沉默代表繼承」——如果你希望某個 Folder 或 Project 有不同的行為，必須明確在那個層級設定 Override；如果沒有設定，就代表接受上層的政策設定，沒有任何例外。

14. 預設網路與 CI/CD 管道的安全配置

compute.skipDefaultNetworkCreation 是什麼？

當一個新的 Google Cloud Project 被建立時，系統預設會自動建立一個 Default VPC 網路。這個預設網路有幾個問題：

防火牆規則預設允許許多常見的輸入連線（如 SSH、RDP），不符合最小權限原則
大型組織中，每個 Project 都有預設網路，網路架構會變得混亂難以管理
工程師可能直接在預設網路上部署資源，沒有任何額外的安全配置

解決方法： 在 Organization 層級啟用 constraints/compute.skipDefaultNetworkCreation。啟用後，所有新建立的 Project 都不會自動產生預設 VPC 網路，工程師必須根據企業的網路架構規範手動建立符合要求的 VPC。

15. 備戰重點整理與常見觀念陷阱

GCP Organization Policy 六大常見陷阱：

Allow vs Deny 搞反：compute.trustedImageProjects 用 Allow（只允許白名單）；gcp.restrictNonCmekServices 用 Deny（禁止不用 CMEK）

Boolean Constraint 混用：disableServiceAccountCreation（禁建帳戶）≠ disableServiceAccountKeyCreation（禁建金鑰）

繼承機制誤解：inheritFromParent: false 會讓子節點完全獨立，父層允許的規則在此完全無效

地理位置限制用錯工具：要限制資源建立地區，只能用 gcp.resourceLocations，IAM 和 IAP 都做不到

Shared VPC 保護工具記錯：用 compute.restrictXpnProjectLienRemoval，不是 restrictSharedVpcHostProjects

Cloud Storage 防護不完整：storage.publicAccessPrevention 要搭配 Uniform Bucket-Level Access 才形成完整防線

結論

GCP Organization Policy 是 Google Cloud 安全架構中不可或缺的一環，它在 IAM 之上提供更高維度的護欄——無論誰來操作、用什麼角色，只要行為違反組織政策，就一律擋下。從映像檔的來源控制、VM 的 IP 管理、服務帳戶的建立限制，到 Cloud Storage 的公開防護和 CMEK 加密強制，每一個 constraint 背後都對應著真實的企業安全需求。建議在設計組織的雲端安全架構時，把 Organization Policy 的規劃納入最早期的階段，先把護欄架好，讓工程師在安全的邊界內自由發揮。

常見問題解答（FAQ）

Q1：Organization Policy 和 IAM 條件（IAM Conditions）有什麼差別？ IAM Conditions 是在 IAM 授權基礎上加入額外條件（如時間、資源標籤）來細化授權；Organization Policy 則是從行為層面設定哪些操作根本不被允許，不管你有什麼 IAM 角色。

Q2：我可以在 Project 層級覆蓋 Organization 層級的政策嗎？ 預設情況下可以，子層可以 Override 父層的政策。但如果父層在設定 constraint 時鎖定了不允許 Override，子層就無法覆蓋。這是組織管理員需要仔細規劃的地方。

Q3：Organization Policy 的設定會即時生效嗎？ 是的，Organization Policy 通常在幾分鐘內就會生效。但需要注意：對於已經存在的資源（例如已有公開 IP 的 VM），Policy 不會自動修正，只會阻擋未來的違規操作。

Q4：什麼是 Constraint 的 Dry Run 模式？ Dry Run（模擬執行）模式讓你先評估一個 constraint 的影響範圍，而不實際執行限制。違規操作會被記錄在 Cloud Logging 中但不會被阻止，方便管理員在正式啟用前了解有哪些資源會受到影響。

Q5：如何查看目前組織內所有的 Organization Policy 設定？ 可以在 Google Cloud Console 的「IAM & Admin → Organization Policies」中查看，也可以使用以下指令：

bash

gcloud org-policies list --organization=ORGANIZATION_ID

Q6：compute.trustedImageProjects 可以套用在 Folder 層級嗎？ 可以。Organization Policy 可以套用在 Organization、Folder 或 Project 任何層級。套用在 Folder 層級時，該 Folder 底下的所有 Project 都會受到映像來源限制的約束。

Q7：storage.publicAccessPrevention 和 Uniform Bucket-Level Access 有什麼關係？ 兩者是獨立的設定，但相輔相成。publicAccessPrevention 防止 bucket 被匿名公開存取；Uniform Bucket-Level Access 則是關閉 ACL，統一用 IAM 管理存取權限。同時啟用兩者，可以建立更完整的 Cloud Storage 安全管控。

Q8：如果同一個 constraint 在 Folder 和 Project 層級都有設定，以哪個為準？ 以最接近資源的層級為準，也就是 Project 層級的設定會覆蓋 Folder 層級的設定（前提是 inheritFromParent 沒有特別限制）。理解這個優先順序，對排查政策衝突非常重要。

Q9：Resource Location Restriction 可以限制到具體的 Zone（區域）嗎？ 可以。constraints/gcp.resourceLocations 支援以 Region、Multi-region 或具體的 Zone 為單位設定限制，能夠非常精確地控制資源的建立位置。

Q10：Organization Policy 的設定有沒有辦法自動化管理？ 有。可以透過 Terraform 的 google_org_policy_policy 資源，或使用 Google Cloud 的 Organization Policy API，以程式碼方式管理所有 constraint 設定。這也是大型企業推薦的「Policy as Code」實踐方式，確保政策設定可被版本控管和自動化部署。

GCP Organization Policy, GCP Security, 機構政策, 組織政策

東東 GCP 教學 - GCP 實戰講師