作為數(shù)字經(jīng)濟(jì)和信息社會的核心資源，數(shù)據(jù)對國家治理、經(jīng)濟(jì)運(yùn)行機(jī)制、社會生活方式等產(chǎn)生著深刻影響。數(shù)據(jù)在流動、分享、加工和處理的過程中創(chuàng)造價值，但其前提是保障數(shù)據(jù)安全無虞。因?yàn)辇嫶蟮臄?shù)據(jù)足以勾勒出數(shù)以億計的人物畫像，而支撐這些龐大數(shù)據(jù)高速傳輸?shù)闹匾ǖ溃闶茿PI。因此，API接口安全將很大程度決定了互聯(lián)網(wǎng)數(shù)據(jù)的安全。

　　PART1 API資產(chǎn)不明引發(fā)安全困境

　　據(jù)《Salt Labs State of API Security Report, Q1 2022》報告，在受訪者最關(guān)心的API安全問題中，僵尸API以43%占比高居第一；遠(yuǎn)超過以22%的占比位居第二的賬戶接管/濫用；還有83%的受訪者對組織API 資產(chǎn)清單是否完整沒有信心。

　　為何企業(yè)對僵尸API及API清單完整度有如此大的擔(dān)憂？安全隱患往往藏于“未知”，未知的僵尸API、未知的影子API、未知的敏感數(shù)據(jù)暴露等，根源都在于企業(yè)對API資產(chǎn)全貌的未知。安全的管理與防護(hù)始于“已知”和“可見”，人們難以掌控那些被遺忘的、看不見摸不著的資產(chǎn)安全狀況。然而正是這些被人遺忘、不可管控的API，因其往往潛藏著未被修復(fù)的漏洞，備受攻擊者青睞。

　　即便是企業(yè)已經(jīng)開始重視并著手治理僵尸API問題，也仍有一處容易被忽略的巨大風(fēng)險——僵尸參數(shù)。不同于那些被徹底遺忘的僵尸API，這些僵尸參數(shù)有可能還存在于當(dāng)前仍在服務(wù)且持續(xù)維護(hù)的API接口中。常見的僵尸參數(shù)，例如在開發(fā)測試周期內(nèi)設(shè)置的調(diào)試參數(shù)、系統(tǒng)屬性參數(shù)，它們在接口正式上線后未對外暴露給用戶，但仍能被暗處的攻擊者惡意調(diào)用。攻擊者基于僵尸參數(shù)，能夠利用批量分配等漏洞獲得越權(quán)的響應(yīng)。一旦這些未知的API脆弱點(diǎn)被惡意利用，背后的核心業(yè)務(wù)數(shù)據(jù)、平臺用戶數(shù)據(jù)等海量敏感數(shù)據(jù)在黑客面前就宛如“裸奔”了，再無秘密可言。

　　PART2 API資產(chǎn)的可知、可視、可管

　　如何更好地管理API全貌資產(chǎn)，而非僅是管理“已知”資產(chǎn)？傳統(tǒng)的API管理方案往往是通過API網(wǎng)關(guān)進(jìn)行資產(chǎn)管理與更新，業(yè)務(wù)開發(fā)人員在開發(fā)過程中需及時將新開發(fā)的API注冊在API網(wǎng)關(guān)上，并在API內(nèi)容發(fā)生改變時同步更新API定義內(nèi)容。在這種資產(chǎn)維護(hù)方式下，資產(chǎn)清單的準(zhǔn)確性與有效性完全依賴于人工管理。

　　隨著企業(yè)業(yè)務(wù)快速擴(kuò)張，開發(fā)人員在不可避免地需要交付更多功能、加快發(fā)布速度以適應(yīng)千變?nèi)f化的市場，不斷上線大量新版本API。如此快速的迭代對API資產(chǎn)維護(hù)提出了很高的要求，一旦人工維護(hù)出現(xiàn)紕漏，僵尸API、僵尸參數(shù)等便會不斷積聚，造成惡性循環(huán)。

　　另需注意的一點(diǎn)是，關(guān)注僵尸API、影子API等API資產(chǎn)管理漏洞的往往是企業(yè)的安全人員，而API網(wǎng)關(guān)通常由業(yè)務(wù)部門維護(hù)。也就是說，安全人員對API風(fēng)險的防控工作，是以業(yè)務(wù)人員的API資產(chǎn)維護(hù)工作為基礎(chǔ)的，這之間就存在跨部門協(xié)作的壁壘問題。

　　那么，如何解決上述的API資產(chǎn)清單人工維護(hù)成本高且準(zhǔn)確性難以保障的問題？如何打破安全部門與業(yè)務(wù)部門在API資產(chǎn)管理協(xié)作上的壁壘？面對這兩大問題，傳統(tǒng)的API網(wǎng)關(guān)管理模式已不再有效，需要引入新的管理模式——API資產(chǎn)發(fā)現(xiàn)，實(shí)現(xiàn)對全貌API資產(chǎn)的自動盤點(diǎn)與分析。

