使用 Apigee 保護應用程式和 API 的最佳做法

Last reviewed 2025-04-01 UTC

本文說明最佳做法，協助您使用 Apigee API 管理平台和下列 Google Cloud 產品，保護應用程式和 API：

本文的目標讀者是管理應用程式基礎架構的 API 架構師、安全架構師和工程主管，他們希望公開安全、可擴充且效能良好的 API。

本文將透過一系列範例架構，說明使用 Apigee API 管理服務的最佳做法。本文也會探討使用網頁應用程式與 API 防護 (WAAP) 的最佳做法。WAAP 是一項全方位的安全防護解決方案，可協助您保護應用程式和 API。

本文假設您已熟悉網路、API 和Google Cloud。

Apigee API 管理平台

Apigee 是用於開發及管理 API 的平台。在服務中新增 Proxy 層後，Apigee 會提供抽象化或外觀，協助您保護後端服務 API。

使用者可以透過 OAuth 2.0 和允許的 IP 位址範圍與應用程式互動。如下圖所示，使用者可以與應用程式互動，資料和服務則會以雙向流程呈現。

使用者與應用程式互動時，以及與後端互動時的安全點。

安全注意事項如下：

  • 使用者：
    • OAuth 2.0
    • IP 位址存取權控管
  • 應用程式
    • API 金鑰
    • OAuth 2.0
    • TLS
  • 開發人員和合作夥伴
    • 單一登入 (SSO)
    • RBAC
  • API
    • OAuth 2.0
    • OpenID Connect
    • 配額
    • 尖峰訊號停止
    • 威脅防護
  • API 團隊
    • IAM RBAC
    • 聯合邏輯
    • 資料遮蓋
    • 稽核記錄
  • 後端
    • 私人網路
    • 雙向傳輸層安全標準 (TLS)
    • IP 位址存取權控管

如上圖所示，您可以在應用程式中使用不同的安全機制，例如 API 金鑰或搭配傳輸層安全標準 (TLS) 的 OAuth 2.0。您也可以新增速率限制、威脅防護政策，並為 API 層的後端設定相互 TLS。

為協助您管理 Apigee 平台中 API 團隊的存取權，Apigee 提供角色型存取權控管 (RBAC) 和聯合登入功能。

建議您使用 Apigee 預設政策保護 API。相關政策如下：

  • 流量管理。協助您設定快取、控管配額、減輕尖峰流量的影響，以及控管 API 流量。
  • 訊息層級保護。可檢查及驗證要求酬載，協助後端防範惡意攻擊者。
  • 安全性。協助您控管 API 存取權。

您可以將一或多項政策附加至 Proxy 層。下表列出各項政策的安全性用途，並依政策類型分類。

政策類型 政策名稱 安全性用途
流量管理 SpikeArrest 政策 對傳送至後端的要求數量套用頻率限制。
流量管理 配額政策 協助貴機構為每個消費者強制執行配額 (API 呼叫次數)。
流量管理 ResponseCache 政策 快取回應，減少對後端的要求數量。
郵件層級防護 OASValidation 政策 根據 OpenAPI 3.0 規格 (JSON 或 YAML) 驗證傳入的要求或回應訊息。
郵件層級防護 SOAPMessageValidation 政策 根據您選擇的結構定義驗證 XML 訊息。根據 WSDL 驗證 SOAP 訊息，並判斷 JSON 和 XML 訊息的格式是否正確。
郵件層級防護 JSONThreatProtection 政策 可讓您指定陣列和字串等 JSON 結構的限制，降低內容層級攻擊的風險。
郵件層級防護 XMLThreatProtection 政策 評估訊息內容，並在剖析訊息前偵測損毀或格式錯誤的訊息，協助您解決 XML 安全漏洞，並降低攻擊風險。
郵件層級防護 RegularExpressionProtection 政策 根據預先定義的規則運算式評估內容，如果運算式為 true，則拒絕內容。
安全性 BasicAuthentication 政策 Base64 會編碼及解碼使用者憑證。
安全性 VerifyAPIKey 政策 在執行階段強制驗證及驗證 API 金鑰。只允許與API 產品相關聯的核准 API 金鑰存取 API。
安全性 OAuthV2 政策 執行 OAuth 2.0 授權類型作業，產生及驗證存取權杖。
安全性 JWS 和 JWT 政策 產生、驗證及解碼 JSON Web Token (JWT) 和 JSON Web Signature (JWS)。
安全性 HMAC 政策 計算及驗證雜湊式訊息驗證碼 (HMAC)，用於驗證和應用程式層級的完整性檢查。
安全性 SAMLAssertion 政策
  • 驗證內送郵件，其中包含經過數位簽章的 SAML 聲明。
  • 為傳出 XML 要求產生 SAML 聲明。
