你的API網關有多安全？

你的組織使用了多少API？我們談論的是内部産品、外部服務，甚至是基礎設施管理，如亞馬遜的S3對象存儲或Kubernetes。很多人不知道答案。在一次又一次的調查中，首席資訊官和首席資訊官承認他們并沒有一份準确的API目錄。然而，在繼續采用以API為中心的技術範式（如雲原生計算和微服務）的推動下，進一步使用API是不可避免的。

根據Gartner軟體工程研究主管Mark O'Neill在2022年分享的統計資料：

——98%的組織使用或計劃使用内部API，高于2019年的88%。

——94%的組織使用或計劃使用第三方提供的公共API，高于2019年的52%。

——90%的組織使用或計劃使用合作夥伴提供的私人API，高于2019年的68%。

——80%的組織提供或計劃提供公開的API，高于2019年的46%。

API網關仍是關鍵基礎設施元件

為了應對這種快速增長及其帶來的管理和安全挑戰，首席資訊官、平台運維團隊和雲架構師正轉向API網關來集中管理API流量。API網關幫助發現、管理、觀察和保護網絡上的API流量。

事實上，API網關是一種可以由反向代理或負載均衡器執行的功能，并且越來越多地由入口控制器執行。我們知道這是事實，因為許多NGINX開源使用者專門配置他們的NGINX執行個體來管理API流量。

然而，這需要大量的定制，是以許多DevOps團隊選擇部署一個API網關并不奇怪，該網關已經配置為處理一些最重要的API管理用例，如NGINX Plus。

API網關通過充當通路API的外部應用程式的中心控制點和通路點來提高安全性。它們可以強制執行身份驗證和授權政策，并實施速率限制和其他安全措施，以防止惡意攻擊和未經授權的通路。

此外，API網關可以加密傳輸中的資料，并提供可見性和監控功能，以幫助識别和防止安全漏洞。API網關還可以對流量進行優先級排序，強制執行服務級别協定（SLA）或圍繞API使用的業務決策，并節約網絡和計算資源。

一旦安裝并完全部署，API網關往往很難移除。是以，確定第一次選擇正确的API網關至關重要。這風險很大。因為并非所有API網關都提供相同級别的安全性、延遲、可觀察性和靈活性。

有些依賴于底層的開源技術，這些技術可能會導緻安全漏洞或可靠性問題。其他可能需要繁瑣的內建步驟，并産生無法預見的流量延遲。所有這些都會影響API網關的安全性，需要在選擇過程中加以考慮。

更多需要考慮的因素

市場上大多數API網關解決方案都是基于開源軟體的修改版本建構的。NGINX、HAProxy、Envoy和Traefik都是常用的。然而，許多API網關解決方案都是閉源代碼（它們使用封裝在專有代碼中的開源代碼）。盡管如此，此類專有解決方案仍然完全依賴于開源元件的底層安全性。

這可能會造成嚴重的安全漏洞。當在專有API網關解決方案下的開源項目中宣布漏洞時，網關供應商可能需要幾個月才能推出安全更新檔，因為對反向代理層的任何更改都需要回歸測試和其他品質保證措施，以確定修複不會影響穩定性或性能。攻擊者知道這一點，通常會将這些産品中暴露的和未修補的開源層作為攻擊目标。

底線是什麼？你需要知道哪些技術是API網關的一部分。如果需要高度安全的API解決方案、子產品和基礎元件（無論是開源還是專有）依賴第三方可能會産生不可接受的風險。

使用軟體物料清單稽核安全依賴關系

建立軟體物料清單（SBOM）是評估潛在漏洞的最常見方法之一。簡單地說，SBOM是構成應用程式的所有軟體元件（商業和開源）的詳細清單。

一旦你對軟體堆棧有了完整的了解，就可以評估所有項目是否符合安全和合規标準。你經常會發現，許多工具都在其中嵌入了依賴關系。一些項目正在積極維護，并根據标準化服務級别協定釋出已知CVE（常見漏洞和風險）的更新檔。

