防火牆與政策

GCP 防火牆架構導論

Google Cloud 提供三種不同的防火牆表面 —— 傳統的 VPC firewall rules、現代化的 Network Firewall Policies（區域或全域）、以及組織或資料夾層級的 Hierarchical Firewall Policies —— 加上更高階的 Cloud NGFW Enterprise，後者透過 security profile groups 接上 Layer 7 入侵預防與 URL/FQDN 檢測。這四個產品都在同一個位置攔截封包（VM 的 host kernel，在虛擬網卡之前），共用同一套 stateful 連線追蹤引擎，也共用優先級整數空間（rules 是 0–65535，hierarchical policies 是 0–2,147,483,647），但它們在範圍、表達能力與價格上完全不同。

PCNE 考試常常給你類似這樣的情境：「在 200 個專案內集中管理規則」、「禁止 compute workloads 存取 *.cryptominer.example.com」、或者「只允許來自日本與新加坡的流量」。挑錯產品就直接掉分。本筆記把每個情境對應到正確的防火牆表面，提供具體的 gcloud 語法、評估順序陷阱，以及區隔 Cloud NGFW Standard 與 Enterprise 的精確計費 SKU。

白話文解釋（Plain English Explanation）

在被一堆優先級整數淹沒之前，先把 GCP 防火牆堆疊想像成 VM 外面三層巢狀屏障。每個封包都必須通過三道屏障，而每道屏障都有自己的負責人、規則清單與「放行」動詞。

把它想像成三道門的高級社區

想像你的 VM 們住在一個有警衛的高級社區。Hierarchical Firewall Policies 就是社區的大門，由社區管理委員會（組織管理員）管。它們決定外送員能不能進入這片土地 —— 而且還有一個特別的動詞 goto_next，意思是「我個人沒有意見，請問裡面的門」。Network Firewall Policies 是你所住大樓的大廳門，由樓層主管（VPC 管理員）管。傳統 VPC firewall rules 則是自家門口，由你親自決定誰能進來。封包必須被三道門都許可。聰明的地方是：如果大門或大廳門說 goto_next，決策就一路往內滾。但若任何一道門說 deny，封包當場死亡，裡面的門根本不會看到。

把優先級想像成熟食店的號碼牌

在一個 policy 內部，規則按優先級排序 —— 而且數字越小越先，就像熟食店的取號機，1 號比 65535 號先被叫到。第一個 match 條件符合封包的規則勝出；之後的全部被忽略。這叫做 first-match-wins，不是 best-match。考生常常踩兩個坑：(1) 優先級 1000 的 deny 規則永遠勝過優先級 2000 的 allow 規則；(2) 隱含預設規則躺在最底層（傳統 firewall 是 65535，加上全組織隱含的 deny ingress 與隱含的 allow egress），所以你的自訂規則自然會覆蓋它們。

把 goto_next 想像成櫃台說「這不是我能決定的」

在公司辦公樓裡，櫃台小姐可能會直接揮手放你進來，因為她那層樓本來就是公共區域 —— 但每一層樓還是有自己的門禁感應器。goto_next 就是這樣：一條 hierarchical 或 network policy 規則可以說「這條 match 了，但我把判決權交給下一層」。它跟 allow 不一樣 —— allow 是短路放行，而 goto_next 只結束目前這個 policy 的評估，繼續往鏈條下一層走。這是 PCNE 防火牆題目最常被測的單一陷阱。

傳統 VPC Firewall Rules

傳統 VPC firewall rules 是原始的 GCP 防火牆產品。它們存在於單一 VPC 網路內、是 stateful 的，並依據 --source-ranges、--target-tags 或 --target-service-accounts 附加到 VM 網卡上。

優先級整數空間 0–65535

