Azure Landing Zones：企业级云治理的分层模型与PowerShell实践

简介：本资源是面向Azure云架构师与政府云迁移工程师的PowerShell自动化部署方案，聚焦Microsoft Azure政府（MAG）环境下的企业级着陆区（Landing Zones）落地实践。它基于Cloud Adoption Framework（CAF）最新参考架构，扩展支持MAG合规要求，并提供企业规模治理、多订阅网络隔离、身份集成及用户登陆区模板等关键能力，适用于政务云迁移、等保合规建设与大型应用上云场景。压缩包为ZIP格式，共3.02MB，虽未提供具体文件明细，但内容预览显示包含部署脚本、参数配置模板及分步操作指南，核心以PowerShell脚本为主，辅以说明文档，支撑从基础架构搭建到企业服务启用的全流程自动化。目前已有196人学习下载，读者可直接获取MAG适配的企业级着陆区完整部署框架、政府云专属配置要点、模块化模板结构（如管理组层级设计、策略分配逻辑、用户登陆区部署顺序），以及与CAF标准架构的对齐说明，显著降低政务云环境的架构设计与实施门槛。

1. Azure Landing Zones 不是模板库，而是企业级云治理的“施工蓝图”：它解决的是权限混乱、环境漂移、合规断点这三类高频翻车现场

你有没有遇到过这样的场景：刚上线一个生产环境，安全团队突然发来整改单——资源组没打标签、Key Vault 没启用软删除、SQL Server 缺少 TDE 加密；或者开发团队提了个紧急需求，运维却卡在“这个网络策略到底该配在订阅级还是管理组级”上反复对齐三天；更典型的是，多个项目并行时，A 团队用 ARM 模板部署，B 团队用 Terraform，C 团队直接 Portal 点点点，三个月后整个订阅像被不同工种轮番装修过的毛坯房，连谁改过 NSG 规则都查不清。Azure Landing Zones（ALZ）就是微软针对这类“云上基建失序”问题给出的系统性解法——它不是一堆可即插即用的脚本合集，而是一套经过大规模客户验证的分层治理结构 + 可裁剪策略框架 + 自动化部署流水线。核心价值不在“快”，而在“稳”：把订阅划分、角色分配、网络拓扑、日志归集、合规基线这些容易被跳过的“脏活累活”，提前固化成可版本化、可审计、可灰度发布的工程产物。适合正在从单项目上云转向多业务线规模化上云的团队，尤其当你开始被 SOC2 审计、GDPR 数据驻留或内部 ITSM 流程倒逼着建标准时，ALZ 就不是“可选项”，而是避免重复造轮子、防止权限雪崩的后悔药。

2. ALZ 的核心不是代码，而是四层治理模型：Management Group → Subscription → Resource Group → Policy Assignment 的职责切分逻辑

ALZ 的设计哲学，本质是把传统数据中心里“机房-机柜-服务器-应用”的物理隔离思维，映射到云的逻辑层级中。它强制你回答三个关键问题：谁拥有决策权？谁承担执行成本？谁为安全结果负责？答案就藏在这四层结构里。下面拆解每层的技术含义和 ALZ 的典型实现方式，重点说明为什么不能跳过某一层直接开干。

2.1 Management Group 层：不是容器，而是“策略发射台”与“权限锚点”

在 ALZ 架构中，Management Group（MG）是顶层治理单元，但它的作用远不止于组织订阅。ALZ 默认构建Tenant Root Group→Corp/Online/Sandbox三级 MG 结构，其中CorpMG 承载所有生产相关订阅，OnlineMG 管理互联网暴露面（如 Web 应用、API 网关），SandboxMG 则专供临时实验。关键点在于：所有跨订阅的强制策略（如“所有虚拟机必须启用托管身份”“所有存储账户必须禁用 HTTP”）必须在此层部署。原因很简单——Policy Assignment 在 MG 级生效范围最大，且支持enforcementMode: Default（默认强制）和enforcementMode: DoNotEnforce（仅审计）两种模式。若你在订阅级部署同一条策略，当新订阅加入 MG 时，该策略不会自动继承，导致治理断点。

