OWASP 前 10 大 API 威脅

您正在查看 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

本文說明您可以在 Apigee 中使用各種方法，解決 OWASP 指出的安全漏洞。如要進一步瞭解 Apigee 的其他方法，請參閱 Google Cloud 上的 OWASP 2021 年前 10 大風險緩解選項。

簡介

OWASP 是一個開放社群，專門協助機構開發、購買及維護可信任的應用程式和 API。透過 OWASP API 安全性專案，OWASP 會發布網頁應用程式和 REST API 最嚴重的安全性風險，並提供相關建議，協助您解決這些風險。

本文件將討論 OWASP 2019 年十大 API 安全威脅所指出的常見 API 攻擊防禦方法。最新清單中列出的重大威脅，其共同特徵是驗證和授權控制項放置不當，例如依賴用戶端應用程式內的 API 要求所傳回資料篩選，並使用依賴使用者端應用程式執行存取權控管的反模式。

隨著 API 生態系統持續快速成長，API 濫用和誤用導致攻擊者竊取資料，不幸地成為現今最常見的攻擊途徑之一。安全性仍是 Apigee 的重點優先事項，我們推出了多項新功能，例如 Advanced API Ops，其中包含安全性報表和異常偵測功能。不過，正確設計及實作 Apigee 的安全性功能，對於降低 API 遭到成功攻擊的可能性至關重要。

消費者應用程式應視為不受信任或「公開」，因為您無法控制應用程式執行的平台。假設任何公開應用程式都可能遭到入侵，因此無法信任這些應用程式執行存取權控管 (API1、API5)、篩選回應資料 (API6)，或安全儲存用戶端機密 (API2)，例如 API 金鑰或存取權權杖。我們根據 2019 年 OWASP 十大攻擊手法，提出以下建議：

  • 決定哪種用戶端應用程式會使用您的 API (SPA、行動或瀏覽器)，並設計適當的驗證、授權和安全性模式。
  • 請一律使用「公開用戶端」OAuth 或 OpenID Connect 流程 (強烈建議使用 PKCE)
  • 請先思考應用程式的商業邏輯，定義 OpenAPI 規格，然後設計 API 代理程式，以便篩選 Apigee 後端的所有回應資料。請勿依賴下游應用程式程式碼邏輯執行此操作！
  • 篩除所有含有使用者特定 PII 的資料要求，只允許來自後端的資料，且該資料屬於要求使用者。

API1：2019 年物件層級授權異常

威脅說明

如果對物件存取要求的授權驗證不足，攻擊者就能透過重複使用存取權杖，執行未經授權的動作。這類威脅是因為授權驗證設定不當所致。Apigee 提供 VerifyApiKey、OAuth 和 JSON Web Token (JWT) 政策，有助於防範這項安全漏洞，但這些政策必須正確設定，才能防範這項威脅。

為避免這類威脅，應用程式開發團隊和安全團隊必須密切合作。授權本質上是複雜的議題，而有效的精細授權需要深入瞭解應用程式的商業邏輯。

從 Apigee 導入的角度來看，您需要考量兩個主要層面：

  • 存取權杖完整性
  • 存取權控管機制

存取權杖完整性

請務必使用正確的 OAuth 或 OpenID Connect 流程，搭配適當的憑證驗證或簽署機制，驗證要求用戶端提供的權杖是否遭到竄改。Apigee 支援所有常用的 OAuth 流程。

Apigee 存取權杖驗證政策包括：

強制執行存取權控管

驗證存取權杖的有效性後，請務必實施存取權控制強制執行政策，根據授權權杖的存取權限來評估每項傳入的 API 要求。

Apigee 提供兩種主要機制，用於驗證及強制執行授權政策：

  • 內部：使用條件式流程，根據從授權權杖中擷取的聲明做為流程變數，評估存取要求
  • 委派：使用服務呼叫至第三方存取權管理解決方案

如果存取權控管模型相對簡單，建議採用內部方法 (如上圖所示)。舉例來說，如果從存取權憑證中擷取的宣告可用於直接評估及授權 API 物件要求。

使用 OAuth 或 JWT 政策提供的流程變數，透過條件式流程陳述式評估存取要求。

如果從存取權杖擷取的權杖無法直接用於授權後端物件的 API 要求，或是需要單獨呼叫授權伺服器才能取得存取權杖的更複雜 OAuth 流程類型，建議採用委派方法 (如上圖所示)。

使用服務呼叫政策，您可以向第三方服務要求授權政策決定，或是取得要求代理程式的其他宣稱資訊，然後使用條件式流程做出存取權控管決定