每條規則有一個 32-bit-ish 的 priority，但有效值範圍是 0..65535。數字小者勝。優先級 65535 永遠有兩條隱含規則：隱含的 allow egress to 0.0.0.0/0 與隱含的 deny ingress from 0.0.0.0/0。你不能刪除它們，只能覆蓋。常見的正式環境設計是在 65534 加一條 deny-all-egress，然後在 1000 或 100 等較低的優先級數字挖出 allow-list 例外。

目標：Tags 還是 Service Accounts

一條傳統規則可以用三種方式鎖定 VM：

• 網路內所有執行個體 —— 不指定目標；範圍廣、風險高。
• 網路標記 (Network Tags) —— --target-tags=web,prod。任何擁有 compute.instances.setTags 權限的使用者都能把自己掛上敏感規則，所以在共用專案裡網路標記是稽核地獄。
• 服務帳戶 (Service Accounts) —— [email protected]。把 service account 附加到 VM 上需要 iam.serviceAccountUser 權限，因此這是受 IAM 控管的強化選項。

單一規則只能選擇 tags 其一 或 service accounts 其一，不能兩者皆有。跨專案的 service account 目標只要該 SA 在同一個 Org 內且在目標專案上被授權即可運作。

Stateful 連線追蹤

VPC 防火牆是 stateful 的：一旦 allow ingress 被 match，同一條 flow 的反向封包會自動被許可，無視 egress 規則。Conntrack 逾時時間是已建立 TCP 為 600 秒、UDP 為 30 秒，足以撐過大多數短暫斷線。

Network Firewall Policies（區域與全域）

Network Firewall Policies 是新一代產品。你不再直接在 VPC 上寫規則，而是建立一個 policy 物件，然後把它關聯 (associate) 到 VPC 網路（global policy）或 VPC 中的某個區域（regional policy）。多個 VPC 可以共用同一個 policy。

為什麼它們取代了傳統規則

Network Firewall Policies 加上了傳統規則沒辦法表達的能力：

• FQDN match —— dst-fqdn=storage.googleapis.com 而不是 IP 範圍。
• 地理位置 match —— src-region-codes=JP,SG 只許可特定國家。
• Address groups —— 可重複使用的命名 CIDR 清單，跨規則共享。
• Threat-intel match —— src-threat-intelligence=iplist-tor-exit-nodes 丟棄已知惡意來源。
• Security profile groups —— 在 Cloud NGFW Enterprise 等級接上 L7 IPS。
• Mirroring action —— 除了 allow/deny 外，把流量複製到 Packet Mirroring sink。

傳統規則與 network firewall policies 可以在同一個 VPC 上共存；合併後的評估順序在下方說明。

全域與區域範圍

• 全域 Network Firewall Policy —— gcloud compute network-firewall-policies create my-pol --global。關聯到 VPC 網路；規則套用到 VPC 內任何區域的執行個體。每個 VPC 最多一條全域 policy。
• 區域 Network Firewall Policy —— gcloud compute network-firewall-policies create my-pol --region=us-central1。關聯到 (VPC, region) 組合；只影響該區域的執行個體。每個 (VPC, region) 最多一條。

一個 VPC 可以同時擁有一條全域與一條區域 policy 同時生效。在 network-firewall-policy 這一層內部，區域比全域更早被評估。

建立與關聯

gcloud compute network-firewall-policies create prod-global-pol --global \
  --description="prod global rules"
gcloud compute network-firewall-policies associations create \
  --firewall-policy=prod-global-pol --network=prod-vpc --global-firewall-policy
gcloud compute network-firewall-policies rules create 1000 \
  --firewall-policy=prod-global-pol --global-firewall-policy \
  --direction=INGRESS --action=allow --layer4-configs=tcp:443 \
  --src-ip-ranges=10.0.0.0/8 --target-secure-tags=tagValues/123456789

Hierarchical Firewall Policies

Hierarchical Firewall Policies 住在 GCP 資源階層的組織或資料夾節點。它們在所有專案層級規則之前被評估，讓資安團隊能在數百個專案上強制無法繞過的護欄。

組織層級與資料夾層級的附加

