不需要自己架防火牆主機，也不需要密碼學背景，最快 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 實戰講師.

Security Command Center 簡稱 SCC，就是資訊安全指揮中心，

是 GCP 的資安和風險管理平台，提供各方面的安全分析和威脅偵測，

就像是給你的雲端環境請了一組資安保全團隊，

24小時不間斷幫助你保護雲端上的系統和資料。

它包含了 Standard、Premium 和 Enterprise 三種版本，

可以針對企業的規模大小和需求，提供不同程度的保護。

這裡先介紹從 Console 上可以看到的各個功能視圖 (View)。

1. Risk Overview

不管你使用什麼版本，SCC 都能夠快速地把各種威脅分門別類，

並且總結起來，呈現在首頁的 Risk Overview，

並且會依照嚴重程度排序，讓你可以優先解決最嚴重的威脅和弱點。

隨著 SCC 版本的提升，可以收集到的威脅種類也會更多。

2. Vulnerabilities View

可以看到詳細的弱點清單，牽涉到的相關法規，和建議的解決方法。

3. Assets View

在這裡能夠看到所有建立的資源，例如 BigQuery Table、Subnet、防火牆和 Service Account 等等，

也能看到各個資源所屬的專案，以及資源建立的位置。

方便讓你定期進來盤點，如果擔心自己建立過什麼東西，被閒置或濫用的話，來這裡一定能夠找到。

4. Findings View

Findings 可以把所有發現到的威脅，用各種過濾器或查詢條件，讓你快速找到要處理的部分，

因為它能夠全部顯示，撈出來的資料量非常大，

所以它也提供 Mute 功能，你可以建立 Mute Rule 去過濾掉不想看到的東西，方便你查找到真正重要的威脅。

5. Sources View

Sources 和 Risk Overview 有點像，就是把所有偵測的威脅，

依照不同功能總結呈現在這裡。

例如你要查看容器或 GKE 的威脅，

可以直接去點擊相對應的資訊卡，查看到該功能發現的威脅細節。

而 Threats、Compliance 和 Posture Management 都是 SCC Preimum 以上版本才有提供，

以下分述各別版本會逐一提到。 

二、SCC Standard 版本功能介紹

1. Security Health Analytics

提供漏洞的掃描，可以自動偵測你在 GCP 環境中最嚴重的漏洞和錯誤設定，常見的掃描結果包含：

(1) 啟用舊版的授權方式

(2) MFA (Multi-Factor Authentication) 多因子驗證未執行

(3) IAM 裡有「不在網域內」的成員，例如有人使用個人的 Gmail，或是授權給外部人員

(4) 完全開放的防火牆規則

(5) 完全公開的 Cloud Storage Bucket

(6) 完全公開的虛擬機器 Image

(7) 完全公開的 BigQuery Dataset

(8) 對外的 IP 位址

(9) 對外的 Cloud SQL 主機

(10) 網站沒有強制執行 SSL 加密

而掃描的結果會自動呈現在 Vulnerabilities，它還會告訴你某個漏洞是否違反了國際標準，

並提供解決的建議，幫助你合規，是非常貼心的功能。

你會看到有些設定被判斷為漏洞，因為它的檢測結果是基於 GCP 自己的標準，

例如你可能有一個網站就是要對全世界服務的，

那你防火牆的 HTTPS Port 自然會完全公開，

圖片或影片也會來自完全公開的 Bucket，甚至也會有一個對外的 IP 位址。

所以當你看到太多警告，不用太過擔心，真正的漏洞沒有想像中那麼多。

2. Web Security Scanner

GCP 對於部署應用程式的平台，

包含 App Engine、Compute Engine、GKE，皆提供弱點掃描，

它會爬行 (Crawling) 你的網站，從首頁開始延伸到的相關連結，

執行各種輸入和事件處理，藉此偵測應用程式的弱點。

尤其知名的 OWASP (Open Web Application Security Project) 資安組織公佈的威脅，

像是 A02 的明碼傳送密碼、A03 的 SQL injection和 XSS (Cross-Site Scripting) 攻擊，都可能掃描出來。

在 SCC Standard 版本裡，你可以執行手動的掃描排程，只要提供 IP 或網址就可以開始掃描，

也可以自訂多個參數來做更客製化的掃描，讓掃描的廣度和深度更為全面。

但是要注意，必須是專案內的應用程式才能掃描，以及要用公開的 IP 或網址才能掃描得到。

當你掃描完後，你可以在 Vulnerabilities 頁面看到像這樣的結果：

能依照漏洞的狀態、類別、數量、嚴重程度和合規的部分來排序，

讓你可以依照順序來改善應用程式的漏洞。

3.Security Command Center errors

Security Command Center errors 主要用來幫你偵測 SCC 是否有任何設定錯誤的地方，

因為這些錯誤會導致 SCC 無法正常運作，它會產生錯誤訊息來提示你。

例如 API 尚未啟用、容器威脅偵測的 Image 拉不出來、

Cloud Logging 的記錄無法匯出到 SCC、專案被 Service Control 保護，

導致 SCC 無法進入等等。

針對各種錯誤，GCP 也提供修復 SCC 問題的官方文件，讓你可以快速解決。

4.Continuous Exports

這個功能可以自動把新發現的威脅匯出到 Pub/Sub，

Pub/Sub 是一種無伺服器器的訊息佇列功能，

可以將匯出的資料暫存，然後再由其他應用程式做後續的處理和分析。

5.從下列功能發現到的弱點或威脅，統一呈現在 SCC：

(1) Sensitive Data Protection 敏感資料保護

偵測到的敏感資料，包含個人身份資訊或信用卡號碼等，會呈現在 Risk Overview 或 Findings。

(2) Google Cloud Armor

偵測到攻擊事件，或是流量觸發到安全規則，例如流量是從封鎖的 IP 或國家進來。

(3) Anomaly Detection 異常檢測

異常檢測是內建的功能，它能夠自動偵測 GCP 專案或虛擬機器中的安全異常，例如憑證洩漏。

要注意如果你是在專案層級啟用 SCC 的話，就不支援這個功能，要在機構層級啟用才有。

(4) Policy Controller 政策控制器

Policy Controller 可以幫助你確保你的 GKE 和 運行的應用程式是安全且合規的。

它可以設置一些規則，就像是護欄一樣，讓你的系統不會違反規則。

而這些規則可以幫助你遵守最佳實務 Best Practice、保證安全性，並且符合各種規定。

它是基於一個叫做 Open Policy Agent Gatekeeper 的開源專案，但是已經完全整合到 GCP 中了。

它有一個內建的儀表板，讓你可以很容易地看到系統的狀態。

它還提供了很多現成的 Policy，例如 CIS GKE Benchmark v1.5、

NIST SP 800-190 和 PCI-DSS v4.0 等等，你可以直接使用。

如果現有的 Policy 不夠用，你還可以自己寫新的 Policy。

不過要注意，你需要有 Google Kubernetes Engine (GKE) Enterprise 版本的才能使用。

6.呈現 GKE Security Posture Dashboard (安全態勢儀表板) 發現的威脅

GKE Security Posture Dashboard 能自動檢查安全漏洞，

用圖表讓你一目了然，查看 GKE 目前是否有設定錯誤、

容器作業系統和程式語言套件的漏洞等等，然後告訴你該怎麼改進。

而 SCC 整合此功能，可以把相關的漏洞呈現在 Findings 中。

7.整合 BigQuery，能夠把發現的威脅匯出到 BigQuery 執行進一步的分析。

8.整合 Forseti Security

這是 GCP 開源的工具組，它可以收集所謂的資產 (Asset) 清單，產生合規性報告，

並且和 SIEM (Security Information and Event Management) 整合，

可以將掃描結果發送到 SCC，並且 Forseti 生成的警報 (Notification) 也可以被轉發到 SCC，

