人工智能的安全API如何使用

企業(yè)的數(shù)字轉(zhuǎn)型通常是基于API（應(yīng)用程序編程接口）之上的，API可驅(qū)動(dòng)新的運(yùn)營模型，提供對(duì)業(yè)務(wù)邏輯應(yīng)用程序和數(shù)據(jù)的直接訪問。

雖然這種訪問對(duì)于企業(yè)的員工、合作伙伴、客戶來說非常寶貴，但它也使API成為黑客和僵尸網(wǎng)絡(luò)具有吸引力的目標(biāo)。隨著越來越多的攻擊和API漏洞的增加，擴(kuò)展安全性變得越來越重要。

現(xiàn)有的解決方案（例如訪問控制、速率限制等）提供基本的保護(hù)，但不足以完全阻止黑客的網(wǎng)絡(luò)攻擊。如今的安全團(tuán)隊(duì)需要識(shí)別并響應(yīng)動(dòng)態(tài)變化的攻擊，這些攻擊旨在利用單個(gè)API的獨(dú)特漏洞。企業(yè)可以采用人工智能來檢測(cè)API和未暴露數(shù)據(jù)的異常行為，自動(dòng)阻止對(duì)整個(gè)API基礎(chǔ)設(shè)施的攻擊，設(shè)計(jì)自學(xué)習(xí)解決方案是安全的未來。這種方法為IT基礎(chǔ)設(shè)施提供了深入的可視性，并使安全團(tuán)隊(duì)能夠在識(shí)別惡意行為時(shí)立即采取行動(dòng)。

API數(shù)據(jù)泄露

2019年，澳大利亞最大的房地產(chǎn)估價(jià)服務(wù)商LandMark White公司發(fā)生API數(shù)據(jù)泄露事件，導(dǎo)致房產(chǎn)估價(jià)內(nèi)容和客戶信息泄露。在這種情況下，最初用于企業(yè)內(nèi)部使用的API最終可以從外部訪問。

這些漏洞導(dǎo)致了不同程度的數(shù)據(jù)泄露行為，其中包括賬戶接管、私人信息和照片被盜，以及信用卡號(hào)碼被他人提取。在此次數(shù)據(jù)泄露事件之后，LandMark White公司的聲譽(yù)受到嚴(yán)重影響，而其很多客戶和銀行合作伙伴退出，并爭相與其他廠商合作。

數(shù)據(jù)泄露事件通常需要數(shù)周或數(shù)月才能檢測(cè)到，其他類似的違規(guī)行為幾乎需要一年時(shí)間才能完全解決。還有許多公司現(xiàn)在面臨這種情況。要了解如何防范這些威脅，人們必須首先了解API所帶來的潛在漏洞。

API漏洞

許多企業(yè)目前依靠不充分的安全措施來保護(hù)其API。雖然API管理工具提供了一組重要的安全功能，其中包括身份驗(yàn)證和速率限制，但這些做法通常無法阻止專門為違反API及其提供訪問權(quán)限的數(shù)據(jù)和系統(tǒng)而構(gòu)建的攻擊。

不完整和遺漏的驗(yàn)證

缺少權(quán)利檢查是最近一系列API違規(guī)中頻繁出現(xiàn)的漏洞模式。這些缺失的權(quán)利檢查會(huì)在生產(chǎn)API中暴露漏洞。在某些情況下，完全缺乏訪問控制已經(jīng)使API完全開放，使得具有基本技能的不良行為者可以進(jìn)行惡意攻擊。

在Facebook、USPS和Verizon/LocationSmart公司的數(shù)據(jù)泄露案例中，黑客使用有效賬戶對(duì)API行為進(jìn)行反向工程，以識(shí)別多個(gè)漏洞，其漏洞可以在沒有正確憑據(jù)檢查的情況下提供對(duì)來自其他賬戶的數(shù)據(jù)的訪問，同時(shí)看起來像普通用戶。這種技術(shù)有可能提供對(duì)大量賬戶的訪問，并用于破壞銀行和保險(xiǎn)公司的賬戶。

使用調(diào)用API的應(yīng)用程序時(shí)，不會(huì)暴露此類漏洞。通過跳過客戶端應(yīng)用程序（例如，Web應(yīng)用程序）并直接調(diào)用API來觀察數(shù)據(jù)和控制流，可以進(jìn)行惡意訪問?？蛻舳藨?yīng)用程序極大地限制了通過用戶界面限制使用API的方式。依賴應(yīng)用程序可能會(huì)產(chǎn)生安全盲點(diǎn)，尤其是在API層的應(yīng)用程序之外未執(zhí)行測(cè)試時(shí)。

