據(jù)??行業(yè)分析機構(gòu)451 Group指出??，目前企業(yè)擁有的 API 的平均數(shù)量超過15,000個。顯然，這一數(shù)字遠高于??平臺運營??團隊可以用電子表格跟蹤的API 的平均數(shù)量。即使將API跟蹤的責任分配給各個業(yè)務部門，考慮到API數(shù)量的驚人的增長速度，這仍然是一項艱巨的任務。

2021年，F(xiàn)5工程師和技術(shù)專家Rajesh Narayanan為這個問題創(chuàng)造了一個新詞：??API蔓延??（API sprawl）。“API蔓延”一詞的含義正如其名——即世界各地的企業(yè)中的API數(shù)量的加速增長，而這也給API的管理和防護帶來了巨大挑戰(zhàn)。這一問題有多嚴重？據(jù)Narayan估計，到2030年，全球部署和運行的API將超過10億個。

現(xiàn)代應用在開發(fā)方式方面的變化加速了API的蔓延。微服務的興起、用于系統(tǒng)內(nèi)部通信的API的不斷增加，以及多云和混合云架構(gòu)的快速增加，都使得我們需要更多地使用API在應用之間進行通信。例如，作為容器編排的事實標準的Kubernetes就是使用API來實現(xiàn)所有的內(nèi)部通信的。新的基礎架構(gòu)類型（如serverless架構(gòu)）也意味著API可以在幾乎所有環(huán)境中運行。同時還有更多種類的API技術(shù)需要管理——REST、GraphQL和gRPC都已被廣泛使用，而更多的API查詢協(xié)議也將很快出現(xiàn)。

更糟糕的是，網(wǎng)絡罪犯絕對會樂于見到API蔓延。他們越來越多地將API作為他們精確攻擊的目標，原因是API通常沒有得到仔細的管理，而且默認配置的訪問權(quán)限相對開放。

為了消除這種問題，必須以程序化、規(guī)模化的解決方案來應對API管理、發(fā)現(xiàn)和防護方面的挑戰(zhàn)。不過在您能夠??有效應對API蔓延??之前，您需要先了解該問題在您的組織機構(gòu)中的嚴重程度。以下六個明顯跡象表明您遇到了API蔓延問題。

1. 沒有最近更新的API清單

API蔓延的典型癥狀是不知道在所有環(huán)境中都運行著哪些API，這通常是由于松散的API管理策略導致的——在這種策略下，團隊無需注冊僅在內(nèi)部使用的API（即所謂的“影子API”）。

您的首要任務是準確盤點現(xiàn)有的API。但由于API的添加和棄用通常極為頻繁，想要“準確盤點”就需要不斷地進行統(tǒng)計。合理的解決方案是通過編程式的方式進行盤點并持續(xù)進行API發(fā)現(xiàn)，類似于網(wǎng)絡掃描和資產(chǎn)發(fā)現(xiàn)。

從理論上講，結(jié)構(gòu)化的API審批流程也有所助益。但在現(xiàn)實中，對于API創(chuàng)建和版本管理等任務，不斷“左移”的企業(yè)會想要縮減繁重的審批流程。對于這些企業(yè)來說，將API清單盤點作為CI/CD的一部分來構(gòu)建流程通常是一種很好的方法，尤其是當API用于微服務和其他更現(xiàn)代的應用架構(gòu)時。

2. 不知道每個API分別在何處運行

在現(xiàn)代基礎架構(gòu)環(huán)境中，僅僅知道API的存在還遠遠不夠——還需要知道每個API的位置。端點可能會在不同基礎架構(gòu)形式的容器間互為鏡像——橫跨多個云平臺、在混合云中，或者在像是 serverless 這樣的多種服務中。

安全團隊需要掌握API的位置信息，從而正確配置策略和防護措施并運行API安全測試。如果您需要在多個環(huán)境中運行API，這也會影響您對于??API網(wǎng)關(guān)??和其他API流量管理方式的選擇。理想情況下，您會希望有一個適用全局的API網(wǎng)關(guān)解決方案，以便能夠在不同環(huán)境中實現(xiàn)具有一致性的API流量管理和防護。

