本文說明最佳做法，協助您運用 Apigee API 管理平台和下列 Google Cloud 產品保護應用程式和 API：
本文適用對象為 API 架構師、安全架構師和工程師主管，他們負責管理應用程式基礎架構，並希望提供安全、可擴充且效能良好的 API。
本文件會使用一系列架構範例，說明使用 Apigee API 管理服務的最佳做法。本文件也將討論使用網頁應用程式與 API 防護 (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 金鑰或 OAuth 2.0 搭配傳輸層安全標準 (TLS)。您也可以在 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 政策 |
|
| 安全性 | CORS 政策 | 可讓您為網路應用程式使用的 API 設定跨來源資源共享 (CORS) 標頭。 |
建議您使用 Google Cloud Armor 進行 IP 位址和地理位置存取權控管。不過，如果無法使用此方法，您可以使用 AccessControl 政策。為協助您保護從 Apigee 到後端的連線，Apigee 也提供金鑰庫管理功能，讓您為 TLS 握手設定金鑰庫和信任存放區。
您可以使用 Apigee 建立 API 產品，讓您將 API 作業整合在一起，並提供給應用程式開發人員使用。API 產品會將一或多項作業彙整在一起。作業會指定 API Proxy 和可透過該 Proxy 存取的資源路徑。作業也可以依據 HTTP 方法和配額限制存取權。
您可以使用 API 產品控管 API 存取權。在開發人員應用程式中定義一或多項 API 產品，即可使用 API 金鑰限制 Proxy 的存取權。舉例來說，客戶使用的行動應用程式只能在 /v1/payments 端點 (在本例中為 https://$DOMAIN/v1/payments) 執行 POST 作業。舉另一個例子來說，呼叫中心應用程式可讓呼叫中心人員執行 PUT 或 DELETE 等作業，針對 /payments 端點 (例如 https://$DOMAIN/v1/payments/1234) 進行付款撤銷或退款。
初始架構
本節將說明微服務架構範例，其中的服務已部署在資料中心和雲端服務供應商中。以下架構最佳做法說明如何重複執行並改善初始架構。
初始架構如下：
- 付款和帳戶服務會在資料中心代管，而匯款服務則會在 Google Cloud代管。
- 外部應用程式負載平衡器會控制及設定服務的輸入端。
- 外部應用程式負載平衡器會將要求轉送至適當的後端或第三方服務，並處理 TLS 握手。
在初始狀態下，範例架構有以下限制：
- 不太可能擴大規模。
- 系統很可能無法防範惡意攻擊
- 這些服務是由組織內不同團隊開發及維護，因此無法反映出安全性和記錄的一致最佳做法。
架構最佳做法
Apigee 可在所有 API 中導入一組標準安全政策，為您提供更多價值，並讓您更輕鬆地向消費者公開服務。本節將說明使用 Apigee 保護 API 的最佳做法。
使用 Apigee 做為 Proxy 層
下圖顯示初始架構，其中加入了 Apigee 做為 Proxy (外觀) 層：
Apigee 會在 Google Cloud 專案中佈建，而執行階段會使用 VPC 網路對等互連在租用戶專案中佈建及對等互連。為確保系統安全，您可以使用 Apigee 做為 Proxy 層，透過 Cloud Interconnect 建立與資料中心的直接 (私人) 連線，而非透過網際網路傳送資料。
要求流程如下：
- 用戶端會將要求傳送至外部應用程式負載平衡器，並附上應用程式的憑證，例如金鑰、權杖或憑證。
- 負載平衡器會將要求轉送至 Apigee。
- Apigee 會處理要求，並依照「Apigee API 管理」一文所述執行安全性政策，然後允許或拒絕要求。Apigee 也可用於根據用戶端、要求或用戶端和要求，將要求轉送至不同的後端。
- Apigee 會直接透過內部 IP 位址將要求轉送至 GKE 後端。Apigee 和匯款服務之間的通訊可透過 RFC 1918 位址 (內部 IP 位址) 進行，因為兩者位於對等網路中。
- Apigee 會透過 Cloud Interconnect 將要求傳送至私人資料中心後端。
- Apigee 會透過 Apigee NAT IP 位址佈建，將要求傳送至第三方服務。
搭配使用 Google Cloud Armor 和 Apigee，做為網路應用程式防火牆層
您可以將 Google Cloud Armor 新增至架構，以擴大安全範圍。Google Cloud Armor 是 Google Cloud的全球負載平衡基礎架構之一。提供網頁應用程式防火牆 (WAF) 功能，有助於防範分散式阻斷服務 (DDoS) 攻擊。這項功能還可協助您降低應用程式遭受 OWASP 前十大所列風險的威脅。
您可以在 Google Cloud Armor 中設定規則和政策，評估用戶端對外部應用程式負載平衡器發出的每個呼叫。您也可以自動設定 Google Cloud Armor 政策。如要進一步瞭解如何在 Google Cloud Armor 中設定規則，請參閱 Google Cloud Armor 操作說明手冊。
下圖顯示範例架構，其中包含 Apigee 和 Google Cloud Armor：
這個架構中的事件流程與前文「使用 Apigee 做為 Proxy 層」一節所述的事件流程類似。要求流程如下：
- 用戶端會將要求傳送至外部應用程式負載平衡器，並附上應用程式的憑證，例如金鑰、權杖或憑證。
- 由於外部應用程式負載平衡器已啟用，因此 Google Cloud Armor 會篩選要求。並強制執行及評估所有已設定的規則和政策。如果違反任何規則，Google Cloud Armor 會拒絕要求，並傳回錯誤訊息和狀態碼。
- 如果沒有違反 Google Cloud Armor 規則，外部應用程式負載平衡器會將要求轉送至 Apigee。
- Apigee 會處理要求、執行安全性政策，並允許或拒絕要求。您也可以使用此方法，根據用戶端、要求或用戶端和要求，將要求轉送至不同的後端。
- Apigee 會直接透過內部 IP 位址將要求轉送至 GKE 後端。Apigee 和匯款服務之間的通訊可透過 RFC 1918 位址 (內部 IP 位址) 進行，因為這兩者位於對等網路中。
- Apigee 會透過 Cloud Interconnect 將要求傳送至私人資料中心後端。
- Apigee 會透過 Apigee NAT IP 位址佈建，將要求傳送至第三方服務。
使用 WAAP
如要進一步強化安全性設定檔，您也可以使用 WAAP，將 Google Cloud Armor、reCAPTCHA 和 Apigee 整合在一起，協助保護系統免於遭受分散式阻斷服務攻擊和機器人攻擊。也提供 WAF 和 API 防護。
如果是透過網站和行動應用程式發出 API 呼叫的企業用途，我們建議使用 WAAP。您可以設定應用程式載入 reCAPTCHA 程式庫，產生 reCAPTCHA 權杖，並在提出要求時一併傳送。
下圖顯示工作流程：
上圖中的要求流程如下：
- (1) 客戶和 API 使用者傳送的所有 HTTP(S) 要求都會傳送至外部應用程式負載平衡器。
- (2) WAAP 解決方案的第一個聯絡窗口是 Google Cloud Armor。
- (2a) 如果 Google Cloud Armor 政策未觸發任何這些規則，系統會傳送要求給 reCAPTCHA API，評估傳入流量是否為合法要求。
- (3a) 如果是合法要求，系統會將要求轉送至後端。
- (2b) 如果要求不合法，Google Cloud Armor 可以拒絕要求，並傳送 403 回應代碼給使用者。
- (3b) 針對任何 API 要求，在 Google Cloud Armor OWASP 規則和分散式阻斷服務防護機制經過評估後，要求會轉送至 Apigee，以便檢查 API 要求的有效性。
- (4) Apigee 會判斷要求中使用的 API 金鑰或存取權杖是否有效。如果 Apigee 判定要求不合法，就會傳送 403 回應碼。
- (5) 如果要求合法，Apigee 會將要求轉送至後端。
下圖顯示 WAAP 的架構，其中包含 Google Cloud Armor、reCAPTCHA 和 Apigee，可用於 API 要求。
上圖中的要求流程如下：
- 用戶端會將要求傳送至外部應用程式負載平衡器，並附上應用程式的憑證，例如金鑰、權杖或憑證。
- 由於外部應用程式負載平衡器已啟用 Google Cloud Armor，因此 Google Cloud Armor 會選取要求。並強制執行及評估所有已設定的規則和政策。如果違反任何規則，Google Cloud Armor 會拒絕要求，並傳回錯誤訊息和狀態碼。
- 針對網站呼叫 (例如登入頁面的表單提交)，Google Cloud Armor 會與 reCAPTCHA 整合。reCAPTCHA 會評估傳入流量，並為合法流量新增風險分數。如果流量不合法，Google Cloud Armor 可以拒絕要求。
- 如果沒有違反 Google Cloud Armor 規則，外部應用程式負載平衡器會將 API 要求轉送至 Apigee。
- Apigee 會處理要求、執行安全性政策，並允許或拒絕要求。Apigee 也可用於根據用戶端、要求，或用戶端和要求，將要求導向至不同的後端。
- Apigee 會直接透過內部 IP 位址將要求轉送至 GKE 後端。Apigee 和匯款服務之間的通訊可以透過 RFC 1918 位址 (內部 IP 位址) 進行，因為兩者都位於對等網路中。
- Apigee 會透過 Cloud Interconnect 將要求傳送至私人資料中心後端。
- Apigee 會透過 Apigee NAT IP 位址佈建，將要求傳送至第三方服務。
使用 Cloud CDN 進行快取
Cloud CDN 會使用 Google 的全球網路，就近提供內容給使用者，進而加快網站和應用程式的回應時間。Cloud CDN 也提供快取功能，可透過從快取返回回應來保護後端。在 Google 網路邊緣的 Google 前端 (GFE) 快取經常存取的資料，盡可能將資料儲存在最靠近使用者的位置，因此可將存取時間縮到最短。
Cloud CDN 還可協助機構順利因應季節性流量尖峰，例如在節慶或開學季節期間可能出現的尖峰。這種快取方法有助於改善生態系統的可靠性和使用者體驗。這麼做也可以盡量減少網路伺服器負載、運算和網路用量。如要實作這個架構，您必須在負責提供 Apigee 流量的負載平衡器上啟用 Cloud CDN。
Cloud CDN 可搭配本文所述的任何選項使用。下圖顯示 WAAP 的初始架構範例，並加入 Cloud CDN。
上圖顯示的要求流程如下：
- 用戶端會使用 reCAPTCHA 程式庫取得權杖，並將要求傳送至外部應用程式負載平衡器，並附上應用程式的憑證，例如金鑰、權杖或憑證。
- Cloud CDN 會使用快取索引鍵檢查快取內容，並在快取命中為 true 時傳回回應。
- 如果快取命中為否，Google Cloud Armor 會篩選要求，因為外部應用程式負載平衡器已啟用 Google Cloud Armor。Google Cloud Armor 會強制執行並評估所有已設定的規則和政策。如果違反任何規則，系統會拒絕要求，並傳回錯誤訊息和狀態碼。
- Google Cloud Armor 已整合 reCAPTCHA，可透過風險分數評估合法的傳入流量。如果流量不合法，Google Cloud Armor 可以拒絕要求。
- 如果沒有違反 Google Cloud Armor 規則，外部應用程式負載平衡器會將要求轉送至 Apigee。
- Apigee 會處理要求，並依照「Apigee API 管理」一文所述執行安全性政策，然後允許或拒絕要求。您也可以使用此方法，根據用戶端、要求或用戶端和要求，將要求轉送至不同的後端。
- Apigee 會直接透過內部 IP 位址將要求轉送至 GKE 後端。Apigee 和匯款服務之間的通訊可透過 RFC 1918 位址 (內部 IP 位址) 進行，因為兩者位於對等網路中。
- Apigee 會透過 Cloud Interconnect 將要求傳送至私人資料中心後端。
- Apigee 會透過 Apigee NAT IP 位址佈建，將要求傳送至第三方服務。
- 回應流回用戶端時，Cloud CDN 會將其快取，以便在日後的呼叫中傳回快取中的回應。
後續步驟
- 進一步瞭解 Apigee 佈建選項。
- 請參閱這篇文章，瞭解如何透過 Apigee 和 Google Cloud Armor 實現多層 API 安全性。
- 瞭解如何透過 Apigee X 和 Cloud CDN 提供高效能的全球 API。
- 在 Apigee 社群中閱讀文章和提問。
- 前往 GitHub 探索 Apigee 存放區。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 雲端架構中心。