共用方式為

Azure 登陸區域的獨立軟體廠商 （ISV） 考慮

  • 發行項

對於許多組織， Azure 登陸區域 概念架構代表其雲端採用旅程的目的地。 登陸區域描述如何使用多個訂用帳戶建置 Azure 環境。 每個登陸區域都會考慮調整、安全性、治理、網路和身分識別，並根據許多客戶學到的意見反應和教訓。

提示

將 Azure 登陸區域視為城市計畫很有説明。 部署到登陸區域的工作負載架構就像是城市建築物的計畫。

城市的水、天然氣、電力和交通系統都必須到位，才能建造建築物。 同樣地，Azure 登陸區域的元件，包括管理群組、原則、訂用帳戶和角色型存取控制（RBAC），都必須就緒，才能部署任何生產工作負載。

身為在 Azure 上建置及操作解決方案的獨立軟體廠商 （ISV），您應該在建置 Azure 環境時參考下列資源：

Azure 登陸區域可協助您選擇整體 Azure 環境的方向。 但是，身為 ISV、SaaS 提供者或啟動，您的特定實作需求可能會與更標準的客戶案例不同。 以下是幾個不同的實作案例範例：

  • 您可以建置客戶部署到自己的訂用帳戶的軟體。
  • 您有自己的 控制平面 ，並使用自動化腳本或軟體來部署及設定 SaaS 解決方案的 Azure 資源。
  • 您是小型 ISV 或初創公司，且想要以最低的可能成本開始，而且可能不想一開始使用 Azure 防火牆 和 Azure DDoS 保護等服務。
  • 您是大型 SaaS ISV，並計畫將 SaaS 應用程式分割成多個訂用帳戶以進行調整。 您也想要將訂用帳戶分組，使其對應至您的開發、測試、預備和生產環境。
  • 貴組織的作業模型會分隔公司 IT 小組和 SaaS 產品小組的角色。 貴組織的公司 IT 小組可能會管理 Microsoft Office 365 和 Microsoft Teams 等資源，而您的 SaaS 產品小組可能負責建置及操作您的 SaaS 產品（包括其中央平臺和身分識別元件）。

注意

有時候，ISV 只想要從單一 Azure 訂用帳戶開始，其中包含平臺「共用服務」層面和實際工作負載資源。 雖然在技術上是可能的，但當您需要在訂用帳戶之間移動資源，併發現並非所有 資源類型都可以移動 時，您將會面臨挑戰。 檢閱 設計偏差 的影響，以瞭解哪些偏差是可能的，以及其各種風險層級。

ISV 部署模型

ISV 解決方案通常適合三種部署模型之一：純 SaaS、客戶部署或雙部署 SaaS。 本節說明每個模型對於 Azure 登陸區域的不同考慮。

純 SaaS

在純 SaaS 模型中，您的軟體只會完全部署在 Azure 訂用帳戶中。 終端客戶不需要在自己的 Azure 訂用帳戶中部署軟體，即可取用您的軟體。 在下圖中，使用者使用的是 ISV 所提供的純 SaaS 應用程式：

Diagram that shows a pure SaaS deployment model. A user directly uses the application deployed into the I S V's Azure subscription.

純 SaaS 軟體的範例包括電子郵件即服務、Kafka 即服務、雲端資料倉儲即服務，以及 Azure Marketplace 中的許多 SaaS 清單。

如果您是小型 SaaS ISV，您可能不需要使用多個 Azure 訂用帳戶立即部署資源。 但是當您調整規模時，Azure 的訂用帳戶限制可能會影響您在單一訂用帳戶內調整的能力。 檢閱 企業級登陸區域設計原則 ，特別是訂用帳戶大眾化，並熟悉 多租使用者 規劃未來成長的架構方法。

建置純 SaaS 解決方案的 ISV 應考慮下列問題：

  • 組成 SaaS 解決方案的所有 Azure 資源是否都在一個 Azure 訂用帳戶中，或跨多個 Azure 訂用帳戶進行分割？
  • 我們應該將每位客戶裝載在自己的專用 Azure 訂用帳戶中，或者是否可以在一或多個共用訂用帳戶內建立資源？
  • 如何將部署戳記（縮放單位）模式 套用 至我們解決方案的所有層？
  • 如何在多租使用者解決方案 中使用 Azure 資源組織，讓我們無法面臨規模挑戰和 Azure 訂用帳戶限制？