提示：ALZ 的managementGroups目录下，deploy.ps1脚本会调用New-AzManagementGroup创建 MG，并通过New-AzManagementGroupSubscription关联订阅。但实际落地时，不要手动运行此脚本——它只处理初始结构，后续 MG 变更（如重命名、移动订阅）必须走Update-AzManagementGroup，否则会导致 Policy Assignment 失效。我见过某团队因直接修改 Portal 中 MG 名称，导致 17 个订阅的 DDoS 防护策略全部脱管。

2.2 Subscription 层：按责任域而非技术栈划分，ALZ 强制定义五类标准订阅类型

ALZ 对订阅的分类不是按“开发/测试/生产”，而是按责任主体与风险等级。其标准模板定义了五类订阅：

• identity：仅承载 Azure AD B2C、Managed Identity 等身份服务，禁止部署任何计算资源；
• management：部署 Log Analytics、Azure Monitor、Sentinel 等监控与安全中心，严禁部署业务应用；
• connectivity：专用于虚拟 WAN、ExpressRoute、VPN Gateway 等网络骨干，要求所有资源启用 Private Link；
• landingzones：业务系统部署区，按业务线（如finance-apps,hr-systems）进一步划分子 MG；
• sandbox：开发者自助实验区，启用 Budget Alert 与 Auto-Shutdown。

这种划分的底层逻辑是：让 RBAC 权限能按责任边界精准切割。例如，网络团队只能管理connectivity订阅，财务团队只能操作finance-apps下的资源组，而安全团队通过management订阅统一查看所有日志。若你把所有业务塞进一个prod订阅，再用 Resource Group 做隔离，RBAC 就会退化成“全有或全无”的粗粒度控制，审计时根本无法追溯“谁在何时修改了哪个数据库的防火墙规则”。

2.3 Resource Group 层：ALZ 的“最小可审计单元”，所有资源必须归属且命名带环境标识

在 ALZ 中，Resource Group（RG）不是资源容器，而是成本核算、策略执行、备份恢复的原子单位。ALZ 强制要求 RG 命名遵循rg-{env}-{service}-{region}格式（如rg-prod-sql-westeurope），其中{env}必须是prod/nonprod/dev之一。这个看似简单的命名规则，实则绑定三大机制：

• Cost Management：Azure Cost Analysis 按 RG 聚合账单，prodRG 的费用自动计入生产预算；
• Policy Enforcement：Allowed Locations策略在 RG 级部署，确保rg-prod-*只能在指定区域创建资源；
• Backup & DR：Azure Backup 以 RG 为单位配置保留策略，rg-nonprod-*可设为 7 天保留，rg-prod-*则强制 90 天。

注意：ALZ 的deploy.ps1脚本在创建 RG 时会自动附加tags（如"Environment": "prod"），这些 tag 是后续 Policy 中field":"tags['Environment']"的匹配依据。若手动创建 RG 未加 tag，策略将静默失效——这是新手最常踩的坑，现象是“明明策略显示已分配，但新 VM 还是能建在非授权区域”。

2.4 Policy Assignment 层：ALZ 的“数字宪法”，80% 的合规检查靠 Initiateive 而非单条 Policy

ALZ 的 Policy 不是零散规则，而是打包成Initiative（计划）的策略组合。例如Deploy-Diagnostics-SettingsInitiative 包含 5 条 Policy：启用诊断日志、设置存储账户、配置 Log Analytics 工作区、设置事件中心、设置保留天数。这种打包逻辑的关键在于：Initiative 支持参数化继承。当你在CorpMG 级部署该 Initiative 时，可传入参数-Parameter @{'logAnalyticsWorkspaceId'='/subscriptions/xxx/resourcegroups/rg-mgmt/providers/microsoft.operationalinsights/workspaces/mgmt-workspace'}，所有子订阅自动复用该工作区 ID，无需逐个订阅配置。而单条 Policy 无法传递参数，导致每个订阅都要单独维护日志目标地址，运维成本指数级上升。

