如今，API不僅成為生態(tài)系統(tǒng)之間的交互窗口，更是構(gòu)建混合業(yè)務(wù)平臺(tái)的基礎(chǔ)。未來(lái)79%的物聯(lián)網(wǎng)流量將通過(guò)網(wǎng)關(guān)接入，50%的網(wǎng)絡(luò)流量將來(lái)自物聯(lián)網(wǎng)，而物聯(lián)網(wǎng)將貢獻(xiàn)超過(guò)500億的連接。與之相對(duì)應(yīng)的是危機(jī)來(lái)臨，開(kāi)放互聯(lián)也成了黑客眼中一條通往用戶端的“捷徑”。事實(shí)上，已經(jīng)有不少網(wǎng)絡(luò)攻擊者將API列為首選的入侵目標(biāo)之一。

物聯(lián)網(wǎng)漏洞難防 開(kāi)放接口也會(huì)被黑客盯上

考慮到物聯(lián)網(wǎng)的設(shè)備形態(tài)和功能千奇百怪，從終端、無(wú)線接入、網(wǎng)關(guān)，再到云平臺(tái)，涉及的環(huán)節(jié)眾多，要知道不少設(shè)備使用的操作系統(tǒng)也是不統(tǒng)一的，不是定制的就是非標(biāo)準(zhǔn)的，無(wú)形中為運(yùn)維人員增加了負(fù)擔(dān)。而在工業(yè)和制造業(yè)場(chǎng)景中，一些產(chǎn)線上的物聯(lián)網(wǎng)設(shè)備服役時(shí)間長(zhǎng)達(dá)數(shù)月或數(shù)年，但安全防護(hù)措施卻非常有限。

數(shù)據(jù)顯示，平均每家企業(yè)管理的API數(shù)量超過(guò)360種，其中有接近70%的接口會(huì)向合作伙伴開(kāi)放，而開(kāi)發(fā)者則可以借助API庫(kù)豐富代碼選擇，規(guī)模往往會(huì)達(dá)到數(shù)萬(wàn)量級(jí)。正因如此，才會(huì)說(shuō)調(diào)用API對(duì)接數(shù)據(jù)流或觸發(fā)響應(yīng)幾乎貫穿了每個(gè)代碼級(jí)的交互流程。

API的可擴(kuò)展性和可用性適用于多種編程語(yǔ)言，這也使得使用者能夠選擇自己擅長(zhǎng)的語(yǔ)言來(lái)進(jìn)行編程。無(wú)論軟件處于哪一種形式，API始終伴隨其中，并且隨著網(wǎng)絡(luò)環(huán)境下的接口越來(lái)越開(kāi)放，其對(duì)內(nèi)部應(yīng)用的影響力也會(huì)隨之增加。要知道，像谷歌、亞馬遜等公司的業(yè)務(wù)規(guī)模，每天進(jìn)行的API交互次數(shù)至少要達(dá)到數(shù)百萬(wàn)量級(jí)。

然而，存在于不同IT環(huán)境中的聯(lián)網(wǎng)設(shè)備，多數(shù)是由不同廠商“組裝”起來(lái)的，硬件、軟件、組件的提供方都不一樣。這種情況造成的困境之一是，有時(shí)候芯片升級(jí)了可對(duì)應(yīng)的軟件升級(jí)并沒(méi)有趕上，而安全補(bǔ)丁更新的時(shí)候組件又不支持。

這也就是為什么，有的物聯(lián)網(wǎng)安全廠商會(huì)在一開(kāi)始就希望將安全解決方案整合到一個(gè)平臺(tái)中，而不是之后不斷的打補(bǔ)丁。通過(guò)這種從芯片到網(wǎng)絡(luò)、再到云的集成式管理，原有安全認(rèn)證的復(fù)雜性降低了，也不用過(guò)于依賴第三方的證書授權(quán)。

當(dāng)然，如果沒(méi)有API，用戶在虛擬環(huán)境中調(diào)用程序時(shí)就要手動(dòng)完成，考慮到成千上萬(wàn)臺(tái)虛擬機(jī)的數(shù)量，這種工作量可不是幾個(gè)人能解決的。對(duì)于云計(jì)算廠商來(lái)說(shuō)，能否提供足夠豐富、足夠開(kāi)放的API，同時(shí)確保這些API經(jīng)過(guò)嚴(yán)格的安全測(cè)試，在用戶選擇服務(wù)商時(shí)有著關(guān)鍵作用。

