網路安全性設計

網路安全性設計簡介

對於專業雲端架構師 (Professional Cloud Architect) 而言，網路安全性不再僅僅是「在邊緣設置防火牆」。在現代雲端環境中，安全性必須是多層次的、以身份為中心的且自動化的。在 GCP 中設計網路安全性，涉及從傳統的基於周邊的模型轉向層層防禦 (Defense in Depth) 和零信任 (Zero Trust) 架構。

本指南涵蓋了如何保護您的 VPC、防禦外部威脅，並確保資料保留在授權邊界內。

白話文解釋

比喻 1 — 機場的多層安檢 (Defense in Depth)

把現代機場想成你的雲端網路。Cloud Armor 是外圍圍籬與機場大門的安檢站，把明顯的威脅擋在航廈外。Identity-Aware Proxy (IAP) 是登機門口的地勤，就算你已經通過 TSA，每一班飛機都要重新驗證登機證與身份。VPC firewall rules 是登機門、行李處理區、停機坪之間的上鎖門 — 不同角色拿不同鑰匙。VPC Service Controls 則是海關，它檢查的是什麼東西「離境」(perimeter)，不是誰走進來。任何一層失守，其他層仍然能擋。

比喻 2 — 連鎖飯店的智慧鑰匙系統 (Hierarchical Firewall Policies)

大型連鎖飯店不會讓每家分店各自決定「萬能鑰匙」怎麼設定。總部訂下全集團規則（「萬能鑰匙不能開保險庫」）— 這就是組織層級的階層式防火牆政策。區域主管再加一層（「11 點之後沒有鑰匙能上頂樓」）— 這就是資料夾層級政策。最後每家飯店設定房間鎖 — 這是專案層級的 VPC firewall rule。分店櫃台無法推翻總部的規定。GCP 也一樣：專案擁有者無法穿透資料夾層級的拒絕規則。

比喻 3 — 私人專線 vs 公用總機 (Private Service Connect)

想像你經營一家醫院，要打電話給某家檢驗室拿報告。走公共電話網（網際網路）代表任何人都可能竊聽或冒充檢驗室。Private Service Connect (PSC) 就像辦公室和那家檢驗室之間的私人專線 — 不經過公用總機。檢驗室（producer）發布一個私有端點，你的辦公室（consumer）只用內部 IP 連線，整段通話永遠不離開 Google 的私有光纖。不用 VPN、不用 peering、不用公共 DNS 查詢。

「層層防禦」策略

網路安全性應被視為一系列同心圓。如果一層被突破，其他層必須仍然存在以保護核心資料。

1. 邊緣安全性 (Edge Security): Cloud Armor、Cloud CDN 和外部負載平衡 (Load Balancing)。
2. 邊界安全性 (Boundary Security): VPC Service Controls (服務周邊)。
3. 網路層安全性 (Network-Level Security): Cloud Firewall 規則、階層式防火牆政策 (Hierarchical Firewall Policies) 和入侵檢測 (Cloud IDS)。
4. 應用程式/身份安全性 (Application/Identity Security): Identity-Aware Proxy (IAP)、SSL/TLS 終端。
5. 運算安全性 (Compute Security): Shielded VMs、OS Login 和私有 IP。

網路安全性的白話比喻

比喻 1 — 中世紀城堡 (層層防禦)

城堡不只有一面牆。它有護城河（外部負載平衡器/Cloud Armor）來阻擋人群，有吊橋 (Identity-Aware Proxy)，只為已知的盟友放下，有厚實的石牆 (VPC Service Controls) 防止人們從國庫走私黃金，以及在每個走廊都有內部衛兵哨所 (Cloud Firewall)，確保人們只待在他們應該待的地方。

比喻 2 — VIP 夜店 (Identity-Aware Proxy)

在傳統網路中，如果你有大門的「鑰匙」，你就進去了。在結合 IAP 的零信任模型中，網路就像一間 VIP 夜店。即使你站在門口（URL 處），保鏢 (IAP) 也不在乎你在那裡。他們會先檢查你的 ID 和邀請名單 (IAM 角色)，然後才讓你碰門把。沒有 ID，就不能進入 — 無論你來自哪裡。

比喻 3 — 銀行金庫的實體隔離 (VPC Service Controls)

想像一家銀行，行員可以看到錢，但不能把它帶出大樓。VPC Service Controls 就像大樓周圍的一個特殊安全場。即使行員（被盜用的服務帳戶）試圖將黃金（資料）「電郵」給外部帳戶，安全場也會將其封鎖，因為資料不允許離開銀行的「周邊」，即使行員擁有有效的憑證也是如此。