客戶部署

在客戶部署的模型中，您的終端客戶會從您購買軟體，然後將其部署至自己的 Azure 訂用帳戶。 他們可能會從 Azure Marketplace 起始部署，或依照您提供的指示和使用腳本手動進行部署。

在下圖中，ISV 提供軟體套件或 Azure Marketplace 目錄產品，而使用者會將該資源與其他工作負載一起部署到自己的 Azure 訂用帳戶：

Diagram that shows a customer-deployed deployment model. A customer deploys resources provided by the ISV into their own Azure subscription, and users use those resources.

圖表 中的客戶其他工作負載元素可以代表客戶自己的工作負載 ，或客戶在其 Azure 訂用帳戶內部署的另一個 ISV 產品。 客戶經常將來自不同 ISV 的多個產品部署到其 Azure 訂用帳戶。 它們結合這些個別產品來建立解決方案。 例如，客戶可能會從一個 ISV 部署資料庫產品、另一個 ISV 的網路虛擬裝置，以及來自第三個 ISV 的 Web 應用程式。

客戶部署的 ISV 產品範例包括 Azure Marketplace 中的許多 虛擬機器映射 （例如網路和儲存體虛擬裝置）和 Azure 應用程式 。

對於某些客戶部署的解決方案，組織可能會使用 Azure Lighthouse 或 Azure 受控應用程式 ，為其終端使用者 Azure 訂用帳戶內部署的解決方案提供管理和更新。 ISV、解決方案整合者（SIS）和受控服務提供者（MSP）都可以在符合其特定需求時使用此策略。

從 Azure 登陸區域的觀點來看，客戶部署的 ISV 解決方案會被視為標準應用程式工作負載。 當您設計產品以配合 Azure 客戶採用的 Azure 登陸區域設計原則 時，請考慮 Azure 登陸區域指引 。

當您將現有客戶的工作負載移轉至 Azure 時，請務必充分瞭解 Azure 登陸區域概念。

建置客戶部署解決方案的 ISV 應該考慮下列問題：

  • 客戶是否應該將解決方案部署到自己的專用訂用帳戶，或部署到包含相關工作負載的現有訂用帳戶？
  • 客戶應如何建立現有工作負載（Azure 內外）與解決方案之間的網路連線？
  • 我們的解決方案是否支援來自 Microsoft Entra ID 的驗證機制，或需要 LDAP 或 Kerberos 等其他通訊協定？
  • 我們如何減少或消除Azure 原則違規，例如解決方案範本與客戶 Azure 原則之間發生衝突所造成的違規？

可能導致Azure 原則違規的客戶 Azure 原則包括「所有子網都必須有網路安全性群組」和「無法將公用 IP 位址附加至公司登陸區域中的網路介面」等範例。 當您規劃部署時，請記住這些造成衝突的原則的可能性。

雙重部署 SaaS

某些 SaaS 解決方案會與客戶 Azure 訂用帳戶中部署的資源互動或使用。 此部署模型有時稱為 雙重部署 SaaS 或 SaaS 混合式 。 在下圖中，ISV 提供裝載的 SaaS 解決方案，其會與部署到終端客戶的 Azure 訂用帳戶中的資源互動：

Diagram that shows a dual deployment SaaS deployment model.

雙重部署 SaaS 的實際範例 是 Microsoft Power BI，這是一項 SaaS 服務，可選擇性地使用部署在客戶 Azure 訂用帳戶中虛擬機器上的 Power BI 內部部署資料閘道。

雙重部署 SaaS 案例 的其他範例包括：

  • 您的組織會建置 Virtual Desktop Manager，此產品提供 SaaS 主控台介面來控制每個客戶 Azure 訂用帳戶中的 Azure 虛擬桌面資源。
  • 您的組織提供 SaaS 主控台來進行資料分析，並動態建立和刪除每個客戶的 Azure 訂用帳戶中的計算節點虛擬機器。

身為雙重部署 ISV，您應該參閱 Azure 登陸區域，以取得兩個領域的指引：建構您自己的 Azure 環境來裝載您的 SaaS 服務，並確保客戶 Azure 訂用帳戶和客戶登陸區域中的部署之間有適當的互動。

