網路安全性最佳實踐

網路安全性最佳實踐簡介

Google Cloud 的網路安全在 PCNE 考試中很少是「單一產品」題目。實際題型通常描述一個受管制的工作負載（PCI、HIPAA、FedRAMP），需要同時在邊緣套用 Cloud Armor、在中間套用 Hierarchical Firewall Policy、用 IAP 處理應用層存取、用 VPC Service Controls 圍住資料平面、用 Private Service Connect 移除公共 IP、用 Cloud NAT 提供僅限出向的網際網路存取。「最佳實踐」這一章是其他所有 PCNE 章節的整合膠水，題目測的是你能否為某個威脅選對防禦層，而不是背誦單一功能的文件。

本學習筆記把每個 PCNE 安全控制對應到它的威脅模型，提供具體的 gcloud 與 API 欄位參考，最後以一個對齊 Google BeyondCorp Enterprise 與 Secure Foundation 藍圖的參考架構收尾。要記住的脈絡是：身分在最前、網路在中段、資料周界在最後、可觀測性貫穿整個堆疊。

白話文解釋 (Plain English Explanation)

雲端安全從來不是只靠一道牆。PCNE 考試期待你用分層思維作答，最簡單的內化方式就是想像三種完全不同的實體保全情境，每個比喻對應一組真實的 PCNE 功能。

把 VPC 想像成現代化銀行分行

銀行的最外層是停車場圍籬與監視器（Cloud Armor + edge security policy），它把明顯的威脅擋在進入建築物之前。大廳門口有身分驗證（IAP），員工會比對你的身分證件與預約名單後才放行。內部進入金庫的門有刷卡讀卡機並綁定你的角色（VPC firewall policy 以 service account 為目標、IAM）。金庫本身位於一間沒有窗戶、沒有對外連線的密閉房間裡（VPC Service Controls + Private Service Connect）。所有區域都裝有錄影設備記錄誰去過哪裡（VPC Flow Logs、Cloud Audit Logs）。任何單層防禦都不夠 —— 突破停車場圍籬之後，還有身分驗證、刷卡門禁、金庫牆面，以及全程錄影。

把 Hierarchical Firewall Policy 想像成跨國企業的服裝規範

一家跨國公司有一份由總部頒布的全球服裝規範（organization 層級 firewall policy：「全公司任何地方都不准穿夾腳拖」）。每個地區總部再加上自己的細節（folder 層級 policy：「歐洲辦公室週五要求商務便服」）。每個分公司可以再細化規則，但不能推翻全域規範（project 層級 VPC firewall rule）。當你出差到不同辦公室時，規則會自動疊加，而且新分公司無法選擇退出全球性的「不准夾腳拖」禁令。這就是 hierarchical firewall policy 由 organization → folder → project → VPC 繼承的方式，高層級的 deny 規則會凌駕低層級的 allow。

把 VPC Service Controls 想像成外交郵袋

外交郵袋是一個特殊的法律建構：無論誰攜帶、從哪個國家通關，海關都不能打開檢查。VPC Service Controls 對你的資料採取類似邏輯 —— 一旦某個 Cloud Storage bucket 或 BigQuery dataset 進入 service perimeter，任何位於 perimeter 外部的存取都會被拒絕，即使攻擊者偷到一把擁有完整 IAM 權限的 service account key 也一樣。重點是：IAM 規範「誰能做什麼」，而 VPC-SC 規範「從哪裡能做」。兩者都必須允許這個動作，所以洩漏的憑證從公共 IP 發起就毫無用處。

分層防禦：五個安全層

Google 的 PCNE 藍圖定義了五個重疊的防禦層，每個考題情境都對應其中一層或多層。

第 1 層：邊緣（Cloud Armor + Edge Security Policy）