3. 無法輕松地識別API的所有者或負責人 如果您不知道API由誰負責，當API出現(xiàn)問題時，就不知道該找誰處理。通常情況下，當構(gòu)建API的人或團隊調(diào)崗或者離職時，那些對于平穩(wěn)運營來說不可或缺的API就會成為“孤兒”。有時，API所有權(quán)的轉(zhuǎn)移非常明確——但更常見的情況是，這個過程會被跳過或通過非正式手續(xù)完成。

為每個API分配所有權(quán)是清單盤點過程的一部分，它至關(guān)重要，因為這樣可以確立問責制，幫助責任人合理地管理和防護他們負責的API。

4. 多個API在執(zhí)行著類似或重復任務

當多個團隊有相似但不完全相同的需求，通常會發(fā)生任務重合的情況，而且有人會說：“我們會通過構(gòu)建自己的API來滿足我們的需求，這樣，我們就可以掌控自己的命運！”但是，擁有多個類似API會增加不必要的技術(shù)債務。因此，衡量有多少應用或服務需要使用API，并將其作為關(guān)鍵性能指標 (KPI) 之一非常重要。跟蹤這些指標有助于最大程度地提高每個API的可重用性。整合API的另一種方法是轉(zhuǎn)換到像是GraphQL一類的更靈活的形式。

5. 文檔滯后超過2個版本

文檔對于經(jīng)驗傳遞、新員工入職培訓和組織彈性至關(guān)重要?？上У氖?，編寫和維護文檔通常是工程師最痛恨的事情。過時的API文檔通常表明API正在蔓延——因為這說明團隊創(chuàng)建和更新API的速度太快，所以沒時間更新文檔——或者他們可以看似合理地這么解釋他們不更新文檔的行為。在最壞的情況下，過時的文檔標示著其中提到的API是無人維護的孤兒。

慶幸的是，API往往有清晰定義的結(jié)構(gòu)，使其易于理解。良好的API管理解決方案通常包含一個工具，用于幫助開發(fā)人員根據(jù)API規(guī)范自動生成文檔。最常見的例子之一是??OpenAPI規(guī)范??。它使用標準格式來描述API，這樣，人類和計算機就可以在無需訪問源代碼或其他文檔的前提下發(fā)現(xiàn)和理解API的功能。

6. 項目由于API安全防護而延誤

有好消息？安全團隊會在發(fā)布前檢查所有API。壞消息呢？由于API負責人在開發(fā)過程中沒有遵循API安全最佳實踐，或者沒有進行充分的測試，因此未通過檢查，代碼被送回返工。還有更好的消息？制定一套一致的通用規(guī)則和最佳實踐來幫助開發(fā)人員實現(xiàn)絕大部分的要求，并不是那么難的事情——基本方法包括了實施速率限制、加密外部流量，以及要求對密鑰再生進行重新授權(quán)等。大多數(shù)企業(yè)還可以使用高級Web應用防火墻 (WAF) 或其他工具對API網(wǎng)關(guān)實施額外的保護，以抵御??OWASP ??列出的10種最常見API攻擊。

更先進的組織機構(gòu)擁有成熟的SecDevOps能力，可以為每個API進行威脅建模，而且還可能能夠根據(jù)可以訪問的數(shù)據(jù)或服務類型為不同的API指定不同的安全等級。

結(jié)論：避免蔓延是一場永無止境的斗爭 以上六個跡象只是API蔓延現(xiàn)象的一部分預警。我們要明確一點——API蔓延是開發(fā)人員自主性和微服務DIY思維的自然產(chǎn)物。借助現(xiàn)代開發(fā)工具和像GitHub Copilot這樣的代碼自動化能力，構(gòu)建新的API正變得越來越輕松可行。

應對API蔓延的工作沒有止境。部署API管理解決方案和API網(wǎng)關(guān)可以發(fā)揮強大的助推作用——如果開發(fā)人員不針對API使用APIM（API Management，即API管理）解決方案，網(wǎng)關(guān)可能會關(guān)閉他們的API——這一要求很苛刻，但對安全防護來說很必要。

幸運的是，??應對蔓延所采取的措施??大多與常見的API管理方法一致。隨著時間的推移，這些措施可以消除技術(shù)債務，并避免在開發(fā)過程后期或發(fā)布后通過補充的安全措施修復API，最終讓開發(fā)速度得到提高。

如果說API是企業(yè)的生命線，則API蔓延是對企業(yè)健康狀況的最大威脅之一。謹慎且主動的API蔓延控制措施會帶來巨大的回報，并且最終會提高開發(fā)人員的滿意程度。