編譯| API 安全是新的雲安全嗎？

隨着 API 越來越多成爲了互聯網流量最常見的通信渠道，保護它們的安全對企業安全團隊來說將變得愈發重要，也更具挑戰。API 的普遍性極大地拓展了非法分子的攻擊面，也使這些攻擊面之間的聯繫變得更加緊密了。

換句話說，API對所有企業、社會組織都構成了巨大的安全威脅。

Imperva 首席技術官 Peter Klimek 將這個 API 安全的概念比作成早期的雲安全，他說：“在雲遷移正式被關注前人們並不關心雲安全，而針對不同渠道所開發的 API 數量確實呈爆炸式增長。雖然以前對API的使用方式似乎更謹慎，主要是用於移動應用程序或一些 B2B 流量等，但現在客觀條件放在那兒，幾乎所有東西都需要由 API 提供支持，因此，所有這些新的 API 都有可能帶來更多的安全風險，這也是當下很多 CISO 會去關注的原因。”

根據 Klimek 的說法， Imperva 將 API 安全風險分爲兩類，第一類是技術漏洞，包括標準 Web 應用程序中也可能存在的一系列風險，例如OWASP 十大應用程序安全風險和CVE 漏洞，Log4j 漏洞就屬於這一類。

大多數 Imperva 客戶首先應對的就是這些威脅，因爲它們往往是最嚴重的威脅，用戶只需要採用現有的應用程序安全策略，例如在開發過程中進行代碼掃描或部署 Web 應用程序防火牆或使用應用程序自保護技術等就可以了。用戶採用了這些策略，並將其更多地轉移到 API 安全方面。

而第二類風險對於 API 來說更爲獨特，這是因爲API 與 Web 應用程序不同， API 安全性從根本上說是一個數據安全問題。API 使人們或系統能夠快速查詢數據、訪問數據或修改數據、置換數據，因此我們現在在 API 安全中看到的一些策略都來自於圍繞數據安全所制定的策略，用戶會去研究瞭解到底是誰在訪問這些數據，他們的敏感數據在哪裡，以及哪些 API 暴露了敏感數據，然後將這些用作如何解決問題的模型。

API 安全的 4 個步驟

根據 Klimek 的說法，實現 API 安全性有四個步驟。與大多數安全策略一樣，第一個是發現，這包括構建 API 、API 的端點、API的庫存。

Klimek 說：“更爲重要的是，當你深入研究API的安全時，你得弄清楚每個人實際處理的數據類型是什麼？這麼做是爲了讓企業更好地瞭解他們的風險狀況以及所有 API 端點的風險狀況。”

第二步涉及監控 API。API 的結構是什麼樣的？哪些 API 在請求進入企業系統？誰在訪問這些請求？Klimek 表示，企業需要監控他們的 API 流量，並找出潛在的威脅。

第三步，Klimek認爲我們通常需要以兩種不同的方式對保護進行分類。第一，我們必須先確定該阻止哪些實時威脅，因爲在這諸多攻擊中，一個精心設計的惡意請求可以有效地毀掉整個公司，所以實時漏洞是必須得馬上緩解的。第二則需要防止攻擊者會策劃更長遠的攻擊，因此就需要查看更長的事件鏈，而不是防止單個 API 攻擊。

Klimek 說：“你得了解並基本能描述出個人消費者或客戶在很長一段時間內訪問了你們多少數據和 API，因爲對於AI和分佈式拒絕服務 (DDoS)攻擊來說，問題並不在於個人請求，而在於持續抓取網站或來自受感染設備的大量流量。”

最後，API 安全性的第四步是驗證和合規。Klimek 解釋說：“這就好比企業爲他們的開發團隊設置了護欄的地方，相當於在開發生命週期中轉移了安全性。在這種情況下，我們在開發週期的早期就能測試 API，以主動識別問題。”

安在新媒體