第一站是公網側的 Points of Presence (PoP)，Cloud Armor 會在請求進入 VPC 前進行檢查。Edge security policy 附掛在 backend bucket 與啟用 Cloud CDN 的 backend service 上，在 cache 查找之前套用 IP/Geo/method 過濾，能同時擋下中毒快取與源站流量。Backend security policy 則涵蓋 OWASP ModSecurity CRS WAF、自訂 CEL 表達式、rate-based ban，以及 Adaptive Protection 的貝氏 ML。

第 2 層：網路周界（VPC Firewall Policy + Hierarchical Policy）

在 VPC 內部，firewall policy 負責東西向與南北向流量。Hierarchical policy 在 organization 或 folder 層級強制套用，確保某個租戶專案不會誤開 SSH 到 0.0.0.0/0。Network firewall policy 附掛在單一 VPC 上，使用 0–2,147,483,647 的優先序，採 first-match 語意。

第 3 層：應用程式身分（IAP）

Identity-Aware Proxy 處理 HTTPS、SSH、TCP，甚至 on-prem 應用程式的逐請求身分驗證。你不必對公司 VPN 網段開放某個 port，而是把 roles/iap.tunnelResourceAccessor 授予特定 Google identity，IAP 在驗證使用者、裝置狀態與情境之後才仲介這個連線。

第 4 層：資料周界（VPC Service Controls）

VPC-SC 在 BigQuery、Cloud Storage、Cloud KMS、Pub/Sub 以及 30 多種其他 API 表面外圍畫出一道環。來自 perimeter 外部的 API 呼叫即使擁有有效 IAM，也會收到 PERMISSION_DENIED: vpcServiceControlsUniqueIdentifier。這就是你的資料外洩護城河。

第 5 層：可觀測性（VPC Flow Logs + Firewall Insights + Cloud Audit Logs）

看不見就守不住。VPC Flow Logs 在 VM NIC 層級採樣 5-tuple 流量。Firewall Insights 用 ML 標出 shadow rule、過於寬鬆的規則，以及 30 天以上沒有命中的規則。Cloud Audit Logs 紀錄每一次 IAM 與防火牆變更。

周界防禦：Cloud Armor 與 Edge Security Policy

考試很愛問 Cloud Armor 拓樸題，因為一半的考生會搞混 edge policy 與 backend policy。

Edge Security Policy 的附掛目標

Edge security policy 只能附掛在兩種資源上：backend bucket（Global External Application LB 後面的 Cloud Storage 源站），以及啟用 Cloud CDN 的 backend service。它在 Google PoP 的 CDN cache 查找之前評估，所以被擋下的請求根本不會碰到 cache。

Edge Policy 的比對限制

Edge policy 只支援 srcIpRanges、origin.region_code 與 request.method。它無法檢查請求 body、URL path 或 header —— 那是 backend policy 的工作。代價是延遲：edge enforcement 不會增加 round-trip，因為它和 TLS handshake 發生在同一個 PoP。

Edge 與 Backend Policy 的組合

常見的正式環境布局：edge policy 在 priority 1000 拒絕來自非出貨國家的流量；cache hit 立刻回應；cache miss 才落到 backend policy 跑 OWASP CRS、自訂 CEL 與 rate-based ban。Edge policy 也涵蓋了 Cloud CDN 的「中毒快取」場景 —— 若無 edge policy，單一筆惡意請求填入 cache 後，可能對所有後續同國家使用者送出攻擊者控制的位元組。

Adaptive Protection 與 Edge 的關係

Adaptive Protection 的貝氏 ML 只能跑在 backend security policy 上，不能跑在 edge。它輸出的 signature 是一段 CEL 表達式，要當作 backend policy rule 套用。Edge policy 維持純宣告式語法。

VPC Firewall Policy 與 Hierarchical 強制執行

Firewall policy 是 PCNE 藍圖的主要內部控制機制，在新部署上幾乎取代了舊版 VPC firewall rule。

Hierarchical Firewall Policy