讓你可以從 SCC 看到兩邊的資訊。

9.Sensitive Actions Service 敏感操作服務

Sensitive Actions Service 也是內建就會執行的服務，可以偵測 GCP 環境中，

什麼時候執行那些會對企業造成傷害的操作。

它會自動監視所有 Admin Activity Audit Log 中的敏感操作，

這種 Audit Log 永遠都是保持開啟的，因此不需要特別啟用或設定。

當 Sensitive Actions Service 偵測到 Google 帳戶執行的敏感操作時，

它會將結果寫入 SCC，和 Cloud Logging。

通常 Sensitive Actions Service 偵測到並不代表威脅，因為它們是合法的使用者基於合法目的而採取的行為，

所以這個服務無法確定這些動作是否合法，你需要調查這個結果才能判定它們是不是威脅。

10.如果 SCC 在機構層級啟用，你可以在 Org、Folder、Project Level 授權 SCC 的使用者角色。

11.Data Residency Controls 資料駐留控制

Data Residency Controls 是一種規定，它限制了 SCC 的資料只能存放和處理在特定的地方。

包含 Findings (發現到的威脅)、Mute Rules 靜音規則 (用來忽略不重要訊息的設定)、

Continuous Exports (威脅資訊匯出) 和 BigQuery Export。

這些資料只能存放在 SCC 支援的幾個特定區域裡，這些區域其實不是一個單一地點，

而是分佈在幾個相鄰國家或地區的資料中心。

這是為了遵守一些國家或地區的法規，確保敏感資料不會被存放在不允許的地方。

三、Premium 版本功能介紹

1. Attack Path Simulations 攻擊路徑模擬

SCC 會針對 GCP 環境進行攻擊路徑模擬，以找出所有可能的攻擊路徑，並計算攻擊暴露分數。

首先它會根據你的 GCP 環境自動生成一個模型，以圖形方式呈現。

接下來開始模擬攻擊，最多每天運做 4 次 (每 6 小時 1 次)，

若組織規模增大，模擬時間會變成，但至少每天運行一次。

根據模擬攻擊的結果，會針對 GCP 資源和相關問題分配一個攻擊暴露分數，並視覺化潛在攻擊的路徑。

可以幫助企業發現安全漏洞，並採取相關措施來加強防禦。

2. 根據 Mandiant 的評估結果優先處理最重要的漏洞

Mandiant 會評估系統中的安全漏洞，並建議最需要先修復的問題。

你會在 SCC 中看到 「Top CVE findings」 區塊，依照漏洞被利用的機率和損害來排序。

你可以在 Findings 用 CVE 編號來查詢相關漏洞。

3.  事件威脅偵測 Event Threat Detection

Event Threat Detection 可以比對 Cloud Logging 裡的 Log 和 Google 所開發的已知的危害指標

(Indicators Of Compromise；簡稱 IoC)，比對完會提供發現到的威脅，

例如惡意軟體、加密貨幣挖礦和資料外洩，完整的威脅可以參考 Event Threat Detection rules。

如果你在 Organization Level 啟用 SCC，它也可以監控 Google Workspace 的 Log，

追蹤使用者登入網域的情況，還有在 GWS 管理控制台操作的記錄。

當偵測到威脅時，它會將結果寫入 SCC 和 Cloud Logging，

就代表你可以把 Log 匯出到其他地方，再做進一步的處理。
你也可以參考這篇文章，建立自訂的威脅偵測器。

4. 容器威脅偵測 Container Threat Detection

Container Threat Detection 會收集在一個容器裡面，核心和執行中的 bash 腳本的底層行為。

當系統偵測到可疑事件時，首先它把事件資訊和容器的身份，透過 DaemonSet 程式傳給偵測服務來分析。

只要你開啟此功能，系統就會自動設定好收集事件資料。

偵測服務會分析這些事件，判斷是否有可疑的跡象。

對於執行的 bash 腳本，系統還會用自然語言處理 (NLP) 的方法來分析內容，看看有沒有惡意程式碼。

如果偵測服務發現了可疑事件，就會在 SCC 記錄一筆 Finding，你也可以選擇把記錄傳到 Cloud Logging。

5. 政策智慧 Policy Intelligence

很多大企業在 GCP 上會設定大量政策來管理資源的存取，政策智慧可以幫你了解和管理政策，

讓你可以改善安全性的設定。你可以分析存取權限例如：

1. 誰可以使用這個 Service Accont？

2. 某個使用者，在 BigQuery 的某個 Dataset，有哪些角色和權限？

3. 某個使用者，可以讀取哪些 Dataset？

另外它也可以分析機構政策 (目前為預覽版本)，你可以用來建立查詢語法，設定一些條件，

來找到你想要了解的政策，例如你想知道你的組織中有哪些政策會限制虛擬機器建立，

你可以建立一個查詢語法，來查找所有符合這個條件的政策，無論是 Google 預設的還是你的組織自己設定的。

另外它還能解決存取上的問題，就像是一個偵探，可以幫你查到為什麼某人可以或不可以存取某個資源。

你只要告訴它「誰」要對「什麼服務」進行「讀取或修改」，

它就會告訴你「他」能不能做到、為什麼、是由哪些規則造成的。

幫助你快速了解問題，並且提供你改善的建議。

6. 查詢 GCP 上的資源

雲端資產清單 (Cloud Asset Inventory) 可以讓你管理和追蹤 GCP 所有資源，還能保存 35 天的歷史記錄。

而在 SCC 中，你不需要把資料匯出到 BigQuery，就可以直接下語法來查詢。

7. 虛擬機器威脅偵測 Virtual Machine Threat Detection 

Virtual Machine Threat Detection 主要是用來監測虛擬機裡面是不是有惡意的程式在運作，

就像是有個警衛在外面觀察你的主機，但不會打擾主機運作。

它會定期檢查以下三種威脅：

(1) 挖礦軟體

分析在虛擬機上運行的軟體資訊，包括應用程式名稱、每個程序的 CPU 使用率、

記憶體分頁的雜湊值 (Hash Value)、CPU 硬體效能計數器，以及已執行機器代碼的資訊。

它會比對這些資訊是否感覺像是在挖礦，如果找到符合的，

它會判定與偵測到的特徵相關的程序，並在發現中包含該程序的資訊。

(2) 核心級別的惡意程式

檢查 VM 的作業系統，找到記憶體中的核程式碼、唯讀資料和其他核心資料結構，

使用核心原本的雜湊值來比對，確認它們是否被篡改。

(3) 惡意軟體

首先針對主機建立短期 Clone，然後掃描這些 Clone，過程中不會影響主機運作，

接著分析主機上可執行的檔案，看看是否有文件符合已知的惡意軟體特徵。

如果有任何發現了，會生成報告告訴你該文件的資訊和檢測到的惡意軟體特徵。

8. Security Health Analytics

除了 Standard 提到的功能，還包含了：

(1) 對於 Security Health Analytics 所有的偵測器，進行定期的掃描。

(2) 依照業界公認的標準，檢查目前環境是否符合這些標準。

(3) 合規性監控，系統會檢查你是否遵守重要的規則。

(4) 自訂模組支援，你可以建立自己的偵測器。

在 SCC 的 Compliance View，可以看到所有各種產業規範的合規程度，

你也可以將檢查結果匯出，做為有公信力的合規報告。
關於支援的安全標準清單，可以查詢這份文件。

9. Web Security Scanner 

除了包含所有 SCC Standard 版本的功能之外，還有支援 OWASP Top 10 的偵測器，

注意 Top 10 中的 A09 是關於系統如何記錄和監控潛在的安全問題，不針對特定漏洞偵測，因此不列入偵測範圍。

10. 安全態勢服務 Security Posture Service

Security Posture Service 可以幫你設定、檢查和監控 GCP 的安全狀況，