ALZ 提供的policySetDefinitions目录中，Deploy-Log-Analytics和Enable-Azure-Monitor-for-VMs是高频启用的两个 Initiative。前者确保所有资源日志流向统一工作区，后者则自动为 VM 安装依赖扩展（如 Dependency Agent）。但要注意：Initiative 的mode必须设为All（而非Microsoft.Resources/subscriptions/resourceGroups），否则无法对非 RG 级资源（如 Key Vault、SQL Server）生效。某次我帮某公司排查“SQL Server 日志未采集”问题，最终发现就是mode配错，导致策略只扫描 RG 内部资源，漏掉了顶级 SQL Server 实例。

3. PowerShell 是 ALZ 的“唯一官方驱动器”：从本地调试到 CI/CD，所有自动化链路都绕不开 Az.Accounts 与 Az.Resources 模块

ALZ 的官方交付物（GitHub 上的Azure/Enterprise-Scale仓库）完全基于 PowerShell 开发，这不是历史包袱，而是刻意为之的设计选择。PowerShell 的强类型、管道机制和 Azure CLI 不具备的深度对象操作能力，让它成为处理 ALZ 这类“多层级、强依赖、需状态校验”的治理任务的最佳载体。下面详解 ALZ 自动化流程中 PowerShell 的不可替代性，以及如何规避模块版本陷阱。

3.1 ALZ 的核心脚本链：deploy.ps1→validate.ps1→update.ps1的职责分工

ALZ 的自动化不是单脚本暴力执行，而是三阶段渐进式流程：

# deploy.ps1：初始化治理骨架（只运行一次） .\scripts\deploy.ps1 -Location 'West Europe' -ManagementGroupId 'corp' -Verbose

该脚本完成四件事：创建 MG 结构、关联订阅、部署基础 Policy Initiative（如Deny-Public-IP）、配置management订阅的 Log Analytics 工作区。关键参数-ManagementGroupId必须与 Azure AD 中的 MG ID 严格一致（如corp，而非显示名称Corporate），否则后续所有 Policy Assignment 将失败。错误现象是Get-AzPolicyAssignment返回空，但Get-AzManagementGroup显示 MG 存在——根源在于 ALZ 内部用Get-AzManagementGroup -GroupId $ManagementGroupId查找，ID 不匹配即返回$null。

# validate.ps1：治理健康度快照（每次变更前必跑） .\scripts\validate.ps1 -ManagementGroupId 'corp' -PolicySetName 'Deploy-Diagnostics-Settings'

该脚本不修改任何资源，而是调用Get-AzPolicyState获取指定 Initiative 下所有 Policy 的合规状态，并生成 CSV 报告。输出包含ResourceId,PolicyDefinitionName,ComplianceState,Timestamp四列。这是 ALZ 最被低估的价值点：它把“合规”从人工抽查变成可量化指标。例如，当ComplianceState为NonCompliant的资源数超过阈值（如 5 个），CI/CD 流水线应自动阻断发布。

# update.ps1：增量更新（日常维护主力） .\scripts\update.ps1 -ManagementGroupId 'corp' -PolicySetName 'Enable-Azure-Monitor-for-VMs' -ParameterFile '.\parameters\monitor-params.json'

该脚本用于更新已部署 Initiative 的参数（如更换 Log Analytics 工作区）。注意：它不重新部署 Policy，而是调用Set-AzPolicyAssignment修改现有 Assignment 的Parameters字段。若你误用deploy.ps1重跑，会导致 Policy Assignment 重复创建，引发策略冲突（如两个Deny-Public-IPAssignment 同时生效，但参数不同）。

3.2 Az 模块版本陷阱：ALZ v6+ 强制要求 Az.Accounts 3.0+，但旧版脚本会静默降级

ALZ 的 GitHub 仓库明确要求Az.Accounts >= 3.0.0，因为Connect-AzAccount -UseDeviceAuthentication在旧版中不支持 MFA 设备登录模式。但实际落地时，很多团队本地 PowerShell 环境仍为Az.Accounts 2.12.1，此时运行deploy.ps1会出现诡异现象：脚本显示“连接成功”，但后续Get-AzManagementGroup返回空。原因在于Connect-AzAccount在低版本中会自动降级到Az.Accounts 2.x的兼容模式，而 ALZ 的Get-AzManagementGroup调用依赖3.0+的Microsoft.Azure.PowerShell.Cmdlets.Resources.ManagementGroups.dll。

解决方案不是升级全局模块，而是在脚本开头强制加载指定版本：