Hierarchical policy 附掛在 organization 或 folder 資源上，套用到範圍內每一個 VPC。它支援 allow/deny 以外的兩個動作：goto_next（略過這層 policy，繼續評估下一層）與 apply_security_profile_group（導流到 Cloud NGFW 入侵防護）。Hierarchical policy 在 network firewall policy、VPC firewall rule 與隱含規則之前評估。

Network Firewall Policy

Network firewall policy 附掛在單一 VPC 上，取代舊版 compute.firewalls 資源。它支援以 network tag、service account 與 secure tag（受 IAM 控管、任何使用者無法自我指派的 tag）作為目標。優先序範圍 0–2,147,483,647，採 first-match 語意。goto_next 動作會把請求交給下一個來源評估。

Secure Tag 與 Network Tag 的差別

Network tag（compute.instances.tags）只要有 compute.instances.setTags 就能設定 —— 那是個低權限角色。Secure tag（tagBindings）需要在 tag 本身擁有 roles/resourcemanager.tagUser，所以擁有 VM 編輯權的攻擊者無法把自己的 VM 加入某個「production」tag 對應的規則。考題出現「以 tag 為目標的防火牆規則但要防止權限升級」時，標準答案永遠是 secure tag。

Hierarchical Deny Rule 範例

gcloud compute firewall-policies create org-baseline \
  --organization=123456789 \
  --description="Org-wide network baseline"

gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=org-baseline \
  --action=deny \
  --direction=INGRESS \
  --src-ip-ranges=0.0.0.0/0 \
  --layer4-configs=tcp:22 \
  --description="No SSH from internet, ever"

網路相關的 IAM 最小權限

IAM 設計失誤就會製造網路漏洞。PCNE 考試期待你能把角色對應到職務功能。

網路專用角色

• roles/compute.networkAdmin — 管理 network、subnet、route、firewall rule，但不能 SSH 進 VM 或讀取 instance 資料。
• roles/compute.securityAdmin — 只管理 firewall rule 與 SSL 憑證；與 networkAdmin 形成職務分離 (SoD) 設計。
• roles/compute.networkUser — 在 service project 中使用 Shared VPC 的 subnet，但無法修改。
• roles/compute.networkViewer — 給稽核人員的網路資源唯讀權限。
• roles/iap.tunnelResourceAccessor — 透過 IAP tunnel 連到特定 VM。

職務分離

正式環境網路絕不該由單一人類同時擁有 compute.networkAdmin 與 compute.securityAdmin。標準做法：網路團隊持有 networkAdmin（route、peering、subnet）；安全團隊持有 securityAdmin（firewall rule、SSL）；維運只在 production VM 上拿 roles/iap.tunnelResourceAccessor。

避免專案層級 Owner

roles/owner 包含 compute.firewalls.update，可以停用 Cloud Armor policy。補救方式是自訂角色或預定義的細粒度角色 —— 永遠不要把專案 Owner 給正式環境的人類使用者。

IAP：零信任應用程式存取

幾乎每一個與「安全存取內部應用程式」相關的 PCNE 考題，Identity-Aware Proxy 都會取代 VPN。

HTTPS 應用程式的 IAP

把 IAP 附掛在 External 或 Internal Application LB 的 backend service 上。每個請求都會經 Google 身分層仲介：使用者用 Google 身分或 workforce identity federation 認證，IAP 簽發 JWT，你的應用程式透過 x-goog-iap-jwt-assertion 驗證 JWT。應用程式在 x-goog-authenticated-user-email 看到已驗證的電子郵件，不必再重做認證。

IAP TCP Forwarding

針對 SSH、RDP 與任意 TCP，gcloud compute start-iap-tunnel 指令會透過 IAP 仲介 tunnel，不必對網際網路開放任何 port。VM 的 firewall rule 只要允許 IAP 的來源網段 35.235.240.0/20 即可。

Context-Aware Access

