數字轉型是基於一種可驅動新的操作模型的API，提供對業務邏輯、應用程序和數據的直接訪問。雖然這種訪問對於員工，合作伙伴和客戶來說非常方便，但它也使API成爲黑客和惡意網絡的攻擊目標。隨着越來越多的攻擊和漏洞，擴展安全性現在變得越來越重要。
現有的解決方案（例如訪問控制，速率限制等）提供基本保護，但不足以完全阻止惡意攻擊。今天的安全團隊需要識別並響應動態變化的攻擊，這些攻擊利用了各個API的自我漏洞而提高了攻擊的成功率。想想在未來，人工智能可以檢測API以及其他泄露數據的異常行爲，自動阻止對整個API基礎架構的攻擊，並設計完善解決方案是多麼值得期待的事。此方法爲IT基礎架構提供了深入的可見性，並使安全團隊能夠在識別出惡意行爲時立即採取行動。
API違規
2019年，澳大利亞最大的房地產估價公司LandMark White發生API漏洞，導致房產估價細節和客戶信息泄露。在這種情況下，本來只供內部使用的API卻可以從公司域外訪問。
這些漏洞導致了不同程度的公司違規行爲，包括賬戶被接管，私人信息和照片被盜以及信用卡號碼的提取。在此次違規行爲之後，該公司的良好聲譽遭到破壞，他們的客戶和銀行合作伙伴急忙尋找其他替代品。
從泄露到發現漏洞整個過程持續了數週或數月才被檢測到，同時其他類似的違規行爲已經花了將近一年時間才能完全解決。除LandMark White外，到目前爲止許多人信息仍是沒有保障的，這是一件十分危險的事情。要了解如何防範這些威脅，我們必須首先了解API所帶來的潛在漏洞。
API漏洞
許多企業目前依靠不充分的安全措施來保護其API。雖然API管理工具提供了一些重要的安全功能，包括身份驗證和速率限制，但這些做法通常無法阻止專門爲違反API及其提供訪問權限的數據和系統而構建的攻擊。
1.不完整的驗證
缺少權限審查是最近一系列API違規中反覆出現的漏洞模式。這些丟失的權限審查會在生產API中暴露漏洞。在某些情況下，完全缺乏訪問控制已經使API信息暴露，使得具有基本技能的不良行爲者可以進行惡意攻擊。
在Facebook，USPS和Verizon / LocationSmart的情況下，黑客使用特定帳戶對API行爲進行反向工程，以識別至少一個漏洞，該漏洞可以在沒有正確憑證檢查的情況下提供對來自其他帳戶的數據的訪問，而且將所有這些都僞裝成像普通用戶。這種技術有可能提供對大量賬戶的訪問，並已成功用於破壞某些銀行和保險公司。
如果調用API的應用程序時，可能不會暴露上述漏洞。因爲通過跳過客戶端應用程序（例如，Web應用程序）並直接調用API來觀察數據和控制流，是會獲得惡意訪問的。客戶端應用程序極大地限制了通過用戶界面限制使用API的方式，依賴應用程序可能會提高些許安全性，尤其是在API層的應用程序之外未執行測試時。
除了訪問控制之外，API安全性還必須包括內容驗證。在2019年初發現（已經修復）的Kubernetes的API服務器事件，向我們展示了這種缺乏安全性內容是致命的。整個事件起始是被授權向Kubernetes API服務器發出補丁請求的用戶可以發送過量消耗的特別補丁。這種處理過程中的資源上傳，導致API服務器上遭受到服務（DoS）攻擊。
利用此類漏洞可以極大地破壞服務，如果傳入的JSON補丁包含超過10,000個操作，則Kubernetes API服務器修復包括返回413類型錯誤。這種類型的內容驗證很容易在API網關中配置，但它經常被遺漏，因爲這樣做需要超越自動生成的JSON模式，這些模式只定義簡單的規則類型，需要人工干預才能識別特定驗證的需要，並確保正確的配置和測試。
2.API缺乏可見性
就目前來看，API數量的激增只會增加其漏洞。API的部署速度比以往任何時候都要快，而且很多不同的團隊在某些情況下，要求創新、減少摩擦和創造新收入流的持續壓力會導致API不可用的意外影響。
因此，許多利益相關者報告其組織部署的所有API缺乏可見性，這並不奇怪。事實上，許多API相關的漏洞已經被發現幾個月，甚至是幾年，這進一步說明了整體API設計缺乏可見性。
此外，一些API並不是公開的，可能只被視爲總體項目的實施細節。這使他們會被從安全性的角度隱藏起來，但反過來又導致缺乏特定的安全考慮因素。在其他情況下，從組織的不同部分出現的API可會因爲異構平臺導致不一致的安全策略。
無論如何，這些API可能與公共API一樣容易受到攻擊，因爲它們同樣容易被黑客反向設計。爲彌補這些差距，我們需要清楚地瞭解需要保護的內容，對API流量的深入洞察爲改善網絡安全提供了起點。
3.超越Token驗證的思考
驗證Token並驗證請求用戶的身份通常不足以支持API基礎結構。在API層應用粒度訪問控制的能力不僅符合邏輯，而且隨着API成爲訪問開發人員的數據的最常用渠道，它將成爲常態。
此外，定義應允許個人請求哪些數據的規則不僅由API提供商定義，還由用戶定義。這些決策允許用戶在涉及他們擁有的數據時限制應用程序，因此用戶API的管理策略與核心API安全性概念緊密相關。
API基礎安全的核心是審查和治理流程的定義，更新的API必須經過審覈，首先要確定問題的答案，包括：
- 訪問API需要哪些權限？
- 誰是預期的請求者？
- 該服務將利用哪些數據庫和數據進行讀寫？
- 該API與之交互的其他服務是什麼？
- 輸入和輸出參數是什麼樣的，它們應該如何被限制？
這些問題的答案會告訴我們預備發佈的新API應該採取哪些安全策略。
4.擴展舊的基礎API安全性
即使有正確的基礎，安全性也只能保持與其配置的程度相當而已。當配置受到人爲錯誤的影響時，API漏洞使其經過測試並投入生產的風險隨着API層複雜性的增加而增加。即使你已採取一切措施來防止它，仍然可能面臨在API本身上暴露漏洞的風險。
例如，黑客經常通過網絡釣魚攻擊竊取tokens，這些攻擊允許他們構成合法的應用程序。此外，代表用戶調用API的客戶端應用程序也存在缺陷，並且在保密方面非常糟糕。這可以像通過查看應用程序的JavaScript代碼或通過HTTPS代理查看API流量而進行反向破解API密鑰一樣簡單。
例如，北卡羅來納州立大學的一項研究表明，GitHub是一個用於調用API的應用程序機密寶庫，超過100,000個存儲庫泄漏了API token和加密密鑰。GitHub通過實施新的安全功能從提交到其平臺的代碼中掃描token來實現這一發現。
攻擊者還使用遠程訪問特洛伊木馬來竊取憑據，如Mimikatz。然後，他們使用竊取的憑據來冒充用戶並獲取token。另一個常見漏洞是授權服務器上的憑據填充，利用從先前漏洞中挖掘的憑證集合。
在每種情況下，攻擊者都會利用用戶調用客戶端應用程序或授權服務器上的漏洞獲取token，而不是API本身。這提出了許多問題，因爲這些token似乎是合法的，黑客看起來像一個有效的用戶。這爲用戶數據“通過API泄漏”設置了臺階，即使有適當的訪問控制策略和運行時實施，這些攻擊除了那些涉及API本身漏洞的攻擊，也不會被傳統的API安全工具檢測到，而且通常持續數月甚至數年。
安全團隊可以投入大量精力教育用戶和API開發人員關於客戶端應用程序安全性和身份基礎架構，但他們仍然可能面臨生產API漏洞和憑據泄露的風險。API提供商必須在其安全措施中考慮這一點，無論API是內部還是外部。但其實可以通過應用人工智能（AI）來加速攻擊檢測和自動阻止攻擊。
將AI應用於安全性
安全團隊可以根據用戶通常展示的API行爲來培訓機器學習引擎。通過使用AI，團隊可以識別好的和壞的流量，並在沒有人工干預的情況下識別未遂的攻擊和持續的攻擊。
1.用AI檢測非典型行爲
每個API調用時，訪問token或cookie的數據以及某些操作的時間和順序都可以提供給AI模型。在運行時，此機器學習引擎利用行爲模型來識別潛在威脅的跡象，例如特定token或cookie是否在合法應用程序之外使用，數據是否被泄露或更改等。
利用基於AI的異常使用檢測可顯着加速威脅可見性，將攻擊發現從數月轉換爲數分鐘或數秒。檢測到可疑API活動後，用於獲取API訪問權限的訪問token或Cookie可以列入黑名單或撤銷，立即停止在所有API端點上使用該token從任何一方進行訪問。如果這些攻擊背後存在相同的用戶身份，則必須將用戶身份本身列入黑名單並相應地進行標記。在沒有人爲干預的情況下實現這種類型的監視，攻擊檢測和阻止。
2.使用API誘餌
API陷阱的使用也可以加速API黑客攻擊的檢測。這涉及添加僞造的API資源，這些資源會向請求者返回看似有效的響應。陷阱利用黑客傾向於以合法應用程序不具備的方式進行搜索，有效地轉變爲桌面以利用圍繞典型黑客行爲的知識。
當黑客陷入這些陷阱時，他們會立即得到認可。同時，他們的相關IP地址和訪問token（如果他們當時擁有它們）會自動被視爲已泄露並列入黑名單。陷阱偵聽器能夠識別出這些請求不可能從真正的應用程序傳入，因爲這些API資源不合法存在。這些安全措施不需要自定義規則或擴展配置。
3.阻止和修復
當然，檢測只是解決方案的一部分，系統如何反饋同樣重要。一旦發現客戶私人信息（例如token）已被泄露，該信息必須立即被撤銷或列入黑名單。此外，必須記錄這些事件以供後續審覈，並且必須通知安全信息和事件管理（SIEM）系統以應對接下來類似的情況。
應記錄有關在檢測和阻止受損憑據之前調用的方法和資源的詳細信息，以報告形式提供的信息允許API提供者、DevOps團隊或安全團隊採取必要措施來修復或逆轉攻擊造成的損害。
保護API的技術和工具
使用合適的技術和工具來保障API的安全性，是一種最易實現的舉措。現在，有許多技術和工具可以最大程度上的保護API免受網絡攻擊和黑客入侵，最簡單的就是用API gateway（API網關），通過流量過濾和節點監控等方式去防止未知的攻擊和入侵。諸如國外的Amazon API Gateway（亞馬遜旗下）、國內的 GOKU API Gateway（EOLINKER 旗下）等都能輕鬆的實現網關係統的要求。在 API gateway 這個領域，也有一些開源框架在活躍，如 Netflix Zuul，基於 Nginx 的 Kong 等，目前關注較少，就不展開介紹了。在選擇網關係統時，安全性、便捷性和本土化性需要特別關注的幾個關鍵因素，這些網關都對API的安全性有一定的保障，使得私密的信息能免遭泄露。
結論
API安全性是數字化轉型計劃的重要組成部分，可以提高跨渠道的網絡安全。在危機四伏的時代，採用以身份爲中心的API安全基礎設施是現代數字化轉型戰略的核心。爲了確保API的安全性，還需要深入瞭解API活動和AI驅動的漏洞檢測。兩者都需要在基本的API訪問控制上進行分層，以捕獲源自API漏洞的攻擊，並在傳統API安全系統的配置中修復人爲錯誤的風險。
參考資料：Jinesh Thakkar，Secure APIs Using Artificial Intelligence
原文鏈接：https://dzone.com/articles/se...
圖片來源：互聯網