简介：本资源是面向Azure云架构师与政府云迁移工程师的PowerShell自动化部署方案，聚焦Microsoft Azure政府（MAG）环境下的企业级着陆区（Landing Zones）落地实践。它基于Cloud Adoption Framework（CAF）最新参考架构，扩展支持MAG合规要求，并提供企业规模迁移、绿地开发所需的治理框架、网络分层、身份集成及多订阅管理模板。压缩包为3.02MB的ZIP文件，含PowerShell脚本、ARM/Bicep部署模板、参数配置文件及详细操作指南，其中PowerShell脚本承担核心自动化部署任务，模板文件支撑可重复的基础设施即代码（IaC）交付。目前已有196人学习下载，读者可直接复用整套MAG适配的着陆区部署流程，获取从企业级管理组结构搭建、平台服务模板（如用户登陆区）到跨订阅治理策略的完整实施方案，显著降低政府云环境的架构设计与实施门槛。

1. Azure Landing Zones 是什么：不是模板，而是云治理的“施工图”和“验收标准”

很多人第一次看到Azure Landing Zones，下意识以为是某个一键部署的 ARM 模板或 Terraform 模块——点几下就生成一整套生产环境。结果真去跑，要么卡在权限报错上，要么资源建好了却连不上企业 AD，要么安全策略形同虚设，最后发现：这根本不是“开箱即用”的盒子，而是一套可落地、可审计、可演进的云基础设施治理框架。它解决的不是“怎么在 Azure 上起虚拟机”，而是“当 5 个业务部门、3 种合规要求（GDPR/ISO27001/等保）、2 套 CI/CD 流水线同时要上云时，如何让所有人用同一套命名规范、同一套网络分段逻辑、同一套日志归集路径、同一套 RBAC 权限基线”。它面向的是云平台团队、企业架构师、安全合规负责人和 DevOps 工程师——不是单个开发者。你不需要从零写 Policy，但必须理解每条 Policy 背后的控制意图；你不需要手敲 200 行 Bicep，但得知道哪个模块管订阅拓扑、哪个模块控日志路由、哪个模块决定 Key Vault 的密钥轮换周期。它不承诺“省事”，但能让你在第 100 个新业务上线时，依然能快速回答审计官：“这个数据库的加密密钥由谁管理？访问日志存哪？网络流量是否经过 NSG 和 Azure Firewall 双重检查？”——这才是 Azure Landing Zones 的真实价值：把云治理从“人肉约定”变成“代码化契约”。

2. 为什么必须用 Landing Zones 而不是自己拼凑：从三个血泪翻车现场说起

2.1 翻车现场一：权限失控——“管理员”账号成了全租户后门

某金融客户初期用一个 Global Admin 账号手动创建了所有资源，半年后发现：

• 所有生产数据库的 Owner 都是该账号；
• 无法追溯谁在何时删了关键 NSG 规则；
• 审计要求“最小权限”时，才发现 87% 的用户被赋予了 Contributor 级别权限，远超其实际需要。

Landing Zones 的解法：强制采用Privileged Identity Management (PIM)+Role-Based Access Control (RBAC) 分层模型。它不只定义“谁有权限”，更定义“权限何时生效、持续多久、需经谁审批”。例如，Subscription Owner角色默认禁用，仅在 PIM 中按需激活 2 小时；Network Contributor权限只授予Networking-Team组，且该组成员必须通过 Azure AD 条件访问策略（如 MFA 强制+设备合规）才能获得临时访问权。

2.2 翻车现场二：网络混沌——VNet 对等互连像蜘蛛网，安全边界形同虚设

另一个客户把 12 个业务系统分别部署在独立 VNet，再靠 40+ 条对等连接打通。结果：

• 一次误操作删除了中心 VNet 的路由表，导致 7 个系统断网；
• 安全团队无法在单一位置部署 WAF 或防火墙规则；
• 合规检查时发现，开发测试环境与生产环境之间竟存在直连路由。

Landing Zones 的解法：推行Hub-Spoke 网络拓扑 + Azure Firewall Manager 集中管控。所有工作负载 VNet（Spoke）只与中心 Hub VNet 对等，Hub 内部署 Azure Firewall、DNS 转发器、日志分析器。所有跨 Spoke 流量必须经 Hub 的防火墙策略检查，且策略本身由 Azure Policy 强制绑定到 Hub 资源组——任何绕过 Firewall 的 NSG 规则都会被 Policy 自动拒绝并告警。

