AWS帳號代開服務 AWS CloudFront與WAF配合防護網站安全

第一章：為什麼一定要把 CloudFront 與 WAF 放在一起

網站安全很少是單點問題。你可能已經有防火牆、已做了基本的身份驗證，也有後端的安全檢查，但攻擊者仍會從「入口」開始找縫。對現代網站而言，入口不再只是你的網頁伺服器那台機器，而是使用者與服務之間那段最靠近世界的路徑：DNS、TLS 連線、HTTP 請求的第一跳、以及你如何回應重複請求。

CloudFront 負責把流量導向最近的邊緣節點，並提供快取、壓縮、TLS 終止、以及連線層面的控制。它讓「同樣的請求」在邊緣被處理得更快，也讓你可以在更早的階段阻擋一部分不合理流量。

WAF（Web Application Firewall）則針對 HTTP(S) 請求內容做規則判斷：例如特定路徑、特定參數模式、異常 User-Agent、可疑 header 組合、或疑似掃描的字串特徵。WAF擅長「理解請求」並做細緻的拒絕或放行。

把兩者配合的關鍵在於：你要在「前面」先降低壓力，在「裡面」再做精準防護。CloudFront 提供速度與基礎治理，WAF 提供語意與策略。若只做其中一個，你不是缺少效能，就是缺少精準。

第二章：先盤點攻擊面，再決定規則要守什麼

在實作前，很多團隊會直接套用範本規則。但真正在現場落地時，真正的難題往往不是「WAF 能不能擋」，而是「擋了以後會不會擋到正常人」。因此先盤點攻擊面，才能讓規則有方向。

建議你從以下幾個角度盤點：

• 入口路徑：例如登入、註冊、忘記密碼、查詢訂單、上傳 API、搜尋頁。這些通常是攻擊重點。
• 方法類型：GET 是否會帶出敏感資訊？POST 是否容易被嘗試注入或暴力嘗試？PUT/DELETE 是否有授權漏洞？
• 參數與格式：id、token、email、query 參數有沒有可預期的格式？例如 UUID、數字範圍、固定長度 token。
• 回應行為：你是否對錯誤回應過於詳細？是否回傳相同錯誤訊息給不同狀況？這會影響攻擊者的判斷成本。
• 使用者行為：正常的請求頻率、是否有行動裝置/爬蟲/合作夥伴需要白名單。

盤點後你會發現：你要防的不是「所有攻擊」，而是「你最常遇到、也最容易被誤傷的那一批情境」。規則越早明確，後續調參就越可控。

第三章：CloudFront 的基礎設定決定你後續有多好防

CloudFront 本身不是 WAF，但它的行為設定會影響 WAF 的觸發範圍與效能。實務上，建議把網站按「資源類型與風險」切成不同行為（Behaviors），再對不同行為套不同策略。

3.1 行為（Behavior）切分原則

