API 業務的防護難題
API 服務的防護比傳統網站更棘手，因為它面對的不只是惡意攻擊，還有合法用戶的濫用：
- 無法用驗證碼阻擋——API 客戶端是程式，不是瀏覽器，人機驗證無法直接套用。
- 單一租戶可能拖垮全局——一個客戶的腳本寫錯，就可能把整個平台的配額耗盡。
- 攻擊與正常流量難以區分——高頻 API 呼叫本身就是業務常態。
- Webhook 回調是薄弱環節——回調接口往往缺乏認證，成為攻擊入口。
API 平台典型風險
| 風險類型 | 表現 | 防護手段 |
|---|---|---|
| 接口洪水 | 單一 endpoint 被高頻呼叫 | per-endpoint 速率基線 |
| 配額濫用 | 合法 key 被過度使用 | 按 key / 租戶配額控制 |
| 爬蟲抓取 | 自動化工具批量拉取資料 | 行為指紋 + 序列分析 |
| Webhook 洪水 | 偽造回調請求打內部接口 | 來源校驗 + 簽名驗證 |
AwayDDoS API 防護要點
1. 分層限流：全局 → 租戶 → 接口
建立三級速率控制：全局保護平台不被整體打穿，租戶級防止單客戶拖垮全局，接口級精準保護高成本 endpoint。任何一層觸發都不影響其他層的正常流量。
2. 多租戶隔離與公平調度
當某個租戶的流量異常時，防護策略只對該租戶生效，其他租戶完全不受影響。這對 SaaS 平台至關重要——不能因為一個客戶的問題讓所有人一起遭殃。
3. 機器學習化的行為基線
針對每個 endpoint 建立正常呼叫的基線模型（QPS、參數分佈、來源分佈、時序特徵），偵測到偏離基線時自動降級——排隊、回傳快取或要求重新認證。原理詳見 CC 攻擊是什麼？
4. Webhook 與回調保護
對回調接口強制來源校驗與簽名校驗，並對異常呼叫模式做速率限制，防止攻擊者透過偽造回調滲透內部系統。
為什麼 API 團隊選擇我們
- 不依賴人機驗證——針對程式客戶端設計的策略，不破壞 API 的自動化場景。
- 精細到 endpoint——不是粗暴的全局限流，而是精準保護真正有價值的接口。
- 支援長連接與 WebSocket——覆蓋現代 API 的常見形態。
- 固定收費、絕不黑洞——API 服務中斷會連鎖影響所有客戶，絕不能接受被黑洞。
推薦部署方式
API 業務通常採用 DNS 牽引（分鐘級生效）搭配 GRE / BGP 隧道保護內部服務通訊。若 API 部署於自建機房，隧道模式能一次覆蓋所有端口與協議。詳見 部署模式對比。