API安全建設(shè)白皮書

1、 HYPERLINK / API 安全建設(shè)白皮書目錄 HYPERLINK l _bookmark0 前言 3 HYPERLINK l _bookmark1 API 是什么 3 HYPERLINK l _bookmark2 API 的定義 3 HYPERLINK l _bookmark3 API 的類型 4 HYPERLINK l _bookmark4 小結(jié) 5 HYPERLINK l _bookmark5 API 的安全挑戰(zhàn) 5 HYPERLINK l _bookmark6 API 防護(hù)缺失已成業(yè)務(wù)和數(shù)據(jù)安全最大風(fēng)險(xiǎn)敞口 6 HYPERLINK l _bookmark7 API 面臨的主要安全

2、問題 6 HYPERLINK l _bookmark8 API 資產(chǎn)不可見 6 HYPERLINK l _bookmark9 攻擊面增加 7 HYPERLINK l _bookmark10 API 攻擊更加隱蔽 8 HYPERLINK l _bookmark11 監(jiān)管合規(guī)性挑戰(zhàn) 9 HYPERLINK l _bookmark12 2.3. 小結(jié) 10 HYPERLINK l _bookmark13 API 全生命周期安全防護(hù) 10 HYPERLINK l _bookmark14 API 安全設(shè)計(jì)的指導(dǎo)原則 11 HYPERLINK l _bookmark15 3.1.1. 5A 原則 11 H

3、YPERLINK l _bookmark16 3.1.2. 縱深防御原則 12 HYPERLINK l _bookmark17 API 生命周期的安全防護(hù)模型 13 HYPERLINK l _bookmark18 設(shè)計(jì)階段：引入威脅建模 14 HYPERLINK l _bookmark19 開發(fā)階段：安全開發(fā)意識(shí)和規(guī)范培訓(xùn)，引入安全工具 15 HYPERLINK l _bookmark20 測(cè)試階段：漏洞加入測(cè)試流程，使用 AST 類工具提高覆蓋率 16 HYPERLINK l _bookmark21 上線運(yùn)行階段：借助網(wǎng)關(guān)、WAF 和流量審計(jì)工具提早感知攻擊面 17 HYPERLINK l

4、_bookmark22 迭代階段：利用安全工具及時(shí)審計(jì) API 變更 21 HYPERLINK l _bookmark23 下線階段：及時(shí)下線僵尸影子 API 213.3. 小結(jié) 22結(jié)束語 22前言數(shù)字經(jīng)濟(jì)時(shí)代，數(shù)據(jù)成了重要生產(chǎn)要素，對(duì)數(shù)據(jù)要素的掌控和利用能力，已成為經(jīng)濟(jì)增長(zhǎng)的核心驅(qū)動(dòng)力。數(shù)據(jù)因其變現(xiàn)價(jià)值極高使其成為企業(yè)的重要資產(chǎn)，與此同時(shí)圍繞數(shù)據(jù)的攻防也變得越來越劇烈，數(shù)據(jù)的安全是網(wǎng)絡(luò)安全不可或缺的重要組成部分。在云計(jì)算、大數(shù)據(jù)、物聯(lián)網(wǎng)、人工智能、5G 等新興技術(shù)的推動(dòng)下，伴隨著近些年的疫情因素，大部分企業(yè)都在積極推進(jìn)數(shù)字化和在線化轉(zhuǎn)型。數(shù)字化和在線化使得連接數(shù)據(jù)和應(yīng)用的 API 爆炸式增

5、長(zhǎng)。企業(yè)通過 API 的能力將數(shù)據(jù)資源整合，提供給到用戶、合作伙伴、內(nèi)部員工等多方使用，讓數(shù)據(jù)在多方流動(dòng)起來，并借助云智物大移的技術(shù)提高企業(yè)的生產(chǎn)效率。API 在數(shù)字化轉(zhuǎn)型中扮演的角色將愈發(fā)重要，通過 API 來進(jìn)行數(shù)據(jù)交換和實(shí)現(xiàn)業(yè)務(wù)邏輯成為最常見的方式，每個(gè) API 都有可能成為一個(gè)攻擊面，API 增多，漏洞也會(huì)增多，API 也因此成為攻擊者的重點(diǎn)攻擊對(duì)象。2022 年國(guó)家級(jí)攻防演練新增了對(duì)于數(shù)據(jù)泄漏的攻防點(diǎn)，說明數(shù)據(jù)的安全保護(hù)逐步從監(jiān)管法規(guī)落實(shí)到具體的攻防實(shí)戰(zhàn)中來。雖然入侵拖庫帶來的數(shù)據(jù)泄漏隨著網(wǎng)絡(luò)邊界安全水位增高，難度已經(jīng)非常大了，但近些年因 API 安全問題導(dǎo)致的數(shù)據(jù)泄漏事件卻頻頻發(fā)生

6、，可以看到 API安全是一個(gè)常見但似乎又不為人熟知的挑戰(zhàn)。OWASP 每年整理 API Security Top 10 問題都會(huì)有新的變化，值得每個(gè)企業(yè)關(guān)注并更新應(yīng)對(duì)策略。從傳統(tǒng)的 WAF 到 Gartner 提出的 WAAP 方案， API 的安全問題成為行業(yè)關(guān)注的新焦點(diǎn)。API 是什么API 的定義API（Application Programming Interface，應(yīng)用程序接口）是一種計(jì)算接口，定義了軟件之間的數(shù)據(jù)交互方式、功能類型。隨著互聯(lián)網(wǎng)的普及和發(fā)展，API 從早期的軟件內(nèi)部調(diào)用的接口，擴(kuò)展到互聯(lián)網(wǎng)上對(duì)外提供服務(wù)的接口。調(diào)用者通過調(diào)用 API，可以獲取接口提供的各項(xiàng)服務(wù)，而無

7、須訪問源碼，也無須理解內(nèi)部工作機(jī)制的細(xì)節(jié)。目前我們討論的 API 更多是指 Web API，不同于由操作系統(tǒng)或庫公開給在同一臺(tái)機(jī)器上運(yùn)行的應(yīng)用程序的 API。Web API 是一種編程接口，由一個(gè)或多個(gè)公開暴露的端點(diǎn)組成，指向已定義的請(qǐng)求-響應(yīng)消息系統(tǒng)，通常以 JSON 或 XML 表示。API 的類型Web API 被定義為基于 HTTP，今天看到的四種主要類型的 Web API ：RESTful API：可以追溯到 Roy Fielding 在 2000 年的博士論文，代表性狀態(tài)傳輸是最常見的 Web API 類型，通常使用 JSON（JavaScript 對(duì)象表示法）來處理數(shù)據(jù)。REST

8、ful AP I 很容易被現(xiàn)代前端框架（例如，React 和 React Native）使用，并促進(jìn) Web 和移動(dòng)應(yīng)用程序的開發(fā)。它們成為任何 Web API 的事實(shí)上的標(biāo)準(zhǔn)，包括用于 B2B 的那些，是目前的主流應(yīng)用風(fēng)格。SOAP API： SOAP 使用詳細(xì)的擴(kuò)展標(biāo)記語言 (XML) 進(jìn)行遠(yuǎn)程過程調(diào)用 (RPC)。目前使用比較少，在一些老舊的系統(tǒng)能還能看到。GraphQL API： Facebook 開發(fā)的新 GraphQL 標(biāo)準(zhǔn)通過單個(gè) POST 端點(diǎn)（通常是 /graph ql）提供數(shù)據(jù)庫訪問，多用于具有圖結(jié)構(gòu)的數(shù)據(jù)場(chǎng)景，實(shí)際應(yīng)用目前比較少見。gRPC API：一種新的、Google

