待更新：這組文章的概念篇與 Cloudflare 的實測紀錄都還在撰寫中。本篇先寫出整組文章的判讀機制與各篇要交付的判斷；各篇發佈之後，下面的內容表會換成連到那一篇的連結。

這篇說明一組關於邊緣安全事件的文章：網站放在 CDN 或 WAF 後面之後，請求在邊緣經過哪幾層處理、每一層的決定在事件紀錄裡留下哪些欄位、邊緣紀錄與源站 access log 怎麼分工、事件頁上的背景流量怎麼分類、各種處置（Block、Challenge、Log、Skip、限流）在紀錄裡代表什麼、哪些事件要即時告警而哪些定期翻閱，以及發現新的請求模式之後怎麼回寫成規則。判讀方法不綁定業者，Cloudflare 是貫穿各篇的實例，AWS WAF 與 Fastly 的對應欄位在各篇並列。

這組文章設定的讀者

讀者是替一個對外網站負責的工程師：網站已經放在 CDN 或 WAF 後面（或正在決定要不要放），手上有一個事件頁或一份匯出的紀錄，身邊沒有資安團隊替他判讀。他熟悉 HTTP、DNS 與自己網站的技術堆疊，缺的是判斷事件頁上幾百筆紀錄裡哪些跟自己的網站有關的經驗。典型的情境是有會員資料與訂單的小型電商或會員制網站，網站公開運作一段時間之後，負責的工程師定期翻閱事件頁。

請求在邊緣依序經過的處理層

各篇的判斷都建立在同一個機制上：請求在邊緣依序經過幾層處理，每一層各自做一個決定（放行、擋下、要求驗證、只記錄、跳過後面的層），被擋下或被攔住的請求不會到達源站。由這個機制推出三件事：

  • 邊緣紀錄與源站紀錄的分工：被擋下的請求只留在邊緣的事件紀錄裡，源站的 access log 沒有它們；被放行的請求兩邊都有紀錄。兩份紀錄各自涵蓋哪些請求，由請求在哪一層被處置決定，跟用哪一套記錄工具無關。
  • 事件的 Action 欄位：這個欄位記的是哪一層做了什麼決定，所以判讀一筆事件之前，要先知道它是哪一層留下的。
  • 事件頁上量最大的那一類：背景流量多半在最前面的幾層就被處置，所以事件頁上筆數最多的那一類，多半是對這個網站威脅最小的那一類；針對這個網站的請求，要從被放行或只被記錄的事件裡找。

讓流量一定先經過邊緣的前提，也就是源站主機只接受 CDN 來源的連線，寫在 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖；這組文章從流量進了邊緣之後寫起。

各篇交付的判斷與目前的狀態

文章（暫定標題）交付的判斷狀態
邊緣事件的處理層與紀錄欄位請求依序經過的處理層（DDoS 防護、託管規則、自訂規則、限流、bot 判定、AI 爬蟲控制）、每一層留下的事件欄位、邊緣紀錄與源站紀錄的分工撰寫中
背景流量的組成與分類漏洞掃描、撞庫登入、搜尋引擎爬蟲、經過驗證的 bot、AI 爬蟲；用自己的技術堆疊判斷哪些請求不可能命中這個網站；針對這個網站的訊號（命中真實路徑、集中在登入或結帳端點）撰寫中
處置的種類與它們留下的紀錄Block、Managed Challenge、JS Challenge、Log、Skip、限流，以及不阻斷請求的處置（AI Labyrinth）；不擋下請求的處置換到什麼；從驗證的通過率判讀誤擋撰寫中
邊緣事件的監控分級即時告警、定期翻閱、只留存三種處理的分界；有會員與訂單資料時要多看的訊號；各方案的保留期限與匯出方式；邊緣紀錄、源站紀錄與應用程式稽核紀錄的對照撰寫中
從事件回寫規則發現新的請求模式之後，先用 Log 處置觀察再改成擋下；規則放進版本控制；規則的退場；偵測規則的生命週期在邊緣這一層的做法撰寫中
Cloudflare 的實測紀錄測試網域經 Cloudflare proxy 指到一台雲端主機、收集數天的自然流量、事件頁的篩選、bot 功能與 AI Labyrinth 的開關、用 API 取出事件、通知設定撰寫中

Cloudflare 的實測紀錄發佈之後放在 Cloudflare WAF 的資料夾底下，因為那一篇操作的對象是 Cloudflare 這個業者。防護控制本身怎麼選、怎麼配置（流量清洗、速率規則、挑戰驗證、搶購機器人）不在這組文章的範圍；這組文章寫的是那些控制動作留下的紀錄怎麼讀、怎麼排進監控。