2.3 翻车现场三：合规漂移——月初通过等保测评，月底因配置变更自动失效

某政务云项目每月初人工检查 200+ 项配置（如磁盘加密开关、日志保留天数、存储账户防火墙白名单），但：

• 开发人员为调试临时关闭了 Key Vault 的软删除；
• 运维脚本自动扩容 VM 时未继承父资源组的标签策略；
• 结果测评报告刚签完字，Azure Security Center 就发出高危告警。

Landing Zones 的解法：将合规要求转化为Azure Policy Initiative（策略集）+ 自动修复（Remediation）。例如，“等保 2.0 8.1.2 条款：重要数据应加密存储”被拆解为：

• 策略 1：Audit if Storage Account encryption is disabled（审计）；
• 策略 2：DeployIfNotExists: Enable Storage Account encryption with CMK（自动修复）；
• 策略集绑定到 Management Group 层级，确保所有子订阅继承，且修复动作记录完整审计日志。

3. 用官方 Accelerator 在本地跑通最小 Landing Zone：从 clone 到第一个合规告警

Azure Landing Zones 的核心交付物是Azure Landing Zones Accelerator——这不是一个“安装包”，而是一套模块化、可定制的 IaC 代码仓库，包含 Bicep 模块、Policy 定义、CI/CD 流水线模板和参考架构文档。它不强制你用全部，但提供了经过微软云采用团队（CAT）验证的最小可行路径。

3.1 准备工作：四个必须确认的前提条件

在 clone 仓库前，请务必确认以下四点，否则后续 90% 的失败都源于此：

1. 租户层级权限：你必须是 Azure AD 租户的Global Administrator或Privileged Role Administrator，用于注册必需的 Azure Resource Providers（如Microsoft.Authorization,Microsoft.PolicyInsights）并创建 Management Group 层级结构；
2. 订阅所有权：至少拥有一个空订阅（Clean Subscription）的 Owner 权限，该订阅将作为Management Group Root的承载容器（注意：不是用你的个人 MSDN 订阅！）；
3. 本地工具链：已安装Azure CLI 2.40+、Bicep CLI 0.26+、PowerShell 7.2+，且已执行az login --use-device-code登录到目标租户；
4. DNS 域名准备：若启用 Azure AD Domain Services（AD DS），需提前在 Azure DNS 或自有 DNS 中预留privatelink.<yourdomain>.com子域，并配置正确的 NS 记录指向 Azure。

提示：不要跳过“空订阅”要求。Accelerator 的launchpad模块会创建managementGroups、policyDefinitions、roleDefinitions等全局资源，若订阅已有遗留资源（如旧版 Log Analytics 工作区、手动创建的 Key Vault），极易触发ResourceConflict错误。

3.2 克隆与初始化：三步完成基础骨架部署

# 1. 克隆官方 Accelerator 仓库（推荐使用 v6.0.0 稳定版） git clone https://github.com/Azure/Enterprise-Scale.git cd Enterprise-Scale # 2. 初始化部署参数文件（基于示例模板修改） cp ./examples/parameters/launchpad.parameters.json ./parameters/launchpad.parameters.json # 3. 编辑 parameters 文件，填入你的环境信息（关键字段如下） # - "rootManagementGroupName": "contoso" （你的根 MG 名，全小写，无特殊字符） # - "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" （租户 ID） # - "subscriptionId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" （空订阅 ID） # - "location": "East US" （建议选离你最近的区域，避免跨区域策略延迟）

3.3 执行 Launchpad 部署：构建治理底座

Launchpad 是整个 Landing Zones 的“地基模块”，它不创建业务资源，只搭建治理框架：

• 创建 Management Group 层级（contoso→corp/online/mgmt/sdlz）；
• 注册所有必需 Resource Providers；
• 部署基础 Policy Definitions（如Allowed locations,Require tags）；
• 创建初始 RBAC 分配（如Owner分配给Contoso-Platform-Admins组）。

# 使用 Azure CLI 执行部署（推荐，比 PowerShell 更稳定） az deployment tenant create \ --name launchpad-deploy-$(date +%Y%m%d-%H%M%S) \ --location "East US" \ --template-file ./eslz.bicep \ --parameters ./parameters/launchpad.parameters.json

参数说明：