建置雙重部署 SaaS 解決方案的 ISV 應該考慮下列問題：

  • 我們是否已檢閱所有建置純 SaaS 和客戶部署解決方案的考慮？
  • 解決方案的哪些元件應該裝載在我們的 Azure 訂用帳戶中，以及哪些元件應該由客戶部署？
  • 如何確保與客戶 Azure 訂用帳戶中部署的資源進行安全布建和互動？

Azure 登陸區域設計原則和實作

Azure 的登陸區域設計原則 建議與 Log Analytics、Azure 監視器和Azure 防火牆等 Azure 原生平臺功能一致。 登陸區域指引也會提供特定的 Azure 登陸區域實作選項 。

身為 ISV，您可以決定實作自己的登陸區域環境。 您可能需要使用自己的自動化，跨訂用帳戶部署 Azure 資源。 或者，您可能想要繼續使用您已經用於記錄、監視和其他平台層服務的工具。

如果您確實實作自己的登陸區域環境，建議您使用 Azure 登陸區域指引和範例實作來參考，並將您的方法與經證實的 Azure 登陸區域設計保持一致。

Microsoft Entra 租使用者

每個 Azure 登陸區域及其管理群組階層都根植于單一 Microsoft Entra 租使用者中。 這表示您需要做出的第一個決策是哪些 Microsoft Entra 租使用者要用來作為管理 Azure 資源的身分識別來源。 Microsoft Entra 識別碼中的身分識別包括使用者、群組和服務主體。

提示

您為登陸區域選取的 Microsoft Entra 租使用者不會影響您的應用程式層級驗證。 不論您選擇的租使用者為何，您仍然可以使用其他身分識別提供者，例如 Azure AD B2C。

Azure 登陸區域和 Microsoft Entra 租使用者的指引強烈建議使用單一 Microsoft Entra 租 使用者，而且在大部分情況下，這是正確的方法。 不過，身為 SaaS ISV，您可能有理由使用兩個租使用者。

對於某些 SaaS ISV，一個小組會管理公司資源，另一個小組會操作 SaaS 解決方案。 此區隔可能是基於操作原因或符合法規需求。 也許不允許您的公司 IT 小組管理任何 SaaS 相關訂用帳戶和資源，因此他們不能是 Microsoft Entra 租使用者的系統管理員。 如果此案例適用于您，請考慮使用兩個不同的 Microsoft Entra 租使用者：一個租使用者用於公司 IT 資源，例如 Office 365，另一個租使用者用於組成 SaaS 解決方案的 Azure 資源。

每個 Microsoft Entra 租使用者都必須有自己的功能變數名稱。 如果您的組織使用兩個租使用者，您可以選擇公司 Microsoft Entra 租使用者和 contoso-saas-ops.com SaaS Microsoft Entra 租使用者的名稱 contoso.com ，如下圖所示。

Diagram that shows Microsoft Entra tenant options for ISVs with a single corporate tenant or separation between corporate and SaaS Ops tenants.

警告

當您使用多個 Microsoft Entra 租使用者時，您的管理額外負荷會增加。 如果您使用 Privileged Identity Management 等 Microsoft Entra ID P1 或 P2 功能，則必須為每個 Microsoft Entra 租使用者購買個別授權。 如果您的情況確實需要，最好只使用多個 Microsoft Entra 租使用者。

避免針對生產前和生產環境使用個別的 Microsoft Entra 租使用者。 您應該建立一個 Microsoft Entra 租使用者，而不是在每個租使用者下建立兩個租使用者，例如 contoso-saas-ops-preprod.com 和 contoso-saas-ops-prod.com 使用不同的 Azure 訂用帳戶。 您可以使用管理群組和 Azure RBAC 來管理此單一租使用者下的訂用帳戶和資源存取權。

如需使用多個 Microsoft Entra 租使用者的詳細資訊，請參閱 Azure 登陸區域和多個 Microsoft Entra 租使用者 ，以及 使用 Microsoft Entra 白皮書 保護 Azure 環境。

管理群組

Azure 登陸區域概念架構 建議使用特定的管理群組階層。 不過，ISV 的需求與其他組織不同。 本節說明 ISV 組織可能選擇採用與登陸區域概念架構建議不同做法的一些方式。

