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 安全架構的兩個不同層次，不能互相取代：

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 映像，需要同時完成兩個步驟：

1. 設定 Organization Policy：在 Organization 層級啟用 compute.trustedImageProjects，以 Allow 操作列入受信任的 Project（例如 security-images-project）當你使用 Allow 動作，它就是白名單的方式，同時，會阻擋所有不在白名單的映像檔。
2. 設定 IAM 權限：在 security-images-project 中，授予組織內使用者 compute.imageUser 角色，讓他們有讀取並使用映像的權限

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

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

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

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

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

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

怎麼做？

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

1. 移除一般使用者的 Project Creator 角色：在 Organization 層級，把所有使用者從 Project Creator 角色中移除，一般使用者就無法自行建立新專案
2. 授權指定團隊：把負責專案管理的 DevOps 團隊群組，加入 Organization 層級的 Project Creator 角色

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

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 快速比較

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

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

CI/CD 場景的最佳實務

在 CI/CD 場景中，建議：

1. 為 CI/CD cluster 建立一個專屬的自訂服務帳戶
2. 在 Project 層級啟用 constraints/iam.disableServiceAccountKeyCreation
3. 讓 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 政策的前提下，為外部合作夥伴開設例外的正確流程：

1. 暫時關閉 iam.allowedPolicyMemberDomains 政策
2. 將政策值設定為「Custom（自訂）」
3. 把外部合作夥伴的 Cloud Identity 或 Google Workspace 客戶 ID 加入 constraint 的例外清單
4. 確認設定正確後，重新啟用政策

注意：把合作夥伴帳號加入 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 為單位設定限制，能夠非常精確地控制資源的建立位置。

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

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

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

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

排查步驟

1. 到 Google Cloud Console → Organization Policy，找到該 constraint
2. 查看政策的繼承情況，確認各個層級的設定值
3. 找出哪個層級有 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 六大常見陷阱：

1. Allow vs Deny 搞反：compute.trustedImageProjects 用 Allow（只允許白名單）；gcp.restrictNonCmekServices 用 Deny（禁止不用 CMEK）
2. Boolean Constraint 混用：disableServiceAccountCreation（禁建帳戶）≠ disableServiceAccountKeyCreation（禁建金鑰）
3. 繼承機制誤解：inheritFromParent: false 會讓子節點完全獨立，父層允許的規則在此完全無效
4. 地理位置限制用錯工具：要限制資源建立地區，只能用 gcp.resourceLocations，IAM 和 IAP 都做不到
5. Shared VPC 保護工具記錯：用 compute.restrictXpnProjectLienRemoval，不是 restrictSharedVpcHostProjects
6. 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」實踐方式，確保政策設定可被版本控管和自動化部署。

The post GCP Organization Policy 完全攻略：Google Cloud 安全工程師必備知識 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

不需要自己架防火牆主機，也不需要密碼學背景，最快 15 分鐘就能完成基礎設定。

這篇文章會帶你從頭搞懂 Cloud Armor 是什麼、用它之前要準備什麼、怎麼操作，以及 5 種常見的防禦規則範例，看完就能直接動手。

什麼是 GCP Cloud Armor？

GCP Cloud Armor 是 Google Cloud 提供的應用程式層防護服務，部署在 Google 的全球邊緣節點上，用來攔截進入你後端服務 (虛擬機、Cloud Run 或 Kubernetes) 之前的惡意 HTTP 流量。

它的角色是守門員：在流量進入你的後端服務之前，先根據你設定的規則篩選一遍。

符合規則的流量放行，不符合的直接拒絕，回傳 403 或自訂的錯誤回應。

因為 GCP Cloud Armor 運行在 Google 的邊緣基礎設施上，惡意流量甚至不會打到你的 VM 或 Cloud Run 服務，就已經在網路邊緣被攔截。

這是它和傳統在主機上裝軟體防火牆最大的差異。

Cloud Armor 的核心功能：WAF 與 DDoS 防護

Cloud Armor 主要提供兩層防護。

WAF（Web Application Firewall，網頁應用程式防火牆）：針對應用程式層的攻擊，例如 SQL Injection、XSS、CSRF（Cross-Site Request Forgery，跨站請求偽造）、路徑遍歷（Path Traversal，進入不開放的路徑）等。

你可以用 Google 預建的規則集（Rules Set），也可以自己寫條件規則。

DDoS 防護：針對大流量的攻擊，Google 的基礎設施本身就有 L3/L4 層的 DDoS 緩解能力，Cloud Armor 在此基礎上再加上 L7 層的防護，例如針對 HTTP Flood 的速率限制（Rate Limiting）。

兩種防護都不需要你另外架設任何伺服器，全部透過設定「安全政策」和「規則」來完成。

Cloud Armor Standard 和 Managed Protection Plus 的差異

Cloud Armor 分成兩個版本，初學者只需要了解基礎版就夠用。

Standard（標準版）：

• 免費啟用，依照請求數與規則數計費
• 支援自訂規則、IP 封鎖、地理位置封鎖
• 支援 WAF 預建規則集（但要另外付費啟用每條規則）
• 適合絕大多數的 GCP 初學者和中小型專案

Managed Protection Plus（進階版）：

• 月費制，約 3,000 美元/月起，一次要訂閱一年。
• 包含自適應防護（Adaptive Protection）的完整功能
• 提供 DDoS 攻擊時的應急支援（Google 工程師介入，需搭配 Premium Support）
• 提供詳細的攻擊分析報告
• 適合有大規模 DDoS 風險的企業級應用

這篇文章的操作說明只涵蓋 Standard 版本。

Cloud Armor 和傳統防火牆的不同之處

很多人第一次接觸 GCP Cloud Armor 時會問：「GCP 不是已經有 VPC Firewall 了嗎？為什麼還需要 Cloud Armor？」

答案在於防護層次不同。

VPC Firewall 在 L3/L4 層運作，它看的是 IP 位址、Port、Protocol。

它可以說「拒絕所有來自這個 IP 的 TCP 連線」，但它看不懂 HTTP 請求的內容。

GCP Cloud Armor 在 L7 層運作，它可以看到 HTTP Header、URL 路徑、Request Body、User-Agent，甚至可以判斷「這個請求的 query string 裡面有 SQL Injection 的特徵」。

兩個服務不是互相取代，而是互補。實務上你會同時使用兩個。

你為什麼需要 Cloud Armor？

沒有 WAF 的 GCP 服務面臨哪些風險

把服務部署到 GCP 並開放公開存取之後，你面對的不只是真實用戶，還有各種自動化攻擊工具。

常見的威脅類型有 6 種：

1. 自動化掃描工具：每天有數以千計的 Bot 在網路上掃描開放的端點，試探常見漏洞
2. SQL Injection 攻擊：試圖透過 URL 參數或表單欄位注入惡意 SQL 語句，讀取或竄改資料庫
3. XSS 攻擊：在回應中插入惡意腳本，影響其他使用者的瀏覽器行為
4. DDoS 攻擊：大量請求同時打進來，讓你的服務因為過載而無法回應
5. 地區性惡意流量：某些地區的 IP 段本身就有大量惡意行為的歷史紀錄
6. 暴力破解：對登入端點反覆嘗試密碼，每分鐘可發送超過 1,000 次請求

如果沒有 WAF，這些攻擊會直接打到你的後端，讓你的 VM 或容器承受無效請求，耗費運算資源，也增加被攻破的風險。

Cloud Armor 能防禦的攻擊類型

GCP Cloud Armor 可以有效防禦的攻擊，按照常見程度排列：

1. IP 層攻擊：封鎖特定 IP 或 IP 段的所有請求
2. 地理位置攻擊：封鎖來自特定國家的流量
3. SQL Injection（SQLi）：使用 OWASP 規則集偵測並封鎖注入攻擊
4. XSS（Cross-Site Scripting）：偵測 request 中的腳本注入特徵
5. HTTP Flood：透過速率限制，對單一 IP 的請求次數設上限
6. 路徑遍歷（Path Traversal）：試圖存取 ../../../etc/passwd 等路徑
7. 掃描工具偵測：根據 User-Agent 特徵封鎖常見的掃描工具

什麼規模的專案適合導入 Cloud Armor

只要你的 GCP 服務有開放公開的 HTTP/HTTPS 端點，就應該考慮 GCP Cloud Armor。

以下 4 種情況特別建議導入：

1. 有處理用戶輸入的表單或 API（SQL Injection、XSS 風險高）
2. 服務對外有 SLA 要求，不能接受因 DDoS 導致的停機
3. 有合規需求（例如 PCI DSS），要求必須有 WAF
4. 服務已經上線，Log 中已經出現大量可疑請求

即使是個人學習專案，Standard 版本的費用相對低，拿來練習設定規則也很合理。

使用 Cloud Armor 之前：你必須知道的前提條件

GCP Cloud Armor 不是獨立服務，它必須掛在 GCP Load Balancer 上才能運作。

這是最多初學者沒注意到的限制。

Cloud Armor 只能搭配哪些 Load Balancer？

Global External HTTP(S) Load Balancer

這是最常用的搭配，也是 Cloud Armor 支援最完整的 Load Balancer 類型。

