OWASP 前 10 大 API 威脅

您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊

本文說明在 Apigee 中，可用來解決 OWASP 發現的安全漏洞的各種方法。如需 Apigee 所記錄的其他方法，請參閱 OWASP 的 2021 年 10 大資安因應措施。

簡介

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

本文件將討論 OWASP 2019 年前 10 大 API 安全性威脅所指出的方法，防止常見的 API 型攻擊。最新清單醒目顯示的重大威脅中，有一項常見主題是驗證和授權控管機制的不當配置方式，例如仰賴篩選用戶端應用程式中 API 要求傳回的資料，方法是使用依賴的用戶端應用程式執行存取權控管強制執行的反模式。

由於 API 生態系統持續快速成長，導致 API 濫用及濫用而導致攻擊者竊取資料，可說是現今最常見的攻擊手法之一。安全性一直是 Apigee 的關鍵優先要務，我們推出進階 API 作業等多項新功能，包括安全性回報和異常偵測功能。不過，正確設計及實作 Apigee 的安全性功能是降低 API 遭到成功攻擊的可能性。

由於您無法控制執行應用程式的平台，因此消費者應用程式應視為不信任或「公開」；假設任何公開應用程式都有可能會遭到入侵，因此不可由信任應用程式強制執行存取權控管機制 (API1、API5)、篩選回應資料 (API6)，或以安全的方式儲存用戶端密鑰 (API2)，例如 API 金鑰或存取權杖。為了查看 2019 年 OWASP 的 10 大熱門作品，

  • 判斷哪種用戶端應用程式會使用您的 API (SPA、行動裝置或瀏覽器)，並設計適當的驗證、授權和安全性模式。
  • 一律使用「公開用戶端」OAuth 或 OpenID Connect 流程 (強烈建議使用 PKCE)
  • 請思考應用程式的商業邏輯、先定義 OpenAPI 規格，然後設計 API Proxy，在 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 充分的正確實作身分標準，不過 Apigee 還有許多額外資源，可以進一步瞭解 OAuth 流程，例如這份電子書、網路廣播和實作範例。

驗證政策

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

流量管理

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

  • 高點陣營政策用於設定 API Proxy 的整體累計平均頻率限制
  • 配額政策：依據應用程式金鑰、開發人員或 API 產品配額定義的配額，為 API Proxy 設定精細的頻率限制
  • 快取政策：依據定義的到期時間來「快取」儲存的存取權杖，並能invalidate快取憑證 (例如：解鎖有效存取權杖的情況)

管理

安全性是一項持續進化的過程，而非「既定的」專案，也是造成安全漏洞設定錯誤的最主要原因之一。定義驗證流程、身分整合模式和與驗證相關的流量管理政策之後，請務必以正確一致的方式實作這類政策。

Apigee 提供多種功能和工具，可協助您確保實作完整性，並避免發生設定錯誤。

角色型存取權控管 (RBAC)

無論是大型企業或小型新創公司，只要確保只有合適的人員和團隊可以存取及修改 API Proxy 設定，就能避免發生設定錯誤錯誤。貴機構中各個領域的團隊都支援 API 計畫。請務必在您的 API 旅程中，授予各團隊執行工作所需的必要權限。

Apigee 提供下列功能，方便您將使用者指派給預先定義的角色或為 API 團隊建立自訂角色，藉此管理角色型存取權。如要安全地擴充 API 計畫，請務必正確定義及管理角色指派作業。另外，您也可以使用聯盟功能來整合現有的公司目錄，減少在 Apigee 中管理第二組管理員憑證的需求。

共用的流程

共用流程可讓您將政策和資源定義為可重複使用的物件，且能跨 API Proxy 實作。舉例來說，您可能已與安全性團隊合作設計多個驗證設計模式，以使用 API 的應用程式類型為依據。API 開發人員不必是識別專家，也能重複使用這項服務，只需要知道正確的共用流程，即可透過流程呼叫政策將其加入現有的 API Proxy 設定。

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

安全性報告

一旦確認只有貴機構中的適當人員能夠修改您的驗證模式，且您已定義共用的驗證流程，那麼您必須確保 API 團隊開發的 API Proxy 以一致的方式使用這些驗證模式。