是否符合公司的標準，如果有偏離就會提醒你，這樣可以減少被駭客攻擊的風險。

你可以在開始使用 GCP 之前，就先設好安全規則，幫你持續檢查有沒有人更改了安全設定。

它也提供很多安全態勢範本，從基本的安全設定，到國際標準例如 NIST、ISO 27001 或 PCI DSS 的範本都有，

讓你可以直接套用，不用自己設定，非常方便。

11. IaC 驗證功能

基礎設施即代碼 (Infrastructure As Code) 驗證，讓你可以檢查你寫的 IaC 是否符合公司的規定和安全標準，

就是確保不會有安全漏洞或違反公司政策。

它主要可以檢查 Organization Policy 和 Security Health Analytics 偵測器，

在部署各種雲端資源之前，就先檢查出來，然後修正。

而且它現在已經支援 Terraform 的計劃檔案，你可以用 gcloud 指令來驗證，

也可以把驗證過程整合到 Cloud Build、Jenkins 或 GitHub Actions 這些開發工具中。

12. VM Manager 漏洞報告

如果你在 GCP 有啟用 VM Manager，並且在 VM 上安裝 OS Config Agent，

系統會自動掃描並比對漏洞資料庫和已知問題的軟體清單，

一旦發現某個軟體在已知問題清單上，就會生成一份報告，

而這這份報告會寫到 SCC Findings 中。

四、Enterprise 版本

雖然 SCC 的 Standard 和 Premium 版本已經很有用，但還不夠。

這些功能就像是一個個獨立的工具，沒有很好地整合在一起工作。

而 SCC Enterprise 打破分隔的資安工具、團隊和數據孤島，

把雲端的安全性，和整體企業的安全性連接在一起，

除了使用 Google 自己的資安技術，還結合 Mandiant 的專業知識，

可以幫公司把原本分散的安全工具、團隊和資料整合起來，更快地發現重要的安全問題，

也能讓公司更容易管理多個雲端系統的安全性。

除了 Standard 和 Premium 版本提供的功能，再加上以下功能：

1. 危險組合 (Toxic Combination) 偵測

危險 (或稱毒性) 組合指的是，是一堆安全漏洞湊在一起，變成了一條讓駭客可能入侵的路徑，

讓他們有機會進入你的資料或系統。

這些安全漏洞可能是你設定錯誤，或是某個軟體本身就有問題。

它們各自可能不太嚴重，但是幾個湊在一起的話，就變得很危險了。

SCC 有所謂的風險引擎 (Risk Engine) 系統會幫你檢查這些危險組合，

它會模擬駭客的入侵路徑，看看哪裡有問題。

找到問題後，它會發出警報，告訴你這個「危險組合」有多危險，

甚至畫成圖讓你了解駭客是如何入侵進來的。

2. 多雲支援

你可以把 SCC 連接到其他雲端供應商 (例如 AWS)，用來偵測那裡的威脅、漏洞和錯誤設定。

此外，你也可以透過攻擊暴露分數和攻擊路徑，來評估他們遭受攻擊的風險。

3. SIEM (Security Information and Event Management)

由 Google SecOps (Google Security Operations；舊稱 Chronicle) 提供支援，

它可以幫企業收集、分析和搜尋大量的安全和網路資料，像是一個厲害的安全管家。

主要功能包含：

(1) 收集各種安全資料

不管是從公司內部網路、其他安全系統，或是甚至 Office 365、Azure AD 的服務，它都能收集到資料。

(2) 分析資料

你可以用一個簡單的網頁來分析安全資料，很多功能還可以用程式來操作，

讓你在看到可能的威脅時，能夠弄清楚這是什麼、它在做什麼、重要程度和該如何處理。

(3) 搜尋功能

你可以很方便地查看過去幾個月甚至更久的安全資料，例如你想知道公司裡誰訪問過某個網站，

或者某台電腦有沒有被駭，都可以很快查到。

(4) 自動偵測

你可以設定一些規則，讓它自動幫你找出可能的安全問題，然後通知你。

(5) 從各種視角 (View) 看問題

比如從資產、IP 位址、網域名稱或使用者等角度，幫你更全面地了解情況。

(6) 整合 VirusTotal

如果你想進一步查某個可疑的東西，還可以直接連到 VirusTotal 去查。

4. SOAR (Security Orchestration, Automation and Response)

Google SOAR 原名為 Siemplify，是以色列的資安公司，

在 2022 年被 Google 買下，整合到 Google SecOps 的功能當中，

能夠幫助企業能夠即時偵測、調查和回應安全威脅，

並整合 Google 的機器學習功能來自動化和簡化資安的工作流程。

SOAR 從各種來源收集資料，例如網路設備、端點 Agent 和威脅情報來源，

使用這些資料來識別潛在的安全事件並啟動因應的操作，

並且與 SIEM、威脅情報平台和漏洞掃描器整合，提供全面的資安解決方案。

SOAR 提供直覺的使用者介面，讓你可以調查安全事件、建立工作流程並自動執行回應操作，而不需要寫程式。

也因為自動回應的功能，減少偵測和回應安全威脅所需花費的時間，進而降低資料外洩的風險。

5. CIEM (Cloud Infrastructure Entitlement Management)

CIEM 可以幫你管理誰能用什麼資源，重點是它可以跨不同的公有雲 (AWS 和 Azure)，

它還可以幫你找出設定錯誤的地方，避免造成安全漏洞，詳細功能包含：

(1) 偵測 GCP 和 AWS 上的權限設定中，疑似錯誤的地方。

(2) IAM recommender 可以告訴你每個用戶或應用程式被授予什麼權限，包含使用 Azure ID 和 Otka 登入的用戶。

(3) 教你修正錯誤的設定，例如把多餘的權限收回。

(4) 幫你管理每個 Case，透過 SecOps Console 來追蹤修復的進度。

因為很多安全問題都是因為權限設定錯誤造成的，

例如有人有太多權限、有人的帳號長期沒在使用但還留著權限，

或是沒有定期更換 Service Account Key，或是沒有多因素驗證 (MFA)。

CIEM 會發現這些問題，然後呈現在 Risk Overview 頁面上，

讓你看到具體的問題，以及解決方法。

6. 整合 Mandiant Hunt

Mandiant Hunt 可以提供隨需的專家知識，成為內部安全運營團隊的延伸，

它讓數百名精英等級的分析師和研究人員隨時待命，主動尋找那些逃避傳統機制的隱藏威脅。

7. 案例管理和劇本功能

能夠對漏洞、錯誤配置和威脅進行分析並將其分配給案例 (Case)，讓分析師進行調查，

並附加到開箱即用的手冊 (Playbook) 中以進行預防和補救。

8. 整合 AWS 記錄

除了 GCP 本身的 Log，也能收集 AWS CloudTrail audit logs、Syslog、Auth logs 和 GuardDuty events。

9. 整合 Google Cloud Marketplace 上的工具和服務

例如 Siemplify、VirusTotal 和 Jira 等等。

10. Gemini 支援

Google SecOps 的 Gemini 支援自然語言搜尋和案例調查的摘要資訊。

11. DSPM (Data security posture management；資料安全態勢管理)

能夠查找、分類和管理雲端環境中的敏感數據。

12. AI 工作負載威脅偵測 (AI Workload Findings)

當你在 Vertex AI 開發 AI 的應用時，能夠持續監控 Vertex AI 的環境設定是否違反安全性策略。包含：

(1) Vertex AI Workbench Notebook 允許外部 IP 存取

(2) Workbench 主機允許檔案下載

(3) Vertex AI 主機的存取權限更改

13. 開發階段安全 (Shift-Left)

此功能包括 Assured Open Source Software 的進階版，這個服務可以幫你提高程式碼的安全性，

因為它讓你用的是 Google 自己的開發團隊在用的開源套件。

