近年來，API 的激增極大地改變了企業運營方式。 API 支援不同的應用相互通訊和交換數據，可讓應用流程和軟體開發變得更加高效和有效。
然而，隨著 API 使用的增多，API 蔓延的風險也隨之產生，即跨分散式團隊和架構建立和部署 API 往往缺乏適當的監督和管理。 這可能會給企業帶來一系列新的安全風險，因為每個 API 都是攻擊者未經授權存取敏感數據和系統的潛在入口點。
API 優先軟體開發的興起
API 蔓延的主要驅動因素之一是微服務的激增。 微服務架構將一個大型應用分解為許多通過 API 相互通訊的小型應用。 這就將複雜的應用分解為獨立的元件，這些元件可由各個團隊進行管理，並能夠彼此獨立擴展以滿足流量需求。
微服務為開發人員提供了許多優勢，包括更高的靈活性和可擴充性。 但這些優勢是有代價的，其中就包括額外的複雜性。 因此，許多企業採用 API 優先方法來建立微服務。 在實施這種策略時，應用和服務的設計流程都是先制定 API 契約，該契約概述了 API 的工作方式，細化到請求和回應格式。
攻擊面隨 API 激增而不斷擴大
若不重視 API 安全防護，特別是在設計和部署過程中，那麼 API 優先軟體開發的優勢就很容易被削弱。 從根本上講，API 越多，攻擊面越大。 儘管 API 在現代軟體開發中發揮著重要作用，但它們同時也更容易被攻擊者盯上。
2018 年，Gartner 預測，到 2022 年，API 將成為應用中最常見的攻擊向量。 實際上，他們對形勢的預測過於樂觀了。 影響數百萬使用者的重大 API 漏洞事件在多家大型公司不斷上演，而且只會愈加頻繁
- 2018 年，Facebook 報告稱，攻擊者利用該公司的開發人員 API 竊取了與使用者個人資料頁面相關聯的個人身份資訊（PII），包括姓名、性別及籍貫，至少 5000 萬用戶的數據處於風險之中。
- 2019 年，LinkedIn 報告稱，一名駭客利用數據抓取技術通過 API 收集了 7 億多使用者的資訊，並在暗網上發佈兜售。
- 2021 年，Peloton 維護的 API 出現漏洞，允許攻擊者請求 PII，包括年齡、性別、城市、體重和出生日期。
- 2022 年，Twitter 發生了一起 API 漏洞事件，540 萬使用者帳戶的數據慘遭洩露，包括電話號碼和電子郵件位址。
- 2023 年，T-Mobile 報告稱，API 漏洞導致 3700 萬客戶的數據被盜，包括姓名、電子郵箱、地址、電話號碼、出生日期等。
這些攻擊的大規模和多樣性揭示了安全防護和工程領導者所面臨的嚴峻挑戰。 一些攻擊利用了被錯誤地暴露在互聯網上的 API，而另一些攻擊則使用了代碼庫中錯誤暴露的 API 金鑰或其他身份驗證工具。 或者，攻擊者通過 VPN 漏洞侵入內部環境，利用內部 API 竊取數據。
阻止 API 攻擊需要採用正確的策略和工具
防範 API 威脅的最常見方法是結合使用傳統 Web 應用安全防護策略與現代 API 安全防護技術。 面對當今各種 API 威脅，傳統策略往往力不能及。 自動化 API 發現和 API 對比測試等現代技術試圖彌合這些缺口。
對於企業而言，「右護」（實施全域控制和安全防護策略，以保護已部署的應用和 API）和「左移」 （在安全防護嵌入到代碼中，從而在應用和 API 投入生產環境前消除漏洞）至關重要。 但這兩種策略均無法單獨提供全面的 API 安全防護，因此防範漏洞的關鍵在於採取一種涵蓋三類 API 安全防護實踐的全面方法：
- API 安全防護狀態管理 – 提供對 API 集合的安全狀態的可見性，包括暴露的數據的類型和請求方法
- API 安全防護測試 – 評估 API 在其生命週期中各關鍵點的安全防護，以發現潛在漏洞
- API 運行時保護 – 在運行過程中檢測並防止惡意請求到達 API
通過結合使用正確的策略與正確的工具，企業能夠更好地保護其 API 免受攻擊，並確保軟體系統安全無虞。下面我們來看看平臺工程領導者需要部署哪些重要功能和工具，以便在 API 的整個生命週期對其進行有效保護。
什麼是 API 安全防護態勢管理？
API 安全防護態勢管理可提供對 API 所暴露的數量、類型、位置及數據的可見性。 這些資訊能夠説明您瞭解與每個 API 相關的風險，從而採取適當的措施保護 API。
主要功能：
- 自動化 API 發現 – 自動持續的 API 發現，以全面了解環境中部署的 API 情況
- API 特性 – 按協議或架構（REST、GraphQL、SOAP 等）對 API 進行識別和分類，並映射敏感數據流， 從而瞭解所面臨的暴露風險
- API 清單 – 維護完整的 API 清單，以方便軟體團隊複用現有 API，並説明 SecOps 團隊構建安全防護態勢的完整全貌
代表性技術：
- Web 應用和 API 防護（WAAP） – 利用在 API 基礎架構中的特殊全域位置來分析進出環境的流量，識別API， 並構建風險暴露檢視
- 內聯或基於代理的發現 – 將代理附加到現有 API 閘道、負載均衡器或 Kubernetes Ingress Controller，以鏡像和分析 API 流量
- 帶外或無代理發現 – 使用流量鏡像或導出日誌和指標來分析 API 流量; 與其他技術相比，通常對 API 和威脅的可見性較低
- 域爬蟲程式 – API 安全防護供應商可能會提供爬蟲程式，以探測您的域中是否有暴露的 API 端點，這些端點允許流量繞過執行安全防護策略的 API 閘道和負載均衡器
需要警惕的是，任何技術都無法一個不落地發現架構中的每個 API。 大多數發現技術都依賴於現有負載均衡器、API 閘道及 Ingress Controller 提供的可見性，不太可能發現能夠繞過這些架構元件的錯誤配置。
從根本上說，執行代碼審查和遵循 API 優先最佳實踐可提供更有效的長期防禦。 不過，對於快速建立安全防護態勢視圖以及發現有可能不受管理和保護的 API 而言，自動化 API 發現工具仍很有用。
什麼是 API 安全防護測試？
API 安全防護態勢管理關乎企業整體安全防護，而 API 安全防護測試則關乎單個 API。 從根本上講，API 安全防護測試是通過測試 API 運行時（API 背後運行的應用）來幫助識別和防範漏洞及其相關風險。 它有助於確保滿足基本的安全防護要求，包括身份驗證、授權、速率限制及加密條件。
主要功能：
- API 契約測試 – 使用 API 的 OpenAPI 規範，通過比較用戶端請求和伺服器回應來驗證其是否正常運行。 它採用“由內而外”的方法，可在部署 API 之前發現它們是否存在漏洞。
- 動態應用安全防護測試（DAST）– 類比針對 API 運行時的攻擊以查找漏洞，像惡意使用者一樣從“從外向內”評估 API。
代表性技術：
- API 契約測試軟體 – 用於運行測試的專用工具，這些測試可對 API 請求和回應進行分段，以驗證客戶端和伺服器行為是否符合 API 契約
- 應用安全防護測試（AST）軟體 – 透過模擬攻擊來分析和測試應用（包括 API）的工具
- 既有開源契約測試工具，也有來自專業 API 安全防護廠商的商用產品。 應用安全防護測試（AST）市場發展已有數十年，越來越多的廠商提供 API 專用掃描和測試工具。
什麼是 API 運行時保護？
API 運行時保護是指在 API 運行和管理請求時確保其安全防護。 它優先考慮將安全防護構建到平臺基礎架構及 API 本身的代碼中，旨在識別和防止部署后出現惡意 API 請求。
主要功能：
- 存取控制 – 執行身份驗證（authN）和授權（authZ）策略
- 網路安全防護 – 加密並保護網路通訊
- 應用保護 – 保護 API 運行時免受惡意 API 請求和攻擊的影響
- 實時監控 – 可視化、跟蹤和緩解 API 基礎架構中的攻擊
代表性技術：
- API 閘道 – 應用和執行安全防護策略，包括身份驗證、授權、速率限制、存取控制清單及加密
- Web 應用防火牆（WAF） – 根據攻擊特徵庫主動監控並過濾流量，以保護 API 和應用免受複雜的七層攻擊
- 身份驗證供應商（IdP） – 存儲並驗證使用者身份的服務，通常與單點登錄（SSO）供應商協同驗證使用者身份
API 閘道和 WAF/WAAP 各不相同。 一些服務（特別是適用於雲及其他平臺的原生解決方案）缺乏多雲和混合架構所需的全域可見性和標準化。
API 安全防護的最佳實踐
考慮到保護 API 的重要性，必須有計劃地實施 API 安全防護。 平臺工程和安全防護領導者必須通力合作，以滿足整個 API 生命週期的安全防護要求。 如前所述，這需要在三大方面併發用力：API 安全防護態勢管理、API 安全防護測試及 API 運行時保護。 換句話說，您需要重點瞭解您有多少個 API、如何測試它們是否存在缺陷，以及如何將安全防護嵌入到代碼中。
結語
與所有網路安全一樣，API 安全防護也是一個持續的過程，需要網路工程師、安全防護運維領導者、平臺工程領導者及軟體開發工程師等諸多利益相關者之間展開密切協作。 好在 API 安全防護並不是深不可測的事情。
大多數企業已經採取相應措施來應對已知攻擊，如跨站腳本攻擊、注入攻擊、分散式拒絕服務攻擊以及其他可能針對 API 的攻擊。 對於經驗豐富的安全防護專業人員來說，上述許多最佳實踐可能都非常熟悉。 無論貴企業運行多少 API，您都要建立可靠的 API 安全防護策略，並主動地對其進行持續管理。
文章來源：NGINX