共用方式為


Azure Spring Apps 參考架構

注意

Azure Spring Apps 是 Azure Spring Cloud 服務的新名稱。 雖然服務有新的名稱,但是您暫時還是會在某些位置看到舊的名稱,我們正在致力更新螢幕擷取畫面、影片和圖表等資產。

本文適用于: ✔️ Standard ✔️ Enterprise

此參考架構是使用一般企業中樞和輪輻設計來使用 Azure Spring Apps 的基礎。 就設計而言,Azure Spring Apps 會部署在依賴中樞所裝載之共用服務的單一輪輻中。 此架構是使用元件所建置,以達成 Microsoft Azure Well-Architected Framework 中的原則。

Azure Spring Apps 有兩種類型:標準方案和企業方案。

Azure Spring Apps Standard 方案是由 Spring Cloud Config Server、Spring Cloud Service Registry 和 kpack 建置服務所組成。

Azure Spring Apps Enterprise 方案是由 VMware Tanzu® 建置服務™、VMware Tanzu 的應用程式組態服務、VMware Tanzu® 服務登錄、適用于 VMware Tanzu® 的 Spring Cloud Gateway 和適用于 VMware Tanzu®® 的 API 入口網站所組成。

如需此架構的實作,請參閱 GitHub 上的 Azure Spring Apps 參考架構

此架構的部署選項包括 Azure Resource Manager (ARM)、Terraform、Azure CLI 和 Bicep。 此存放庫中的成品提供您自訂環境的基礎。 您可以將 Azure 防火牆或應用程式閘道等資源分組到不同的資源群組或訂用帳戶。 此分組有助於將不同的功能分開,例如 IT 基礎結構、安全性、商務應用程式小組等等。

規劃位址空間

Azure Spring Apps 需要兩個專用子網路:

  • 服務執行階段
  • Spring Boot 應用程式

每個子網路都需要專用的 Azure Spring Apps 叢集。 多個叢集無法共用相同的子網路。 每個子網路的大小下限為 /28。 Azure Spring Apps 可支援的應用程式執行個體數目會根據子網路的大小而有所不同。 您可以於在虛擬網路中部署 Azure Spring Apps虛擬網路需求一節中找到詳細的虛擬網路需求。

警告

選取的子網路大小無法與現有的虛擬網路位址空間重疊,且不應與任何對等互連或內部部署子網路位址範圍重疊。

使用案例

此架構的典型使用案例包括:

  • 私人應用程式:部署在混合式雲端環境中的內部應用程式
  • 公用應用程式:外部對應的應用程式

這些使用案例彼此類似,其差別在於其安全性和網路流量規則。 此架構的設計目的是要支援每個使用案例的細微差異。

私人應用程式

下列清單描述私人應用程式的基礎結構需求。 這些需求在高度管制的環境中很常見。

  • 子網路只能有一個 Azure Spring Apps 執行個體。
  • 應強制遵守至少一個安全性效能評定。
  • 應用程式主機網域名稱服務 (DNS) 記錄應該儲存在 Azure 私人 DNS 中。
  • Azure 服務相依性應該透過服務端點或 Private Link 通訊。
  • 待用資料應加密。
  • 傳輸中資料應加密。
  • DevOps 部署管線可以使用 (例如由 Azure DevOps) 且需要與 Azure Spring Apps 之間的網路連線。
  • 輸出流量應流經中央網路虛擬設備 (NVA) (例如 Azure 防火牆)。
  • 如果使用 Azure Spring Apps 設定伺服器從存放庫載入設定屬性,該存放庫必須是私人的。
  • Microsoft 零信任安全性做法需要將祕密、憑證和認證儲存在安全保存庫中。 建議的服務是 Azure Key Vault。
  • 內部部署和雲端中的主機名稱解析應該要是雙向的。
  • 除了控制平面流量之外,不能有任何直接輸出到公用網際網路的流量。
  • Azure Spring Apps 部署所管理的資源群組不得修改。
  • Azure Spring Apps 部署所管理的子網路不得修改。

