領先於新型 API 威脅的三種方法
在以 API 為核心的世界中確立以 API 為核心的安全性
API 連接萬物的隱藏陷阱
二十多年前，Jeff Bezos 宣佈，Amazon 的所有團隊都必須「透過服務介面來公開其資料和功能」，沒有例外。這份備忘錄（現在被稱為「API 指令」）基本上表明，應用程式設計介面 (API) 不是可有可無的，它促使各地的開發人員紛紛投入將一切事物透過 API 相連的潮流。然而，對於許多組織來說，API 安全性已經跟不上 API 部署的快節奏。
根據最近的《2024 年 API 安全性與管理報告》，與 API 相關的流量現在已佔所有動態網際網路流量的多數（約 57%）。但是，企業通常會發現自己面臨以下挑戰：
不可見且未受保護的攻擊面：IT 和安全部門無法保護他們看不到的東西，而組織存在著「影子 API」，即未受 IT 或安全團隊管理的 API，從而導致資料暴露、橫向移動和其他網路風險。
授權過度寬鬆：如果對原本應授予唯讀權限的人授予了對 API 的「寫入」權限，則會使系統容易受到攻擊並可能導致資料丟失。然而，將近 60% 的組織允許對其至少一半的 API 進行「寫入」存取。
企業容易忽視並誤分類 API 相關錯誤的原因：並非所有的 API 錯誤都是由攻擊引起的，而且並非所有針對 API 的攻擊都能以相同方式加以緩解。一個被忽視或誤診的錯誤或漏洞可能會導致使用者體驗不佳，在更糟糕的情況下，還會導致網路攻擊。
據估計，目前使用的公用和私人 API 達到 2 億個，而且數量還在持續成長。為了安全地利用這些（以及未來的）API 的力量，組織需要採用專門設計的 API 管理方法，其中包含以下 3 條「應該做」與「不應該做」的原則。
1) 務必利用專門設計的機器學習服務，以提高 API 的可見性及安全管理的效率。
假設 Acme 醫院提供了一些深受患者和醫療提供者喜愛的數位計畫：從無縫的行動遠端醫療到 AI 輔助的病歷處理，一應俱全。有一天，Acme 醫院的一名開發人員在未進行適當文檔記錄的情況下，為計費系統的 API 啟用了「寫入」權限。幾個月後，該廠商遭到駭客攻擊——隨後，攻擊者透過橫向移動，利用 Acme 醫院的公用 API 入侵了該醫院的病患病歷。
如果 Acme 醫院有一種方法能夠自動執行以下操作，本可以更早地偵測並緩解這種情況：
發現所有公用 API 端點（包括未經驗證的 API）及相關流量
偵測 API 結構描述——定義有效 API 請求/回應規範的中繼資料
偵測針對 API 的攻擊變體
登場：利用機器學習模型的 API 安全解決方案，且無需 IT、安全部門和開發人員進行手動的「時間點」通訊。
例如，機器學習支援的 API 探索和 API 結構描述偵測，可以幫助像 Acme 這樣的組織建立更完整的 API 詳細目錄：這些 API 是什麼？它們存取哪些資料與系統？什麼時候以及在哪裡對它們進行了存取？誰被授予了「唯讀」權限？誰又被授予了「寫入」權限？
這類資料對於防止影子 API 的泛濫至關重要。在開發新的客戶功能（這些功能通常首先以面向網際網路的 API 形式提供）的過程中，API 文件編寫和安全「最佳做法」通常由開發人員自行決定。很多時候，沒有足夠的時間或資源讓安全部門參與進來。
這就是出現網路安全挑戰的原因：組織無法保護他們看不到的東西。實際上，Cloudflare 的機器學習模型發現的 API 端點比組織自行報告的多出 31%——這表明近三分之一的 API 基本上是「影子 API」。
影子 API（通常是在頻繁的程式碼變更期間無意引入）本身並非惡意。然而，考慮到有 86% 的開發人員並未將應用程式安全性視為首要任務，影子 API 便成為了一個主要威脅。如果被利用，它們可能導致資料洩露、未修補的漏洞、違反資料合規性以及其他風險。機器學習有助於讓這些影子 API 從黑暗中現形。
2) 不要僅僅依賴 Web 應用程式安全工具來實現 API 安全性和管理。
Web 應用程式和 API 在本質上是不同的。例如，拼車應用程式對其使用者而言是「可見的」，但使該應用程式能夠存取 Google Maps 資料的 API 卻是「不可見的」。考慮到這些（以及其他）差異，組織需要專門構建的 API 安全性解決方案來保護 API，而不僅僅是使用 Web 應用程式安全性解決方案。
例如，傳統的 Web 應用程式防火牆 (WAF) 會根據封鎖清單篩选和監控 Web 應用程式與網際網路之間的 HTTP 流量。WAF 會尋找已知的攻擊跡象，然後採取動作來阻止這些攻擊。其他所有流量則被允許通行。這是一種「被動」安全性模型，對於 Web 應用程式安全性而言，由於更容易識別和封鎖惡意 Web 流量，所以這種模型可能是有效的。
然而，保護 API 免遭濫用（即 API 安全性）需要採取「主動」安全策略。不要僅僅尋找「已知惡意」的請求，而是尋找「已知善意」的請求，並僅允許這些請求通過，其餘的則全部封鎖。（在此處深入瞭解如何定義這些請求（即 API 呼叫））。
為什麼？
以一家澳大利亞電信提供者為例，該公司曾遭遇一起資料洩露事件，近 1000 萬客戶的資料被曝光。駭客透過一個未經驗證的 API 存取了某個客戶資料庫。雖然公眾並不瞭解此次攻擊的全部細節，但值得注意的是，採用「主動」API 安全性模型本可以只允許符合該公司 API 規範的 API 流量通行。
換句話說，轉向「主動」API 安全性，僅允許來自經過驗證的使用者、經過驗證的企業網路，並執行授權動作的流量通過。（組織也可以結合多種安全模型，例如將 WAF 的「被動」安全性與 API Gateway 的「主動」安全性層疊使用）。
總之，需要採取全面的 API 防護方法，來抵禦多種多樣的 API 威脅，其中包括以下 6 大主要 API 威脅：
來源：2024 年 API 安全性與管理報告
如上圖所示，在已緩解的 API 威脅中，HTTP 異常佔了多數 (60.7%)。HTTP 異常（例如，缺少使用者代理程式（為終端使用者擷取網際網路內容的軟體）以及其他異常）是常見的惡意請求訊號。
透過採用前文所述的「主動」安全性機制，組織可以識別 HTTP 異常情況及其他威脅，並僅允許每個 API 的「乾淨」流量到達其 API 伺服器。
3) 務必統一管理應用程式的開發、效能與安全性。
IT 部門、安全部門和應用程式開發人員應共同負責保護因擁有數千筆 API 支援的資產而帶來的巨大攻擊面。然而，這些團隊的優先任務往往相互衝突：
73% 的開發人員表示，網路安全團隊要求他們做的工作或使用的工具「干擾了他們的工作效率和創新」。
87% 的 CIO 認為，軟體工程師和開發人員「在安全策略和控制方面作出妥協，以更快地將新產品和服務推向市場」。
僅一半的 CISO 認為，開發人員「非常熟悉」開發和工作流程工具的安全風險。
因此，組織可能會在加快創新速度和提高安全性之間「權衡取捨」，從而使其 API 面臨風險。根據該報告，將近 60% 的組織允許對其至少一半的 API 進行「寫入」存取，但由誰來最終「負責」確保不會將「寫入」存取權限授予不當的使用者呢？
對於那些不斷透過 API 推出新服務的企業而言，全球連通雲能夠充當應用程式部署與 API 縱深防御之間的結締組織。
全球連通雲是一個統一的雲端原生服務平台，可簡化跨 IT 環境的安全「任意」連線性。反過來，這有助於組織重新取得對其龐大數位網域（包括其 API 流量）的控制和可見性。
藉助全球連通雲，組織可以使用單一控制平面完成以下工作（以及更多其他工作）：
自動化 API 探索與可見性流程，為所有利害關係人提供清晰的 API 資產詳細目錄
從一開始就對 API 驗證和授權流程進行現代化改造
管理 API 端點以監控延遲、錯誤和錯誤率，以及 API 驅動網域的回應大小等指標
隨著時間的推移提高 API 安全性成熟度
API 技術並非新鮮事物，但從整體上解決 API 安全問題對許多 AppSec 和 AppDev 團隊而言卻是新挑戰。然而，任何進步都有起點，API 安全性可以分階段解決：
第 1 階段 - 可見性：首先找出組織內使用的所有 API。使用 API 探索工具，審查技術文件和協議，與開發人員交談，以及監控 Web 流量。
第 2 階段 - 一般 Web 攻擊防護：Web 應用程式和 API 通常協同工作（例如，電子商務網站使用 API 來處理支付）。使用並整合專門設計用於保護 Web 應用程式（也在一定程度上保護其背後的 API）免受 DoS 和 DDoS 攻擊、憑證填充、零時差漏洞和其他威脅的工具。
第 3 階段 - 整合式進階 API 安全性：Cloudflare 的 Web 應用程式和 API 保護 (WAAP) 產品組合由全球連通雲提供支援，可在不妨礙生產力的前提下，為面向公眾的 API 提供全面的安全性和效能保障。透過 API 探索、整合式 API 管理和分析以及分層防禦，Cloudflare 讓 IT 和網路安全部門能夠清楚瞭解並控制其 API。
Cloudflare 就影響當今技術決策者的最新趨勢和主題發表了一系列文章，本文為其中之一。
深入探討這個主題。
取得《2024 年 API 安全性與管理》報告，瞭解最常見的 API 漏洞、產業預測，以及更深入的 API 保護建議。
重點
閱讀本文後，您將能夠瞭解：
3 個常見的 API 相關挑戰
專用 API 管理的「應該做」與「不應該做」
如何隨著時間的推移提高 API 安全性成熟度