你可以找到熱門的 Java 和 Python套件，包含 TensorFlow、Pandas 和 Scikit-learn 等。

並且下載時都帶有 Google 的認證，確認都是從可信任的來源取得的，

甚至帶有 Google 的數位簽名，確認套件沒有被人動過手腳。

這裡總結 Enterprise 版本的獨特優勢

1.多雲保護

除了 GCP，也保護 AWS 和 Azure，對大企業而言，簡化多雲的資安管控。

2.AI 驅動

在生成式 AI 的輔助之下，讓不管是專家還是新手都能更容易地處理雲安全問題。

從發現問題、理解複雜的安全問題，到調查和引導修復，AI 技術都能幫上忙。 

3.威脅檢測和回應

(1) 數字孿生模型，理解雲環境並模擬攻擊者行為。

(2) 危險組合檢測，動態發現可能導致高風險暴露的危險組合

(3) Mandiant Hunt，可以提供專家知識，主動尋找威脅。

4.全面雲原生應用保護平台(CNAPP)

作為一個完整的 CNAPP，SCC Enterprise 版本提供了全面的安全功能，

包括檢測、調查、案例管理、態勢管理等。

它還包括 SIEM、SOAR 和 CIEM 功能，以及強大的合規性支持，

確保了企業的雲端環境在各個方面都得到了充分的保護。

五、Security Command Center 加密貨幣挖礦防護計畫

除了上述三個版本的主要功能，Google 還推出《加密貨幣挖礦防護計畫 Cryptomining Protection Program》，

如果你的 VM 被攻擊，而 Google 未偵測出來而通知你，

則因為攻擊產生的費用，可以向 Google 申請上限為一百萬美元的抵免額。

當然這是有一些條件的：

1. SCC 為 Premium 或 Enterprise 版本

2. VM 是 Linux 的作業系統

3. 要啟用 VMTD (VM Thread Detection) 和 ETD (Event Threat Detection) 功能

4. 要遵守 Security Command Center 加密貨幣挖礦偵測最佳做法

5. 更新及維護安全性重要聯絡人

如果不確定是否符合，可以執行驗證指令碼來確認看看，這部分還蠻貼心的。

但還是提醒大家，Google 並不是直接給你現金，

而是給你「未來使用 Compute Engine 的費用抵免」，不是所有 GCP 各項資源都抵免。

而且抵免額在 12 個月後失效，所以要抓緊時間善用。

無論如何，這部分 Google 是要強調他們超強的資安能力。

你可以在 GCP 安心地使用 VM，不用擔心被駭客入侵拿來挖礦，

就算被入侵也能馬上偵測到然後通知你，而非要你為了抵免額，故意放鬆戒備導致駭客入侵。

六、Security Command Center 不同版本的價格說明

1. SCC Standard 版本價格

免費，其中 Data Security Findings 是屬於敏感資料保護的功能，是另外計費的，不在免費範圍。

2. SCC Premium 版本價格

這裡有分成 Project Level 和 Organization Level 的不同價格，整理如下：

3. SCC Enterprise 版本價格

這個版本的會價格取決於資產的數量，主要重點如下：

(1) 訂閱最少一年。

(2) 每個資產價格是 199 到 309 美元之間，取決於你的資產數量和訂閱長度。

我建議你就當做每個資產都是 309 美元/年，除非你的資產數量夠大，或是訂閱年份夠長。

(3) 你可以買不同數量的資產，可以隨時用，但年底沒用完的話，不能留到下一年。 

(4) 訂閱價格 = 資產數量 x 每個資產的價格，當月費用在下個月付費。

(5) 如果使用超過原本購買的數量，就要付超用費。

(6) 不管你購買多少資產，只要是符合的資源，都會計費。

(7) 最低費用是一年 15,000 美元。

此還可能還有其他間接或衍生的費用，完整的費用說明可以參考這份文件，

建議還是直接聯絡代理商，與你詳談需求後，得更較精準的報價。

七、Security Command Center 不同版本的啟用方式

你可以在 Project Level 或 Org Level 啟用，為了較全面的防護，建立還是在 Org Level 啟用。

首先在 Console 上將環境切換到 Org Level，點擊 Security => Risk Management 會看到首次啟用的畫面，

這時點擊 GET SECURITY COMMAND CENTER

接下來的步驟一，會給你三個版本的比較，

Standard 和 Premium 版本可以直接選擇，而 Enterprise 需要點擊 Contact us 聯絡 Google，

或是聯絡代理商來協助啟用。

步驟二會看先到它詢問你是否要啟用 Data Residency，

它會將 SCC 發現到的威脅儲存在你指定的地方，選項包含全球、美國和歐盟。 

要注意的是，如果沒啟用，之後就沒辦法回來啟用了，它預設儲存位置就是全球。

再來如果你啟用了，以後也無法停用，或變更儲存位置。

再往下看，有些 Premium 功能已經預設啟用，

你可以視需求決定各個功能的開關設定。

第三步會看到，SCC 需要你主動授權，讓它可以去掃描各項資源，

除非你對權限非常熟悉，不然就依照系統的建議，自動授權即可。

授權完成會看到相關資訊，沒問題再按 NEXT。

第四步就是告訴你設定完成，按下 Finish 即可。

這時候會進入 Risk Overview 的畫面，

畫面往下捲，你會看到還需要啟動敏感資料保護的功能，

它不屬於 SCC 的功能，必須額外啟用，

我們先點擊 “ENABLE SENSITIVE DATA PROTECTION” 按鈕。

接著它又會再彈出一個視窗，

你要選擇手上其中一個的專案，讓 Service Agent Container 可以運作，

並且授予相關權限，讓它可以收集資料。

而下方的 Enable Subscription 指的是 Data Profiles 的 Discovery 功能，

能夠識別高風險資料都存在哪裡，告訴你哪些資料需要特別保護。

這不屬於 SCC 本身的功能，但也能夠把檢查到的敏感資料總結到 Risk Management。

預設就是 Consumption Mode，代表用多少算多少，

不管是 BigQuery、Cloud SQL、Cloud Storage 甚至 Amazon S3，每 GB 都是 0.03 美金。

如果你選用 Subscription Mode，則是每月 2500 美金，

除非你公司有超過 10000 個 Table 再來考慮，詳情可參考這份文件。

接下來再針對你想要掃描的服務啟用 Discovery，例如我們只啟用 BigQuery。

當你啟用完成再按下一步，它會跳轉到 Sensitive Data Protection 的畫面，

代表有啟用的服務，它才會幫你檢查敏感資料，沒啟用就檢查不到。

如下圖 BigQuery 是有啟用 Discovery 的，Cloud SQL 和 Cloud Storage 則沒有。

再回到 SCC 的 Risk Overview 就能看到 Data Security Findings

八、Security Command Center 版本比較整理

以下將 Security Command Center 三個版本當中，針對重要功能的差異整理如下表：

由此可知，SCC Standard 不同版本提供的差異很大，

如果你是新創或中小企業，選擇 Standard 版本即可做到基本的資安防護；

如果公司已經有些規模，並且重視資訊安全和合規，可以考慮 Premium 版本；

如果已經是大企業，尤其是在多個公有雲，甚至跨國部署重要的系統，

重視商譽和客戶，並且具備足夠預算的話，務必考慮 Enterprise 版本。

如果需要完整的評估，可向合適的 GCP 代理商諮詢。

本文同時刊登於思想科技官網部落格文章 【東東老師 X 思想科技】 Security Command Center 不同版本比較及啟用方式

The post Security Command Center 是什麼？三個版本差異、價格和啟用方式介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師.

首先從帳號安全開始，讓你還沒登入 GCP，帳號就已經受到保護； 

接著開始觸碰到 GCP 的最前端，就有 DDoS 防禦、WAF 和入侵偵測功能； 

在進入應用程式之前，會有嚴格的登入驗證和授權機制；

