Cloud IDS（入侵偵測系統）

簡介

Cloud IDS 是 Google Cloud 的代管式網路型入侵偵測服務，使用 Palo Alto Networks 威脅偵測引擎來檢查 VPC 流量的鏡像副本，找出惡意軟體、間諜軟體、命令與控制（C2）回呼、橫向移動嘗試、針對已知 CVE 的攻擊流量，以及違反原則的協定。關鍵在於：Cloud IDS 是純偵測 out-of-band——它不在資料路徑上、不丟棄封包、不對正式流量增加延遲。它消化由 Google Cloud Packet Mirroring 產出的流量副本，並把警示送到 Cloud Logging 與 Security Command Center（SCC）。

對 PCNE 考試而言，當情境同時要求深層封包檢查、PCI-DSS / HIPAA 合規佐證，以及流量不得被阻擋或拖慢時，Cloud IDS 就是標準答案。它不是用來回答「在邊緣阻擋此攻擊」（那是 Cloud Armor），也不是用來「在 subnet 之間做東西向過濾」（那是階層式防火牆政策）。本研讀筆記涵蓋 Cloud IDS endpoint、鏡像政策、簽章類別、嚴重度分級、吞吐量級別、SCC 整合、底層的 VPC peering 機制、警示路由至 Pub/Sub、例外清單，以及考試最愛考的 out-of-band 部署模式。

白話文解釋（Plain English Explanation）

Cloud IDS 的術語——endpoint、鏡像政策、嚴重度、例外、producer VPC——相當密集，先用三個比喻把概念固定住，再進入 gcloud 指令與欄位細節。

比喻一：飯店監視器加上下班巡警

想像一間繁忙的飯店。大門門鎖是你的 VPC 防火牆政策——刷卡才能進入。大廳監視器是 VPC Flow Logs——它錄下誰進出、停留多久、帶了幾個包包，但看不到包包裡是什麼。Cloud IDS 則是飯店僱用的下班警官：這位警官不檢查門禁卡（那是門鎖的工作），也不主動阻擋任何人（因為他下班了，技術上只是觀察者），但他受過數十年訓練、能辨識可疑行為。飯店把大廳監視畫面的副本轉播到警官的螢幕（那就是 Packet Mirroring）。當他看到有人想撬自動販賣機，或臉孔比中通緝名單（即 Palo Alto Networks 簽章命中），他就用無線電通知飯店經理（即 Security Command Center 發現），由飯店決定要不要派駐場保全動手（即你透過 Pub/Sub 串接的自動化管線）。警官從不碰觸任何房客——Cloud IDS 從不碰觸任何封包。

比喻二：郵件室 X 光機 vs. 寄件地址貼紙

比較兩種檢查公司郵件室包裹的方法。運送標籤（寄件人、重量、收件部門）就是 VPC Flow Logs 看到的——5-tuple 中介資料：來源 IP、目的 IP、port、protocol、bytes。這足以偵測「某部門收到的郵件量比平時多十倍」，但完全看不出裡面真正有沒有威脅。X 光機就是 Cloud IDS——它檢視包裹內部：爆裂物、違禁品、惡意軟體 payload、攻擊簽章。X 光機架在與正常分揀帶平行的另一條輸送帶（out-of-band Packet Mirroring），所以包裹不會被耽誤。X 光機若比中已知威脅簽章，就會依危險程度點亮顏色燈號——綠燈代表 Informational、黃燈 Low、橘燈 Medium、紅燈 High、閃爍紅燈 Critical——由郵件室主管決定怎麼處理。重點是：X 光機本身不會攔下包裹，它只產生警示。要攔下，需要另外的執行機制（Cloud Armor / 防火牆規則 / 由警示觸發的 SOAR playbook）。

比喻三：工廠分區煙霧偵測器網路