核心安全性元件

1. Cloud Firewall (與 Firewall Plus)

GCP 防火牆是具備狀態 (stateful) 且分散式的。它們不是「設備」，而是套用於 VM 的中繼資料。

• 服務帳戶與標記 (Tags): 始終優先使用服務帳戶或網路標記而非 IP 範圍來制定內部規則，以確保擴充性。
• 階層式防火牆政策 (Hierarchical Firewall Policies): 套用於資料夾或組織層級，以實施專案擁有者無法覆寫的安全護欄。

2. VPC Service Controls (VPC SC)

這是 PCA 考試的關鍵主題。它圍繞 Google 管理的服務（如 Cloud Storage、BigQuery、Vertex AI）建立安全性周邊。

• 防止資料外洩 (Data Exfiltration Prevention): 防止將資料從授權的儲存桶複製到未經授權的儲存桶。
• Access Context Manager: 允許根據 IP、使用者身份或裝置健康狀況等屬性進行存取。

3. Cloud Armor (WAF & DDoS)

部署在全域外部 HTTP(S) 負載平衡器。

• WAF 規則: 防範 SQL 注入、跨網站指令碼 (XSS)。
• Adaptive Protection: 使用機器學習偵測並封鎖 L7 DDoS 攻擊。

4. Identity-Aware Proxy (IAP)

Google 「BeyondCorp」（零信任）願景的基石。

• 允許透過公共網際網路存取網頁應用程式和 VM（經由 SSH/RDP），而不需要使用 VPN。
• 驗證每個請求的使用者身份和情境。

VPC Firewall Rules 與 Hierarchical Firewall Policies

GCP 防火牆執行點在 VM 的虛擬 NIC，而不是集中式的設備。每條規則由主機 hypervisor 各自評估，因此規則數量隨機隊規模線性擴展，不會產生瓶頸。

規則優先順序與結構

一條防火牆規則包含五個關鍵欄位：priority（0-65535，數字小者優先）、direction（Ingress 或 Egress）、action（allow 或 deny）、target（透過服務帳戶、tag 或「全部」指定套用對象）、filter（來源/目的範圍、port、protocol）。

每個 VPC 預設帶有隱含規則：

• 隱含允許 egress 至 0.0.0.0/0，priority 65535。
• 隱含拒絕 ingress 來自 0.0.0.0/0，priority 65535。

Hierarchical firewall policies

階層式防火牆政策附加在組織或資料夾層級，在專案層級的 VPC firewall rules 之前評估。它支援三種動作，下層的網路管理員無法覆寫：allow、deny、goto_next。goto_next 等於明確把決策權交給下一層。

gcloud compute firewall-policies create corp-guardrails \
  --organization=123456789012 \
  --short-name=corp-guardrails
gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=corp-guardrails \
  --action=deny --direction=INGRESS \
  --src-ip-ranges=0.0.0.0/0 --layer4-configs=tcp:22 \
  --description="Deny SSH from internet — IAP-only"

Global vs Regional network firewall policies

GCP 現在提供 Global Network Firewall Policies 與 Regional Network Firewall Policies，作為傳統 per-VPC 規則的統一替代方案。它們支援 secure tags（透過 IAM 控制的 tag key），相較舊的 network tag 字串比對更安全 — 舊式 tag 任何專案擁有者都能冒用。

Cloud Armor 邊緣保護

Cloud Armor 是 Layer 7 保護平面，部署在 Global External Application Load Balancer、Regional External Application Load Balancer，以及（透過 Cloud Armor for Network Load Balancers）外部 Network Load Balancer（提供 rate limiting 與威脅情報）的前面。

Security policy 類型

• Backend security policies — 附加於 backend service，在請求抵達來源前過濾。
• Edge security policies — 附加於 Cloud CDN 的 backend bucket/service，在 Google 邊緣 POP、快取查找之前評估。

Pre-configured WAF rules

Cloud Armor 內建以 OWASP ModSecurity Core Rule Set 3.3 為基礎的 WAF 規則。每條規則的 sensitivity 可從 1（高特異性、誤判少）調到 4（涵蓋廣、誤判多）：

gcloud compute security-policies rules create 1000 \
  --security-policy=prod-edge \
  --expression="evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 2})" \
  --action=deny-403

預設規則集包括 sqli-v33-stable、xss-v33-stable、lfi-v33-stable、rfi-v33-stable、rce-v33-stable、methodenforcement-v33-stable、protocolattack-v33-stable。

