你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

独立软件供应商 (ISV) 的 Azure 登陆区域注意事项

项目
07/30/2024

对于很多组织而言，Azure 登陆区域概念体系结构代表了其云采用历程中的目标。登陆区域描述了如何构建具有多个订阅的 Azure 环境。每个登陆区域考虑到了规模、安全性、治理、网络和标识，并且是根据许多客户的反馈和经验教训得出的。

提示

将 Azure 登陆区域视为城市规划可能会有所帮助。部署到登陆区域的工作负载架构就像城市中的建筑物计划。

一个城市的水、气、电和交通系统都必须在建造建筑物之前就位。同样，Azure 登陆区域的组件，包括管理组、策略、订阅和基于角色的访问控制 (RBAC)，都必须在部署任何生产工作负载之前就位。

作为在 Azure 上构建和运营你的解决方案的独立软件供应商 (ISV)，你在构建 Azure 环境时应参考以下资源：

Azure 登陆区域：为整个 Azure 环境提供指导。
Azure 架构完善的框架：提供适用于所有工作负载的架构指导。
在 Azure 上构建多租户解决方案：为 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 应用程序：

显示纯 SaaS 部署模型的示意图。用户直接使用部署到 ISV 的 Azure 订阅中的应用程序。

纯 SaaS 软件的示例包括电子邮件即服务、Kafka 即服务、云数据仓库即服务以及 Azure 市场中的许多 SaaS。

如果你是小型 SaaS ISV，则可能不需要使用多个 Azure 订阅来立即部署资源。但随着规模的扩展，Azure 的订阅限制可能会影响你在单个订阅中进行扩展的能力。查看企业级登陆区域设计原则，尤其是订阅民主化，并熟悉多租户的体系结构方法，以规划你的未来增长。

构建纯 SaaS 解决方案的 ISV 应考虑以下问题：

构成我们的 SaaS 解决方案的所有 Azure 资源应该在一个 Azure 订阅中，还是跨多个 Azure 订阅进行分区？
我们应该将每个客户托管在他们自己的专用 Azure 订阅中，还是可以在一个或几个共享订阅中创建资源？
我们如何将部署缩放单元模式应用于我们解决方案的所有层？
我们如何在多租户解决方案中使用 Azure 资源组织来避免面临规模挑战和 Azure 订阅限制？

客户部署

在客户部署模型中，你的最终客户从你那里购买软件，然后将其部署到他们自己的 Azure 订阅中。他们可能会从 Azure 市场启动部署，或者按照说明并使用你提供的脚本手动执行。

在下图中，ISV 提供软件包或 Azure 市场目录产品，用户将该资源与其他工作负载一起部署到他们自己的 Azure 订阅中：

显示客户部署的部署模型的图表。客户将 ISV 提供的资源部署到他们自己的 Azure 订阅中，用户使用这些资源。

图中客户的其他工作负载元素可以表示客户自己的工作负载或客户在其 Azure 订阅中部署的其他 ISV 产品。客户经常将来自不同 ISV 的多个产品部署到他们的 Azure 订阅中。客户结合这些单独的产品来创建解决方案。例如，客户可能会部署来自一个 ISV 的数据库产品、来自另一个 ISV 的网络虚拟设备以及来自第三个 ISV 的 Web 应用程序。

客户部署的 ISV 产品的示例包括 Azure 市场中的许多虚拟机映像（例如网络和存储虚拟设备）和 Azure 应用程序。

对于某些客户部署的解决方案，组织可能会使用 Azure Lighthouse 或 Azure 托管应用程序为其最终客户 Azure 订阅中部署的解决方案提供管理和更新。 ISV、解决方案集成商 (SI) 和托管服务提供商 (MSP) 在满足其特定需求时都可以使用此策略。

从 Azure 登陆区域的角度来看，客户部署的 ISV 解决方案被视为标准应用程序工作负载。在设计产品时请考虑 Azure 登录区域指南，以使用 Azure 客户采用的 Azure 登陆区域设计原则。

在将现有客户的工作负载迁移到 Azure 时，充分理解 Azure 登陆区域概念尤为重要。

构建客户部署解决方案的 ISV 应考虑以下问题：

