快問快答：貴企業使用了多少個 API？ 即所有用於內部產品、外部服務乃至 Amazon S3 物件儲存或 Kubernetes 等基礎設施管理的 API。
如果您不知道答案，也不必尷尬，因為並非只有您不知道。 在大量調查中，首席資訊官和首席資訊安全長承認，他們沒有全部 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 流量。
實際上，API 閘道的功能可由反向代理或負載均衡器執行，而且正越來越多地由 Ingress controller（Ingress 控制器）來執行。 我們之所以知道這一點，是因為許多 NGINX 開源版使用者對其 NGINX 實例進行專門配置以管理 API 流量。
這需要進行大量定製，因此許多 DevOps 團隊會選擇部署已配置好的 API 閘道（例如 NGINX Plus）來處理一些最重要的 API 管理用例也就不足為奇了。
API 閘道通過充當存取 API 的外部應用的中心控制點和存取點來改進安全防護。 它們不僅可以執行身份驗證和授權策略，並實施速率限制及其他安全防護措施，以防範惡意攻擊和未經授權的存取，而且還能夠對傳輸中數據進行加密，並提供可見性和監控功能，從而幫助識別和防止安全漏洞。 API 閘道還可對流量進行優先順序劃分，執行服務級別協定 （SLA） 或有關 API 使用的業務決策，並節省網路和計算資源。
一旦完成安裝並全面部署后，API 閘道往往具有粘性，很難再更換。 因此，必須確保第一次就選擇合適的 API 閘道。 此事關係重大——並非所有 API 閘道都能提供相同水準的安全性、延遲、可觀測性及靈活性。
一些 API 閘道依賴於底層開源技術，這些技術可能會導致安全漏洞或可靠性問題。 而另一些 API 閘道則可能需要執行繁瑣的整合步驟，並會造成不可預見的流量延遲。 所有這些都可能影響 API 閘道的安全性，因此需要在選擇時慎重考慮。
瞭解API閘道底層機制很重要
市場上的大多數 API 閘道解決方案均基於開源軟體的修改版本而構建。 常用的有 NGINX、HAProxy、Envoy 和Traefik。 然而，許多 API 閘道解決方案都是閉源解決方案（它們會在專有代碼中封裝開原始件）。 也就是說，這些專有解決方案仍然完全依賴於開源元件的底層安全防護。
這可能會帶來重大安全漏洞。 當被用於專有 API 閘道解決方案的開源專案被爆出漏洞後，API 閘道廠商可能需要數月的時間才能推出安全補丁，因為對反向代理層進行任何更改均需執行回歸測試並實施其他質量保證措施，以確保修復代碼不會影響穩定性或性能。 攻擊者深知這一點，因此往往會瞄準這些產品中暴露在外且未打補丁的開源層。
結論是什麼呢？ 您需要瞭解您的 API 閘道採用了哪些技術。 如果您需要為 API 部署高度安全的解決方案，那麼對第三方模組和基礎元件（開源或專有）的依賴可能會產生巨大的風險。
使用軟體物料清單審核安全依賴
建立軟體物料清單 （SBOM） 是評估潛在漏洞的最常用方法之一。 簡而言之，SBOM 提供了組成應用的所有商用和開源軟體元件的詳細清單。
在全面了解軟體堆疊后，您便可評估所有專案是否符合安全和合規標準。 您往往會發現，許多工具都有嵌入式依賴。 一些專案得到了積極維護，並遵照標準化服務級別協定發佈了已知 CVE（通用漏洞和暴露）的補丁。
但許多重大開源專案並非商業實體，因此它們可能不會發佈有關漏洞披露或保證補丁時間的服務級別協定，致使您更容易受到 CVE 的影響。 這會無意間造成您的服務不符合規定的標準。 因此，您需要驗證 SBOM 中的每個元件是否符合標準。
與其他安全防護控制的輕鬆整合至關重要
雖然 API 閘道是 API 安全防護的重要組成部分，但也只是其中的一個要素。 大多數運行 API 閘道的企業還需在其閘道的前面部署 Web 應用防火牆 （WAF） 來攔截攻擊（OWASP 十大 API 安全防護風險等）。 如果基礎設施為分散式，則需部署多個 WAF。 在大型企業中，API 閘道需要與全域防火牆相集成，以監管所有進出流量。
即使是有助於應對 API 發現和威脅分析等挑戰的新型 API 安全防護解決方案，也離不開與強大 API 閘道的緊密整合。 這些工具往往依靠 API 閘道來瞭解 API 流量，並通常與 API 閘道協同應對新興威脅。
無論是哪一種情況，API 閘道和安全防護工具之間的緊密集成對於維護有效的安全防護而言至關重要。 最便捷的方法是使用單個監控解決方案同時跟蹤防火牆和閘道流量。
這種整合可能具有挑戰性，尤其是當企業在多雲或混合環境中運行時。 集成挑戰還可能意味著，若更改網關配置，則需更新 WAF 或全域防火牆，這會增加團隊的工作量，或者最糟糕的情況是，拖慢應用開發團隊的工作速度，因為他們必須等待其防火牆或網關配置請求得到處理。
策略細粒度可能因環境不同而有很大差異
從理論上講，無論在何種環境下運行，API 閘道均可執行同一策略。 然而，如果您必須在不同的環境中通過不同的元件組合來構建 API 閘道，那麼實際情況將迥然不同。
例如，API 管理解決方案可能將一種底層開源技術用於其 API 閘道的本地安裝或託管安裝，而將另一種解決方案用於雲端服務。 策略細粒度和由此帶來的所有安全優勢也可能明顯受限於底層基礎反向代理本身或兩種實現之間功能的不一致。
因此，進行廣泛的概念驗證至關重要 （POC）。 只有這樣，才能確保 API 閘道解決方案可為不斷增長的 API 群提供所需的策略細粒度和控制類型。
策略細粒度和控制不足可能會導致安全防護功能的敏捷性降低，這往往會使 API 閘道淪為鈍器，而非管理 API 環境中快速變化的攻擊面所需的利器。
速度對應用開發團隊很重要
對於應用團隊和 API 擁有者而言，API 閘道在執行策略的同時安全傳輸流量的速度至關重要。 緩慢的 API 會迫使依賴進程等待，進而進一步影響應用的整體性能，造成用戶體驗不佳。
不得不面對緩慢 API 的團隊很有可能繞過安全系統或部署自己的 API，以提高性能並更好地控制用戶體驗和依賴項。 這些影子 API，如果未對 API 進行適當的鎖定、測試和監控，便會產生巨大的安全風險。
API 閘道本身以快為要。 但同樣重要的是，需要密切關注 WAF 和 API 閘道組合產生的延遲影響。 理想情況下，這兩者緊密整合，可降低對數據包速度的影響。 這也是近似生產的概念驗證對於做出正確決策至關重要的另一個原因。
結論：API 閘道的安全係數可能會有所不同 — 慎重選擇
API 是技術基礎設施和組合式鬆散耦合應用的未來。 隨著越來越多的企業轉向雲環境、微服務及其他解耦和分散式計算範式，API 的普及速度可能會加快。
即使您反潮流地向單體應用的方向發展，您的應用仍需管理 API，以便與全球其他實體進行通訊，包括合作夥伴、客戶、存儲層、Stripe 等支付服務提供者、CDN 等關鍵雲服務。
購買 API 閘道一事需要嚴肅對待，慎重考慮。 當然，最重要的考慮因素就是安全。
本文列出了四項標準：可靠的底層技術、與安全防護工具的輕鬆整合、跨環境的策略細粒度及低延遲，但這只是在將 API 閘道投入生產環境之前所需考量的諸多因素中的幾項。
請深思熟慮，慎重選擇，願 API 成為您的利器！
作者：
Andrew Stiefel F5 產品行銷經理文章來源：NGINX