API2：2019 年使用者驗證功能故障

威脅說明

若使用者驗證政策實作不當，攻擊者便可利用驗證實作項目中的實作缺陷，模擬合法使用者。實作驗證方法時，請牢記以下幾項驗證原則：

  • 請務必同時驗證使用者代理程式 (應用程式) 和提出要求的使用者。
  • 使用委派驗證和授權模式，並避免直接在 API 要求中傳遞密碼
  • 請一律驗證存取憑證的簽名，並確保所有使用的存取憑證都有明確的到期時間。
  • 設定配額，並使用 Apigee Sense 偵測並回應由機器人發動的暴力破解攻擊，以防範暴力破解攻擊

在由外而內的架構下，API 設計會以資料使用者的用途而非後端系統中現有資料的結構為基礎，而為外部使用者設計 API 時，安全性是至關重要的元素。後端系統通常不會採用足夠強大的驗證實作，因此無法公開於網路上。這正是 Apigee 與身分和存取權管理解決方案結合後，可提供強大解決方案防範這類威脅的最佳時機。

這裡有幾個主要元素需要考量，後續章節會一併說明：

  • 安全性設計：充分運用 Apigee 功能，導入驗證模式
  • 治理：確保在所有發布的 API 產品中，設計的驗證模式一律正確使用
  • 營運安全性：能夠偵測可疑或異常行為，並嘗試規避或暴力破解已驗證的 API Proxy

安全性設計

安全性設計的目標是正確實作驗證流程，並與第三方身分工具整合。安全性設計是關鍵階段，首先必須根據將使用 API 端點的應用程式類型，瞭解要使用的正確委派驗證流程類型。接下來，請與身分識別團隊共同定義要透過身分識別解決方案導入的整合模式。

OpenID Connect 和 OAuth RFC 提供多種委派驗證和授權流程，以及這些流程中的參與者。這項主題相當複雜，而驗證機制故障是 OWASP API 前幾大威脅之一，這一點毫不令人意外。本文件無法提供有關如何正確導入身分識別標準的完整入門資訊，但 Apigee 提供許多其他資源，協助您進一步瞭解 OAuth 流程，例如這本電子書和網路廣播，以及實作範例。

驗證政策

有助於解決身分和驗證問題的 Apigee 政策包括：

流量管理

下列 Apigee 流量管理功能可協助防範暴力破解攻擊：

  • 尖峰流量防範政策，可為 API 代理程式設定整體滾動平均頻率限制。
  • 配額政策：根據應用程式金鑰、開發人員或 API 產品配額定義的配額，為 API Proxy 設定精細的頻率限制
  • 快取政策，可根據定義的到期時間快取已儲存的存取權權杖，以及invalidate快取憑證的功能 (例如在有效存取權權杖遭到入侵的情況下)

管理

安全性是一項持續進行的過程，而不是「設定就好」的專案，而設定錯誤是造成安全漏洞的最大原因之一。一旦定義驗證流程、身分整合模式和驗證相關的流量管理政策，就必須正確且一致地實作這些政策。

Apigee 提供多項功能和工具，可確保導入完整性並避免設定錯誤。

角色型存取權控管 (RBAC)

無論您是大型企業還是小型新創公司，只要確保只有適當的使用者和團隊可以存取及修改 API 代理程式設定，就能避免設定錯誤。API 計畫由貴機構的跨領域團隊提供支援。在 API 旅程中，每個團隊都必須只獲得執行工作所需的必要權限，這一點絕對必要。

Apigee 提供的功能可讓您管理以角色為基礎的存取權，您可以將使用者指派給預先定義的角色，或是建立適合 API 團隊的自訂角色。正確定義及管理角色指派作業，對於安全擴充 API 計畫至關重要。您也可以使用聯播功能整合現有的公司目錄，減少在 Apigee 中管理第二組管理員憑證的需求。

共用的流程

共用流程可讓您將政策和資源定義為可在各 API Proxy 中實作的可重複使用物件。舉例來說，您可能會根據使用 API 的應用程式類型，與安全性團隊共同設計多種驗證設計模式。API 開發人員不必是身分專家，也能重複使用這項功能，只要透過呼叫流程政策，瞭解正確的共用流程，即可將其新增至現有的 API 代理程式設定。

圖表：共用流程是可重複使用的政策和條件邏輯組合，可讓您維持複合模式。

安全性報告

確認只有貴機構中的適當人員可以修改驗證模式，並定義共用的驗證流程後，您必須確保 API 團隊開發的 API 代理程式一律使用這些驗證模式。

