我們現(xiàn)在的世界已經(jīng)逐漸由云計算、移動設(shè)備和微服務(wù)構(gòu)成。幾乎我們每一個交互的應(yīng)用都由API支持，尤其是在那些領(lǐng)先的云服務(wù)供應(yīng)商、移動應(yīng)用和微服務(wù)環(huán)境中。這就讓API成為了組織攻擊面的一個關(guān)鍵部分。

Akamai估計，大約83%的互聯(lián)網(wǎng)流量都是基于API的。其他的研究，比如像Salt Security認為，API攻擊從2021年到2022年增長了600%；而Gartner則預(yù)計，90%的web賦能應(yīng)用會因為暴露的API形成更大的攻擊面。最近由Imperva的研究則表明，有隱患的API導(dǎo)致組織的損失，每年大約會在400億美元到700億美元之間。

另一個導(dǎo)致API攻擊面擴大的關(guān)鍵因素是K8s和微服務(wù)的使用。最近一項研究發(fā)現(xiàn)了超過38萬個暴露的K8s的API服務(wù)器，這足以引起擔(dān)憂——畢竟K8s的API服務(wù)器是容器部署的核心控制組件。這同樣表明，API的安全性被很少關(guān)注，盡管API已經(jīng)是提升現(xiàn)代數(shù)字生態(tài)的粘接劑。

API不僅用于接入和請求數(shù)據(jù)，還會在流程中進行數(shù)據(jù)富集和修改等行為。這就意味著API自身不僅需要安全，他們當中流動的數(shù)據(jù)本身也需要安全。

這一現(xiàn)實強調(diào)了在關(guān)注API安全時，離不開應(yīng)用和數(shù)據(jù)安全的最佳實踐。和許多其他領(lǐng)域的技術(shù)一樣，大部分企業(yè)在建立他們自己的API庫這個基礎(chǔ)的任務(wù)時，就掙扎不已。這就表明他們?nèi)狈λ麄冇心男〢PI、和哪些API交互、以及API和哪些攻擊面關(guān)聯(lián)的可視化能力。

像Resurface Labs和Traceable AI這樣的組織已經(jīng)開始應(yīng)對這個問題，但是要做的工作依然很多。以下三點是組織應(yīng)該開始理解他們的API攻擊面情況以及其潛在的隱患。

如何開始評估API攻擊面

API安全對那些剛開始做安全的組織來說是一件令人頭疼的任務(wù)，尤其對于那些API庫雜亂無章的大企業(yè)而言。也就是說，需要一系列有效的措施和方法論，才能處理這個龐大而又無法解決的安全領(lǐng)域。這一方式需要結(jié)合治理、基礎(chǔ)設(shè)施安全和應(yīng)用級別的最佳實踐，才能降低組織的風(fēng)險。

除了將組織現(xiàn)有的API全部都歸庫以外，一個可能更好的起步方式，是識別和理解最常見的API安全問題。幸運的是，OWASP社區(qū)已經(jīng)有了API安全TOP10的清單。這個清單包括了受損對象、用戶授權(quán)/認證、過度數(shù)據(jù)暴露、缺乏速率限制等風(fēng)險。

受損的對象級別授權(quán)是指破壞了確保用戶只能接入他們被授權(quán)的對象的代碼級結(jié)構(gòu)。這一風(fēng)險又回到了最小權(quán)限接入控制的老問題，這一點在零信任中被持續(xù)推動。

受損的用戶認證則有多種形態(tài)的表現(xiàn)，包括脆弱的認證機制、在URL中存在敏感的認證信息、憑證填充等等。這些都是惡意人員通過已經(jīng)獲取的認證信息反復(fù)嘗試，以突破認證交互。這些脆弱性的解決方式包括了理解認證的流程、機制，并且使用行業(yè)標準的認證方式。

過度的數(shù)據(jù)暴露簡直是一個太過于常見的問題了。當和API相關(guān)的時候，這個隱患往往發(fā)生在API給用戶回復(fù)數(shù)據(jù)時，將不應(yīng)該暴露的敏感數(shù)據(jù)進行了回傳。組織解決這類問題的方式包括驗證API響應(yīng)中包含的數(shù)據(jù)，確保敏感數(shù)據(jù)不會不經(jīng)意中被包括其中。組織也應(yīng)該部署響應(yīng)驗證機制，保證敏感數(shù)據(jù)不被暴露。