下列清單顯示組成設計的元件:

  • 內部部署網路
    • 網域名稱服務 (DNS)
    • 閘道
  • 中樞訂用帳戶
    • 應用程式閘道子網路
    • Azure 防火牆子網路
    • 共用服務子網路
  • 已連線的訂用帳戶
    • Azure Bastion 子網路
    • 虛擬網路對等

下列清單描述此參考架構中的 Azure 服務:

  • Azure Key Vault:由硬體支援的認證管理服務,其與 Microsoft 身分識別服務和計算資源緊密整合。

  • Azure 監視器:適用於在 Azure 和內部部署中部署之應用程式的全方位監視服務套件。

  • Azure Pipelines:功能完整的持續整合/持續開發 (CI/CD) 服務,可自動將更新的 Spring Boot 應用程式部署至 Azure Spring Apps。

  • 適用於雲端的 Microsoft Defender:適用於跨內部部署、多個雲端和 Azure 之工作負載的統一安全性管理和威脅防護系統。

  • Azure Spring Apps:專為 Java 型 Spring Boot 應用程式和 .NET 型 Steeltoe (英文) 應用程式所設計及最佳化的受控服務。

下圖代表架構良好並可解決上述需求的中樞和輪輻設計:

公用應用程式

下列清單描述公用應用程式的基礎結構需求。 這些需求在高度管制的環境中很常見。

  • 子網路只能有一個 Azure Spring Apps 執行個體。
  • 應強制遵守至少一個安全性效能評定。
  • 應用程式主機網域名稱服務 (DNS) 記錄應該儲存在 Azure 私人 DNS 中。
  • 應啟用 Azure DDoS 保護。
  • Azure 服務相依性應該透過服務端點或 Private Link 通訊。
  • 待用資料應加密。
  • 傳輸中資料應加密。
  • DevOps 部署管線可以使用 (例如由 Azure DevOps) 且需要與 Azure Spring Apps 之間的網路連線。
  • 輸出流量應流經中央網路虛擬設備 (NVA) (例如 Azure 防火牆)。
  • 輸入流量應該至少由應用程式閘道或 Azure Front Door 管理。
  • 網際網路可路由位址應儲存在 Azure 公用 DNS 中。
  • Microsoft 零信任安全性做法需要將祕密、憑證和認證儲存在安全保存庫中。 建議的服務是 Azure Key Vault。
  • 內部部署和雲端中的主機名稱解析應該要是雙向的。
  • 除了控制平面流量之外,不能有任何直接輸出到公用網際網路的流量。
  • Azure Spring Apps 部署所管理的資源群組不得修改。
  • Azure Spring Apps 部署所管理的子網路不得修改。

下列清單顯示組成設計的元件:

  • 內部部署網路
    • 網域名稱服務 (DNS)
    • 閘道
  • 中樞訂用帳戶
    • 應用程式閘道子網路
    • Azure 防火牆子網路
    • 共用服務子網路
  • 已連線的訂用帳戶
    • Azure Bastion 子網路
    • 虛擬網路對等

下列清單描述此參考架構中的 Azure 服務:

  • Azure 應用程式防火牆:Azure 應用程式閘道的功能之一,可針對常見的惡意探索和弱點為應用程式提供集中式保護。

  • Azure 應用程式閘道:負責處理應用程式流量,並使用以第 7 層運作之傳輸層安全性 (TLS) 卸載的負載平衡器。

  • Azure Key Vault:由硬體支援的認證管理服務,其與 Microsoft 身分識別服務和計算資源緊密整合。

  • Azure 監視器:適用於在 Azure 和內部部署中部署之應用程式的全方位監視服務套件。

  • Azure Pipelines:功能完整的持續整合/持續開發 (CI/CD) 服務,可自動將更新的 Spring Boot 應用程式部署至 Azure Spring Apps。

  • 適用於雲端的 Microsoft Defender:適用於跨內部部署、多個雲端和 Azure 之工作負載的統一安全性管理和威脅防護系統。

  • Azure Spring Apps:專為 Java 型 Spring Boot 應用程式和 .NET 型 Steeltoe (英文) 應用程式所設計及最佳化的受控服務。