若你的應用程式在 VPC 網路內，流量就會受到防火牆的控管，

可疑封包也能納入分析； 

應用程式不論是在 VM 或 Container，都可以對它們弱點掃瞄； 

資料存取受到層層管制，確保不被輕易入侵、破解或外洩；

整體環境還有其他獨立運作的監控機制和政策，

讓你建立重重關卡，滴水不漏。

本文整理目前最常用並且「可以立即使用」的資安功能，

從外部一直到 GCP 最深處，逐步介紹各個功能，

讓你可以建立每一層的防禦工事。

一、帳號安全

(一) Cloud Identity

使用 GCP 之前，你至少要使用公司的帳號，

而不是使用個人 Gmail，

如果帳號有任何問題，例如無法登入或被駭，

至少公司管理員還可以幫你處理，不會求助無門。

Google Workspace 就是公司專用的 Google 帳號，

但是它還有 Gmail、日曆、雲端硬碟等等相關功能，

不一定每家公司要先用 Google Workspace 才能用 GCP。

Google 有把帳號管理的功能抽出來，就是所謂的 Cloud Identity，

即使公司使用 M365 或其他企業信箱，

你可以建立公司的 Google 帳號，

像這樣的格式：aaron@dongdong.com，依然可登入 GCP。

Google 的帳號安全機制很多，像是最基本的「兩步驟驗證」功能，

公司可以先「邀請」使用者自行啟用，

如果使用者不配合，管理員可以「強制實施」，

這樣一來，已事先啟用兩步驟驗證的使用者，可以正常登入 GCP。

未啟用的使用者，就完全無法登入 GCP。

確保使用者帳號密碼被盜，駭客還是拿不到驗證碼。

(二) Titan Security Key 安全金鑰

針對非常重要的人員帳號，例如系統管理員或高階主管，

還可以使用 Titan Security Key，

長得有點像隨身碟，當你註冊金鑰到帳號中，

以後兩步驟驗證的第二步驟，就可以插入金鑰來驗證，

只要駭客沒有金鑰，就無法登入你的 Google 帳戶，

就像一把真正的鑰匙在你手上，讓安全性大為提高。

二、攻擊防禦

(一) Load Balancer 負載平衡器

每分每秒，全世界有 60% 的網路流量會經過 Google，

Google 也隨時在監控網路的各種攻擊流量，

針對高流量的 DDoS 攻擊，

Google 的 Load Balancer 就有內建防禦功能。

像是知名遊戲廠商艾玩天地，也曾飽受 DDoS 之苦，

後來把遊戲部署在 Compute Engine 上，前端採用 Load Balancer，

就直接過濾掉所有 DDoS 的攻擊流量，提高玩家的遊戲體驗。

另外 HTTP(S) Load Balancer 也有提供免費且自動更新的 SSL 憑證，

幫你的應用程式在傳輸過程中進行 TLS 加密，

降低資料被竊取的風險。 

(二) Cloud Armor

像艾玩天地碰到的是大流量攻擊，Google 容易偵測得到，

但也有很多中小企業，網站流量不大，

只要稍微碰到小幅度的攻擊，就足以讓整個網站癱瘓掉。

因此可以再加上 Cloud Armor，是 DDoS 防禦和 WAF 功能的結合體。

在 Standard 方案底下，就已經內建基本的防禦功能，

不需要再額外設定。

你也可以再自訂各種防禦規則，

最基本的規則例如來源 IP 黑白名單、來源國家、網路封包標頭 (Header) 過濾，

以及有現成語法可用的 SQL Injection、XSS 語法，

還有 OWASP (Open Web Application Security Project) 資安組織公佈的10大威脅，

都可以直接複製貼上使用現成的語法。

如果你確認主機平常流量不大，想提前預防突然升高的流量，

可以設定 Throttle (節流) 或 Rate base ban (暫時停止服務)，

讓流量控制在一定的範圍之下。

Cloud Armor 還有 Enterprise 版，

有特別提供自適性防護 (Adaptive Protection) 的功能，

它會建立機器學習的模型，來偵測異常活動，

還能自己產生 WAF 規則來阻止潛在的攻擊。 

如果企業對於 DDoS 有極大的需求，

可以在已經購買 Premium Support 的情況下，

加購 Cloud Armor Enterprise，

當攻擊發生，可以立即開立 DDoS 支援案件，

讓 Google 專家立即協助阻斷。

另外，攻擊時所輸出的流量費用，

可以獲得未來 GCP 使用的抵免額度。

(三) Cloud IDS 入侵偵測系統 (Intrusion Detection System)

Cloud IDS 可以偵測到入侵、惡意軟體、C&C 命令和控制，

它會建立一個對等網路 (Peered Network)，

然後將原本網路中的流量映射到對等網路，

再利用業界知名的 Palo Alto 公司的技術來檢測威脅。

再加上它是雲原生的，而不是像地端設備的複雜功能，

設定很簡單，只要點幾下滑鼠就能部署該功能。

不過要注意的是，Cloud IDS 只檢查進入 VM 或 GKE Pod 的流量，

其他服務還沒納入檢測範圍。

三、登入驗證和授權

(一) Cloud IAM (Identity and Access Management)

當我們登入 GCP 時，系統就會立即檢察你的身份，

以及你是否有足夠權限進入某個功能。

我們也是在這裡統一管理所有人員和服務帳戶 (Service Account) 的權限角色，

比較特別的是，權限可以設定「條件」，

讓使用者只能在「特定時間」有權限，

例如星期幾之前或之後、一天當中幾點之前或之後，

或是存取權的有效期限。

現在 IAM 還能主動提供權限檢查，

告訴你哪一個帳號似乎用了太大的權限，

提醒你要調整，減少帳號被駭之後被破壞的範圍。

(二) Cloud IAP (Identity-Aware Proxy)

Cloud IAP 是一個非常神奇的功能，

可以讓你非常安全地存取 GCP 的資源，

包含 SSH 到 Compute Engine 的主機、遠端連線到 Windows、

和透過 Load Balancer 存取網頁應用程式。

以往都是透過 VPN 來連線，但是 VPN 只會管你從哪裡來，

並不會驗證你的身份，

但是 Cloud IAP 會驗證你的身份，並且檢查你有沒有存取權限，

才決定放行，所以在安全性上提高很多。

此外，Cloud IAP 幾年前剛推出時，設定比較麻煩，

需要啟用 API，建立連線通道，授權使用者等等。

但是現在除了原本的設定方式，也推出自動使用 IAP 的功能，

以前如果要直接點擊 SSH 按鈕連線到你的主機，

必須要讓防火牆規則，開放所有的 IP 來源的 Port 22，

代表不是只有你，全世界的駭客都可以連到你的主機 Port 22。

如果要安全地連，必須自己做 SSH Key，從本機 SSH 來連，

然後設定防火牆只允許自家 IP，並且擋掉其他 IP，有點麻煩。

而且如果 Key 被盜，任何持有 Key 的人都可以連進你的主機，

你還不知道是誰進來搞破壞。

但是現在 Cloud IAP 讓你不用再做自己的 SSH Key了，

你只要在防火牆允許 Cloud IAP 的 IP Range：35.235.240.0/20，

不用 Allow 全世界的 IP，也不用 Allow 自家的 IP，

只要 Allow GCP 的內部網段即可，實在是安全又方便。

四、VPC 網路的安全機制

當我們身份驗證成功了，

我們的流量就會進入到 VPC (Virtual Pricate Cloud)，

也就是 GCP 的內部網路，這時就會受到防火牆的管控。

(一) 防火牆

1.防火牆規則 Firewall Rules

這是 GCP 最基本也最重要的安全機制，是以一個專案內的 VPC 為管理範圍，

方向包含 Ingress (進入 VM 的流量) 和 Egress (離開 VM 的流量)，

