根據F5 的《 2021 年應用策略現況報告》，企業採用了多種多樣的方法來推進現代化，其中API 名列榜首：
- 58% 的受訪者選擇新增一層 API 來啟用現代介面
- 51% 的受訪者選擇新增現代應用元件（例如 Kubernetes ）
- 47% 的受訪者選擇採用重構的方法（修改應用程式碼本身）
- 40% 的受訪者正在遷移到公有雲（直接遷移上雲），而沒有進行現代化升級
隨著企業的發展，他們可以透過採用API 閘道來降低API 風險。F5 最新的《 2022 年應用策略現況報告》指出，將API 閘道放在邊緣或靠近邊緣的位置效果最佳。透過在這些地方設定API 網關，企業可以及時阻止攻擊，避免威脅蔓延到整個網路，並為多個API 提供統一且一致的保護。
API 閘道封裝了應用的內部結構，簡化了客戶端和API 之間的通訊。用戶端無需呼叫特定服務，只需連接到API 網關便可。透過為客戶端提供了特定的API ，可以減少了客戶端和API 之間的會話次數，並簡化了客戶端程式碼。
F5 NGINX 客戶已成功地在分散式環境中部署了API 閘道。但是如果您的API 網關不安全，攻擊者仍然可以趁虛而入。NGINX 擁有強大的安全工具，可在不斷變化的威脅情勢中，始終保障API 閘道背後應用的安全。
API 越多，攻擊面越大
API 並非是新鮮事物。基於Web 的API 可以追溯到20 世紀90 年代，甚至早在我們今天所知的互聯網誕生之前，各種版本的API 就已經作為小型分散式網路之間的通訊方式而存在了。經過多年的變遷，使用API 建立的現代應用架構登上了歷史舞台，成為這個時代的顛覆者。
儘管API 在加速現代化進程方面起著至關重要的作用，但它們同時也更容易被攻擊者盯上。在微服務架構中，一個API 可能具有數百個端點，而一個應用程式可能包含許多個使用API 互聯的微服務。這與以往的單體應用不同，單體應用只有一個需要保護的切入點。由於每個微服務會暴露多組API 端點，潛在的攻擊面也增加了十倍之多。
F5 的2022 年報告也發現，大多數企業擁有200 到1000 個應用，其中77% 的受訪企業在多雲環境中運行應用程式。企業在分散式環境中引入的應用程式和API 越多，潛在的受攻擊面就越大。
OWASP 十大API 安全漏洞
一般來說， API 是開放的，可以暴露敏感資料。開放式Web 應用程式安全性專案(OWASP) 指出了十個最常見的API 安全漏洞：
- API1.失效的物件級授權
- API2.失效的使用者驗證
- API3.過度的資料暴露
- API4.缺乏資源與速率限制
- API5.失效的功能級授權
- API6.批量賦值
- API7.安全設定錯誤
- API8.注入
- API9.資產管理不當
- API10.日誌記錄和監控不足
隨著開發週期的加快，敏捷性和速度成為當今企業的當務之急。在當今這個脆弱的、由API 驅動的環境中，安全解決方案必須具備適應性和輕量級的特點，並且能夠成為API 自動化部署流程的一部分。
保護API 安全，從F5 NGINX Plus 開始
API 攻擊事件登上頭條引起轟動的事情已經屢見不鮮。2019 年，共享出行應用程式公司優步被曝其API 存在嚴重漏洞 —— 它的一個API 端點非常容易遭到攻擊，允許攻擊者盜取重要數據，包括打車者的身份驗證令牌。
值得慶幸的是，這個漏洞在還沒有造成任何傷害之前就被發現了。而LinkedIn 領英就沒有那麼幸運了—— 2021 年，由於存在一個API 漏洞，駭客藉此竊取了7 億多名LinkedIn 用戶的數據，隨後又在暗網上兜售這些資訊。
將F5 NGINX Plus 部署成API 網關，您可以跟上API 快速發展的潮流，在處理API 路由和交付時獲得出色的效能。GigaOm （一家獨立技術研究和分析公司）對NGINX 與其他API 閘道解決方案進行了基準測試和比較。結果表明， NGINX 能夠每秒發送30,000 個請求，並且延遲不到30ms ，比一些超大規模企業的API 網關低1000 倍。
NGINX Plus 不僅提供了開箱即用的OWASP API 漏洞防禦機制，而且還帶來了額外的安全保護，例如檢查格式錯誤的cookie 、 JSON 和XML ，驗證允許的檔案類型和回應狀態碼等。它可以確保HTTP RFC 合規性，並偵測用於遮罩攻擊的規避技術。
NGINX Plus 能夠快速路由API 請求，同時對API 用戶端進行身份驗證和授權以確保API 安全，並對流量實施速率限制，以防止基於API 的服務過載。以下工具也可以保護您的API 免於OWASP 十大API 安全漏洞攻擊：
- 身份驗證和授權機制
確保只有那些具有正確存取權的用戶端才能使用您的API 。JSON Web Token (JWT) 中的「聲明（Claims）」機制就是一個典型的例子。驗證和授權可以防禦OWASP 十大API 安全風險中的多個漏洞，包括失效的物件層級授權 (API1)、失效的使用者驗證 (API2)、失效的功能級授權 (API5) 以及日誌記錄和監控不足 (API10)。
- 速率限制策略
透過在定義的時間內限制API 閘道從每個API 用戶端接收的請求數量，防止您的API 過載並緩解DDoS 攻擊。NGINX Plus 允許針對特定的來源端設定專門的速率限制（例如基於JWT 聲明的值），以免有效使用者受到影響。這有助於應對缺乏資源和速率限制 (API4) 的漏洞。
使用F5 NGINX App Protect WAF 加固API
透過使用F5 NGINX App Protect WAF 保護API 網關，企業可以獲得額外的API 安全性，同時抵禦注入攻擊 (API8) 等OWASP 威脅。其他API 閘道和管理解決方案供應商僅針對OWASP API 風險提供了最低限度的保護，而NGINX App Protect WAF 更進一步，還可以抵禦遠端程式碼執行(RCE)、跨站腳本攻擊(XSS) 以及其他攻擊向量。
NGINX App Protect WAF 也圍繞著日誌記錄和監控不足 (API10) 的問題實施了必要的攻擊視覺化。這些攻擊日誌詳情可以傳送到安全資訊與事件管理(SIEM) 系統或其他客戶資料湖，以便於客戶執行額外分析。
如果您使用NGINX Plus 作為API 網關和負載平衡器（路由需要暴露給互聯網以及外部開發人員、合作夥伴的API ），那麼這裡就是部署NGINX App Protect WAF 保護解決方案的最佳位置。讓API 流量減少一跳路由，能夠將安全防護的複雜性和延遲降到最低。
根據特定產業中處理敏感資料（個人識別資訊[PII] ）的PCI 合規性要求，有效載荷必須「跨開放的公共網路進行端對端加密」。透過在API 網關處、負載平衡器或CDN 後面部署NGINX App Protect WAF ，有效載荷將保持完全加密，直到在API 網關上解密為止。這樣，您的API 可以在滿足敏感資料處理要求的同時保持安全。
使用F5 NGINX App Protect WAF 實現多層保護
您可能有一個負載平衡器，並且在該負載平衡器上部署了WAF （例如F5 Advanced WAF ）。在這些後面，您部署了一個API 閘道。那麼既然您的負載平衡上已經有了WAF ，為什麼還要在API 閘道上安裝WAF 呢？
將邊緣側的「負載平衡器- WAF 組合」轉變成環境內的「 API 閘道- WAF 組合」有一個重要的好處，那就是能夠實現更嚴格、更細粒度的安全控制。這種方法允許將安全責任移交給API 團隊，使得安全策略更具API 針對性。
借助這種雙層保護，即使在最快速的API 開發和發布週期中，您的API 也能保持安全。
透過OpenAPI 模式驗證主動安全防禦
針對API 的保護的一個關鍵領域是驗證是否符合Swagger 的OpenAPI 規格。每個API 都具有獨一無二的OpenAPI 模式，且該模式因API 版本而異。如果採用基於OpenAPI 規範模式的保護，那麼我們根本等不及IT 團隊更新其維護的集中式WAF 上的安全控制，因為這項更新需要得到批准並進行嚴謹的測試，以免對其他API 和應用程式帶來意想不到的影響。
NGINX App Protect WAF 可以驗證OpenAPI 規範，核證請求是否符合API 支援的內容（方法、端點、參數等）。基於以上原因，我們認為讓NGINX App Protect WAF 在負載平衡器集中式WAF 後面的API 閘道提供主動安全防禦是明智之舉。
透過「安全即程式碼」與API 部署保持同步
CI/CD 管線是為了速度而生，其初衷與安全性無關。API 的發布頻率也比以往的應用程式高得多，因此API 驅動的DevOps 環境正在呈現「左移」的趨勢。透過「左移」或在應用開發生命週期的早期實施應用安全控制， DevOps 正在朝著「安全即代碼」的DevSecOps 文化演進。
無論是在API 閘道、負載平衡器上或在這兩個位置均安裝WAF ， WAF 配置都需要以自動化的方式部署，以跟上API 版本的變更速度。當企業擁抱「左移」文化並將「安全即代碼」整合到CI/CD 管線中時，安全性就可以建構到應用程式和API 開發的每個階段中，而不是事後再補救。
以程式碼的形式使用安全策略和配置有很多好處：
- 您可以輕鬆從原始碼儲存庫中拉取程式碼。
- 您的SecOps 團隊可以建立並維護聲明式安全策略，以確保保護業務所需的控制措施都已到位。
- 聲明式策略可以重複編碼到新的應用程式和API 中。
- 安全性成為CI/CD 管線中的一個自動化組成部分。
在採用自動化API 模式時，只要您更新API，就要更新該檔案中的設定和程式碼。再次重申一下，自動化是關鍵。一旦完全採用了「左移」或「安全為先」的理念，開發人員就可以輕鬆地從倉庫中獲取程式碼，從而保持敏捷性、提高開發速度並縮短上線時間。
為您的API 提供高效能保護
無論您將WAF 部署在何處來保護API ，高效能和低延遲都是讓API 快速回應客戶、豐富使用者體驗的必要條件。NGINX App Protect WAF 的輕量級架構能夠實現這種高效能和低延遲，並且在雲端的運算需求極低。
GigaOm 的《高效能應用安全測試報告》展示了NGINX App Protect WAF 、AWS WAF 、Azure WAF 以及ModSecurity 開源WAF 的效能測試結果。GigaOm 發現，NGINX App Protect WAF 的延遲比ModSecurity OSS WAF on NGINX 低4.7 倍，並且在運行需要高效能的應用時比AWS WAF 的延遲低128 倍。
NGINX 是唯一將WAF 嵌入NGINX API 閘道的廠商，幫助API 流量減少了一跳路由。不同層之間更少的跳躍可以縮短延遲、降低複雜性並減少故障點。這與不整合WAF 的普通API 管理解決方案形成了鮮明對比（後者要求您必須單獨部署WAF ，並且一旦完成設置， API 流量就必須分別遍歷WAF 和API 網關）。NGINX 的緊密整合意味著高效能與安全性的完美結合。
結語
NGINX 的NGINX Plus 和NGINX App Protect WAF 可以提供強大的API 安全性。借助可擴展的輕量級NGINX 和穩健、強大的F5 Advanced WAF 引擎，您可以自信地邁入API 驅動的世界，並且不必擔憂您的現代應用的安全性。
作為一款現代應用軟體安全解決方案，NGINX App Protect WAF 堅持秉承 NGINX 的核心價值，不受平台限制，能夠無縫整合常見的DevOps 工具鏈，從而消除摩擦並加速安全部署。
憑藉聲明式配置功能，安全性可以成為CI/CD 管線以及整個軟體開發生命週期 (SDLC) 中的一個自動化組成部分。這不僅有助於加快發布速度，還可以幫助企業建立可靠且受保護的API ，同時彌合DevOps 和SecOps 團隊之間的差距，並推動向DevSecOps 文化轉變。
文章來源：NGINX