現代工廠依分區部署煙霧偵測器——A 產線、B 產線、化學品儲存、出貨碼頭。每個偵測器各盯自己的分區，辨識不同的煙霧簽章（塑膠燃燒 vs. 電氣火災 vs. 溶劑火災），統一回報中央面板。Cloud IDS endpoint 就是分區煙霧偵測器：你每個 region、每個 VPC 一個 endpoint，再用鏡像政策指定哪些區域（subnet / instance group）把鏡像流量餵進來。偵測器靈敏度就是你設定的嚴重度門檻——化學品儲存區的偵測器設定為連 Informational 等級的煙霧也響鈴，因為漏報後果嚴重；一般車間的偵測器可能只在 Medium 以上才響，避免操作員被誤報淹沒。例外清單就是維修班貼在面板上的白名單——「收貨日早上 6 到 8 點忽略堆高機排氣」——因為已經確認那種煙霧是無害且擾人的。和真實的煙霧偵測器一樣，Cloud IDS 不會自己滅火——它只發出警報，真正的處置由人或自動化執行。

Cloud IDS Endpoint —— 區域型檢查引擎

Cloud IDS endpoint 是部署單位。它是代管的區域型資源，Palo Alto Networks 檢查引擎跑在 Google 託管的 service producer VPC 之內，並透過 **Private Services Access（VPC peering）**連回你的 VPC。你看不到背後執行引擎的 VM——Google 全權管理擴充、修補與簽章更新。

Endpoint 建立與作用範圍

Endpoint 透過 gcloud ids endpoints create 建立：

gcloud ids endpoints create ids-east \
  --network=prod-vpc \
  --zone=us-central1-a \
  --severity=INFORMATIONAL \
  --threat-exceptions=12345,67890

--severity 旗標設定 endpoint 會送出警示的最低嚴重度。可選值由最囉嗦到最安靜：INFORMATIONAL、LOW、MEDIUM、HIGH、CRITICAL。建立 endpoint 通常需要 20–30 分鐘，因為如果該專案尚無 producer-VPC peering，Google 必須先建立 peering 連線。

Endpoint 是 region 級，鏡像是 zone 級

Cloud IDS endpoint 雖然建立在某個 zone，但其檢查覆蓋整個 region 內所掛載的 VPC 子網段。你可以掛載多個鏡像政策，但每個政策只鏡像單一 region 的流量。要檢查多 region 流量，每個 region 都要建一個 endpoint。

Endpoint 配額與限制

預設配額相當保守：每個專案 10 個 endpoint、每個 endpoint 5 個鏡像政策，同一個 VPC 的 region peering 關係只會建立一次並重複使用。最常見的部署阻礙就是撞到配額——記得提早申請配額提升。

Packet Mirroring —— 流量如何進到 Endpoint

Cloud IDS 不會憑空看到流量，它依賴 Packet Mirroring——另一個 VPC 網路功能，會複製選定的封包並轉發到收集端。當 Cloud IDS 作為收集端時，鏡像政策會自動偵測 endpoint 的 forwarding-rule 前端。

挑選要鏡像的來源

Packet Mirroring 政策可依下列方式挑選來源：

• Subnet：子網段內每台 VM 都鏡像。
• Instance：指定的 Compute Engine VM 清單。
• Tag：帶有特定網路標籤的 VM，例如 prod-web、pci-tier。 此外可依協定與 CIDR 過濾（tcp、udp、icmp、esp），讓 endpoint 只檢查南北向 HTTPS、忽略叢集內部的 gRPC。

鏡像的內容

ingress 與 egress 兩個方向的封包都會複製，含完整 payload。鏡像是真複本而非抽樣——Cloud IDS 會在 endpoint 吞吐量上限以內，完整分析 100% 的鏡像封包。

鏡像不影響正式流量

複本走 Google 網路內的平行路徑，原封包仍以全速送往真實目的地。鏡像對來源 VM 的 egress 配額影響極小——主要成本來自 Cloud IDS endpoint 小時費與檢查 GB 費。

跨 VPC 鏡像的限制

Packet Mirroring 政策與其收集端必須在同一個 VPC 網路。要檢查另一個 VPC 的流量，必須在該 VPC 內另建一個 endpoint——即使兩個 VPC 已 peer，也不能把 VPC A 的流量鏡像到 VPC B 的 endpoint。

Palo Alto Networks 簽章引擎 —— Cloud IDS 究竟偵測什麼