Apigee 新推出的進階 API 作業功能包含進階安全性報告，可讓營運與安全性團隊輕鬆查看所有 API Proxy 的報表，並著重於遵循安全性政策 (例如共用流程的使用方式)。報表、記錄和快訊是 API 安全性的關鍵要素，詳情請見 API10：記錄功能不足。但就防範失敗的驗證風險而言，報表、記錄和快訊是非常實用的做法，有助於確保遵循以共用流程實作的已定義驗證標準。

作業安全性

當您透過正確的驗證模式和基準流量管理將 API 導入實際工作環境後，您的資安營運團隊也必須能夠監控及回應可疑活動，這類活動通常始於試圖入侵驗證憑證。

Apigee Sense

Apigee Sense 可保護您的 API 避免 API 收到不必要的要求流量，包括來自惡意用戶端的攻擊。Apigee Sense 會分析 API 要求流量，識別可能代表不必要要求的模式。有了這項分析，您就能找出發出不需要要求的用戶端，然後採取行動來允許、封鎖或標記這些要求。Sense 未來將支援自動針對可疑流量啟用 ReCAPTCHA 驗證的功能。

有了 Apigee Sense，您可以防止 API 受到下列要求模式的影響：

  • 結合人類行為的自動化行為
  • 來自相同 IP 的永久嘗試
  • 異常的錯誤率
  • 可疑的用戶端要求
  • 資料檢索
  • 金鑰收集和驗證暴力攻擊
  • 活動爆發
  • 地理模式

Advanced API Ops

雖然 Sense 是專為偵測及回應機器人式威脅而設計，但進階 API 作業同時包含異常偵測和進階快訊定義。

異常偵測的運作原理是將人工智慧 (AI) 和機器學習 (ML) 模型套用至過去的 API 資料。異常偵測機制會即時發出快訊，針對您未曾想進提高工作效率的情境發出快訊，並減少解決 API 問題所需的平均時間 (MTTR)。

Advanced API Ops 以現有的 API 監控快訊機制為基礎，並新增下列進階快訊類型：

  • 總流量快訊。當一段時間內的流量依指定百分比變更時，請發出快訊。舉例來說，您可以讓系統在流量增加 5% 以上一小時時提醒，或是每週減少 10% 以上。
  • 異常狀況快訊。Edge 可以偵測流量和效能問題，讓您不必自行安排。接著，您可以針對這些異常狀況發出警示，
  • TLS 過期快訊。在 TLS 憑證即將過期時發出通知

API3:2019 資料外洩過多

威脅說明

已發布的 API 可能會公開超過所需資料，並依賴用戶端應用程式執行必要的篩選。如果攻擊者直接查詢基礎 API，就能存取機密資料。

Apigee 的「外部」設計原則之一就是「資料剖析」。請與您的使用者體驗設計人員和開發人員合作，僅透過應用程式 UI 中所需的 API 公開資料。後端系統並非專為公開使用模式而建構，因此使用 Apigee 設計 API 的第一項工作時，其中一項就是減少所需資料公開，以便為客戶提供優質的 API 產品。

Apigee 的另一項設計原則為可重複使用。除了安全性考量，如果依賴應用程式來篩選 API 提供的資料，則在您開發應用程式的每個平台中，必須移植篩選邏輯。

從安全性的角度來看，這種威脅會導致將授權強制執行的工作委派給應用程式，但通常是在您無權控管的平台或作業系統上。我們已在 API1 和 API2 中檢驗正確做法，正確實作驗證和授權機制，避免資料存取未經授權而遭到存取。

下列各節將說明如何：

  • 重新編寫對後端服務的要求和回應，盡可能降低資料外洩
  • 實施錯誤處理機制，避免詳細錯誤訊息將機密環境資訊提供給後端服務的相關攻擊者

重新編寫回應和要求

後端系統通常不適合用於公開應用程式或不受信任的公用網路。Apigee Edge 可以保護您的後端避免過度曝露資料，進而讓您部署公用 API 產品。

為達成此目標，Apigee 採用三項關鍵政策：

  • 指派訊息
  • 程式碼呼叫
  • 錯誤處理