Hierarchical policy 是全域資源（gcloud compute org-firewall-policies create），接著你把它關聯到一個或多個節點：組織本身、資料夾，甚至單一專案。繼承是由上而下：掛在組織上的 policy 套用到底下每個專案；掛在資料夾上的 policy 套用到該資料夾底下的每個專案。多條 hierarchical policy 可以堆疊 —— 組織層級的先評估、然後是資料夾層級、然後是專案層級的 network firewall policies、再來是傳統 VPC 規則。

為什麼用它而不是專案層級規則

經典答案是不可繞過的控制。專案 owner 可以編輯自己的 VPC 防火牆規則，但他無法移除掛在資料夾層級的 hierarchical 規則 —— 只有在該資料夾或組織節點擁有 compute.orgFirewallPolicyAdmin 的使用者才能。這就是受規範環境如何在整個事業群內禁止來自網際網路的 SSH：在組織節點掛一條 deny ingress tcp:22 src=0.0.0.0/0，優先級設為 100。

必須記住的限制

• 每個節點最多 2 條 hierarchical policy（遷移視窗時可以一條 v1 加一條 v2）。
• 每個 policy 預設最多 200 條規則；可透過配額調高。
• 目標只能用 secure tags 或 target-resources（特定專案），因為 hierarchical policy 看不到專案本地的 network tags。

goto_next 動作與評估語意

Hierarchical 與 network firewall policies 都支援三個終結動作：allow、deny 與 goto_next。第三個是分層設計的關鍵。

goto_next 究竟做什麼

當一條規則 match 且其動作是 goto_next 時，評估會在目前的 policy 內停止，然後跳到階層中下一層防火牆。它不會繼續同一個 policy 內優先級較低的規則。所以如果你的組織層級 policy 有 priority=100, match=10.0.0.0/8, action=goto_next 與 priority=200, match=10.0.0.0/8, action=deny，封包會先 match 100，跳到資料夾層級；優先級 200 的 deny 永遠不會觸發。

常見的 goto_next 模式

• 組織層級為受信任 CIDR 開洞：「若來源在公司辦公室 IP 內，goto_next 交由各專案規則決定；否則套用全組織的 deny 規則」。
• 法規 landing zone：組織有 deny ingress 0.0.0.0/0 tcp:22 priority=100。資安團隊的資料夾在優先級 50 有條 goto_next 允許從 bastion 子網的 SSH —— 但資料夾規則本身無法覆蓋組織的 deny。正確設計是把 bastion 的 allow 放在組織層級，並用比 deny 更小的優先級數字。

沒有規則 match 時的預設行為

如果一個 policy 被評估而沒有任何規則 match，評估會隱含地落到下一層 —— 等同於沒有 match 的 goto_next。這就是為什麼空的 hierarchical policy 在 rollout 期間掛上是安全的。

Network Firewall Policies 內的 FQDN 規則

Cloud NGFW 支援用完整網域名稱代替靜態 IP 來 match，這在白名單第三方 SaaS 端點（IP 每天輪換的 *.googleapis.com、slack.com、套件 mirror 等）時是必需的。

FQDN 解析如何運作

GCP 在資料平面上每幾分鐘執行 DNS 解析（通常 30 秒），使用 VPC 設定的 resolver 與 Google 的公共 DNS-over-HTTPS resolver。解析結果的 IP 會被快取在規則的 match set 內，並在 TTL 到期時刷新。你寫 dest-fqdns=*.googleapis.com,storage.googleapis.com，Cloud NGFW 會處理其他細節。

萬用字元與限制

單一 FQDN match 支援前綴萬用字元（*.example.com 會 match a.example.com 與 b.example.com，但不會 match example.com 本身 —— 需要兩者都加）。每條規則最多列 2,000 個 FQDN，每條規則的實際解析 IP 集合上限約為 150,000 個唯一 IP。目前 FQDN match 僅支援 IPv4（IPv6 支援正在 rollout）。