9、 開發(fā)的基于 HTTP/2.0 的高性能二進(jìn)制協(xié)議，主要用于一些海量用戶的高并發(fā)請(qǐng)求的場(chǎng)景。小結(jié)在當(dāng)今應(yīng)程序驅(qū)動(dòng)的世界中，創(chuàng)新的個(gè)基本元素就是 API。從銀、零售、運(yùn)輸?shù)轿锫?lián)、動(dòng)駕駛汽和智慧城市，API 是現(xiàn)代移動(dòng)端、SaaS 和 web 應(yīng)程序的關(guān)鍵部分，企業(yè)在向客戶、向合作伙伴和機(jī)構(gòu)內(nèi)部的應(yīng)程序中隨處可API 的使。Akamai 的統(tǒng)計(jì)報(bào)告指出“API 請(qǐng)求已占所有應(yīng)用請(qǐng)求的 83，預(yù)計(jì) 2024 年 API 請(qǐng)求命中數(shù)將達(dá)到 42 萬億次”。從本質(zhì)上講，API 暴露了應(yīng)程序的邏輯和敏感數(shù)據(jù)，如個(gè)身份信息，正因?yàn)槿绱耍絹碓蕉嗟爻蔀楣粽叩臉?biāo)。沒有安全的 API，快速創(chuàng)新將是不可能的。A

10、PI 的安全挑戰(zhàn)從 API 的發(fā)展過程可了解到，API 安全問題一直伴隨著 API 技術(shù)的發(fā)展而不斷變化。API安全是從安全的角度關(guān)注 API 領(lǐng)域的安全問題和這些問題的解決方案，關(guān)注的安全領(lǐng)域與傳統(tǒng)的 Web 安全比較接近，但又不同于 Web 安全。傳統(tǒng) Web 安全更多的是關(guān)注 Web 應(yīng)用程序的安全性，以服務(wù)器端應(yīng)用程序安全為主，其漏洞表現(xiàn)形式主要為 SQL 注入、XSS、CSRF 等。而新形勢(shì)下的 API 由于承載了業(yè)務(wù)邏輯和數(shù)據(jù)流動(dòng)，隨著微服務(wù)和云計(jì)算的發(fā)展，模塊之間越來越獨(dú)立，每個(gè)模塊可以根據(jù)請(qǐng)求需要?jiǎng)討B(tài)擴(kuò)容，原來的服務(wù)器邊界被打破；攻擊面不斷擴(kuò)大的情況下帶來了新的安全管理問題和安

11、全技術(shù)問題，面臨的外部環(huán)境比傳統(tǒng)的 Web 安全更為復(fù)雜。從云管端的角度來看，API 安全在服務(wù)器端包含 API 服務(wù)及其運(yùn)行環(huán)境（與傳統(tǒng) Web 安全相似）的安全，管道側(cè)包括 API 消息傳輸?shù)陌踩?，終端包含 API 客戶端應(yīng)用程序、IoT 設(shè)備的安全、監(jiān)管政策的安全風(fēng)險(xiǎn)等。從安全場(chǎng)景分類的角度來看，API 安全包含了網(wǎng)絡(luò)安全、Web應(yīng)用安全、安全開發(fā)、監(jiān)管合規(guī)多個(gè)方面。在網(wǎng)絡(luò)層面，API 安全主要關(guān)注客戶端與 API 服務(wù)器端之間的通信安全；在 Web 應(yīng)用層面，重點(diǎn)關(guān)注 API 客戶端與 API 服務(wù)器端之間的協(xié)議規(guī)范、賬號(hào)的安全、應(yīng)用安全審計(jì)、常見的 API 漏洞以及如何通過 API

12、安全設(shè)計(jì)規(guī)避這些安全問題；在安全開發(fā)層面，從 API 生命周期的角度，結(jié)合 SDL 或 DevSecOps 模型來綜合管理 API 開發(fā)過程的安全性；在監(jiān)管合規(guī)層面，需要結(jié)合法律法規(guī)和行業(yè)監(jiān)管要求，考慮 API 數(shù)據(jù)隱私保護(hù)和合規(guī)性設(shè)計(jì)。API 防護(hù)缺失已成業(yè)務(wù)和數(shù)據(jù)安全最大風(fēng)險(xiǎn)敞口2021 年 IBM Security X-Force 報(bào)告中指出，其分析的數(shù)據(jù)安全事件中有三分之二是由不安全的 API 造成的。據(jù) Gartner 提供的數(shù)據(jù)顯示，到 2025 年，由于 API 的爆炸式增長(zhǎng)超過了 API 管理工具的能力，將有 50的企業(yè)出現(xiàn) API 安全防護(hù)缺位，并且有 90的企業(yè)僅能為其公開

13、發(fā)布的 API 進(jìn)行保護(hù)，而其它 API 則不受監(jiān)控，并且大部分企業(yè)缺乏 API 安全的實(shí)踐經(jīng)驗(yàn)。 Gartner 因此預(yù)測(cè)，到 2022 年，API 濫用將成為導(dǎo)致企業(yè) Web 應(yīng)用程序數(shù)據(jù)泄露最常見的攻擊媒介，甚至在 2024 年 API 安全問題引起的數(shù)據(jù)泄露風(fēng)險(xiǎn)將翻倍。下圖是近些年一些典型的因 API 漏洞導(dǎo)致的攻擊事件：事件主體事件經(jīng)過Facebook第三方應(yīng)用通過 API 獲取 5 千萬用戶數(shù)據(jù)， 并用以政治廣告投放Linkedin因?yàn)?API 濫用導(dǎo)致泄漏 7 億用戶的姓名、郵件、手機(jī)號(hào)碼、行業(yè)等信息微博通訊錄匹配查詢 API 被撞庫，導(dǎo)致 5 億用戶信息泄漏美國(guó)郵政 UPS因

14、API 認(rèn)證漏洞導(dǎo)致 6000 萬用戶信息泄漏淘寶兩個(gè) API 的邏輯漏洞導(dǎo)致 11 億的用戶購(gòu)物信息泄漏攻防演練企業(yè)OA 系統(tǒng)任意用戶登錄漏洞、ajax.do 文件上傳漏洞、任意文件上傳漏洞導(dǎo)致靶標(biāo)系統(tǒng)被攻破等API 是數(shù)據(jù)交互最重要的傳輸方式之一，也因此成為攻擊者竊取數(shù)據(jù)的重點(diǎn)攻擊對(duì)象。與此同時(shí)，由于 API 防護(hù)的缺失，企業(yè)對(duì)外暴露了哪些 API、對(duì)誰開放 API、API 通信中哪些敏感數(shù)據(jù)在流動(dòng)等問題都未得到應(yīng)有的重視。攻擊者可以通過 API 認(rèn)證授權(quán)漏洞、數(shù)據(jù)過度暴露、數(shù)據(jù)可遍歷、安全配置缺陷等攻擊 API 進(jìn)行數(shù)據(jù)竊取和業(yè)務(wù)攻擊。API 面臨的主要安全問題API 資產(chǎn)不可見大部分企