• --name：部署名称必须唯一，建议带时间戳避免冲突；
• --location：此处 location 指部署元数据存储位置，不影响实际资源部署区域；
• ./eslz.bicep：这是 Accelerator 的主入口文件，它会按顺序调用./modules/launchpad/launchpad.bicep等子模块；
• 若报错The client 'xxx' with object id 'yyy' does not have authorization to perform action 'Microsoft.Authorization/policyAssignments/write'，说明登录账号缺少租户级权限，请用 Global Admin 重新登录。

部署成功后，你会在 Azure Portal 的Management Groups中看到类似结构：

contoso (Root) ├── corp # 企业内部应用（HR/ERP） ├── online # 面向公众的在线服务 ├── mgmt # 平台管理资源（Log Analytics, Key Vault） └── sdlz # Shared Data Landing Zone（可选，用于跨业务数据共享）

此时，打开Azure Policy→Assignments，你会看到至少 15 条已分配的策略，例如：

• Allowed resource types：限制Microsoft.Web/sites只能在onlineMG 下创建；
• Require a tag on resources：强制所有资源必须有Environment=prod/dev/test标签；
• Audit diagnostic settings：检查所有存储账户、Key Vault 是否启用了诊断日志。

验证技巧：立刻创建一个测试资源组（如rg-test-dev），不加Environment标签。2 分钟后，Policy 会自动生成Non-compliant状态，并在Compliance页显示具体原因——这就是 Landing Zones 的第一声合规告警。

4. 避坑：Landing Zones 部署中 5 个高频致命错误与修复方案

4.1 现象：Deployment failed: The request content was invalid报错，堆栈指向managementGroups模块

原因：Management Group 名称违反命名规范。Azure 要求 MG 名只能含小写字母、数字、短横线（-），且不能以短横线开头或结尾，长度 1-64 字符。常见错误包括：Contoso-Corp（大写 C）、corp-（结尾短横）、my_mg（下划线）。
解决：严格使用小写+短横组合，如contoso-corp。修改launchpad.parameters.json中的rootManagementGroupName，并确保所有子 MG 名（如corp,online）也符合该规则。重新部署前，先在 Portal 手动删除已创建的非法 MG（Portal → Management Groups → 选中 → Delete）。

4.2 现象：部署卡在Microsoft.Authorization/policyDefinitions步骤，超时失败

原因：租户内已存在同名 Policy Definition（如Allowed locations），而 Accelerator 默认尝试CreateOrUpdate，但 Azure 不允许覆盖内置策略。
解决：在部署前，运行以下命令清理冲突策略：

# 列出所有自定义策略定义（排除 Microsoft.* 命名空间） az policy definition list --query "[?contains(name, 'Allowed') && !contains(id, 'Microsoft.')].{Name:name,Id:id}" -o table # 删除冲突项（替换 <policy-id> 为实际 ID） az policy definition delete --id "<policy-id>"

注意：此操作仅删除自定义策略，不影响 Azure 内置策略（如Audit VMs without managed identity）。

4.3 现象：Policy 分配成功，但资源组创建后始终显示NotStarted合规状态

原因：Policy 分配作用域（scope）错误。例如，将Require tags策略分配给了Management Group，但该 MG 下没有资源组，而 Policy 的mode设置为All（默认），导致评估引擎找不到目标资源。
解决：进入 Azure Policy → Assignment → 选中该策略 →Edit assignment→ 在Scope页，点击Select scope→ 选择具体的Management Group（如/providers/Microsoft.Management/managementGroups/corp）→ 确保What should this assignment apply to?选This management group and all its children→ 保存后，点击Remediate手动触发首次评估。

4.4 现象：Bicep 部署报错The specified location 'East US' is not available for resource type 'Microsoft.Authorization/policyAssignments'

原因：Policy Assignment 是全局资源，其location必须为global，而非区域名。Accelerator 的 Bicep 模块中部分参数默认写死为区域，需手动修正。
解决：打开./modules/launchpad/launchpad.bicep，搜索location:，将所有 Policy Assignment 相关资源的location值改为'global'。例如：

// 修改前（错误） resource policyAssignment 'Microsoft.Authorization/policyAssignments@2022-09-01' = { name: 'allowed-locations' location: 'East US' // ← 删除此行或改为 'global' properties: { // ... } } // 修改后（正确） resource policyAssignment 'Microsoft.Authorization/policyAssignments@2022-09-01' = { name: 'allowed-locations' properties: { // ... 无需 location 字段 } }

4.5 现象：部署成功，但mgmt管理组下无 Log Analytics 工作区，Security Center 显示“未配置日志收集”