最上層管理群組

您的管理群組階層會巢狀于 Azure 建立 的租使用者根群組管理群組 之下。 您不會直接使用 租使用者根群組 。

一個標準組織，其擁有集中式公司 IT 小組來管理其平臺和共用服務（例如記錄、網路、身分識別和安全性）通常會在 Azure 建立 的租使用者根群組下建立一個最上層管理群組，並將其餘的管理群組 部署在其下方。 此最上層管理群組通常以組織本身命名（例如 Contoso ）。

身為 SaaS ISV，您可能會有一個 SaaS 產品，或者您可能有幾個個別的 SaaS 產品或企業營運。 雖然您通常應該使用相同的 Microsoft Entra 租使用者來管理所有產品的 Azure 資源（如 Microsoft Entra 租 使用者一節所述 ），但在某些情況下，您可能會選擇部署多個管理群組階層。

請考慮產品彼此獨立的方式，並詢問自己：

  • 我們的產品是否都針對 DevOps、身分識別、安全性、連線和記錄使用相同的平臺？
  • 這些共用服務是否由單一中央小組運作？

如果您回答 這兩個問題是，請在租使用者根群組下 建立單一最上層 SaaS 產品 管理群組 。

如果您改為回答 否 ，而且每個 SaaS 產品都是由不同的平臺小組管理及操作，請考慮為每個產品建立個別的最上層管理群組，例如兩個最上層管理群組 SaaS Product-01 和 SaaS Product-02 。

提示

一個 ISV 擁有一個以上的最上層管理群組並不常見。 通常，數個產品可以結合在一起，因為其管理與運作方式有相似之處。

此管理方法類似于 企業級登陸區域的 測試方法。 不過，與其在租使用者根群組下建立 Contoso 和 Contoso-Canary ，在此方法中，範例公司會改為建立產品特定的 Contoso-SaaS-Product-01 、 Contoso-SaaS-Product-02 和 Contoso-SaaS-Product-03 最上層管理 群組。 下圖說明此案例：

Diagram that shows top-level management group options with a single management group and separate management groups for each of the SaaS products

平臺管理群組

在 Azure 登陸區域資源組織階層 中 ，平臺 管理群組包含裝載登陸區域訂用帳戶中工作負載所使用的元件和共用服務的所有 Azure 訂用帳戶。 部署到平臺和共用服務訂用帳戶的元件範例包括集中式記錄基礎結構（例如 Log Analytics 工作區）、DevOps、安全性、自動化工具、中央網路資源（例如 hub-VNet 和 DDos Protection 方案），以及 ISV 的控制平面服務。

平臺 管理群組經常分割成 身分識別 、 管理和 連線性 子群組，為企業客戶提供方便的角色和原則分隔。

在您的組織中，您可能會有一個小組來管理所有共用平臺元件，例如身分識別、網路和管理。 若是如此，而且您沒有計劃跨多個小組分隔該管理，請考慮使用單 一平臺 管理群組。

如果您改為有個別小組來管理集中式平臺的不同部分，您應該在平臺 管理群組下 的管理群組階層中部署進一步層級。 這可讓您為集中式平臺的每個部分指派個別的原則。

下圖說明平臺 管理群組的兩個可能實作 。 選項 A 會顯示更全面的案例，其中 平臺 管理群組包含三個子管理群組： 管理與 DevOps 、 身分識別和安全性 ，以及 連線ivity 。 每個子管理群組都包含具有相關資源的訂用帳戶。 選項 B 顯示更簡單的案例，其中 平臺 管理群組包含單一平臺訂用帳戶。

Diagram that shows two management group hierarchies. Option A shows separate platform management groups for management, connectivity, and identity. Option B includes a platform management group option with a single management group.

登陸區域管理群組

登 陸區域 管理群組包含裝載 SaaS 解決方案實際子系統和工作負載的 Azure 訂用帳戶。