客户应该将我们的解决方案部署到自己的专用订阅中还是包含相关工作负载的现有订阅中？
客户应如何在现有工作负载（Azure 内部和外部）与我们的解决方案之间建立网络连接？
我们的解决方案是否支持来自 Microsoft Entra ID 的身份验证机制，或者是否需要 LDAP 或 Kerberos 等其他协议？
我们如何减少或消除 Azure Policy 违规行为，例如由我们的解决方案模板与客户的 Azure 政策之间的冲突引起的违规行为？

可能导致违反 Azure Policy 的客户 Azure 策略包括“所有子网必须具有网络安全组”和“不能将公共 IP 地址附加到公司登陆区域中的网络接口”等示例。在规划部署时，请牢记这些可能引发冲突的政策。

双部署 SaaS

某些 SaaS 解决方案与客户的 Azure 订阅中部署的资源进行交互或使用。这种部署模型有时称为双重部署 SaaS 或 SaaS 混合。在下图中，ISV 提供了一个托管的 SaaS 解决方案，该解决方案与部署到最终客户的 Azure 订阅中的资源进行交互：

显示双重部署 SaaS 部署模型的示意图。

双重部署 SaaS 的实际示例 是Microsoft Power BI（一种 SaaS 服务，可以选择使用客户 Azure 订阅中虚拟机上部署的 Power BI 本地数据网关）。

双重部署 SaaS 场景的其他示例包括：

你的组织构建虚拟桌面管理器，该产品提供 SaaS 控制台界面来控制每个客户的 Azure 订阅中的 Azure 虚拟桌面资源。
你的组织为数据分析提供 SaaS 控制台，并在每个客户的 Azure 订阅中动态创建和删除计算节点虚拟机。

作为双重部署 ISV，你应该参考 Azure 登陆区域以获取两个方面的指导：构建你自己的 Azure 环境以托管你的 SaaS 服务，以及确保你在客户的 Azure 订阅中的部署与客户的登陆区域之间的正确交互。

构建双重部署 SaaS 解决方案的 ISV 应考虑以下问题：

我们是否审查了构建纯 SaaS 和客户部署解决方案的所有注意事项？
我们解决方案的哪些组件应该托管在我们的 Azure 订阅中，哪些组件应该由客户部署？
我们如何确保与客户的 Azure 订阅中部署的资源进行安全配置和交互？

Azure 登陆区域设计原则和实施

Azure 的登陆区域设计原则建议与 Azure 原生平台功能保持一致，例如 Log Analytics、Azure Monitor 和 Azure 防火墙。登陆区指南还提供了特定的 Azure 登陆区域实施选项。

作为 ISV，你可能决定实施自己的登陆区域环境。你可能需要使用自己的自动化来跨订阅部署 Azure 资源。或者，你可能希望继续使用已用于日志记录、监控和其他平台层服务的工具。

如果你确实实现了自己的登陆区域环境，我们建议你使用 Azure 登陆区域指南和示例实现作为参考，并将你的方法与经过验证的 Azure 登陆区设计保持一致。

Microsoft Entra 租户

每个 Azure 登陆区域及其管理组层次结构都植根于单个Microsoft Entra 租户中。这意味着需要做出的第一个决定是，Microsoft Entra 租户用作用于管理 Azure 资源的标识源。 Microsoft Entra ID 中的标识包括用户、组和服务主体。

提示

为登陆区域选择的 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名称，如下图所示。

此图显示了 ISV 的 Microsoft Entra 租户选项，其中包含单个企业租户或企业租户与 SaaS Ops 租户之间的分离。

警告

使用多个Microsoft Entra 租户时，管理开销会增加。如果使用 Microsoft Entra ID P1 或 P2 功能（如 Privileged Identity Management），则必须为每个 Microsoft Entra 租户购买单个许可证。如果情况确实需要，最好只使用多个 Microsoft Entra 租户。

避免将单独的 Microsoft Entra 租户用于预生产环境和生产环境。应创建一个Microsoft Entra 租户，而不是创建两个租户，而不是contoso-saas-ops-preprod.comcontoso-saas-ops-prod.com在每个租户下创建单独的 Azure 订阅。你可以使用管理组和 Azure RBAC 来管理对这个单一租户下的订阅和资源的访问。

有关使用多个 Microsoft Entra 租户的详细信息，请参阅 Azure 登陆区域和多个 Microsoft Entra 租户和资源隔离与多个租户。

管理组

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 其下的高层管理组改为。下图演示了此方案：