Adaptive Protection 與 rate limiting

• Adaptive Protection 用機器學習為每個 backend service 建立流量基準，在異常尖峰時自動建議規則。它在 Cloud Logging 中輸出 adaptiveProtection JSON 欄位，附帶攻擊特徵。
• Rate limiting 支援 throttle（丟掉超量流量）和 rate_based_ban（封鎖違規 key 一段時間）。Key 可以是 IP、HTTP header、XFF IP、region code 或 HTTP cookie。

Cloud Armor Managed Protection 方案

Private Service Connect (PSC)：producer 與 consumer

Private Service Connect 是 GCP 透過私有 IP 暴露服務的機制，不需要 VPC peering、Cloud VPN 或公開端點。它是多租戶 SaaS、跨 VPC 服務共用、以及私有存取 Google APIs 的建議模式。

兩種 PSC 拓樸

1. PSC for Google APIs（純 consumer）

將 Google 管理的服務（Cloud Storage、BigQuery、Pub/Sub 等）映射為你 VPC 內的私有 IP。

gcloud compute addresses create psc-gcp-apis \
  --global --purpose=PRIVATE_SERVICE_CONNECT \
  --addresses=10.10.0.5 --network=prod-vpc
gcloud compute forwarding-rules create psc-gcp-apis-fr \
  --global --network=prod-vpc \
  --address=psc-gcp-apis --target-google-apis-bundle=all-apis

之後 storage.googleapis.com 在 prod-vpc 內會解析為 10.10.0.5 — 流量永遠不走公共網際網路。

2. PSC for published services（producer + consumer）

Producer 在自己 VPC 的內部負載平衡器後面跑服務，發布一個 service attachment。Consumer 在自己的 VPC 中建立一個 PSC endpoint（一個帶私有 IP 的 forwarding rule），透過 URI 連結到該 service attachment。

# Producer 端
gcloud compute service-attachments create my-saas-attachment \
  --region=us-central1 --producer-forwarding-rule=ilb-fr \
  --connection-preference=ACCEPT_AUTOMATIC \
  --nat-subnets=psc-nat-subnet

# Consumer 端
gcloud compute forwarding-rules create my-saas-endpoint \
  --region=us-central1 --network=consumer-vpc \
  --target-service-attachment=projects/producer/regions/us-central1/serviceAttachments/my-saas-attachment

PSC vs VPC Peering vs Shared VPC

• PSC — 把單一服務暴露為 endpoint。不擔心 IP 重疊、沒有 transitive 限制、可做服務粒度的 IAM。
• VPC Peering — 連結整個 VPC。非 transitive、需要協調 CIDR、把所有可路由的資源都暴露出去。
• Shared VPC — host project 擁有單一 VPC，service project 使用之。集中管理但耦合緊。

Cloud NAT：受控的對外連線

Cloud NAT 為沒有外部 IP 的 VM 提供對外網際網路連線，這也是正式環境工作負載預設安全的姿態。它是託管的、區域型、SDN 型服務 — 沒有 NAT gateway VM 要你維運或擴展。

Cloud NAT 運作方式

• 附加到特定 region/VPC 的 Cloud Router。
• 配置外部 IP（自動或手動），動態把內部來源 port 映射到外部 IP:port tuple。
• 支援同 region 內子網的主要與 alias IP 範圍。
• 對於需要一致 NAT 映射的協定（例如 WebRTC），可啟用 Endpoint-Independent Mapping (EIM)。

gcloud compute routers create nat-router \
  --network=prod-vpc --region=us-central1
gcloud compute routers nats create prod-nat \
  --router=nat-router --region=us-central1 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips \
  --enable-logging --log-filter=ERRORS_ONLY

Port 配置陷阱

預設每個 VM 在每個 NAT IP 上分配 64 個 port。一個 VM 對同一個目的（destIP:destPort）開很多並行連線就會 port 耗盡，VPC Flow Logs 會看到 NAT_ALLOCATION_FAILED。

緩解方式：

• 把 --min-ports-per-vm 拉到 1024 以上。
• 啟用 Dynamic Port Allocation（--enable-dynamic-port-allocation），讓 port 在需要時擴張到 --max-ports-per-vm。
• 為 NAT 加更多外部 IP（每個 IP 增加約 64,512 個可用 port）。

Cloud NAT logging

