混合式雲端和多雲端安全網路架構模式

Last reviewed 2025-01-23 UTC

這份文件是該組三份文件中的第三份。本文將探討混合雲和多雲端網路架構模式。本單元旨在探索可用於混合式雲端和多雲端架構的常見安全網路架構模式。本文說明這些網路模式最適合哪些情境，並提供使用 Google Cloud進行實作的最佳做法。

混合式雲端和多雲端架構模式的文件集包含下列部分：

  • 建構混合式和多雲端架構： 說明如何規劃策略，使用 Google Cloud建構混合式和多雲端設定。
  • 混合式雲端和多雲端架構模式：討論可採用的常見架構模式，做為混合式雲端和多雲端策略的一部分。
  • 混合式雲端和多雲端安全網路架構模式：從網路角度討論混合式雲端和多雲端網路架構模式 (本文)。

如要順利完成任何混合式雲端和多雲端架構，關鍵在於透過安全可靠的方式將私人運算環境連線至 Google Cloud 。為混合式雲端和多雲端設定選擇的混合式網路連線和雲端網路架構模式，必須滿足企業工作負載的獨特需求。此外，也必須符合您打算套用的架構模式。雖然您可能需要調整每個設計，但仍可將通用的模式做為藍圖使用。

本文中的網路架構模式不應視為登陸區設計 Google Cloud的替代方案。您應設計及部署所選架構模式，做為整體 Google Cloud 登陸區設計的一部分，涵蓋下列領域：

  • 身分
  • 資源管理
  • 安全性
  • 網路
  • 監控

不同的應用程式可以使用不同的網路架構模式，這些模式會納入登陸區架構。在多雲設定中，您應在所有環境中維持登陸區設計的一致性。

本系列包含下列頁面：

貢獻者

作者：Marwan Al Shawi | 合作夥伴客戶工程師

其他貢獻者：

架構模式

本系列文件討論的網路架構模式，是根據應用程式在 Google Cloud 和其他環境 (地端部署、其他雲端或兩者) 之間所需的通訊模式設計而成。

這些模式應納入整體機構登陸區架構，其中可包含多種網路模式，以因應不同應用程式的特定通訊和安全性需求。

本系列文件也會討論可搭配各架構模式使用的不同設計變化。下列網路模式可協助您滿足應用程式的通訊和安全需求：

鏡像圖案

鏡像模式是以將特定現有環境的設計複製到新環境為基礎。因此，這個模式主要適用於遵循環境混合模式的架構。在該模式中，您會在一個環境中執行開發和測試工作負載，同時在另一個環境中執行測試環境和實際運作工作負載。

鏡像模式假設測試和實際運作工作負載不應直接互相通訊，但您應能透過一致的方式來管理及部署這兩組工作負載。

如果使用這個模式，請以符合下列需求的方式連結兩個運算環境：

  • 持續整合/持續推送軟體更新 (CI/CD) 可在所有運算環境或特定環境中部署及管理工作負載。
  • 監控、設定管理和其他管理系統應可在不同運算環境中運作。
  • 工作負載無法跨運算環境直接通訊。如有必要，通訊必須以精細且受控的方式進行。

架構

下方的架構圖顯示此模式的概略參考架構，支援 CI/CD、監控、設定管理、其他管理系統和工作負載通訊：

資料會在 Google Cloud 的 CI/CD 和管理 VPC，以及內部部署的實際工作環境之間流動。資料也會在 CI/CD-VPC 與 Google Cloud內的開發和測試環境之間流動。

上圖的架構說明如下：

  • 工作負載會根據功能環境 (開發、測試、CI/CD 和管理工具) 分散到 Google Cloud 側的獨立 VPC。
  • 共用虛擬私有雲用於開發和測試工作負載。另一個 VPC 則用於 CI/CD 和管理工具。使用共用虛擬私有雲：
    • 每個環境和服務專案的應用程式，都由不同的團隊管理。
    • 主專案會管理及控管開發和測試環境之間的網路通訊和安全控管，以及與虛擬私有雲外部的通訊。
  • CI/CD VPC 已連線至在私人運算環境中執行實際運作工作負載的網路。
  • 防火牆規則只允許允許的流量。
    • 您也可以搭配入侵預防服務 (IPS) 使用 Cloud Next Generation Firewall Enterprise，實作深層封包檢查來防範威脅，不必變更設計或路由。Cloud Next Generation Firewall Enterprise 會建立 Google 管理的區域防火牆端點，並使用封包攔截技術，以透明方式檢查工作負載是否含有已設定的威脅特徵碼。同時防範工作負載遭受威脅。
  • 使用內部 IP 位址，在對等互連的虛擬私有雲之間進行通訊。
    • 這個模式中的對等互連功能，可讓 CI/CD 和管理系統部署及管理開發和測試工作負載。
  • 請考慮採用這些一般最佳做法。

您可以使用其中一種混合式雲端和多雲端網路連線選項，建立符合業務和應用程式需求的 CI/CD 連線。這項連線可在不同運算環境之間提供私人網路可連線性，方便您部署及管理實際運作工作負載。所有環境都應具備不重疊的 RFC 1918 IP 位址空間。

如果開發和測試環境中的執行個體需要存取網際網路，請考慮下列選項：

  • 您可以將 Cloud NAT 部署到同一個共用 VPC 主專案網路。部署到同一個共用 VPC 主專案網路，有助於避免從網際網路直接存取這些執行個體。
  • 對於輸出網路流量，您可以使用 Secure Web Proxy。 Proxy 具有多項優點。

如要進一步瞭解 Google Cloud 工具和功能，協助您在混合式和多雲端環境中建構、測試及部署 Google Cloud ，請參閱「DevOps and CI/CD on Google Cloud explained」網誌。

變化版本

為滿足不同的設計需求，同時兼顧所有通訊需求，鏡像架構模式提供下列選項，詳情請參閱以下各節：

每個環境都有專屬的共用虛擬私有雲

如果選擇每個環境使用一個共用虛擬私有雲，就能在各個環境中區隔應用程式或服務層級，包括持續整合/持續推送軟體更新和管理工具，以符合特定機構的安全防護需求。這些需求會限制不同服務的通訊、管理網域和存取權控管，而這些服務也需要由不同團隊管理。

這種設計可提供不同環境之間的網路和專案層級隔離，進而實現分離，並支援更精細的通訊和身分與存取權管理 (IAM) 存取權控管。

從管理和作業的角度來看，這個設計可彈性管理不同團隊建立的應用程式和工作負載，並依據環境和服務專案進行管理。網路作業團隊可根據下列可能結構，佈建及管理虛擬私有雲網路及其安全功能：

  • 一個團隊管理所有環境中的所有主機專案。
  • 不同團隊會在各自的環境中管理主專案。

管理託管專案的決策應以團隊架構、安全作業和各團隊的存取權需求為依據。您可以將這個設計變化套用至每個環境登陸區設計選項的共用虛擬私有雲網路。不過，您需要考量鏡像模式的通訊需求，定義不同環境之間允許的通訊，包括透過混合式網路進行的通訊。

您也可以為每個主要環境佈建共用虛擬私有雲網路，如下圖所示：

Google Cloud 中的 VPC 對等互連會在開發和測試環境，以及 CI/CD 和管理子網路之間共用資料。子網路會在 Google Cloud 和內部部署環境之間共用資料。

集中式應用程式層防火牆

在某些情況下，安全防護需求可能會要求考慮應用程式層 (第 7 層) 和深層封包檢查，並採用超出 Cloud Next Generation Firewall 功能範圍的進階防火牆機制。如要符合貴機構的安全需求和標準，可以使用網路虛擬設備 (NVA) 中代管的 NGFW 設備。有幾家 Google Cloud 安全合作夥伴提供適合這項工作的選項。

如下圖所示，您可以使用多個網路介面，將 NVA 放在虛擬私有雲和私人運算環境之間的網路路徑中。

