現(xiàn)代系統(tǒng)依賴于通過各種網(wǎng)絡(luò)公開的 API（應(yīng)用程序接口）的復雜系統(tǒng)。很多企業(yè)借助 API 來傳輸數(shù)據(jù)和連接服務(wù)，提供便利。但同時，近年來一些嚴重的數(shù)據(jù)泄露都源于 API 遭到攻擊和破環(huán)，導致敏感的信息被不法分子利用。

那什么是 API 安全，它如何融入到整體的安全計劃？

所有應(yīng)用程序都使用 API（比如，對內(nèi)核的調(diào)用、軟件開發(fā)工具包、密碼庫和 SOAP 協(xié)議）。如今，供應(yīng)商提到的“ API 安全”是指這些 API 的子集 —— 通過網(wǎng)絡(luò)公開的那些 API。

就本質(zhì)而言，這些網(wǎng)絡(luò)公開的 API 使信息能夠自由傳遞以及在軟件組件之間進行交互。攻擊者有機會可以通過公共網(wǎng)絡(luò)、云和專用網(wǎng)絡(luò)的暴露端點來破壞系統(tǒng)的組件。一些知名公司（包括 USPS、T-Mobile 和 Salesforce 等）的重大違規(guī)事件是源于暴露或使用不安全的 API 端點。那么問題來了，要如何了解軟件安全計劃是否滿足企業(yè)所需的安全控制的要求，以確保使用和創(chuàng)建的 API 是安全的？首先，你需要定義什么是“API 安全”。

究竟什么是“API 安全”？

API 安全是對企業(yè)創(chuàng)建和使用的（暴露在網(wǎng)絡(luò)中）API 的保護。當然，這意味著需要使用與 API 緊密相關(guān)的通用安全控制：速率限制以及用戶、服務(wù)和請求的身份驗證和授權(quán)。這還意味著了解數(shù)據(jù)來源，以及在查看組成的系統(tǒng)時，在設(shè)計或查看討論時準確地尋找到上下文的位置。對于軟件安全領(lǐng)頭企業(yè)來說，這意味著應(yīng)用程序安全計劃可以在適當?shù)臅r間捕獲活動并將其應(yīng)用于暴露或使用 API的軟件。強大的 API 安全性不只是購買一些新工具，還源于一種安全文化，它涉及整個軟件安全計劃中的活動。

解決 API 安全難題

諸如微服務(wù)架構(gòu)等的流行軟件開發(fā)趨勢已將與軟件安全計劃（SSI）相關(guān)的軟件單元從“應(yīng)用程序”（或整體式）擴展至 API 的許多子組件。這些子組件具有自己的生命周期和合同，并必須遵守安全控制措施。軟件安全企業(yè)可以從以下方面提升安全性：

設(shè)計 API

API 是被用在前端客戶端（胖客戶端或瀏覽器）和后端系統(tǒng)之間，以及后端組件之間。進一步考慮，單個 API 端點可能最終會同時處理前端和后端請求。當各個 API 端點暴露于各種已知和未知的調(diào)用方（網(wǎng)關(guān)或負載平衡器的上游消耗、組成或包裝）時，很難確定單個 API 端點必須執(zhí)行哪些安全控制。應(yīng)用程序安全主管可以做出的一個決定是，推動使用 API，以明確記錄提供商和使用者應(yīng)承擔的安全責任。

架構(gòu)師還面臨識別 API 跨領(lǐng)域問題的麻煩。安全領(lǐng)導者應(yīng)該注意一些安全活動，例如統(tǒng)一訪問控制，以及那些與業(yè)務(wù)邏輯接近的活動，例如統(tǒng)一客戶身份認證。

安全控制

關(guān)于安全控制，API 安全中有多個抽象級別：業(yè)務(wù)邏輯中的控制（防止濫用）；保護業(yè)務(wù)邏輯的控制（身份驗證和授權(quán)）；以及最終由架構(gòu)啟用或定義的架構(gòu)安全控制（API 網(wǎng)關(guān)和微細分）。

由架構(gòu)決策支持的安全控制，對于在 API 安全的環(huán)境中的應(yīng)用程序開發(fā)而言相對較新。除了應(yīng)用于業(yè)務(wù)邏輯的安全控制之外，還擴展到諸如速度檢查、身份驗證和授權(quán)決策等。我們需要知道如何最好地隔離一組 API，并在那里通過網(wǎng)關(guān)啟用重要的安全控制。例如，微分段是否能達到要求？服務(wù)網(wǎng)格提供的安全控制效果如何？

一些架構(gòu)決策試圖提供阻塞點，以便安全架構(gòu)師更深入地了解這些分布式系統(tǒng)。雖然某些架構(gòu)決策需要集中管理的方法，但有的則啟用端點強制的方法。

當然，我們建議進行威脅建模。應(yīng)用安全企業(yè)必須開始識別各種類型的 API（第一方、第三方、客戶或使用者）的風險、每個 API 端點的關(guān)鍵控制、針對采用很多 API 的架構(gòu)（如微服務(wù)）造成的問題提供可接受的解決方案，以及是否將賣方索賠作為風險管理計劃的一部分。

物料清單

應(yīng)用安全企業(yè)需要了解他們的 API 足跡；衡量使用流程和工具來覆蓋該足跡的工作；跟蹤、記錄正在進行的安全活動并確定優(yōu)先級；并為各種類型的安全分析提供了豐富的上下文。當與程序所有者討論 API 安全時，我們經(jīng)常會發(fā)現(xiàn)現(xiàn)有的清單解決方案無法提供這些內(nèi)容。安全計劃負責人應(yīng)該仔細研究是否可以采用現(xiàn)有的物料清單解決方案，或者是否必須采用新的解決方案。

安全測試

如今的安全測試與以往一樣，對于深入了解上游軟件安全實踐的有效性都很重要。API 安全測試對手動、自動或者混合測試都提出了新挑戰(zhàn)。其中上下文關(guān)聯(lián)是一種。如果測試人員沒有輸入或感知威脅模型的能力，則無法找到對 SSI 不利的高風險問題，得不到及時修復。

靜態(tài)分析工具可以有效地識別特定于語言的軟件安全問題，或可以很好理解的注入攻擊，對于那些使用大量 API 的代碼庫仍然有效，但是前提是這些工具必須對用于公開這些 API 路由的庫和平臺進行建模。有的企業(yè)已經(jīng)采用靜態(tài)分析推動安全控制（例如，使用身份驗證和授權(quán)庫），并可用于 API 安全。

動態(tài)分析可以生成 API 覆蓋范圍，其典型方法包括對客戶端（或工具）、行為以及使用規(guī)范進行測試。該解決方案不是構(gòu)建一個工具，并強迫開發(fā)團隊使用一種測試工具，而是去支持各種可能的測試。

現(xiàn)代應(yīng)用程序和系統(tǒng)依賴于通過各種公共和專用網(wǎng)絡(luò)公開的 API 的復雜系統(tǒng)。我們可以采取一些步驟來了解這些更改如何影響我們的軟件安全計劃的各個要素，并確保在正確的時間和地方，將安全性內(nèi)置到暴露在或使用 API的軟件中。
? ? ? ?責任編輯:pj