動作就包含允許 (Allow) 和拒絕 (Deny) 兩種，

而目標 Target 指的是要套用規則的 VM 有哪些，

再把來源或目的地的 IP 或標籤 Tag 設定好，

以及要放行或禁止的通訊協定和 Port，最後就是設定好優先順序，

數字越小越優先。

其中最特別的是「標籤式管理」機制，

你可以為每一台 VM 加上特定的標籤 (Network Tag)，

同時也給防火牆規則設定相對應的標籤，

這樣就可以讓你一次將規則套用到多台主機，

省去一台一台設定 VM 防火牆的麻煩。

如下圖 Rule 1 的Target Tag 設定 “Web”，只會套用到右邊第一台 VM。

 Rule 2 的Target Tag 設定 “DB”，則會套用到右邊第二、三台 VM。

2.防火牆政策

最近 Google 又新增了防火牆政策，它的管理範圍更大，

從整個 Organization 開始，往下到資料夾、專案，

中間經過防火牆規則，

再到 Global VPC、Region VPC，都可以設定防火牆政策。

除了原本的允許和拒絕之外，

還多了 Go to next (給下一層決定) 和 L7 (做第七層檢查)。

但要注意的是，設定層級很多，規則複雜，容易混淆。

建議先以防火牆規則為主，管理較為單純，

等到熟悉整體運作，再逐步增加各個層級的防火牆政策。

(二) Packet Mirroring 封包鏡像

Packet Mirroring 可以讓你複製 VM 或其他資源的網路封包，

並將其鏡像到指定的目的地，

如其他虛擬機器、Cloud Security Command Center 或第三方設備。

這對於網路監控、安全檢測、故障排除及合規性檢查等場景非常有用，

它可以執行網路流量監控和分析，識別異常流量或攻擊行為，

也可以送到故障排除工具，協助診斷網路問題或效能瓶頸。

但要注意，它是真的把原有的流量「一模一樣複製出來」，

所以流量費用是直接變成兩倍，

因此要看是否有重大事件需要檢查封包或排除故障，

針對關鍵部分再複製封包，確保費用在控制範圍之內。

五、應用程式的資安功能

(一) 針對虛擬機器 – Confidential VM

以往 GCP 都會強調資料在「儲存中」和「傳輸中」都會加密，

而近期推出 的 Confidential VM，是能夠達到資料在「處理中」也能加密。

就是主打「以硬體為基礎的記憶體加密」機制，

來確保你的資料和應用程式無法被竊取或竄改，

加密的 Key 是在專屬的硬體上產生，Hypervisor (虛擬化程式) 也無法讀取。

你也可以驗證 VM 的身份和狀態，確保關鍵的元件沒有被竄改。

不過要注意的是，它是有限定機器類型的，

例如 N2D、C2D 和 C3 Standard 的主機才有支援，

當然費用會稍微高一點，這就取決於你公司的資安或合規需求來選用，

但好處是，整個使用的過程和一般的主機沒有差別，

只要在開機過程中勾選 “Confidential VM service” 就可以了，

也是非常方便的功能。

(二) 針對容器 Container 的資安服務

1. Image 弱點掃瞄功能 – Vulnerability Scanning

如果要部署應用程式在容器平台，

包含 Cloud Run 或 Google Kubernetes Engine (簡稱 GKE)，

就要先上傳容器映像檔到 Container Registry 或 Artifact Registry，

不管是哪一種，都可以使用弱點掃瞄功能，

只要在 Console 上啟用之後，

你接下來 Push 上傳的每一個 Image，都會自動掃瞄。

(但是舊的不會掃瞄喔)

掃瞄完成之後，它會列給你一個非常完整的弱點清單，

並且依照嚴重程度和弱點分數做一個「排行榜」，

以及建議的修護方式和相關外部連結，

讓你可以知道有哪些弱點需要修補，算是非常貼心的功能。

2. Image 簽署功能 – 二進位授權 Binary Authorization 

軟體開發過程中，常常推送各種 Image 到 GCP，

但有些 Image 尚未開發完成，只是先推送出來測試看看，

因此可能會有資安漏洞，不能部署到正式環境。

為了防止 Image 不被意外部署出來，

GCP 設計了二進位授權 Binary Authorization 的機制，

讓你的 Image 在部署到 Cloud Run 或 GKE 之前，

強制驗證它是否經過簽名，

就像是找個人幫你背書，證明這個 Image 很安全，

如果 Image 未經簽名，一律拒絕部署，

而且可以針對多個步驟例如：單元測試、原始碼分析和漏洞分析等等，

都設定簽名的關卡，算是非常嚴格的安全機制。

(三) 應用程式掃瞄 – Web Security Scanner

GCP 對於部署應用程式的平台，

包含 App Engine、Compute Engine、GKE，皆提供弱點掃瞄，

它會爬行 (Crawling) 你的網站，從首頁開始延伸到的相關連結，

執行各種輸入和事件處理，藉此偵測應用程式的弱點。

你可以執行定期的掃瞄排程，只要提供 IP 或網址就可以開始掃瞄，

也可以自訂多個參數來做更客製化的掃瞄，讓掃瞄的廣度和深度更為全面。

但是要注意，必須是專案內的應用程式才能掃瞄，

以及要用公開的 IP 或網址才能掃瞄得到。

六、資料存取

(一) Secret Manager

我們的應用程式時常需要和 Google 的 API，或是後端主機、資料庫或其他儲存的服務互動，

這時需要一些連線資訊、環境變數、設定檔或憑證，

如果我們直接寫在程式碼中，容易有被竊取的風險，

我們可以將它們寫在 Secret Manager 當中，讓有權限的 Service Account 去讀取，

可以減少重要資訊外洩的機率。

而且它是一個代管的服務，我們可以很方便的把資訊建立成 Secret，

每次更新都會立即生效，在管理上非常方便。

(二) Key Management Service

我們使用的 Disk、Cloud Storage、Cloud SQL、Filestore 和 BigQuery，

都已經內建了 Google 預設的加密機制。

如果我們想要有更高的加密等級，就可以使用 KMS。

KMS 是一個集中管理加密金鑰的地方，

也就是所謂的 CMEK (Customer Managed Encryption Keys) 模式。

你可以選擇各種加密演算法，也可以決定自動更換 Key 的頻率，

從 24 小時到 120 天都可以選擇。

除了軟體生成的 Key ，也有硬體模組生成的 Key，叫做 HSM (Hardware Security Module)，

軟體 Key 可達到 FIPS 140-2 Level 1，

而硬體 Key 更是達到 FIPS 140-2 Level 3，是很多金融機構合規需求的標準。

另外，你也可以不使用 KMS 產生的 Key，

可以直接從外部第三方送進 GCP 使用，

就是所謂的 EKM (External Key Management) Keys，

這裡的 Key 完全不會送到 GCP 裡面 (支援的廠商清單)。

如果不用第三方管理系統，

也可以直接使用所謂的 CSEK (Customer Supplied Encryption Keys) 模式，

直接從外部自己產生 Key，每次存取時指定 Key 的位置，

但要注意這種方法，Google 也不會儲存你的 Key，

自己務必要保管好，因為你沒有專屬的金鑰管理系統，

萬一 Key 不見了，是連 Google 都無法幫你還原資料的。

(三) Cloud DLP (Data Loss Prevention)

公司因為合規需求，或是避免內部人員看到不該看的敏感資料，

你可以呼叫 Cloud DLP 的 API，來幫你檢查資料中是否包含個資。

例如使用者傳訊息給客服人員，有時太直白地留下身份證字號或是手機號碼，

收到這種訊息反而提高公司觸法的風險，所以每次收到最好當下就檢查，

只要檢查到個資，就可以使用「遮罩」、「刪除」或「加密」來處理。

「加密」這個動作可以搭配 KMS 的 Key ，