Cloud NAT 可以輸出兩種 log：TRANSLATIONS_ONLY 與 ERRORS_ONLY（或同時）。考題若問「稽核我們的私有 VM 對外連到哪些外部 IP」，答案是 TRANSLATIONS_ONLY。

Cloud IDS：入侵偵測

Cloud IDS 是 Google 託管的入侵偵測系統，由 Palo Alto Networks 的威脅偵測引擎驅動。它是只偵測（IDS，不是 IPS） — 警示送進 Cloud Logging 與 Security Command Center，但 Cloud IDS 不會封鎖流量。

架構

Cloud IDS 在每個 region 部署一個 IDS endpoint，透過你設定的 packet mirroring policy 接收鏡像流量。endpoint 檢查：

• 威脅特徵（9,000+ 條 Palo Alto 規則）
• 惡意程式 C&C 流量
• 已知漏洞與利用
• 異常 protocol 行為

設定流程

# 1. 從 producer VPC 配置 /24 給 IDS endpoint
gcloud compute addresses create cloud-ids-ip-range \
  --global --purpose=VPC_PEERING --prefix-length=24 \
  --network=prod-vpc

# 2. 建立 IDS endpoint
gcloud ids endpoints create prod-ids \
  --network=prod-vpc --zone=us-central1-a \
  --severity=INFORMATIONAL

# 3. 把鏡像流量轉到 IDS endpoint
gcloud compute packet-mirrorings create ids-mirror \
  --region=us-central1 \
  --collector-ilb=$(gcloud ids endpoints describe prod-ids \
    --zone=us-central1-a --format='value(endpointForwardingRule)') \
  --mirrored-subnets=prod-subnet-us-central1

嚴重性等級與告警

警示標記為 INFORMATIONAL、LOW、MEDIUM、HIGH 或 CRITICAL。在 Cloud Monitoring 設定 log-based 告警：

resource.type="ids.googleapis.com/Endpoint"
jsonPayload.alert_severity="CRITICAL"

Cloud IDS vs Cloud Armor vs VPC Service Controls

Packet Mirroring：深度封包檢視

Packet Mirroring 複製指定 VM 的所有 ingress 與 egress 流量，把完整封包副本（header + payload）轉送到收集器 — 通常是內部負載平衡器後面接 Cloud IDS 或自管的 IDS/IPS 機隊。

篩選條件

packet mirroring policy 用 AND 組合篩選哪些流量要複製：

• **鏡像來源：**特定子網、按名稱指定的 VM、或符合 network tag 的 VM。
• **過濾器：**protocol（tcp/udp/icmp）、CIDR 範圍、方向（INGRESS、EGRESS、BOTH）。

成本注意事項

鏡像會讓被鏡像 VM 的 egress 流量加倍 — 每個封包都產生一份副本送到收集器。10 Gbps 的熱門服務，等於要多付 10 Gbps 的跨 zone 或跨 region 流量費，如果收集器不同位的話。

最佳實踐：

• 把收集器 ILB 放在被鏡像來源同一個 region，避免跨 region 流量費。
• 積極使用過濾器 — 只鏡像可疑子網或只鏡像 TCP/443，比鏡像全部流量便宜很多。

gcloud compute packet-mirrorings create web-tier-mirror \
  --region=us-central1 \
  --collector-ilb=ids-collector-ilb \
  --mirrored-tags=pci-scope \
  --filter-protocols=tcp \
  --filter-cidr-ranges=10.0.0.0/8 \
  --filter-direction=BOTH

Packet Mirroring 的定位

它是餵 Cloud IDS 或第三方安全設備的管線層。PCA 題目常會說「合規團隊要求保留 90 天完整封包擷取」— 答案是把流量鏡像到第三方 VM 收集器，由收集器把 pcap 寫進 Cloud Storage，不是 Cloud IDS（Cloud IDS 不存原始 pcap）。

Service Directory：安全的服務探索

Service Directory 是託管的服務註冊中心，跨 GCP、混合與多雲提供服務名稱、IP、port、metadata 的單一事實來源。它讓你不必硬寫 IP、也不必自建 Consul/etcd 叢集。

核心概念

• Namespace — 最上層作用域（例如 prod、staging）。
• Service — namespace 內的邏輯名稱（例如 payments-api）。
• Endpoint — 註冊在 service 下的具體 address:port，附帶選填的 metadata key/value（版本、region、權重）。

gcloud service-directory namespaces create prod --location=us-central1
gcloud service-directory services create payments-api \
  --namespace=prod --location=us-central1