IAP 整合 Access Context Manager 提供裝置狀態、IP CIDR、地理位置與時段條件。一個常見的 BeyondCorp 設計：roles/iap.httpsResourceAccessor 只在 device.is_corp_owned == true && origin.region_code == 'US' 時授予。被竊取的憑證若從個人筆電在不同國家使用，在 IAP 認證之前就會被 access policy 擋下。

IAP 對 On-Prem 應用程式

On-Prem Connector（前身為「App Connector」）讓 IAP 可以前置一個透過私有連線存取的 on-prem 應用程式。應用程式不需搬到 GCP —— IAP 透過位於你 VPC 的 connector VM 仲介連線，提供 SSO + context-aware access，on-prem 防火牆只會看到 connector 的 IP。

用 VPC Service Controls 防止資料外洩

VPC-SC 就是 PCNE 對「如何阻止被入侵的管理員把資料抄走」的標準答案。

Service Perimeter 基礎

Service perimeter 包圍一組專案，以及你選擇要保護的 GCP API（BigQuery、Storage、KMS、Pub/Sub、AI Platform、Dataflow 等）。任何從 perimeter 外部呼叫受保護服務的 API 都會失敗並回傳 VPC_SERVICE_CONTROLS_VIOLATION，即使呼叫端擁有有效的 IAM 也一樣。

Ingress 與 Egress Rule

現代的 VPC-SC perimeter 支援 ingress 與 egress rule，可以為跨 perimeter 的存取建立顯式 allow-list。一條 ingress rule 可能寫成：「允許 [email protected] 從 corp-perimeter 呼叫 bigquery.googleapis.com 進入 prod-perimeter」。沒有顯式規則的話，所有跨 perimeter 呼叫一律拒絕。

Access Level 與情境

Access level（由 Access Context Manager 管理）描述「誰或什麼」可以進入。條件可以組合裝置狀態、IP CIDR、地理區域、使用者身分群組與所需的 access policy。Perimeter 引用 access level 的意思是：「條件成立時允許，否則拒絕」。

常見 VPC-SC 情境

• BigQuery 資料外洩 — 把 perimeter 圍住 analytics project，洩漏的 service account key 無法 bq extract 到公共 bucket。
• Cloud Storage 偷搬攻擊 — gsutil cp gs://prod/* gs://attacker/ 失敗，因為目的端在 perimeter 之外。
• 被入侵的管理員 — 即使 Owner 也無法逃出 perimeter，必須通過 access level。
• 跨專案分析 — 顯式 ingress/egress rule 允許合法的跨專案查詢。

Private Service Connect：消除公共 IP

PSC 是存取 Google API 與第三方服務時，避免外部 IP 或公共路由的現代做法。

Google API 的 PSC

不要讓 VPC 走一條到公共 googleapis.com IP 範圍的 route，而是在你的 subnet 內建立一個有私有 IP 的 PSC endpoint，用來解析 *.googleapis.com（或服務專屬端點如 bigquery-private.googleapis.com）。DNS 透過 private.googleapis.com VIP 199.36.153.8/30 自動解析。

Published Service 的 PSC

Service producer 發布一個 service attachment；consumer 在自己的 VPC 中建立一個 endpoint 指向 producer 的 NLB。流量全程走 Google 網路 —— 不需 peering、不需公共 IP、不必協調可能重疊的 CIDR。SaaS 廠商可以為每位客戶發布一個 service attachment，讓每個 consumer 都有獨立的私有端點。

PSC vs Private Google Access vs Private Service Access

• Private Google Access — subnet 層級設定；沒有外部 IP 的 VM 透過隱含路由連到 199.36.153.8/30 存取 Google API。
• Private Service Access — 與 Google 託管 VPC 做 VPC peering，用於 Cloud SQL、Memorystore、AlloyDB 等服務。會從你的 VPC 配出一個 /24。
• Private Service Connect — 較新、不會 IP 衝突、更細粒度。新設計請優先選 PSC，除非該服務只支援 PSA。