來將資料加密成看不懂的樣子，只讓關鍵人員有權限解密該資料。

對於已經存在資料庫裡的資料，不確定是否含有個資，

也可以建立掃瞄工作，對整個資料庫或 Cloud Storage 進行完整掃瞄，

再針對掃瞄到的資料統一處理。

七、整體安全控制

(一) Cloud Logging

Cloud Logging 會收集整個 GCP 環境所有的 Log，

不管是 Project Level 還是 Organization Level 的 Log，

集中顯示在專屬的 Logs Explorer 中，並且分門別類，

依照時間排序，也可以使用語法查詢。

預設會記錄所有的管理員操作 (Admin Activity)，

例如「是誰開了一台大機器卻忘了關？」

和系統事件 (System Event)，例如「主機什麼時候發生異常，

Google 幫你重開機器？」。

如果你的 Web Server 想要收集 Log，

也可以安裝 OPs Agent 將應用程式的 Log 送到 Cloud Logging，

這樣如果主機當機進不去，

你也可以從 Cloud Logging 看到主機到底發生了什麼事。

如果你希望 Google 技術人員幫你 Troubleshooting 的時候也有記錄，

可以選用開啟 Access Transparency Log，

確認 Google 的人員連線到你 GCP 專案的記錄。

另外，大部分資料存取的 Audit Log 預設是不開啟的，

因為這種 Log 可能無時無刻都在發生，

資料量非常大，有需要再開，

例如要監控是否有不正常的存取行為時，可以開起來收集記錄，

很適合用來抓小偷，因為這裡的 Log 是無法刪除的。

你也可以因應法規需求，將 Log 設定更長的保存期限，

或是匯出到其他地方永久保存。

(二) Beyond Corp

Beyond Corp 是 GCP 的資安框架，主打「零信任」，

代表任何來源未經正常的驗證程序，都先視為「不信任」。

它包含前面提到的 Cloud IAP，和接下來這兩個重要功能：

1. Access Context Manager

這是用來設定所謂的「Access Level」存取層級，

用更白話的方式講，就是一種存取的條件或情境，

或是用戶端的屬性，

例如用戶是從哪一個 IP 或國家過來存取的，

而 Beyond Corp 的 Enterprise 版本還提供「裝置是否經過認證」。

而上述的各種條件，可以組合成不同的層級，

例如 “Basic” 指的是基層員工、”High” 代表高階主管，

也可以設定一個 “Office” 代表從公司的 IP 位址去連到 GCP 的人員。

2. VPC Service Control

當我們設定好「條件」之後，這裡就要來設定「動作」，

就是要「允許」還是「拒絕」存取「某個服務或資源」。

如上述我們設定一個 “Office” 的層級，裡面只設定辦公室的 IP 位址。

然後在這裡設定專案 “dong-dong-gcp-3” 裡所有服務都納入「保護」，

就代表符合 ”Office” 的人 (IP 在辦公室的人)，

都可以存取 “dong-dong-gcp-3” 專案所有的服務。

反過來說，不符合 ”Office” 的人 (IP 不在辦公室的人)，都無法存取，如下圖。

你可以看到，因為只有 “dong-dong-gcp-3” 被納入保護，

所以當我切換成 “dong-dong-gcp-2” 時，

該專案沒有納入保護，所以不管 IP 位址是否在辦公室，

都不會影響存取。

其實 Service Control 的使用範圍相關廣泛，

除了專案，也可以將專案中某個 VPC 網路納入保護，

還能定義服務邊界 (Service Peremeter)，讓邊界外的來源不能進來存取，或是不能把資料帶出邊界。

是除了防火牆之外，另一個獨立運作的存取控制功能。

(三) Cloud Security Command Center (簡稱 SCC)

它可以視為資安中心的角色，能夠隨時掃描整個 GCP 環境的資源，

將檢測結果集中顯示在統一的頁面上一目了然。

免費的標準版除了先前提到的 Web Security Scanner，

還包含以下服務：

1. Security Health Analytics

自動檢查資安漏洞和錯誤設定，例如 IAM 授權給外部人員、太過開放的防火牆規則等等。

2. Security Command Center errors

如果有任何設定錯誤的地方，導致 SCC 無法正常運作，它會產生錯誤訊息來提示你。

3. Continuous Exports

可以自動把新發現的檢查測果傳到 Pus/Sub，讓你可以整合資訊到其他應用上。

4. GKE security posture dashboard findings

可以查看 GKE 目前是否有設定錯誤的地方、容器作業系統和程式語言套件的漏洞等等。

5. 整合 Forseti Security

這是 GCP 開放源始碼的各種工具，可以和 SIEM (Security Information and Event Management) 整合。

6. Sensitive Actions Service

監控管理員的活動是否會傷害業務運作，再把結果寫到 SCC，再讓使用者確認該行為是否真的有害。

SCC 目前還有 Premium 和 Enterprise 版本，

提供更完善的功能，後續將再專門介紹三個版本的細節和差異。

(四) Organization Policies 機構政策

Org Policies 可以針對全公司所有的資源，統一控管存取的政策，

例如 VM 是否可以使用外部 IP、哪個專案的 Image 可以拿來建立 VM、

哪個專案不能建立 Service Account 或 Key、

哪個專案不能在瀏覽器使用 SSH 連線等等。

你可以在 Org 層級設定好，套用到底下所有的資料夾和專案，

你也可以在資料夾或專案層級覆寫 (Override)，

設定不一樣的政策，在管理上非常靈活。

最後整理本文提到的所有資安服務如下圖：

其中灰色字體為一般 GCP 服務，黑色字體為資安服務，

粗體代表不同層級或類別，

各個服務之間的關係用箭頭表示，但不代表嚴謹的架構邏輯，

僅為示意。

由此可知，GCP 的資安功能強大且完善，

讓你可以用好用滿，遠離威脅。

未來會再針對個別服務撰寫專門的文章來深入介紹，

讓各位可以立即上手。

本文同時刊登於思想科技官方網站的網誌文章：《【 東東老師 X 思想科技 】雲端的資訊安全防禦縱深，常用資安服務介紹》。

The post [GCP 教學] 雲端的資訊安全防禦縱深，常用 GCP 資安服務介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師.

通常必須要讓防火牆規則，開放所有的 IP 來源的 Port 22，

像這樣：Allow 0.0.0.0/0 Port 22

代表不是只有你，

全世界的駭客都可以連到你的主機 Port 22。

如果要安全地連，必須自己做 SSH Key，從本機 SSH 來連，

才可以設定防火牆只允許自家 IP，然後擋掉其他 IP，有點麻煩。

但是現在 GCP 改善了，你不用再做自己的 SSH Key了，

你可以只允許 Cloud IAP 的 IP Range 35.235.240.0/20，

不用 Allow 全世界的 IP，也不用 Allow 自家的 IP。

Cloud IAP 的技術原理可以直接看這篇，本文直接實作給你看。

以下是我新建一條防火牆，

只允許 Cloud IAP 的 IP 範圍：

你只要點擊 SSH 按鈕，就可以直接連線了。

連上之後，從 Linux 查看連線的來源 IP 為 35.235.244.82，果然是 Cloud IAP 的範圍。

也從防火牆 Log 來看，也是一樣。

以後再也不用自己做 SSH Key了，實在是非常方便呢！！

最後提醒一下，原本那條 default-allow-ssh 防火牆規則，記得要停用喔！不然駭客還是會找到你喔！

The post Cloud IAP 簡單介紹和實作, 防火牆不用全開，讓你安全又方便連線到虛擬機器 first appeared on 東東 GCP 教學 - GCP 實戰講師.

雲端的資訊安全威脅包含以下九大層面：

本文逐一說明相關的威脅和解決方法：

1.網路

這是大家最熟悉的，例如 DDoS 攻擊、駭客嘗試登入系統、網路釣魚等等。