Google Cloud 中的 VPC 對等互連會在開發和測試環境，以及 CI/CD 和管理子網路之間共用資料。子網路會透過傳輸 VPC 網路，在 Google Cloud 和地端部署環境之間共用資料。

如以下圖表所示，這個設計也可以搭配多個共用虛擬私有雲使用。

Google Cloud 中的 VPC 對等互連會在開發和測試環境，以及 CI/CD 和管理子網路之間共用資料。子網路會使用 NVA，透過傳輸虛擬私有雲網路在 Google Cloud 和內部部署環境之間共用資料。

這個設計中的 NVA 會做為周邊安全層。此外，這項功能也是啟用內嵌流量檢查和強制執行嚴格存取控制政策的基礎。

如要制定強大的多層安全策略，包括虛擬私有雲防火牆規則和入侵防禦服務功能，請進一步檢查東西向和南北向流量，並控管安全性。

中樞輻型拓撲

另一種可能的設計變化是針對開發作業和不同測試階段，個別使用 VPC (包括共用 VPC)。在這個變體中，如以下圖表所示，所有階段環境都會在軸輻式架構中，與 CI/CD 和管理虛擬私有雲建立連線。如必須在每個環境中區隔管理網域和函式，請使用這個選項。中樞輻射型通訊模型可協助滿足下列需求：

  • 應用程式需要存取一組常見服務，例如監控、設定管理工具、持續整合/持續推送軟體更新或驗證。
  • 必須透過中樞，以集中方式對傳入和傳出流量套用一組通用的安全性政策。

如要進一步瞭解中樞輻射型設計選項，請參閱「具有集中式裝置的中樞輻射型拓撲」 和「沒有集中式裝置的中樞輻射型拓撲」。

開發和測試環境會與中樞 VPC CI/CD 和管理 VPC 共用資料，並與內部部署環境共用資料。

如上圖所示，虛擬私有雲間通訊和混合式連線都會通過中樞虛擬私有雲。在這個模式中，您可以控管及限制中樞虛擬私有雲的通訊，以符合連線需求。

在軸輻式網路架構中，以下是 Google Cloud的主要連線選項 (介於輻 VPC 和中樞 VPC 之間)：

  • 虛擬私有雲網路對等互連
  • VPN
  • 使用網路虛擬設備 (NVA)

如要進一步瞭解設計時應考慮的選項，請參閱輻射型網路架構。 在輪輻和中樞 VPC 之間選取 VPN 而非 VPC 對等互連時，主要影響因素是是否需要流量遞移性。流量遞移性是指輪輻的流量可透過中樞抵達其他輪輻。

微服務零信任分散式架構

混合雲和多雲端架構可能需要多個叢集，才能達成技術和業務目標，包括將正式環境與開發和測試環境分開。因此，網路周邊安全控管機制非常重要，尤其是在必須遵守特定安全規定的情況下。

除了支援目前雲端優先分散式微服務架構的安全需求，您也應考慮零信任分散式架構。微服務零信任分散式架構可支援您的微服務架構，並強制執行微服務層級的安全政策、驗證及工作負載身分。信任是以身分為基礎，且會針對每項服務強制執行。

使用分散式 Proxy 架構 (例如服務網格) 時，服務可以有效驗證呼叫端，並為每個要求實作精細的存取權控管政策，打造更安全且可擴充的微服務環境。Cloud Service Mesh 可讓您靈活地建構共通網格，跨越Google Cloud 和地端部署項目。服務網格會使用授權政策，協助保護服務之間的通訊。

您也可以將 Apigee Adapter for Envoy 納入這個架構。這是在 Kubernetes 叢集中部署的輕量級 Apigee API 閘道。Apigee Adapter for Envoy 是開放原始碼的邊緣和服務 Proxy，專為雲端優先的應用程式設計。

Google Cloud 服務與內部部署環境之間的資料流，會透過分散式 Proxy 架構傳輸。

如要進一步瞭解這個主題，請參閱下列文章：

鏡像模式最佳做法

  • 部署或重新設定實際運作工作環境所需的 CI/CD 系統必須具備高可用性，也就是說，所有架構元件都必須經過設計，才能提供預期的系統可用性。詳情請參閱Google Cloud 基礎架構可靠性。
  • 為避免重複程序 (例如程式碼更新) 發生設定錯誤，自動化是標準化建構、測試和部署作業的必要條件。
  • 在這個設計中整合集中式 NVA 時，可能需要納入多個區隔，並搭配不同層級的安全存取控制項。
  • 設計包含 NVA 的解決方案時，請務必考量 NVA 的高可用性 (HA)，避免單一故障點阻斷所有通訊。請按照 NVA 供應商提供的高可用性和備援設計與實作指南操作。
  • 透過虛擬私有雲對等互連或 VPN，將內部部署 IP 路徑匯出至開發和測試虛擬私有雲時，您可以限制開發和測試環境與內部部署環境之間的網路可連線性。詳情請參閱「虛擬私有雲網路對等互連自訂路徑交換」。
  • 對於需要存取 Google API 的工作負載，您可以使用 VPC 網路中的 Private Service Connect 端點公開 Google API。詳情請參閱本系列文章中的「Gated ingress」。
  • 請參閱混合式雲端和多雲端網路架構模式的一般最佳做法。

網狀圖案

網狀模式是以建立混合式網路架構為基礎。該架構涵蓋多個運算環境。在這些環境中，所有系統都能彼此通訊，且不受限於根據應用程式安全需求進行的單向通訊。這個網路模式主要適用於分層混合式、分區多雲端或爆發式架構。這也適用於業務持續性設計，可在 Google Cloud中佈建災難復原 (DR) 環境。在所有情況下，您都必須以符合下列通訊需求的方式連結運算環境：

  • 工作負載可以使用私人 RFC 1918 IP 位址，跨越環境界限來互相通訊。
  • 雙方皆可發起通訊。通訊模型的具體細節可能因應用程式和安全性需求而異，例如後續設計選項中討論的通訊模型。
  • 您使用的防火牆規則必須允許特定 IP 位址來源和目的地之間的流量，具體取決於模式設計的應用程式需求。理想情況下，您可以使用多層式安全防護方法，以精細的方式限制運算環境之間和運算環境內部的流量。

架構

下圖說明網狀模式的高階參考架構。

在混合式網路架構中，資料會從 Google Cloud 的兩個子網路流向內部部署環境中的工作負載。

  • 所有環境都應使用不重疊的 RFC 1918 IP 位址空間。
  • 在 Google Cloud 端，您可以將工作負載部署至單一或多個共用虛擬私有雲，或非共用虛擬私有雲。如需這個模式的其他可能設計選項，請參閱下方的設計變化。所選虛擬私有雲結構應與貴機構的專案和資源階層結構設計一致。
  • 虛擬私有雲網路 Google Cloud 會延伸至其他運算環境。這些環境可以是內部部署環境，也可以是其他雲端環境。使用符合業務和應用程式需求的混合式和多雲端網路連線選項。

  • 將通訊限制為僅允許來源和目的地的 IP 位址。使用下列任一功能或組合：

變化版本

網狀架構模式可與其他方法搭配使用，以滿足不同的設計需求，同時仍考量模式的通訊需求。以下各節將說明模式選項：

每個環境一個虛擬私有雲

考慮為每個環境使用一個虛擬私有雲的常見原因如下：

  • 雲端環境需要虛擬私有雲網路和資源的網路層級分離，以符合貴機構的資源階層設計。如果需要區隔管理網域，也可以為每個環境搭配使用不同的專案。
    • 如要集中管理一般網路中的網路資源，並在不同環境之間提供網路隔離，請為 Google Cloud中的每個環境 (例如開發、測試和生產環境) 使用共用虛擬私有雲。
  • 可能需要超出單一虛擬私有雲或專案的虛擬私有雲配額。

如下圖所示，每個環境一個虛擬私有雲的設計，可讓每個虛擬私有雲直接與地端環境或其他雲端環境整合，方法是使用 VPN 或具有多個 VLAN 連結的 Cloud Interconnect。