Cloud IDS 內部的引擎是 Palo Alto Networks Threat Prevention 內容集——與 PAN-OS NGFW 使用同一份簽章資料庫。簽章由 Google 在背景更新，你無法控制簽章版本。

威脅類別

• 漏洞攻擊：針對已知 CVE 的攻擊流量，例如 Log4Shell payload、Apache Struts OGNL injection、ProxyShell 攻擊鏈。引擎比對的是封包上的 byte 樣式，不是目的應用程式實際使用的版本。
• 惡意軟體：以 sha256 雜湊與行為簽章辨識的檔案型 payload，包含已知的 ransomware dropper、cryptominer 與 RAT。
• 間諜軟體 / C2：受感染主機的 C2 beacon 樣式，包括 DNS tunnelling、IRC C2，以及 HTTPS 中介資料啟發式比對（JA3 指紋、憑證異常）。
• Anti-spyware DNS：對 Palo Alto DNS sinkhole feed 中已知惡意網域的 DNS 查詢。
• 可疑協定：匿名化流量（Tor 握手樣式）、未授權的 VPN 協定，以及協定異常事件如畸形 TLS、HTTP smuggling。

解密邊界

Cloud IDS 只檢查明文。TLS 加密的 payload 對它而言是不透明位元組——只有 TLS 握手中介資料（SNI、JA3、憑證）能用。要檢查 HTTPS payload，必須在上游終止 TLS（外部 HTTPS Load Balancer 配 SSL Policy 與代管憑證，或在 instance 上自行解密），再鏡像解密後的流量。

簽章更新節奏

Palo Alto Networks 一週發行多次內容更新。Cloud IDS 會自動拉取——沒有簽章管理 API 給你操作。代價是：你無法 pin 或回滾簽章集；新簽章若造成誤報，你的選擇只有例外清單（依簽章 ID）或調高 endpoint 嚴重度門檻。

嚴重度分級 —— Informational、Low、Medium、High、Critical

每筆 Cloud IDS 警示都帶有 Palo Alto 引擎輸出的嚴重度。五個等級不是隨意命名——它們對齊 PAN-OS 慣例，也決定你如何在大量警示下做分流。

定義

• Informational —— 協定異常、可疑 header、低信心 DNS 名譽。誤報率高；只有當分析人員有餘力時才值得看。
• Low —— 偵察流量、port scan、banner grabbing。代表有人在找弱點但尚未實際攻擊。
• Medium —— 針對非關鍵漏洞的攻擊嘗試、可疑檔案下載。屬於「該處理但不必恐慌」。
• High —— 攻擊成功跡象、已知惡意 payload 簽章、橫向移動嘗試、常見 ransomware C2 回呼。
• Critical —— 對嚴重 CVE 的確認攻擊（例如邊緣服務 RCE）、活躍的資料外洩樣式、ransomware 加密迴圈簽章。

Endpoint 最低嚴重度

Endpoint 建立時的 --severity 旗標會在警示送出前丟棄低於門檻的警示。設為 --severity=MEDIUM 代表 Informational 與 Low 簽章仍會比中，但會被靜默丟棄；換來節省日誌量與 SCC 雜訊。

各環境分級調整

• 正式對外：用 LOW 或 INFORMATIONAL，讓 SOC 看到偵察、可預先阻擋。
• PCI / HIPAA 資料環境：用 INFORMATIONAL——稽核員要求完整可見性，且範圍較小、成本可接受。
• Dev / test：用 HIGH 抑制不代表真實風險的偵察雜訊。
• 從地端 lift-and-shift 過來的 VM：先設 MEDIUM、觀察兩週、再行調整。

吞吐量級別 —— 5、10、20 Gbps Endpoint

Cloud IDS endpoint 不以 VM 數量計量，而是依檢查吞吐量分級。建立時挑選等級；等級同時決定能力與費用。

可選等級

• 5 Gbps —— 入門級，適合小型機隊或 dev/test 環境。
• 10 Gbps —— 中階，單區域正式環境最常見的選擇。
• 20 Gbps —— 高階，適合把多個 spoke 鏡像流量集中到中央檢查點的 hub-and-spoke 架構，或高流量電商 / 串流 workload。