gcloud service-directory endpoints create v1-instance-1 \
  --service=payments-api --namespace=prod --location=us-central1 \
  --address=10.20.30.40 --port=8443 \
  --metadata=version=1.4.2,region=us-central1

Service Directory zones for DNS

Service Directory 透過「Service Directory zone」整合 Cloud DNS。建立一個由 Service Directory namespace 支援的私有 DNS zone，每個 service 就會自動可解析為 service.namespace.cloud.dns.suffix。

安全性效益

• IAM 守門的讀取 — 只有具備 servicedirectory.endpoints.resolve 權限的呼叫者才能查到 endpoint。對比公共 DNS 任何網際網路用戶端都能 dig。
• 稽核 log — 每次解析都記在 Cloud Audit Logs，留下哪個服務呼叫哪個服務的鑑識軌跡。
• 沒有硬寫 IP — 當 IP 改變（例如 autoscaler 換掉一台 VM），註冊中心原子更新，不需要 rolling restart。

Cloud DNS 與 DNSSEC

Cloud DNS 是 Google 的權威 DNS，提供公開 zone、私有 zone、forwarding zone 與 peering zone。對安全架構最重要的兩個功能是：DNSSEC 確保紀錄完整性，DNS policy 控制出站流量。

公開 zone 的 DNSSEC

DNSSEC 簽署每個 DNS 回應，resolver 可以驗證紀錄沒有在傳輸中被竄改。在 managed zone 啟用：

gcloud dns managed-zones create example-com \
  --dns-name=example.com. --visibility=public \
  --dnssec-state=on \
  --denial-of-existence=nsec3

啟用後，取得 DS record 並到域名註冊商發布 — 沒有那條 DS 連結，resolver 無法完成信任鏈。

gcloud dns dns-keys list --zone=example-com \
  --format='value(ds_record_data)'

私有 zone、forwarding、split-horizon DNS

• 私有 zone — 只在指定 VPC 內解析內部紀錄。
• forwarding zone — 把查詢轉送到地端 DNS server（例如 corp.internal）。
• peering zone — 讓一個 VPC 解析另一個 VPC 的私有 zone（hub-and-spoke 常用）。

DNS policy 控制進出流量

DNS policy 可以啟用 inbound DNS forwarding（讓地端用戶端透過 region 保留 IP 查詢 Cloud DNS），或強制特定 zone 的 outbound forwarding。

Network Connectivity Center：大規模 hub-and-spoke

Network Connectivity Center (NCC) 是 GCP 的託管 hub-and-spoke 連線架構。它讓你不必為每對 VPC、每個地端站點建立兩兩的 peering，而是提供一個邏輯 hub，連結多種類型的 spoke。

Spoke 類型

• VPC spoke — 直接附加到 hub 的 VPC（取代全 mesh 的 VPC peering）。
• Hybrid spoke — HA VPN tunnel 與 Cloud Interconnect VLAN attachment。
• Router appliance spoke — 第三方 SD-WAN/NGFW VM（例如 Cisco、Palo Alto）。

模式

• Mesh mode — 每個 spoke 都可以跟其他 spoke 通訊（transitive）。
• Star mode — spoke 只能到 hub（例如集中檢視 VPC）。

gcloud network-connectivity hubs create global-hub \
  --description="Corp hub-and-spoke"
gcloud network-connectivity spokes linked-vpc-network create prod-vpc-spoke \
  --hub=global-hub --vpc-network=prod-vpc \
  --global
gcloud network-connectivity spokes linked-interconnect-attachments create dc-interconnect \
  --hub=global-hub --region=us-central1 \
  --interconnect-attachments=projects/host/regions/us-central1/interconnectAttachments/vlan-1

為什麼 NCC 適合安全架構

• 集中檢視 — Star mode 強制 spoke 之間的流量穿過跑第三方 NGFW 或 Cloud IDS 的 hub VPC，提供東西向檢視的單一瓶頸點。
• 維運簡化 — N 個 spoke 只需要 N 條 attachment，而不是 N×(N-1)/2 條 peering。
• 跨 region — VPC spoke 全球互通，不需要為不同 region 設自訂 route。

Network Intelligence Center：可觀測性與驗證

Network Intelligence Center (NIC) 是 GCP 網路的診斷與驗證工具集。它不是執行階段的 data-plane 元件 — 它是每位架構師在出事之前就該知道存在的控制平面觀測站。

五個模組

1. Network Topology — 自動產生的 VPC、子網、VM、負載平衡器與流量圖。用來查「沒料到的 egress 是從哪裡來的？」很好用。