在混合式網路架構中，每個環境都有一個虛擬私有雲，資料會從 Google Cloud 的兩個子網路，流向內部部署環境中的工作負載。

上圖顯示的模式可套用至登陸區軸輻式網路拓撲。在該拓撲中，單一 (或多個) 混合式連線可與所有輪輻虛擬私有雲共用。方法是使用傳輸虛擬私有雲，終止混合式連線和其他輻式虛擬私有雲。您也可以在 Transit VPC 中新增 NVA，並具備新一代防火牆 (NGFW) 檢查功能，藉此擴展這項設計，詳情請參閱下一節「使用集中式應用程式層防火牆」。

使用集中式應用程式層防火牆

如果您的技術需求規定必須考慮應用程式層 (第 7 層) 和深層封包檢查，並採用超出 Cloud Next Generation Firewall 功能的進階防火牆功能，則可以使用 NVA 中代管的 NGFW 裝置。不過，該 NVA 必須符合貴機構的安全性需求。如要實作這些機制，您可以擴充拓撲，透過集中式 NVA 防火牆傳送所有跨環境流量，如下圖所示。

您可以使用軸輻式拓撲和集中式設備，在登陸區設計中套用下圖所示的模式：

Google Cloud 中的兩個共用虛擬私有雲資料會透過 NVA 流向傳輸虛擬私有雲網路，然後傳輸至內部部署環境中的工作負載。

如上圖所示，NVA 會做為周邊安全層，並做為啟用內嵌流量檢查的基礎。並強制執行嚴格的存取控管政策。如要檢查東/西向和北/南向流量，集中式 NVA 的設計可能包含多個區隔，並具備不同層級的安全存取控制。

微服務零信任分散式架構

使用容器化應用程式時，鏡像模式一節中討論的微服務零信任分散式架構，也適用於這個架構模式。

這個模式與鏡像模式的主要差異在於， Google Cloud 和其他環境中工作負載之間的通訊模型可從任一端啟動。根據應用程式需求和安全性需求，使用 Service Mesh 控制及精細管理流量。

網格模式最佳做法

  • 在進行任何其他操作前，請先決定資源階層結構設計，以及支援任何專案和虛擬私有雲所需的設計。這麼做有助於您選取與 Google Cloud 專案結構相符的最佳網路架構。
  • 在私人運算環境中使用 Kubernetes 時，請採用零信任分散式架構。Google Cloud
  • 在設計中集中使用 NVA 時，您應定義多個區隔，並採用不同層級的安全存取控制和流量檢查政策。請根據應用程式的安全性需求，設定這些控制項和政策。
  • 設計包含 NVA 的解決方案時，請務必考量 NVA 的高可用性 (HA)，避免單一故障點阻斷所有通訊。請按照Google Cloud 安全廠商提供的 HA 和備援設計與實作指南操作， 該廠商會提供 NVA。
  • 為提升隱私權、資料完整性及受控的通訊模型，請使用 API 閘道 (例如 Apigee 和 Apigee Hybrid) 透過 API 公開應用程式，並採用端對端 mTLS。您也可以在同一個機構資源中，使用共用虛擬私有雲端搭配 Apigee。
  • 如果解決方案設計需要將 Google Cloud型應用程式公開至網際網路，請考慮透過網路提供面向網際網路的應用程式中討論的設計建議。
  • 為保護專案中的服務，並降低資料竊取風險，請使用 VPC Service Controls 在專案或 VPC 網路層級指定服務範圍。 Google Cloud 此外，您也可以透過獲授權的 VPN 或 Cloud Interconnect，將服務範圍延伸至混合式環境。如要進一步瞭解服務範圍的優點，請參閱 VPC Service Controls 總覽。
  • 請參閱混合式雲端和多雲端網路模式的一般最佳做法。

如果您打算在 Google Cloud中託管的應用程式與其他環境之間，強制執行更嚴格的隔離措施和更精細的存取權，請考慮使用本系列其他文件中討論的閘道式模式。

閘道模式

設限模式是以架構為基礎，可根據不同環境間的特定公開 API 或端點，以精細的方式公開選取的應用程式和服務。本指南將此模式分為三種可能選項，每種選項都取決於特定的通訊模型：

如本指南先前所述，這裡說明的網路架構模式可因應各種應用程式的不同需求。為滿足不同應用程式的特定需求，主要登陸區架構可能會同時納入一種或多種模式。所選架構的具體部署方式，取決於每個設限模式的具體通訊需求。

本系列文章將討論各項設限模式及其可能的設計選項。 不過，適用於所有設限模式的常見設計選項是零信任分散式架構，適用於採用微服務架構的容器化應用程式。這個選項採用 Cloud Service Mesh、Apigee 和 Apigee Adapter for Envoy，可在 Kubernetes 叢集中部署輕量型 Apigee 閘道。Apigee Adapter for Envoy 是熱門的開放原始碼邊緣和服務 Proxy，專為雲端優先應用程式設計。這項架構可控管允許的服務對服務安全通訊，以及服務層級的通訊方向。您可以根據所選模式，在服務層級設計、微調及套用流量通訊政策。

閘道模式可讓您導入 Cloud Next Generation Firewall Enterprise，並搭配入侵預防服務 (IPS)，執行深層封包檢查來防範威脅，不必進行任何設計或路由修改。檢查內容取決於存取的特定應用程式、通訊模型和安全性需求。如果安全防護需求需要第 7 層和深層封包檢查，以及超越 Cloud Next Generation Firewall 功能的進階防火牆機制，您可以在網路虛擬設備 (NVA) 中代管集中式新一代防火牆 (NGFW)。多個 Google Cloud 安全合作夥伴提供 NGFW 設備，可滿足您的安全需求。整合 NVA 與這些設有閘道的模式時，可能需要在網路設計中導入多個安全區域，每個區域都有不同的存取控制層級。

閘道式輸出

「閘道式輸出」網路模式的架構，是根據從地端環境或其他雲端環境中選取的 API，向部署在 Google Cloud中的工作負載開放。這樣一來，這些服務就不會直接從內部部署環境或其他雲端環境暴露在公開網際網路上。您可以使用 API 閘道或 Proxy，或是做為現有工作負載遮蔽的負載平衡器，有限度地公開 API。您可以在隔離的邊界網路區隔中部署 API 閘道功能，例如邊界網路。

閘道輸出網路模式主要適用於 (但不限於) 分層應用程式架構模式和分割應用程式架構模式。在內部網路中部署後端工作負載時，閘道式輸出網路有助於在內部運算環境中維持較高的安全等級。您必須以符合下列通訊需求的方式連結運算環境：

  • 部署在 Google Cloud 中的工作負載可以使用內部 IP 位址，與公開應用程式的 API 閘道或負載平衡器 (或 Private Service Connect 端點) 通訊。
  • 但無法從 Google Cloud直接連線至私人運算環境中的其他系統。
  • 私人運算環境無法與部署在 Google Cloud 中的任何工作負載通訊。
  • 其他環境中的私人 API 流量只能從 Google Cloud 環境內發起。

本指南著重於透過私有混合網路連線的混合雲和多雲端環境。如果貴機構的安全規定允許，您可以透過網際網路直接連線，對具有公開 IP 位址的遠端目標 API 進行 API 呼叫。但您必須考量下列安全機制：

  • API OAuth 2.0 搭配傳輸層安全標準 (TLS)。
  • 頻率限制。
  • 威脅防護政策。
  • 相互 TLS 已設定為 API 層的後端。
  • IP 位址許可清單過濾器，設定為僅允許與預先定義的 API 來源和目的地進行雙向通訊。

如要保護 API Proxy，請考慮這些其他安全層面。詳情請參閱「使用 Apigee 保護應用程式和 API 的最佳做法」。

架構

下圖顯示符合上一節所列通訊需求的參考架構：

資料會從 Google Cloud 中的主機專案單向流向內部部署環境中的工作負載。