15、業(yè)并沒有把 API 資產(chǎn)納入到資產(chǎn)盤點(diǎn)的范疇，未做好全面的資產(chǎn)梳理工作；而且API 隨著業(yè)務(wù)的變更也在持續(xù)的迭代更新，導(dǎo)致企業(yè)對(duì) API 進(jìn)行安全測(cè)評(píng)時(shí)遺漏了部分資產(chǎn)或長(zhǎng)期未對(duì)相關(guān)應(yīng)用進(jìn)行維護(hù)。另一方面，API 上流動(dòng)的數(shù)據(jù)以及關(guān)聯(lián)的賬號(hào)，大部分企業(yè)也沒有將其納入到資產(chǎn)進(jìn)行統(tǒng)一的管理和維護(hù)，一旦某類 API 框架型漏洞爆發(fā)或被黑客入侵時(shí)無法及時(shí)定位到相關(guān)應(yīng)用節(jié)點(diǎn)，將錯(cuò)過最佳的應(yīng)急響應(yīng)時(shí)間。資產(chǎn)的可見性是安全的基礎(chǔ)，API 由于數(shù)量大、更新快、且關(guān)聯(lián)有敏感數(shù)據(jù)和賬號(hào)的變更，導(dǎo)致 API 資產(chǎn)很難通過有限人力以靜態(tài)的方法來完成持續(xù)有效的梳理。攻擊面增加隨著云計(jì)算技術(shù)的廣泛應(yīng)用，越來越多的業(yè)務(wù)遷移上

16、云，云原生的開發(fā)基于微服務(wù)架構(gòu)和 k8s 等彈性擴(kuò)容模式，相較于傳統(tǒng)數(shù)據(jù)中心的單點(diǎn)調(diào)用，API 成為模塊間通訊的標(biāo)準(zhǔn)，業(yè)務(wù)邏輯分散在多個(gè)微服務(wù)模塊，無論東西向和南北向都有無數(shù)的 API，每個(gè) API 可能成為一個(gè)攻擊面，從而導(dǎo)致需要防范的攻擊面比原來要大很多。攻擊面說明認(rèn)證授權(quán)存在漏洞引入攻擊面某些 API 在設(shè)計(jì)之初對(duì)身份認(rèn)證的設(shè)計(jì)存在不足或者缺失，導(dǎo)致攻擊者可以進(jìn)行未授權(quán)或者越權(quán)攻擊，可以通過 API 任意訪問訪問數(shù)據(jù)權(quán)限設(shè)計(jì)不合理，致使用戶 A 可以訪問到屬于同一角色的用戶B 的數(shù)據(jù)出現(xiàn)水平越權(quán)訪問的攻擊；或者普通權(quán)限 A 用戶可以操作管理員 B 用戶的功能，出現(xiàn)垂直越權(quán)的攻擊密碼安全性

17、校驗(yàn)不足，攻擊者可利用弱密碼發(fā)起攻擊，進(jìn)行賬號(hào)的破解輸入?yún)?shù)校驗(yàn)不嚴(yán)引入攻擊面在 API 設(shè)計(jì)和迭代的過程中，研發(fā)人員對(duì) API 的入?yún)⑷鄙傩ｒ?yàn)或者校驗(yàn)不嚴(yán)格，可能會(huì)被攻擊者利用構(gòu)造的輸入來進(jìn)行注入類攻擊如 SQL、XSS、SSRF或者利用參數(shù)遍歷與用戶身份進(jìn)行組合帶來越權(quán)類攻擊設(shè)計(jì)不合理引入攻擊面數(shù)據(jù)權(quán)限，某些 API 在設(shè)計(jì)時(shí)為兼容多個(gè)功能會(huì)將過多的數(shù)據(jù)雜糅到一起返回至前端，或者將脫敏和明文數(shù)據(jù)一起返回，然后由前端去篩選相關(guān)的數(shù)據(jù)。這導(dǎo)致 API 返回過多的數(shù)據(jù)，攻擊者可通過流量攔截等手段獲取 API 原始返回的數(shù)據(jù)，從而存在數(shù)據(jù)泄漏的隱患API 常見的攻擊面：，對(duì)于登錄場(chǎng)景類，API 在

18、出錯(cuò)提示時(shí)對(duì)錯(cuò)誤信息展示的過于詳細(xì)，攻擊者可以利用提示信息來進(jìn)行撞庫掃號(hào)攻擊API 未對(duì)傳輸數(shù)據(jù)進(jìn)行加密設(shè)計(jì)而直接進(jìn)行明文傳輸，攻擊者可通過網(wǎng)絡(luò)嗅探等手段直接獲取 API 的交互格式以及數(shù)據(jù)，通過對(duì)獲取的數(shù)據(jù)進(jìn)行分析，并進(jìn)行下一步的攻擊API 設(shè)計(jì)時(shí)沒有考慮到重放邏輯、頻率限制、事務(wù)完整性邏輯等業(yè)務(wù)側(cè)邏輯的問題，導(dǎo)致攻擊者可以通過重放、修改參數(shù)等方式來完成金額修改，篡改交易的攻擊代碼實(shí)現(xiàn)上存在邏輯 bug，導(dǎo)致攻擊者可利用 bug 來進(jìn)行攻擊安全配置缺陷引入攻擊面允許 web 服務(wù)器任意目錄瀏覽、未關(guān)閉 HTTP 標(biāo)頭配置、沒有打開一些認(rèn)證授權(quán)配置開關(guān)未修改業(yè)務(wù)系統(tǒng)的缺省口令，導(dǎo)致攻擊者可使用

19、缺省的口令來進(jìn)行登錄將內(nèi)部系統(tǒng)部署在公網(wǎng)使用易受攻擊和過時(shí)的組件引入的攻擊面開發(fā)過程中引入開源或第三方插件、模塊、框架等，引用的第三方的軟件或模塊存在安全問題時(shí)，勢(shì)必會(huì)導(dǎo)致代碼中的漏洞、惡意代碼、“后門”等安全隱患被引入至 API 接口中使用的開源或第三方組件的版本過低，存在漏洞可以被攻擊API 攻擊更加隱蔽API 是需要開放給用戶來使用的，具備開放性和承載業(yè)務(wù)邏輯的特點(diǎn)，攻擊者可以和正常用戶一樣來調(diào)用 API，導(dǎo)致攻擊者的流量隱藏在正常用戶的流量里面，其攻擊行為會(huì)更加隱蔽，更難發(fā)現(xiàn)。一些常見的攻擊行為：高頻訪問行為：API 接口在設(shè)計(jì)之初未對(duì) API 接口訪問頻率做限制，使攻擊者在短時(shí)間內(nèi)可