如果你的後端是 Cloud Run、GKE、Compute Engine VM，並且使用 Global External HTTP(S) LB 對外服務，Cloud Armor 的所有功能（WAF 規則、地理封鎖、速率限制）都可以使用。

套用位置是 Load Balancer 的後端服務（Backend Service），不是 LB 本身。

SSL Proxy 和 TCP Proxy Load Balancer

這兩種 LB 也支援 Cloud Armor，但只能使用 L4 層的防護功能（IP 封鎖），無法使用 WAF 規則或地理封鎖。

原因是 SSL Proxy 和 TCP Proxy 在 L4 層就把流量轉發出去了，Cloud Armor 沒有機會讀取到 HTTP 層的內容。

不支援的 LB 類型：Internal LB 和 Regional LB 的限制

以下 Load Balancer 不支援 GCP Cloud Armor：

• Internal HTTP(S) Load Balancer：只面對內部 VPC 流量，Cloud Armor 的邊緣防護機制在此無法運作
• Regional External HTTP(S) Load Balancer：Cloud Armor 目前只支援 Global 版本
• Network Load Balancer（TCP/UDP NLB）：這是 Pass-through 型 LB，流量直接到後端，無法插入 Cloud Armor

如果你現在用的是 Internal LB 或 Regional LB，要使用 Cloud Armor 就必須先換成 Global External HTTP(S) LB，這可能需要調整你的架構。

需要的 GCP 權限與 IAM 角色

設定 Cloud Armor 需要以下 IAM 角色之一：

• compute.securityAdmin：可以建立、修改、刪除安全政策
• compute.admin：包含上面的所有權限，加上管理 LB 的能力
• roles/owner 或 roles/editor：專案層級的完整權限（不建議在正式環境使用）

如果只需要查看安全政策但不需要修改，可以給：

• compute.securityPolicyUser：只能查看政策，無法修改

Cloud Armor 的計費方式

Cloud Armor Standard 版的計費方式：

實際費用計算範例：

1 個安全政策 + 5 條規則（含 2 條 WAF 規則）+ 每月 1 億次請求：

• 政策：$5
• 規則：$5（5條 × $1）
• WAF 規則：$2（2條 × $1）
• 請求數：$75（100百萬 × $0.75）
• 合計約 $87 美元/月

實際費用視流量規模而定，可以在 Google Cloud Pricing Calculator 試算。

GCP Cloud Armor 功能完整介紹

安全政策（Security Policy）是什麼？

安全政策（Security Policy）是 GCP Cloud Armor 的核心容器，用來集中管理所有防禦規則，並套用到指定的 Load Balancer 後端服務上。

一個安全政策可以包含多條規則，然後套用到一個或多個 Load Balancer 的後端服務（Backend Service）上。

把安全政策想成「一份守門規則書」：裡面寫了哪些人可以進、哪些人要擋在外面、哪些人要特別審查。

Load Balancer 把這份規則書交給門口的保全（Google 的邊緣節點）執行。

一個 GCP 專案可以有最多 200 個安全政策，每個後端服務只能套用 1 個安全政策。

規則（Rule）的組成：優先序、條件與動作

每條規則由 3 個部分組成：

1. 優先序（Priority）：數字越小，優先度越高，範圍是 0 到 2147483646。

建議用 1000、2000、3000 這樣有間距的數字，方便之後在中間插入新規則。

2. 條件（Match Condition）：用 CEL（Common Expression Language）語法描述這條規則要符合什麼條件，例如：

• 來源 IP 是否在某個範圍
• 請求的來源國家代碼是否符合
• Request 的內容是否有 SQL Injection 特徵

3. 動作（Action）：當條件成立時，要對這個請求做什麼：

• allow：放行
• deny(403)：拒絕，回傳 403 Forbidden
• deny(404)：拒絕，回傳 404（讓攻擊者不確定原因）
• throttle：速率限制，超過閾值才封鎖
• rate_based_ban：超過速率就暫時封鎖這個 IP

預設規則（Default Rule）的作用

每個安全政策都有一條無法刪除的「預設規則」，Priority 固定為 2147483647（最低優先度）。

預設規則的作用是：當所有其他規則都不符合時，這條規則決定最終結果。

預設規則的動作可以設定為：

• allow（預設值）：沒被其他規則攔截的流量（黑名單模式），全部放行
• deny(403)：沒被特別允許的流量，全部封鎖（白名單模式）

初學者建議使用 allow 作為預設動作（黑名單模式），只封鎖你明確設定要擋的流量，避免誤擋正常用戶。

進階規則語言：CEL 表達式基礎

GCP Cloud Armor 使用 CEL（Common Expression Language，通用表達式語言）來寫規則條件，這是 Google 開發的開源條件判斷語法，專門用來描述篩選邏輯。

常用的 CEL 函數：

條件可以用 &&（AND）、||（OR）、!（NOT）組合。

地理位置封鎖（Geo-blocking）

地理位置封鎖讓你根據來源國家代碼（ISO 3166-1 alpha-2）決定是否放行。

這個功能不需要你維護任何 IP 清單，Google 在邊緣節點自動判斷來源地理位置。

常見使用情境：

• 你的服務只對台灣用戶開放，可以封鎖所有非台灣的流量
• 某個國家最近有大量惡意請求，可以臨時封鎖該地區

封鎖多個國家的 CEL 語法：

origin.region_code == 'RU' || origin.region_code == 'KP' || origin.region_code == 'IR'

注意：地理位置判斷是依照 IP 對應的地理資料庫，VPN 用戶可能顯示錯誤的國家。

IP 白名單與黑名單

IP 封鎖是 GCP Cloud Armor 最基本的功能，適合封鎖已知惡意 IP 或只開放特定辦公室 IP。

每條規則最多可以指定 10 個 IP 或 CIDR 範圍。

超過 10 個 IP 需要封鎖時，有 2 個選擇：

1. 建立多條規則，每條規則放 10 個 IP
2. 使用 Cloud Armor 的「IP Address Group」功能，集中管理大量 IP 清單

黑名單模式（封鎖特定 IP）：

inIpRange(origin.ip, '198.51.100.0/24')

動作設為 deny(403)，其他規則預設 allow。

白名單模式（只開放特定 IP）：

inIpRange(origin.ip, '203.0.113.10/32')

動作設為 allow，預設規則改為 deny(403)。

WAF 預建規則集（OWASP Top 10 防護）

Cloud Armor 提供 Google 維護的 WAF 預建規則集，對應 OWASP Top 10 常見攻擊。

OWASP Top 10 是全球最廣泛引用的網頁應用程式安全風險清單，由非營利組織 OWASP 每幾年更新一次，列出最常被攻擊者利用的 10 種漏洞類型。

不需要自己寫偵測邏輯，只要在條件中呼叫 evaluatePreconfiguredExpr() 就好：

這些規則集由 Google 持續更新，不需要自己維護特徵碼。

靈敏度等級說明：每個預建規則集都有靈敏度等級（Sensitivity Level），從 1 到 4。

• 等級 4：偵測最嚴格，但誤判率也最高
• 等級 1：只抓最明顯的攻擊特徵，誤判率最低

初學者建議從 Level 1 開始，觀察 Log 後再調整。

速率限制（Rate Limiting）功能

速率限制讓你設定「同一個 IP 在一段時間內最多可以發送幾個請求」，超過就觸發節流或封鎖。

兩種模式：

Throttle（節流）：超過速率的請求會收到 429 Too Many Requests，不會被永久封鎖，速率恢復後就能正常請求。

適合防止意外的高流量，例如爬蟲設定太激進。

Rate-based Ban（速率封鎖）：超過速率之後，該 IP 在指定時間內（例如 300 秒）的所有請求都被封鎖，無論後續速率是否降低。

適合防禦故意的 HTTP Flood 攻擊。

自適應防護（Adaptive Protection）簡介

自適應防護（Adaptive Protection）是 Cloud Armor 的 AI 功能，它會分析你的流量基準，當偵測到異常流量模式時，自動生成防禦規則建議，讓你一鍵套用。

Standard 版本有基本的自適應防護功能，只能提供警告；Managed Protection Plus 版本的功能更完整，還提供即時攻擊警報和 Google 工程師介入支援，支援的前提是有購買 Premium Support 技術支援方案。

對初學者來說，自適應防護是很好的輔助工具，但不要完全依賴它——建議的規則還是需要你自己審核才能套用。

GCP Cloud Armor 基礎版操作步驟

GCP Cloud Armor 的設定流程共 5 個步驟：確認 LB 類型、建立安全政策、新增規則、套用到後端服務、測試生效。

Step 1：確認你的 Load Balancer 類型

在開始之前，先確認你的 Load Balancer 是否支援 GCP Cloud Armor。

1. 前往 Google Cloud Console → Network Services → Load Balancing
2. 點進你的 Load Balancer，查看類型欄位
3. 確認類型是 Global External HTTP(S) Load Balancer 或 Classic HTTP(S) Load Balancer

如果你還沒有 Load Balancer，需要先建立一個 Global External HTTP(S) LB，再把你的後端服務（Cloud Run、GKE、VM 等）掛上去，才能繼續後面的步驟。

Step 2：在 Google Cloud Console 建立安全政策