上圖中的資料流如下：

  • 在 Google Cloud 端，您可以將工作負載部署至虛擬私有雲 (VPC)。虛擬私有雲可以是單一或多個 (共用或非共用)。部署作業應與貴機構的專案和資源階層設計保持一致。
  • Google Cloud 環境的虛擬私有雲網路會擴充至其他運算環境。這些環境可以是地端或另一個雲端。如要使用內部 IP 位址促進環境之間的通訊，請使用合適的混合雲和多雲端網路連線。

  • 如要限制來自特定 VPC IP 位址，且目的地為遠端閘道或負載平衡器的流量，請使用 IP 位址允許清單篩選功能。使用具狀態防火牆規則時，系統會允許這些連線的傳回流量。您可以搭配使用下列任何功能，確保通訊安全，並將通訊限制為僅允許的來源和目的地 IP 位址：

  • 所有環境均共用不重疊的 RFC 1918 IP 位址空間。

變化版本

受限輸出架構模式可與其他方法搭配使用，以滿足不同的設計需求，同時仍考量此模式的通訊需求。這個模式提供下列選項：

使用 Google Cloud API 閘道和全域前端

資料從 Apigee 流入 Google Cloud ，再流向客戶專案 VPC，然後從 Cloud 流出至內部部署環境或其他雲端執行個體。

採用這種設計方法時，API 曝光和管理作業會位於Google Cloud內。如上圖所示，您可以透過實作 Apigee 做為 API 平台來達成此目的。是否要在遠端環境中部署 API 閘道或負載平衡器，取決於您的具體需求和目前設定。Apigee 提供兩種連線佈建選項：

  • 使用虛擬私有雲對等互連
  • 不使用虛擬私有雲對等互連

Google Cloud 全域前端功能 (例如 Cloud Load Balancing、Cloud CDN (透過 Cloud Interconnect 存取時) 和 Cross-Cloud Interconnect) 可提升使用者存取應用程式的速度，這些應用程式的後端託管於您的內部部署環境和其他雲端環境。

為加快內容傳遞速度，這些應用程式會從 Google Cloud 服務點 (PoP) Google Cloud 傳遞。全球超過 180 個網際網路交換中心和超過 160 個互連網路設施都提供服務點。

如要瞭解使用 Apigee 和 Cloud CDN 完成下列事項時，PoP 如何協助提供高效能 API，請觀看 YouTube 上的「使用 Apigee 和 Cloud CDN 提供高效能 API」：

  • 縮短延遲時間。
  • 在全球代管 API。
  • 在尖峰流量期間提高可用性。

上圖所示的設計範例是以 Private Service Connect 為基礎，不含虛擬私有雲對等互連。

這項設計中的北向網路是透過下列方式建立：

  • 負載平衡器 (圖表中的 LB) 會終止用戶端要求、處理流量，然後將流量轉送至 Private Service Connect 後端。
  • Private Service Connect 後端可讓負載平衡器透過與生產者服務連結相關聯的 Private Service Connect 連線，使用 Private Service Connect 網路端點群組 (NEG) 將用戶端要求傳送至已發布的服務 (Apigee 執行階段例項)。 Google Cloud

向南網路是透過下列方式建立：

  • Private Service Connect 端點，參照與客戶虛擬私有雲中內部負載平衡器 (圖表中的 ILB) 相關聯的服務附件。

  • 部署 ILB 時，會使用混合式連線網路端點群組 (混合式連線 NEG)。

  • 透過混合式網路連線 (例如 VPN 或 Cloud Interconnect)，即可透過混合式連線 NEG 存取混合式服務。

詳情請參閱「使用混合式連線設定區域內部 Proxy 網路負載平衡器」和「Private Service Connect 部署模式」。

使用 Private Service Connect 公開遠端服務

資料從 Google Cloud 流向地端環境或其他雲端，這些資料源自 VPC 中的工作負載，並經過 Cloud Load Balancing、混合式連線 NEG，以及 Cloud VPN 或互連。

在下列情況下，請使用 Private Service Connect 選項公開遠端服務：

  • 您未使用 API 平台，或基於下列原因，想避免將整個虛擬私有雲網路直接連線至外部環境：
    • 您有安全性限制或法規遵循要求。
    • IP 位址範圍重疊，例如在合併和收購情境中。
  • 即使時間緊迫，也能在環境之間啟用用戶端、應用程式和服務的單向安全通訊。
  • 您可能需要透過服務供應商虛擬私有雲 (傳輸虛擬私有雲) 提供多個消費者虛擬私有雲的連線，才能提供高度可擴充的多租戶或單一租戶服務模型，以便存取其他環境中發布的服務。

如果應用程式是以 API 形式使用，則可透過 Private Service Connect 為發布的應用程式提供內部 IP 位址，以便在區域內透過私人網路安全存取，並透過混合式連線存取。這種抽象化有助於透過混合雲和多雲端連線模型，整合不同雲端和內部部署環境的資源。您可以透過 Private Service Connect 發布服務，並設定精細的存取權，加速整合應用程式，並安全地公開位於內部部署環境或其他雲端環境的應用程式。在這種情況下，你可以使用下列選項：

在上圖中，應用程式虛擬私有雲網路中的工作負載可透過 Private Service Connect 端點，連線至在內部部署環境或其他雲端環境中執行的混合式服務，如下圖所示。這個單向通訊的設計選項，是與中繼虛擬私有雲對等互連的替代方案。

資料在 Google Cloud 內的多個 VPC 之間流動，然後透過 Cloud VPN 或 Cloud Interconnect 傳輸至內部部署環境或其他雲端。

如上圖的設計所示，多個前端、後端或端點可以連線至同一個服務附件，讓多個虛擬私有雲網路或多個消費者存取同一項服務。如下圖所示，您可以讓多個 VPC 存取應用程式。這項存取權有助於多租戶服務情境，即使多個消費者虛擬私有雲端的 IP 位址範圍重疊，您的服務仍可供這些虛擬私有雲端使用。

整合不同環境中的應用程式時，最常見的問題之一就是 IP 位址重疊。下圖中的 Private Service Connect 連線有助於避免 IP 位址重疊問題。而且不需要佈建或管理任何額外的網路元件 (例如 Cloud NAT 或 NVA)，即可執行 IP 位址轉換。如需設定範例，請參閱「使用 Private Service Connect 發布混合式服務」。

這項設計具有下列優點：

  • 避免潛在的共用擴充依附元件，以及大規模的複雜管理作業。
  • 提升安全性： 提供精細的連線控制選項。
  • 減少服務生產者和消費者之間，以及遠端外部環境的 IP 位址協調作業。

在後續階段，您可以運用先前討論的網路設計選項 (包括 Private Service Connect 選項)，將 Apigee 整合為 API 平台，擴充上圖的設計方法。

如要讓其他區域也能存取 Private Service Connect 端點，請使用 Private Service Connect 全球存取權。

連線至 Private Service Connect 端點的用戶端可以與端點位於相同區域，也可以位於不同區域。這種做法可用於在多個區域代管的服務中提供高可用性，或從其他區域存取單一區域的服務。如果其他區域中代管的資源存取 Private Service Connect 端點，則目的地為具有全域存取權端點的流量，會產生跨區域連出費用。

Google Cloud

最佳做法

  • 考慮將 Apigee 和 Apigee Hybrid 做為 API 平台解決方案，可帶來多項優勢。這項服務提供後端服務 API 的 Proxy 層，以及抽象化或外觀，並結合安全性功能、速率限制、配額和分析。
  • 虛擬私有雲和專案設計應以資源階層和安全通訊模型需求為依據。 Google Cloud
  • 使用 API 閘道時，您也應使用 IP 位址許可清單。允許清單會將通訊限制在 API 消費者和 API 閘道的特定 IP 位址來源和目的地，這些項目可能託管在不同環境中。
  • 透過 Private Service Connect 端點，使用虛擬私有雲防火牆規則或防火牆政策控管 Private Service Connect 資源的存取權。
  • 如果應用程式透過應用程式負載平衡器對外公開，建議使用 Google Cloud Armor 做為額外的安全防護層，防範 DDoS 和應用程式層安全威脅。

  • 如果執行個體需要存取網際網路，請在應用程式 (消費者) 虛擬私有雲中使用 Cloud NAT，讓工作負載可以存取網際網路。這樣一來，您就不必在部署於 API 閘道或負載平衡器後方的系統中，為 VM 執行個體指派外部公開 IP 位址。

  • 請參閱混合式雲端和多雲端網路模式的一般最佳做法。