原因：mgmt区域的 Log Analytics 部署被默认禁用。Accelerator 将日志基础设施视为可选模块，默认enableLogAnalytics参数为false。
解决：编辑./parameters/launchpad.parameters.json，找到logAnalyticsWorkspaceSettings对象，将enabled设为true，并指定workspaceName和location：

"logAnalyticsWorkspaceSettings": { "enabled": true, "workspaceName": "eslz-mgmt-la", "location": "East US", "sku": "PerGB2018" }

然后重新运行az deployment tenant create命令。部署完成后，在mgmt管理组下即可看到新建的工作区。

5. 把 Landing Zones 从“能跑”升级到“敢用”：三个必须落地的硬核验证动作

Landing Zones 的价值不在部署成功那一刻，而在它能否在真实业务压力下持续守住治理底线。我见过太多团队在演示环境里跑通所有模块，结果上线第一个月就被安全团队叫停——因为没做这三件事。

5.1 动作一：用真实业务流触发 Policy Remediation，验证“自动修复”是否真可靠

很多团队只看 Policy 的Audit效果，却忽略DeployIfNotExists的实际执行能力。请立即执行以下验证：

1. 手动创建一个未启用磁盘加密的 Windows VM（在corp管理组下的任意订阅中）；
2. 等待 15 分钟（Policy 评估默认周期），进入 Azure Policy → Compliance → 找到DeployIfNotExists: Enable OS disk encryption策略 → 查看该 VM 是否标记为Non-compliant；
3. 点击该策略 →Remediate→ 创建修复任务（Remediation task name建议填test-vm-encryption-fix）；
4. 进入Remediation tasks页面，等待状态变为Succeeded；
5. 登录该 VM，运行Get-BitLockerVolume（PowerShell），确认ProtectionStatus为On。

关键检查点：

• 修复任务日志中是否出现Deployment succeeded？
• VM 的OS Disk属性中Encryption Settings是否显示Enabled: true？
• 若失败，查看Activity log中Microsoft.Compute/virtualMachines/write事件的Error字段——常见原因是 Key Vault 未启用Soft Delete和Purge Protection，需在mgmt管理组中单独启用。

5.2 动作二：模拟权限变更，验证 PIM 审批流是否闭环

Landing Zones 的 RBAC 不是静态快照，而是动态流程。必须验证：

• 当用户申请临时Network Contributor权限时，审批人能否收到邮件？
• 审批通过后，权限是否精确生效 2 小时？
• 时间到期后，权限是否自动回收且无残留？

实操步骤：

1. 在 Azure AD →Privileged Identity Management→Azure resources→ 选择corp管理组 →Assignments→Add assignments；
2. 为测试用户分配Network Contributor角色，Assignment type选Eligible，Justification填Test PIM flow；
3. 切换到测试用户账号，访问My roles→Activate→ 选择Network Contributor→ 填写 Justification → 提交；
4. 用管理员账号登录 PIM →Access reviews→ 找到该请求 →Approve；
5. 回到测试账号，确认Active assignments中出现该角色，且End date为当前时间 + 2 小时；
6. 等待 2 小时后，再次检查Active assignments，确认角色已消失；
7. 尝试用该账号创建 NSG 规则，应返回AuthorizationFailed错误。

血泪经验：PIM 审批邮件可能被归类为垃圾邮件。务必在PIM → Settings → Email notifications中开启Send email notifications for pending requests，并检查管理员邮箱的垃圾邮件文件夹。

5.3 动作三：用 Azure Security Benchmark 扫描，生成首份“治理健康度报告”

Azure Security Benchmark（ASB）是微软官方发布的云安全基线，覆盖 200+ 项控制点。Landing Zones 的 Policy 集成 ASB，但需主动触发扫描才能生成报告。

操作流程：

1. 进入 Azure Security Center（现为 Microsoft Defender for Cloud）→Regulatory compliance→Azure Security Benchmark；
2. 点击Initiate assessment→ 选择All subscriptions或指定corp管理组；
3. 等待 30-60 分钟（首次扫描较慢），刷新页面，查看Compliance score（如82%）；
4. 点击View controls→ 筛选Status = Non-compliant→ 重点看前三项：

