（文章來源：中關(guān)村在線）

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

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

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

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

然而，存在于不同IT環(huán)境中的聯(lián)網(wǎng)設(shè)備，多數(shù)是由不同廠商“組裝”起來的，硬件、軟件、組件的提供方都不一樣。這種情況造成的困境之一是，有時候芯片升級了可對應(yīng)的軟件升級并沒有趕上，而安全補丁更新的時候組件又不支持。這也就是為什么，有的物聯(lián)網(wǎng)安全廠商會在一開始就希望將安全解決方案整合到一個平臺中，而不是之后不斷的打補丁。通過這種從芯片到網(wǎng)絡(luò)、再到云的集成式管理，原有安全認(rèn)證的復(fù)雜性降低了，也不用過于依賴第三方的證書授權(quán)。

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

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

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

其次是請求參數(shù)的篡改，采用https協(xié)議傳輸?shù)拿魑募用芎笠灿锌赡鼙缓诳徒孬@，進而將數(shù)據(jù)包偽造發(fā)起重放攻擊。這時候，安全證書往往也是難以幸免的，因為黑客會讓需求發(fā)起方使用“仿制證書”通信，從而獲得看似已經(jīng)被加密的內(nèi)容。再有就是黑客會有意追蹤物聯(lián)網(wǎng)設(shè)備的端口，這樣可以直接獲得API的控制權(quán)，或者向標(biāo)的引入惡意內(nèi)容設(shè)置漏洞陷阱。其實之前所說的重放攻擊，就是將已經(jīng)竊取到的內(nèi)容再完整的發(fā)送給接收方，這也是https無法阻止的。舉個例子，雖然黑客不能憑借重復(fù)信息盜取密碼，但卻能在獲得加密口令后從后端發(fā)起攻擊。

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

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

同時，云服務(wù)商還可以提供類似的全托管服務(wù)，不僅在開發(fā)側(cè)支持?HTTP、WebSockets、MQTT，減少了代碼在設(shè)備上占用的空間并降低帶寬要求，還在所有連接點范圍內(nèi)提供了身份驗證和端到端加密服務(wù)。可以說，API在復(fù)雜環(huán)境中扮演的角色愈發(fā)重要，自然也就成為了黑客的關(guān)注重點。除了要在應(yīng)用端建立防護措施，更要在代碼上線前對API進行測試，盡力消除可能存在漏洞，將風(fēng)險降到更低。
? ? ? （責(zé)任編輯：fqj）