1. 前往 Network Security → Cloud Armor
2. 點擊「+ Create Policy」
3. 填入以下資訊：
   • Name：自訂政策名稱，例如 my-armor-policy（只能小寫英文和連字號）
   • Description（選填）：說明這個政策的用途
   • Default rule action 預設規則：選擇 Allow（黑名單模式，符合的先擋，都不符合就允許，推薦初學者）
4. 點擊「Create Policy」

這時候安全政策已經建立，但還沒有套用到任何 Load Balancer，也沒有任何自訂規則（只有預設的 allow 規則）。

Step 3：新增第一條防禦規則

在政策頁面中，點擊「Add Rule」，依序填入：

1. Description：填入規則說明，例如「封鎖惡意 IP 段」
2. Mode：選擇「Basic mode」（適合初學者）或「Advanced mode」（可以寫 CEL 表達式）
3. Match：填入條件，例如 IP 範圍 198.51.100.0/24
4. Action：選擇 Deny 並選擇回應碼（403 或 404）
5. Priority：填入優先序數字，例如 1000
6. 點擊「Add」

規則建立後會在 60 秒內生效，不需要重新部署 Load Balancer。

Step 4：將安全政策套用到後端服務

安全政策不是套用在 Load Balancer 本身，而是套用在 Load Balancer 的**後端服務（Backend Service）**上。

從 Cloud Armor 頁面套用：

1. 前往 Network Security → Cloud Armor → 點進你剛建立的政策
2. 點擊「Apply to targets」
3. 點擊「Add target」
4. 選擇你的 Load Balancer 和對應的 Backend Service
5. 點擊「Add」確認

從 Load Balancer 頁面套用（二擇一）：

1. 前往 Load Balancing → 點進你的 LB
2. 點擊「Edit」
3. 在 Backend Configuration 中，點進你的後端服務
4. 在「Cloud Armor policy」欄位選擇你剛建立的政策
5. 儲存

Step 5：測試規則是否生效

用 curl 測試封鎖效果

假設你建立了一條封鎖特定 IP 的規則，可以從該 IP 的機器用 curl 測試：

curl -v https://your-service-domain.com/

如果規則生效，你會看到：

< HTTP/2 403
< content-type: text/html; charset=UTF-8

要測試封鎖特定 User-Agent 或路徑，可以加上對應參數：

# 測試封鎖特定 User-Agent
curl -v -A "sqlmap/1.0" https://your-service-domain.com/

# 測試封鎖特定路徑
curl -v https://your-service-domain.com/admin/config

在 Cloud Logging 確認攔截紀錄

Cloud Armor 的攔截紀錄會自動寫入 Cloud Logging，查詢方式：

1. 前往 Logging → Log Explorer
2. 在查詢框填入：

resource.type="http_load_balancer"
jsonPayload.enforcedSecurityPolicy.outcome="DENY"

3. 點擊「Run Query」

你會看到每筆被攔截的請求，包含來源 IP、請求路徑、觸發的規則名稱，以及 Cloud Armor 做出的動作。

Cloud Armor 防禦規則範例

以下 5 個範例都是實務中最常用的規則設定，建議新增時使用 Advanced mode（進階模式），直接貼入 CEL 表達式。

範例一：封鎖特定 IP 位址或 IP 段

情境：你的 Log 中發現 198.51.100.42 這個 IP 持續發送惡意請求。

規則設定：

• Priority：1000
• 條件（CEL）：

inIpRange(origin.ip, '198.51.100.42/32')

• 動作：deny(403)

同時封鎖多個 IP 段：

inIpRange(origin.ip, '198.51.100.0/24') || inIpRange(origin.ip, '203.0.113.128/25')

單條規則最多支援 10 個 IP 範圍。超過 10 個時，建立多條規則，或使用「IP Address Groups」功能集中管理。

範例二：封鎖特定國家的流量（地理位置封鎖）

情境：你的服務只面向台灣用戶，想封鎖來自特定高風險國家的流量。

規則設定：

• Priority：2000
• 條件（CEL）：

origin.region_code == 'RU' || origin.region_code == 'KP'

• 動作：deny(403)

如果服務只開放特定國家，反向設定更有效率（白名單模式）：

!(origin.region_code == 'TW' || origin.region_code == 'HK' || origin.region_code == 'SG')

動作：deny(403)

這個寫法的意思是「不是台灣、香港、新加坡的流量，全部拒絕」。

國家代碼使用 ISO 3166-1 alpha-2 標準：台灣是 TW，中國是 CN，美國是 US。

範例三：防禦 SQL Injection 攻擊

情境：你的服務有開放查詢 API，擔心被 SQL Injection 攻擊。

規則設定：

• Priority：3000
• 條件（CEL）：

evaluatePreconfiguredExpr('sqli-stable')

• 動作：deny(403)

這條規則使用 Google 的預建 SQLi 規則集，自動偵測 request 中常見的 SQL Injection 特徵，包含：

• URL 參數中的 ' OR 1=1、UNION SELECT 等語句
• 編碼混淆過的注入字串
• Blind SQL Injection 常用的時間延遲語句

如果誤判率太高，可以調整靈敏度到 Level 1：

evaluatePreconfiguredExpr('sqli-stable', {'sensitivity': 1})

範例四：防禦 XSS（跨站腳本攻擊）

情境：你的服務有留言或輸入功能，想防止 XSS 攻擊。

規則設定：

• Priority：3100
• 條件（CEL）：

evaluatePreconfiguredExpr('xss-stable')

• 動作：deny(403)

這條規則偵測的 XSS 特徵包含：

• <script> 標籤的各種變形
• javascript: 協議注入
• onerror=、onload= 等事件處理器注入
• HTML 編碼和 URL 編碼混淆的腳本

想節省計費，可以把 SQLi 和 XSS 合併成 1 條規則：

evaluatePreconfiguredExpr('sqli-stable') || evaluatePreconfiguredExpr('xss-stable')

範例五：針對單一路徑設定速率限制

情境：你的 /api/login 端點常被暴力破解攻擊，想限制每個 IP 每分鐘最多 10 次請求。

規則設定：

• Priority：4000
• 條件（CEL）：

request.path.matches('/api/login')

• 動作：throttle
• 速率設定：
  • 統計週期：60 秒
  • 超過閾值：10 次請求
  • 超過後動作：deny(429)

如果想要更嚴格的封鎖，改用 rate_based_ban 動作，並設定封鎖時間（例如 300 秒）——超過次數後，該 IP 會被封鎖整整 5 分鐘。

這個範例可以應對的情境：

• 自動化密碼爆破工具（每秒幾十次請求）
• API Key 暴力猜測
• OTP 驗證碼爆破

想查詢更完整內容可查看官方文件《設定 Cloud Armor 安全性政策》。

常見問題與錯誤排查

規則設定完但沒有生效，怎麼辦？

按以下順序依序檢查，通常在第 1–3 步就能找到原因：

1. 確認安全政策有套用到後端服務：前往 Cloud Armor → 點進你的政策 → 查看「Targets」分頁，確認你的 Backend Service 在清單中
2. 確認規則的優先序正確：數字小的先執行，確認要生效的規則優先序比「預設 allow 規則」小
3. 確認條件語法沒有錯誤：CEL 語法錯誤會讓規則直接無效，在 Cloud Console 的規則編輯頁面用「Validate」功能檢查
4. 等待傳播時間：Cloud Armor 規則通常在 60 秒內生效，最多可能需要 5 分鐘才能完全傳播到所有邊緣節點
5. 確認測試來源 IP：在自己的電腦測試時，確認你的 IP 確實在規則的封鎖範圍內

安全政策套用後合法流量被擋，如何排查？

合法流量被誤擋是 WAF 最常見的問題，特別是啟用預建規則集後。

排查步驟：

1. 前往 Cloud Logging，查詢被擋的請求：

resource.type="http_load_balancer"
jsonPayload.enforcedSecurityPolicy.outcome="DENY"

2. 查看 jsonPayload.enforcedSecurityPolicy.name 欄位，確認是哪條規則觸發
3. 查看原始請求的 path、headers、body，判斷是否為正常請求
4. 如果是 WAF 預建規則集誤判，可以選擇以下 3 種方式處理：
   • 降低靈敏度等級（Sensitivity Level）
   • 在誤判的規則前面加一條優先序更高的 allow 規則，放行特定 IP 或路徑
   • 改用「Preview Mode」先觀察，不實際封鎖

Preview Mode（預覽模式）：規則動作設定為 preview，Cloud Armor 會記錄所有符合條件的請求到 Log，但不實際封鎖。

上線新規則前，建議先開 Preview Mode 觀察 1–3 天，確認沒有異常再正式封鎖。

在 Cloud Logging 中找到 Cloud Armor 攔截紀錄

Cloud Armor 的完整 Log 欄位說明：

查詢所有 GCP Cloud Armor 相關紀錄（含放行和攔截）：

resource.type="http_load_balancer"
jsonPayload.enforcedSecurityPolicy.name!=""

建議把這個查詢存成「已儲存的查詢」，方便日後快速查看。

結語：Cloud Armor 值得學嗎？

值得，而且應該在服務上線前就設定好，而不是等到被攻擊才補。

GCP Cloud Armor 的入門門檻不高，Standard 版本費用合理，3 個步驟就能讓你的服務多一層 WAF 保護：建立安全政策、加規則、套用到 Backend Service。

