應對 API 泛濫的五種方法（以及為何應當關注 API 泛濫問題）

發布日期：2023/02/20

API 是現代互聯網的結締組織，能夠將數據從邊緣連接回雲端和本地數據中心。根據 F5《2021 年應用策略現狀報告》，利用 API 是最受組織青睞的現代化改造方法：

58% 的受訪組織添加了一層 API 以啟用現代介面
51% 的受訪組織選擇添加現代應用元件（例如 Kubernetes）
47% 的受訪組織選擇採用重構的方法（修改應用代碼本身）
40% 的受訪組織正在向公有雲遷移（直接遷移上雲），而沒有進行現代化升級

在 API 驅動的經濟中，API 必須完全可靠。但隨著業務和應用的不斷擴展，運營複雜性大幅增加。從設計上來看，雲原生應用的分散式和去中心化特徵愈發明顯，其數十、數百甚至數千個 API 無序地分散在雲端、本地和邊緣等多種環境中。

根據 F5 首席技術官辦公室最近的研究，API 持續泛濫對正在進行數位化轉型的企業構成重大威脅。但這又意味著什麼呢？

什麼是 API 泛濫？

“API 泛濫”描述了隨著組織數位化轉型而出現的兩個相互交織的問題：API 數量的激增，以及 API 跨多個架構和團隊的散亂分佈。

API 泛濫的四大驅動因素：

混合基礎架構——當今 81% 的企業跨三種或更多架構運營，包括公有雲、本地數據中心和邊緣基礎架構。
微服務架構——隨著新服務的不斷上線，微服務架構的日益普及導致 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 管理的複雜性，NGINX 專門構建了一款管理平面解決方案。 API Connectivity Manager 是 F5 NGINX Management Suite的一部分，提供了一個統一介面來連接、管理和保護 API，無論它們位於何處或由誰構建。

借助 API Connectivity Manager，您可通過執行以下五大策略，有效應對 API 泛濫和大規模管理 API：

策略1：實施 API 管理策略

集中管理和控制支援您在單個架構或集群中更輕鬆地發現、連接和保護 API。 API 泛濫問題需要您調整思考方式，將純粹的分層模型調整為分散式自主擴展模型。

NGINX 可如何提供説明——藉助 API Connectivity Manager，您可以實施靈活的管理模型，在全域策略和細粒度控制之間取得平衡，以便 API 擁有者可以管理本地策略。這有助於加快上市時間，同時又不影響以一致的方式對安全性和合規性進行監督。

平臺和基礎架構團隊可通過日誌記錄、錯誤響應代碼、TLS 配置等全域策略來確保整個企業的 API 一致性。構建和管理 API 的開發人員保留對速率限制、身份驗證和授權等服務級別策略的控制權。

策略2：為 API 查找建立單一事實來源

隨著 API 數量和應用複雜性的增長，查找和跟蹤可用 API 及其位置變得極其困難。如果 API 隱藏在特定微服務的基礎架構中並且未註冊，那麼負責其他微服務的團隊將無法找到這些 API，也無法將其集成到自己的專案中。

NGINX 可如何提供説明——借助 API Connectivity Manager，您可以建立服務目錄和 API 門戶，以方便開發人員查找和使用 API。通過在一個集中位置提供有關可用 API 及其使用方法和證書生成工具的資訊，打造良好的開發人員門戶體驗，從而推動 API 的使用。

策略3：確保適當的版本控制和文件維護

建立使用者友好的 API 門戶是很好的第一步。然而，當 API 規範在開發週期中發生變化時，就會出現問題。這意味著調用 API 的遠端服務也需要更改。如果所有微服務均由同一個團隊為同一款應用設計，那麼這種方法可能會奏效，但如果 API 是供第三方使用，則無濟於事。

同時，文件維護也是一個令開發人員頭疼的問題。經過最初的高頻率使用期，API 門戶通常會被限制，充斥著大量不受支援的 API 和過時的文件，給利益相關者和 API 用戶帶來極大不便和挫敗感。

NGINX 將如何提供説明——借助 API Connectivity Manager，您可以將 API 發佈和文件整合到 API 開發人員的無縫工作流中。 API 擁有者可同時發佈 API 並使用 OpenAPI 規範生成文件，從而節省時間並確保每個人都能獲取最新文件。

策略4：提供 API 流量指標和可視化

瞭解 API 位置及其配置方式是企業面臨的最大挑戰之一。如果無法以統一的視角查看各種環境中的 API 流量——即使這並非不可能——也很難識別性能問題和安全威脅。

NGINX 可如何提供説明——借助 API Connectivity Manager，您可通過建立一個統一平臺，輕鬆訪問重要指標，從而加快實施最佳實踐並確保性能和可靠性。基礎架構擁有者可以監控 API 流量和配置，執行標準化日誌格式，並將數據匯出到其首選的監控解決方案。

策略5：大規模應用 API 保護

超過 90% 的企業在 2020 年遭遇過 API 安全事件。 貴組織的威脅面會隨著每個新 API 端點的上線而擴大。大規模安全保護不能只是一項附加特性，必須構建到從規範到代碼再到部署的整個生命週期中。

NGINX 可如何提供説明——借助 API Connectivity Manager，您可以使用兩大 API 安全元件來保護 API：API 存取控制和 API 保護。通過 OpenID Connect 使用 JSON Web 令牌（JWT）、API 金鑰或 OAuth 管理身份驗證和授權，執行 API 存取控制。

在接下來的幾個月里，API Connectivity Manager 將增加對 NGINX App Protect WAF 的支援，屆時您將能夠利用可開箱即用 OWASP 十大 API 安全風險防護、模式驗證等特性，來保護 API 閘道並防禦常見和高級威脅。

利用 API Connectivity Manager 縮短上市時間

通過解決 API 泛濫帶來的挑戰，您可以將多架構複雜性轉化為競爭優勢。借助 API Connectivity Manager，您可以構建彈性 API 生態系統，以開發人員所需的速度和靈活性實施大規模管理。

查看原文：NGINX

以上資料來源為F5官網

返回上一頁