下圖代表架構良好並可解決上述需求的中樞和輪輻設計。 請注意,只有中樞虛擬網路會與網際網路通訊:

Azure Spring Apps 內部部署連線能力

Azure Spring Apps 中的應用程式可以與各種 Azure、內部部署和外部資源通訊。 透過使用中樞和輪輻設計,應用程式可以使用 Express Route 或站對站虛擬私人網路 (VPN),針對外部或內部部署網路路由傳送流量。

Azure Well-Architected Framework 考量

Azure Well-Architected Framework 是建立強式基礎結構基礎時應遵循的一組指導原則。 該架構包含下列類別:成本最佳化、卓越營運、效能效率、可靠性和安全性。

成本最佳化

由於分散式系統設計的本質,基礎結構擴展是一定會發生的現實。 此現實會導致非預期且無法控制的成本。 Azure Spring Apps 是使用可調整的元件來建置,使其能符合需求並將成本最佳化。 此架構的核心是 Azure Kubernetes Service (AKS)。 此服務的設計目的是降低管理 Kubernetes 的複雜度和作業額外負荷,其中包括叢集作業成本中的效率。

您可以將不同的應用程式和應用程式類型部署到 Azure Spring Apps 的單一執行個體。 此服務支援由計量或排程所觸發的應用程式自動調整,以改善使用率和成本效益。

您也可以使用 Application Insights 和 Azure 監視器來降低營運成本。 透過完整的記錄解決方案所提供的可見度,您可以實作自動化,以即時調整系統元件的規模。 您也可以分析記錄資料,以顯示應用程式程式碼中效率不佳的部分來加以改進,以改善系統的整體成本和效能。

卓越營運

Azure Spring Apps 可解決卓越營運的多個層面。 您可以結合這些層面,以確保服務能在生產環境中有效率地執行,如下列清單所述:

  • 您可以使用 Azure Pipelines 來確保部署可靠且一致,同時協助您避免人為錯誤。
  • 您可以使用 Azure 監視器和 Application Insights 來儲存記錄和遙測資料。 您可以評估收集的記錄和計量資料,以確保應用程式的健康情況和效能。 應用程式效能監視 (APM) 已透過 Java 代理程式完全整合到該服務中。 此代理程式可讓您查看所有已部署的應用程式和相依性,而不需要額外的程式碼。 如需詳細資訊,請參閱部落格文章輕鬆地監視 Azure Spring Apps 中的應用程式和相依性 (英文)。
  • 您可以使用適用於雲端的 Microsoft Defender,透過提供分析和評估所提供資料的平台,以確保應用程式能維持安全性。
  • 該服務支援各種部署模式。 如需詳細資訊,請參閱在 Azure Spring Apps 中設定預備環境

可靠性

Azure Spring Apps 是以 AKS 為基礎所建置。 雖然 AKS 能透過叢集提供某種程度的復原性,但此參考架構會進一步透過納入服務和架構考量,以在發生元件失敗時增加應用程式的可用性。

透過建置在定義完善的中樞和輪輻設計之上,此架構的基礎可確保您可以將其部署到多個區域。 針對私人應用程式使用案例,架構會使用 Azure 私人 DNS,以確保在發生地理失敗期間能夠維持可用性。 針對公用應用程式使用案例,Azure Front Door 和 Azure 應用程式閘道可確保可用性。

安全性

此架構的安全性是透過遵守業界定義的控制措施和基準來加以解決。 在此內容中,「控制措施」表示精簡且定義完善的最佳做法,例如「在實作資訊系統存取時採用最低權限原則」。 IAM-05" 此架構中的控制措施是來自雲端安全性聯盟 (英文) (CSA) 的雲端控制矩陣 (英文) (CCM),以及網際網路安全性中心 (英文) (CIS) 的 Microsoft Azure 基礎效能評定 (MAFB)。 在套用的控制措施中,焦點在於治理、網路和應用程式安全性的主要安全性設計原則上。 您必須負責處理身分識別、存取管理及儲存體與您目標基礎結構之間的相關設計原則。

控管