安全性 CORS 政策 可為網路應用程式使用的 API 設定跨源資源共享 (CORS) 標頭。

建議您使用 Cloud Armor，根據 IP 位址和地理位置控管存取權。不過，如果無法使用，可以改用 AccessControl 政策。為協助您保護 Apigee 與後端之間的連線，Apigee 也提供金鑰儲存區管理功能，可讓您設定 TLS 握手的金鑰儲存區和信任儲存區。

您可以使用 Apigee 建立 API 產品，將 API 作業組合在一起，供應用程式開發人員使用。API 產品會將一或多項作業組合在一起。作業會指定 API Proxy 和資源路徑，這些路徑可在該 Proxy 上存取。作業也可以依據 HTTP 方法和配額限制存取權。

您可以使用 API 產品控管 API 存取權。在開發人員應用程式中定義一或多個 API 產品，即可使用 API 金鑰限制 Proxy 的存取權。舉例來說，客戶使用的行動應用程式只能對 /v1/payments 端點執行 POST 作業，在本例中為 https://$DOMAIN/v1/payments。以另一個例子來說，供客服中心人員使用的客服中心應用程式，可以在 /payments 端點 (例如 https://$DOMAIN/v1/payments/1234) 執行 PUT 或 DELETE 等作業，以還原或退還款項。

初始架構

本節說明微服務架構範例，其中服務部署在資料中心和雲端供應商。下列架構最佳做法說明如何疊代及改善初始架構。

微服務架構範例，服務部署於資料中心和雲端服務供應商。

初始架構如下：

  • 付款和帳戶服務會代管在資料中心，而匯款服務則代管在 Google Cloud。
  • 外部應用程式負載平衡器會控制及設定服務的 Ingress。
  • 外部應用程式負載平衡器會將要求轉送至適當的後端或第三方服務，並處理 TLS 交握。

在初始狀態下，範例架構有下列限制：

  • 不太可能擴大規模。
  • 不太可能保護系統免於惡意攻擊
  • 由於這些服務是由機構內的不同團隊開發及維護，因此無法反映一致的安全性和記錄最佳做法。

架構最佳做法

Apigee 可在所有 API 中實作標準安全政策，藉此增加價值，並讓您更輕鬆地向消費者公開服務。本節將探討使用 Apigee 保護 API 的最佳做法。

將 Apigee 當做 Proxy 層使用

下圖顯示初始架構，並新增 Apigee 做為 Proxy (外觀) 層：

Apigee 做為 Proxy 層。

Apigee 會在 Google Cloud 專案中佈建，而執行階段則會在租戶專案中佈建及對等互連，並使用 VPC 網路對等互連。為確保系統安全，您可以透過 Apigee 做為 Proxy 層，使用 Cloud Interconnect 建立與資料中心的直接 (私人) 連線，不必透過網際網路傳送資料。

要求流程如下：

  1. 用戶端會將要求連同應用程式的憑證 (例如金鑰、權杖或憑證) 傳送至外部應用程式負載平衡器。
  2. 負載平衡器會將要求轉送至 Apigee。
  3. Apigee 會處理要求、執行Apigee API 管理所述的安全政策，並允許或拒絕要求。您也可以使用 Apigee，根據用戶端、要求，或用戶端和要求，將要求轉送至不同的後端。
  4. Apigee 會透過內部 IP 位址，直接將要求轉送至 GKE 後端。由於 Apigee 和匯款服務位於對等互連的網路中，因此兩者可透過 RFC 1918 位址 (內部 IP 位址) 通訊。
  5. Apigee 會透過 Cloud Interconnect 將要求傳送至私人資料中心後端。
  6. Apigee 會透過 Apigee NAT IP 位址佈建，將要求傳送至第三方服務。

