|
|
相关文章推荐
对于很多组织而言， Azure 登陆区域 概念体系结构代表了其云采用历程中的目标。 登陆区域描述了如何构建具有多个订阅的 Azure 环境。 每个登陆区域考虑到了规模、安全性、治理、网络和标识，并且是根据许多客户的反馈和经验教训得出的。
将 Azure 登陆区域视为城市规划可能会有所帮助。 部署到登陆区域的工作负载架构就像城市中的建筑物计划。
一个城市的水、气、电和交通系统都必须在建造建筑物之前就位。 同样，Azure 登陆区域的组件，包括管理组、策略、订阅和基于角色的访问控制 (RBAC)，都必须在部署任何生产工作负载之前就位。
作为在 Azure 上构建和运营你的解决方案的独立软件供应商 (ISV)，你在构建 Azure 环境时应参考以下资源：
Azure 登陆区域可帮助你为整个 Azure 环境选择方向。 但作为 ISV、SaaS 提供商或初创公司，你的具体实施需求可能与更标准的客户场景有所不同。 以下只是几个不同的实现场景示例：
有时，ISV 只想从一个包含平台“共享服务”方面和实际工作负载资源的 Azure 订阅开始。 尽管这在技术上是可行的，但稍后当你需要在订阅之间移动资源并发现 并非所有资源类型都可以移动 时，你将面临挑战。 评审 设计偏差 的影响，了解哪些偏差是可能的以及它们的各种风险级别。
ISV 部署模型
ISV 解决方案通常适合以下三种部署模型之一：纯 SaaS、客户部署或双重部署 SaaS。 本部分介绍每个模型对 Azure 登陆区域的不同注意事项。
纯 SaaS
在纯 SaaS 模型中，你的软件仅完全部署在你的 Azure 订阅中。 最终客户无需在自己的 Azure 订阅中部署即可使用你的软件。 在下图中，用户正在使用 ISV 提供的纯 SaaS 应用程序：
纯 SaaS 软件的示例包括电子邮件即服务、Kafka 即服务、云数据仓库即服务以及 Azure 市场中的许多 SaaS 。
如果你是小型 SaaS ISV，则可能不需要使用多个 Azure 订阅来立即部署资源。 但随着规模的扩展，Azure 的订阅限制可能会影响你在单个订阅中进行扩展的能力。 查看 企业级登陆区域设计原则 ，尤其是订阅民主化，并熟悉 多租户的体系结构方法 ，以规划你的未来增长。
构建纯 SaaS 解决方案的 ISV 应考虑以下问题：
在客户部署模型中，你的最终客户从你那里购买软件，然后将其部署到他们自己的 Azure 订阅中。 他们可能会从 Azure 市场启动部署，或者按照说明并使用你提供的脚本手动执行。
在下图中，ISV 提供软件包或 Azure 市场目录产品，用户将该资源与其他工作负载一起部署到他们自己的 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 Policy 的客户 Azure 策略包括“所有子网必须具有网络安全组”和“不能将公共 IP 地址附加到公司登陆区域中的网络接口”等示例。 在规划部署时，请牢记这些可能引发冲突的政策。
双部署 SaaS
某些 SaaS 解决方案与客户的 Azure 订阅中部署的资源进行交互或使用。 这种部署模型有时称为双重部署 SaaS 或 SaaS 混合。 在下图中，ISV 提供了一个托管的 SaaS 解决方案，该解决方案与部署到最终客户的 Azure 订阅中的资源进行交互：
双重部署 SaaS 的实际示例 是Microsoft Power BI（一种 SaaS 服务，可以选择使用客户 Azure 订阅中虚拟机上部署的 Power BI 本地数据网关）。
双重部署 SaaS 场景的其他示例包括：
作为双重部署 ISV，你应该参考 Azure 登陆区域以获取两个方面的指导：构建你自己的 Azure 环境以托管你的 SaaS 服务，以及确保你在客户的 Azure 订阅中的部署与客户的登陆区域之间的正确交互。
构建双重部署 SaaS 解决方案的 ISV 应考虑以下问题：
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
名称，如下图所示。
使用多个Microsoft Entra 租户时，管理开销会增加。 如果使用 Microsoft Entra ID P1 或 P2 功能（如 Privileged Identity Management），则必须为每个 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 租户 和资源 隔离与多个租户 。
Azure 登陆区域概念体系结构 建议使用特定的管理组层次结构。 但是，ISV 可能有与其他组织不同的要求。 本节介绍了你的 ISV 组织可能会选择采用的一些方法，这些方法不同于与登陆区域概念体系结构建议不同的做法。
高层管理组
你的管理组层次结构嵌套在 Azure 创建的租户根组管理组下。 你不直接使用租户根组。
拥有一个集中的企业 IT 团队来管理其平台和共享服务（如日志记录、网络、身份和安全）的标准组织通常会在 Azure 创建的租户根组下创建一个顶级管理组，并部署其余的管理它下面的组。 这个顶级管理组通常以组织本身命名（例如 Contoso）。
作为 SaaS ISV，你可能拥有一个 SaaS 产品，或者你可能拥有几个单独的 SaaS 产品或业务线。 虽然通常应该使用相同的Microsoft Entra 租户来管理所有产品的 Azure 资源（如Microsoft Entra 租户 部分所述 ），但在某些情况下，可以选择部署多个管理组层次结构。
考虑你的产品彼此之间的独立程度，并思考以下问题：
如果你对这两个问题的回答都是肯定的，请在租户根组下创建一个顶级 SaaS 产品管理组。
如果你的回答是否定的，并且你的每个 SaaS 产品由不同的平台团队管理和运营，请考虑为每个产品创建一个单独的顶级管理组，例如以下两个顶级管理组：SaaS Product-01 和 SaaS Product-02。
一个 ISV 拥有多个顶级管理组的情况并不常见。 通常，由于管理和操作方式的相似性，可以将多个产品组合在一起。
这种管理方式类似于 企业级登录区域的测试方式 。 但是，在此方法中，示例公司不会在租户根组下创建 Contoso 和 Contoso-Canary，而是创建特定于产品的 Contoso-SaaS-Product-01、Contoso-SaaS-Product-02 和 Contoso-SaaS-Product -03 其下的高层管理组改为。 下图演示了此方案：
平台管理组
在 Azure 登陆区资源组织层次结构 中，“平台”管理组包含托管登陆区订阅中的工作负载使用的组件和共享服务的所有 Azure 订阅。 部署到平台和共享服务订阅中的组件示例包括集中式日志基础架构（例如 Log Analytics 工作区）、DevOps、安全性、自动化工具、中央网络资源（例如 hub-VNet 和 DDos 保护计划）以及 ISV 的控制平面服务。
“平台”管理组经常划分为“标识”、“管理”和“连接”子组，以便为企业客户提供方便的角色和策略分离。
在你的组织中，你可能有一个团队来管理所有共享平台组件，例如身份、网络和管理。 如果是这样，并且你没有计划将管理分离到多个团队，那么请考虑使用单个“平台”管理组。
如果你将有单独的团队来管理集中式平台的不同部分，则应在“平台”管理组下的管理组层次结构中部署更多级别。 这允许你为集中式平台的每个部分分配单独的策略。
下图说明了“平台”管理组的两种可能的实现。 选项 A 显示了一个更全面的场景，其中“平台”管理组包含三个子管理组：“管理和 DevOps”、“标识和安全”和“连接”。 每个子管理组都包含一个具有相关资源的订阅。 选项 B 显示了一个更简单的方案，其中“平台”管理组包含单个平台订阅。
登陆区域管理组
“登陆区域”管理组包含托管 SaaS 解决方案的实际子系统和工作负载的 Azure 订阅。
此管理组包含一个或多个子管理组。 “登陆区域”下的每个子管理组都代表一个工作负载或子系统原型，具有适用于所有订阅的一致策略和访问要求。 使用多个原型的原因包括：
特定环境管理组
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 包括。
示例 ISV 登陆区域
本部分包括 SaaS ISV 的两个示例 Azure 登陆区域结构。 选择每个选项卡以比较两个示例登录区域。
下图显示了具有以下特征的示例 SaaS ISV Azure 登陆区域层次结构：
推荐文章