在過去幾年中，API 驅動的應用程序在企業級云平臺上部署以擴展規模興起。它們能夠根據用戶需求進行擴展，徹底改變了應用程序的編寫和部署方式。通常，這些分布式應用程序部署在 Kubernetes 平臺上，以便更輕松地管理、編排和部署微服務容器。

DevOps 團隊投入了大量資源，以確保他們在 Kubernetes 基礎設施平臺上運行的應用程序安全可靠，不會被利用。這可以包括強化操作系統，通過跨集群的微分段防止橫向移動，以及通過嚴格的 RBAC 控制來限制訪問來防止未經授權的訪問。

然而，這只是成功的一半。從 Kubernetes 平臺上移，部署的 API 驅動的應用程序有自己的安全問題類別，需要不同的方法來實現適當級別的安全保護。API 驅動的應用程序的興起助長了一類新的 API 漏洞，這些漏洞無法被現有的應用程序安全產品保護。

隱藏在底層 API 中的漏洞可能會暴露等待被利用的弱點，從而暴露關鍵業務數據。網絡犯罪分子已經注意到并正在開發新的攻擊向量，以便在企業向 API 經濟發展時利用它們。

需要一種新的方法來擺脫專注于保護單體應用程序的應用程序安全性，并專注于 API 驅動的應用程序如何運行以提供適當級別的保護。

以下是企業在評估 API 安全解決方案時應考慮的一些關鍵標準。

1. API 可見性和監控：你無法保護看不到的東西

盡管 API 使用量呈爆炸式增長，但許多安全和開發團隊仍無法回答有關其 API 程序的基本問題——例如我們有多少、誰擁有它們以及它們做什么。在當今復雜的威脅環境中，這給企業帶來了巨大的安全風險。

為了防范安全風險，企業了解其 API 程序的所有方面及其相關的安全挑戰至關重要。這可以更好地幫助領導者通過適當的緩解策略改善其組織的安全狀況。

大多數企業都公開了許多內置的 API，并為客戶和合作伙伴開源。它們由不同的團隊發布，使用不同的應用程序堆棧和不同的程序。因此，很難跟蹤和了解潛在風險在哪里。以下是企業應該考慮的一些關鍵 API 可見性挑戰：

• 未知 API：影子、已棄用或隱藏的 API 可能會超出安全團隊的可見范圍，這通常會導致它們不受保護。這些 API 可能會傳輸敏感數據并危及組織的合規地位。
• API 參數：API 漏洞(例如批量分配)允許攻擊者將用戶配置文件更改為“管理員”，從而導致權限提升，這可能導致欺詐、數據丟失。
• 敏感數據暴露：在響應代碼或錯誤消息中暴露機密或敏感數據可用于竊取數據或作為大規模攻擊的偵察形式。
• 業務邏輯缺陷：應用程序業務邏輯缺陷可以使不良行為者通過帳戶接管、抓取、虛假帳戶創建和其他形式的 API 濫用進行欺詐。

在尋求解決這些常見的 API 安全挑戰時，提出問題以評估和降低風險程度會有所幫助。有許多問題需要考慮：我們擁有的 API 有什么作用?API 所有者是誰?哪些 API 需要遵守法律或法規?我們如何監控 API 中的漏洞?我們的 API 是否會暴露敏感數據或 PII，這是否會導致我們不合規?我們如何測試和衡量 API 監控的有效性?

2. API 安全性：不同類型的應用程序安全性

大多數擁有 Web 應用程序的企業都將擁有 Web 應用程序防火墻 (WAF) 以進行安全保護。然而，隨著企業繼續擴大其 API 驅動的應用程序，他們發現傳統的 WAF 無法很好地適應單體應用程序的需求，無法滿足現代 API 驅動的應用程序的需求。

由于 API 驅動的應用程序的編寫方式非常獨特，這使其成為一個單獨的可利用漏洞類別，這些漏洞與其 OWASP 前 10 名 Web 兄弟非常不同。有效保護單體 Web 應用程序漏洞免受 OWASP 的 10 大 Web 漏洞攻擊的安全方法在 API 世界中并不能很好地轉化。

