共用方式為

Azure Spring Apps 參考架構

備註

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

本文適用於： ✔️ 標準 ✔️ 企業

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

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

Azure Spring Apps 標準方案是由 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 金鑰保存庫。
  • 內部部署和雲端主機的名稱解析應該是雙向的。
  • 除了控制平面流量以外，不會直接輸出至公用因特網。
  • Azure Spring Apps 部署所管理的資源群組不得修改。
  • Azure Spring Apps 部署所管理的子網不得修改。

下列清單顯示構成設計的元件：

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

下列清單說明此參考架構中的 Azure 服務：

  • Azure Key Vault：硬體支持的認證管理服務，與Microsoft身分識別服務和計算資源緊密整合。

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

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

  • Microsoft Defender for Cloud：適用於內部部署、多雲端和 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 金鑰保存庫。
  • 內部部署和雲端主機的名稱解析應該是雙向的。
  • 除了控制平面流量以外，不會直接出口至公用網際網路。
  • 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 for Cloud：一個統一的安全管理和威脅防護系統，適用於內部部署、多雲環境和 Azure 的工作負載。

  • Azure Spring Apps：這是一個受控服務，專為 Java 型 Spring Boot 應用程式和 .NET 型 Steeltoe 應用程式所設計及優化。

下圖代表架構完善的中樞和輪輻設計，可解決上述需求。 只有中樞虛擬網路會與因特網通訊：

Azure Spring Apps 內部連線能力

Azure Spring Apps 中的應用程式可以與各種 Azure、內部部署和外部資源通訊。 使用中樞和輪輻設計，應用程式可以將流量路由至外部或內部部署網路，使用 Express 路由或站對站虛擬私人網路（VPN）。

Azure 良好架構框架考量

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

成本優化

由於分散式系統設計的性質，基礎結構蔓延是現實。 這種現實會導致非預期且無法控制的成本。 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 中輕鬆監視應用程式和相依性。
  • 您可以使用適用於雲端的 Defender Microsoft，藉由提供平臺來分析和評估所提供的數據，以確保應用程式維護安全性。
  • 服務支援各種部署模式。 如需詳細資訊，請參閱 在 Azure Spring Apps 中設定預備環境。

可靠性

Azure Spring Apps 建置在 AKS 上。 雖然 AKS 透過叢集提供復原層級，但此參考架構會進一步納入服務和架構考慮，以在元件失敗時增加應用程式的可用性。

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

安全

此架構的安全性可藉由遵守業界定義的控制項和基準來解決。 在此內容中，「控件」表示簡潔且定義完善的最佳做法，例如「實作資訊系統存取時採用最低許可權原則」。 IAM-05“ 此架構中的控件來自雲端安全性聯盟（CSA）的雲端控制矩陣（CCM），以及因特網安全性中心（CIS）的Microsoft Azure 基礎基準（MAFB）。 在套用的控件中，重點在於治理、網路和應用程式安全性的主要安全性設計原則。 您必須負責處理身分識別、存取管理和記憶體的設計原則，因為它們與您的目標基礎結構相關。

治理

此架構所解決治理的主要層面是透過隔離網路資源來實現分隔。 在 CCM 中，DCS-08 建議數據中心的輸入和輸出控制。 為了滿足控件，架構會使用網路安全組 （NSG） 的中樞和輪輻設計來篩選資源之間的東西部流量。 此架構還會篩選中樞中的中央服務與輪輻中的資源之間的流量。 此架構會使用 Azure 防火牆的實例來管理因特網與架構內資源之間的流量。

下列清單顯示此參考中資料中心安全性的控制項：

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

網路

支援此架構的網路設計衍生自傳統中樞和輪輻模型。 此決策可確保網路隔離是基本建構。 CCM 控制 IVS-06 建議在受信任和不受信任的環境之間限制和監視網路與虛擬機之間的流量。 此架構透過執行 NSG 來控制東西向流量（位於「數據中心」內），以及使用 Azure 防火牆來控制南北向流量（位於「數據中心」外）。 CCM 控制IPY-04建議基礎結構應使用安全的網路協定，在服務之間交換數據。 支援此架構的 Azure 服務都會使用標準安全通訊協定，例如 HTTP 和 SQL 的 TLS。

下列清單顯示此參考中解決網路安全性的 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 Apps 的客戶責任 中所列出的網路和應用程式規則。

應用程式安全性

此設計原則涵蓋身分識別、資料保護、金鑰管理和應用程式設定的基本元件。 根據設計，在 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 部署來探索此參考架構。

  • Last updated on