估算原則

規劃檢查容量為峰值鏡像流量的 2 倍。Packet Mirroring 同時送 ingress 與 egress；一個推 3 Gbps 南北向的 workload 已產生約 6 Gbps 鏡像流量，超過 5 Gbps endpoint。超過上限後 endpoint 會丟棄鏡像封包，靜默壓低偵測覆蓋率——預設不會有「buffer 滿」的警示。

撞到上限

機隊成長到超過 20 Gbps 時，架構解法是跨 endpoint 分片：依 tag 拆分鏡像政策（例如 tier-1 流量送到 endpoint A、tier-2 送到 endpoint B），讓每個 endpoint 都待在上限以下。跨 region workload 本來就會自動分片，因為每 region 需各自的 endpoint。

級別切換

切換等級不是 in-place——建立較大級別的新 endpoint、把鏡像政策指向它、再刪除舊 endpoint。請預留短暫的偵測空窗（或讓兩個 endpoint 並行一小時做 cutover 測試）。

Security Command Center 整合 —— Findings、Sources 與路由

Cloud IDS 是 Security Command Center（SCC）已註冊的安全來源。引擎輸出的每一筆威脅，會以結構化 SCC finding 的方式發布在 THREAT 類別中，並同時落地 Cloud Logging。

Finding 欄位

每筆 Cloud IDS finding 帶有：

• category —— Palo Alto 簽章類別（例如 vulnerability、spyware、c2）。
• severity —— LOW / MEDIUM / HIGH / CRITICAL（SCC 把 Informational 正規化為 LOW）。
• network —— 來源 / 目的 IP、port、protocol、應用識別（App-ID）。
• signature_id —— 數字型 Palo Alto 簽章 ID；這正是你放進例外清單的值。
• cvss —— 可得時提供。
• resource_name —— 由內部 IP 推導出的受影響 VM / instance。

SCC 級別要求

Cloud IDS finding 在 SCC 的所有級別（Standard、Premium、Enterprise）都會出現。Standard 雖看得到，但拿不到跨來源關聯。Premium / Enterprise 啟用後可走 SCC 的 notification module 做持續匯出與自動化 playbook，並與 Sensitive Data Protection 交叉比對。

把 finding 路由出 SCC

建立 notification config 後，SCC 會把新建與更新的 finding 發布到 Pub/Sub topic。從那裡：

• Cloud Functions / Cloud Run 可呼叫 API 進行修補（更新防火牆規則、隔離 instance）。
• 經由 Dataflow 進 BigQuery 給 SOC 分析。
• 經由 Pub/Sub pull subscription 進 SIEM（Chronicle、Splunk、Sumo Logic）。

Cloud Logging 路徑

獨立於 SCC，每筆 Cloud IDS 警示也會寫入 Cloud Logging，log name 為 cloudids.googleapis.com/threat。多數維運會建立 log sink 到 BigQuery 或 Pub/Sub，達到 30 天以上的保留。

VPC Peering 限制 —— Private Services Access 底層機制

底層上，你的 VPC 透過 VPC peering 連到 Google 託管的 service producer VPC。這個 peering 是用 Private Services Access 對每個專案、每個 network 建立一次——也因此帶來一連串你必須提早規劃的限制。

每個 VPC 一條 peering

特定 VPC 與 Cloud IDS service producer 之間只有一條peering 關係。第一個 endpoint 建立時建立 peering，後續 endpoint 重複使用。刪掉所有 endpoint 不會自動刪掉 peering——若要乾淨拆除，需明確刪除已配置的 IP 範圍。

已配置 IP 範圍

Private Services Access 需要你從 VPC 的位址空間配置一個 CIDR 區塊（/24 或更大）。IDS producer VPC 從這個區塊取走 IP。請挑一個不與任何現有或規劃中的地端 CIDR 重疊的區塊，因為未來的 VPN / Interconnect 路由不能與 producer VPC 路由衝突。

不允許 transitive peering

