Azure 美金充值 Azure微软云代理商主子帐号管理

别再把主子账号当QQ小号管了：Azure代理商的账号管理，是一场精密外科手术

你是不是也干过这事——给客户开个子账号，顺手把Owner权限一勾，心想“反正他能管自己资源就行”；结果三天后接到电话：“我们测试环境被删了！”“账单怎么突然翻了三倍？”“为什么我看不到自己买的VM？”……别急着甩锅给客户手滑，问题大概率出在你那个看似“省事”的账号配置上。

Azure代理商的主子账号，从来不是简单的“大号带小号”。它是权限、计费、审计、合规四条线拧成的麻花——拧松一根，整根就散。微软设计这套模型时，压根没打算让你用“共享密码+截图教学”的方式交付云服务。它要的是可追溯、可分账、可隔离、可回收的商业级管控能力。

先搞清一个基本事实：Azure里根本没有“子账号”这个官方概念

这是90%新手代理商踩的第一个坑。Azure原生只有用户（User）、组（Group）、服务主体（Service Principal）和托管标识（Managed Identity）。所谓“子账号”，是代理商基于Azure AD租户和RBAC权限模型，自己造出来的业务术语——本质是：在你的AD租户下创建另一个用户的账户，并通过角色分配（Role Assignment）限制其可见范围和操作边界。

换句话说，客户登录的不是“子账号”，而是你租户里的一个普通用户，只是你没给他Global Admin权限，也没让他看到所有资源组。如果这层逻辑没理清，后续所有配置都会跑偏——比如误以为“删除子账号=释放资源”，其实资源还在，只是没人能管了；或者以为“重置密码就能重获控制权”，却忘了客户可能早用Service Principal跑着生产流水线。

主账号不是皇帝，子账号也不是奴才：权限设计的三个铁律

Azure 美金充值 铁律一：永远不用Owner角色授权给客户。Owner=删库跑路权+改账单权+加新用户权。你敢给？客户敢接？真出了事，微软可不管你们合同里写没写“客户自行负责”。实操中，应严格按最小权限原则分配：
• 开发团队 → Contributor（仅限指定RG）+ Reader（全订阅只读）
• 财务人员 → Cost Management Reader + 自定义报表权限
• 运维交接人 → Virtual Machine Contributor + Network Contributor（不含NSG规则修改）

铁律二：资源组（Resource Group）是隔离墙，不是装饰画。很多代理商图省事，让所有客户挤在一个RG里，靠命名区分。但RG是RBAC作用域的最小单元——权限只能按RG、订阅、管理组三级分配。一旦混放，A客户的运维脚本误删B客户的存储账户，连快照都救不回来。正确姿势：每个客户独占1个RG，RG命名带客户ID+环境（如：cust-789-prod），RG锁（Resource Lock）默认启用CanNotDelete。

铁律三：别信“默认权限”，务必显式拒绝。Azure RBAC只有“允许”，没有“拒绝”。如果你没明确禁止某操作，系统就默认放行。曾有案例：代理商给客户分配了Reader角色，但忘了禁用Microsoft.Authorization/roleAssignments/write——客户反手给自己提权到Owner。解决方案？上自定义角色，或直接用Azure Policy强制阻断高危操作（例如禁止任何用户创建Owner角色分配）。

计费分摊：比切蛋糕还难的数学题

客户说：“我要看自己花了多少钱。”你打开Cost Management，发现费用全堆在你主订阅下，按资源组分账？错！RG只是逻辑容器，费用归属取决于资源创建时绑定的Billing Scope。真正的分账钥匙在：Enrollment Account ID和Department字段。

正确姿势：为每个客户创建独立的部门（Department）（需EA Portal操作），所有资源部署时强制指定该Department ID。这样Cost Management才能按部门维度出账单。更狠的招数：用Azure Policy强制校验——任何未标注客户Department的资源创建请求，一律拒绝。顺便提醒：别碰“分账账单（Split Billing）”功能，那是给大型企业定制的，中小代理商用了反而触发微软人工审核，拖慢开票周期。

最痛的真相：你以为的“隔离”，可能正在裸奔

曾有个客户投诉：“我们测试环境的数据库连接字符串，被另一个客户的应用日志打印出来了！”查了一周，发现根源在于——两个客户共用同一个Log Analytics工作区，而工作区的查询权限是按订阅级开放的。这就是典型的隐性数据泄露。

Azure的“隔离感”是幻觉。真正需要检查的盲区包括：
• Key Vault访问策略是否按客户粒度精确控制？
• Application Insights的API密钥是否全局共享？
• Azure Monitor Alerts是否跨RG发送到同一邮箱？
• 网络安全组（NSG）规则是否允许了0.0.0.0/0？

终极建议：每季度执行一次权限审计，用Azure CLI导出所有Role Assignment，用Excel筛出跨客户分配的权限项——别等客户打来电话才补救。

收尾一张表：代理商账号管理自查清单（打印贴工位）

• □ 主租户启用MFA，且强制要求所有管理员使用FIDO2安全密钥
• □ 每个客户拥有独立RG+独立Department+独立Key Vault实例
• □ 客户用户角色全部基于自定义角色，无Owner/Contributor全局分配
• □ 所有生产RG启用CanNotDelete锁，测试RG启用ReadOnly锁
• □ Cost Management报表已配置按Department导出，且客户仅能查看自身部门
• □ 每月自动运行PowerShell脚本，扫描并邮件告警越权角色分配
• □ 与客户签署《云资源使用守则》，白纸黑字写明“账号即责任”

最后说句掏心窝的话：云代理的本质，不是卖许可证，而是卖确定性。客户不怕贵，怕的是账单看不懂、故障找不到人、扩容不敢点——而这一切的起点，就是你给客户开出的那个登录地址、那串用户名、那组权限配置。别把它当成交付流程的最后一个环节，它应该是你整个方案设计的第一块基石。

下次再有人问“怎么快速开个子账号”，请把这篇文章甩过去，然后补一句：“快？那得先慢下来，把权限当代码写，把账单当合同审，把账号当资产管。”