# 在 deploy.ps1 开头插入 $requiredVersion = '3.0.0' if (-not (Get-Module -ListAvailable -Name Az.Accounts | Where-Object {$_.Version -ge $requiredVersion})) { Install-Module -Name Az.Accounts -RequiredVersion $requiredVersion -Force -AllowClobber } Import-Module -Name Az.Accounts -RequiredVersion $requiredVersion -Force

提示：ALZ 的 CI/CD 流水线（如 Azure DevOps Pipeline）必须显式声明pwsh任务的azurePowerShellVersion: 'LatestVersion'，否则默认使用Az.Accounts 2.x，导致流水线在本地能跑通，上线后失败。

3.3 PowerShell 的“状态感知”能力：ALZ 如何用Get-AzPolicyState替代人工巡检

ALZ 的validate.ps1脚本核心是Get-AzPolicyStatecmdlet，它能查询 Azure Policy 的实时评估结果。但直接调用有两大坑：

1. 分页限制：默认只返回 100 条记录，需手动处理NextLink：

$states = Get-AzPolicyState -ManagementGroupName 'corp' -Filter "PolicyDefinitionAction eq 'deny'" -Top 100 while ($states.Count -lt $totalExpected) { $nextStates = Get-AzPolicyState -NextLink $states.NextLink $states += $nextStates }

2. 时间戳偏差：Timestamp字段是策略评估完成时间，非资源创建时间。若某 VM 在评估周期内创建，ComplianceState可能仍为Compliant。ALZ 的最佳实践是：在validate.ps1中增加Wait-PSJob等待策略评估完成，而非依赖静态快照。

# 等待策略评估（ALZ v6+ 内置） Start-Sleep -Seconds 30 # 等待基础评估 $assessment = Get-AzPolicyStateSummary -ManagementGroupName 'corp' while ($assessment.NonCompliantResources -gt 0 -and $assessment.EvaluationTime -lt (Get-Date).AddMinutes(-5)) { Start-Sleep -Seconds 60 $assessment = Get-AzPolicyStateSummary -ManagementGroupName 'corp' }

这段代码确保validate.ps1输出的是“最新评估结果”，而非缓存数据。某次我们发现Deny-Public-IP策略显示 100% 合规，但实际仍有 3 台 VM 暴露公网 IP，根源就是未等待评估完成，脚本读取了 2 小时前的缓存状态。

4. 避坑：ALZ 实施中最常被忽略的五个“玄学”问题及血泪解决方案

ALZ 的文档写得极尽详尽，但真实落地时，80% 的失败源于文档未覆盖的“环境上下文”。以下是我在多个客户现场踩过的坑，按发生频率排序，每条都附带可立即验证的诊断命令和修复步骤。

4.1 现象：deploy.ps1执行到 70% 卡住，日志显示New-AzManagementGroupSubscription : Operation returned an invalid status code 'Conflict'

原因：目标订阅已被其他 MG（如默认的Tenant Root Group）托管，ALZ 脚本尝试将其移动到新 MG 时触发并发冲突。Azure 的 MG 移动操作是独占锁，若同一订阅正被 Portal 或其他脚本操作，就会返回 Conflict。
解决：

1. 先确认订阅当前归属：Get-AzSubscription -SubscriptionId 'xxx' | Select-Object Name, State, ManagementGroupId
2. 若ManagementGroupId非空，先解除绑定：Remove-AzManagementGroupSubscription -GroupId 'current-group-id' -SubscriptionId 'xxx'
3. 等待 2 分钟（Azure 后台清理缓存），再运行deploy.ps1

4.2 现象：Policy Assignment 显示已部署，但新创建的 Storage Account 仍允许 HTTP 访问

原因：Deploy-Storage-AccountsInitiative 中的Deny-HTTP-AccessPolicy 使用了field:"type"匹配，但 ALZ v5+ 的 Policy 定义中，Storage Account 的 type 是Microsoft.Storage/storageAccounts，而某些旧版 ARM 模板创建的 Storage Account type 为Microsoft.Storage/storageAccounts/blobServices（因启用了 Blob 服务）。Policy 无法匹配后者。
解决：