PSC Endpoint Quota

一個專案在單一 region 最多支援 75 個 PSC endpoint 用於 Google API、最多 250 個用於 published service。Endpoint 會消耗 subnet 內的 IP，所以 subnet 大小要先規劃好。

Cloud NAT：僅出向的網際網路存取

Cloud NAT 讓私有 VM 能連到網際網路而不必擁有公共 IP，消除了多數架構中最大的單一攻擊面。

設計上即為僅出向

沒有外部 IP 的 VM 無法接收網際網路發起的未經請求的 inbound 流量。Cloud NAT 把 outbound 流量轉換成你掌控的一池 regional NAT IP。PCNE 標準考題情境：「私有 GKE cluster 要從 Docker Hub 拉 image」—— 答案是 Cloud NAT，而不是每個 node 都配公網 IP。

Port 配置與飽和

每個 NAT IP 提供 64,512 個 ephemeral port。預設靜態分配下，單一 VM 消耗 64 個 port per IP。計算：64,512 ÷ 64 = 每個 NAT IP 可容納 1,008 台 VM。超過就要啟用 dynamic port allocation (DPA) 讓 port 用量隨負載伸縮，或在 pool 中加更多 NAT IP。

NAT Logging

在 Cloud NAT gateway 啟用 NAT logging，把 translation 記錄送到 Cloud Logging。設定 --enable-logging --log-filter=ALL 取得完整可視性。出向資料外洩調查時非常關鍵。

Cloud NAT vs PSC

若目的端是 Google API，優先用 PSC（無 NAT translation、無 egress 費用、延遲較低）。Cloud NAT 只用在第三方網際網路目的地，例如 Docker Hub、npm、PyPI、合作夥伴 API。

VPC Flow Logs 與 Firewall Insights

可觀測性是第五道防禦層，也是許多 PCNE 故障排除與稽核題的答案。

VPC Flow Logs 設定

逐 subnet 啟用 --enable-flow-logs。用 --logging-aggregation-interval（5s、30s、1m、5m、10m、15m）與 --logging-flow-sampling（0.0–1.0）調整採樣率。預設採樣 0.5 會抓到一半的 flow；正式環境的安全敏感 subnet 通常拉到 1.0，高流量但非敏感的 subnet 拉到 0.1。每筆 log 都包含 5-tuple、bytes、packets 與 VPC metadata。

Firewall Insights 與 Shadow Rule

Firewall Insights 用 ML 分析 flow log 與防火牆命中數，找出三類規則品質問題：

• Shadowed rule — 被更高優先序的規則完全覆蓋，永遠不會觸發。
• Overly permissive rule — 來源 0.0.0.0/0 加上 port 22 等，會被標記為風險。
• Unused rule — 30 天內沒有命中，可考慮移除。

可以透過 firewallinsights.googleapis.com API 或 Console 的 Firewall Insights UI 查詢。

Log Analytics 整合

透過 sink 把 Flow Logs 路由到 BigQuery（--logging-aggregation-interval=5s 加上 export sink），就能用 SQL 做事件回應。標準 schema 包含 connection.src_ip、connection.dest_ip、bytes_sent、start_time、end_time 與 VPC/subnet metadata。像「外部 IP 連線到內部 DB port」這類偵測查詢可以排程成 BigQuery job。

BeyondCorp Enterprise 設計模式

BeyondCorp Enterprise (BCE) 是 Google 商業化的零信任產品，也是 PCNE 考試中現代化存取設計的參考典範。

BeyondCorp 核心原則

• 不信任任何網路 — 公司 Wi-Fi 與家中 Wi-Fi 都不再被預設信任。
• 每個請求都重新認證 — IAP + 身分提供者對每個 API call 都驗證，而不是 VPN 連上之後就放行。
• 依情境授權 — 使用者、裝置、地理位置、時間、應用程式風險。
• 持續驗證 — 裝置一旦不符合合規要求，session 立刻失效。