使用傳統的 Web 安全方法很難防御 BOLA(損壞的對象級授權)和批量分配等關鍵 API 漏洞。越來越多的客戶逐漸意識到，部署 WAF 來保護他們的 API 就像在槍戰中拿刀一樣，是低級且錯誤的武器。

現在出現了一種新的 API 安全產品類別，它取代了 Web 應用程序防火墻，更符合保護 API 驅動的應用程序免受利用的特定要求。這些 API 安全解決方案是圍繞應用程序的日常行為方式構建的。這些安全解決方案由機器學習 (ML) 提供支持，專注于學習應用程序行為和發現異常活動。

構建應用程序機器學習模型可以為發現嵌入在數百個微服務中的內在業務邏輯缺陷和 API 漏洞奠定基礎。用戶驅動的流量為機器學習模型的開發提供動力，并捕捉應用程序的微服務如何協同工作以交付應用程序業務邏輯。

如果企業正在尋找 API 安全解決方案，應該考慮以下三個標準：

• 發現：識別企業環境中的所有 API。理想情況下，API 安全工具應該知道定義允許的 API 請求的 API 參數。例如，API 應該只允許用戶響應 255 個字符串字符。通常，未經驗證的 API 響應可用于利用應用程序漏洞。
• 學習：API 安全工具應該能夠從用戶驅動的流量中學習 API 行為。這允許 API 安全解決方案的機器模型了解定義正常應用程序行為的所有細微差別。用戶行為的輕微和突然偏差會通過警報向安全運營團隊顯示。
• 適應：在敏捷環境中開發的大多數現代應用程序都在迅速變化。API 安全解決方案應該能夠自動調整其安全模型以不斷適應所有新變化，以確保應用程序安全始終與 DevOps 保持同步。

3. 威脅分析：在網絡攻擊發生時檢測它們

當網絡犯罪分子從應用程序中泄露敏感數據時，他們會采取必要的預防措施來逃避檢測。為了對抗它們，需要威脅分析來檢測訪問您的應用程序的用戶之間的惡意活動。

從應用程序中獲得的數據的質量和廣度將決定企業的安全保護級別，并影響其在多長時間內檢測到即將發生的網絡攻擊。隨著應用程序變得更加復雜和分布式，更多地了解應用程序的內部工作原理、工作方式、業務邏輯以及與其他第三方技術合作伙伴的交互變得更加重要。

收集應用程序內所有點的數據交互可確保其全面了解所有用戶與應用程序的交互。數據集越豐富，就越容易將惡意與合法用戶交易區分開來，并使企業的安全團隊能夠盡快發現數據泄露。

API 安全平臺應使安全團隊能夠執行以下操作：

• 威脅搜尋：安全分析師可以通過數據湖搜索正在進行的活動。
• 跟蹤攻擊者：當攻擊者深入挖掘應用程序時，您可以跟蹤殺傷鏈活動，例如偵察或掃描活動。
• 事后分析：安全分析師可以獲得事后取證，以了解網絡攻擊如何利用應用程序的業務邏輯或漏洞。

結論

快速變化的 API 驅動應用程序有助于加快產品上市速度，但也釋放了可被網絡犯罪分子快速利用的 API 漏洞。可以很好地保護單體 Web 應用程序的應用程序安全產品在保護 API 驅動的應用程序方面無法很好地擴展。

由于跨更復雜和分布式應用架構的快速變化，API 安全的要求與市場上現有的應用安全產品有著根本的不同。在評估 API 安全解決方案時，一定要關注解決方案如何提供可見性、它對應用程序的理解程度以及威脅分析的質量和深度。

獲得專門針對 API 應用程序的適當應用程序安全解決方案將幫助企業更好地防御不斷增加的 API 驅動的網絡攻擊，這些攻擊旨在利用企業最有價值的資產——數據。