GCP VPC peering 不具遞移性。若你的 VPC peer 到 shared-services VPC、shared-services 又 peer 到 Cloud IDS producer VPC，你的 VPC 無法透過 shared-services 觸及 IDS endpoint。你必須在每個需要檢查的 VPC 各建一個 endpoint，或改用 Network Connectivity Center（使用 VPC Spoke、非 peering）設計 hub-and-spoke。

Shared VPC host 專案

Shared VPC 架構下，IDS endpoint 與鏡像政策放在 host 專案。service 專案的 VM 只要位於 host 專案的子網段，就能鏡像到 host 專案的 endpoint——不需要每個 service 專案各自建立 endpoint。

警示路由至 Pub/Sub —— 自動化的入口

Cloud IDS finding 唯有被某個東西處理才有維運價值。標準路徑是 SCC notification config → Pub/Sub → consumer。

設定 notification config

gcloud scc notifications create cloud-ids-critical \
  --organization=123456789 \
  --pubsub-topic=projects/sec-ops/topics/scc-findings \
  --filter='category="THREAT" AND source_properties.product_name="Cloud IDS" AND severity="CRITICAL"'

--filter 子句代表只有 Critical 等級的 Cloud IDS finding 會送到該 topic——High / Medium / Low 可路由到別的 topic 或直接進 BigQuery。

Cloud Functions 自動修補

訂閱該 topic 的 gen2 Cloud Function 可解析 finding、依 resource_name 查到受影響 VM，呼叫 compute.instances.removeAccessConfig（拔掉公網 IP）或更新防火牆規則拒絕出向。請保持回應邏輯具冪等性——SCC 在故障時可能重複投遞。

轉送至 SIEM

Chronicle 使用 Chronicle 擷取 API，搭配 Pub/Sub Dataflow 管線。Splunk 使用 Splunk Dataflow 範本，吃 Pub/Sub 輸入並輸出 HEC 事件。兩者皆完整保留 Cloud IDS finding 的 JSON，分析員可依 signature_id 鑽取。

Log-based metric 配 Cloud Monitoring

更簡單的警示路徑：對 cloudids.googleapis.com/threat 日誌依 severity 建立 log-based metric，再針對該 metric 建 Cloud Monitoring 警示政策。後端可走 Pub/Sub、PagerDuty 或電子郵件 / 簡訊。

例外清單 —— 噤聲誤報同時不失明

每個 IDS 部署都會遇到誤報——企業內部的弱點掃描器、被誤判為異常的內部自製協定、使用罕見 TLS 設定的合作夥伴整合。Cloud IDS 在 endpoint 上以**威脅例外（threat exception）**處理，俗稱例外清單。

例外如何運作

透過 --threat-exceptions 把以逗號分隔的 Palo Alto 簽章 ID 列表交給 gcloud ids endpoints。比中的警示會在離開檢查器前就被抑制——不會出現在 Cloud Logging、SCC，或任何下游管線。

找對的簽章 ID

簽章 ID 就是 Cloud Logging 警示條目中的 threat_id 欄位。先調查首次發生事件、與資產擁有者確認流量無害，再把 ID 加進例外清單。記下加入理由——稽核員會問每一條例外的成因。

例外是 endpoint 級、不是全組織級

例外是每個 endpoint 各自的清單，不是組織共用。在 dev endpoint 抑制簽章 12345，並不會在 prod 也被抑制。當你的掃描器跨環境執行時，這代表每個 endpoint 都要更新。

何時不該用例外

避免抑制 Critical 等級簽章。若 Critical 真的是誤報，應該修正上游流量（例如更新掃描器 TLS 設定使其不再觸發異常簽章）。Critical 例外清單冗長是稽核紅旗。

部署模式 —— 純偵測 Out-of-Band 架構

Cloud IDS 永遠是 out-of-band。所有有效部署都是同一個主題的變形：正式流量原封不動、鏡像副本送進 Cloud IDS、警示驅動非同步的回應管線。

模式一 —— 單一 VPC，邊界檢查

所有 workload 都在單一 VPC 時：一個 endpoint、一條依 tag internet-facing 過濾的鏡像政策。最便宜的設計，適合單一團隊的產品。