指派訊息政策

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

  • 在訊息中新增表單參數、標頭或查詢參數
  • 將現有的屬性從一則訊息複製到其他訊息
  • 移除訊息中的標頭、查詢參數、表單參數和/或訊息酬載
  • 設定訊息中現有屬性的值

使用「指派訊息」功能時，您通常會新增、變更或移除要求或回應的屬性。不過，您也可以按照「建立自訂要求訊息」中的說明，使用「Assign Message」建立自訂要求或回應訊息，並將訊息傳送至其他目標。

使用自訂程式碼執行複雜的重新編寫作業

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

透過程序程式碼，您可以：

  • 建立或操控複雜的主體值，例如要求和回應值。
  • 改寫網址，例如遮蓋目標端點網址。

Apigee Edge 針對支援的語言另外納入政策：JavaScript 政策、Java 呼叫政策和 Python 指令碼政策。

錯誤處理

Apigee 可讓您使用 Promote Fault 類型的政策執行自訂例外狀況處理。「站高錯誤」政策是「Assign Message」政策的變化版本，可讓您產生自訂錯誤回應來回應錯誤狀況。

共用的流程

共用流程可用來強制將錯誤訊息標準化。舉例來說，您可以按照相同的設定政策，從後端偵測特定 HTTP 錯誤代碼，藉此重新編寫錯誤回應以傳回一般錯誤訊息。

API4:2019 缺少資源和頻率限制

威脅說明

如果未實作頻率限制政策，攻擊者可能會因為阻斷服務攻擊，對後端造成負擔。

只要使用下列 Apigee 功能，即可輕鬆解決這個威脅：

  • 配額和尖峰流量防範政策，做為預防性控制來對傳入 API 要求設下流量限制
  • Apigee Sense，動態偵測及回應機器人導向的攻擊
  • 進階 API 監控和快訊功能可做為偵測控制，在發生持續中的分散式阻斷服務攻擊時發出快訊

透過配額和尖峰流量防範政策進行頻率限制

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

  • 暴增防範提供在 API Proxy 層級定義的一般政策，用於限制向後端傳入要求的整體數量
  • 配額是精細的政策工具，可強制執行配額政策，不論是 API Proxy 或 API 產品層級都沒問題

刺釘摔角

Spike 逮捕 政策可防範流量激增。這項政策會使用政策中可定義的累計平均值，藉此限制 API Proxy 處理並傳送至後端的要求數量，避免發生效能延遲和停機問題。

配額

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

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

這項政策比尖峰時期逮捕更精細，且通常應與此政策同時使用。

透過 Apigee Sense 進行機器人偵測

透過 Apigee Sense，您可以根據這些用戶端或出現惡意或可疑行為的位置，明確允許、封鎖或標記來自特定用戶端、IP 範圍或自主系統機構的要求。Apigee Edge 會在 API Proxy 處理要求之前，將這些動作套用至要求。例如，系統會偵測出某個 IP 範圍或特定用戶端出現「暴力猜測」行為，然後加以封鎖或標記。

透過 Advanced API 作業監控功能偵測威脅

使用流量快訊，當環境、Proxy 或區域的流量在一段時間內的特定百分比變更時，系統就會發出通知。當流量大幅偏離預期處理量時 (如同 DDoS 攻擊期間)，這項功能會動態發出快訊。這些快訊可輕鬆傳送至第三方記錄和監控解決方案。

API5:2019 函式層級授權損毀

威脅說明

這個威脅是 API1 的變化，也是授權安全漏洞。有了這種威脅，攻擊者就可以將要求傳送至他們未經授權存取的函式，以便執行動作。舉例來說，如果攻擊者僅在 API 端點未驗證 HTTP 要求動詞時，攻擊者能夠修改或刪除只有 API 端點未驗證 HTTP 要求動詞的資料，方法是將 GET 替換為 PUT 或 DELETE。或者，如未對 API 資源 URI 路徑實作嚴格的存取權控管，可能會導致攻擊者只變更要求中的路徑，進而查看其他使用者的資料。

這類威脅強調使用 Apigee 做為中介服務和抽象層的價值，因為許多後端系統並非針對公開存取而設計。根據預設，可能會提供單一端點來執行多個商業邏輯函式，包括高風險管理功能。

