Day 17 談的是資料量與儲存空間。除了要收多少，建置時還有另一個問題：如果客戶有好幾個據點，資料要在哪裡收，又要怎麼集中查看？

我過去接觸的做法，是在總公司建立中央平台，各分部部署 Sensor，把當地收集的資料送回來。這樣就能在同一個平台查看各據點的內容。

但資料集中後，我仍然需要知道它來自哪裡。收集出現問題時，要能找出是哪個分部；有告警需要回報時，也要說得出是哪個區域的事情。

這篇就從我實際做過的配置，談到資料收進來後的區分與確認。

先在分部收集，再送回中央

在我當時使用的 Stellar Cyber 架構裡，Sensor 負責收集與正規化，再把處理後的資料送回中央平台分析。

這是依照原廠的架構要求部署。我沒有做過繞過 Sensor 直接傳送的比較測試，因此這裡分享的是當時採用的配置，不把它當成所有 SIEM 都必須遵循的方式。

分部的 Sensor 透過網際網路，使用系統指定的連接埠與中央平台通訊。建置時，除了 Sensor 本身的設定，也需要配合開通這段通訊所需的防火牆規則。實際連接埠要依版本與功能確認，不能只照一張舊架構圖套用。

從這個配置來看，收集工作分散在各據點，資料則集中到總公司查看。這裡說的集中查看，是共用一個平台入口，不代表所有收集工作都在總公司完成。

分部有什麼，就先確認能收什麼

不同分部的設備與防護建置，不一定一樣完整。

我接觸過的資料來源包含 Mirror 流量、防火牆 Syslog、EDR，以及 Windows Agent 的資料。但並不是每個分部都有這些東西，有些據點比較小，實際收集的就只有 Mirror 流量與防火牆 Syslog。

即使是這樣的小分部，當地也會部署 Sensor。

因此，我在描述分部配置時，不能只寫「各據點都有收集」。還要說清楚每個據點收了什麼，才知道中央平台上預期會看到哪些資料。至於 EDR 與 Windows Agent 的具體接入方式，仍要依實際整合設定確認，不能一概畫成相同的傳送路徑。

以下是依前面經驗整理的示意，不代表特定客戶的完整配置：

把這件事想清楚後，就比較不會把「集中管理」理解成「每個據點都有一樣的資料」。

如果某個分部原本就沒有 EDR，在平台上沒有它的 EDR 紀錄，跟原本應該持續收到的 Syslog 突然消失，是兩件不同的事。前者是收集範圍，後者才需要往收集異常的方向確認。這是整理這次經驗時，我想特別說清楚的差別。

為什麼集中後，還要用 Tenant 區分？

我會在總公司的中央平台，將分部資料歸到對應的 Tenant。Tenant 中文常稱為租戶，在這篇的使用情境裡，可以先理解成平台中區分各分部資料的管理範圍。

Stellar Cyber 的 Tenant 管理文件也列有租戶名稱、ID、Sensor 數量與收集量等資訊。這裡著重的是我用它區分分部的方式，不代表 Tenant 只能用在分公司。
官方文件：Managing Tenants

為什麼要這樣分？因為我需要知道是哪個區域的資料出現問題，回報告警時，也要能說明告警來自哪個區域。

如果只看到整個平台持續有資料進來，仍然需要再確認各個分部的狀況。透過對應的 Tenant，我可以分別查看哪些分部有資料、哪些沒有，再對照它們原本應該收集的內容。

Sensor 的命名上，我也會加入分部資訊。這樣看到 Sensor 名稱時，就能先辨認它屬於哪個據點，再配合 Tenant 查看資料。

Tenant 的歸屬與 Sensor 名稱是兩件事：前者用來區分資料範圍，後者協助我辨認設備。只把名稱改得清楚，並不等於已經完成資料歸屬設定。

Sensor 設定好了，我還會回平台看什麼？

我平常會多次檢查收集結果。Sensor 設定完成後，會到中央平台確認是否能看到相關網路流量，以及 Syslog 解析後的資料或紀錄。

防火牆 Syslog 的部分，我還會看平台是否能辨識出正確的廠牌。

這裡有兩個不同的辨識工作：

平台認出防火牆廠牌，與知道它來自哪個分部，不能互相取代。對我來說，這兩件事都確認後，後續查看紀錄或回報問題才比較清楚。

這也不是說認出廠牌，就能保證每個欄位都完全正確。我這裡描述的是自己平常會做的收集與解析確認，不把它寫成完整的欄位驗證。

如果 Sensor 在線，卻沒有資料呢？

在前面談的多據點部署情境中，我沒有碰過這個狀況，所以這一段是我的排查方向，不是已處理過的故障案例。

如果真的發生，我會先往 Syslog 傳輸或 Mirror 是否有問題的方向查看。

原因是，Sensor 在線與資料來源有沒有送進來，是兩個需要分開確認的事情。前者是 Sensor 的連線狀態，後者則要回到實際收集結果來看。這也呼應前面 Day 15 談過的收集檢查。

我會先對照該據點原本要收哪些資料，再看缺的是哪一種。例如原本應該有防火牆 Syslog，就沿著那條傳送路徑確認；如果缺的是 Mirror 流量，就回到鏡像設定與連線檢查。這些是依目前做法整理出的檢查思路，不能只憑「沒有資料」就先認定根因。

回到多據點管理本身

這次回頭整理，我發現自己在建置時做的幾件事，其實可以接在一起看。

分部部署 Sensor，是為了依照使用中的架構收集當地資料；回到中央後，用 Tenant 與命名保留據點區分；最後再查看流量、Syslog 解析與防火牆廠牌辨識，確認收集結果。

其中，Tenant 對我最直接的用途，就是讓回報能說清楚位置。我要講的是哪個分部的告警、哪個區域的資料有問題，而不只是說「平台上有異常」。

資料集中到同一個畫面，讓查看更方便；每個據點收了什麼、資料是否正常進來，仍然要能分別確認。這也是我在規劃多據點收集時，會一起處理的事情。