但許多主要的開源項目都不是商業實體，是以它們可能不會釋出關于漏洞披露或保證修補時間的SLA，進而使你更容易受到CVE的攻擊。反過來，這可能會無意中使你的服務不符合要求的标準。出于這些原因，你需要驗證SBOM中的每個元件是否都符合要求。

易于與其他安全控制內建至關重要

雖然API網關是API安全的關鍵部分，但它們隻是一個元素。大多數運作API網關的組織還需要在其網關前面安裝一個web應用程式防火牆（WAF）來阻止攻擊（OWASP API Security Top 10等）。如果他們的基礎設施是分布式的，需要一個以上的WAF。在大型企業中，API網關需要與全局防火牆內建，該防火牆對所有進出的流量進行管理。

即使是幫助應對API發現和威脅分析等挑戰的較新API安全解決方案，也依賴于與API網關的強大內建。這些工具通常依賴于API網關來檢視API流量，并且通常與API網關一起處理任何新出現的威脅。

在所有情況下，API網關和安全工具之間的緊密內建對于維護有效的安全至關重要。如果你可以使用單一的監控解決方案來跟蹤防火牆和網關流量，這是最友善的。

這可能是一個具有挑戰性的內建，特别是當組織在多雲或混合環境中運作時。內建挑戰還可能意味着網關配置的更改需要更新WAF或全局防火牆，進而增加團隊工作負載，或者（最壞的情況下）減慢應用程式開發團隊的速度，因為他們必須等待防火牆或網關配置請求同步。

政策粒度在不同環境中可能有很大差異

理論上，API網關無論在什麼環境中運作都可以執行相同的政策。如果必須在不同環境中使用不同的元件組合來建構API網關，那麼實際情況就大不相同。

例如，API管了解決方案可能使用一種底層開源技術來實作其API網關的内部或托管安裝，另一種用于雲服務。政策粒度和所有由此産生的安全好處也可能受到底層基礎反向代理本身的嚴重限制，或者兩種實作之間的功能不比對。

出于這些原因，運作一個廣泛的概念驗證（POC）以密切模拟實時生産流量至關重要。這是確定API網關解決方案能夠為不斷增長的API星座提供所需的政策粒度和控制類型的唯一方法。

政策粒度和控制不足可能會導緻安全能力不夠靈活，通常會将API網關簡化為一種生硬的工具，而不是管理API環境中快速變化的攻擊面所需的精細手術刀。

速度對應用程式開發團隊至關重要

API網關在執行政策的同時安全傳遞流量的速度對應用程式團隊和API所有者至關重要。緩慢的API會迫使依賴程序等待，進而産生糟糕的使用者體驗，進而以複雜的方式影響應用程式的整體性能。

被迫處理慢API的團隊更有可能繞過安全系統或自行開發以提高性能并更好地控制使用者體驗和依賴關系。這相當于影子IT的API，如果API沒有被正确鎖定、測試和監控，就會産生相當大的安全風險。

僅API網關必須很快。但同樣重要的是，要看看WAF和API網關的組合所産生的延遲命中。理想情況下，這兩者緊密結合，減少了減慢資料包速度的需要。這也是近生産POC對于做出正确決策至關重要的另一個原因。

結論：API網關安全有所不同，請明智選擇

API是技術基礎設施和可組合、松散耦合應用程式的未來。随着越來越多的組織轉向雲、微服務和其他解耦和分布式計算範式，它們的快速擴散可能會加速。

即使你逆潮流而動，朝着單體的方向發展，你的應用程式仍需要管理API以與其他地方進行通信，包括合作夥伴、客戶、存儲層、Stripe等支付提供商、CDN等關鍵雲服務等。

API網關是一項需要仔細考慮的重要購買。當然，最重要的考慮是安全。

我們在這篇文章中提出的四個标準——可靠的底層技術、易于與安全工具內建、跨環境的政策粒度和低延遲——隻是API網關在投入生産之前需要檢查的衆多條件中的幾個。

明智地選擇，深入思考，讓API力量與你同在！