gcloud 範例

gcloud compute network-firewall-policies rules create 2000 \
  --firewall-policy=prod-global-pol --global-firewall-policy \
  --direction=EGRESS --action=allow --layer4-configs=tcp:443 \
  --dest-fqdns="*.googleapis.com,storage.googleapis.com" \
  --target-secure-tags=tagValues/data-pipeline

哪些情況下 FQDN 規則不適用

FQDN 規則需要 Cloud NGFW（policy 框架）。傳統 VPC firewall rules 無法 match FQDN。如果題目描述「用傳統 gcloud compute firewall-rules create 阻擋對一串惡意網域的 egress」，正確答案是「不行 —— 先遷移到 Network Firewall Policies」。

地理位置 match 與 Threat Intelligence

國家層級的 match 是 Network Firewall Policies 的內建能力，依 Google 的 geo-IP 資料庫丟棄或允許流量。

src-region-codes 與使用情境

Match 欄位 src-region-codes=US,CA 或 dest-region-codes=CN,RU,IR 使用 ISO-3166-1 alpha-2 國碼。Google 每天從 MaxMind 加上自己的對等觀察更新 geo-IP 對映，所以它會落後即時資料但 24 小時內準確。

典型情境：

• 阻擋對禁運國家的 egress —— dest-region-codes=CU,IR,KP,SY,RU action=deny direction=EGRESS。
• 只許可本國 ingress —— src-region-codes=JP,TW action=allow，再加上較高優先級數字的 0.0.0.0/0 明確 deny。

Threat Intelligence 清單

Match src-threat-intelligence 引用 Google 維護的內建清單：

• iplist-known-malicious-ips
• iplist-tor-exit-nodes
• iplist-public-clouds（AWS、Azure 等）
• iplist-vpn-providers

這些對封鎖已知壞來源很好用，但跟公共 CDN 範圍混用會破壞合法流量 —— 許多 CDN 跟 VPN 提供商共用 IP。

Address Groups（命名與全域）

Address groups 是可重複使用的命名 CIDR 或 IP 清單物件，scope 在 org、資料夾或專案層級，由防火牆 policy 規則參考，而不是在規則內直接寫 CIDR。

專案 scope vs 組織 scope Address Groups

• 專案 scope —— gcloud network-security address-groups create my-group --type=IPV4 --capacity=100 --project=...。只能被該專案內的 policy 使用。
• 組織 scope（又稱 global）—— --parent=organizations/123456 加 --location=global。可被 hierarchical policy 與組織底下任何專案的 network policy 引用。

容量與可變性

每個 address group 在建立時宣告 --capacity（組織 scope 預設上限 50,000 IP、專案 scope 預設 100）。你可以在執行時用 gcloud network-security address-groups add-items 新增與移除成員，無需重新部署規則，所以事件回應 runbook 都用 address groups 來做「把這個攻擊者列入黑名單」的頁面。

在規則中引用

gcloud compute network-firewall-policies rules create 500 \
  --firewall-policy=prod-global-pol --global-firewall-policy \
  --direction=INGRESS --action=deny \
  --src-address-groups=organizations/123456/locations/global/addressGroups/blocklist

Security Profile Groups 與 Cloud NGFW Enterprise

Cloud NGFW 的高階方案（叫 Cloud NGFW Enterprise）加上 Layer 7 檢測。底層管線是兩個新物件：security profiles 與 security profile groups。

Security Profiles 的職責

security profile 是 type=THREAT_PREVENTION 的組織層級資源，包覆 Palo Alto 授權的入侵預防引擎。它可以對嚴重度為 Critical/High/Medium/Low/Informational 的特徵碼採取 ALERT、DROP、RESET 或 DEFAULT 動作。

包裝成 Security Profile Groups

security profile group 包一條或多條 profile（目前每組僅支援一條 threat-prevention profile，但 API 預期未來會更多），是真正被防火牆規則引用的物件：

