Azure 权益号 微软云 Azure 账号多子号管理

前言：别让“多子号”变成“多灾难”

你以为开了个 Azure 账号就万事大吉？错。Azure 生态里，“账号”只是聊天时的简称，真正影响你能不能用、能用什么、花多少钱、谁来管的，是租户（Tenant）、订阅（Subscription）、资源组（Resource Group），以及它们背后的访问控制（RBAC）和治理体系（管理组、策略）。

于是问题来了：当你的业务分成多个团队、多个项目、多个环境（开发/测试/生产），甚至需要分给不同客户或不同合作方时，“多子号管理”就变成了日常工作，而不是口头上的“我们开几个账号呗”。如果管理方式不对，轻则权限乱套、成本失控，重则合规事故。

下面这篇文章，我会用不装神秘、可直接照做的方式，把“微软云 Azure 账号多子号管理”讲清楚：到底该怎么分、怎么给权限、怎么控成本、怎么审计、怎么避免踩坑。你看完就能落地做一套属于你自己的多子号治理方案。

先搞清楚：Azure 里的“多子号”到底指什么

在很多中文语境里，“多子号”可能指几种不同情况。为了避免你做着做着发现“怎么和我想的不一样”，我们先把常见定义掰开揉碎：

1）多订阅：同一个租户下的“多号”

最常见的“多子号”，其实是多个订阅。比如：同一个企业邮箱租户下，你为不同业务线建了订阅 A、订阅 B、订阅 C。这样你可以集中治理（管理组/策略），也能把成本和权限切得更干净。

2）多租户：不同公司/不同合作方的“多号”

如果你需要把某个合作方完全隔离到另一个目录（租户）里，那么就会出现多租户。这时权限边界更强，但管理会更复杂，需要更明确的协作方式。

3）多环境：开发/测试/生产的分离

很多团队会用多个订阅来隔离环境，例如 Dev 订阅、Test 订阅、Prod 订阅。这样生产不容易被“误操作”拖下水。

总体策略：你应该怎么设计你的多子号架构

Azure 的治理最佳实践通常围绕一个核心思想：层级治理 + 最小权限 + 可审计 + 可追踪成本。你可以把它当成“四件套”，缺一件都不舒服。

建议方案：管理组（Management Groups）+ 订阅（Subscriptions）

Azure 权益号 如果你是在同一个租户里做多子号管理，常见结构是：

• 管理组：按组织架构/业务线/环境分层
• 订阅：承载资源与计费边界
• RBAC 角色：按人员/组授予最小权限
• 策略（Azure Policy）：统一规则，如强制打标签、限制资源类型、要求加防火墙等

这样你的“子号”不只是几个账号，而是一套可治理、可扩展的体系。

什么时候用多租户？什么时候不用？

• 建议多租户：合作方要完全隔离、合规要求强、或需要把身份体系完全分开。
• 建议单租户多订阅：大多数企业内部管理，身份统一，成本和权限更容易集中。

大多数读者的场景都属于第二种：单租户多订阅，然后用管理组把“子号”按秩序排好。

实操部分一：在 Azure 中创建并组织多订阅

我们从最基础的“多子号”骨架开始。你要做的是：在同一个租户（或目标租户）下创建多个订阅，并按管理组组织它们。

步骤 1：进入 Azure 管理门户，确认你在哪个目录（租户）

打开 Azure 门户后，通常在右上角会看到“目录 + 订阅”的切换入口。你要做的第一件事是：确认当前你操作的是目标租户。

这一步的意义非常大：很多“怎么找不到订阅/权限不对”的问题，根源就是你在另一个目录里打转。

步骤 2：创建订阅（如果你还没有）

创建订阅的方式取决于你是通过企业协议（EA）、CSP 还是其他渠道。无论哪种，核心思路一致：

• 给订阅取一个能看懂的名称：例如 Prod-核心业务、Dev-研发平台、Test-测试环境等。
• 尽量统一命名规则：后面 RBAC、策略、报表会更省事。

如果你的订阅已经存在，也不用慌，直接进入后面的“绑定管理组”和“RBAC 授权”即可。

步骤 3：创建管理组层级，把订阅挂进去

管理组的作用是：你不用对每个订阅重复设置策略和权限，你可以在管理组层级统一下发规则。

一个实用的层级示例：

• 根管理组：YourCompany
• 子管理组：Production、Development、Testing
• 再细分：Production-业务线A、Production-业务线B

然后把对应订阅分别加入。例如：

• 业务线 A 的生产订阅 → 挂到 Production-业务线A
• 业务线 A 的测试订阅 → 挂到 Testing-业务线A

