技術繼續以前所未有的速度發展。應用程序編程接口 (API) 的開發和使用是一個特別值得注意的例子。
最新的 Salt Labs API 安全狀態報告 發現總體 API 流量在 12 個月內增加了 168%，而同期 API 攻擊流量增加了 117%。也許可以理解，許多 CISO 都在努力跟上。
根據同一份報告，94% 的組織在 12 個月內遭遇了 API 安全事件。此組中包括家喻戶曉的品牌，例如 Experian、Peloton 和星巴克。就連樂高也曾在去年年底糾正了一個潛在的災難性 API 漏洞。擁有大量安全預算的大公司經常會遇到 API 安全事件。顯然，在保護 API 方面，傳統的應用程序安全技術根本達不到標準。
考慮到這一點，我們採訪了 Salt Security 以澄清一些 API 安全性最常見的問題。
BN:零信任架構可以保護 API 嗎?
YB:不幸的是，零信任無法減輕許多 API 風險。零信任的目標是限制訪問，而 API 需要訪問才能發揮作用。大多數 API 都是公開的或開放的，旨在供整個互聯網和龐大的客戶群使用，這對零信任提出了獨特的挑戰。
此外，API 攻擊通常發生在受信任的渠道和經過身份驗證的會話中.攻擊者知道如果他們可以獲得授權用戶的密鑰或憑證，他們就可以訪問有價值的數據。通過使用竊取的活動會話 cookie、身份驗證令牌、雙因素身份驗證挑戰、API 密鑰和其他身份驗證材料搭載或劫持經過身份驗證的會話，黑客不會受到零信任架構的阻礙。請記住，根據 API 安全狀況報告，驚人的 94% 的攻擊都發生在經過身份驗證的 API 上。
當談到零信任時，組織必須超越身份驗證和授權的原則。他們需要 API 運行時保護來持續驗證授權用戶對 API 資源的訪問和行為，發現異常並查明不良行為者。
BN:雲安全產品可以保護 API 嗎?
YB:雖然一些雲安全提供商確實提供了 API 管理或 API 網關等工具，但諸如此類的單點產品不足以保護企業免受 API 攻擊。這些工具在應用程序層和 API 層的 API 安全功能有限，導致 API 得不到保護。 API 攻擊實際上是零日攻擊，這意味著旨在尋找已知“不良”行為（例如簽名或列入黑名單的 IP）的安全工具永遠無法正確保護 API。這裡還值得注意的是，由於 API 是應用程序邏輯，因此云客戶對在安全共享責任模型中保護它們負有最終責任。
BN:為什麼 IAM、WAF 或 API 不能網關保護 API?
YB:雖然 IAM、WAF 和 API 網關在每個組織的安全堆棧中都是必要且重要的工具，但它們無法保護 API——主要是因為它們沒有提供必要的可見性或安全控制。
攻擊者不斷繞過訪問控制，並獲取密鑰和令牌。當代黑客是規避訪問控制、搭載經過身份驗證的用戶會話或從流量、設備存儲或應用程序代碼中獲取身份驗證材料的專家。IAM、API 或 WAF 解決方案無法檢測到這些攻擊技術。
這些工具也無法檢測到特定於 API 的問題——例如，業務邏輯濫用和授權利用——因為它們依賴於簽名和規則來檢測攻擊。更糟糕的是，它們固有的 API 管理組件也可能被利用。
此外，IAM、WAF 和 API 網關都依賴於代理。由於代理模型減慢了 API 通信速度，組織通常無法調解與網關或 WAF 一起使用的每個 API——尤其是對於內部或內部 API。這導致無法了解這些 API 的使用方式。
BN:可以通過工作負載保護來保護 API 嗎?
YB:工作負載安全保護提供了很多好處。除其他事項外，它們有助於提供基礎架構安全性以確保您不會在易受攻擊的軟件版本上運行工作負載，並且還有助於阻止外部用戶訪問工作負載。但是，它們未能提供 API 或應用程序級上下文，因此無法保護 API 本身。
BN:左移對於保護 API 的有效性如何?
YB:雖然在開發階段實施安全性是一種值得實踐的做法，但左移支持並不意味著每個 API 都將在生產前得到保護。開發人員測試工具根本無法識別所有漏洞。許多常見的 API 安全問題無法通過常見的安全分析和測試工具識別為自動化設計、開發和構建掃描的一部分——除非使用 API，否則無法發現業務邏輯缺陷。
圖片來源: Panchenko Vladimir/Shutterstock