此架構所解決的治理主要層面是透過網路資源的隔離 (Isolation) 來進行隔離 (Segregation)。 在 CCM 中,DCS-08 建議資料中心的輸入和輸出控制措施。 為了滿足控制措施,架構會使用中樞和輪輻設計,使用網路安全性群組 (NSG) 來篩選資源之間的東西流量。 此架構也會篩選中樞中的中央服務與輪輻中的資源之間的流量。 架構會使用 Azure 防火牆執行個體來管理網際網路與架構內資源之間的流量。

下列清單顯示此參考中處理資料中心安全性的控制措施:

CSA CCM 控制措施識別碼 CSA CCM 控制措施領域
DCS-08 資料中心安全性未經授權人員進入

網路

支援此架構的網路設計衍生自傳統的中樞和輪輻模型。 此決策可確保網路隔離是基本建構。 CCM 控制措施 IVS-06 建議在信任與不受信任的環境之間限制和監視網路與虛擬機器之間的流量。 此架構採用控制措施的方式,是針對東西流量 (位於「資料中心」內的流量) 實作 NSG,然後針對南北流量 (位於「資料中心」外的流量) 實作 Azure 防火牆。 CCM 控制措施 IPY-04 建議基礎結構應使用安全的網路通訊協定,在服務之間交換資料。 支援此架構的 Azure 服務全都會使用標準安全通訊協定,例如針對 HTTP 使用 TLS,以及 SQL。

下列清單顯示可處理此參考中網路安全性的 CCM 控制措施:

CSA CCM 控制措施識別碼 CSA CCM 控制措施領域
IPY-04 網路通訊協定
IVS-06 網路安全性

透過定義來自 MAFB 的控制措施來進一步保護網路實作。 這些控制措施可確保會限制來自公用網際網路傳入環境的流量。

下列清單顯示可處理此參考中網路安全性的 CIS 控制措施:

CIS 控制措施識別碼 CIS 控制措施描述
6.2 確定已限制來自網際網路的 SSH 存取。
6.3 確認沒有 SQL 資料庫允許輸入 0.0.0.0/0 (任何 IP)。
6.5 確定網路監看員為 [已啟用]。
6.6 確定會限制來自網際網路且使用 UDP 的輸入。

部署到安全環境中時,Azure Spring Apps 需要從 Azure 輸出管理流量。 您必須允許在虛擬網路中執行 Azure Spring 應用程式的客戶責任中所列出的網路和應用程式規則。

應用程式安全性

此設計準則涵蓋身分識別、資料保護、金鑰管理和應用程式設定的基本元件。 根據設計,部署在 Azure Spring Apps 中的應用程式會以最低的運作權限來執行。 這組授權控制措施會與使用服務時的資料保護直接相關。 金鑰管理可強化這個階層式的應用程式安全性做法。

下列清單顯示可處理此參考中金鑰管理的 CCM 控制措施:

CSA CCM 控制措施識別碼 CSA CCM 控制措施領域
EKM-01 加密和金鑰管理權利
EKM-02 加密和金鑰管理金鑰產生
EKM-03 加密和金鑰管理敏感性資料保護
EKM-04 加密和金鑰管理儲存體和存取

CCM、EKM-02 和 EKM-03 建議管理金鑰,以及使用加密通訊協定來保護敏感性資料的原則和程序。 EKM-01 建議所有密碼編譯金鑰都要有可識別的擁有者,以便加以管理。 EKM-04 建議使用標準的演算法。

下列清單顯示可處理此參考中金鑰管理的 CIS 控制措施:

CIS 控制措施識別碼 CIS 控制措施描述
8.1 確定已在所有金鑰上設定到期日。
8.2 確定已在所有祕密上設定到期日。
8.4 確定金鑰保存庫可復原。

CIS 控制措施 8.1 和 8.2 建議針對認證設定到期日,以確保強制執行輪替。 CIS 控制措施 8.4 確保可以還原金鑰保存庫的內容,以維護商務持續性。

應用程式安全性的層面能夠設定基礎,以使用此參考架構來支援 Azure 中的 Spring 工作負載。

後續步驟

透過 Azure Spring Apps 參考架構 (英文) 存放庫中提供的 ARM、Terraform 及 Azure CLI 部署來探索此參考架構。