除了訪問控制之外，API安全性還必須包括內(nèi)容驗(yàn)證。在2019年初發(fā)現(xiàn)（并修補(bǔ)）的Kubernetes的API服務(wù)器的情況下，這種缺乏安全性是顯而易見的。被授權(quán)向Kubernetes API服務(wù)器發(fā)出補(bǔ)丁請(qǐng)求的用戶也可能發(fā)送過量消耗資源的特定補(bǔ)丁，這種偶然（或故意）的行為導(dǎo)致對(duì)API服務(wù)器的拒絕服務(wù)（DoS）攻擊。

利用此類漏洞可以極大地破壞服務(wù)。如果傳入的JSON補(bǔ)丁包含10，000多個(gè)操作，則Kubernetes API服務(wù)器修復(fù)包括返回413類型的錯(cuò)誤。這種類型的內(nèi)容驗(yàn)證很容易在API網(wǎng)關(guān)中配置，但它經(jīng)常被遺漏，因?yàn)檫@樣做需要超越自動(dòng)生成的JSON模式，這些模式只定義簡單的規(guī)則類型，需要人工干預(yù)才能識(shí)別特定驗(yàn)證的需要，并確保正確的配置和測(cè)試。

擴(kuò)散和缺乏可見性

API的擴(kuò)散只會(huì)增加其漏洞。API的部署速度比以往任何時(shí)候都要快，而且由許多不同的團(tuán)隊(duì)負(fù)責(zé)。在某些情況下，持續(xù)不斷的創(chuàng)新、減少摩擦、創(chuàng)造新收入流的壓力會(huì)導(dǎo)致開放API可能產(chǎn)生意外的影響。

因此，許多利益相關(guān)者報(bào)告其組織部署的所有API缺乏可見性，這并不奇怪。事實(shí)上，許多API相關(guān)的漏洞在幾個(gè)月有時(shí)是幾年之后才被發(fā)現(xiàn)，這進(jìn)一步說明了對(duì)整體API流量缺乏可見性。

此外，一些API并不是公開的，可能只被視為總體項(xiàng)目的實(shí)施細(xì)節(jié)。這使他們從安全從業(yè)者的角度隱藏起來，進(jìn)而導(dǎo)致缺乏具體的安全考慮。在其他情況下，來自組織不同部分的API可能會(huì)利用異構(gòu)平臺(tái)和不一致的安全策略。

無論如何，這些API可能與公共API一樣容易受到攻擊，因?yàn)樗鼈兺瑯尤菀妆缓诳屯ㄟ^反向工程進(jìn)行攻擊。為彌補(bǔ)這些差距，人們需要清楚地了解需要保護(hù)的內(nèi)容。而對(duì)API流量的深入洞察將為改善網(wǎng)絡(luò)彈性提供基礎(chǔ)。

超越令牌驗(yàn)證的思考

驗(yàn)證令牌并驗(yàn)證請(qǐng)求用戶的身份通常不足以支持API基礎(chǔ)設(shè)施。在API層應(yīng)用粒度訪問控制的能力不僅符合邏輯，而且隨著API成為訪問開發(fā)人員需要管理的數(shù)據(jù)的最常用渠道，它將成為常態(tài)。

此外，定義應(yīng)允許個(gè)人請(qǐng)求哪些數(shù)據(jù)的規(guī)則，不僅由API提供商定義，還由最終用戶定義。例如，在OAuth握手期間，將會(huì)要求最終用戶認(rèn)可。這些決策允許用戶在涉及他們擁有的數(shù)據(jù)時(shí)限制應(yīng)用程序代表他們行事的方式。因此，用戶認(rèn)可的管理與核心API安全性概念緊密相關(guān)。

基礎(chǔ)API安全準(zhǔn)備的核心是審查和治理流程的定義，它們將所有這些概念結(jié)合在一起。新的API或更新的API必須經(jīng)過審核，首先要確定問題的答案，其中包括：

?訪問API需要哪些權(quán)限？

?預(yù)期的請(qǐng)求者是誰？

?此服務(wù)將利用哪些數(shù)據(jù)庫和數(shù)據(jù)進(jìn)行讀寫？

?此API與之交互的其他服務(wù)是什么？

?輸入和輸出參數(shù)是什么樣的，應(yīng)該如何限制它們？

這些問題的答案將告知哪些安全策略應(yīng)該適用于正在發(fā)布的新API。

擴(kuò)展基礎(chǔ)API安全性

即使有正確的基礎(chǔ)，安全性也只能與其配置一樣強(qiáng)大。當(dāng)配置受到人為錯(cuò)誤的影響時(shí)，隨著API層復(fù)雜性的增加，API漏洞通過測(cè)試并進(jìn)入生產(chǎn)的風(fēng)險(xiǎn)也隨之增加。即使企業(yè)已采取一切措施來防止數(shù)據(jù)泄露，仍然可能面臨在API本身之外的不同向量暴露漏洞的風(fēng)險(xiǎn)。