20、以訪問大量 API 接口，很短的時(shí)間就可以完成如營(yíng)銷作弊、惡意注冊(cè)等攻擊，甚至可能帶來 CC 攻擊。大量數(shù)據(jù)下載行為：API 接口未對(duì)用戶某個(gè)時(shí)段內(nèi)的下載次數(shù)、下載內(nèi)容大小等做限制，導(dǎo)致攻擊者可以通過多次下載達(dá)到獲取大量數(shù)據(jù)的目的，容易造成大量敏感數(shù)據(jù)泄漏。網(wǎng)絡(luò)爬蟲行為：API 接口的開放性，如果沒有設(shè)置反爬蟲安全策略，則攻擊者可以使用代理 IP 或修改 User-Agent 請(qǐng)求頭隱匿身份，通過信息收集獲取企業(yè)內(nèi)部系統(tǒng)賬號(hào)，利用網(wǎng)絡(luò)爬蟲爬取賬號(hào)權(quán)限以及開放在公網(wǎng)上所有的 API 接口數(shù)據(jù)，導(dǎo)致大量數(shù)據(jù)泄漏。動(dòng)態(tài)代理 IP 低頻爬蟲行為：如果 API 有頻率限制和反爬策略，攻擊者會(huì)還會(huì)利用大量

21、的動(dòng)態(tài)代理 IP，低頻慢速的方式來繞過現(xiàn)有的防御措施，遍歷爬取數(shù)據(jù)、進(jìn)行惡意注冊(cè)或者營(yíng)銷作弊。接口濫用：如果 API 沒有對(duì)使用者的身份進(jìn)行校驗(yàn)，缺少白名單檢查、缺失驗(yàn)證碼進(jìn)行人機(jī)校驗(yàn)的邏輯，攻擊者會(huì)利用企業(yè)的 API 可以任意跳轉(zhuǎn) URL、任意短信發(fā)送等功能來完成攻擊，消耗企業(yè)的短信費(fèi)用，給企業(yè)帶來負(fù)面的社會(huì)影響。監(jiān)管合規(guī)性挑戰(zhàn)近幾年，隨著國(guó)家層面網(wǎng)絡(luò)空間治理的不斷深入，滿足合規(guī)性要求成為每一個(gè)企業(yè)正常業(yè)務(wù)開展的必要條件。自 2016 年以來，我國(guó)陸續(xù)出臺(tái)了一系列的法律法規(guī)來監(jiān)管數(shù)據(jù)的安全問題，從 2017 年 6 月網(wǎng)絡(luò)安全法的落地實(shí)施，再到被稱為“數(shù)據(jù)安全元年”的 2021 年。在 20

22、21 年，數(shù)據(jù)安全法個(gè)人信息保護(hù)法等法律法規(guī)陸續(xù)正式實(shí)施，國(guó)家網(wǎng)信辦發(fā)布數(shù)據(jù)出境安全評(píng)估辦法(征求意見稿)并公開征求意見。從這一系列法律法規(guī)中可以看出，我國(guó)對(duì)企業(yè)的數(shù)字安全監(jiān)管確實(shí)在走向更加嚴(yán)格和規(guī)范化，聚焦的內(nèi)容更加細(xì)化，處罰的力度也逐漸加強(qiáng)。對(duì)企業(yè)而言，圍繞數(shù)據(jù)的全生命周期從數(shù)據(jù)采集、存儲(chǔ)、訪問、使用、銷毀構(gòu)建數(shù)據(jù)安全的體系成為重點(diǎn)的安全建設(shè)工作。目前，大多數(shù)企業(yè)在數(shù)據(jù)采集、存儲(chǔ)、數(shù)據(jù)庫訪問方面做了比較全面的安全建設(shè)，在數(shù)據(jù)的流動(dòng)訪問方面的安全建設(shè)的意識(shí)也正逐步萌芽和發(fā)展；而 API 作為連接數(shù)據(jù)與應(yīng)用的主要通道，成為了數(shù)據(jù)傳輸中最薄弱的環(huán)節(jié)之一，傳統(tǒng)的 WAF、IPS 類安全設(shè)備關(guān)注點(diǎn)不

23、在數(shù)據(jù)安全， API 這個(gè)點(diǎn)目前的安全防護(hù)比較薄弱，所以 API 很容易成為攻擊者眼中竊取數(shù)據(jù)的頭號(hào)目標(biāo)。金融行業(yè)標(biāo)準(zhǔn) JR/T 0185-2020商業(yè)銀行應(yīng)用程序接口安全管理規(guī)范中，更是從 API類型與安全設(shè)計(jì)、開發(fā)、部署、集成、運(yùn)維等生命周期角度，對(duì) API 的管理提出多方面的合規(guī)性要求。這些標(biāo)準(zhǔn)或規(guī)范為企業(yè)的 API 安全實(shí)踐提供方向性指引，同時(shí)也為 API 的合規(guī)提供可落地標(biāo)準(zhǔn)。企業(yè)完成了此類合規(guī)的挑戰(zhàn)，才能更好地開展業(yè)務(wù)。下圖所示為這幾年來的數(shù)據(jù)相關(guān)法規(guī)的處罰細(xì)化說明：小結(jié)從攻擊視角來看，當(dāng)越來越多的企業(yè)通過 API 對(duì)外開放業(yè)務(wù)能力，意圖共建生態(tài)時(shí)，賬號(hào)、營(yíng)銷、數(shù)據(jù)方面的安全漏洞可

24、以被攻擊者直接快速獲利，而且當(dāng)前企業(yè)在這塊的安全防護(hù)意識(shí)才剛剛開始萌芽，這種新型的攻擊面充滿誘惑。攻擊者的動(dòng)機(jī)越強(qiáng)、攻擊手段越多、造成的危害越強(qiáng)，給企業(yè)的防御帶來的挑戰(zhàn)就會(huì)越大。API 全生命周期安全防護(hù)由于云計(jì)算的快速發(fā)展，越來越多的企業(yè)將應(yīng)用和數(shù)據(jù)遷移至云端，并暴露核心業(yè)務(wù)能力和流程相關(guān)的 API 為外部合作伙伴提供服務(wù)。脫離了傳統(tǒng)的內(nèi)網(wǎng)或網(wǎng)絡(luò)區(qū)域劃分，云上應(yīng)用的開發(fā)和集成、云端管理 API，被潛在的商業(yè)合作伙伴及攻擊者使用，無形中使得 API 安全風(fēng)險(xiǎn)增大。對(duì)大多數(shù)企業(yè)而言，很難完全掌握系統(tǒng)全部 API；開發(fā)人員往往也只是熟悉自己開發(fā)的相關(guān)模塊，且很多技術(shù)開發(fā)人員認(rèn)為采納新的、酷的技術(shù)更

25、重要，在技術(shù)路線上選擇新的特性，忽視 API 是否被攻擊。在這種缺少 API 安全性管理平臺(tái)又未建立全面系統(tǒng)的 API 安全治理體系的情況下，API 安全風(fēng)險(xiǎn)更不可控。API 安全設(shè)計(jì)的指導(dǎo)原則安全架構(gòu)設(shè)計(jì)有很多的安全設(shè)計(jì)原則，比如公開設(shè)計(jì)原則、權(quán)限最小化、開放最小化、默認(rèn)不信任等。安全設(shè)計(jì)原則需要不斷的學(xué)習(xí)和培訓(xùn)，讓安全設(shè)計(jì)人員和研發(fā)都能融會(huì)貫通。A PI 作為業(yè)務(wù)系統(tǒng)新的邊界，從設(shè)計(jì)的角度來保障好 API 這個(gè)新的邊界，有兩個(gè)基本的原則可以參考，分別是 5A 原則和縱深防御原則。5A 原則5A 原則是指 Authentication（身份認(rèn)證）、Authorization（授權(quán)）、Acce