BCE 的組成元件

• Chrome Enterprise 加上受管的裝置狀態（OS 版本、螢幕鎖、磁碟加密）。
• Endpoint Verification 為非 Chrome 裝置回報狀態到 Access Context Manager。
• Access Context Manager 把狀態與身分轉成 access level。
• IAP 以逐請求方式強制套用 access level，涵蓋 web、SSH 與 TCP。
• Cloud Identity Premium 或 Workforce Identity Federation 提供使用者身分。

零信任 vs 以網路為中心

以網路為中心的設計把 VPN 打開到企業 /16 範圍；一旦連上 VPN，就能存取所有內部應用程式。BCE 設計則只在使用者需要時，把 roles/iap.httpsResourceAccessor 授權到特定應用程式，並綁定裝置狀態條件。被竊筆電一旦失去合規狀態，立刻喪失存取權。

參考架構：受管制的多層工作負載

以下是 PCNE 對齊的合併設計，用於有資料庫與分析需求的受管制 web 應用程式。

網路拓撲

• 在 prod-host-project 中設定 Shared VPC，在 us-central1 與 europe-west1 分別建立 web tier、app tier 與 data tier 的 subnet。
• Web tier 位於 Global External Application LB 後方，啟用 Cloud CDN、Cloud Armor edge + backend policy，並對 /admin 套用 IAP。
• App tier 在私有 subnet，沒有外部 IP，只透過 LB 或 IAP TCP forwarding 存取。
• Data tier 在私有 subnet，Cloud SQL 使用 Private Service Access，Cloud Storage 透過 PSC 存取。
• 出向流量走 Cloud NAT 且啟用 NAT logging 送到 Cloud Logging。

安全控制

• Hierarchical firewall policy 在 organization 層級拒絕 SSH (tcp:22) 從 0.0.0.0/0 到每一個 VPC，沒有例外。
• Network firewall policy 在 Shared VPC 上以 secure-tag 為目標允許 tier 之間流量，其餘一律拒絕。
• VPC Service Controls perimeter 包住 prod-data-project，涵蓋 BigQuery、Cloud Storage、KMS、Pub/Sub。
• IAP TCP forwarding 處理所有管理員 SSH；VM 上完全沒有外部 IP。
• BeyondCorp Enterprise access level 對管理員路徑要求企業擁有的裝置 + 美/歐地理位置。
• VPC Flow Logs 在 data tier subnet 採樣 1.0，web/app tier 採樣 0.5，透過 log sink 送到 BigQuery。
• Firewall Insights 每月檢查；shadow rule 即時清理。

為何在被入侵時仍能保護資料

如果攻擊者釣到管理員憑證並竊取 service account key：

1. 缺乏裝置狀態的情況下，IAP 在 BCE 條件下拒絕存取管理員路徑。
2. 缺乏從公網到內部 subnet 的 route，僅憑憑證無法觸及 Cloud SQL 或 Cloud Storage VM。
3. 從 perimeter 外部呼叫 BigQuery 或 Storage 會收到 VPC_SERVICE_CONTROLS_VIOLATION。
4. VPC Flow Logs 與 Cloud Audit Logs 紀錄每一次嘗試；PERMISSION_DENIED 飆升時告警立刻觸發。

常見陷阱與 PCNE 考試地雷

考試最愛測這些誤解：