Apigee 推出的全新 Advanced API Ops 功能包含進階安全性報表，可讓作業和安全性團隊輕鬆查看所有 API Proxy 的報表，並著重於遵循安全性政策，例如使用共用流程。報表、記錄和快訊是 API 安全性的關鍵要素，我們會在 API10：記錄不足一節中進一步討論這項要素，但從防止驗證機制失效的風險的角度來看，這項要素非常有助於確保遵循以共用流程實作的已定義驗證標準。

作業安全性

一旦 API 在正式環境中使用正確的驗證模式，並設有基準流量管理機制，SecOps 團隊也必須能夠監控並回應可疑活動，這些活動通常會先嘗試破壞驗證憑證。

Apigee Sense

Apigee Sense 可保護 API 免受不必要的要求流量侵擾，包括惡意用戶端的攻擊。Apigee Sense 會分析 API 要求流量，找出可能代表不當要求的模式。您可以透過這項分析，找出發出不必要要求的用戶端，然後採取行動來允許、封鎖或標記這些要求。Sense 日後推出的功能將包括自動啟用 ReCAPTCHA 驗證功能，以便針對可疑流量進行驗證。

透過 Apigee Sense，您可以保護 API 不受以下要求模式的影響：

  • 與人類行為相似的自動化行為
  • 來自相同 IP 的持續嘗試
  • 異常的錯誤率
  • 可疑的用戶端要求
  • 資料檢索
  • 金鑰擷取和驗證暴力攻擊
  • 活動爆發
  • 地理圖案

Advanced API Ops

雖然 Sense 專門用於偵測並回應機器人類型的威脅，但 Advanced API Ops 同時包含異常偵測和進階快訊定義。

異常偵測功能會將人工智慧 (AI) 和機器學習 (ML) 模型套用至歷來 API 資料。異常偵測功能可針對您未曾想到的情況，即時發出快訊，協助您提高工作效率，並縮短 API 問題的平均解決時間 (MTTR)。

進階 API 作業會在現有的 API 監控快訊機制上，新增下列進階快訊類型：

  • 路況快訊總數。當流量在特定時間範圍內變動指定百分比時，系統會發出快訊。舉例來說，您可以設定在流量在 1 小時內增加 5% 以上，或在 1 週內減少 10% 以上時發出快訊。
  • 異常警示。Edge 會自動偵測流量和效能問題，您不必事先預測。接著，您可以針對這些異常狀況發出警示。
  • 傳輸層安全標準 (TLS) 到期警示。在 TLS 憑證即將到期時發出通知

API3：2019 年過度暴露資料

威脅說明

發布的 API 可能會揭露過多資料，需要仰賴用戶端應用程式執行必要的篩選。如果攻擊者直接查詢基礎 API，便可存取機密資料。

Apigee 的「outside-in」API 設計設計原則之一，就是資料節儉。請與 UX 設計師和開發人員合作，只透過應用程式 UI 所需的 API 提供資料。後端系統並非針對公開使用模式而建構，因此使用 Apigee 設計 API 時，第一項工作就是減少公開的資料，為客戶和開發人員提供優質的 API 產品。

Apigee 的另一項設計原則是可重複使用性。除了安全性疑慮之外，如果您依賴應用程式篩選 API 提供的資料，就必須在您為其開發應用程式的每個平台上，移植該篩選邏輯。

從安全性角度來看，這類威脅是因為將授權執行委派給應用程式，而該應用程式通常位於您無法控管的平台或 OS 上。我們在 API1 和 API2 中已討論過，正確實作驗證和授權的重要性，以免資料遭到未經授權的存取。

接下來幾節將說明如何：

  • 重新撰寫要求和回應至後端服務，盡量減少資料曝光
  • 實作錯誤處理機制，避免詳細的錯誤訊息將後端服務的機密環境資訊洩漏給攻擊者

重新撰寫回應和要求

後端系統通常不是設計用於公開應用程式，或跨不受信任的公開網路使用。Apigee Edge 的設計目的是讓您能部署公開 API 產品，同時保護後端免於過度曝露資料。

為此，Apigee 會使用三項重要政策：

  • 指派訊息
  • 程式碼說明
  • 錯誤處理

指派訊息政策

在 API Proxy 流程中，指派訊息政策會變更或建立新的要求和回應訊息。這項政策可讓您對這些訊息執行下列動作：

  • 新增表單參數、標頭或查詢參數至郵件
  • 複製訊息中現有的屬性
  • 移除訊息中的標頭、查詢參數、表單參數和/或訊息酬載
  • 設定訊息中現有屬性的值