搭配 Apigee 使用 Cloud Armor 做為 WAF 層

您可以在架構中新增 Cloud Armor，擴大安全防護範圍。Cloud Armor 是 Google Cloud全球負載平衡基礎架構的一部分。這項服務提供網頁應用程式防火牆 (WAF) 功能，有助於防範分散式阻斷服務 (DDoS) 攻擊。此外，這項功能也有助於防範 OWASP 前十大風險，降低應用程式遭受威脅的機率。

您可以在 Cloud Armor 中設定規則和政策，評估用戶端對外部應用程式負載平衡器發出的每個呼叫。您也可以自動設定 Cloud Armor 政策。如要進一步瞭解如何在 Cloud Armor 中設定規則，請參閱 Cloud Armor 操作指南。

下圖顯示同時使用 Apigee 和 Cloud Armor 的範例架構：

採用 Cloud Armor 的架構。

這個架構中的事件流程與本文稍早「將 Apigee 做為 Proxy 層」一節討論的流程類似。要求流程如下：

  1. 用戶端會將要求連同應用程式的憑證 (例如金鑰、權杖或憑證) 傳送至外部應用程式負載平衡器。
  2. 外部應用程式負載平衡器已啟用 Cloud Armor，因此會篩選要求。並強制執行及評估所有已設定的規則和政策。 如果違反任何規則，Cloud Armor 會拒絕要求，並提供錯誤訊息和狀態碼。
  3. 如果沒有違反 Cloud Armor 規則，外部應用程式負載平衡器就會將要求轉送至 Apigee。
  4. Apigee 會處理要求、執行安全政策，並允許或拒絕要求。您也可以根據用戶端、要求，或用戶端和要求，將要求傳送至不同的後端。
  5. Apigee 會透過內部 IP 位址，直接將要求轉送至 GKE 後端。由於 Apigee 和匯款服務位於對等互連的網路中，因此兩者之間的通訊可透過 RFC 1918 位址 (內部 IP 位址) 進行。
  6. Apigee 會透過 Cloud Interconnect 將要求傳送至私人資料中心後端。
  7. Apigee 會透過 Apigee NAT IP 位址佈建，將要求傳送至第三方服務。

使用 WAAP

如要進一步提升安全防護，您也可以使用 WAAP，整合 Cloud Armor、reCAPTCHA 和 Apigee，防範分散式阻斷服務攻擊和機器人。同時提供 WAF 和 API 保護。

如果 API 呼叫來自網站和行動應用程式，建議您在企業使用案例中採用 WAAP。您可以設定應用程式載入 reCAPTCHA 程式庫，產生 reCAPTCHA 權杖，並在提出要求時一併傳送。

下圖顯示工作流程：

WAAP 的要求流程。

上圖中的要求流程如下：

  • (1) 客戶和 API 消費者的所有 HTTP(S) 要求都會傳送至外部應用程式負載平衡器。
  • (2) WAAP 解決方案的第一個聯絡點是 Cloud Armor。
  • (2a) 如果 Cloud Armor 政策未觸發任何規則，系統會將要求傳送至 reCAPTCHA API，評估傳入流量是否為正當要求。
  • (3a) 如果是正當要求，系統會將要求轉送至後端。
  • (2b) 如果要求不合法，Cloud Armor 可以拒絕要求，並向使用者傳送 403 回應代碼。
  • (3b) 針對任何 API 要求，在評估 Cloud Armor OWASP 規則和 DDoS 防護後，系統會將要求轉送至 Apigee，檢查 API 要求是否有效。
  • (4) Apigee 會判斷要求中使用的 API 金鑰或存取權杖是否有效。如果 Apigee 判斷要求不合法，Apigee 可以傳送 403 回應碼。
  • (5) 如果要求合法，Apigee 會將要求轉送至後端。

下圖顯示 WAAP 架構，其中包含 Cloud Armor、reCAPTCHA 和 Apigee，用於處理 API 要求。

WAAP 的要求流程 (搭配 Cloud Armor、reCAPTCHA 和 Apigee)。