閘道式輸入

「閘道式輸入」模式的架構是根據在 Google Cloud 中執行的工作負載選取一組 API，並開放給私人運算環境使用，但不會在公開網際網路上發布這些 API。此模式與閘道式輸出模式互相對應，且非常適合邊緣混合、分層混合和分割多雲情境。

與閘道輸出模式類似，您可以使用 API 閘道或負載平衡器做為現有工作負載或服務的遮蔽，有限度地公開 API。這麼做可讓私人運算環境、地端部署環境或其他雲端環境存取，如下所示：

  • 部署在私人運算環境或其他雲端環境中的工作負載，可以使用內部 IP 位址與 API 閘道或負載平衡器通訊，但無法連線至部署在Google Cloud 中的其他系統。
  • 無法與私人運算環境或其他雲端環境通訊。 Google Cloud 流量只會從私人環境或其他雲端環境傳輸至 Google Cloud中的 API。

架構

下圖顯示符合閘道式輸入模式需求的參考架構。

資料從內部部署環境或雲端透過 Cloud VPN 或 Cloud Interconnect 單向流向 Google Cloud 環境，最終進入工作負載。

上圖的架構說明如下：

  • 在 Google Cloud 端，將工作負載部署至應用程式虛擬私有雲 (或多個虛擬私有雲)。
  • Google Cloud 環境網路會透過混合式或多雲網路連線，擴展至其他運算環境 (內部部署或在其他雲端)，以利環境之間的通訊。
  • 您可以視需要使用傳輸虛擬私有雲，完成下列事項：
    • 提供額外的邊界安全層，允許存取應用程式 VPC 外部的特定 API。
    • 將流量導向至 API 的 IP 位址。您可以建立 VPC 防火牆規則，防止某些來源透過端點存取特定 API。
    • 整合網路虛擬設備 (NVA)，在 Transit 虛擬私有雲檢查第 7 層流量。
  • 透過 API Gateway 或負載平衡器 (Proxy 或應用程式負載平衡器) 存取 API，提供 Proxy 層，以及服務 API 的抽象層或外觀。如要將流量分配至多個 API 閘道執行個體，可以使用內部直通式網路負載平衡器。
  • 透過 Private Service Connect 端點，對已發布的服務提供精細的存取權。方法是透過 Private Service Connect 使用負載平衡器，公開應用程式或服務。
  • 所有環境都應使用不重疊的 RFC 1918 IP 位址空間。

下圖說明如何使用 Apigee 做為 API 平台，設計這個模式。

資料會流入 Google Cloud 環境，並透過 Cloud VPN 或 Cloud Interconnect，從內部部署或雲端環境傳送到 Apigee 執行個體中的專案。

在上圖中，使用 Apigee 做為 API 平台可提供下列功能，以啟用閘道式進入模式：

  • 閘道或 Proxy 功能
  • 安全防護功能
  • 頻率限制
  • 數據分析

在設計中：

  • 北向網路連線 (適用於來自其他環境的流量) 會通過應用程式虛擬私有雲中的 Private Service Connect 端點，該端點與 Apigee 虛擬私有雲相關聯。
  • 在應用程式 VPC 中，內部負載平衡器會透過 Apigee VPC 中顯示的 Private Service Connect 端點，公開應用程式 API。詳情請參閱「停用虛擬私有雲對等互連的架構」。

  • 在應用程式 VPC 中設定防火牆規則和流量篩選條件。這樣做可提供精細的受控存取權。此外，這項功能也能防止系統直接連線至應用程式，而不經過 Private Service Connect 端點和 API 閘道。

    此外，您也可以限制在應用程式 VPC 中，將後端工作負載的內部 IP 位址子網路廣告放送至地端網路，以免不經過 Private Service Connect 端點和 API 閘道，就能直接連線。

某些安全防護需求可能需要對應用程式 VPC 以外的範圍進行安全檢查，包括混合式連線流量。在這種情況下，您可以納入傳輸虛擬私有雲，實作額外的安全層。這些層 (例如具有多個網路介面的 NVA 新一代防火牆 (NGFW)，或具有入侵預防服務 (IPS) 的 Cloud Next Generation Firewall Enterprise) 會在應用程式虛擬私有雲外部執行深層封包檢查，如下圖所示：

資料會流入 Google Cloud 環境，並透過 Cloud VPN 或 Cloud Interconnect，從地端或雲端環境傳送至應用程式。

如上圖所示：

  • 北向網路連線 (適用於來自其他環境的流量) 會通過獨立的傳輸虛擬私有雲，前往與 Apigee 虛擬私有雲相關聯的傳輸虛擬私有雲中的 Private Service Connect 端點。
  • 在應用程式虛擬私有雲中，內部負載平衡器 (圖表中的 ILB) 用於透過 Apigee 虛擬私有雲中的 Private Service Connect 端點公開應用程式。

您可以在同一個 VPC 網路中佈建多個端點，如下圖所示。如要涵蓋不同的用途，您可以使用 Cloud Router 和 VPC 防火牆規則，控管各種可能的網路路徑。舉例來說，如果您要透過多個混合式網路連線將地端網路連線至 Google Cloud ，可以透過其中一個連線將地端流量傳送至特定 Google API 或已發布的服務，其餘流量則透過另一個連線傳送。此外，您也可以使用 Private Service Connect 全域存取權提供容錯移轉選項。

資料會流入 Google Cloud 環境，並透過多個 Private Service Connect 端點，從內部部署或雲端環境，經由 Cloud VPN 或 Cloud Interconnect 傳送至多個供應商 VPC。

變化版本

閘道式連入架構模式可與其他方法搭配使用，以滿足不同的設計需求，同時仍考量模式的通訊需求。這個模式提供下列選項：

從其他環境存取 Google API

如果需要存取 Cloud Storage 或 BigQuery 等 Google 服務，但不想透過公開網路傳送流量，Private Service Connect 就能派上用場。如下圖所示，這項功能可讓您透過混合式網路連線，使用 Private Service Connect 端點的 IP 位址，從內部部署或其他雲端環境存取支援的 Google API 和服務 (包括 Google 地圖、Google Ads 和Google Cloud)。如要進一步瞭解如何透過 Private Service Connect 端點存取 Google API，請參閱「透過端點存取 Google API 簡介」。

資料從內部部署環境流向 Google 服務，再流向 Google Cloud 環境。

在上圖中，您的內部部署網路必須使用 Cloud VPN 通道或 Cloud Interconnect VLAN 連結，連線至 transit (消費者) VPC 網路。

您可以使用端點或後端存取 Google API。Endpoints 可讓您指定一組 Google API。後端可讓您指定區域性 Google API。

使用 Private Service Connect 將應用程式後端公開給其他環境

在特定情境中，如分級混合模式所強調，您可能需要在 Google Cloud 中部署後端，同時在私人運算環境中維護前端。雖然這種做法較不常見，但如果處理的重量級單體式前端可能依附於舊版元件，就適用這種做法。或者，更常見的情況是，管理多個環境 (包括地端部署和其他雲端) 中的分散式應用程式時，需要連線至 Google Cloud 混合式網路中託管的後端。

在這種架構中，您可以在私有內部部署環境或其他雲端環境中使用本機 API 閘道或負載平衡器，直接將應用程式前端公開至網際網路。在 Google Cloud 使用 Private Service Connect 可促進與後端的私人連線，這些後端會透過 Private Service Connect 端點公開，理想情況是使用預先定義的 API，如下圖所示：