降低這類威脅發生的可能性，概念通常分為以下幾個：

  • 保護的範圍為何？思考您的 API 產品策略，並在使用 符合 REST 樣式的最佳做法設計由 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 產品功能不適用的要求：

  • 條件邏輯和提高錯誤政策，限制 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、要求訊息政策和參數

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 Monitoring 可讓機構主動偵測 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 插入

威脅說明

在 API 要求中插入不信任的資料 (例如 SQL、NoSQL、XML 剖析器、ORM、LDAP、OS 指令和 JavaScript) 可能會導致非預期指令執行，或是未經授權存取資料。攻擊者會透過任何可用的插入向量 (例如直接輸入、參數、整合式服務等)，將惡意資料提供給 API，並預期這些資料會傳送至解譯器。攻擊者透過安全漏洞掃描工具和模糊工具檢查原始碼時，可以輕鬆找出這些安全漏洞。插入成功可能會導致資訊外洩會影響機密性和資料遺失，在某些情況下也可能引發 DoS。

減少插入錯誤/攻擊的最佳做法包括嚴格定義輸入資料，例如結構定義、類型、字串模式、執行輸入驗證、限制檢查並在執行階段強制執行。Apigee 平台允許使用篩選器驗證傳入的資料，僅允許對每個輸入參數使用有效值。

Apigee Edge 可做為傳入 API 要求的伺服器，進行檢查來確保酬載結構落在可接受的範圍內，也稱為「限制檢查」。您可以設定 API Proxy，讓輸入驗證處理常式轉換輸入內容來移除有風險的字元序列，並替換為安全的值。

規則運算式保護政策

RegularExpressionProtection 政策會從訊息中擷取資訊 (例如 URI 路徑、查詢參數、標頭、表單參數、變數、XML Payload 或 JSON Payload)，並根據預先定義的規則運算式評估該內容。如果任何指定的規則運算式評估為 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 部署狀態的權限，並確保開發人員無法存取或修改全域安全性程式庫 (流程掛鉤)。這些有限的角色可以防止全域安全性政策遭到意外變更，且政策涵蓋範圍廣泛，包括舊版和目前已發布的端點。

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

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

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

流量掛勾

API 的宣傳和發布程序必須一律包含安全性法規遵循和認證程序。為了有效，使用適當工具的 API 團隊應能建立防護機制，確保責任分離，同時維持靈活的發布週期。

Apigee 可讓您透過 Flow Hooks 強制執行全球政策，藉此提升安全性管理職責。這些全域政策可視為特殊權限防護機制來管理，API 開發人員無法修改，因此會套用預設安全防護機制，藉此確保責任分隔，同時提升靈活性，進一步確保特定執行環境中部署的所有 API 都符合安全規範。

圖：在 Apigee 中，可透過流程掛鉤和共用流程設定特殊權限的防護機制。 安全性相關人員負責維護與安全性相關的全域政策。這些功能可保證責任分離，並促進靈活的開發生命週期。

安全性報告

安全性稽核旨在評估及測試旨在保護貴機構資料和業務目標的安全性政策。API 是標準化的公開或私人介面，必須受到完善的保護，同時提供可稽核的安全性管理模型。

在 Apigee 中，您可以存取專屬的安全性報告，協助確保遵守既定的政策，並讓資安團隊根據下列全方位的深入分析採取行動：

執行階段流量：一次掌握所有 API 流量的深入分析結果，包括目標伺服器、虛擬主機、TLS 設定、每個環境的流量變更等。

設定：API Proxy 設定的稽核功能，針對在 API Proxy 層級強制執行的所有政策，以及附加於機構或 Proxy 層級的共用流程，提供端對端瀏覽權限。

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

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

威脅說明

記錄、監控和快訊不足導致系統無法偵測進行中的攻擊，因此您應該擬定策略，針對影響業務的重要事件取得深入分析。

API 的事件和記錄管理策略應考慮下列最佳做法：

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

Apigee 提供必要的工具，方便您制定完善的事件與記錄管理策略。這些工具包括：

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

Google 的 Cloud 作業套件：運用立即可用的整合功能，使用 Google 提供的高擴充性監控和記錄工具。

服務呼叫政策：針對需要 HTTP 端點傳送事件的記錄檔串流新增支援功能。

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

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