　　PART3 API資產(chǎn)發(fā)現(xiàn)的應(yīng)用實(shí)踐

　　為了實(shí)現(xiàn)API的安全應(yīng)用，企業(yè)組織需要進(jìn)行全面的API資產(chǎn)發(fā)現(xiàn)，從API資產(chǎn)盤點(diǎn)，到API路徑折疊與規(guī)范化，再到進(jìn)一步的敏感數(shù)據(jù)暴露面清點(diǎn)?；谝陨显O(shè)計思路，網(wǎng)宿安全在API防護(hù)產(chǎn)品上進(jìn)行應(yīng)用實(shí)踐，已可較好實(shí)現(xiàn)API資產(chǎn)的可知、可視、可管。

　　1.全自動的資產(chǎn)盤點(diǎn)

　　基于流量數(shù)據(jù)分析，無需改變用戶現(xiàn)有部署架構(gòu)，實(shí)時盤點(diǎn)流量中的API資產(chǎn)。全自動梳理API列表資產(chǎn)、API參數(shù)資產(chǎn)、API調(diào)用方法等多維度API資產(chǎn)清單。根據(jù)預(yù)定義的API流量請求特征，結(jié)合機(jī)器學(xué)習(xí)的API流量基線，持續(xù)性地捕獲流量中的API資源。區(qū)別于普通URL資源，API在數(shù)據(jù)傳輸格式、資源/操作定義等方面具有其鮮明的特性。通過對全量API列表資產(chǎn)進(jìn)行進(jìn)一步分析，描繪其請求趨勢、響應(yīng)狀態(tài)、被調(diào)用方法等接口活躍狀態(tài)，即可令A(yù)PI列表資產(chǎn)可視、可知。

　　API資產(chǎn)自動盤點(diǎn)的范圍不僅限于API列表資產(chǎn)，清點(diǎn)參數(shù)資產(chǎn)同樣重要。針對捕獲到的API列表清單，API防護(hù)產(chǎn)品需要能夠通過建立正常用戶數(shù)據(jù)傳輸基線，識別API調(diào)用需攜帶的參數(shù)名稱、參數(shù)位置、參數(shù)類型、是否為必帶參數(shù)等，甚至提煉請求Body的數(shù)據(jù)結(jié)構(gòu)，從而為企業(yè)充分清點(diǎn)全量API列表資產(chǎn)中正被使用的參數(shù)資產(chǎn)，發(fā)現(xiàn)僵尸參數(shù)或是攻擊偽造的惡意參數(shù)。

　　2. API路徑折疊與規(guī)范化

　　API 資產(chǎn)中，存在眾多類似“api/test/111”與“api/test/112”這樣路徑高度重合的API端點(diǎn)。進(jìn)一步觀測這些近似的API端點(diǎn)，會發(fā)現(xiàn)它們往往也具有相同的用途。這些API端點(diǎn)往往僅有固定位置的路徑參數(shù)不同，而路徑參數(shù)的變量多達(dá)成百上千。

　　這類路徑、用途高度重合的API端點(diǎn)若全盤列出，可能會造成API資產(chǎn)列表過于龐大的問題。充斥著這些冗余數(shù)據(jù)的海量列表給管理增加了難度，甚至難以完成人工確認(rèn)。因此，API防護(hù)產(chǎn)品需要能夠持續(xù)分析這類高重合度的API端點(diǎn)，將這些端點(diǎn)在API資產(chǎn)列表中進(jìn)行折疊，并將路徑中的變量規(guī)范為路徑參數(shù)，以進(jìn)一步聯(lián)動后續(xù)防護(hù)模塊進(jìn)行參數(shù)合規(guī)檢測。

　　3. 敏感數(shù)據(jù)暴露面清點(diǎn)

　　各類敏感數(shù)據(jù)在接口傳輸過程中飛速流轉(zhuǎn)，有些敏感數(shù)據(jù)是必要傳輸內(nèi)容，但有部分敏感數(shù)據(jù)因接口的過度暴露而遭到不必要的泄露。在實(shí)際應(yīng)用中，敏感數(shù)據(jù)暴露面的清點(diǎn)可有助發(fā)現(xiàn)此現(xiàn)象。敏感數(shù)據(jù)識別引擎實(shí)時分析、判別請求數(shù)據(jù)與響應(yīng)數(shù)據(jù)中流轉(zhuǎn)的敏感參數(shù)信息，智能識別身份證、手機(jī)號、銀行卡號等敏感數(shù)據(jù)，分析與統(tǒng)計全盤API敏感數(shù)據(jù)暴露態(tài)勢，幫助企業(yè)擺脫敏感數(shù)據(jù)“燈下黑”的困境。

更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<