• 「Cloud Armor 保護 Internal LB」 — 錯。Cloud Armor 只能附掛在 External Application LB 與 External Proxy NLB。Internal LB 要用 VPC firewall policy + Cloud IDS。
• 「VPC-SC 擋 VM-to-VM 流量」 — 錯。VPC-SC 保護 API 表面（BigQuery、GCS、KMS）；VM 對 VM 是 firewall policy 的範圍。
• 「Hierarchical policy 覆寫 VPC firewall rule」 — 部分正確。它們先評估，所以 hierarchical 層的 deny 是最終的，但 hierarchical 的 goto_next 會把判斷交給下層。
• 「Network tag 是安全的」 — 錯。任何有 compute.instances.setTags 的人都能更改。正式環境用 secure tag 或 service account 作為防火牆目標。
• 「IAP 需要 VPN」 — 錯，相反。IAP 取代 VPN，提供身分感知的 tunnel。
• 「Private Google Access 之後就不需要連網際網路的路由」 — 對，但 PGA 只在 subnet 層級且僅限 Google API；第三方 API 仍需 Cloud NAT 或 PSC for published service。
• 「PSC 與 Private Service Access 相同」 — 錯。PSA 使用 VPC peering 並消耗你的 VPC IP 範圍。PSC 使用 endpoint，且避免 IP 衝突。

gcloud 快速參考

PCNE 安全堆疊的常用指令：

# Hierarchical firewall policy 拒絕網際網路 SSH
gcloud compute firewall-policies create org-baseline --organization=123 \
  --description="No SSH from internet"
gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=org-baseline \
  --action=deny --direction=INGRESS \
  --src-ip-ranges=0.0.0.0/0 --layer4-configs=tcp:22

# Network firewall policy 以 secure tag 為目標
gcloud compute network-firewall-policies create app-policy --global
gcloud compute network-firewall-policies rules create 1000 \
  --firewall-policy=app-policy --global-firewall-policy \
  --action=allow --direction=INGRESS \
  --src-secure-tags=tagValues/12345 \
  --layer4-configs=tcp:8080

# VPC Service Controls perimeter
gcloud access-context-manager perimeters create prod-perimeter \
  --title="Prod Data Perimeter" \
  --resources=projects/PROJECT_NUM \
  --restricted-services=bigquery.googleapis.com,storage.googleapis.com

# 啟用 VPC Flow Logs
gcloud compute networks subnets update prod-data-subnet \
  --region=us-central1 \
  --enable-flow-logs \
  --logging-aggregation-interval=interval-5-sec \
  --logging-flow-sampling=1.0

# Cloud NAT 加 logging
gcloud compute routers nats create prod-nat \
  --router=prod-router --region=us-central1 \
  --nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips \
  --enable-logging --log-filter=ALL

# IAP TCP tunnel 到私有 VM
gcloud compute start-iap-tunnel prod-bastion 22 \
  --local-host-port=localhost:2222 --zone=us-central1-a

常見問題 (FAQ)

防火牆規則應該用 network tag 還是 service account 作目標？

Service account 與 secure tag 都比 network tag 安全。Network tag 任何有 compute.instances.setTags 的人都能改。Service account 目標需要 SA 上的 iam.serviceAccountUser。Secure tag 需要 tag 本身的 resourcemanager.tagUser。PCI/HIPAA 工作負載建議用 secure tag，因為它受 IAM 控管且 VM 重建後仍持續存在。

Hierarchical firewall policy 與 VPC firewall rule 如何互動？

評估順序：hierarchical org policy → hierarchical folder policy → global network firewall policy → regional network firewall policy → VPC firewall rule → 隱含 deny-ingress / allow-egress。任一層的 deny 都會終止評估。goto_next 動作會讓請求落到下一層。也就是說，組織層級的 deny rule 無法被專案層級的 allow 推翻。

什麼時候用 VPC Service Controls，什麼時候用 firewall policy？

兩者保護不同的表面。Firewall policy 控制 VM 之間以及網際網路到 LB 的 IP 流量。VPC Service Controls 保護的是對 BigQuery、Storage、KMS、Pub/Sub 等託管服務的 API 呼叫。被入侵的 VM 即使擁有有效 IAM，沒有 VPC-SC 仍能呼叫 BigQuery；有 VPC-SC 之後，從 perimeter 外的呼叫就會失敗。受管制工作負載要兩者並用。