26、ss Control（訪問控制）、Auditable（可審計(jì)性）、AssetProtection（資產(chǎn)保護(hù)）5 個(gè)部分的首字母縮寫，其含義是當(dāng)安全設(shè)計(jì)人員在做安全設(shè)計(jì)時(shí)，需要從這 5 個(gè)方面考量安全設(shè)計(jì)的合理性。如果某一個(gè)方面缺失，則在安全設(shè)計(jì)上是不全面的。身份認(rèn)證，解決“你是誰”的問題，目的是為了知道誰在與 API 服務(wù)進(jìn)行通信，是否是 A PI 服務(wù)允許的客戶端請(qǐng)求。一些需要權(quán)限才能訪問的 API 服務(wù)，需要知道誰在請(qǐng)求，是否允許請(qǐng)求，以保障 API 接口調(diào)用的安全性。認(rèn)證方式主要有用戶名/密碼認(rèn)證、動(dòng)態(tài)口令、數(shù)字證書認(rèn)證、生物特征認(rèn)證等。對(duì)于安全性的要求比較高的業(yè)務(wù)，可使用雙因子認(rèn)證（2

27、 FA）或多因子認(rèn)證（MFA）。常見的組合有用戶名/密碼+短信挑戰(zhàn)碼、用戶名/密碼+動(dòng)態(tài)令牌、用戶名/密碼+人臉識(shí)別、人臉識(shí)別+短信挑戰(zhàn)碼等。認(rèn)證通常融入單點(diǎn)登錄 SSO 系統(tǒng)中，使用統(tǒng)一的入口來完成身份認(rèn)證，減少攻擊面。授權(quán)，解決“你可以訪問什么數(shù)據(jù)和資源”的問題，通常發(fā)生在身份認(rèn)證之后，即對(duì)服務(wù)來說，誰在請(qǐng)求我，這個(gè)請(qǐng)求是有權(quán)限的么？某些 API 只有特定的角色才可以訪問，比如只有內(nèi)網(wǎng)的 IP 才可以調(diào)用某些服務(wù)、只有管理員用戶才可以調(diào)用刪除用戶的 API。訪問控制，解決“你所訪問具體的數(shù)據(jù)和功能是否被允許”的問題，通常發(fā)生在授權(quán)之后，很多情況下，對(duì)于某個(gè)角色的權(quán)限設(shè)置正確，但訪問控制做的

28、不一定正確，這也是存在很多越權(quán)操作的原因。訪問控制是對(duì)授權(quán)后的客戶端訪問時(shí)的正確性驗(yàn)證。某個(gè)角色，對(duì)于不具備訪問權(quán)限的 API 卻可以直接調(diào)用，問題就出在訪問控制上。授權(quán)和訪問控制常常是一起來進(jìn)行的，有兩種方式可以參考：一是基于使用者身份代理的授權(quán)與訪問控制，典型的以 OAuth 2.0 協(xié)議為代表，對(duì)于 API 的授權(quán)和可訪問資源的控制依賴于使用者的身份，使用者可能是某個(gè)自然人用戶，也可能是某個(gè)客戶端應(yīng)用程序，當(dāng)?shù)玫绞褂谜叩氖跈?quán)許可后，即可訪問該使用者授權(quán)的資源；另一類是基于使用者角色的授權(quán)與訪問控制，典型的以 RBAC 模型為代表，對(duì)于 API 的授權(quán)和資源訪問依賴于使用者在系統(tǒng)中被授予的

29、角色和分配的權(quán)限，不同的角色擁有不同的權(quán)限，比如功能權(quán)限、數(shù)據(jù)權(quán)限，訪問資源時(shí)依據(jù)此角色分配的權(quán)限的不同可以訪問不同的資源?？蓪徲?jì)性，解決“你所做的操作能夠被溯源”的問題，目的是為了記錄 API 調(diào)用時(shí)的關(guān)鍵信息，以便事后能夠通過審計(jì)手段及時(shí)發(fā)現(xiàn)問題，并在發(fā)生問題時(shí)通過審計(jì)日志進(jìn)行溯源，找出問題的發(fā)生點(diǎn)。一般記錄 API 日志需要有：什么人（賬號(hào)、UA 信息）、在什么時(shí)間、利用什么 IP（在什么地方）、調(diào)用了什么 API（做了什么）、操作的結(jié)果是什么、操作 A PI 時(shí)的 Referer 是什么等。資產(chǎn)保護(hù)，解決“阻止 API 被濫用”的問題，主要是指對(duì) API 接口自身的保護(hù)，比如限速、限流

30、，防止惡意調(diào)用，以及對(duì) API 接口傳輸?shù)拿舾袛?shù)據(jù)如身份證、手機(jī)號(hào)碼、銀行卡號(hào)等的保護(hù)?？v深防御原則縱深防御這個(gè)詞來源于軍事術(shù)語，是指在前方到后方之間，構(gòu)建多道防線，達(dá)到整體防御 的目的。在網(wǎng)絡(luò)安全領(lǐng)域，縱深防御通常是指不能只依賴單一安全機(jī)制，建立多種安全機(jī)制，互相支撐以達(dá)到相對(duì)安全的目的?？梢酝ㄟ^一個(gè)生活中的例子來理解縱深防御原則的基本含義，比如坐飛機(jī)的這個(gè)過程中，機(jī)場(chǎng)采用了如下這些防線：第一道防線是入口的防爆檢查，可快速 的檢查乘客是否攜帶了防爆物；第二道防線是安全檢查，檢查是否攜帶了一些違禁品；第三道 防線是上機(jī)前身份校驗(yàn)，確保人票一致性。這三層的防御就構(gòu)成了縱深防御，確保是購(gòu)買了機(jī) 票

31、的人在安全的情況下乘機(jī)。在 API 安全設(shè)計(jì)中，可以在不同層面使用不同的安全技術(shù)，來達(dá)到縱深防御的目的。典型的場(chǎng)景如網(wǎng)銀的轉(zhuǎn)賬業(yè)務(wù)，進(jìn)入系統(tǒng)時(shí)需要進(jìn)行登錄進(jìn)行身份認(rèn)證，在后面的調(diào)用轉(zhuǎn)賬 API時(shí)，仍需要再次輸入密碼，甚至對(duì)于大額轉(zhuǎn)賬還需要進(jìn)行人臉認(rèn)證。網(wǎng)銀登錄時(shí)的身份認(rèn)證和轉(zhuǎn)賬時(shí)的身份認(rèn)證，相互之間就構(gòu)成了縱深防御原則。5A 原則重點(diǎn)強(qiáng)調(diào)每一層安全架構(gòu)設(shè)計(jì)的合理性，強(qiáng)調(diào)的是寬度；縱深防御是對(duì)同一問題從不同的層次、不同的角度做安全防護(hù)，強(qiáng)調(diào)的是深度。這兩個(gè)原則相結(jié)合，共同將安全設(shè)計(jì)構(gòu)成一個(gè)有機(jī)的防護(hù)整體。以下是將兩個(gè)原則結(jié)合起來的 API 安全整體示意圖：API 生命周期的安全防護(hù)模型從 API