• 1.1 Ensure that security contacts are configured（安全联系人未配置）→ 进入Defender for Cloud → Environment settings → Security contacts填写；
• 4.1 Ensure that Azure Key Vault is used for secret storage（Key Vault 未启用）→ 检查mgmt管理组下是否已部署 Key Vault；
• 5.2 Ensure that Azure Defender is enabled for Storage Accounts（Defender for Storage 未启用）→ 进入Defender for Cloud → Environment settings → Auto Provisioning，启用Storage Accounts。

进阶技巧：将 ASB 报告导出为 PDF，用Ctrl+F搜索关键词Landing Zones，你会发现所有Non-compliant项都对应 Accelerator 中的 Policy 名称（如Enable Azure Defender for Storage Accounts）。这意味着：你的治理缺口，就是 Landing Zones 的待办清单。把这份报告交给 CISO，他立刻明白哪些 Policy 需要优先启用、哪些资源需迁移。

6. 我的三个落地习惯：让 Landing Zones 从“项目”变成“日常”

做了 7 个 Landing Zones 实施后，我彻底放弃了“一次性交付”思维。它不是上线就结束的项目，而是嵌入日常运维的呼吸节奏。以下是我雷打不动的三个习惯，帮你避开“部署即遗忘”的陷阱。

6.1 习惯一：每周五下午 3 点，雷打不动执行az policy state list差异比对

我写了一个极简 Bash 脚本，每周自动拉取 Policy 合规状态快照，并与上周对比：

#!/bin/bash # save as: /opt/eslz/weekly-compliance-check.sh DATE=$(date +%Y%m%d) LAST_WEEK=$(date -d "last Friday" +%Y%m%d) # 获取当前合规状态（JSON 格式，过滤出 Non-compliant） az policy state list \ --top 1000 \ --filter "isCompliant eq false" \ --query "[].{Policy:policyDefinitionName, ResourceGroup:resourceGroup, Resource:resourceId, Reason:policyEvaluationDetails}" \ -o json > "/opt/eslz/reports/compliance-${DATE}.json" # 与上周对比，输出新增的 Non-compliant 项 if [ -f "/opt/eslz/reports/compliance-${LAST_WEEK}.json" ]; then echo "=== NEW NON-COMPLIANT ITEMS SINCE ${LAST_WEEK} ===" jq -s 'reduce .[] as $item ({}; .[$item.Resource] |= (. // []) + [$item]) | to_entries[] | select(.value | length > 1) | .value[1] | {Policy, ResourceGroup, Resource, Reason}' \ "/opt/eslz/reports/compliance-${LAST_WEEK}.json" "/opt/eslz/reports/compliance-${DATE}.json" | \ jq -r '.Policy + " | " + .ResourceGroup + " | " + .Resource' fi

为什么有效：Policy 合规状态是动态的。开发提交代码、运维扩容集群、安全团队更新规则，都可能瞬间制造新的Non-compliant。这个脚本不追求 100% 合规（那不现实），而是聚焦“新增风险”。如果某周突然冒出 20 条Key Vault soft delete disabled，说明有人绕过了 Landing Zones 的 Key Vault 创建流程——这就是你需要介入的信号。

6.2 习惯二：所有新业务上线前，强制走Landing Zones Readiness Checklist

我设计了一份 12 项的检查清单，由平台团队、安全团队、业务方三方签字确认。其中三项最常被卡住：

关键逻辑：这不是增加流程负担，而是把“事后救火”变成“事前拦截”。当业务方看到第 7 项要求提供诊断日志路由证据时，他自然会去查文档——而文档里写的正是 Landing Zones 的标准路径。

6.3 习惯三：每季度用Bicep What-If演练一次架构变更影响

Landing Zones 的 Bicep 模块支持what-if模式，能预演任何变更对现有环境的影响。我坚持每季度做一次：

1. 修改./parameters/launchpad.parameters.json，例如将enableLogAnalytics从true改为false；
2. 运行az deployment tenant what-if --template-file ./eslz.bicep --parameters ./parameters/launchpad.parameters.json；
3. 仔细阅读输出中的DELETE和MODIFY行——它会明确告诉你：
   • DELETE: Microsoft.OperationalInsights/workspaces@2022-10-01（将删除 Log Analytics 工作区）；
   • MODIFY: Microsoft.Authorization/policyAssignments@2022-09-01（将修改策略分配作用域）。

教训：去年我们曾因未执行what-if，直接更新了 Policy 分配作用域，导致corp管理组下所有资源的标签策略被意外解除。what-if就是你的“后悔药”，它不阻止你改，但强迫你看清代价。

希望帮到你。

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