例如，黑客經(jīng)常通過網(wǎng)絡(luò)釣魚攻擊竊取令牌，這些攻擊允許他們構(gòu)成合法的應(yīng)用程序。此外，代表用戶調(diào)用API的客戶端應(yīng)用程序也存在一些缺陷，并且在保密方面非常糟糕。這可能像API密鑰一樣簡單，這些密鑰是通過查看單頁應(yīng)用程序的JavaScript代碼或通過HTTPS代理查看API流量而反向設(shè)計(jì)的。

例如，北卡羅來納州立大學(xué)的一項(xiàng)研究表明，GitHub是一個(gè)用于調(diào)用API的應(yīng)用程序機(jī)密寶庫。該研究得出結(jié)論，如今已有10萬多個(gè)存儲(chǔ)庫泄漏了API令牌和加密密鑰。GitHub通過實(shí)施新的安全功能從提交到其平臺(tái)的代碼中掃描令牌來實(shí)現(xiàn)這一發(fā)現(xiàn)。

未檢測(cè)到的漏洞

攻擊者還使用遠(yuǎn)程訪問特洛伊木馬來竊取憑據(jù)，如Mimikatz。他們使用竊取的憑據(jù)來冒充用戶并獲取令牌。最后，另一個(gè)常見漏洞是授權(quán)服務(wù)器上的憑據(jù)填充，利用從先前漏洞中挖掘的憑證集合。

在這些場(chǎng)景中，攻擊者通過利用用戶、客戶端應(yīng)用程序或授權(quán)服務(wù)器上的漏洞（而不是API本身）獲取令牌。這帶來了許多問題，因?yàn)檫@些令牌似乎是合法的，黑客像一個(gè)有效的用戶。即使企業(yè)采用了適當(dāng)?shù)脑L問控制策略，除了涉及到API本身的漏洞之外，這些攻擊通常會(huì)在數(shù)月甚至數(shù)年的時(shí)間內(nèi)也不會(huì)被傳統(tǒng)的API安全工具檢測(cè)到。

安全團(tuán)隊(duì)可以投入大量精力，向用戶和API開發(fā)人員介紹客戶端應(yīng)用程序安全和身份基礎(chǔ)設(shè)施，但他們?nèi)匀豢赡苊媾R生產(chǎn)API漏洞和憑據(jù)泄露的風(fēng)險(xiǎn)。API提供商必須在其安全措施中考慮這一點(diǎn)，無論API是內(nèi)部還是外部。企業(yè)可以通過應(yīng)用人工智能（AI）來加速攻擊檢測(cè)和自動(dòng)阻止攻擊。

將人工智能應(yīng)用于安全

安全團(tuán)隊(duì)可以根據(jù)客戶、用戶和通常展示的API行為來訓(xùn)練機(jī)器學(xué)習(xí)引擎。通過使用人工智能，安全團(tuán)隊(duì)可以識(shí)別良好和惡意流量，并在沒有人工干預(yù)的情況下識(shí)別未遂的攻擊和持續(xù)的攻擊。

采用人工智能檢測(cè)非典型行為

每個(gè)API調(diào)用、訪問令牌或cookie的元數(shù)據(jù)以及某些操作的時(shí)間和順序都可以提供給AI模型。在運(yùn)行時(shí)，此機(jī)器學(xué)習(xí)引擎利用行為模型來識(shí)別潛在威脅，例如特定令牌或cookie是否在合法應(yīng)用程序之外使用，數(shù)據(jù)是否被泄露或更改等。

利用基于人工智能的異常使用檢測(cè)顯著加快了威脅可見性，將攻擊發(fā)現(xiàn)的時(shí)間從幾個(gè)月減少到幾分鐘或幾秒鐘。一旦檢測(cè)到可疑的API活動(dòng)，用于獲取API訪問權(quán)限的訪問令牌或cookie將被列入黑名單或吊銷，立即停止所有API端點(diǎn)上使用該令牌的任何一方的訪問。如果這些攻擊背后隱藏著相同的用戶身份，那么必須將用戶身份本身列入黑名單并相應(yīng)地進(jìn)行標(biāo)記。這種類型的監(jiān)視、攻擊檢測(cè)和阻塞是在不需要操作人員采用自定義規(guī)則的情況下實(shí)現(xiàn)的。

使用API誘餌

API誘餌的使用也可以加速API黑客攻擊的檢測(cè)。這涉及添加偽造的API資源，這些資源會(huì)向請(qǐng)求者返回看似有效的響應(yīng)。誘餌利用黑客傾向于以合法應(yīng)用程序不具備的方式進(jìn)行搜索，有效地利用圍繞典型黑客行為的知識(shí)。