使用 Assign Message 時，您通常會新增、變更或移除要求或回應的屬性。不過，您也可以使用「指派訊息」建立自訂要求或回應訊息，並將其傳遞至其他目標，如「建立自訂要求訊息」一文所述。

使用自訂程式碼進行複雜的重寫

如果資料處理和重寫規則的複雜度超出「指派訊息」政策的功能，您可以使用 JavaScript、Java 或 Python 等程序語言。您可以將自訂程式碼新增至 API Proxy，然後從新增至 Proxy 流程的政策中呼叫該程式碼。我們提供的程序碼支援功能，可讓您更輕鬆地實作流程變數、錯誤、要求和回應主體的複雜處理作業。

您可以使用程序碼：

  • 建立或操作複雜的內容值，例如要求和回應值。
  • 重寫網址，例如遮蔽目標端點網址。

Apigee Edge 針對支援的語言提供個別政策：JavaScript 政策、Java 說明文字政策和 Python 指令碼政策。

錯誤處理

Apigee 可讓您使用「Raise Fault」類型的政策，執行自訂例外狀況處理作業。「Raise Fault」政策是「Assign Message」政策的變化版本，可讓您針對錯誤狀態產生自訂錯誤回應。

共用的流程

共用資料流可用於強制執行錯誤訊息的標準化作業。舉例來說，您可以使用相同的設定政策，偵測後端的特定 HTTP 錯誤代碼，並用來重新撰寫錯誤回應，以便傳回一般錯誤訊息。

API4：2019 缺乏資源和頻率限制

威脅說明

如果未實施頻率限制政策，攻擊者就能透過阻斷服務攻擊癱瘓後端。

只要使用下列 Apigee 功能，就能輕鬆解決這項威脅：

  • 配額和尖峰流量防範政策：這類政策可做為預防性控管機制，用於對傳入的 API 要求設定流量限制。
  • Apigee Sense 可動態偵測及回應由機器人驅動的攻擊
  • 進階 API 監控和警示功能可做為偵測性控制項，在發生 DDoS 攻擊時發出警示

使用配額和尖峰流量防範政策限制頻率

Apigee 提供兩種頻率限制政策：

  • 尖峰流量防範提供在 API Proxy 層級定義的一般政策，用於限制後端的整體傳入要求數量
  • 配額提供精細的政策工具，可在 API Proxy 或 API 產品層級強制執行配額政策。

Spike Arrest

「尖峰流量防範」 政策可防範流量激增情形。這項政策會使用政策中可定義的滾動平均值，限制 API Proxy 處理並傳送至後端的要求數，以防範效能延遲和停機。

配額

配額政策可讓您設定 API Proxy 在一段時間內 (例如分鐘、小時、天、週或月) 允許的要求訊息數量。您可以為所有存取 API 代理程式的應用程式設定相同的配額，也可以根據下列項目設定配額：

  • 包含 API Proxy 的產品
  • 要求 API 的應用程式
  • 應用程式開發人員
  • 許多其他條件

這項政策比「尖峰時段偵測」更精細，通常應與「尖峰時段偵測」同時使用。

使用 Apigee Sense 偵測機器人

您可以使用 Apigee Sense 採取行動，根據顯示惡意或可疑行為的用戶端或位置，明確允許、封鎖或標記特定用戶端、IP 範圍或自治系統組織的請求。Apigee Edge 會在 API Proxy 處理要求前，將這些動作套用至要求。舉例來說，系統可以偵測出某個 IP 範圍或特定客戶的「暴力猜測」行為，然後將其封鎖或標記。

使用 Advanced API Ops Monitoring 偵測威脅

當環境、Proxy 或區域的流量在一段時間內變動指定百分比時，您可以使用流量快訊發出通知。當流量與預期的傳輸量有顯著差異時，這項功能會動態發出警報，例如在 DDoS 攻擊期間。這些快訊通知可輕鬆傳送至第三方記錄和監控解決方案。

API5：2019 年功能層級授權異常

威脅說明

這項威脅是 API1 的變化版本，也是一種授權漏洞。在這種威脅下，攻擊者可以向未經授權的函式傳送要求，進而執行動作。舉例來說，如果 API 端點未驗證 HTTP 要求動詞，攻擊者可能就能修改或刪除他們僅有讀取權限的資料，方法是將 GET 替換為 PUT 或 DELETE。或者，如果未針對 API 資源 URI 路徑實作足夠嚴格的存取控制，API 端點可能會讓攻擊者只需變更要求中的路徑，即可查看其他使用者的資料。