不過(guò)，任何事都有兩面性。網(wǎng)絡(luò)應(yīng)用前端隨處可見(jiàn)的API逐漸變成了黑客攻擊的熱點(diǎn)，一旦端口被攻破隨之而來(lái)的就是大范圍的用戶信息外泄。通常，企業(yè)IT團(tuán)隊(duì)會(huì)通過(guò)API調(diào)用和管理云資源、服務(wù)編排、應(yīng)用鏡像等服務(wù)，而這些服務(wù)的可用性很大程度上會(huì)依賴于API的安全性，尤其是在客戶引入第三方服務(wù)的時(shí)候，讓API暴露在了外部環(huán)境中。

此時(shí)，API所面臨的挑戰(zhàn)往往會(huì)體現(xiàn)在幾個(gè)方面：外部攻擊、信息篡改、惡意跟蹤。首先還是老生常談的DDoS攻擊，其對(duì)關(guān)鍵API的入侵能導(dǎo)致網(wǎng)絡(luò)大面積癱瘓，并且占用大量計(jì)算資源使得程序中斷。此外，如果通過(guò)API建立聯(lián)系的用戶端和服務(wù)器端沒(méi)有經(jīng)過(guò)特殊加密，很容易造成信息泄露。

其次是請(qǐng)求參數(shù)的篡改，采用https協(xié)議傳輸?shù)拿魑募用芎笠灿锌赡鼙缓诳徒孬@，進(jìn)而將數(shù)據(jù)包偽造發(fā)起重放攻擊。這時(shí)候，安全證書往往也是難以幸免的，因?yàn)楹诳蜁?huì)讓需求發(fā)起方使用“仿制證書”通信，從而獲得看似已經(jīng)被加密的內(nèi)容。

再有就是黑客會(huì)有意追蹤物聯(lián)網(wǎng)設(shè)備的端口，這樣可以直接獲得API的控制權(quán)，或者向標(biāo)的引入惡意內(nèi)容設(shè)置漏洞陷阱。其實(shí)之前所說(shuō)的重放攻擊，就是將已經(jīng)竊取到的內(nèi)容再完整的發(fā)送給接收方，這也是https無(wú)法阻止的。舉個(gè)例子，雖然黑客不能憑借重復(fù)信息盜取密碼，但卻能在獲得加密口令后從后端發(fā)起攻擊。

考慮到這些風(fēng)險(xiǎn)，服務(wù)商自然也要積極完善API的安全性。舉個(gè)例子，客戶端將密鑰添加到參數(shù)傳輸過(guò)程中，結(jié)合口令發(fā)送給服務(wù)端，后者進(jìn)行二次加密后再給出一個(gè)口令，通過(guò)比對(duì)前后兩次口令的一致性來(lái)認(rèn)定是否為合法請(qǐng)求。由于黑客無(wú)法獲知簽名密鑰，因此既是修改請(qǐng)求參數(shù)也不能對(duì)其進(jìn)行簽名，更不能獲得之后的口令。

好在，已有不少云服務(wù)商使用API認(rèn)證或API網(wǎng)關(guān)來(lái)監(jiān)控代碼庫(kù)中API的狀態(tài)，不僅注視著流量和分析處理進(jìn)程，還會(huì)執(zhí)行相應(yīng)的安全策略有效削減DDoS攻擊的風(fēng)險(xiǎn)。有數(shù)據(jù)顯示，超過(guò)60%的企業(yè)正在使用網(wǎng)絡(luò)應(yīng)用防火墻或API網(wǎng)關(guān)構(gòu)建混合方案來(lái)保護(hù)數(shù)據(jù)。

同時(shí)，云服務(wù)商還可以提供類似的全托管服務(wù)，不僅在開(kāi)發(fā)側(cè)支持 HTTP、WebSockets、MQTT，減少了代碼在設(shè)備上占用的空間并降低帶寬要求，還在所有連接點(diǎn)范圍內(nèi)提供了身份驗(yàn)證和端到端加密服務(wù)。

可以說(shuō)，API在復(fù)雜環(huán)境中扮演的角色愈發(fā)重要，自然也就成為了黑客的關(guān)注重點(diǎn)。除了要在應(yīng)用端建立防護(hù)措施，更要在代碼上線前對(duì)API進(jìn)行測(cè)試，盡力消除可能存在漏洞，將風(fēng)險(xiǎn)降到更低。