開發者 SSH 存取要用 IAP 還是 VPN？

IAP TCP forwarding 是新設計的 PCNE 標準答案。它取消了 VPN 需求、消除 VM 的外部 IP、整合 Google identity 提供 SSO + 2FA、支援情境感知存取（裝置狀態、地理位置），並把每次連線寫進 Cloud Audit Logs。VPN 只在無法套用 IAP 的舊應用程式上仍有用 —— 新 PCNE 答案應預設選 IAP。

Service account key 洩漏時如何防止資料外洩？

兩個互補控制。第一，VPC Service Controls 確保洩漏的 key 無法從 perimeter 外部呼叫 BigQuery、Storage 等受限服務，與 IAM 無關。第二，Cloud Audit Logs 在 cloudaudit.googleapis.com 上紀錄每一次 API call 與呼叫者身分；告警設在 PERMISSION_DENIED: vpcServiceControlsUniqueIdentifier 飆升時，可在數分鐘內通知。VPC-SC 之前的時代得靠 IAM 輪換，速度太慢。

Private Google Access、Private Service Access、Private Service Connect 有什麼差別？

Private Google Access 是 subnet 旗標，讓私有 VM 透過隱含路由到達 *.googleapis.com。Private Service Access 是與 Google 託管 VPC 做 VPC peering，用於 Cloud SQL 這類產品，會從你的 VPC IP 空間配出一個 /24。Private Service Connect 是最新的、無 IP 衝突的模型：在你的 subnet 內建立一個私有端點，解析到 Google API 或 published service。新設計優先選 PSC；PSA 仍是 Cloud SQL 舊版設計的必要選項。

Cloud NAT 與每台 VM 都配公網 IP 有何不同？

Cloud NAT 把一池 regional NAT IP 共享給多台 VM，移除了每台 VM 的外部 IP 攻擊面。每個 NAT IP 支援 64,512 個 ephemeral port；預設靜態分配下每台 VM 占 64 個 port，可容納約 1,000 台 VM。Dynamic port allocation 可進一步擴充。關鍵差別：NAT 只能 outbound，網際網路的主機無法回頭主動連線到 NAT IP。外部 IP 則是雙向的，會製造 inbound 攻擊面。

Firewall Insights 到底偵測什麼？

三類規則品質問題。Shadowed rule 被優先序更高的規則完全覆蓋，永遠不會觸發。Overly permissive rule 比對範圍很大（例如 0.0.0.0/0）且 port 範圍很廣，會被標記為風險。Unused rule 30 天內零命中，可考慮刪除。Firewall Insights 以 VPC Flow Logs 與規則命中計數器為輸入，所以相關 subnet 必須啟用 flow log 才能分析。

相關章節

• pcne-cloud-armor — edge/backend policy、OWASP CRS、Adaptive Protection。
• pcne-firewalls-policies — hierarchical 與 network firewall policy、secure tag。
• pcne-cloud-nat — NAT IP 配置、port 飽和、dynamic port allocation。
• pcne-packet-mirroring-flow-logs — VPC Flow Logs 與 Packet Mirroring 深度解析。

延伸閱讀

• Firewall policies overview: https://cloud.google.com/vpc/docs/firewall-policies
• VPC Service Controls overview: https://cloud.google.com/vpc-service-controls/docs/overview
• Identity-Aware Proxy concepts: https://cloud.google.com/iap/docs/concepts-overview
• Private Service Connect overview: https://cloud.google.com/vpc/docs/private-service-connect
• VPC Flow Logs: https://cloud.google.com/vpc/docs/flow-logs
• Firewall Insights overview: https://cloud.google.com/vpc/docs/firewall-insights-overview
• BeyondCorp Enterprise overview: https://cloud.google.com/beyondcorp-enterprise/docs/overview
• Security foundations blueprint: https://cloud.google.com/architecture/security-foundations