當(dāng)黑客陷入這些陷阱時(shí)，他們會(huì)立即被識(shí)別出來。同時(shí)，他們的相關(guān)IP地址和訪問令牌（如果他們當(dāng)時(shí)擁有它們）會(huì)自動(dòng)被視為泄露，并列入黑名單。誘餌偵聽器能夠識(shí)別出這些請(qǐng)求不可能從真正的應(yīng)用程序傳入，因?yàn)檫@些API資源并不是合法存在。這些安全措施不需要自定義規(guī)則或擴(kuò)展配置。

阻止和修復(fù)

當(dāng)然，檢測(cè)只是解決方案的一部分。安全系統(tǒng)如何反應(yīng)同樣重要。一旦客戶機(jī)標(biāo)識(shí)符（如用戶或令牌）被泄露，該標(biāo)識(shí)符必須立即被撤銷或列入黑名單。這些信息需要在所有API強(qiáng)制點(diǎn)、API網(wǎng)關(guān)和代理之間廣泛傳播。此外，必須記錄這些事件以供后續(xù)審計(jì)，并且必須通知安全信息和事件管理（SIEM）系統(tǒng)以啟動(dòng)任何標(biāo)準(zhǔn)響應(yīng)過程。

企業(yè)應(yīng)該記錄在檢測(cè)和阻止泄露的憑證之前調(diào)用的方法和資源的詳細(xì)信息。取證報(bào)告形式的信息允許API提供者、DevOps團(tuán)隊(duì)或安全團(tuán)隊(duì)采取必要的措施來修復(fù)或反向工程攻擊造成的損壞。還可利用取證來幫助遵守GDPR、PSD2和開放式銀行等法規(guī)。

保護(hù)API

Ping智能身份平臺(tái)提供了一套解決方案，可解決專為API流量設(shè)計(jì)的基礎(chǔ)API安全性和合規(guī)性實(shí)施。

PingAccess

PingAccess控制對(duì)企業(yè)內(nèi)部和面向公眾的API的訪問。它作為反向代理部署在受保護(hù)網(wǎng)絡(luò)的邊界，或作為與API端點(diǎn)一起運(yùn)行的代理部署。PingAccess支持精細(xì)的API訪問控制，將用戶限制為訪問令牌中包含的授權(quán)范圍所允許的API事務(wù)。

PingDataGovernance

PingDataGovernance通過啟用評(píng)估API請(qǐng)求和響應(yīng)主體的策略，對(duì)API和通過API流出的數(shù)據(jù)實(shí)施細(xì)粒度授權(quán)。在API請(qǐng)求中，細(xì)粒度授權(quán)策略可以限制用戶在授權(quán)的API調(diào)用中可以做什么（例如，如果他們授權(quán)超過特定限制的支付，修改大量數(shù)據(jù)條目等）。在API響應(yīng)中，PingDataGovernance根據(jù)未經(jīng)授權(quán)、非預(yù)期、敏感或受限制數(shù)據(jù)的策略和同意記錄檢查出站數(shù)據(jù)，這些數(shù)據(jù)應(yīng)在發(fā)布到客戶端之前動(dòng)態(tài)修改或從響應(yīng)中刪除。

針對(duì)API的PingIntelligence

PingIntelligence提供對(duì)API流量的深入可見性，自動(dòng)發(fā)現(xiàn)API，提供基于AI的自動(dòng)API攻擊檢測(cè)和阻止，并使用欺騙/蜜罐環(huán)境實(shí)時(shí)識(shí)別黑客攻擊。其人工智能引擎為PingAccess、API網(wǎng)關(guān)、API管理平臺(tái)和直接在App Server上實(shí)現(xiàn)的API（如Node.JS，WebLogic，Tomcat或WebSphere）帶來了網(wǎng)絡(luò)攻擊保護(hù)和深入洞察API活動(dòng)。

結(jié)論

API安全性是數(shù)字化轉(zhuǎn)型計(jì)劃的重要組成部分，可以提高跨渠道的網(wǎng)絡(luò)彈性。

在零信任時(shí)代，采用以身份為中心的API安全基礎(chǔ)設(shè)施是現(xiàn)代數(shù)字化轉(zhuǎn)型戰(zhàn)略的核心。為了確保API的安全性，企業(yè)需要深入了解API活動(dòng)和AI驅(qū)動(dòng)的漏洞檢測(cè)。兩者都需要在基本的API訪問控制上進(jìn)行分層，以捕獲源自API漏洞的攻擊，并在傳統(tǒng)API安全系統(tǒng)的配置中修復(fù)人為錯(cuò)誤的風(fēng)險(xiǎn)。