上圖中的要求流程如下：

  1. 用戶端會將要求連同應用程式的憑證 (例如金鑰、權杖或憑證) 傳送至外部應用程式負載平衡器。
  2. 由於外部應用程式負載平衡器已啟用 Cloud Armor，因此 Cloud Armor 會選取要求。並強制執行及評估所有已設定的規則和政策。如果違反任何規則，Cloud Armor 會拒絕要求，並傳回錯誤訊息和狀態碼。
  3. 對於網站呼叫 (例如登入頁面的表單提交)，Cloud Armor 會與 reCAPTCHA 整合。reCAPTCHA 會評估傳入流量，並為合法流量新增風險分數。對於非正當流量，Cloud Armor 可以拒絕要求。
  4. 如果沒有 Cloud Armor 規則違規事項，外部應用程式負載平衡器會將 API 要求轉送至 Apigee。
  5. Apigee 會處理要求、執行安全政策，並允許或拒絕要求。您也可以使用 Apigee，根據用戶端、要求或兩者，將要求傳送至不同的後端。
  6. Apigee 會透過內部 IP 位址，直接將要求轉送至 GKE 後端。由於 Apigee 和匯款服務都位於對等互連的網路中，因此兩者之間的通訊可以透過 RFC 1918 位址 (即內部 IP 位址) 進行。
  7. Apigee 會透過 Cloud Interconnect 將要求傳送至私人資料中心後端。
  8. Apigee 會透過 Apigee NAT IP 位址佈建，將要求傳送至第三方服務。

使用 Cloud CDN 進行快取

Cloud CDN 使用 Google 全球網路，從較靠近使用者的位置提供內容，藉此縮短網站和應用程式的回應時間。Cloud CDN 也提供快取功能，可從快取傳回回應，協助您保護後端。在 Google 前端 (GFE) 快取經常存取的資料，盡可能將資料儲存在最靠近使用者的位置，因此可將存取時間縮到最短。

Cloud CDN 也能協助機構順利處理季節性流量高峰，例如節慶或開學季期間的流量高峰。這種快取方式有助於提升生態系統的可靠性和使用者體驗。此外，這項功能也有助於減少網路伺服器負載、運算和網路用量。如要導入這個架構，您必須在為 Apigee 流量提供服務的負載平衡器上啟用 Cloud CDN。

您可以使用本文討論的任何選項搭配 Cloud CDN。下圖顯示 WAAP 的初始範例架構，並新增了 Cloud CDN。

使用 Cloud CDN 的要求流程。

上圖顯示的要求流程如下：

  1. 用戶端會使用 reCAPTCHA 程式庫取得權杖，並將要求連同應用程式的憑證 (例如金鑰、權杖或憑證) 傳送至外部應用程式負載平衡器。
  2. Cloud CDN 會使用快取金鑰檢查快取，如果快取命中為 true，則會傳回回應。
  3. 如果快取命中為 false，由於外部應用程式負載平衡器已啟用 Cloud Armor，因此 Cloud Armor 會篩選要求。Cloud Armor 會強制執行並評估所有已設定的規則和政策。如果違反任何規則，系統會拒絕要求，並傳回錯誤訊息和狀態碼。
  4. Cloud Armor 整合了 reCAPTCHA，可評估正當的傳入流量並提供風險分數。對於非正當流量，Cloud Armor 可以拒絕要求。
  5. 如果沒有違反 Cloud Armor 規則，外部應用程式負載平衡器就會將要求轉送至 Apigee。
  6. Apigee 會處理要求、執行Apigee API 管理所述的安全政策，並允許或拒絕要求。您也可以根據用戶端、要求，或用戶端和要求，將要求轉送至不同的後端。
  7. Apigee 會透過內部 IP 位址，直接將要求轉送至 GKE 後端。由於 Apigee 和匯款服務位於對等互連的網路中，因此兩者可透過 RFC 1918 位址 (內部 IP 位址) 通訊。
  8. Apigee 會透過 Cloud Interconnect 將要求傳送至私人資料中心後端。
  9. Apigee 會透過 Apigee NAT IP 位址佈建，將要求傳送至第三方服務。
  10. 當回應回流至用戶端時，Cloud CDN 會快取該回應，以便在日後呼叫時從快取傳回回應。

後續步驟