1. 检查违规资源 type：Get-AzResource -ResourceId '/subscriptions/xxx/resourceGroups/rg-prod-storage/providers/Microsoft.Storage/storageAccounts/myaccount' | Select-Object ResourceType
2. 若返回Microsoft.Storage/storageAccounts/blobServices，需在 Policy Rule 中扩展 type 匹配：

"if": { "anyOf": [ { "field": "type", "in": ["Microsoft.Storage/storageAccounts", "Microsoft.Storage/storageAccounts/blobServices"] } ] }

3. 用update.ps1更新 Initiative 参数。

4.3 现象：validate.ps1报告ComplianceState=NonCompliant，但Get-AzResource查不到对应资源

原因：Policy 评估对象是资源的“策略状态快照”，而非实时资源。当资源被删除后，其 Policy State 记录仍保留 72 小时（Azure 默认 TTL）。validate.ps1读取的是快照，而非当前资源列表。
解决：

1. 确认资源是否真存在：Get-AzResource -ResourceId '/subscriptions/xxx/resourceGroups/rg-dev/providers/Microsoft.Web/sites/myapp' -ErrorAction SilentlyContinue
2. 若返回空，则是快照残留，无需处理；若需清理快照，调用Remove-AzPolicyState（需 Owner 权限）
3. 长期方案：在 CI/CD 中增加Clean-Up-Stale-Policy-States步骤，每天执行一次。

4.4 现象：connectivity订阅中的 Virtual WAN 无法被landingzones订阅的 VM 访问

原因：ALZ 的Deploy-Virtual-WANInitiative 默认启用Disable-Default-Routing，但未同步配置VirtualHubRouteTable的propagatedRouteTables。结果是 WAN 的路由表未向分支传播，VM 流量无法到达。
解决：

1. 获取 Virtual Hub ID：Get-AzResource -ResourceType 'Microsoft.Network/virtualHubs' | Where-Object {$_.ResourceGroupName -eq 'rg-connectivity-vwan'}
2. 更新路由表传播：

$hub = Get-AzResource -ResourceId '/subscriptions/xxx/resourceGroups/rg-connectivity-vwan/providers/Microsoft.Network/virtualHubs/myhub' $routeTable = Get-AzResource -ResourceId "$($hub.Id)/hubRouteTables/defaultRouteTable" $routeTable.Properties.propagatedRouteTables.labels = @("defaultRouteTable") Set-AzResource -ResourceId $routeTable.Id -Properties $routeTable.Properties -Force

4.5 现象：management订阅的 Log Analytics 工作区无法收集identity订阅的 Azure AD 日志

原因：ALZ 的Deploy-Diagnostics-SettingsInitiative 默认只启用AuditLogs和SignInLogs，但 Azure AD 日志需额外启用DirectoryAudit和RiskDetections，且identity订阅的 Diagnostic Settings 必须指向management订阅的工作区 ID，而非本地工作区。
解决：

1. 在identity订阅中，手动创建 Diagnostic Settings：

$workspaceId = '/subscriptions/yyy/resourcegroups/rg-mgmt/providers/microsoft.operationalinsights/workspaces/mgmt-workspace' Set-AzDiagnosticSetting -ResourceId '/providers/microsoft.aadiam' -WorkspaceId $workspaceId -Enabled $true -Category 'AuditLogs', 'SignInLogs', 'DirectoryAudit', 'RiskDetections'

2. 关键：-ResourceId '/providers/microsoft.aadiam'是全局资源 ID，非订阅级路径，必须用此格式。

5. 进阶技巧：用 PowerShell 构建 ALZ 的“双轨验证”机制——Policy 合规性 + 资源拓扑一致性

ALZ 的终极目标不是“策略全绿”，而是“架构符合设计意图”。我见过太多团队 Policy 报告 100% 合规，但实际网络拓扑却严重偏离 ALZ 白皮书：比如connectivity订阅的 ExpressRoute Gateway 被错误关联到landingzones订阅的 VNet，导致流量绕行；或identity订阅的 Key Vault 未启用 Private Endpoint，所有认证请求直连公网。这些问题 Policy 无法捕获，因为它们不违反“规则”，只违背“架构契约”。为此，我设计了一套“双轨验证”机制，在validate.ps1基础上叠加拓扑校验，真正实现“所见即所得”。