資料會從地端環境或其他雲端環境流入 Google Cloud 環境。資料會流經非Google Cloud 環境中的 Apigee 執行個體和前端服務，最終進入客戶專案應用程式 VPC。

上圖的設計採用 Apigee Hybrid 部署作業，其中包含 Google Cloud 中的管理層，以及託管於其他環境的執行階段層。您可以在地端環境或其他雲端環境中，於其中一個支援的Kubernetes 平台上，安裝及管理分散式 API 閘道的執行階段層。您可以根據在 Google Cloud 和其他環境中分散工作負載的需求，搭配使用 Apigee Hybrid 的 Apigee on Google Cloud 。詳情請參閱分散式 API 閘道。

使用軸輻式架構，將應用程式後端公開至其他環境

在某些情況下，您可能需要從不同 VPC 網路中託管的應用程式後端公開 API。 Google Cloud 如下圖所示，中樞虛擬私有雲可做為各種虛擬私有雲 (輪輻) 的互連中心點，透過私人混合式連線進行安全通訊。您也可以在其他環境中使用本機 API 閘道功能，例如 Apigee Hybrid，在本機終止用戶端要求，也就是應用程式前端的代管位置。

資料會在 Google Cloud 環境與地端或其他雲端環境之間流動，並透過不同虛擬私有雲網路，公開 Google Cloud 中託管的應用程式後端 API。

如上圖所示：

  • 為提供額外的 NGFW 第 7 層檢查功能，您可選擇將具備 NGFW 功能的 NVA 整合至設計中。您可能需要這些功能，才能遵守特定安全規定和貴機構的安全政策標準。

  • 這項設計假設輪輻 VPC 不需要直接 VPC 對 VPC 通訊。

    • 如果需要輪輻間通訊，可以使用 NVA 協助進行這類通訊。
    • 如果不同虛擬私有雲中有不同的後端，您可以使用 Private Service Connect，將這些後端公開至 Apigee 虛擬私有雲。
    • 如果使用 VPC 對等互連，在輻射 VPC 和中樞 VPC 之間建立南北向連線，則必須考量透過 VPC 對等互連的 VPC 網路傳遞限制。如要解決這項限制，可以採取下列任一做法：
      • 如要互連虛擬私有雲，請使用網路虛擬設備。
      • 請視情況考慮 Private Service Connect 模型。
      • 如要在 Apigee 虛擬私有雲與位於相同機構中其他Google Cloud 專案的後端之間建立連線，且不使用額外的網路元件，請使用共用虛擬私有雲。

  • 如果需要 NVA 檢查流量 (包括來自其他環境的流量)，則應在混合式轉移 VPC 中終止與內部部署或其他雲端環境的混合式連線。

  • 如果設計不包含 NVA，您可以在中樞 VPC 終止混合式連線。

  • 如果需要特定負載平衡功能或安全性功能，例如新增 Google Cloud Armor DDoS 防護或 WAF，您可以選擇在周邊透過外部 VPC 部署外部應用程式負載平衡器，然後將外部用戶端要求路由至後端。

最佳做法

  • 如果需要由私人內部部署或其他雲端環境中代管的前端，在本機接收來自網際網路的用戶端要求，請考慮使用 Apigee Hybrid 做為 API 閘道解決方案。此外，這種做法也有助於將解決方案無縫遷移至完全 Google Cloud代管的環境，同時維持 API 平台 (Apigee) 的一致性。
  • 視需求和架構而定，搭配使用 Apigee Adapter for Envoy 與Kubernetes 適用的 Apigee Hybrid 部署作業架構。
  • Google Cloud 中的 VPC 和專案設計應遵循本指南所述的資源階層和安全通訊模型規定。
  • 將傳輸虛擬私有雲納入這項設計，可彈性地在工作負載虛擬私有雲外部，佈建額外的邊界安全措施和混合式連線。
  • 透過混合式連線網路，使用端點的內部 IP 位址，從內部部署環境或其他雲端環境存取 Google API 和服務。詳情請參閱「透過地端部署主機存取端點」。
  • 為保護專案中的服務，並降低資料竊取風險，請使用 VPC Service Controls 在專案或 VPC 網路層級指定服務範圍。 Google Cloud
  • 透過 Private Service Connect 端點，使用虛擬私有雲防火牆規則或防火牆政策，控管對 Private Service Connect 資源的網路層級存取權。舉例來說，應用程式 (消費者) 虛擬私有雲的輸出防火牆規則可以限制 VM 執行個體對端點 IP 位址或子網路的存取權。如要進一步瞭解虛擬私有雲防火牆規則，請參閱虛擬私有雲防火牆規則。
  • 設計包含 NVA 的解決方案時，請務必考量 NVA 的高可用性 (HA)，避免單一故障點阻斷所有通訊。請按照 NVA 供應商提供的高可用性和備援設計與實作指南操作。
  • 如要強化周邊安全，並保護部署在相應環境中的 API 閘道，您可以在其他運算環境 (混合式或其他雲端) 中，選擇性地導入負載平衡和 Web 應用程式防火牆機制。在直接連線至網際網路的周邊網路中，實作這些選項。
  • 如果執行個體需要存取網際網路，請在應用程式 VPC 中使用 Cloud NAT，讓工作負載可以存取網際網路。這樣一來，您就不必在部署於 API 閘道或負載平衡器後方的系統中，為 VM 執行個體指派外部公開 IP 位址。
  • 輸出網路流量請使用 Secure Web Proxy。 Proxy 具有多項優點。
  • 請參閱混合式雲端和多雲端網路模式的一般最佳做法。

閘道式輸出和閘道式輸入

閘道式輸出和閘道式輸入模式結合了閘道式輸出和閘道式輸入，適用於需要雙向使用 API 的工作負載。工作負載可以在 Google Cloud、私有地端部署環境或其他雲端環境中執行。在這個模式中，您可以使用 API 閘道、Private Service Connect 端點或負載平衡器公開特定 API，並視需要提供驗證、授權和 API 呼叫稽核。

這個模式與網狀模式的主要區別，在於它適用於僅需雙向 API 用途或與特定 IP 位址來源和目的地通訊的案例，例如透過 Private Service Connect 端點發布的應用程式。由於通訊僅限於公開的 API 或特定 IP 位址，因此您在設計時，不需要對齊環境中的網路。常見的適用情境包括但不限於：

  • 併購。
  • 與合作夥伴的應用程式整合。
  • 機構的應用程式和服務與不同機構單位之間的整合，這些機構單位會管理自己的應用程式，並將應用程式託管在不同環境中。

通訊方式如下：

  • 部署在 Google Cloud 中的工作負載可以使用內部 IP 位址，與 API 閘道 (或特定目的地 IP 位址) 通訊，但無法連線至部署在私人運算環境中的其他系統。
  • 相反地，部署在其他運算環境中的工作負載，可以使用內部 IP 位址與 Google Cloud端的 API 閘道 (或特定已發布的端點 IP 位址) 通訊，但無法連線至部署在 Google Cloud 中的其他系統。

架構

下圖顯示閘道式輸出和閘道式輸入模式的參考架構：

Google Cloud 與地端或其他雲端網路之間的資料輸出和輸入。