從最基本的 IP 封鎖和地理封鎖開始，再慢慢加入 WAF 預建規則集，觀察 Log，調整靈敏度。

不需要一次把所有功能都打開，循序漸進才不會誤擋正常流量。

如果你的服務已經有 Global External HTTP(S) Load Balancer，今天就可以花 15 分鐘把基礎的 Cloud Armor 設定好。

相關細節可以參考 Cloud Armor 說明文件。

如果想了解其他 GCP 的資安防禦功能，可以參考《雲端的資訊安全防禦縱深，常用 GCP 資安服務介紹》。

常見問題（FAQ）

Q1：Cloud Armor 可以防禦 L3/L4 層的 DDoS 攻擊嗎？

A：GCP Cloud Armor 本身專注在 L7 層（應用程式層）的防護，L3/L4 層的 DDoS 防禦由 Google 底層基礎設施自動提供，不需要額外設定。大流量的 UDP Flood 或 SYN Flood，Google 網路邊緣就會自動緩解。如果你需要 L7 層的 HTTP Flood 防護，才需要在 Cloud Armor 設定速率限制規則。

Q2：Cloud Armor 可以保護 Cloud Run 服務嗎？

A：可以，但 Cloud Run 必須先搭配 Global External HTTP(S) Load Balancer 對外服務，才能套用 GCP Cloud Armor 安全政策。設定方式是建立 Serverless NEG（Network Endpoint Group），把 Cloud Run 掛到 LB 的後端服務，再套用安全政策。直接用 Cloud Run 的 .run.app 網址，無法使用 Cloud Armor。

Q3：Cloud Armor 的規則修改後多久生效？

A：在 Google Cloud Console 儲存後，新規則或修改後的規則最快 60 秒內生效，最慢約 5 分鐘完全傳播到所有 Google 邊緣節點。如果測試時還沒看到封鎖效果，等 5 分鐘後再試，不要急著以為設定有問題。

Q4：同一個 GCP 專案可以建立幾個安全政策？

A：預設上限是每個 GCP 專案 200 個安全政策，每個政策最多 200 條規則。一般使用不太會碰到這個限制。如果有需要，可以申請提高配額。

Q5：安全政策可以套用到多個 Load Balancer 嗎？

A：一個安全政策可以套用到多個後端服務（Backend Service），這些後端服務可以屬於不同的 Load Balancer。但反過來，一個後端服務在同一時間只能套用 1 個安全政策。

Q6：使用 WAF 預建規則集會不會有很多誤判？

A：剛啟用時確實可能有誤判，特別是靈敏度較高的等級。建議先用「Preview Mode」觀察 1–3 天的 Log，確認沒有異常後再正式開啟封鎖。靈敏度從 Level 1 開始，視需要再調高。

Q7：Cloud Armor 可以封鎖特定的 User-Agent 嗎？

A：可以。用 CEL 表達式判斷 request.headers['user-agent'] 欄位，例如封鎖 sqlmap 工具：request.headers['user-agent'].matches('.*sqlmap.*')。不過攻擊者可以輕易偽造 User-Agent，這個方法只適合封鎖懶惰的攻擊工具，不能作為主要防禦手段。

Q8：Cloud Armor 有辦法只保護特定路徑，不影響其他路徑嗎？

A：可以。在規則條件中加入 request.path 的判斷，例如 request.path.matches('/api/.*') 只對 API 路徑套用規則，其他路徑不受影響。這樣可以針對敏感端點設定嚴格規則，同時不影響靜態資源的存取速度。

Q9：Cloud Armor 和 reCAPTCHA 可以結合使用嗎？

A：可以。Cloud Armor 支援整合 reCAPTCHA Enterprise，當偵測到可疑流量時，可以觸發 CAPTCHA 挑戰，而不是直接封鎖。這個功能適合面向一般用戶的服務，因為直接封鎖可能誤傷真實用戶，先給 CAPTCHA 挑戰更友善。

Q10：如果我換掉 Load Balancer，之前設定的 Cloud Armor 安全政策會消失嗎？

A：GCP Cloud Armor 安全政策本身不會消失，因為它是獨立的 GCP 資源。但套用關係會斷掉，因為原本的 Backend Service 被刪除了。換 LB 後，你需要重新把安全政策套用到新 LB 的後端服務上，政策內的規則設定全部保留，不需要重新設定。

The post GCP Cloud Armor 完整教學：功能介紹、使用條件與防禦規則設定 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

一、Service Account 簡介

在 GCP 各種底層運作當中，有很多會代替我們人類執行的服務，例如 Compute Engine 的虛擬機器，這些服務要動起來，就要給它們一個身份，就是  Service Account，並且要讓它們有權限存取其他服務，例如 Cloud Storage 或 BigQuery，就要在 IAM 授予角色給 Service Account。

從開發的角度來說，Service Account 就是程式專用的帳戶，代表程式本人的身份。重點是，程式是 24 小時全年無休在跑的，它操作 GCP 的次數遠遠超過我們人類，所以管理好 Service Account 很明顯是更為重要的。

和人類的帳號不同的是，Service Account 是沒有密碼的，它是放在程式裡使用，典型的方法就是產生 Service Account Key，它是一個 Json 文字檔，上面記錄 Service Account 所在的 GCP 專案、Key 的 ID、Key 本身 RSA 2048 的值（可視為密碼）等等。

我們會在程式碼裡指定 Key 的存取位置，但通常我們不會把 Key 直接放在程式碼當中（太危險了），而是去外部某個安全的地方讀取到 Key，就可以去呼叫 GCP 上的各項服務。

重點就在這裡，一個 Service Account 可以生成很多 Key，而這些 Key 都被使用者下載到各處，或直接存到主機的某個地方，反而增加了帳戶被盜的風險。

萬一權限設定太大，而 Key 又被拿走，就像你的帳戶被盜，駭客可以在你的專案環境建立大量機器做為殭屍電腦，或是挖礦，一開就是幾千幾萬台，導致你在幫駭客支付 GCP 的費用。

因此 Service Account 和 Key 務必好好保管，以免遭有心人士濫用。

二、使用 Service Account 的小技巧

以下我們依照系統開發的流程，來逐步說明使用 Service Account 的小技巧。

(一) 系統設計階段的最佳安全實務

1. 充分利用 GCP 內建的身份驗證機制 

(1) 在 GCP 內部運行的資源

針對運作應用程式的服務如 Compute Engine、App Engine 和 Cloud Run，一定要為它們設定專屬的 Service Account。

首先 Service Account 在這些服務當中運作，不需要產生 Service Account Key 去跟其他 GCP 服務互動，光是這一點，就直接免除了金鑰外洩的風險。

而由於像 Compute Engine 和 App Engine 預設的 Service Account 具有 Editor 角色，權限非常大，所以才要另外設定專屬的 Service Account，並且給它們設定「最小且必要的權限」，就是所謂最小權限原則 （Principle of Least Privilege），即使該服務被盜用，也能透過權限來限制它的活動範圍，降低駭客入侵帶來的破壞。

而且每個服務用各自的 Service Account ，可以確保每一支程式都是隔離運作的，萬一有個服務遭到入侵，也不會影響到其他服務的正常運作，避免「牽一髮而動全身」的風險。

(2) 容器化環境的解決方案

Google Kubernetes Engine (GKE) 提供 Workload Identity Federation for GKE。讓 Kubernetes 服務帳號能夠無縫地對應到 GCP 服務帳號，帶來極大便利。

透過這種方式，容器化應用程式可以直接使用 GCP 的各種服務，而不需要在系統中儲存 Service Account Key。簡化了權限管理流程，也顯著提升了系統的安全性，為開發者和維運人員提供了一個更加方便且安全的雲端運算環境。

(3) 在 GCP 外部的系統中的創新方法

同上 Workload Identity Federation 不只用於 GKE，也能讓不在 GCP 內部的系統也能輕鬆存取 GCP 資源。

這項功能讓在 AWS、Azure 或是公司自己機房的應用程式，可以使用它們原本的身份認證機制來存取 GCP 的各種服務，不需要額外管理和儲存 GCP 的 Service Account Key。

這樣的設計大幅減少了在多雲環境下管理憑證的複雜度，讓跨雲服務的整合變得更加簡單安全。

綜合以上三種解決方法，你可以看出來，就是盡量不使用到 Service Account Key，間接地減少金鑰外洩的風險。

2. 建立清晰的 Service Account 策略

(1) 了解各種身份驗證選項的優缺點

A. 從應用程式連接 GCP 各項服務

你可以設定「應用程式預設憑證」(Application Default Credentials；ADC)，然後使用對應的程式語言函式庫，這是最常見的開發方式，適合大多數應用程式開發。

B. 需要使用 ID Token 的情況

ADC 主要是證明「這個應用程式有權限使用 Google Cloud 資源」，但不知道身份，ID Token：主要是證明「這個人/使用者是誰」，包含使用者身分資訊。當你需要使用者層級的身分驗證，不只是「應用程式有權限」而已。

C. 實作使用者身份驗證

當你需要讓你的應用程式的使用者能夠登入並存取 Google 服務，可以查看這份文件，裡面有不同方式的比較。

D. 在本機環境試用命令列（Command Line）工具

你可以在自己電腦上安裝 gcloud CLI，輸入驗證的指令並確認身份後，就可以輸入各種指令來操作各項 GCP 的服務和資源。