gcloud compute network-firewall-policies rules create 3000 \
  --firewall-policy=prod-global-pol --global-firewall-policy \
  --direction=INGRESS --action=apply_security_profile_group \
  --security-profile-group=organizations/123456/locations/global/securityProfileGroups/spg-prod \
  --layer4-configs=tcp:443 --src-ip-ranges=0.0.0.0/0

規則動作 apply_security_profile_group 觸發 L7 檢測：TLS 解密後的 HTTP、SMB、FTP、DNS 等流量會被 profile 的特徵碼掃描。match 的封包依 profile 規則被丟棄或告警。

Enterprise SKU 計費影響

Cloud NGFW Enterprise 按每張 VM 網卡每小時加每 GB 檢測量計費。截至 2026 年大約是每 vCPU-小時 $0.025 加每 GB $0.075。這很可觀 —— 考試希望你只在高價值工作負載（受規範資料、面向網際網路的邊界）才推薦 Enterprise，而不是隨手套在每台內部 VM 上。

Service Accounts vs Network Tags vs Secure Tags

有三種目標機制可選擇規則套用到哪些 VM。考試會測你知道何時可用哪一種、以及每種的 IAM 控制方式。

Network Tags（傳統）

透過 --tags=web,prod 掛到 VM 上的自由格式字串。任何擁有 compute.instances.setTags 的人都能掛任意標記，所以在共用專案中是稽核夢魘。Network tags 只在傳統 VPC firewall rules 內能用，Network Firewall Policies 與 Hierarchical Policies 都不支援。

Service Accounts 當目標

把 service account 附加到 VM 上需要 iam.serviceAccountUser，所以 SA-based 鎖定承襲 IAM。用 [email protected]。在傳統 firewall 規則與部分 network firewall policy 情境內可用。

Secure Tags（現代）

Secure tags 是受 IAM 控管的 tag 資源，在組織或專案層級建立（gcloud resource-manager tags keys create、gcloud resource-manager tags values create）。把 tag 值掛到 VM 上需要該 tag 值的 resourcemanager.tagUser 權限，所以授權可以逐 tag 委派。Secure tags 在三層防火牆中都能用 —— hierarchical、network policy，甚至部分傳統情境 —— 是建議的現代目標機制。

單一 VM 最多可掛 50 個 secure tags，而標記沿著資源階層往下繼承（組織層級的 tag 會在底下的專案內可見）。

決策矩陣

新專案永遠先選 secure tags；只有當工作負載還沒有 tag schema 時才退回到 service accounts。

端到端評估順序

把所有層級拼起來，一個封包到你的 VM 會被嚴格依下列順序評估：

1. 組織層級的 Hierarchical Firewall Policy —— 規則依 priority 排序，本層內 first match wins。
2. 資料夾層級的 Hierarchical Firewall Policy —— 同上，可從子資料夾繼承。
3. 全域 Network Firewall Policy 關聯到該 VPC。
4. 區域 Network Firewall Policy 關聯到 (VPC, region) —— 沒錯，依目前文件，區域在全域之後評估。
5. 傳統 VPC Firewall Rules 在該 VPC 網路上。
6. 隱含規則 —— 隱含 deny ingress 與隱含 allow egress。

每一層中，goto_next 把判決延後到下一層。allow 與 deny 是終結動作。如果某層沒有任何規則 match，評估會隱含地進到下一層。

一個完整範例

從 203.0.113.5 進來的封包打到 web 層 VM 的 tcp:443：

1. 組織 hierarchical：優先級 100 的 deny tcp:22 src 0.0.0.0/0 —— 不 match（port 錯）。優先級 200 的 goto_next allow tcp:443 src 203.0.113.5 —— match，goto_next。
2. 資料夾 hierarchical：空的，落空到下一層。
3. 全域 network firewall policy：優先級 500 的 apply_security_profile_group tcp:443 src 0.0.0.0/0 —— 終結動作，L7 檢測啟動。profile 過關，封包放行。
4. 傳統 VPC 與區域層完全不會被諮詢 —— 全域 policy 已經終結。