上圖中的設計方法包含下列元素：

  • 在 Google Cloud 端，您可以在虛擬私有雲 (或共用虛擬私有雲) 中部署工作負載，不必直接向網際網路公開。
  • Google Cloud 環境網路會擴展至其他運算環境。該環境可以是內部部署或位於其他雲端。如要擴充環境，請使用合適的混合和多雲連線通訊模式，促進環境之間的通訊，以便使用內部 IP 位址。
  • 您也可以選擇啟用特定目標 IP 位址的存取權，透過傳輸虛擬私有雲，在應用程式虛擬私有雲外部新增周邊安全層。
    • 您可以在傳輸虛擬私有雲使用 Cloud Next Generation Firewall 或網路虛擬設備 (NVA) 和新一代防火牆 (NGFW)，檢查流量並允許或禁止特定來源存取特定 API，再將流量傳輸至應用程式虛擬私有雲。
  • API 應透過 API Gateway 或負載平衡器存取，以提供 Proxy 層，以及服務 API 的抽象化或外觀。
  • 如果是以 API 形式使用的應用程式，您也可以使用 Private Service Connect 為發布的應用程式提供內部 IP 位址。
  • 所有環境都使用不重疊的 RFC 1918 IP 位址空間。

這個模式的常見應用是將應用程式後端 (或應用程式後端的子集) 部署在 Google Cloud ，同時將其他後端和前端元件託管在地端部署環境或其他雲端 (分層混合模式或分割多雲模式)。隨著應用程式演進並遷移至雲端，通常會出現對特定雲端服務的依附元件和偏好設定。

有時，這些依附元件和偏好設定會導致應用程式和後端分散在不同的雲端服務供應商。此外，部分應用程式可能採用多種資源和服務組合建構而成，並分散在內部部署環境和多個雲端環境中。

對於分散式應用程式，您可以使用外部 Cloud Load Balancing 混合雲和多雲端連線功能，終止使用者要求，並將要求轉送至其他環境中的前端或後端。如以下圖表所示，這項轉送作業是透過混合式網路連線進行。這項整合功能可讓您在不同環境中逐步發布應用程式元件。前端對 Google Cloud 中代管的後端服務發出的要求，會透過內部負載平衡器 (圖中的 ILB) 建立的混合式網路連線，安全地進行通訊。

地端部署或其他雲端環境中的應用程式前端，與 Google Cloud 環境中的應用程式後端之間，資料的傳入和傳出。資料會透過 Google Cloud的內部負載平衡器 (ILB) 流動。

使用上圖中的 Google Cloud 設計有助於：

  • 使用雙方預先定義的 API，在 Google Cloud、地端和其他雲端環境之間建立雙向通訊，這些 API 符合此模式的通訊模型。
  • 如要為面向網際網路的應用程式提供全域前端，並搭配分散式應用程式元件 (前端或後端)，以及達成下列目標，您可以運用 Google Cloud 服務點 (PoP) 分散式架構的進階負載平衡和安全性功能：
  • 使用無伺服器代管服務，減少資本支出並簡化作業。
  • 在全球範圍內，針對應用程式後端連線進行最佳化，以提升速度和降低延遲。
    • Google Cloud Cross-Cloud Network 可透過最佳私人連線，在應用程式元件之間進行多雲端通訊。
  • 透過 Cloud CDN 存取權，快取高需求靜態內容，並為使用全域 Cloud Load Balancing 的應用程式提升效能。
  • 使用 Google Cloud Armor 功能，為面向網際網路的應用程式全域前端提供安全防護，在全球各地部署網頁應用程式防火牆 (WAF) 和 DDoS 緩解服務。
  • 您也可以選擇將 Private Service Connect 納入設計。這麼做可讓您從其他環境，以精細的私人存取權存取 Google Cloud 服務 API 或已發布的服務，不必經過公開網際網路。

變化版本

閘道出口和閘道入口架構模式可與其他方法合併，以滿足不同的設計需求，同時仍考量此模式的通訊需求。這些模式提供下列選項：

分散式 API 閘道

在分割多雲端模式等情境中，應用程式 (或應用程式元件) 可在不同雲端環境 (包括私有內部部署環境) 中建構。一般而言，您需要將用戶端要求直接轉送至應用程式前端，也就是應用程式 (或前端元件) 的代管環境。這類通訊需要本機負載平衡器或 API 閘道。這些應用程式及其元件可能也需要特定的 API 平台功能才能整合。

下圖說明 Apigee 和 Apigee Hybrid 如何在每個環境中提供本機 API 閘道，以滿足這類需求。API 平台管理作業集中在 Google Cloud。這項設計有助於強制執行嚴格的存取控管措施，只有預先核准的 IP 位址 (目標和目的地 API 或 Private Service Connect 端點 IP 位址) 才能在 Google Cloud 和其他環境之間通訊。

在內部部署或其他雲端環境與 Google Cloud 環境之間傳輸資料。用戶端對應用程式前端的要求會直接傳送至應用程式 (或前端元件) 的代管環境。

下表說明上圖中兩個不同的通訊路徑，這些路徑使用 Apigee API 閘道：

  • 用戶端要求會直接傳送到應用程式前端，也就是應用程式 (或前端元件) 的代管環境。
  • 每個環境中的 API 閘道和 Proxy 會在多個環境中，以不同方向處理用戶端和應用程式 API 要求。
    • Google Cloud(Apigee) 中的 API 閘道功能會公開在 Google Cloud中代管的應用程式 (前端或後端) 元件。
    • 另一個環境 (混合式) 中的 API 閘道功能會公開該環境中託管的應用程式前端 (或後端) 元件。

您可以視需要考慮使用傳輸虛擬私有雲。中繼虛擬私有雲可彈性區隔問題，並在獨立的虛擬私有雲網路中執行安全檢查和混合式連線。從 IP 位址可連線性的角度來看，傳輸虛擬私有雲 (附加混合式連線) 可滿足下列需求，以維持端對端連線能力：

  • 目標 API 的 IP 位址必須向其他環境宣傳，這些環境會代管用戶端/要求者。
  • 必須向目標 API 所在的環境 (例如 API 要求者 (用戶端) 的 IP 位址) 宣傳需要與目標 API 通訊的主機 IP 位址。但透過負載平衡器、Proxy、Private Service Connect 端點或 NAT 執行個體進行通訊時，則不在此限。

為將連線擴展至遠端環境，這項設計採用直接虛擬私有雲對等互連，並具備客戶路徑交換功能。這項設計可讓源自 Google Cloud 應用程式虛擬私有雲內裝載工作負載的特定 API 要求，透過 Transit VPC 轉送。或者，您也可以在與負載平衡器相關聯的應用程式虛擬私有雲中，使用 Private Service Connect 端點，而負載平衡器在 Transit 虛擬私有雲中具有混合式網路端點群組後端。下一節將說明該設定：使用 Private Service Connect 進行雙向 API 通訊。

使用 Private Service Connect 進行雙向 API 通訊

有時企業可能不需要立即使用 API Gateway (例如 Apigee)，或想稍後再新增。不過，您可能需要啟用不同環境中特定應用程式之間的通訊和整合功能，以符合業務需求。舉例來說，如果貴公司收購了另一家公司，您可能需要向該公司公開特定應用程式。他們可能需要向貴公司公開應用程式。兩家公司可能各自有自己的工作負載，且這些工作負載託管在不同環境 (Google Cloud、內部部署或其他雲端) 中，因此必須避免 IP 位址重疊。在這種情況下，您可以使用 Private Service Connect 促進有效通訊。

如果是以 API 形式使用的應用程式，您也可以使用 Private Service Connect 為發布的應用程式提供私人位址，以便在區域和混合式連線中，透過私人網路安全存取應用程式。這項抽象化功能可透過混合雲和多雲端連線模型，整合不同雲端和地端環境的資源。此外，您還能跨多雲端和地端環境組裝應用程式。這可滿足不同的通訊需求，例如整合未或不打算使用 API 閘道的安全應用程式。

如以下圖表所示，搭配使用 Private Service Connect 與 Cloud Load Balancing，即可建立兩條不同的通訊路徑。每個路徑都是從不同方向啟動，用於不同的連線用途，最好是透過 API 呼叫。

  • 本指南中討論的 Private Service Connect 設計考量和建議，皆適用於這項設計。
  • 如果需要額外的第 7 層檢查，您可以將 NVA 與此設計 (位於 Transit VPC) 整合。
  • 無論是否使用 API 閘道，都可以採用這種設計。