显示具有单个管理组和每个 SaaS 产品的单独管理组的顶级管理组选项的示意图

平台管理组

在 Azure 登陆区资源组织层次结构中，“平台”管理组包含托管登陆区订阅中的工作负载使用的组件和共享服务的所有 Azure 订阅。部署到平台和共享服务订阅中的组件示例包括集中式日志基础架构（例如 Log Analytics 工作区）、DevOps、安全性、自动化工具、中央网络资源（例如 hub-VNet 和 DDos 保护计划）以及 ISV 的控制平面服务。

“平台”管理组经常划分为“标识”、“管理”和“连接”子组，以便为企业客户提供方便的角色和策略分离。

在你的组织中，你可能有一个团队来管理所有共享平台组件，例如身份、网络和管理。如果是这样，并且你没有计划将管理分离到多个团队，那么请考虑使用单个“平台”管理组。

如果你将有单独的团队来管理集中式平台的不同部分，则应在“平台”管理组下的管理组层次结构中部署更多级别。这允许你为集中式平台的每个部分分配单独的策略。

下图说明了“平台”管理组的两种可能的实现。选项 A 显示了一个更全面的场景，其中“平台”管理组包含三个子管理组：“管理和 DevOps”、“标识和安全”和“连接”。每个子管理组都包含一个具有相关资源的订阅。选项 B 显示了一个更简单的方案，其中“平台”管理组包含单个平台订阅。

显示两个管理组层次结构的图表。选项 A 显示用于管理、连接和身份的单独平台管理组。选项 B 包括带有单个管理组的平台管理组选项。

登陆区域管理组

“登陆区域”管理组包含托管 SaaS 解决方案的实际子系统和工作负载的 Azure 订阅。

此管理组包含一个或多个子管理组。 “登陆区域”下的每个子管理组都代表一个工作负载或子系统原型，具有适用于所有订阅的一致策略和访问要求。使用多个原型的原因包括：

合规性：如果你的 SaaS 产品的子系统需要符合 PCI-DSS，请考虑在“登陆区域”下创建 PCI DSS 原型子管理组。包含 PCI-DSS 合规范围内的资源的所有 Azure 订阅都应放在该管理组中。
层级：考虑为你的 SaaS 解决方案的专用层级客户和免费层级客户创建单独的登陆区原型。每个子管理组都包含不同的 Azure Policy 设置。例如，免费层中的策略可能会将部署限制为仅启用特定的虚拟机 SKU，而专用层中的策略可能需要将资源部署到特定区域。

特定环境管理组

SaaS ISV 通常通过按顺序对其软件开发生命周期环境进行建模来组织其云环境。这通常需要首先部署到开发环境，然后部署到测试环境，然后部署到暂存环境，最后部署到生产环境。

环境之间的一个常见区别是它们的 Azure RBAC 规则，例如谁可以访问每组订阅。例如，DevOps、SaaSOps、开发和测试团队可能都对不同环境具有不同级别的访问权限。

重要

大多数 Azure 客户拥有数百个应用程序，并为每个应用程序团队使用单独的 Azure 订阅。如果每个应用程序都有自己的开发、测试、暂存和生产管理组，那么就会有大量具有几乎相同策略的管理组。对于大多数客户，企业级登陆区域常见问题解答建议不要为每个环境使用单独的管理组。它建议改为在单个管理组中使用单独的订阅。

但是，SaaS ISV 的要求可能与大多数其他 Azure 客户不同，并且在某些情况下可能有充分的理由使用特定于环境的管理组。

SaaS ISV 有时需要对表示同一子系统、应用程序或工作负载的分片或分区的多个订阅进行分组。你可能需要以与原型管理组中明显不同的方式将策略或角色分配应用于订阅组。在这种情况下，请考虑创建与原型管理组下的每个环境相对应的子管理组。

下图说明了两种可能的选择。选项 A 显示了一个场景，每个环境都有单独的订阅，但没有特定于环境的管理组。选项 B 显示了一个 SaaS ISV 场景，在“常规缩放单元”管理组下具有特定于环境的管理组。每个特定于环境的管理组都包含多个订阅。随着时间的推移，ISV 在每个环境中使用一组通用的策略和角色分配在越来越多的订阅中扩展其 Azure 资源。

选择每个选项卡以查看两个图表。