在 GCP 上，最基本的就是防火牆規則要設定好，怎樣才算好？

該開放的有開放，該阻擋的有阻擋，不知道要不要開的一律阻擋。

如果有能力負擔，可以開啟防火牆 Log，定期分析 Log 當是否有異常流量。

至於對外的網站，可以使用 Cloud Armor，

它提供 Layer 3 (IP位址)、Layer 4(TCP Port)、Layer 7 (HTTP Header) 層面的防禦規則，

還有內建 OWASP 發布十大風險的防禦規則，

你也可以引用第三方工具 Fastly、Cloudflare、Imperva 的白名單來管控允許的 IP 位址。

2.驗證和授權

驗證 (Authentication)：你是誰？你是公司的人嗎？

授權 (Authorization)：你有權限進入這個系統嗎？

針對驗證的部分，務必要求使用者開啟2步驟驗證，

光是這一條已經可以防禦一半以上的威脅了，

因為只有帳號密碼的驗證方式，只要幾天甚至幾小時就會被駭客破解。

至於授權，要盡可能遵守最小權限原則，給予剛好需要的權限。

要做到其實非常困難，因為 GCP 的權限很細，

截至 2024/3/18，Owner 已經有9298個權限。

多數人為了便宜行事，大家都是 Project Owner，

如果有人帳號被駭，他同時在多個專案擁有 Owner 角色，

那就麻煩大了，如果駭客用他的帳號狂開機器，

一個專案可以好幾千台機器，一天就可以噴掉上百萬。

為什麼駭客要開機器，當然是挖比特幣，GPU 多香啊！
(挖擴在 GCP 是禁止的)

另一種情況是 Service Account Key 被駭客拿到，如果這個 Service Account 在 IAM 擁有能建立機器的角色，一樣是恭喜發財。

如果可以，在一家公司裡， 機構管理員最多2位，

每個專案的擁有者最好也是2位，不能太多，也不能只有1位。

如果有1位的帳號有問題，或是被駭，至少另1位還可以進去捕救。

有個非常特別的 Case，我曾經接到客戶求救，

說專案被離職的工程師帶走了，

可以跟 Google 發 Ticket 把權限拿回來嗎？

不行，Google 也不能干預客戶專案內的事情，

所以必須靠自己把專案權限管好。

3.應用程式

這部分很基本也很重要，沒有人希望自己用的應用程式有問題吧！

應用程式如果被駭或中毒，是非常危險的事。

其中最重要且有效的方法，也是管理好應用程式所使用的 Service Account，和它的 Key。

不要直接將 Key 寫在程式碼中，這樣太容易被駭客竊取了。

好一點的做法是將 Key 儲存為環境變數，讓 Key 不容易被找到。

或是使用 Workload Identity，讓外部的應用程式不用 Service Account Key 就可以存取 GCP 的服務。

4.資料加密

這又分成2種：

(1)資料加密不被駭客破解

在 GCP 上都有 Google 內建的加密機制，

所以如果有人真的拿走一顆硬碟，

是很難破解出裡面的內容的。

因為儲存在上面的資料，會先分成不同的塊(Chunk)，

然後再存到三個不同地方，你不會知道，

一個檔案到分別存在哪三個硬碟，

所以資料根本就不完整，更不用說把它還原回來。

如果你覺得 Google 預設的加密還不夠，

可以使用 Cloud KMS 來建立和管理加密金鑰，

還可以使用超高加密等級的 HSM (Hardware Security Module) Key，

來符合法規需求(FIPS 140-2 第 3 級)。

(2) 資料不會被駭客加密，或是被加密但可以從其他地方還原。

假如駭客都進來了，如果希望資料不被加密，

就是要設定好資料讀取和寫入的權限，

尤其是相關的 Service Account 擁有的權限角色，

以及資料所在地例如 Cloud Storage Bucket 或是 Bigquery Table 等，

設定好能存取的人員或 Service Account有哪些。

再來就是要把資料多存幾個地方，

這是用屁股想也知道，卻沒人要做的事情，因為怕要花錢。

GCP 上已經有很多服務可以跨 Region 儲存了，

例如 Cloud Storage、BigQuery、Snapshot、Image，

甚至 Cloud SQL 資料庫也可以跨 Region 即時複製 Read Replica，

當然這些都要費用，但總比資料被加密，要乖乖付贖金好吧！

5.供應鏈

請至少檢查這幾項：

公司的應用程式都是正版的嗎？

供應商都是有公信力的廠商？有通過資安認證？

員工都有沒有下載來路不明的免費軟體？

公司是否有安裝防毒軟體或各項資安監控工具？

公司用的作業系統映像檔是不是都由 Google 提供？

容器映像檔是否有掃瞄過？

這些應用程式，是否會主動對外存取？

自行開發的程式碼，是否有使用第三方的程式碼片段？

對哪些IP或網域存取？

對內又向哪些內部系統存取？

另一方面，也可以從軟體開發生命週期

(Secure Software Development Lifecycle, SSDLC) 的角度，

在各階段採用相對應的做法。

例如在需求階段，可使用 Security Command Center，

來管理資產清單、政策和風險。

實作階段可以使用 Binary Authorization ，

來校驗映像檔完整性等等

驗證階段可以使用 Web Security Scanner，

來掃描 HTTP(S) 端點的漏洞。

而在發佈階段可以使用 Artifact Registry，

來安全管理容器映像檔，並且對映像檔執行弱點掃瞄。

6.虛擬化

虛擬機器的映像檔，統一由 Google 提供，

有賴 Google 來協助維護公開映像檔的安全。

但是如果是自行搬遷上雲的主機，

就必須在搬遷之前做好徹底的掃瞄，

以及地端的環境，要防止虛擬機逃逸 (VM Escape)，

取得虛擬機管理程式（Hypervisor）的權限。

7.實體安全

在 GCP 的部分，統一由 Google 來管理全球的機房，沒有委外。

https://www.youtube.com/watch?v=kd33UVZhnAA

而如果你所在的公司有使用混合雲，

使用 Cloud VPN 或 Cloud Interconnect 的話，

就必須做好混合雲設備的管理，和操作的人員，

避免設定漏洞，開放太多用不到的網段、IP 位址和 Port，

或是設備本身被駭，更改設定導致門戶大開。

8.合規

資安法規日趨嚴格，須設置專門的人員，

隨時注意國內外相關法規的變化，

例如歐盟的 GDPR、台灣的個資法等等，

只要違反就有可能面臨鉅額罰金，不可不慎。

而這些法規條文往往艱澀難懂，

所以可能需要向外尋找專業的資安顧問公司，

來協助審查公司的各項做法，協助合規。

而在 GCP 方面，有提供 法規遵循資源中心，

可查詢 Google 通過的相關資安認證。

也有提供 Google Cloud Architect Framework，

讓你可以打造一個符合法規的雲端架構。

9.人員訓練

當然這是老生常談，

大家都知道人員都必須要訓練。

不過我要說的是，高階主管更需要訓練，

因為下屬迫於主管的威勢(官大學問大？)，

通常都給主管最大的系統權限，

但主管本人幾乎不負責操作系統，

等於開了一個超大權限給不會用的人，風險極高。

如果主管只會「看資料」，就只要「讀取」的權限就好，

不應該給到最高權限。

主管以身做作則，也能上行下效。

再來，全公司都要啟用 MFA (多因素驗證) 或 2FA (雙重驗證)，

即使是臨時建立的測試帳號，也要啟用，

避免帳號密碼被破解之後，沒有多一道防護。

以上分享各面向的資安威脅與因應方式，

給各位參考。

 

順便置入一下，關於更多資安相關的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post [GCP 教學] GCP 9 大資訊安全威脅與因應方案 first appeared on 東東 GCP 教學 - GCP 實戰講師.