E. 在本機環境測試 API

你不需要特別準備一個寫程式的環境，你可以直接用像是 curl 的指令來呼叫 REST API。

F. 測試 GCP 官網提供的範例程式碼

你可以在本機設定 ADC 憑證，並安裝相關的客戶端函式庫（ Client Library），客戶端函式庫會自動找到你的憑證，讓你能直接執行程式碼。

在 GCP 的官方文件中，已經整理好各種身分驗證的相關說明，你會發現有很多情況不一定要使用 Service Account 和 Key。

(2) 建立評估流程

為特定情境選擇最合適的身份驗證方式，可以參考這個流程，你一樣會發現，在判斷的過程當中，很多情境都不一定要用到 Service Account，真的是沒有其他辦法了，才用 Service Account。

(3) 使用機構政策 (Organization Policy) 

Organization Policy 提供了管理 Service Account 和 Key 的多種政策控制如下：

• iam.disableServiceAccountCreation – 禁止在專案中創建新的 Service Account
• iam.disableServiceAccountKeyCreation – 禁止為服務帳戶創建新的 Service Account Key
• iam.disableServiceAccountKeyUpload – 禁止上傳外部生成的 Service Account Key
• iam.serviceAccountKeyExpiryHours – 強制設定 Service Account Key 到期時間
• iam.allowedPolicyMemberDomains – 限制可以被授予 IAM 角色的帳號所屬的網域，包括服務帳戶的網域。

使用機構政策做到了幾件重要的事情：它們防止人們亂建立沒人監控的服務帳戶，這樣可以避免資源使用混亂。

它們也限制 Key 的建立，並要求定期更換 Key，大幅降低了 Key 被盜用的風險。這些工具還讓管理員能清楚看到誰在用什麼服務帳戶、有什麼權限，確保公司符合各種規定。

最重要的是，這些政策幫助確保只有真正需要的服務帳戶會被建立，減少了可能被攻擊的地方。你可以根據不同部門或專案的需求，靈活設定這些規則的嚴格程度，既保障安全又不會妨礙正常工作。

(二) 開發與測試階段技巧

1. 使用專屬的 Service Account 提高可觀察性

為每個應用程式建立獨立的服務帳戶，並分配最小權限。

你甚至可以在不同環境的應用程式中，都使用不同的服務帳號，讓環境的隔離做得更為徹底，就不會發生一台機器中毒，然後感染整個環境的狀況。 

