什麼是 網路應用程式 and 應用程式開發介面 (WAAP)？
網路應用程式 and 應用程式開發介面 Protection (WAAP) 描述一套安全工具，可發現並保護現今複雜的應用程式。 現今大量的網路應用程式都是透過應用程 式開發介面 (應用程式開發介面) 建置與執行 - 輕量級的軟體介面可讓應用程 式分享資料。 然而，這種互動性開闢了新的攻擊途徑，而 WAAP 就是為了彌補應用程式開發介面在傳統網路安全上的漏洞而設計的。
傳統 WAF 如何受到限制
在深入探討 WAAP 功能之前，我們應該先瞭解它們所針對的威脅環境。應用程式開發介面專為快速、輕鬆地分享資料而設計。 這使得它們與舊式網路安全平台所保護的軟體大不相同。網路應用程式防火牆 (WAF) 是為了保護網路路由應用程式而建立的，網路路由應用程式的行為大致上是靜態的，而使用者基本都是以預先定義的方式進行通訊。 這是基於規則的安全政策的理想環境：WAF 只需根據內部政策檢查每個 HTTP 通訊；任何類似可疑行為的東西都可以在攻擊到達內部使用者之前被攔截。
為了說明 WAF 以政策為基礎的方法為何有其限制，讓我們來評估應用程式開發介面安全所面臨的一些常見風險：
正確的使用者驗證
與 Web 應用程式互動時，使用者只能存取與其角色權限等級相符的資源。然而，有些應用程式開發介面並沒有編碼來執行使用者驗證檢查 - 這種脆弱的性質非常常見，以至於 OWASP 將其命名為「破壞的物件層級授權」（Broken Object Level Authorization）。 不執行此動作的應用程式開發介面允許攻擊者呼叫應用程式開發介面，在使用者參數中放置虛假的使用者 ID，並取得該使用者或端點的詳細資料。
Token Theft
另外，對使用者進行認證的應用程式開發介面，也可能會有令牌被盜用的風險。 每次使用者或端點向應用程式開發介面的驗證伺服器驗證其身分時，就會發出驗證其存取底層應用程式開發介面的令牌。 這些代幣應設定為定期過期 - 不過，有些開發人員會選擇發行永久代幣。如果這個令牌被盜，例如透過中間人攻擊，攻擊者就可以無限期存取使用者的帳戶。
WAF 規則限制
WAF 規則基本上無法發現應用程式開發介面內的不正當存取。 為了找出 HTML 模式而建立的 WAF，在應用程式開發介面所使用的複雜嵌套結構面前，顯得非常吃力。 簽名並非可靠編碼業務和認證程序的最佳格式。
更糟的是，嘗試在應用程式開發介面情境中執行 WAF 識別碼，往往會產生大量誤判。 這表示 WAF 會對合法的應用程式開發介面使用發出警示，甚至可能攔截合法的應用程式開發介面使用。
WAAP：運作方式與核心元件
這並非宣告 WAF 過時 - WAAP 的核心是網路應用程式防火牆。 WAAP 也遵循相同的架構設計，因為它的定位也是位於使用者與後端服務之間的反向代理。
然而，WAAP 並非完全依賴 WAF 功能，而是從其上的其他幾個元件中獲益。請注意，Gartner 將 WAAP 定義為以雲端為基礎，因為它不僅需要與組織現有的網路工具整合，還需要持續更新的威脅情資骨幹。
網路應用程式防火牆 (WAF)
WAF 繼續作為高效且高度可擴充的防禦層。它會檢查所有進出應用程式及其使用者的 HTTP/S 流量 - 這是保護網路應用程式的基本基線。 進階 WAF 模組以持續更新的規則集為基礎，可在新發現威脅時進行虛擬修補。即時威脅饋送可將提供商的完整脆弱性情報饋送納入其中，實現近乎即時的防護。
此外，先進的 WAF 還能提供深度封包檢測 (DPI)。傳統的 WAF 會檢查使用者請求的封包標頭，這些標頭會顯示封包的來往地點，以及封包的路由方式。DPI 藉由檢查資料封包的完整內容及其通過網路時的有效負載，取代了這一點。
這種更深入的分析可讓 WAF 引擎不僅封鎖個別危險封包，還能封鎖更複雜的攻擊，例如開始要求連線至命令與控制伺服器的受入侵應用程式。因此，情境驅動的通訊協定可以考慮每個請求的廣泛情境，例如使用者身分、位置、時間、裝置，以及資料在請求中出現的位置。
最後，所有這些即時 HTTPS 流量資料都會輸入行為分析平台。這可讓 WAF 建立每個應用程式在一段時間內的呼叫方式，以及不同使用者的行為概況。
應用程式開發接口閘道器
應用程式開發介面安全性是 WAAP 的核心元件。 WAAP 以應用程式開發介面閘道器 (Architectured as an 應用程式開發介面 閘道器) 架構，作為單一入口點 (single point of entry)，負責擷取每個請求，然後將請求路由至適當的後端服務，或調用任何請求的後端服務並匯集其結果。
從安全可視性的角度來看，這可以允許更好的 應用程式開發介面可視性。 應用程式開發介面搜尋可以半自動化，因為 WAAP 解決方案會掃描流量和相關端點，以偵測目前正在使用的應用程式開發介面。 一旦加入清單，就會執行手動審查 - 經驗證的應用程式開發介面會被移至基線清單，而任何意外的發現都會被標記為影子應用程式開發介面，並列為進一步驗證的項目。
此流程的一部分包括驗證每個應用程式開發介面所遵循的模式。 當發現每個應用程式開發介面時，WAAP 工具會擷取其取樣的要求和回應資料，並將其與內部的共通模式清單進行比對。 任何不常見的模式都可以手動驗證。除了模式之外，此 WAAP 發現還包括每個應用程式開發介面的驗證元素。
已學習或已匯入的應用程式開發介面模式允許將驗證應用於傳入和傳出的要求。 因此，這可確保即使是協力廠商應用程式開發介面也遵守最佳實務，例如 OAuth 2.0 認證、輸入淨化和速率限制。 現代的 WAAP 平台通常會整合應用程式開發介面 閘道器，以提供即時流量可視性及自動化的應用程式開發介面庫存管理。
機器人管理
雖然應用程式開發介面和個人使用者是重要的安全防護措施，但在保護應用程式安全時，還需要考慮另外一種行為者：機器人。 值得慶幸的是，殭屍的行為往往能區別於真正的使用者和應用程式開發介面呼叫 - 例如，人類會以隨機、有機的方式移動滑鼠指針，而殭屍不是以機械直線方式模擬滑鼠移動，就是完全不模擬。 WAAP 會收集用戶端的活動，以及裝置、瀏覽器和網路等參數。
WAAP 最佳實務指出，必須向可疑的殭屍發出挑戰，例如 JavaScript 或 CAPTCHA。一旦驗證為殭屍，就可以封鎖或發出合理的速率限制。
存取管理
較早前，我們提到安全應用程式開發介面驗證的重要性。 WAAP 透過與組織原有的身分與存取管理 (IAM) 提供者整合，提供可視性與強制性。
一旦整合後，WAAP 即可擷取並驗證所有在應 用程式開發介面驗證時所發出的存取權限，並確保每次應 用程式開發介面呼叫都攜帶有效且未過期的憑證。 這提供了一個架構，組織可藉此偵測並移除被盜的存取權限，同時在活躍應用程式開發介面中執行定期的權限更新。
從終端使用者的角度來看，WAAP 工具可以使驗證程序更快，因為它們支援聯合身分和 SSO 整合。這表示可信裝置的驗證可在背景中完成。
Maximize 應用程式開發介面 Security withCheck Point
Check Point offers transparent API discovery and schema enforcement: it then applies dual AI engines – one trained on vast volumes of malicious and benign traffic, the other continuously modeling the unique context of your applications – to automatically block threats with near-zero false positives.
Finally, Check Point collates all ongoing API and web application data into a unified dashboard. Reporting is made fast and efficient thanks to audit-ready logs, while Check Point’s global infrastructure provides local Points of Presence that keep latency low and maintain a high level of scalability.
Explore the Check Point dashboard for yourself with a demo and start unveiling the APIs within your organization.