32、 面臨的外部威脅來看，主要有如下方面：命令執(zhí)行/SQL 注入/服務(wù)器接管等高危漏洞的風(fēng)險(xiǎn)、權(quán)限管控不完善的未授權(quán)和越權(quán)訪問的風(fēng)險(xiǎn)、設(shè)計(jì)存在缺陷帶來的數(shù)據(jù)批量泄漏的風(fēng)險(xiǎn)等。接入 WAF 可以解決部分命令執(zhí)行/SQL 注入類問題，但目前市場(chǎng)上的 WAF 產(chǎn)品因 API技術(shù)的特殊性對(duì) API 安全的防護(hù)能力仍顯不足，其主要表現(xiàn)在以下幾個(gè)方面：一是認(rèn)證和授權(quán)流程的繞過，API 的認(rèn)證和授權(quán)流程很多互聯(lián)網(wǎng)應(yīng)用是基于 OAuth2.0 和 OpenIDConnect 去實(shí)現(xiàn)的，傳統(tǒng)的安全防護(hù)產(chǎn)品難以檢測(cè)業(yè)務(wù)流程繞過的威脅；二是數(shù)據(jù)格式難以識(shí)別，API 在交互過程使用的消息格式大多 JSON 格式、XML

33、格式、Protobuf 格式、JWT 格式等，在威脅檢測(cè)時(shí)需要深入這些數(shù)據(jù)格式的數(shù)據(jù)結(jié)構(gòu)內(nèi)容去分析，傳統(tǒng)的安全防護(hù)產(chǎn)品在此方面檢測(cè)能力比較弱；三是流量控制能力難以滿足業(yè)務(wù)需求，面對(duì) API 層面的 CC 攻擊、慢 BOT 攻擊時(shí)，傳統(tǒng)上使用的檢測(cè)和防護(hù)策略，如訪問頻率限制、IP 黑名單設(shè)置、二次驗(yàn)證機(jī)制等難以對(duì)新型攻擊起到很好的防御效果。針對(duì) API 存在威脅防護(hù)，使用 WAF 類產(chǎn)品只能覆蓋其中的一小部分威脅，對(duì)業(yè)務(wù)而言，從單點(diǎn)考慮 API 功能安全設(shè)計(jì)到通過對(duì) API 生命周期來考慮 API 的安全，圍繞設(shè)計(jì)、開發(fā)、測(cè)試、上線運(yùn)行、迭代到下線的每一個(gè)環(huán)節(jié)加強(qiáng)安全建設(shè)就更加有必要。全生命周期

34、來考慮 API 的安全性，通過安全左移方法和工具，綜合性地融合管理手段和技術(shù)手段進(jìn)行 API 安全治理，提高業(yè)務(wù) API 的整體的安全性。設(shè)計(jì)階段：引入威脅建模在設(shè)計(jì)之初以及開發(fā)過程中，根據(jù)業(yè)務(wù)特點(diǎn)對(duì)風(fēng)險(xiǎn)進(jìn)行評(píng)估，做到可靠安全設(shè)計(jì)。安全工程師參與到對(duì)需求和設(shè)計(jì)方案的實(shí)現(xiàn)中來。資源允許的情況下，安全工程師在設(shè)計(jì)階段對(duì)每個(gè) API 進(jìn)行威脅建模，線上的 API 風(fēng)險(xiǎn)將會(huì)大大減少。資源有限的情況下，建設(shè)自動(dòng)化威脅建模的能力，采用“重點(diǎn)業(yè)務(wù)人工評(píng)審”和“非重點(diǎn)業(yè)務(wù)自動(dòng)化威脅建?！毕嘟Y(jié)合的方式，對(duì)核心高風(fēng)險(xiǎn) API 如賬號(hào)登錄、文件上傳、營(yíng)銷活動(dòng)等進(jìn)行覆蓋。在設(shè)計(jì)階段的威脅建模，一般使用 ASTRIDE

35、（隱私、欺騙、篡改、信息泄露、否認(rèn)性、拒絕服務(wù)和特權(quán)提升）和攻擊樹模型作為常用的威脅建模技術(shù)指導(dǎo)原則。結(jié)合業(yè)界安全白皮書、歷史上安全事件總結(jié)，根據(jù)業(yè)務(wù) API 的需求和功能設(shè)計(jì)，基于上述 5A 的原則整理出來潛在攻擊者可能進(jìn)行攻擊的目標(biāo)和方式。對(duì)于 API 而言，攻擊者通常可能會(huì)有：惡意內(nèi)部員工、外部攻擊者，競(jìng)爭(zhēng)對(duì)手、好奇者等，攻擊路徑可能是下班后通過內(nèi)部系統(tǒng) API 盜取數(shù)據(jù)、利用 API 的邏輯漏洞批量爬取數(shù)據(jù)、發(fā)起 BOT 攻擊、借助手機(jī)號(hào)接碼平臺(tái)發(fā)起惡意注冊(cè)、利用代理秒撥平臺(tái)發(fā)起低頻慢速的攻擊等。下面列表的一些安全檢查表和最佳實(shí)踐可以作為威脅建模階段的一些參考：OWASP REST 安

36、全檢查表 HYPERLINK /cheatsheets/REST_Security_Cheat_Sheet.html /cheatsheets/REST_Security_Cheat_Sheet.htmlapisec 提供了 API 安全工具和資源 HYPERLINK /arainho/awesome-api-security /arainho/awesome-api-securityAPI 安全檢查表 HYPERLINK /shieldfy/API-Security-Checklist /shieldfy/API-Security-ChecklistJWT 安全檢查表 HYPERLINK /

37、files/cheatsheets/jwt.pdf /files/cheatsheets/jwt.pdf開發(fā)階段：安全開發(fā)意識(shí)和規(guī)范培訓(xùn)，引入安全工具比較理想的情況，同研發(fā)在設(shè)計(jì)階段就威脅建模進(jìn)行了討論，大家對(duì)于 API 可能遇到的安全問題點(diǎn)都有了全面且清晰的理解；然而，在研發(fā)進(jìn)行編碼實(shí)現(xiàn)的環(huán)節(jié)，往往可能在實(shí)現(xiàn)上出現(xiàn)不完整，或者引入新的bug。同時(shí)考慮到研發(fā)人員也在不斷的變化，需要安全工程師提供 A PI 安全開發(fā)規(guī)范、安全開發(fā)插件、安全輔助包、敏感數(shù)據(jù)加解密工具等輔助性安全開發(fā)工具。一方面通過培訓(xùn)的方式加強(qiáng)全員對(duì)安全開發(fā)的意識(shí)和能力，一方面需要借助工具的方式來實(shí)現(xiàn)自動(dòng)化的檢查，提早發(fā)現(xiàn) bu