地端或其他雲端環境和 Google Cloud 環境會透過不同路徑，以及各種負載平衡器、VPC 端點和子網路傳輸資料。

上圖中描繪的兩條連線路徑代表獨立連線，並未說明單一連線或流程的雙向通訊。

使用 Private Service Connect 端點和介面進行雙向通訊

如閘道式連入模式所述，如要啟用用戶端與服務之間的通訊，其中一種做法是使用 Private Service Connect 端點，將生產者虛擬私有雲中的服務公開給消費者虛擬私有雲。透過混合式連線，這項連線功能可擴展至地端部署環境，甚至是其他雲端供應商環境。不過，在某些情況下，代管服務也可能需要私人通訊。

如要存取特定服務 (例如從可託管在消費者虛擬私有雲內或外部的資料來源擷取資料)，這類私人通訊可發生在應用程式 (生產者) 虛擬私有雲和遠端環境 (例如內部部署環境) 之間。

在這種情況下，Private Service Connect 介面可讓服務供應商 VM 執行個體存取用戶端網路。方法是共用網路介面，同時維持生產者和消費者角色的分離。有了這個位於消費者 VPC 中的網路介面，應用程式 VM 就能存取消費者資源，就像這些資源位於供應商 VPC 中一樣。

Private Service Connect 介面是附加至用戶端 (中繼) 虛擬私有雲的網路介面。您可以連線至可從 Private Service Connect 介面所連結的消費者 (轉移) 虛擬私有雲連線的外部目的地。因此，這個連線可以透過混合式連線 (例如內部部署環境) 擴展至外部環境，如下圖所示：

Google Cloud 中的應用程式與地端或其他雲端網路中的工作負載之間，資料輸出和輸入。

如果用戶虛擬私有雲是外部機構或實體 (例如第三方機構)，您通常無法保護與用戶虛擬私有雲中 Private Service Connect 介面的通訊。在這種情況下，您可以在 Private Service Connect 介面 VM 的客體 OS 中定義安全性政策。詳情請參閱「為 Private Service Connect 介面設定安全性」。如果該方法不符合貴機構的安全法規或標準，您也可以考慮其他做法。

最佳做法

  • 如果需要讓在私人內部部署環境或其他雲端環境中代管的前端，在本機接收來自網際網路的用戶端要求，請考慮使用 Hybrid 做為 API 閘道解決方案。

    • 這種做法也有助於將解決方案遷移至全代管環境，同時維持 API 平台 (Apigee) 的一致性。 Google Cloud

  • 如要盡量縮短延遲時間，並在長期或永久的混合式或多雲端設定中，將大量輸出資料傳輸至其他環境時，盡量降低成本，請考慮下列事項：

    • 使用 Cloud Interconnect 或 Cross-Cloud Interconnect。
    • 如要在適當環境的目標前端終止使用者連線，請使用「混合」。

  • 如符合需求和架構，請搭配使用 Apigee Adapter for Envoy 與Kubernetes 混合式部署。

  • 設計連線和路徑之前，請先找出需要導向本機或遠端 API 閘道的流量或 API 要求，以及來源和目的地環境。

  • 在專案或 VPC 網路層級指定服務範圍，使用 VPC Service Controls 保護專案中的服務，並降低資料竊取風險。 Google Cloud

  • 透過 Private Service Connect 端點，使用虛擬私有雲 (VPC) 防火牆規則或防火牆政策，控管對 Private Service Connect 資源的網路層級存取權。舉例來說，應用程式 (消費者) 虛擬私有雲的輸出防火牆規則可以限制 VM 執行個體對端點 IP 位址或子網路的存取權。

  • 使用 Private Service Connect 介面時，您必須設定 Private Service Connect 介面的安全性，保護與介面的通訊。

  • 如果私人子網路中的工作負載需要存取網際網路，請使用 Cloud NAT，避免為工作負載指派外部 IP 位址，並將其公開至網際網路。

  • 請參閱混合式雲端和多雲端網路模式的一般最佳做法。

移交模式

「轉換」模式的架構是根據使用Google Cloud提供的儲存服務，將私人運算環境連線至 Google Cloud中的專案。這個模式主要適用於採用分析混合多雲端架構模式的設定，其中：

  • 在私人運算環境或其他雲端中執行的工作負載，會將資料上傳到共用的儲存空間位置。視用途而定，上傳可能會以批量或較小的增量進行。
  • 託管給Google Cloud的工作負載或其他 Google 服務 (例如資料分析和人工智慧服務) 會使用共用儲存空間位置的資料，並以串流或批次的方式處理資料。

架構

下圖顯示移交模式的參考架構。

資料從內部部署環境流向 VPC 代管工作負載，以及 Google Cloud 環境中代管的資料分析服務。

上述架構圖顯示下列工作流程：

  • 在 Google Cloud 端，將工作負載部署至應用程式 VPC 中。這些工作負載可包含資料處理、數據分析，以及與數據分析相關的前端應用程式。
  • 如要以安全的方式向使用者公開前端應用程式，可以使用 Cloud Load Balancing 或 API Gateway。
  • 一組 Cloud Storage 值區或 Pub/Sub 佇列會上傳私人運算環境的資料，並讓部署在 Google Cloud中的工作負載進行後續處理。您可以使用身分與存取權管理 (IAM) 政策，限制對信任工作負載的存取權。
  • 使用 VPC Service Controls 限制服務存取權，並將 Google Cloud 服務中不必要的資料竊取風險降到最低。
  • 在這個架構中，與 Cloud Storage 值區或 Pub/Sub 之間的通訊會使用公開網路，或透過 VPN、Cloud Interconnect 或 Cross-Cloud Interconnect 建立的私人連線進行。通常，連線方式的決定取決於多個層面，例如：
    • 預期流量
    • 設定是暫時還是永久
    • 安全性和法規遵循需求

變化版本

您也可以將閘道式連入模式中列出的設計選項，套用至這個模式，這些選項會使用 Google API 的 Private Service Connect 端點。具體來說，這項服務可存取 Cloud Storage、BigQuery 和其他 Google 服務 API。這種做法需要透過混合型多雲端網路連線 (例如 VPN、Cloud Interconnect 和 Cross-Cloud Interconnect) 使用私人 IP 位址。

最佳做法

  • 鎖定 Cloud Storage 值區和 Pub/Sub 主題的存取權。
  • 在適用情況下，使用雲端優先的整合式資料遷移解決方案，例如 Google Cloud 解決方案套件。 這些解決方案可有效率地移動、整合及轉換資料，滿足您的用途需求。

  • 評估影響資料移轉選項的各種因素，例如費用、預計移轉時間和安全性。詳情請參閱「評估移轉選項」。

  • 如要盡量縮短延遲時間，並避免透過公開網際網路傳輸及移動大量資料，請考慮使用 Cloud Interconnect 或 Cross-Cloud Interconnect，包括在虛擬私有雲中存取 Google API 的 Private Service Connect 端點。

  • 如要保護專案中的服務，並降低資料竊取風險，請使用 VPC Service Controls。 Google Cloud 這些服務控制項可在專案或虛擬私有雲網路層級指定服務範圍。

  • 透過 API 閘道、負載平衡器或虛擬網路設備，與 VM 執行個體上代管的公開資料分析工作負載通訊。請使用其中一種通訊方法，確保安全性並避免從網際網路直接存取這些執行個體。

  • 如果需要網際網路存取權，可以在同一個虛擬私有雲中使用 Cloud NAT，處理從執行個體到公開網際網路的輸出流量。

  • 請參閱混合式雲端和多雲端網路拓撲適用的一般最佳做法。

常見的最佳做法

設計及導入雲端身分、資源階層和登陸區網路時，請參考「登陸區設計 Google Cloud」和「企業基礎藍圖」中涵蓋的安全性最佳做法。 Google Cloud 請根據下列文件驗證所選設計：

此外，請考慮下列一般最佳做法：

混合式雲端和多雲端安全網路架構模式：後續步驟