模式二 —— Shared VPC host 專案檢查

使用 Shared VPC 的組織：endpoint 與鏡像政策都在 host 專案，鏡像橫跨 service 專案的子網段。單一檢查點覆蓋整個共用環境。在受規範產業（金融、健康照護）裡，網路團隊擁有 Cloud IDS、產品團隊只負責產出鏡像流量，正是這個模式。

模式三 —— Hub-and-spoke（每個 spoke 各自 endpoint）

多 VPC 架構透過 peering 或 Network Connectivity Center 連接時：每個 VPC 各一個 endpoint，因為鏡像跨不過 peering。這是「peering 不具遞移性」這條規則逼出來的設計。較貴，但 VPC 必須隔離時是唯一可行形狀。

模式四 —— 多 region 正式環境

全球服務：每個 region 各一個 endpoint。在 Pub/Sub 路由設定上讓單一 SOC 透過單一 subscription 消化所有 region 的 finding。finding 上以 region 標籤路由給對應分析員。

純偵測是設計目的、不是限制

有些 PCNE 應試者試圖把 Cloud IDS「修」成 inline 模式。沒有 inline 模式。若需求是阻擋，答案應是 Cloud Armor（L7）、VPC 防火牆規則 / 階層式政策（L3/4）、Secure Web Proxy（出向 URL 過濾），或第三方 NGFW 如 Palo Alto VM-Series、Check Point CloudGuard。Cloud IDS 提供偵測 + 警示 + 稽核級佐證；修補則在其他地方。

日誌、監控與稽核佐證

對合規場景而言——PCI-DSS Req 11.4（持卡人資料網段需有入侵偵測）、HIPAA Security Rule §164.312(b)（稽核控制）、ISO 27001 A.13（通訊安全）——Cloud IDS 提供佐證軌跡。

Cloud Logging 保留

Cloud Logging 預設保留 30 天。為了合規，把 cloudids.googleapis.com/threat sink 到 Cloud Storage 留 7 年（PCI 要求記錄保留 1 年線上、1 年可取回，許多組織存更久），或 sink 到 BigQuery 兼具可搜尋保留與儀表板。

Cloud Monitoring SLO

內建好用的 metric：

• ids.googleapis.com/preprocessor/received_bytes_count —— 檢查器自鏡像接受的 bytes 量。
• ids.googleapis.com/preprocessor/dropped_bytes_count —— 因超過吞吐量上限被丟棄的 bytes。
• ids.googleapis.com/alert_count —— 發出的警示數，依嚴重度切分。 當 dropped_bytes / received_bytes > 1% 時觸發 SLO 警示——代表偵測覆蓋率正在流失，須升級等級。

稽核軌跡

所有 endpoint 的 CRUD 操作會寫入 Cloud Audit Logs，審閱者可看到何時嚴重度被調低、何時加了例外、何時 endpoint 被刪。請把 ids.endpoints.update 鎖到少數人，並要求嚴重度 / 例外變更走變更單。

費用結構

Cloud IDS 計費有三個維度：

1. Endpoint 小時費 —— 依吞吐量等級（5/10/20 Gbps）；無論有無流量都計費。
2. 檢查流量 —— 對實際被檢查的流量依 GB 計費。
3. Packet Mirroring 成本 —— 視跨 zone 設定，鏡像的 egress 資料可能產生費用。

控費技巧

• 過濾鏡像政策只覆蓋高價值層（tag pci、internet-facing），切勿在吵雜的 dev 環境鏡像一切。
• 非關鍵環境的 endpoint 嚴重度設為 MEDIUM，把低價值警示在進儲存前就丟掉。
• 使用 log sink 與排除過濾器把 INFORMATIONAL 條目移出長期保留。
• Shared VPC 架構集中在 host 專案一個 endpoint，不要每個 service 專案各自重複。

比較表 —— Cloud IDS vs. 鄰近服務

考試最愛把 Cloud IDS 塞進考生會直覺反射選 Cloud Armor 或 VPC Flow Logs 的列。記住三個特性——out-of-band、深層封包檢查、不阻擋——陷阱就好避。