這類威脅凸顯了使用 Apigee 做為中介和抽象層的價值，因為許多非公開存取的後端系統可能會預設提供單一端點，用於執行多個業務邏輯函式，甚至包括高風險的管理功能。

降低這類威脅發生機率的概念元素通常可分為：

  • 哪些內容受到保護？請思考您的 API 產品策略，並在使用 RESTful 最佳做法設計 Apigee API Proxy、產品和應用程式功能所公開的路徑和資源時，實作功能的邏輯區隔。
  • 誰可以存取您的 API 資源？請使用 API1 和 API2 中概略說明的部分 Apigee 驗證和授權功能，定義高層級人物角色，並實作「最小特權」的預設存取權授權。
  • 如何執行存取權政策？使用條件式流程和錯誤來驗證所有 API 要求的網址路徑和動詞。

圖：這張圖表說明如何在 Apigee 中使用存取權杖中提供的範圍做為權限，強制執行函式層級授權。

使用 API Proxy、產品和應用程式進行邏輯區隔

Apigee 提供高度彈性的工具組，可讓您邏輯區隔 API 資源，讓API Proxy 整合至任意數量的 API 產品，再由應用程式開發人員使用，他們可以註冊應用程式，以便使用您的 API 產品。存取政策可在任何層級定義。

不過，如要實施有效的功能授權和區隔，定義 API 產品策略至關重要。這個持續進行的重要程序，其中一部分就是定義 API 產品的「誰」和「什麼」，也就是從客戶和開發人員的角度檢視 API 資源，然後進一步定義路徑資源和 HTTP 動詞層級，確切指出允許哪些類型的要求。

圖：API 產品內含的 API 資源可來自一或多個 API，因此您可以混合搭配資源，建立用量層級和授權邊界。

使用 OAuth 範圍和 JWT 宣告進行功能層級存取權控管

雖然上述針對 API1:2019 物件授權異常 所考量的授權方法可解決物件層級的精細存取控制問題，但在函式層級解決粗略存取控制問題同樣重要。要求使用者是否有權要求這個網址路徑？這類政策通常會依使用者角色 (客戶、員工、管理員、內部或第三方開發人員) 定義。

為降低設定錯誤的風險，建議您與安全團隊合作，確保要求使用者的斷言包含在存取權杖中，並使用 OAuth 範圍或 JWT 斷言。

使用條件式流程要求驗證

從基礎層面來說，REST API 呼叫包含以下項目：

  • 端點
  • 資源
  • 動作動詞
  • 任意數量的額外要求屬性，例如查詢參數

這類威脅所描述的攻擊類型，通常是因為 API 要求的篩選條件不足，導致攻擊者能夠執行未經授權的動作，或存取受保護的資源。除了條件邏輯可讓您根據存取權存取權杖或宣告篩選要求外，Apigee 也允許實作根據要求本身的篩選邏輯。

在清楚瞭解並定義 API 產品的業務邏輯 (API 允許的功能) 後，下一步就是透過下列 Apigee 產品功能限制任何超出範圍的要求：

  • 條件式邏輯和 Raise Fault 政策，可在 Proxy 流程設定的任何步驟中限制資源路徑或動詞
  • JSON 和 XML 威脅防護政策，可防範使用格式錯誤的 JSON 或 XML 要求酬載進行的內容攻擊

API6：2019 年大量指派

威脅說明

透過 API 提供給用戶端應用程式的未經過篩選資料，可讓攻擊者透過要求猜測物件屬性，或使用端點命名慣例，找出在儲存在後端的資料物件上執行未經授權的屬性修改或存取作業的線索。

這類威脅會在未過濾的資料 (通常為 JSON 或 XML 格式) 傳送至用戶端時發生，讓攻擊者猜測後端系統的基礎實作細節，以及機密資料元素的屬性名稱。這類攻擊的結果可能會讓攻擊者讀取或操控不當的資料，甚至在最糟的情況下，還可能讓遠端程式碼執行漏洞啟用。

這類威脅通常會涉及以下兩個方面：

  • API 設計觀點。請勿依賴應用程式邏輯執行用戶端資料篩選，因為應用程式可能會遭到攻擊者利用，並被視為可信任的應用程式。請務必設計 API 資料結構，只公開啟用 API 服務所需的必要資料。
  • API 實作角度。實施資料篩選和結構定義驗證，避免意外將機密資料揭露給用戶端應用程式

從 Apigee 產品的角度來看，我們提供多項實用功能，確保 API 的資料篩選導入作業可靠。

OpenAPI 規格篩選政策