和其他常見的隱患相比，缺乏速率限制控制更多會影響系統(tǒng)的可用性，而非機密性或者完整性。鑒于API經(jīng)常作為現(xiàn)代微服務(wù)、云和移動應(yīng)用之間的粘連劑，最終都要為客戶實現(xiàn)價值并且創(chuàng)收，可用性的影響非常關(guān)鍵。業(yè)務(wù)中斷意味著收入或者用戶信任的損失。如果在公共事務(wù)領(lǐng)域或者國家領(lǐng)域，就會對市政服務(wù)或者國家安全打來極大沖擊。

這些問題可能對那些經(jīng)驗老到的安全實踐人員而言非常明顯，畢竟認證、授權(quán)和DoS攻擊司空見慣。換種說法，將以上組織內(nèi)部和互聯(lián)網(wǎng)上的API問題都考慮進去，加上來自惡意份子針對API攻擊的高速增長速率，潛在的風(fēng)險就越發(fā)復(fù)雜。

API導(dǎo)致的橫向移動

由于API經(jīng)常作為應(yīng)用和數(shù)字環(huán)境的前門工作，針對API的攻擊經(jīng)常會進行系統(tǒng)之間的橫向移動。API能夠作為一個攻擊的起點，然后被用于接入下層系統(tǒng)、工作負載和數(shù)據(jù)。這就讓保護API極其重要。API的主要攻擊手段包括對象和用戶級別的認證和授權(quán)。因此，惡意份子并非只是針對API，而是API可以接入并傳輸?shù)臄?shù)據(jù)，以及它們身后的下層系統(tǒng)。

對API安全更多的關(guān)注

盡管說許多攻擊方式并不是只針對API的，但是一旦將這些攻擊和API在現(xiàn)代數(shù)字生態(tài)中的大規(guī)模使用結(jié)合到一起，就會有很大問題。幸運的是，一些趨勢正在逐漸顯現(xiàn)，包括對API安全企業(yè)和產(chǎn)品的加大投資、更多的API安全指導(dǎo)，以及日益增長的業(yè)內(nèi)對API安全引發(fā)問題的意識。

如果API已經(jīng)成為連接現(xiàn)代數(shù)字生態(tài)的系帶，那我們就要必須要確保這些系帶非常堅固，因為我們不需要一個用泡泡糖和鞋帶連接的生態(tài)。盡管說傳統(tǒng)基于邊界的安全可能已經(jīng)逐漸失效，API依然是現(xiàn)代系統(tǒng)的一個關(guān)鍵入口以及樞軸點。這不僅包括了對外的系統(tǒng)，同時也有內(nèi)部交互的系統(tǒng)。

我們同樣能看到越來越多在軟件供應(yīng)鏈方面的努力。這條鏈通過API為主要方式，將軟件驅(qū)動的系統(tǒng)聯(lián)系在一起。這表示API安全作為更為廣義的軟件供應(yīng)鏈生態(tài)的關(guān)鍵組件，確保整個鏈條的安全性。

點評

API安全一定程度上已經(jīng)不能說是一個新話題了，畢竟在過去一年中我們看到了大量的相關(guān)內(nèi)容。但是，API安全的落地始終不怎么理想。

一個很重要的原因就是在于API本身遍布了數(shù)字環(huán)境中各個方面，無論是從應(yīng)用角度，還是從數(shù)據(jù)角度，都無法完整描述API安全包含的內(nèi)容。多樣的應(yīng)用場景必然會帶來API可視化管理的困難；快速的業(yè)務(wù)發(fā)展與IT技術(shù)演化也必然導(dǎo)致當前環(huán)境中的API數(shù)量已經(jīng)相當龐大，且難以管理。

從API面臨的風(fēng)險入手確實一定程度上能夠緩解初入API安全時的手足無措，但是依然無法完全解決API可視化管理的問題。從當前來看，很難有一個企業(yè)能夠單獨、完整地囊括整個企業(yè)的API安全解決方案，正如本文最后提到的那樣，API安全也涉及到了軟件供應(yīng)鏈方面的問題，而這同樣是一個需要多方協(xié)同才能解決的領(lǐng)域。