日誌、Insights 與運維工具

每一層防火牆都能把日誌送到 Cloud Logging，但受到每條規則的 --enable-logging 旗標與取樣率管控。

Firewall Rules Logging

在規則上加 --enable-logging --logging-metadata=INCLUDE_ALL_METADATA 就會記錄每個 match 的連線。日誌包含 5-tuple、動作、規則參照、執行個體，可選地還有 VPC 與 SA。取樣是依 flow 而不是依封包 —— 長期連線只產生一筆日誌條目。

Firewall Insights

Firewall Insights 是基於 Recommender 的分析，會浮現：

• 被遮蔽規則 (Shadowed rules) —— 規則 A 完全被優先級較高的規則 B 遮蔽，你可以刪掉 A。
• 過度寬鬆規則 —— 命中率低的 0.0.0.0/0 match。
• Deny 規則誤判 —— recommender 認為應該被允許但被 deny 的流量。

它持續執行，可在 gcloud recommender insights list --insight-type=google.compute.firewall.Insight 取得發現。

與 Network Connectivity Tests 整合

Network Connectivity Tests 產品會用你當前的防火牆狀態（含 hierarchical policies）評估來源 → 目的地路徑。用它可以在部署前驗證規則變更。

常見問題 (FAQs)

Q1：Hierarchical Firewall Policy 可以引用專案的 network tag 例如 web 嗎？

不行。Hierarchical policy 看不到專案本地的 network tags。改用 secure tags，它們是 resource-manager 的一等資源、全組織可見；或者用 IP 範圍或 service accounts。

Q2：如果我同時有一條傳統 VPC firewall rule 跟一條 Network Firewall Policy 規則，且兩者都 match 同一個封包，誰勝出？

這是基於層級的，不是基於 priority。Network Firewall Policies 在傳統 VPC firewall rules 之前評估。所以如果 policy 規則說 allow，傳統規則永遠不會被諮詢。如果 policy 規則說 goto_next，接下來才依優先級評估傳統規則。

Q3：FQDN firewall rule 多久能反應 DNS 變更？

GCP 在 TTL 到期時刷新解析的 IP 集合，短 TTL 紀錄通常 30 秒一次。如果上游 DNS TTL 是 5 分鐘，DNS 變更後可能有 5 分鐘延遲。對 RPO 嚴格的情境，建議直接綁特定 IP 範圍加 FQDN 規則當備援。

Q4：Cloud NGFW Enterprise 的 L7 檢測能不做 TLS 攔截嗎？

L7 檢測對明文流量直接運作。對 TLS 加密的流量則必須在 security profile 內啟用 TLS Inspection，這需要你建立 client VM 信任的內部 CA 憑證信任儲存區。否則 profile 只看得到 TLS metadata（SNI、JA3）而看不到加密 payload。

Q5：address group 跟規則內 --src-ip-ranges 直接的 CIDR 清單有什麼差別？

直接的 CIDR 清單是規則內 inline 的，每條規則上限 256 筆。Address group 是分離的命名物件，可裝最多 50,000 筆（組織 scope）、執行期間可變動而不用改規則、且可被多條規則同時引用。短而穩定的清單用 CIDR list；大或快速變動的用 address group。

Q6：Hierarchical Firewall Policy 有多少優先級可用？

Hierarchical policy 規則使用 32-bit 優先級空間（0..2147483647）—— 比傳統 VPC 規則的 0..65535 大得多。較寬的範圍讓你在遷移期能交錯排組織、資料夾、專案規則而不撞號。

Q7：Network Firewall Policies 要錢嗎？

標準 Network Firewall Policy 使用免費 —— 你只付 VM 計算費，跟以往一樣。Cloud NGFW Enterprise 功能（security profile groups、L7 IPS、大規模 FQDN matching）另外按每 vCPU-小時與每檢測 GB 計費。