您可以使用 OASValidation (OpenAPI 規格驗證) 政策，根據 OpenAPI 3.0 規格 (JSON 或 YAML) 驗證傳入的要求或回應訊息。這項政策允許您：

  1. 建立 OpenAPI 規格 (OAS) 來設計 API
  2. 實作必要的仲介、安全性和快取邏輯，透過 Apigee 安全地公開後端的 API 產品
  3. 根據 OAS 規格定義的資料結構定義驗證傳入的要求，包括basepath、verb、request message policy 和parameters

「SOAP 訊息驗證」政策

SOAP 訊息驗證政策可讓您驗證以 XML 為基礎的要求，方法是根據 XSD 架構驗證 XML 訊息，或根據 WSDL 定義驗證 SOAP 訊息。此外，您可以使用「訊息驗證」政策，確認 JSON 或 XML 訊息酬載是否格式正確，包括在 XML 或 JSON 訊息中驗證下列項目：

  • 只有一個根元素
  • 內容中沒有無效字元
  • 物件和標記正確巢狀
  • 開頭和結尾標記相符

API7：2019 年安全性設定錯誤

威脅說明

安全性設定錯誤通常是因為不安全的預設設定、不完整或臨時設定、開放式雲端儲存空間、設定錯誤的 HTTP 標頭、不必要的 HTTP 方法、允許跨來源資源共享 (CORS)，以及包含機密資訊的冗長錯誤訊息。攻擊者經常會嘗試找出未修補的缺陷、常見的端點或未受保護的檔案和目錄，以便取得未經授權的存取權，或瞭解要攻擊的系統。安全性設定錯誤不僅會洩漏敏感的使用者資料，還可能洩漏系統詳細資料，導致整個伺服器遭到入侵。此外，安全性設定錯誤的漏洞還有其他用途，包括：

  • 傳輸層安全標準 (TLS) 設定錯誤
  • 含有堆疊追蹤的錯誤訊息
  • 未修補的系統
  • 公開的儲存空間或伺服器管理面板

機構可以採取多種步驟，解決及減輕安全設定錯誤的挑戰，包括：

  1. 建立並標準化強化和修補程序
  2. 制定 API 生態系統的治理機制
  3. 限制管理員存取權，並啟用稽核和警示功能

共用流程和流程掛鉤

Apigee 支援共用資料流的概念，可讓 API 開發人員將政策和資源組合成可重複使用的群組。共用流程可擷取可重複使用的功能，有助於確保一致性、縮短開發時間，並更輕鬆地管理程式碼。您可以在個別 API Proxy 中加入共用流程，也可以更進一步將共用流程放入流程掛鉤，為在相同環境中部署的每個 API Proxy 自動執行共用流程邏輯。

API 安全性報表

隨著各機構致力於制定管理架構，Apigee 提供 API 安全性報表功能，協助營運團隊掌握 API 安全性屬性，以便：

  • 確保遵守安全性政策和設定規定
  • 防止機密資料遭內部和外部人員濫用
  • 主動找出、診斷及解決安全性事件

Apigee 安全性報表可為營運團隊提供深入的洞察資料，確保遵循政策和設定要求、保護 API 免於遭受內部和外部濫用行為，並迅速識別及解決安全性事件。

有了安全性報表，安全性管理員就能快速瞭解 API Proxy 的安全性設定方式，以及可能影響 Proxy 安全性的執行階段條件。您可以根據這些資訊調整設定，確保每個 Proxy 都有適當的安全性等級。

API Monitoring

Apigee 提供完整的 API 監控平台，可補足安全性報表功能。API 監控功能可讓機構主動偵測 API 流量和效能問題。Apigee API Monitoring 與 Apigee Edge for Public Cloud 搭配使用，可提供 API 效能即時的內容相關洞察資料，協助快速診斷問題，並促進修正動作，確保業務持續運作。

圖：Apigee API Monitoring 提供多種工具，可用於監控、調查及處理問題。並運用 Google Cloud Platform 提供的一流智慧功能。

Apigee Sense

Apigee Sense 可協助保護 API 免於遭受不必要的請求流量攻擊，包括來自惡意用戶端的攻擊。Apigee Sense 會分析 API 要求流量，找出可能代表不當要求的模式。

透過這項分析，機構可以找出發出不必要要求的用戶端，然後採取行動來允許、封鎖或標記這些要求。透過 Apigee Sense，您可以保護 API 不受以下要求模式的影響：

  • 與人類行為相似的自動化行為
  • 來自相同 IP 的持續嘗試
  • 異常的錯誤率
  • 可疑的用戶端要求
  • 資料檢索
  • 收集關鍵
  • 活動爆發
  • 地理圖案