5.1 第一轨：Policy 合规性验证（ALZ 原生能力增强）

ALZ 的validate.ps1已足够强大，但默认只输出 CSV。我们将其升级为“可中断的 CI/CD 门禁”：

# enhanced-validate.ps1 $complianceReport = .\scripts\validate.ps1 -ManagementGroupId 'corp' -PolicySetName 'All-Core-Policies' $nonCompliantCount = ($complianceReport | Where-Object {$_.ComplianceState -eq 'NonCompliant'}).Count # 设置门禁阈值：非合规资源数 > 3 则失败 if ($nonCompliantCount -gt 3) { Write-Error "ALZ Compliance Gate Failed: $nonCompliantCount non-compliant resources found" exit 1 } else { Write-Host "ALZ Compliance Gate Passed: $nonCompliantCount non-compliant resources" } # 生成 HTML 报告（供人工复核） $complianceReport | ConvertTo-Html -Fragment | Out-File 'alz-compliance-report.html'

提示：All-Core-Policies是我们自定义的 Initiative，聚合了Deny-Public-IP,Require-Tag-Environment,Enable-Diagnostics-Settings等 12 条核心策略。ALZ 原生的Deploy-Core-ComponentsInitiative 仅含 5 条，需按需扩展。

5.2 第二轨：资源拓扑一致性验证（ALZ 原生能力外挂）

这才是真正的“防翻车”核心。我们编写validate-topology.ps1，校验三层关键关系：

# validate-topology.ps1 核心逻辑（VNet 连接校验示例） function Test-VNetConnectionIntegrity { $gateways = Get-AzVirtualNetworkGateway -ResourceGroupName 'rg-connectivity-vwan' foreach ($gw in $gateways) { $connections = Get-AzVirtualNetworkGatewayConnection -VirtualNetworkGatewayName $gw.Name -ResourceGroupName $gw.ResourceGroupName foreach ($conn in $connections) { if ($conn.ConnectionType -eq 'Vnet2Vnet') { # 提取 RemoteVnetId 的订阅 ID $remoteSubId = ($conn.RemoteVnetId -split '/')[2] if ($remoteSubId -ne (Get-AzSubscription -SubscriptionName 'connectivity').Id) { Write-Warning "VNet Connection $($conn.Name) points to subscription $remoteSubId, not 'connectivity'" return $false } } } } return $true }

5.3 双轨融合：生成“架构健康度仪表盘”

将两轨结果合并，生成可交互的 HTML 仪表盘：

# dashboard.ps1 $policyResult = .\enhanced-validate.ps1 $topologyResult = .\validate-topology.ps1 $dashboardData = [PSCustomObject]@{ PolicyCompliance = @{ Total = $policyResult.Count NonCompliant = ($policyResult | Where-Object {$_.ComplianceState -eq 'NonCompliant'}).Count PassRate = [math]::Round((1 - ($policyResult | Where-Object {$_.ComplianceState -eq 'NonCompliant'}).Count / $policyResult.Count) * 100, 1) } TopologyIntegrity = @{ VNetConnections = $topologyResult.VNetConnections PrivateEndpoints = $topologyResult.PrivateEndpoints KeyVaultSecurity = $topologyResult.KeyVaultSecurity OverallPass = $topologyResult.OverallPass } } # 生成 HTML（省略具体渲染代码，使用 ConvertTo-Html + CSS） $dashboardData | ConvertTo-Html -Fragment | Out-File 'alz-dashboard.html'

这个仪表盘在 CI/CD 中作为最终门禁：只有PolicyCompliance.PassRate >= 95且TopologyIntegrity.OverallPass -eq $true时，才允许发布到prod订阅。某次我们拦截了一个“Policy 全绿但 VNet 连接错绑”的发布，避免了生产环境长达 4 小时的网络抖动。

从那以后我每次启动 ALZ 部署，都强制走一遍enhanced-validate.ps1+validate-topology.ps1双轨验证，哪怕多花 3 分钟。因为云上基建的代价，从来不是脚本多跑几秒，而是故障时那几十分钟的定位黑洞。希望帮到你。

本文还有配套的精品资源，点击获取