38、g 和漏洞。在 API 安全開發(fā)培訓(xùn)方面，可以從四個(gè)方面來考慮：API 安全管理框架和關(guān)鍵指標(biāo)，企業(yè)在 API 安全這塊整體的框架，定型和定量的指標(biāo)，如上線后的漏洞數(shù)量等。常見 API 安全問題，如 OWASP API Top 10 ，以及安全運(yùn)營(yíng)通過 SRC 以及業(yè)務(wù)中提煉出來的一些具有代表性的問題。通過問題案例的方式，更加能讓大家理解和學(xué)習(xí)。常見 API 安全技術(shù)與安全設(shè)計(jì)，整理收集業(yè)界和企業(yè)自身的一些優(yōu)秀安全實(shí)踐案例，能開拓研發(fā)的思維，在遇到類似問題時(shí)能想到更好的解決方法。API 安全編碼案例，結(jié)合業(yè)界的優(yōu)秀案例，基于企業(yè)自身的特點(diǎn)制定出來符合企業(yè)特色的安全編碼的規(guī)范和案例。下面列表的一

39、些安全編碼和開發(fā)規(guī)范，可以借鑒和參考：OWASP 安全編碼實(shí)踐 HYPERLINK /www-project-secure-coding-practices-quick-reference-guide/migrated_content /www-project-secure-coding-practices-quick-reference-guide/migrated_content騰訊的代碼安全指南 HYPERLINK /Tencent/secguide /Tencent/secguide永安在線 API 安全開發(fā)規(guī)范 HYPERLINK /reportDetail/14ac36b8-f5c

40、6-11ec-af75-00163e048a4c /reportDetail/14ac36b8-f5c6-11ec-af75-00163e048a4c在自動(dòng)化工具方面，可以考慮如下幾個(gè)方面的工具：引入代碼白盒代碼掃描工具，嵌入到 CI/CD 或者研發(fā)流程中，發(fā)布到測(cè)試環(huán)境時(shí)就進(jìn)行掃描。引入 API 管理工具，對(duì) API 的文檔進(jìn)行集中統(tǒng)一的管理，能夠監(jiān)控到 API 的變更迭代的過程數(shù)據(jù)。引入 API 安全驗(yàn)證相關(guān)的工具，驗(yàn)證 API 安全實(shí)現(xiàn)的正確性，以保障驗(yàn)證工作盡可能做到全面，相關(guān)工具如 FuzzDB、個(gè)人數(shù)據(jù)隱私監(jiān)測(cè)類工具。測(cè)試階段：漏洞加入測(cè)試流程，使用 AST 類工具提高覆蓋率在測(cè)試

41、環(huán)節(jié)加入 API 安全相關(guān)的內(nèi)容，針對(duì)自動(dòng)化測(cè)試流程和人工測(cè)試，在 API 業(yè)務(wù)邏輯實(shí)現(xiàn)、穩(wěn)定性、性能測(cè)試的基礎(chǔ)上增加 API 安全的測(cè)試。落實(shí) API 安全測(cè)試的目的是為了自動(dòng)化掃描每一個(gè) API，自動(dòng)化 API 安全測(cè)試從請(qǐng)求輸入與應(yīng)答響應(yīng)兩部分去分析 API 是否存在漏洞。API 安全測(cè)試的常規(guī)內(nèi)容主要包含 API 身份驗(yàn)證、授權(quán)、輸入驗(yàn)證、異常處理、數(shù)據(jù)保護(hù)、安全傳輸以及 HTTP Header 安全性等。API 數(shù)量多，且在不斷的迭代更新，需要借助自動(dòng)化工具來輔助進(jìn)行安全測(cè)試。常用的工具有以下三類：SAST、DAST、IAST 工具，在測(cè)試階段提前發(fā)現(xiàn)研發(fā)的安全漏洞。根據(jù)業(yè)務(wù)的特點(diǎn)，

42、和供應(yīng)商一起優(yōu)化IAST 工具，保障覆蓋率的情況下，提高準(zhǔn)確率，能提前發(fā)現(xiàn)許多輸入處理不當(dāng)導(dǎo)致的漏洞。靜態(tài)安全檢測(cè)（Static Application SecurityTesting，SAST），其特點(diǎn)是分析應(yīng)用程序的源代碼或二進(jìn)制文件，通過語法、結(jié)構(gòu)、過程、接口等來發(fā)現(xiàn)應(yīng)用程序的代碼是否存在漏洞。動(dòng)態(tài)安全檢測(cè)（Dynamic Application SecurityTesting，DAST），其特點(diǎn)是在應(yīng)用程序的動(dòng)態(tài)運(yùn)行狀態(tài)下，模擬黑客攻擊行為，分析應(yīng)用程序的響應(yīng)，而確定應(yīng)用程序是否存在漏洞。交互式安全檢測(cè)（Interactive ApplicationSecurity Testing，I

43、AST），相當(dāng)于是 DAST和 SAST 結(jié)合的一種安全檢測(cè)技術(shù)，通常會(huì)在應(yīng)用程序中添加探針或 Agent 代理，收集應(yīng)用程、Web 容器、JVM 中的執(zhí)行日志和函數(shù)調(diào)用信息，結(jié)合請(qǐng)求輸入與響應(yīng)消息，分析應(yīng)用程序中是否存在漏洞。這三類工具中，IAST 使用過程稍顯煩瑣，但技術(shù)優(yōu)勢(shì)比較明顯，漏洞檢出率高于其他兩類，同時(shí)漏洞誤報(bào)率也低于其他兩類，并可以快速定位代碼片段和 API 接口，可以作為首選的自動(dòng)化 API 安全測(cè)試工具，如果沒有此類工具，則建議選擇 DAST 類。上線運(yùn)行階段：借助網(wǎng)關(guān)、WAF 和流量審計(jì)工具提早感知攻擊面經(jīng)過前期的開發(fā)和測(cè)試，API 終于到了上線的環(huán)節(jié)，可根據(jù)業(yè)務(wù)評(píng)估是否

44、需要對(duì)上線環(huán)節(jié)進(jìn)行安全評(píng)審，API 上線后，就進(jìn)入了運(yùn)行階段。對(duì)外暴露的 API 承載了業(yè)務(wù)邏輯和數(shù)據(jù)流動(dòng)，成為攻擊者攻擊的主要通道。因此，需要借助各種安全工具來保障運(yùn)營(yíng)階段的 API 安全。上線階段常用的安全工具利用 WAF，阻斷 SQL 注入、XSS 等攻擊請(qǐng)求、防御 DDoS 防御、常規(guī)的 BOT 攻擊。外部攻擊流量過了 WAF 的流量檢測(cè)，對(duì)惡意漏洞掃描的行為完成了過濾，對(duì)后端系統(tǒng)的危害性就會(huì)降低。同時(shí)，運(yùn)維人員通過 WAF 的數(shù)據(jù)與日志，可以定向分析異常行為，在 WAF 上調(diào)整安全防護(hù)策略，達(dá)到快速阻止攻擊的目的。利用 API 網(wǎng)關(guān)，實(shí)現(xiàn)認(rèn)證、授權(quán)、訪問控制、數(shù)據(jù)脫敏，同時(shí)也能幫助安

