擋掉針對網站程式與 API 的攻擊，降低對外服務被攻破或被癱瘓的風險。依流量來源與系統位置評估防護部署位置，並負責規劃、建置、遷移、教育訓練與年度維護。
對外網站、App 後端與 API 是企業唯一必須開門給所有人進來的地方。防火牆擋得住不該連進來的連線。但從正門走進來、看起來完全正常的惡意請求，它擋不住。
在輸入欄位塞進一段指令，讓程式誤當命令執行，讀走資料庫或植入惡意腳本。走正常 HTTPS 通道，防火牆看不出異常。
大量被綁架的裝置同時湧入。塞爆線路的網路層（L3/L4）與專打程式的應用層（L7），處理方式不同。
搶票程式、比價爬蟲、拿外洩帳密逐組試登入的帳密填充。請求格式合法，只是不像人。
多數企業說不清自己對外開了幾支 API。改版後忘了關的舊版本仍可呼叫，是最安靜的外洩路徑。
結帳頁掛著第三方 JavaScript，只要一支被竄改，卡號就在送出時被複製走。網站本身沒有異常紀錄。
這三個名詞常被混在一起講，但它們站在不同位置、做完全不同的事。把資訊系統想成一棟大樓就很好懂。
它看的是「這個人可不可以進這棟大樓」，依據是來源位址、通訊埠與通訊協定。問題在於：對外網站本來就必須開放 443 埠給所有人。只要對方從大門正常走進來，警衛沒有立場攔。
警衛放行之後，WAF 會把訪客填寫的內容一個字一個字看過。它懂網頁程式的語言，看得出「姓名」欄位填的不是名字，而是一段要偷資料庫的指令。防火牆看不懂這一層，對它而言那只是格式正確的網頁流量。
把資料先複製一份放到離客人最近的分店，客人不必跑到總部。它解決的是「快不快」，跟「安不安全」無關。但所有客人都會先經過分店，那裡就成了設檢查哨最理想的位置。雲端型 WAF 大多長在 CDN 上，原因就在這裡。
防火牆管「誰可以進來」，WAF 管「進來的人帶了什麼」，CDN 管「客人要跑多遠」。三者角色不同，不能互相取代。
更完整的白話說明：WAF 是什麼？防火牆、WAF、CDN 差在哪？
業界把前四件事打包成一個名詞：WAAP（Web Application and API Protection，網站應用與 API 防護），也就是 WAF、DDoS 防護、Bot 管理與 API 防護。第五項前端／客戶端防護多半另行採購，但同樣是對外服務要顧的範圍。
「要買哪一套 WAF」這個問題，功能表給不了答案。要看的是您的流量從哪裡來、系統放在哪裡。
防護發生在網際網路邊緣。您不需要買任何設備，只要把網址（DNS）指向 Akamai。使用者連您網站時，都會先經過 Akamai 的機房，攻擊在那裡就被清掉。乾淨且加速過的流量，才送到您的伺服器。適合對外流量大、面向不特定大眾、停機成本高，或有海外使用者需要加速的服務。
相關產品：App & API Protector、Prolexic、Bot Manager、Akamai API Security、Client-Side Protection & Compliance。
設備放在您自己的機房，流量從頭到尾不離開。它原本就是站在伺服器前面的分流器（ADC，應用交付控制器），WAF 則是同一台機器上的模組。不必改網路架構就能加上防護，一筆採購同時解決「不能斷」與「不能被打」。適合資料不可出境、稽核要求流量可控，或已有 BIG-IP® 應用交付控制器想加上防護的客戶。
另有 F5 Distributed Cloud 與跟著容器部署的 F5 WAF for NGINX®。
從硬體、虛擬機、容器到雲端 SaaS（FortiAppSec Cloud，原名 FortiWeb Cloud）都有對應形態，可直接放在您的機房或雲端環境。FortiWeb 有自己的管理介面，也可納入 Fortinet Security Fabric（資安織網）。日誌集中送到 FortiAnalyzer，統一分析並產出稽核報表。適合中型企業、內部與 B2B 系統，或已採用 Fortinet 生態、希望日誌與稽核報表集中在同一套體系的客戶。
三者可以並存。常見架構是 Akamai 在外層吸收大流量攻擊，F5 或 FortiWeb 在機房內做最後一道防線。選型看流量規模、機房現況、法遵要求與既有設備，一個需求對應一個主方案。判斷邏輯見 WAF 怎麼選？三種情境對照；三家原廠的產品線說明請見 Akamai、F5 與 Fortinet 品牌頁。
本公司透過台灣授權通路取得原廠產品與支援，並提供規劃、導入、遷移、教育訓練與年度維護服務。
除了擋「進來的流量」，另一個常被忽略的位置是「出去的查詢」。
內部電腦被植入惡意程式後，第一步通常是連回攻擊者的中繼站。而那一步一定要先做 DNS 查詢（把網域名稱換成 IP 位址）。URMAZI SENTRY（PDNS，Protective DNS，保護型域名防護）就站在這個檢查點。它可以與企業原有的 DNS 伺服器協同運作，也可以直接替換，完全在內部運行：
導入可先用旁路（TAP）模式鏡像 DNS 流量觀察，不動現有架構。確認後再切換為在線模式主動阻擋。這一層與 WAF 互補，不是替代。
實際適用哪些規範、哪個等級，依貴單位業務性質與主管機關認定而異。導入時依貴單位適用的法規要求對應，並提供設定紀錄與報表，作為稽核佐證。
WAF 不是買回來開機就結束的產品。真正的成本在「調到不會擋到自己人」與「持續跟上版本」。這兩件事都在交付與維護範圍內。
需要。防火牆判斷的是「這條連線可不可以進來」。對外網站的 443 埠本來就必須開放。針對網頁程式的攻擊走這條路進來，防火牆只會當成正常流量放行。WAF 檢查的是流量「內容寫了什麼」。兩者層級不同，不能互相取代。
誤擋是傳統 WAF 最常見的失敗原因。作法是先以觀察模式運行一段時間，排除誤判規則後再分階段開啟阻擋。網站改版時同步檢視規則，這是年度維護的主要工作之一。
會。雲端邊緣防護的原理就是讓流量先經過原廠的全球網路。若有資料不可出境或流量必須可稽核的要求，應優先評估地端方案。也可以只把公開網站流量走雲端、敏感系統留在地端。
雲端型方案的切換點在 DNS，通常可在離峰時間完成、不需停機。地端設備則要安排維護時段切換。時程長短主要看規則調校期，安裝本身影響不大。
一個需求對應一個主方案。建議書會寫清楚選型理由、與其他方案的差異對照，以及各自的適用條件與限制。若對外服務沒有登入、沒有金流，API 使用量也有限，建議書會直接建議先導入基本防護範圍。之後再依業務成長分階段擴充。
請留下聯絡方式與需求說明，工程師會與您聯繫，協助評估架構規劃、導入方式與年度維護範圍。