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

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

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

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

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

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

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

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

為了防范安全風險，企業(yè)了解其 API 程序的所有方面及其相關的安全挑戰(zhàn)至關重要。這可以更好地幫助領導者通過適當?shù)木徑獠呗愿纳破浣M織的安全狀況。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結論

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

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

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