从此你就把“子号”变成了有组织的队列，而不是散落的存储桶。

实操部分二：用 RBAC 管理“谁能对哪个子号做什么”

有了订阅和管理组，下一步就是让人类不互相伤害。RBAC 的目标是：最小权限、清晰责任、可追踪。

步骤 1：建立角色分工模型（别一上来就让所有人 Owner）

很多团队的经典事故是：图省事，把某些人直接给了 Owner。然后你猜怎么着？他能删资源、能改策略、还能动计费相关设置。你以为自己买的是云服务，其实买的是“权限随缘”。

建议的分工思路是：

• 订阅级别：授予管理订阅所需的权限（例如创建资源、管理网络等）
• 资源组级别：对更细粒度的资源授予权限
• 读权限：财务、审计、运维查看用（避免他们“能改”）

角色选择要根据你业务需要，典型常见的角色有：

• 读者（Reader）：只读查看
• 参与者（Contributor）：可创建/管理资源，但通常不具备管理权限
• 所有者（Owner）：通常只给少数平台管理员

步骤 2：以“用户组”为单位授予权限（强烈推荐）

别直接对单个用户授权。你要做的是：

• 创建 AAD 用户组，如：Azure-Prod-Platform-Admins、Azure-Dev-TeamA-Readers 等
• 把人员加入组
• 在订阅或管理组层级给组分配角色

好处是：人员变更时，你只需要改组成员，不用反复动权限“点点点”。

步骤 3：在管理组/订阅/资源组三个层级选择合适的授权范围

你可以在不同层级授予 RBAC 角色：

• 管理组：适合“全公司统一规则”（例如所有 Production 订阅都允许某些读权限）
• 订阅：适合“某业务线整体管理权限”
• 资源组：适合“某个项目/某个应用的细粒度权限”

经验法则：权限越敏感，范围越小。

实操部分三：用 Azure Policy 把“子号管理”变成自动化治理

你可以把 RBAC 理解为“门票”，Azure Policy 理解为“门禁规则”。没有 Policy 的世界是：大家想怎么配就怎么配，直到出事。你加了 Policy，规则就变成了自动筛选器。

常用治理目标（建议你至少上两条）

Azure 权益号 以下是企业里最常见、也最有效的策略目标：

• 强制资源必须打标签（例如 CostCenter、Owner、Environment）
• 限制不允许的资源类型（避免误建/违规服务）
• 要求启用安全设置（例如网络策略、加密要求等）
• 禁止在不允许的区域创建资源（例如合规地区限制）

一步到位：从管理组层级下发策略

如果你在多个订阅之间反复维护策略，那你会很快被“重复劳动”消耗掉。正确做法是：在管理组层级下发策略。这样所有挂在该管理组下面的订阅都自动生效。

比如：你可以在 Production 管理组下发策略，要求必须打 CostCenter 标签；在 Development 管理组可以宽松一些，但也至少要求 Owner 标签存在。

策略配合豁免：别让运维被你逼疯

现实世界总有例外。你可以建立“豁免流程”：当某个项目短期无法满足策略时，可以由平台管理员审批后做 Policy exemption，并设定到期时间。

否则你会遇到这种情景：策略一开，所有人都在提工单，“怎么都不能创建资源？”这不是他们不懂，是你没有告诉他们“为什么”。

实操部分四：成本与计费的“多子号”分账思路

多子号管理最现实的诉求之一就是：钱得分清楚。Azure 的计费和成本分析通常按订阅维度。

建议你用订阅作为基本的计费边界

你可以把每个子号（订阅）当成一个“财务账本”。然后：

• 用资源标签细化到项目/业务
• 用管理组策略确保标签一致
• 用成本分析报表把钱拉出来给对应团队

别只盯“订阅”，标签是成本拆分的关键

很多团队一开始不打标签，结果就是：成本报表只显示“这个月 Production 订阅花了多少钱”，无法回答“具体是谁用了”。时间久了财务会开始怀疑人生，运维也会开始怀疑你。

所以在策略里强制标签基本是必做项。至少：

• Environment：Dev/Test/Prod
• Azure 权益号 Owner：应用负责人或团队
• CostCenter：成本中心/项目号

实操部分五：审计与合规——谁在你的子号里干了什么

RBAC 负责“给谁权限”，日志与审计负责“发生了什么”。这两者缺一不可。

开启活动日志与诊断日志（按需）

常见做法是：

• 订阅级别保留活动日志
• 对关键资源开启诊断日志并导出到集中存储或日志服务
• 建立告警规则（例如异常失败、权限变更、敏感操作）

如果你只在出事后翻日志，那你就会像在深夜找钥匙——找到之前已经把自己气醒了。