• AWS帳號代開服務 靜態資源行為：例如圖片、CSS、JS。通常快取時間可較長，並降低對原站的壓力。
• AWS帳號代開服務 動態頁面行為：例如商品詳情、個人化頁面。快取較保守，WAF 更需要精準規則。
• API 行為：例如 /api/*。通常應以不同策略處理：更常需要限制速率、驗證 header、阻擋可疑內容。

這樣做的好處是：你把 WAF 的規則落在真正需要的行為上，減少不必要的誤判，也降低維護成本。

3.2 快取策略與安全性的取捨

很多人以為快取是「只為了速度」。但快取也會影響安全。

• 避免快取敏感內容：個人化頁面或包含權限資訊的回應，必須確保不被不當快取。
• 處理不同 Cookie/Query：若回應依賴 Cookie 或特定 Query 參數，快取 key 的配置要正確，否則可能造成資訊外洩風險。
• 快取降低 DDoS 壓力：當攻擊請求重複且命中快取，原站負擔下降，系統更不容易被打到崩潰。

在設計快取時要謹慎：快取能防止「重複打爆」，但不該拿錯誤的快取鍵導致「錯誤的人看到別人的內容」。

3.3 TLS 與標頭策略（間接影響 WAF）

WAF 的判斷通常基於 request headers、uri、query string、body（視設定而定）。因此在 CloudFront 層級你要確保：

• 必要的 header 能正確傳遞到 WAF 或至少在 CloudFront 觸發階段可被看到。
• 不要在前段做過度改寫導致 WAF 規則失效。
• 對外公告的安全策略（如 HSTS 等）要保持一致，減少攻擊者利用差異。

第四章：WAF 規則怎麼設，才能既擋得住又擋得對

WAF 的價值在於「規則」。但規則的生命週期很長：部署後會遇到誤擋、攻擊策略變動、行為變化、以及新版本前端帶來的參數格式差異。所以你需要一套設計邏輯。

4.1 規則分層：先擋粗暴，再處理精準

實務上可以把規則分成幾層：

• 層一：明確拒絕：不可能的 pattern，例如明顯不合法的 header 組合、明顯嘗試走內網路徑、或對應到已知惡意字串的嚴重特徵。
• 層二：風險提升（Count / 審核）：對可疑但不確定的請求先用計數模式觀測，確認誤傷率，再改為拒絕。
• 層三：行為限制：針對登入、註冊、上傳 API 做速率限制與併發控制。
• 層四：例外（Exception）：為特定合作夥伴、合法爬蟲或已知客戶行為設白名單，但白名單要有範圍與條件，而不是全域放行。

這種分層能避免你一開始就把所有規則都設為「Block」，結果是正常使用者大量回報錯誤。

4.2 速率限制：防暴力破解與惡意重試

最常見也最有效的防護之一是速率限制。攻擊者通常不只做單次嘗試，而是透過大量重試探測系統。

建議你在 WAF 中針對以下場景做限流：

• 登入與驗證端點：同一 IP / 同一用戶識別（若可用）在短時間內的嘗試次數。
• 重置密碼端點：避免被當成垃圾訊息工具。
• 上傳 API：避免被打爆頻寬與後端資源。

同時注意：限流粒度要小心。若站在 IP 維度，可能會把 NAT 環境下的正常使用者一起限住；若能使用其他可用識別（例如特定 token 或 header 特徵），就更精準，但也更需要維護。

4.3 Bot 控制：不是把所有機器都擋掉

對網站來說，機器並不全然是壞的。搜尋引擎、監控系統、合作夥伴 API、甚至內部的批次任務都可能以機器身份存取。

因此 Bot 控制的思路應該是「降低可疑機器的成功率」而非「全擋」。在 WAF 中你可以採取：

• 對明顯不符合正常瀏覽特徵的請求給予較嚴格限制。
• 對高頻但行為特徵不一致者先計數觀測。
• 針對必要的合法機器，建立白名單並限制可訪問路徑。

當你真的要封掉某類機器時，最好是先確認「誤傷比例」再切到拒絕模式。

AWS帳號代開服務 4.4 內容判斷：針對參數與路徑建立規則

真正造成安全事件的常見攻擊包含注入、路徑穿越、惡意腳本嘗試、以及利用參數格式繞過後端檢查。WAF 的內容判斷要做得「像驗證，而不是猜測」。

建議你使用以下邏輯建立規則：

• 路徑固定：例如只允許 /api/login 這種特定路徑存在，其他相近路徑若不該存在就拒絕或交由應用層處理。
• 參數格式驗證：UUID、數字範圍、email 格式、token 長度。比起用長串惡意關鍵字，格式比對更穩定。
• 敏感操作加強條件：例如上傳 API 必須出現 Content-Type、必要的 header、且 body 大小在合理範圍。

當你把規則寫成「只允許合理的格式」時，攻擊者就很難透過變形繞過。

第五章：把 WAF 接到 CloudFront 的正確姿勢

WAF 通常是附著在 CloudFront 分配（distribution）或特定資源路徑上。做得好的關鍵在於「範圍」與「優先順序」。

5.1 優先順序：先命中高價值規則

當多條規則同時可能命中，WAF 會依優先順序或規則集合策略決定最終動作。你要讓：

• 高風險、明確的規則排在前面。
• 針對特定端點的規則排在通用規則前面。
• 例外（allow/exception）一定要精確，且放在不會讓整體策略失效的位置。

5.2 規則集合（Rule Groups）的維護

隨著時間累積，規則會變得很長。此時你應該把規則拆成邏輯模組，例如：

• 通用威脅規則（common threats）
• API 端點規則（api protections）
• 登入/驗證規則（auth protections）
• 上傳與檔案規則（upload protections）

AWS帳號代開服務 這樣做的好處是：你可以對不同模組調參、回滾與審核，降低整套策略被一個改動牽連。

第六章：日誌、告警與迭代才是真正的防護能力

很多防護只做到「擋住」，但真正運維角度你要做到「知道為什麼擋住」以及「擋住後發生什麼」。沒有可觀測性，安全策略就像盲打。

6.1 WAF 日誌：用事件驅動而不是憑感覺

把 WAF 的日誌導入到可檢索的系統，至少能回答三件事：

• 被擋的請求是什麼：來源 IP、路徑、方法、參數樣貌（注意遮蔽敏感資料）。
• 擋掉是否影響正常用戶：對比 4xx/5xx 比例、特定端點的錯誤率、以及特定地區或裝置類型的變化。
• 攻擊是否持續：同類型命中是否在短時間內大量出現。

你會發現，很多「誤傷」並非規則錯了，而是你沒有充分觀測規則的作用範圍。

6.2 告警策略：設定不只封鎖，而是觸發調查

AWS帳號代開服務 告警不應只在「發生阻擋」時才觸發。更好的告警是：

• 某端點 Block 量在短時間內突然上升：可能是攻擊升級或規則命中過多。
• 特定地區或 ASN 的異常上升：可能是針對性掃描。
• 與業務指標同步的異常：例如登入失敗率飆升同時 Block 增加。

當告警觸發時，你要能快速定位到「命中哪條規則、對哪個路徑、影響哪一類使用者」。

AWS帳號代開服務 6.3 迭代流程：先 Count、再 Block、最後調參

落地的推薦流程是：

• 第一週：以 Count 模式收集命中資料，建立基線。
• 第二週：針對明確高風險類型改成 Block，但保留回滾方案。
• 第三週：檢查誤傷，對例外與格式判斷做調整。
• 持續：每次前端改版或 API 參數變更，回到觀測資料確認規則是否要更新。

安全不是一次完成的工程，而是可持續調參的系統。

第七章：常見誤區與實務解法

7.1 把規則全部設 Block：最常見的翻車方式

很多團隊在上線前缺少觀測，直接把規則都設成拒絕。結果就是：你擋到了攻擊，也擋到了正常行為（例如某些合法的瀏覽器、特定地區的網路設備、或第三方服務）。

解法是分層策略：先 Count，建立基線，再逐步 Block。

7.2 只看安全事件，不看使用者體驗

當你封掉某類攻擊，可能也封掉了某種可用的來源（例如企業代理伺服器）。如果你只盯 WAF 命中數，不盯轉換率、登入成功率，你會在不知不覺中破壞業務。

解法是把安全指標與業務指標一起看：例如登入錯誤率、API 成功率、前端錯誤回報。

7.3 忽略快取與授權：讓安全變成新的風險

快取設定錯誤可能造成資訊外洩。你以為 WAF 擋住了惡意請求，但一樣可能因為錯誤的快取鍵把不同使用者的回應混在一起。

解法是對個人化內容的快取策略保持謹慎，並確認 CloudFront 與應用層的授權邏輯一致。

第八章：一套可落地的導入方案（從零到可運維）

下面提供一套「比較不容易失控」的導入順序。你不需要一次做到完美，但要能持續改善。

8.1 第一步：找出高風險端點與資料流

AWS帳號代開服務 列出登入、註冊、驗證、上傳、查詢等端點，並標記哪些依賴 Cookie、哪些依賴特定 header。這一步決定你的 WAF 規則要套到哪個行為。

8.2 第二步：建立最小可用的規則集合

起手式不要太多，至少包含：

• 對明顯不合法的請求做 Count（或溫和拒絕，視你的容忍度）。
• 對登入/驗證做速率限制（先 Count，確認誤傷再 Block）。
• 針對 API 的基本格式（如必要 header、content-type）做檢查。

目標是先讓你能看見攻擊與誤判，而不是立刻把流量全擋掉。

8.3 第三步：導入告警與回滾機制

規則上線前要先定義：

• 如果某端點 Block 量在 10 分鐘內超過基線的幾倍，通知誰。
• AWS帳號代開服務 如果登入成功率下降，如何快速回滾到上個版本。
• 如何把疑似攻擊請求保留證據（例如摘要資訊而非完整敏感 body）。

沒有回滾機制，調參就變成賭博。

8.4 第四步：逐步擴展到更多端點與更精準的內容檢查

當你累積了足夠的命中資料，就可以把規則從「粗暴阻擋」提升為「精準驗證」。例如把注入類型從關鍵字掃描，逐步改為參數格式與上下文判斷。

同時記得：每次 API 參數或前端行為改版，都要對照 WAF 記錄確認是否新增誤傷。

第九章：把安全做成日常，而不是危機

CloudFront 與 WAF 的配合，本質上是把安全從「事件」變成「流程」。你透過 CloudFront 在邊緣降低不必要負擔，透過 WAF 在應用層做語意判斷，並透過日誌與告警讓調整不靠猜測。

真正的安全運維關鍵不在於你能一次寫出完美規則，而在於你能持續回答三個問題：第一，這條規則擋的是什麼？第二，擋了會不會傷到正常使用者？第三，攻擊是否在演化，我們的規則有跟上嗎？

只要你把這三件事當成日常工作，CloudFront 與 WAF 就不會只是「一套設定」，而會變成網站防禦能力的一部分：穩定、可觀測、可迭代。

結語：下一步你可以先做什麼

如果你現在還沒有把 CloudFront 和 WAF 形成聯動，建議你從最小範圍開始：先把登入與 API 端點加上 WAF 的速率限制與基本內容檢查，先用 Count 模式觀測，再逐步擴大到其他高風險路徑。當你看見了命中資料，你就擁有調參的依據，也擁有做出安全決策的節奏。