另外一個好處是，當你查看稽核記錄（ (Audited Logs）時，可以通過「principalEmail」欄位追蹤到每一個 Service Account 到底訪問過哪些資源，或是操作過哪些 API，確保他們沒有濫用權限，或訪問不該訪問的地方，大為提高了 Troubleshooting 的效率。

這樣做有幾個重要好處，首先它能幫助您清楚區分不同應用程式的活動，讓監控和管理變得更加簡單。

此外，還能幫助你進行更精確的權限控制，讓每個服務只擁有它所需的最小權限，從而減少安全風險。如果一個服務帳戶被入侵，受影響的範圍也會被限制在該服務的權限內，不會危及整個系統。

2. 安全地建立與傳送金鑰

(1) 使用命令列工具創建金鑰的技巧 

在 GCP 中建議使用命令列工具來提高安全性，就是下達 gcloud 指令，直接將 Key 檔案寫入指定的位置：

gcloud iam service-accounts keys create 

這種方法的好處是，系統會自動設置適當的檔案權限，提高了金鑰的安全性。這比手動下載金鑰檔案更安全可靠，也減少了人為錯誤的可能性，像是 Key 到處亂放、甚至被盜取的情況。

(2) 在團隊間安全傳送憑證的新方法 

傳統上，我們是直接把 JSON 金鑰檔案通過電子郵件、聊天工具（如 Line 或Slack）或雲端硬碟分享等方式將檔案傳送給別人。

這樣會增加了洩露的風險，同一個金鑰檔案可能同時存在多個地方，甚至大家傳來傳去，過程中複製越多份，存放的地方越多，越有可能被有心人士取得。

萬一金鑰被盜，你也沒有辦法追蹤到底是誰手上的那一個金鑰被盜。這樣的話，管理員只能直接停用這個金鑰，這樣也會導致要使用同一個金鑰的人全部都不能用，相關的程式全部都停止運作，你必須重新建立金鑰，然後再次發送給各位，非常麻煩。

你可以採用一種創新的自簽證書方法，這比傳統方式更安全。

具體做法是：首先在需要使用 Service Account 的目標主機上創建 RSA 2048 位的金鑰對和自簽證書。

建立私鑰：

openssl genrsa -out private-key.pem 2048

使用私鑰創建公鑰證書請求： 

openssl req -new -key private-key.pem -out cert-request.csr

根據系統提示來填寫國家名稱、城市、公司名稱、單位名稱、服務名稱和電子郵件地址。

生成自簽證書（有效期 365 天）：

openssl x509 -req -days 365 -in cert-request.csr -signkey private-key.pem -out public-cert.pem

開發人員只需要傳遞公開的證書檔案（public-cert.pem）給 GCP 管理員，這部分無需保密，可以透過一般的溝通管道分享。

然後，管理員將這個公開證書上傳並綁定到對應的 Service Account：

gcloud iam service-accounts keys upload public-cert.pem –iam-account=my-service-account@project-id.iam.gserviceaccount.com

運作流程如下圖：

這種方法的最大優點是完全不需要傳遞私鑰，因為私鑰始終保留在原始機器上，大幅降低了憑證洩露的風險，同時保證了開發人員和主機能夠安全地使用 Service Account。

到這裡你可能會想到一個問題，上面提到的原始機器，不就是 Compute Engine 的虛擬機器嗎？Compute Engine 在呼叫 GCP 服務時，本來就不需要使用 Service Account Key 啊，這樣做有什麼意義嗎？不是多此一舉？

對的， Compute Engine 本來就不用 Service Account Key，這個自簽證書的機制主要是針對「外部環境」設計的，例如：

• 本機開發環境：開發人員在自己的電腦上進行開發時需要存取 GCP 資源
• 其他雲端平台的機器：例如在 AWS、Azure 或阿里雲上運行但需要存取 GCP 服務的應用
• 自有機房中的主機：公司內部數據中心的機器需要與 GCP 服務整合
• CI/CD 管道：在 Jenkins、GitHub Actions 等持續整合 (Continuous Integration) 環境中需要存取 GCP
• 第三方服務：需要整合到 GCP 的外部 SaaS 解決方案

(3) 善用過期時間設置

前面提到的 Organizatino Policy，設定的是「所有 Service Account Key」統一的有效時間，而每一個 Service Account Key 本身，都可以單獨設定到期時間。

前者會設定長一點，例如三個月或六個月，做為所有 Key 的最低要求，後者則是會視情況設定較短的到期時間，可能只有 7~30 天，因為它的掌控程度較高，萬一到期再建立新的 Key 就好了。

我們可以為開發和測試環境的 Service Account Key 設定合理的過期時間，自動讓不再需要的 Key 失效，減少後續管理工作，即使金鑰被有心人士取得，它也失去了作用。

(三) 部署與生產環境技巧

1. 優化 Service Account Key 的存儲方式

(1) 硬體安全解決方案

使用硬體安全模組（Hardware Security Module；HSM）或可信平台模組（Trusted Platform Module；TPM）來管理您的金鑰可以大幅提升安全性。

A. 硬體安全模組

關於 HSM，你可以購買專用的設備，價格為幾千到幾萬元不等，然後將此設備連接到伺服器上（不一定是 GCP 的虛擬機器）。 HSM 設備通常會提供的管理工具，使用跟上述類似的方法建立 RSA 金鑰對和公開的自簽證書，再上傳到 GCP 綁定 Service Account Key。

程式要準備呼叫 GCP 的 API 時，會先呼叫 HSM 廠商提供的 API，發送資料跟 HSM 索取簽名，簽名就是要向 GCP 證明這個 Request 是合法的，簽名結果再返回程式，程式再將原始資料和簽名結果一起發送到 Google Cloud API。

其實，你不一定要額外購買 HSM 設備，Cloud Key Management Service (Cloud KMS) 也有 HSM 的功能，這是一種由 Google 管理的硬體安全模組服務，符合 FIPS 140-2 Level 3 安全標準，這樣你就不需要購買實體 HSM 設備。

GCP 使用之前儲存的公鑰，來驗證簽名是否真的由對應的私鑰生成。只有當簽名驗證成功時，GCP 才會認為這是來自授權 Service Account 的合法請求。

這樣做有幾個好處：

• 即使有人攔截了請求和簽名，也無法使用這些資訊生成新的有效請求，就是駭客無法產生新的並且合法的 Request 來呼叫 GCP 的 API。
• 只有 HSM 中的私鑰才能生成 GCP 可以驗證的有效簽名，是一個唯一可以信任的來源。
• 主機和應用程式不一定都要在 GCP 內，但如果都在 GCP 內部，必定更為安全。
• 每個請求的簽名都是獨特的，防止重放攻擊（Replay Attack），指的是駭客使用一模一樣的資料去操作 GCP。

B. 可信任平台模組 (TPM)

大多數電腦（特別是 2016 年後製造的）通常已內建 TPM 2.0 晶片在主機板上。如果沒有內建 TPM，你就要購買一個 TPM 模組並安裝到主機板上。

這些模組通常是小型電路板，可以插入主機板上專門的 TPM 插槽。然後在 Linux 上，使用 tpm2-tools 工具集來產生金鑰。

以 Debian 為例，您可以安裝 tpm2-tools 後執行：

ls /dev/tpm*

如果顯示 /dev/tpm0 或 /dev/tpmrm0，通常表示系統已識別到 TPM 設備：

安裝 tpm2-tools 的相關指令如下（不同作業系統版本，指令可能會有所不同）：

更新套件列表：

sudo apt update

安裝 TPM2 工具和資源庫：

sudo apt install tpm2-tools tpm2-abrmd libtss2-dev

安裝後重啟電腦，進入 BIOS/UEFI 設定，尋找 「Security」或「Advanced」選項，啟用 「TPM」，然後重啟電腦。

接下來建立「主要金鑰」（Primary Key），它是 TPM 中所有其他金鑰的根源。

tpm2_createprimary -C o -g sha256 -G rsa -c primary.ctx

然後使用之前創建的主要金鑰來創建一個子金鑰對：

tpm2_create -C primary.ctx -u key.pub -r key.priv

將金鑰載入 TPM：

tpm2_load -C primary.ctx -u rsa.pub -r rsa.priv -c rsa.ctx

將公鑰轉換為 PEM 格式（是 GCP 可接受的格式）：

tpm2_readpublic -c rsa.ctx -o rsa.pem -f pem

使用 OpenSSL 指令創建自簽名證書：

openssl req -new -x509 -key tpmkey -out cert.pem

接下來就可以將 rsa_cert.pem 上傳到 GCP Service Account。

最後程式在運作時，就可以使用以下指令，對要簽名的資料（例如 data.txt）來執行「簽名」：

tpm2_sign -c rsa.ctx -g sha256 -o signature.bin data.txt

另外注意程式需要能夠呼叫 TPM 指令，這需要使用 tpm2-tss 等程式庫進行開發。而且電腦必須保持開機狀態才能使用這些金鑰，因為私鑰無法從 TPM 中導出。

這樣一來，應用程式只需要使用 HSM/TPM 提供的簽名 API，而不必直接接觸私鑰。這種方法提供了硬體層級的安全保障，有效防止金鑰被複製或提取，大幅降低了資安風險。

(2) 軟體金鑰庫的實用技巧

如果你要使用軟體金鑰庫來儲存 GCP Service Account Key，在 GCP 中可以使用 Secret Manager 來儲存，以下是幾個具體的實作方法：

A. 設定精細的存取控制

• 為 Secret Manager 的使用者，設定最小 IAM 角色權限。
• 建立 Secret，然後把 Service Account 放在 Secret 裡面。
• 為不同團隊或服務建立專用的存取群組，例如讓開發團隊只能存取開發環境的 Secret。

• 為不同環境創建不同的 Key，例如 service-account-key-dev 和 service-account-key-prod，然後為每個 Key 設定不同的存取權限，你也可以或使用不同專案隔離環境，每個專案中有各自的 Secret Manager 和 Key。

B. 詳細記錄所有使用情況：

為了追蹤每個 Key 在 Secret Manager 被存取的狀況，你可以啟用 Cloud Audit Logs 來追蹤，因為根據預設，Secret 的存取是不會主動記錄的。你要去稽核記錄把它打開：

我們可以故意測試一下，在 Secret Manager 建立一個 Secret 之後，再用 gcloud 指令去讀取它。

你看到我執行了兩次讀取 Secret 的指令，因為當我第一次執行完後，出了「Hello」這個值，但我還沒馬上截圖，結果「Hello」這個值就消失了，所以我又再執行了一次，並且馬上截圖，可見 Secret 即使透過 gcloud 指令操作，也會顧及安全性，只顯示幾秒鐘。

接著就可以在 Cloud Logging 的「已稽核的資源」看到 Secret 被存取的時間和操作人員。

因為稽核記錄的儲存是有期限的，如果想要長期保存 Secret 的存取記錄，你可以設定 Log Export 到 BigQuery 或 Cloud Storage。

另外，你也可以針對 Secret 的存取記錄，建立 Log-Based Metric 監控指標，這樣就可以把 Secret 的存取次數畫在儀表板上，如果有存取異常，例如某個 Secret 平均一分鐘大概存取 5 次，突然變成 500 次，很明顯就是異常，就可以再設定快訊，來及時通知管理員。

C. 加再一層 Cloud KMS 確保主金鑰的安全

你可以在建立 Secret 時，選擇 CMEK (Customer-Managed Encryption Keys) 功能，使用 Cloud KMS 來的金鑰來加密你建立的 Secret，這樣你的金鑰，除了要有 Secret Manager 的權限角色，又同時要有 KMS 的權限角色，才能夠存取到 Secret 裡的金鑰，等於是雙重保護。

你還可以定期輪換加密金鑰，建議每 90 天一次。這樣除了你的 Service Account Key 能夠定期輪換，KMS 的 Key 也定期輪換，這樣能讓金鑰被竊取所造成的風險降到最低。

D. 實施防止未授權存取的機制

VPC Service Control 是 GCP 中最嚴格的安全功能，能夠限制哪些 API，只能從哪裡進來存取，以及資料只能輸出到哪裡。 例如你可以設定 Service Controls 限制只有公司網路才能存取 Secret Manager。

即使 Secret Manager 是軟體功能，但是當它與其他 GCP 安全功能結合使用時，還是可以在各種資安功能互相搭配之下，給予完善的保護，有效降低憑證洩漏的風險。

2. 高效追蹤 Service Account 使用情況

你可以使用 Cloud Logging 設定查詢語法，來識別過去 90 天是否有未使用的 Service Account。

在 Cloud Monitoring 中設置監控金鑰身份驗證事件指標，然後針對指標設定快訊，例如某一個 Service Account 每天不會用來呼叫某 API 超過 1000次，若超過就發出快訊通知。這能幫助您了解 Service Account 的使用模式和頻率，從而識別異常行為。

每個 Service Account 都有一個「指標」分頁，可以快速查看基本用量資訊，你可以直接從這裡找到要監控的指標，然後設定快訊，就不用去 Metrics Explorer 大海撈針尋找指標。

3. 外部整合的最佳實務建議

(1) 安全使用外部來源的憑證

當您需要從外部來源取得 Service Account Key 時，建立一個嚴謹的驗證流程非常重要。首先，您應該確保憑證的來源是可信的，例如大家統一都從 Secret Manager 取得 Key，而非透過 Line 或 Email 來傳送，避免使用來歷不明的金鑰檔案。

因為駭客雖然沒那麼容易偽造 Key，但 Key 被駭客取得後，修改其中某些欄位（如重新導向或添加惡意程式碼）但保留核心加密部分，都有可能對你的系統或 GCP 環境造成破壞。

所以每次收到或使用 Service Account Key 檔案時，都應該檢查其 JSON 格式中的 “type” 欄位值是否確實為 “service_account”，並且確認 Service Account 的電子郵件是否具有正當的權限，再確認這個 Key 是否能夠從 GCP 獲取令牌。這些檢查步驟都能幫助您確認您使用的是正確的憑證類型，而非其他類型的金鑰或偽造的檔案。

(2) 全網域授權的高效方法

GCP 提供了一種更安全、更簡潔的方式來進行服務授權，不需要使用傳統的 Service Account 金鑰。這種方法利用 signJwt API，可以為全網域提供高效的授權機制。

什麼是 signJwt？

想像你需要寄一封非常重要的信，你想確保收信人知道這封信確實是你寄的，而且信的內容沒有被人竄改。在數位世界中，signJwt 就像是一種特殊的「數位簽名」服務，幫你在重要文件上蓋上無法偽造的印章。

首先使用 Service Account 或 Workload Identity Federation 進行身份驗證。就像在公司大樓，你不用自己帶鑰匙，而是在前台登記後由保全確認你的身分。這樣可以避免直接管理和存儲敏感的金鑰文件。

然後建立一個 JSON Web Token (JWT) 做為「數位通行證」，它包含實際的資訊，例如誰可以讀取特定資料、這個權限何時過期等，這個 JWT 將作為授權請求的基礎。

接著把這封「未簽名」的 JWT 內容送到 Google 的 signJwt 服務，說：「請幫我在這份文件上簽名。」

Google 會確認你有權請求這項簽名服務，使用只有 Google 知道的特殊私鑰，再依據你信件的內容產生一個獨特的數學計算結果（簽名），然後把這個簽名附在你的信件上，形成一個完整的已簽名 JWT。

最後把它送給 Google 的授權服務，換取一個臨時的「存取令牌」，其他 Google 服務看到這個令牌時，會使用 Google 的公鑰驗證簽名。如果簽名有效，且內容顯示你有權限，服務就會允許存取。

這種方法減少了安全風險，因為你不需要下載、發佈或管理 Service Account Key 的檔案。同時簡化了授權流程，使整個過程更加高效和易於維護。對於需要在多個服務或整個網域中進行授權的場景，這是一個特別有價值的解決方案。

你可能會擔心，看起來流程很長，會不會來回很花時間或吃效能？

其實 GCP 的這些服務都經過高度優化，大部分步驟在 GCP 的基礎設施上執行得非常快速。而且這個流程只有在第一次次建立連接或每次令牌過期時才需要執行。

存取令牌一旦獲取，通常可以使用幾個小時（典型設定為 1 小時），不需要每次請求都重新執行整個流程。整個步驟加起來通常只需數百毫秒完成，所以在實際執行時，效能影響是很有限的，卻因此提升很高的安全性。

(四) 維護與治理技巧

1. 金鑰輪替的最佳策略

(1) 制定有效的輪替計劃

如上述提到，就像定期更換家中門鎖一樣，即使目前沒有安全問題，定期的更新也能防範潛在威脅。建議每隔 90 天進行一次金鑰輪替，這樣即使某個金鑰被洩露，其可用時間也會受到限制。在實際操作中，可以通過 GCP 控制台或使用 gcloud 指令來創建新金鑰並廢棄舊金鑰。

為了減少人為錯誤並確保輪替流程的一致性，建立自動化的金鑰輪替機制非常重要。您可以利用 Cloud Functions 配合 Cloud Scheduler 來定期觸發金鑰輪替流程，或者使用 CI/CD Pipeline 來管理這一過程。自動化不只是輪替，還能將新的金鑰自動部署到相關服務，減少服務中斷或人為操作錯誤。

對於儲存在 HSM 中的高敏感度金鑰，需要制定更嚴格的輪替策略。這些金鑰通常用於加密重要資料或簽署關鍵交易，因此建議為 HSM 金鑰設定更短的輪替周期，例如 30～60 天。

(2) 高效管理未使用的金鑰

如前面提到，你可以用 Cloud Logging 設定查詢語法，來識別過去 90 天是否有未使用的 Service Account，並且設定 Cloud Monitoring 監控指標， 顯示各金鑰的使用頻率，幫助您快速發現那些閒置的金鑰。

這個動作最好建立成一個 SOP，每月或每季度對所有 Service Account Key 進行全面審查。你可以使用標籤系統來標記不同狀態的金鑰，如「活躍」、「待觀察」或「待刪除」。同時，確保審查結果有明確的記錄和後續行動，避免重複工作或遺漏重要金鑰。

在移除未使用的金鑰時，不要急於刪除，而是先將其停用。停用後，觀察一段時間（通常為 7～14 天），確保沒有任何系統依賴這些金鑰。等到確認都沒問題，再執行刪除操作。這種「先停用再刪除」的方法能夠減少因誤刪而導致的系統中斷。

2. 機構層級（Organization Level）的管理建議

(1) 有效利用機構政策

管理員應在機構層級設定預設的限制條件，同時也為特殊需求的設定例外政策。例如「iam.disableServiceAccountKeyCreation」，預設禁止所有專案建立 Service Account 金鑰，但為開發環境或特定整合需求的專案設置例外。

還有透過條件表達式，如「resource.name.startsWith(“projects/dev-“)」，可以僅允許名稱以「dev-」開頭的開發專案建立金鑰，實現更靈活的控制機制，確保安全政策既嚴謹又不妨礙業務運作。

(2) 角色與權限的最佳配置

盡量避免使用過於寬鬆的 Editor 角色，而改用更精細的預定義角色（Predefined Roles）。例如為負責 CI/CD 的 Service Account 分配「Cloud Build Service Agent」和「Storage Object Viewer」角色，共允許只能執行部署工作和讀取必要的物件。

對於需要監控資源的 Service Account，可以建立包含「monitoring.timeSeries.list」和「logging.logEntries.list」等極小權限的自訂角色，而不是授予權限範圍過大的「Monitoring Viewer」角色，避免意外刪除資源或未授權訪問敏感資料等問題。

三、使用 Service Account 的注意事項

前面提到的各項技巧，有些需要時間慢慢建立，如果要立刻可以執行的方法，可以遵守以下防範的各項動作：

(一) 防範憑證外洩

1. 避免將金鑰保存在臨時位置，例如電腦桌面、共用電腦或共享的網路資料夾。

2. 不要在用戶間直接傳遞 Service Account 金鑰文件，例如存在 Line 群組、Email 或雲端硬碟。

3. 防止將金鑰提交到原始碼儲存庫，例如 GitHub 或 GitLab。

4. 不要將金鑰嵌入程序的二進位檔，如果有人獲取了你的二進位檔，他們可能能夠提取出這些金鑰，而且當你需要更新金鑰時，你必須重新編譯整個程式，不安全也很麻煩。

5. 前面雖然提到使用 Secret Manager 來儲存 Key，但能夠不使用 Service Account Key，就盡量不使用，建議還是使用 Workload Identity Federation、HSM、TPM 或自簽證書的方法。

(二) 防範安全配置問題

你需要特別小心處理那些安全認證文件。這些 X.509 證書檔案（就是那種帶有 .pem 或 .crt 副檔名的檔案），它可能會包含比你想像的更多資訊。

首先，請確保你不要在這些證書中放入敏感資訊。例如，不要在裡面寫你公司的內部系統名稱、伺服器位置或其他機密資料。

其次，當你填寫證書的「Subject」（主體）欄位時，請使用一般性的名稱，像是「GCP服務帳戶」或「應用程式認證」，而不是具體的系統名稱如「公司財務系統主機」。

另外，證書中有些是選填欄位，像是地址、城市、郵遞區號等，建議你不要填寫這些資訊。因為如果駭客取得了這些證書，他們可以利用這些地點資訊來猜測你的實體伺服器位置，或是用來發動更具針對性的釣魚攻擊。

(三) 防範權限提升風險

因為如果金鑰被不當取得，駭客可能利用這些憑證來進行各種破壞。尤其是 Editor 角色可能帶來的安全隱患，它的權限實在是太大，若被濫用可能造成嚴重損害，建議採用最小權限原則，只授予必要的權限，前面提了很多次，但還是再問一次，你真的有確實遵守嗎？

其次，應避免在檔案系統（本機電腦、VM 的某個目錄）中直接存儲金鑰，因為這樣很容易被其他人拿到或在系統備份過程中洩露。真的要用，建議使用 Secret Manager 來安全存儲這些敏感憑證。

最後，在虛擬化環境（如容器或虛擬機）中使用 Service Account 金鑰時，要防止底層安全問題，因為底層主機被入侵的話，可能導致所有虛擬環境的金鑰都被洩露。在這種情況下，可考慮使用臨時憑證或 Workload Identity，來減少金鑰洩露的風險。

四、同場加映：防止呼叫 API 爆量的方法 

GCP 提供了豐富的 API 服務，幾乎所有 GCP 的功能，都是以 API 的形式在運作，讓開發人員可以透過程式來自動化存取各種雲端資源。但如果沒有加以控制，API 可能被過度呼叫，導致成本急劇上升，甚至造成服務異常。

(一) API 爆量的發生情境

這種問題通常發生在以下幾種情境：

1. 開發或測試環境未設限

開發人員可能在測試時，沒有把程式碼寫得完善，不慎觸發大量 API 請求。

2. 系統錯誤或程式 Bug

例如無限迴圈 （For Loop）或非預期的重試機制，導致 API 被頻繁呼叫。

3. 流量暴增

突然的流量高峰，例如 DDoS 攻擊或用戶激增，可能導致 API 配額迅速耗盡。

4. 惡意濫用

如果 API 沒有適當的身份驗證與授權控制，可能會被未授權用戶濫用，如上述 Service Account Key 被盜用，如果這個 Key 具有建立虛擬機器的權限，就會被任意建立大量主機，執行挖礦或作為殭屍電腦，是上述情境中最危險的情況。

(二) 限制 GCP API 呼叫的方法

1. 設定消費預算警報

GCP Cloud Billing 允許設定預算警報，一旦 API 費用達到特定閾值，系統會自動發送通知，提醒使用者注意 API 開銷。像我自己是真的把預算警報用到「極致」，不要說超過 50 美金要通知，我只要每超過 1 美金都要收到通知。

但是 GCP 預算警報要隔一天才知道，在正常使用的情況下，GCP 的費用不會超出太多。但如果是被駭客入侵或攻擊，當你看到警報時，可能已經產生一百萬的 GCP 費用了，所以這是緩不濟急的，請再搭配下面提到的方法。

2. 加強 Service Account 權限控制

像前面提到最基本的要求，就是為 Service Account 設置最小權限原則，限制各個 Service Account 只能呼叫特定的 API 和服務，甚至不同環境都用不同的 Service Account，讓它無法隨意呼叫 GCP 的 API。

3. 設定 API 配額限制

在 GCP 上呼叫 API 有多種方式，包括使用 Service Account 和 API Key，API Key 是一種相對簡單的認證方式，它只是一個字串，例如「AIzaSy………M-O1pNg」。

API Key 主要用於特定 API 的存取控制，你可以設定這個 Key 只能呼叫 Compute Engine API，其他 API 都不能呼叫。有些服務能夠限制 API 請求配額，可以有效確保 API 的呼叫次數，尤其是可以限制一天之內或一分鐘之內的次數上限，甚至能區分每個使用者的呼叫上限。

這可以確保萬一 API Key 被駭客取得，呼叫次數也能限制在某個次數範圍之內。

4. 設定資源配額

除了像 API 可以限制呼叫次數，在 GCP IAM 裡管理的則是資源配額，例如專案內可以建立的 VM 數量、vCPU 核心數、儲存容量等各種資源可被開啟的數量上限。

我個人認為這是更重要的，因為假如駭客盜取你的帳號，或是 Service Account Key，他可以直接在你的 GCP 專案內任意開啟機器，要注意他不是一台一台手動開機器，他是用程式自動化的技術，在每個 Region 把你的機器「開好開滿」，直接開到配額上限。

以 N1 的 vCPU 來說，如果你是以個人信用卡使用 GCP，每個 Region 初期只能用到 24 vCPU，隨著使用時間越長，配額會自動調高。

但是你的專案帳單如果直接綁定在代理商，系統會判定你是等級較高的用戶，你在每個 Region 能使用的 vCPU 就會提高不少，萬一被駭，就會變成每個 Region 的主機、CPU 甚至 GPU，全部開滿。

只要 1~2 天的時間，就可以在一個專案內，開「幾萬台」機器，隔天就會收到「百萬」等級的帳單，等你收到帳單警示已經來不及了。這是確實有發生過的情況，絕非杜撰，這就回到你的 Service Account Key 務必保管好，甚至使用其他驗證方式。

難道沒有其他解決辧法嗎？有的，就是減少配額，建議針對每個型號，例如 N1、N2 的 vCPU，而且每個 Region 都要減少。如果你沒有在用 GPU，就直接把每個 GPU 配額改成 0。

你可能會想，駭客進來也可以提高配額啊？這點不用擔心，減少配額可以改完當下就生效，但是如果要增加配額超過預設值，Google 那邊至少需要兩天的時間人工審核，還要填寫聯絡方式包含電話號碼，所以駭客不會去做的。

5. 設定各個服務的運作上限 

(1) Compute Engine 的配額限制

如前段提到的例子，你可以通過配額限制來控制資源使用。

(2) Google App Engine 必須要調整 app.yaml

很多人都不知道，App Engine 預設沒有設定上限，代表它會無限擴充，重點是，很多人都一直以為他的 App Engine 只有一台機器在跑，直到看到帳單才發現原來它在某個尖峰時間，曾經擴充過多台主機。

你必須要在 app.yaml 設定 Autoscale 的上限數量，才不會一直擴充下去。

(3) Cloud Run 或 Cloud Run Function 

執行個體預設的 Autoscale 數量是 0 到 100，記得把它改成你能接受的上限，例如 5 個。

(4) 設定 BigQuery 每天查詢上限 

要注意，原本 BigQuery 的預設查詢配額，也是「無上限」的，如果你的資料太多又沒整理，或是不小心有程式一直自動查詢大量資料，也會造成非常大的費用。你可以設定 BigQuery 每天的查詢限制，也能設定每天+每個使用者的查詢限制。

6. 節流機制 (Throttling)

(1) Cloud Armor 節流（Rate Limit）

對於外部流量，Cloud Armor 可以設定節流機制，例如每分鐘不能存取超過 1,000 次，超過即停止服務。但要注意，你要先知道你的服務平時的流量，以及假日或活動期間的流量，以免低估流量，反而把真正的用戶阻擋在外面。

(2) 本地節流機制

這裡指的就是你自己開發的應用程式，直接實作 API 請求節流的邏輯，那你就可以彈性地設定各種不同時間間隔，例如每秒不能超過 100 次，每分鐘不能超過 1000 次，每小時不能超過 10,000 次等等。這也是要注意，不要錯估流量。

另一方面，如果程式發生錯誤，例如當 API 回應 429 時，必須要重新存取（Retry），或是被外部呼叫，你可以使用指數退避 (Exponential Backoff) 策略處理重試，自動延遲並逐步增加重試間隔，例如當發生第一次錯誤，休息兩秒，第二次，休息四秒，第三次，休息八秒…等，不要讓程式在出錯時還一直不斷存取，減少無謂資源的消耗。

7. 設定各種指標的監控

Cloud Monitoring 可以監控很多指標，不只監控 API 呼叫次數，你也可以監控例如用戶發出的 Request 數量，或是主機每秒送出的流量大小，並且限制例每分送出超過 10 MB，就發出流量警告，讓你在異常流量發生的當下，就能夠立即發現並阻擋。

五、結論

成功管理 Service Account 需要綜合考慮安全性、方便性和維護成本。通過上述的小技巧，你可以在系統開發過程的各個階段，有效並安全地使用 Service Account。

要記住的是，不是「Service Account 怎麼用」或「Service Account Key 怎麼保管」。因為你「不一定要用 Service Account」，選擇合適的身份驗證方法是最重要的第一步。

你可以優先考慮 GCP 的內建驗證機制，只在非用不可的時候，才使用 Service Account 和 Key，並依照最佳實務來管理。這樣不僅可以降低維護成本，還能大幅提高系統的整體安全性。

另外，各種機制也是需要不少時間規劃流程和制度，以及各部門之間互相配合，遵守規範，這也需要主管大力支持並提供充份的資源，才能有效實施。

六、常見問題

(一) 如何檢查 Service Account 是否有過度授權？

1. GCP 提供 IAM 建議 (IAM Recommender)

可以分析 Service Account 的使用情況，找出是否擁有過多權限。
步驟：

(1) 前往 GCP Console，打開 IAM & Admin > IAM。

(2) 找到 Service Account，查看「建議的角色」(Recommended roles) 欄位。

(3) 如果 GCP 建議降低權限，請根據建議調整角色。

2. 使用 IAM Policy Analyzer 進行分析

你可以在 IAM & Admin > Policy Analyzer 中輸入 Service Account 的電子郵件。查看該帳戶擁有哪些權限，並確認是否有不必要的存取權限，操作方式和上述差不多。

(二) 如何刪除未使用的 Service Account？

可參考以下步驟：

1.  列出所有 Service Account 並找出未使用的帳戶：

gcloud iam service-accounts list –format=”table(email, disabled)”

可以顯示所有 Service Account 和目前的使用狀態 (是否已停用)。

(2) 停用 Service Account

如果確認某個 Service Account 一直都沒有在用，可先停用：

gcloud iam service-accounts disable service-account@your-project.iam.gserviceaccount.com

這樣可以避免影響現有服務，若發現問題仍可重新啟用。

(3) 刪除 Service Account

停用後，如果確定不再需要，可刪除：

gcloud iam service-accounts delete service-account@your-project.iam.gserviceaccount.com

⚠ 注意：刪除後不可恢復，請確保已經沒有任何應用程式在使用該帳戶。

(三) Service Account 金鑰遺失該怎麼辦？

如果 Service Account 金鑰遺失，應立即執行以下步驟，以確保系統安全：

1. 列出現有的 Service Account 金鑰

gcloud iam service-accounts keys list –iam-account=service-account@your-project.iam.gserviceaccount.com

這會顯示所有金鑰的 KEY_ID，你可以確認哪個金鑰可能遺失。

2. 立即刪除遺失的金鑰

如果確定某個金鑰已洩露，請使用以下命令刪除：

gcloud iam service-accounts keys delete YOUR_KEY_ID –iam-account=service-account@your-project.iam.gserviceaccount.com

刪除之後，即使駭客手上擁有你的金鑰檔案，也是無法發運任何作用的。

⚠ 注意：一旦刪除，任何使用該金鑰的應用程式都將失去存取權限，請確保已經準備好替代方案。

3. 生成新的 Service Account 金鑰

如果仍需使用金鑰（不推薦），可以產生新的金鑰：

gcloud iam service-accounts keys create new-key.json –iam-account=service-account@your-project.iam.gserviceaccount.com

(四) 我可以將 Service Account Key 存放在 GitHub 嗎？

不建議這樣做，因為這可能導致憑證洩漏，應該使用 Secret Manager 來管理。

(五) 如何檢測 Service Account Key 是否外洩？

你可以透過 Cloud Audit Logs 來查詢這個 Service Account Key 異常存取行為，你可以參考這份文件來操作。

(六) Service Account Key 有效期多久？

預設情況下都是永久的，開發人員應該手動輪替金鑰。

(七) 有哪些更安全的替代方案？

Workload Identity Federation 和 OAuth 2.0 是更安全的選擇，能不用 Service Account Key 就盡量不要用。

另一個方法是產生 RSA 2048 金鑰對，透過 HSM 模組、Cloud KMS 或 TPM 方法，在私鑰完全不需要對外分享的情況下，讓應用程式還是可以操作 GCP 的 API。

(八) 如何讓 CI/CD 流程更加安全？

可以使用 Workload Identity Federation，避免直接存放 Service Account Key。

(九) 如何避免因資安事件發生，而造成大量的帳單費用？

1. 設定預算警示
2. 設定 API 配額
3. 設定減少資源配額，例如 CPU 和 GPU
4. 設定 Service Account 和 Key 的監控和快訊
5. 設定流量和資源使用量的監控和快訊
6. 限縮服務本的的自動擴充上限
7. 設定應用程式的存取次數

本文同時刊登於：

《【東東老師 X 思想科技】使用 GCP Service Account 開發程式的小技巧》

《【東東老師 X 思想科技】使用 GCP Service Account 開發程式的注意事項》

The post 使用 GCP Service Account 開發程式的小技巧和注意事項 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.