常見 PCNE 考試情境

情境 A —— 偵測但不影響業務

「零售公司必須符合 PCI-DSS Req 11.4，且支付流程不能增加任何延遲。」答案：Cloud IDS 鏡像 PCI 分層。Cloud Armor 在資料路徑上，會帶來微小但非零延遲；題目要求零影響，且 PCI 明定 IDS 而非 WAF。

情境 B —— 加密流量

「稽核員要求對入向 HTTPS 做 DPI，但 Cloud IDS 只看到密文。」答案：在外部 HTTPS Load Balancer 用 SSL Policy 與代管憑證終止 TLS，然後鏡像後端 VM 上的解密後流量。Cloud IDS 自己不解密。

情境 C —— Hub-and-spoke 失靈

「三個 workload VPC peer 到中央 security VPC，團隊在 security VPC 裝 Cloud IDS 卻看不到 workload 的東西向流量。」答案：peering 不具遞移性，鏡像也跨不過 peering——每個 workload VPC 各裝一個 endpoint，或把 workload 搬進 Shared VPC。

情境 D —— Endpoint 在丟封包

「行銷活動後，流量翻倍但警示數量反而減半。」答案：5 Gbps endpoint 在丟鏡像 bytes；檢查 dropped_bytes_count，升級等級或把鏡像政策分片到兩個 endpoint。

情境 E —— 內部掃描器誤報

「企業弱點掃描器每天觸發某個 Cloud IDS 簽章。」答案：從 Cloud Logging 條目找出 signature_id，加進 endpoint 的 --threat-exceptions 清單，並記錄加入理由。

常見問題（FAQs）

問：Cloud IDS 會阻擋任何流量嗎？

不會。Cloud IDS 只做偵測。它消化流量鏡像副本、把警示送到 Cloud Logging 與 Security Command Center。要阻擋流量，需把 finding 串到 Cloud Armor、VPC 防火牆規則，或以 Cloud Function 回應 SCC 通知並更新拒絕規則。

問：Cloud IDS 能檢查 TLS 加密（HTTPS）流量嗎？

不能直接檢查——它只看得到密文。要檢查 HTTPS payload，必須在上游終止 TLS（外部 HTTPS Load Balancer 配 SSL Policy，或在 instance 自行解密），並確保 Packet Mirroring 抓的是解密後流量。TLS 握手本身（SNI、JA3、憑證）即便在加密 flow 上仍可檢視。

問：如何在多 region 部署 Cloud IDS？

每個 region 一個 endpoint。每個 region 都要有自己的 Packet Mirroring 政策，因為鏡像是 region 級。可用同一個 Pub/Sub topic 透過多份 SCC notification config 匯流所有 region 的警示，讓 SOC 看到統一的 feed。

問：鏡像流量超過 endpoint 吞吐量等級時會怎樣？

Endpoint 會靜默丟棄超量。不會自動升級。請監控 ids.googleapis.com/preprocessor/dropped_bytes_count，並依需求升級等級（5 → 10 → 20 Gbps）或依 tag 把鏡像政策分片到兩個 endpoint。

問：兩個 VPC peer 後能共用一個 Cloud IDS endpoint 嗎？

不能。Packet Mirroring 不允許跨 peering 收集。鏡像政策與 Cloud IDS endpoint 必須在同一個 VPC。替代方案是每個 VPC 各一個 endpoint，或整併進 Shared VPC、由 host 專案擁有唯一 endpoint。

問：如何抑制已知無害的內部掃描器警示？

透過 gcloud ids endpoints update --threat-exceptions=... 把掃描器命中的簽章 ID 加進 endpoint 例外清單。例外是 endpoint 級，所以掃描器跑過的每個 endpoint 都要更新。

問：Cloud IDS finding 要去哪做長期保留？

預設 Cloud Logging 保留 30 天。建立 log sink 到 Cloud Storage 做合規級封存（PCI / HIPAA），或 sink 到 BigQuery 兼具可搜尋保留與分析儀表板。獨立於此，SCC finding 可匯出到 Pub/Sub 後分流到 SIEM 如 Chronicle 或 Splunk。