2. Connectivity Tests — 合成可達性檢查。你指定來源（VM、IP、GKE pod）和目的地，NIC 模擬封包穿過防火牆、route、NAT 的路徑，回傳結論（REACHABLE 或 UNREACHABLE 並附原因，例如「被 firewall rule deny-ssh-from-internet 擋下」）。

gcloud network-management connectivity-tests create web-to-db \
  --source-instance=projects/p/zones/us-central1-a/instances/web-1 \
  --destination-instance=projects/p/zones/us-central1-a/instances/db-1 \
  --destination-port=5432 --protocol=TCP

3. Performance Dashboard — region 與 zone 之間的封包遺失率與延遲，資料來自 Google 內部探針。用來確認「是網路問題還是應用問題？」

4. Firewall Insights — 標記未使用、被遮蔽、權限過寬的防火牆規則並給建議。輸出例：「rule allow-all-ssh 60 天沒命中任何封包 — 建議移除。」

5. Network Analyzer — 主動掃描配置問題（例如「子網 5 天內會耗盡 IP」、「VPN tunnel MTU 不一致」）。發現會自動出現，不需要手動執行。

何時用哪一個

• 「為什麼 VM A 連不到 VM B？」→ Connectivity Tests
• 「哪些 firewall rule 可以安全刪除？」→ Firewall Insights
• 「我們是不是快沒 IP 了？」→ Network Analyzer
• 「給我看實際流量模式」→ Network Topology

PCA 題目若在複雜 Shared VPC 環境裡問連線排查，Connectivity Tests 幾乎都是正解 — 它在模擬時評估的是當下實際的規則集，不是過時的設計文件。

實作模式：「安全的中樞和輻射 (Secure Hub and Spoke)」

大型企業常見的架構模式是使用 Shared VPC 的中樞和輻射 (Hub and Spoke) 模式。

• 中樞 (Hub): 包含集中式的安全性設備（如果使用第三方）、Cloud IDS 和集中式記錄。
• 輻射 (Spokes): 為不同業務單位建立的隔離專案。
• 安全性效益: 集中管理網路出口點，並簡化組織層級政策的套用。

**架構師的選擇：**在 PCA 考試中，如果您需要為遠端員工提供對內部應用程式的安全存取，且不希望產生 VPN 的負擔，答案幾乎總是 Identity-Aware Proxy (IAP)。 ::

常見問題 — 網路安全性設計

Q1. 防火牆規則與 VPC Service Controls 有什麼區別？

防火牆規則控制 VM 之間的網路流量（IP、連接埠、通訊協定）。VPC Service Controls 控制 Google 服務之間的資料流動 (API 呼叫)，特別是防止資料被外洩到未經授權的專案。

Q2. 我可以將 Cloud Armor 與網路負載平衡器搭配使用嗎？

Cloud Armor for Network Load Balancers 確實存在，但只支援有限規則集（rate limiting、威脅情報、具名 IP 清單）。要完整 WAF 防護 — 包含 OWASP 預設規則 — 必須使用 proxy 型負載平衡器（Application Load Balancer）。

Q3. Shared VPC 比 VPC Peering 更安全嗎？

就安全性治理而言，通常首選 Shared VPC，因為它允許中央「網路管理員」控制所有連網，而「服務專案管理員」僅管理其應用程式。VPC Peering 是兩個網路之間的去中心化「交握」，在大規模情況下較難稽核。

Q4. 如何防範「零日 (Zero Day)」網頁攻擊？

啟用 Cloud Armor Adaptive Protection。它使用機器學習建立正常流量的基準，並自動產生規則來封鎖看起來像攻擊的異常尖峰。

Q5. VPC Service Controls 的「隱形成本」是什麼？

主要的「成本」是維運複雜性。一旦啟用，它可能會破壞合法的整合（例如第三方工具存取您的 BigQuery）。您必須在周邊內仔細配置輸入 (Ingress) 和輸出 (Egress) 規則。

最後的架構師提示

在 PCA 考試中，尋找關鍵字如「合規性 (Compliance)」、「資料外洩 (Data Exfiltration)」或「監管要求 (Regulatory Requirements)」。如果你看到這些，你的設計必須包含 VPC Service Controls。如果焦點是「面向公眾的網頁應用程式」和「攻擊」，請聯想到 Cloud Armor。始終針對最小權限原則 (Least Privilege) 進行設計 — 不要向世界開放連接埠 22 或 3389；請改用 IAP TCP Forwarding。