45、全團(tuán)隊(duì)來管理 A PI。雖然 API 網(wǎng)關(guān)產(chǎn)品中所具有的身份認(rèn)證、訪問控制、數(shù)據(jù)校驗(yàn)、限流熔斷等功能，能有效地提高 API 的安全性。但是對(duì)內(nèi)部開發(fā)人員來說，需要打通持續(xù)集成（CI/CD）與 AP I 網(wǎng)關(guān)的接口，發(fā)布前準(zhǔn)備好 API 導(dǎo)入數(shù)據(jù)供 CI/CD 調(diào)用。這會(huì)增加開發(fā)人員的額外工作量，并影響發(fā)布進(jìn)度；同時(shí)，當(dāng)所有后端服務(wù)的流量都必須由 API 網(wǎng)關(guān)進(jìn)行通信時(shí)，對(duì)原有通信性能的影響和 API 自身的穩(wěn)定性 將是對(duì)推進(jìn)此項(xiàng)工作的負(fù)責(zé)人員的最大挑戰(zhàn)?？梢愿鶕?jù)業(yè)務(wù)的實(shí)際情況來評(píng)估是否需要使用 API 網(wǎng)關(guān)。利用 API 安全審計(jì)工具，對(duì) API 分類分級(jí)，標(biāo)示出來高風(fēng)險(xiǎn) API，如涉及敏感信

46、息出站的、涉及資金的、涉及核心基礎(chǔ)設(shè)施操作等；持續(xù)監(jiān)測(cè) API 數(shù)據(jù)暴露、越權(quán)、配置、設(shè)計(jì)不合理帶來的漏洞；發(fā)現(xiàn)僵尸API、影子 API，老版本、功能重復(fù)的 API；通過 UEBA 發(fā)現(xiàn)利用自身權(quán)限批量獲取敏感數(shù)據(jù)的行為等；借助情報(bào)和機(jī)器學(xué)習(xí)模型來發(fā)現(xiàn)針對(duì) API 的低頻慢速的攻擊?；?P2DR 模型的自適應(yīng)安全閉環(huán)工具只是手段，在安全模型的指導(dǎo)下能充分利用其功效。在上線運(yùn)營(yíng)階段需要基于動(dòng)態(tài)自適應(yīng)的P2DR 安全模型，對(duì) API 攻擊威脅實(shí)現(xiàn)“發(fā)現(xiàn)”、“檢測(cè)”、“防護(hù)”、“響應(yīng)”的閉環(huán)，可以更好滿足數(shù)據(jù)安全體系下的 API 安全防護(hù)需要。安全的前提是資產(chǎn)的可見性，資產(chǎn)可見后才能實(shí)現(xiàn)可控，可控

47、包括兩個(gè)方面，一個(gè)方面是資產(chǎn)漏洞風(fēng)險(xiǎn)的持續(xù)監(jiān)測(cè)，一個(gè)方面是攻擊威脅的感知和防護(hù)。一是持續(xù)構(gòu)建資產(chǎn)發(fā)現(xiàn)能力API 發(fā)現(xiàn)能力是 API 提供者和攻擊者之間的競(jìng)賽，要在攻擊者之前發(fā)現(xiàn) API，提前感知和了解到系統(tǒng)可能的攻擊面。因?yàn)?API 是不斷在研發(fā)迭代的，所以持續(xù)動(dòng)態(tài)梳理 API 的能力顯得至關(guān)重要?？梢酝ㄟ^ API 安全網(wǎng)關(guān)、負(fù)載平衡或交換機(jī)鏡像的網(wǎng)絡(luò)流量中提取出來 API、API上流動(dòng)的數(shù)據(jù)、訪問 API 時(shí)關(guān)聯(lián)的賬號(hào)和 IP 等資產(chǎn)。同時(shí)對(duì)發(fā)現(xiàn)的資產(chǎn)進(jìn)行分級(jí)分類處理，分級(jí)分類可以讓安全運(yùn)營(yíng)的人分優(yōu)先級(jí)的來進(jìn)行治理。API 可以根據(jù)業(yè)務(wù)場(chǎng)景，如登錄、文件上傳、文件下載、第三方開源組件等進(jìn)行分

48、級(jí)分類；也可以根據(jù)返回的數(shù)據(jù)敏感度的情況來進(jìn)行分級(jí)分類。流動(dòng)的數(shù)據(jù)，可以根據(jù)國(guó)家的監(jiān)管法規(guī)規(guī)范來進(jìn)行分級(jí)分類，同時(shí)建立數(shù)據(jù)到 API 的映射關(guān)系，這樣可以從容應(yīng)對(duì)法規(guī)和監(jiān)管的治理需要。賬號(hào)資產(chǎn)，可以根據(jù)權(quán)限級(jí)別、訪問系統(tǒng)、活躍性等來進(jìn)行分級(jí)分類。IP 資產(chǎn)，可以根據(jù)地域、類型、安全性等來進(jìn)行分級(jí)分類。面向終端用戶面向合作企業(yè)面向內(nèi)部員工面向開源組件和中間件在互聯(lián)網(wǎng)上給到用戶使用的 APP、Web、小程序等用到的 API在互聯(lián)網(wǎng)上開放給到合作企業(yè)客戶使用的業(yè)務(wù) API開放給到內(nèi)部員工或者合作伙伴使用的應(yīng)用系統(tǒng)上關(guān)聯(lián)到的 API使用到的 clickhouse、spring boot 、k8s 、h

49、adoop 、jenkins等涉及到的 APIAPI 的資產(chǎn)發(fā)現(xiàn)要全面，從 API 的應(yīng)用場(chǎng)景的角度，圍繞終端用戶、合作企業(yè)、內(nèi)部員工、以及開源組件和中間件四個(gè)場(chǎng)景能比較全面的覆蓋 API 資產(chǎn)，借助負(fù)載均衡或者核心交換機(jī)的的流量來梳理 API 能夠?qū)崿F(xiàn)對(duì)上述四個(gè)場(chǎng)景比較全面的覆蓋。二是持續(xù)的風(fēng)險(xiǎn)監(jiān)測(cè)能力API 安全的風(fēng)險(xiǎn)監(jiān)測(cè)包括了API 自身的漏洞風(fēng)險(xiǎn)，也包括了攻擊者對(duì) API 進(jìn)行攻擊的風(fēng)險(xiǎn)、賬號(hào)的違規(guī)操作行為風(fēng)險(xiǎn)、IP 的異常行為風(fēng)險(xiǎn)等。需要持續(xù)針對(duì)資產(chǎn)的漏洞風(fēng)險(xiǎn)、攻擊行為和異常行為風(fēng)險(xiǎn)進(jìn)行檢測(cè)，在保障召回率的前提下，提高準(zhǔn)確率。漏洞風(fēng)險(xiǎn)的檢測(cè)，有如下幾個(gè)方面：自身業(yè)務(wù)漏洞檢測(cè)，需要持續(xù)監(jiān)測(cè) API 存在的授權(quán)、認(rèn)證、數(shù)據(jù)過度暴露、配置、邏輯設(shè)計(jì)等方面的缺陷；以及關(guān)聯(lián)賬號(hào)的弱密碼這類風(fēng)險(xiǎn)的監(jiān)測(cè)。第三方組件