审计重点：权限变更、策略变更、网络与密钥相关操作

建议你把关注点放在：

• 角色分配（RBAC）变更
• 策略（Policy）豁免/修改
• 关键资源（例如 Key Vault、网络安全组规则）变更

这样你能在事故早期就定位问题，而不是等到线上炸了才想“是谁开的”。

常见坑位避雷清单（看完你少踩 80%）

下面这些是我见过的最常见“多子号管理事故现场”。你可以对照看看你有没有踩：

坑 1：把“多订阅”当成“多账号”，导致权限边界错配

很多人以为开了新订阅就相当于新账号，结果发现身份权限还是互通的（同租户下）。解决方案：明确 RBAC 授权范围，并用管理组分层管理。

坑 2：所有人都给 Owner，出了事先怪云

云当然不会替你“擦屁股”。你要做的是限制 Owner 数量，把大多数权限交给更合适的角色，并通过资源组层级收敛权限。

坑 3：没有统一的命名和标签规范

没有命名和标签，你的成本报表就像一锅混乱的粥：看着能吃，但分不清是谁做的。

坑 4：策略开得太猛，缺少豁免流程

策略一上来就“拒绝一切”，团队会立刻对抗。建议建立豁免流程和到期时间。

坑 5：只管订阅不管管理组

如果你每加一个订阅就要手动配置 RBAC/策略，那你会越来越累。管理组是为了让你“少点鼠标”。

一套可落地的“多子号管理模板”（你可以直接照抄）

下面我给你一个更具体的模板。你可以把它当作你们公司的 Azure 治理起步方案。

模板：管理组层级

• MG-Root（根）
• MG-Prod
• MG-Dev
• MG-Test
• MG-Prod-业务线A
• MG-Prod-业务线B
• MG-Dev-业务线A
• MG-Test-业务线A

模板：订阅与命名

• sub-Prod-业务线A
• sub-Prod-业务线B
• sub-Dev-业务线A
• sub-Test-业务线A

模板：RBAC 角色分配

• 组 A（Platform-Admins）：对 MG-Root 或关键管理组拥有适度管理权限（少数人）
• 组 B（Prod-Team-Readers）：对 MG-Prod 下只读
• 组 C（Dev-Team-Contrib）：对 MG-Dev 下参与者
• 组 D（App-Specific-Admins）：对特定资源组管理

模板：策略（Policy）

• Azure 权益号 强制标签：Environment、Owner、CostCenter
• 限制区域：Production 限制特定 region
• 禁止某些资源类型：例如不允许在 Production 新建实验性服务
• 要求资源符合安全基线：例如启用加密/安全设置

进阶：多租户协作的“子号管理”要点

如果你确实需要多租户（例如合作方、客户隔离），建议你建立协作规则：

• Azure 权益号 明确“身份来自谁”：合作方的用户组还是你自己的目录？
• 明确“权限怎么给”：用共享订阅权限还是使用管理组边界？
• 明确“日志怎么追”：你是否能看到对方在你的资源上的关键操作？

多租户并不是不能做，而是你必须把边界画清楚，否则你会发现：明明谁都说“我授权了”，但资源仍然不通。

最后的建议：把管理当成流程，而不是一次性配置

Azure 的“多子号管理”最怕什么？不是你现在不会配置，而是你把配置当成一次性工程。现实会不断变化：人员流动、项目变更、环境升级、预算调整、合规要求变化。

所以你要做的不是“把参数填完”，而是建立流程：

• 订阅如何创建（申请、审批、命名规范）
• 权限如何变更（RBAC、用户组、到期时间）
• 标签与成本如何治理（策略、报表、责任人）
• 审计如何留痕（日志、告警、复盘机制）

当这套流程跑起来，你的多子号管理就不会变成“天天救火”。它会变成你团队效率的外挂。

结语：你不是在管账号，你是在管一套系统

把 Azure 的多子号管理做对，你会得到四个好处：权限清晰、成本可控、合规可证、运维省心。把管理做错，你得到的通常是三个字：加班多。

希望这篇文章能让你少走弯路。下一步，你可以先拿当前的业务现状做一次盘点：你到底需要多订阅还是多租户？你现在的权限是怎么给的？你有没有强制标签？然后按文中模板搭一套“能长期用”的治理结构。

如果你愿意，也可以把你们现有的订阅数量、环境划分方式（Dev/Test/Prod）、以及当前权限授予方式告诉我，我可以帮你把模板进一步定制成更贴合你们的版本。毕竟，云治理这事儿，最忌的是“照搬别人家的锅”，而要“做成自己的烹饪习惯”。