API8：2019 年注入

威脅說明

將不受信任的資料 (例如 SQL、NoSQL、XML 剖析器、ORM、LDAP、作業系統指令和 JavaScript) 插入 API 要求，可能會導致執行非預期的指令或未經授權存取資料。攻擊者會透過任何可用的注入途徑 (例如直接輸入、參數、整合服務等)，將惡意資料提供給 API，並希望將其傳送至解譯器。攻擊者只要使用漏洞掃描器和模糊測試器檢查原始碼，就能輕鬆發現這些瑕疵。成功注入後，可能會導致資訊外洩，進而影響機密性和資料遺失，在某些情況下，也可能導致 DoS。

為了減少注入錯誤/攻擊，最佳做法包括嚴格定義輸入資料 (例如結構定義、類型、字串模式)、執行輸入驗證、限制檢查，並在執行階段強制執行這些操作。Apigee 平台可透過篩選器驗證傳入的資料，只允許每個輸入參數的有效值。

Apigee Edge 會充當傳入 API 要求的伺服器，檢查酬載結構是否落在可接受的範圍內，這也稱為限制檢查。您可以設定 API 代理程式，讓輸入驗證例行程式轉換輸入內容，移除危險字元序列，並以安全的值取代。

規則運算式防護政策

RegularExpressionProtection 政策會從訊息中擷取資訊 (例如 URI 路徑、查詢參數、標頭、表單參數、變數、XML 酬載或 JSON 酬載)，並根據預先定義的規則評估該內容。如果任何指定的規則運算式評估結果為 true，系統就會將郵件視為威脅並拒收。規則運算式 (簡稱「regex」) 是一組字串，用於指定字串中的模式。規則運算式可讓您以程式輔助方式評估內容模式。舉例來說，您可以使用規則運算式評估電子郵件地址，確保其結構正確。

RegularExpressionProtection 最常見的用途是評估 JSON 和 XML 酬載是否含有惡意內容。

沒有任何規則運算式可以消除所有內容攻擊，因此您應結合多種機制，實施多層防護。本節將說明一些建議的模式，可用來防止存取內容。

您也可以透過 Apigee 平台採用其他幾種方法驗證輸入內容：

驗證內容類型

內容類型是指透過 HTTP 傳輸的檔案內容，並根據兩部分結構進行分類。Apigee 建議您使用條件邏輯驗證要求和回應的內容類型，如下所述。

API 安全性報表

為了協助各機構建立治理架構，Apigee 提供 API 安全性報表功能，讓運作團隊掌握 API 的安全性屬性，以便保護 API，具體功能如下：

  • 確保遵守安全性政策和設定規定。
  • 防止機密資料遭內部和外部人員濫用。
  • 主動識別、診斷及解決安全性事件。

API9：2019 資產管理不當

威脅說明

環境管理和環境區隔不完善，讓攻擊者可存取安全性不足的 API 端點。缺乏治理保護措施也會導致不必要的淘汰資源曝光。

您可以利用 Apigee 成熟的功能管理完整的 API 生命週期，藉此解決這項威脅，並建立全面的治理模式，讓各團隊能夠協同合作，同時在安全性利益相關者和 API 開發人員之間劃分責任。您可以使用下列方式設定及維護邊界和控制項：

組織、環境和修訂版本：透過執行階段情境，確保隔離和安全的升級程序的虛擬和實體防護機制。

角色型存取權控管：只有 API 團隊中必要的人員，才有權管理設定變更和升級程序。

API 說明文件的目標對象管理：在開發人員入口網站中發布 API 後，您可以管理目標對象，限制說明文件的瀏覽權限。

流程掛鉤：您可以強制執行全域政策和模式，並以特權護欄的形式進行管理，這樣 API 開發人員就無法修改這些政策和模式。

安全性報表：安全性權益相關人可查看已發布的 API 及其支援設定的端對端資訊。您可以根據每個發布的 API 端點的風險資料，稽核及評估是否遵循全球安全性政策。

機構組織和環境

Apigee 中的配置構件、使用者和功能，可將範圍限定為特定機構和/或環境。也就是說，平台已預先建構了可圍繞 API 及其支援設定放置的防護措施。

機構：機構是 Apigee 中的頂層租用戶。這可讓您完全區隔流量、設定和使用者。為確保治理最佳做法，您應考慮建立實際工作環境和非實際工作環境的獨立機構。這項做法可有效避免將實際工作資料、使用者和流量與較低層級的環境混淆。

