封包從 Internet 進來之後經過哪些系統、每個系統各管什麼、以及「單獨使用這些開源元件」與「接上 BeakPlatform」之後的處理方式有什麼差別。

共六篇，本篇是總覽與閱讀順序。

請先看過覺得適用再安裝，別一股腦的先裝先玩，生命美好時間有限。

一、先建立全景

整套架構只有兩台主機，與安裝章節用同一組位址。主機 A（192.168.0.111）裝 BeakPlatform，是「管制端」：收事件、跑案件流程、記錄決策。主機 B（192.168.0.112）裝 Integrated-WAF 安裝包，是「防禦端」：站在被保護網站前面擋攻擊、監聽網路、把事件送出去、再把平台核可的封鎖落地到自己的防火牆。被保護的網站可以是主機 A 上的平台本身，也可以是任何一台內網網站。

三條資料流方向不同，讀後面各篇時請隨時對照：(上一篇是單機，這張是雙機，請配合另一系列文件一起看 企業管理自動化與執行框架-以SOC運作為實例 )

兩個常被誤會的方向。第一，決策不是平台「推」到防禦端，而是防禦端主動輪詢；所以防禦端不必對外開任何接收埠，平台被入侵也無法直接對防禦端下指令。第二，Suricata 不在請求路徑上，它是旁路監聽，永遠不會擋任何封包；真正即時阻擋的只有 WAF（HTTP 層）與 nftables（IP 層）。

二、元件一覽：誰在哪一層、負責什麼

三、放行與例外：誰可以繞過哪一道檢查

資安人員聽到「白名單」直覺是一份 IP 清單，名單內的來源不受檢查。這套架構有八個「放行點」，但只有三個真的是這種 IP 白名單，其餘各有自己的業界名詞：可信代理管的是「信誰說的來源 IP」、禁封清單管的是「誰不得被封」、授權範圍管的是「這把金鑰能送什麼」、規則排除管的是「哪條路徑少檢查什麼」。混稱白名單會讓人拿錯工具，所以下表先標類型，再列原廠用詞。後面各篇提到時會註明是第幾條。

八個放行點不是八份要分開維護的名單。主機 B 上人手要改的只有 .env 兩行（ADMIN_IPS、TRUSTED_INGRESS_EXTRA），第 1、2、7 條由 install.sh --reconfigure 從同一個 ADMIN_IPS 重新產生；第 4 條是決策的輸出，沒有人手維護；平台側三條各在自己的管理頁或 .env。

三個容易誤會的：
第 1 條只救「直連主機 B 本機程序」的流量，開了 --ssh-guard 又把自己排除在 ADMIN_IPS 外時它救不了 SSH；
第 5 條在平台端做一次，防禦端不帶本地副本，所以改了保護清單不必動主機 B；
第 1、2、7 條只支援 IPv4，ADMIN_IPS 要填 IPv4 位址；主機 B 發布的埠也只綁 IPv4（0.0.0.0），IPv6 連不進這些埠，不會繞過來源管制。CrowdSec 也有內建 whitelist，出廠只含本機回送位址，本架構沒有另外擴充。

四、一句話版本的運作原理

攻擊進來時，WAF 當場擋掉，這件事不需要平台。平台介入的是「擋掉之後」：把這次攻擊變成一張有人負責、有時限、有紀錄的案件，由人或流程決定要不要進一步封鎖來源 IP，封多久，然後把決定落地到防火牆，到期再自動解除。單獨使用這些開源元件時，前半段一樣會發生，後半段完全不存在。

後面五篇依序展開：封包經過哪些站（第 1 篇）、每一站看什麼（第 2 篇）、告警怎麼變成決策再回來（第 3 篇）、有沒有平台差在哪（第 4 篇）、這套設計信任誰、看不到什麼（第 5 篇）。