此管理群組包含一或多個子管理群組。 登陸區域 下 的每個子管理群組都代表工作負載或子系統 原型 ，並具有應套用至所有訂用帳戶的一致原則和存取需求。 使用多個原型的原因包括：

  • 合規性： 如果您的 SaaS 產品的子系統必須符合 PCI-DSS 規範，請考慮在登陸區域 下 建立 PCI DSS 原型子管理群組。 所有包含 PCI-DSS 合規性範圍內資源的 Azure 訂用帳戶都應該放在該管理群組內。
  • 階層： 請考慮為 SaaS 解決方案的 專用 層客戶和 免費 層客戶建立個別登陸區域原型。 每個子管理群組都包含不同的Azure 原則設定。 例如，免費層中的原則可能會限制部署只啟用特定的虛擬機器 SKU，而專用層中的原則可能需要將資源部署到特定區域。

環境特定的管理群組

SaaS ISV 通常會依序將其軟體發展生命週期環境模型化來組織其雲端環境。 這通常需要先部署至 開發 環境，再 部署到測試 環境，再 部署到預備 環境，最後部署至 生產 環境。

環境之間的其中一個常見差異是其 Azure RBAC 規則，例如誰可以存取每個訂用帳戶群組。 例如，DevOps、SaaSOps、開發和測試小組可能都有不同層級的不同環境存取權。

重要

大部分的 Azure 客戶都有數百個應用程式，並針對每個應用程式小組使用不同的 Azure 訂用帳戶。 如果每個應用程式都有自己的開發、測試、預備和生產管理群組，則會有大量具有相同原則的管理群組。 對於大多數客戶， 企業級登陸區域常見問題 建議不要針對每個環境使用不同的管理群組。 建議改用單一管理群組內的個別訂用帳戶。

不過，SaaS ISV 可能會有與其他大多數 Azure 客戶不同的需求，而且在某些情況下，可能會有充分的理由使用環境特定的管理群組。

SaaS ISV 有時需要將多個訂用帳戶分組，這些訂用帳戶代表 相同子系統、應用程式或工作負載的分區 或 分割區。 您可能需要以明顯不同于原型管理群組的方式，將原則或角色指派套用至訂用帳戶群組。 在此情況下，請考慮建立對應至原型管理群組下每個環境的子管理群組。

下圖說明兩個可能的選項。 選項 A 會顯示一個案例，每個環境都有個別的訂用帳戶，但沒有環境特定的管理群組。 選項 B 顯示 SaaS ISV 案例，其中包含一般戳記 管理群組下 的環境特定管理群組。 每個環境特定的管理群組都包含多個訂用帳戶。 經過一段時間，ISV 會在每個環境中調整其 Azure 資源，以一組常見的原則和角色指派來增加訂用帳戶數目。

選取每個索引標籤以查看兩個圖表。

已解除委任和沙箱管理群組

Azure 登陸區域 資源組織指引 建議，包括 解除委任 和 沙箱 管理群組，直接位於最上層管理群組下方。

已 解除委任的管理群組是停用且最終會刪除的 Azure 訂用帳戶保留位置。 您可以將不再使用的訂用帳戶移至此管理群組，以追蹤該訂用帳戶，直到永久刪除訂用帳戶中的所有資源為止。

沙箱 管理群組通常包含 用於探索用途 的 Azure 訂用帳戶，並對其套用鬆散或沒有套用原則。 例如，您可以為個別開發人員提供自己的訂用帳戶來進行開發和測試。 您可以將一般原則和治理套用至這些訂用帳戶，方法是將它們放在沙箱 管理群組中 。 這可增加開發人員的靈活度，並讓他們輕鬆地實驗 Azure。

重要

沙箱管理群組中的 訂用帳戶 不應該直接 連線到登陸區域訂 用帳戶。 避免將沙箱訂用帳戶連線到生產工作負載，或連線到鏡像生產環境的任何非生產環境。

下圖說明兩個可能的選項。 選項 A 不包含 已解除委任 和 沙箱 管理群組，而選項 B 則為 。

Diagram that shows the Decommissioned and Sandboxes management groups on the same level as the Platform and Landing Zones management groups.

範例 ISV 登陸區域

本節包含 SaaS ISV 的兩個範例 Azure 登陸區域結構。 選取每個索引標籤來比較兩個範例登陸區域。

下圖顯示具有下列特性的 SaaS ISV Azure 登陸區域階層範例：

Diagram that shows an example Azure landing zone hierarchy for an ISV. Most of the components from this article are omitted.

下一步