環境：Apigee 中的 API 可透過多個部署狀態進行升級，每個狀態都會連結至執行情境。在升級程序中不會攜帶環境背景，因此不會向無權使用者揭露敏感設定。

修訂版本：修訂版本可讓 API 和個別功能透過環境無縫升級。

角色型存取權控管

為了降低 API9 的風險，安全性利害關係人和 API 開發人員之間的職責必須明確定義並加以區隔。如本文件先前所述，Apigee 提供彈性的角色型存取權控制功能，可讓您為自訂角色指派權限。針對這項特定威脅，您可以將角色範圍設為每個機構、環境或更精細的設定權限，以便限制權限。建議您限制權限，以便透過環境變更 API 的部署狀態，並確保開發人員無法存取或修改全域安全性程式庫 (Flow 鉤子)。這些受限角色可防止對全域安全性政策進行未經授權的變更，這些政策涵蓋舊版和目前已發布的端點。

API 說明文件的目標對象管理

開發人員入口網站是 API 策略成功的關鍵要素，可讓您全面掌握與 API 相關的所有說明文件，包括主機/端點、資源、作業、酬載範本等等。在 Apigee 中，您可以使用 API 產品結構體將 API 分組。API 產品是由屬於相同業務和安全性情境的資源和作業組合所定義 (例如服務方案、業務領域、類別、公司階層等)。

透過 Apigee 的整合式開發人員入口網站，您可以發布 API 產品，並透過管理目標對象限制已發布內容的瀏覽權限。這項功能符合內容區隔策略，符合業務和安全性要求。

流程掛鉤

API 的升級和發布程序必須一律納入安全性法規遵循和認證程序。為提高效率，API 團隊應使用適當的工具建立安全防護措施，確保責任劃分，並維持敏捷的發布週期。

您可以透過 Apigee 的流程掛鉤強制執行全域政策，提升安全性治理職責。這些全域政策可做為特權護欄進行管理，API 開發人員無法修改，因此可確保責任分離，並透過套用預設安全性提升敏捷性，進而為在特定執行環境中部署的所有 API 提供安全性相容性。

圖：您可以透過流程掛鉤和共用流程，在 Apigee 中設定特權護欄。安全性權益相關人負責維護安全性相關的全球政策。這些功能可確保責任分工，並促進敏捷開發生命週期。

安全性報告

安全性稽核旨在評估及測試旨在保護貴機構資料和業務目標的安全性政策。API 是標準化的公用或私用介面，需要透過全面且可稽核的安全控管模型加以保護。

在 Apigee 中，您可以存取專門的安全性報表，確保遵循定義的政策，並讓安全性團隊根據下列項目的完整洞察資訊採取行動：

執行階段流量：提供一站式 API 流量深入分析資訊，包括目標伺服器、虛擬主機、TLS 設定、每個環境的流量變化等。

設定：API Proxy 設定的稽核功能，可讓您瞭解在 API Proxy 層級強制執行的所有政策，以及在機構或 Proxy 層級附加的共用流程執行範圍。

使用者活動：追蹤平台使用者執行的敏感作業。深入分析可疑活動，以便分析可疑活動。

API10：2019 記錄與監控功能不足

威脅說明

記錄、監控和快訊功能不足，可能會導致正在進行的攻擊未能偵測到，因此您應採取策略，針對對業務有影響的重大事件取得洞察資料。

針對 API 的事件和記錄管理策略，請考量下列最佳做法：

  • 記錄管理政策：記錄並強制執行規則，以標準化及控管記錄詳細程度、記錄層級、記錄完整性、集中式存放區等
  • 事件管理政策：保證每個事件都能追溯到來源。此外，事件也應能依重要性和業務影響程度進行分類。
  • 報表和稽核：安全性和作業相關人員應能即時存取及回應記錄和事件。此外，利益相關者可以執行強化循環，根據歷來資料調整偵測模式。

Apigee 提供必要工具，讓您建立全面的事件和記錄管理策略。這些工具包括：

訊息記錄政策：根據 API 流量的流量資料或中繼資料建立記錄串流。您可以利用條件式邏輯和訊息範本，彈性決定串流的詳細程度。

Google Cloud 作業套件：充分利用 Google 提供的監控和記錄工具，並將這些工具整合至可擴充的系統。

服務說明政策：新增對記錄串流的支援，這些串流需要 HTTP 端點才能傳送事件。

Analytics：透過現成和/或自訂報表存取及分析歷來流量中繼資料。根據趨勢建立及管理快訊，並瞭解流量異常狀況。

API 監控：如先前所述，這項工具可提供可根據重要事件觸發的快訊功能。您可以進一步分析流量記錄並採取行動。