简介本资源是面向Azure云架构师与政府云迁移工程师的PowerShell自动化部署方案聚焦Microsoft Azure政府MAG环境下的企业级着陆区Landing Zones落地实践。它基于Cloud Adoption FrameworkCAF最新参考架构扩展支持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 集中管控。所有工作负载 VNetSpoke只与中心 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 条款重要数据应加密存储”被拆解为策略 1Audit if Storage Account encryption is disabled审计策略 2DeployIfNotExists: 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% 的失败都源于此租户层级权限你必须是 Azure AD 租户的Global Administrator或Privileged Role Administrator用于注册必需的 Azure Resource Providers如Microsoft.Authorization,Microsoft.PolicyInsights并创建 Management Group 层级结构订阅所有权至少拥有一个空订阅Clean Subscription的 Owner 权限该订阅将作为Management Group Root的承载容器注意不是用你的个人 MSDN 订阅本地工具链已安装Azure CLI 2.40、Bicep CLI 0.26、PowerShell 7.2且已执行az login --use-device-code登录到目标租户DNS 域名准备若启用 Azure AD Domain ServicesAD 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强制所有资源必须有Environmentprod/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 手动删除已创建的非法 MGPortal → 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/policyAssignments2022-09-01 { name: allowed-locations location: East US // ← 删除此行或改为 global properties: { // ... } } // 修改后正确 resource policyAssignment Microsoft.Authorization/policyAssignments2022-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和locationlogAnalyticsWorkspaceSettings: { 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的实际执行能力。请立即执行以下验证手动创建一个未启用磁盘加密的 Windows VM在corp管理组下的任意订阅中等待 15 分钟Policy 评估默认周期进入 Azure Policy → Compliance → 找到DeployIfNotExists: Enable OS disk encryption策略 → 查看该 VM 是否标记为Non-compliant点击该策略 →Remediate→ 创建修复任务Remediation task name建议填test-vm-encryption-fix进入Remediation tasks页面等待状态变为Succeeded登录该 VM运行Get-BitLockerVolumePowerShell确认ProtectionStatus为On。关键检查点修复任务日志中是否出现Deployment succeededVM 的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 小时时间到期后权限是否自动回收且无残留实操步骤在 Azure AD →Privileged Identity Management→Azure resources→ 选择corp管理组 →Assignments→Add assignments为测试用户分配Network Contributor角色Assignment type选EligibleJustification填Test PIM flow切换到测试用户账号访问My roles→Activate→ 选择Network Contributor→ 填写 Justification → 提交用管理员账号登录 PIM →Access reviews→ 找到该请求 →Approve回到测试账号确认Active assignments中出现该角色且End date为当前时间 2 小时等待 2 小时后再次检查Active assignments确认角色已消失尝试用该账号创建 NSG 规则应返回AuthorizationFailed错误。血泪经验PIM 审批邮件可能被归类为垃圾邮件。务必在PIM → Settings → Email notifications中开启Send email notifications for pending requests并检查管理员邮箱的垃圾邮件文件夹。5.3 动作三用 Azure Security Benchmark 扫描生成首份“治理健康度报告”Azure Security BenchmarkASB是微软官方发布的云安全基线覆盖 200 项控制点。Landing Zones 的 Policy 集成 ASB但需主动触发扫描才能生成报告。操作流程进入 Azure Security Center现为 Microsoft Defender for Cloud→Regulatory compliance→Azure Security Benchmark点击Initiate assessment→ 选择All subscriptions或指定corp管理组等待 30-60 分钟首次扫描较慢刷新页面查看Compliance score如82%点击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 storageKey Vault 未启用→ 检查mgmt管理组下是否已部署 Key Vault5.2 Ensure that Azure Defender is enabled for Storage AccountsDefender for Storage 未启用→ 进入Defender for Cloud → Environment settings → Auto Provisioning启用Storage Accounts。进阶技巧将 ASB 报告导出为 PDF用CtrlF搜索关键词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 项的检查清单由平台团队、安全团队、业务方三方签字确认。其中三项最常被卡住序号检查项负责人证据要求3网络拓扑确认业务 VNet 是否已与hub对等NSG 是否仅放行必要端口平台工程师提供az network vnet peering list输出截图7日志路由验证所有诊断日志是否已路由至mgmt管理组下的 Log Analytics 工作区SRE提供az monitor diagnostic-settings list --resource resource-id输出11密钥生命周期Key Vault 中的证书是否启用自动续订密钥轮换周期是否 ≤ 90 天安全工程师提供az keyvault certificate show和az keyvault key list-versions输出关键逻辑这不是增加流程负担而是把“事后救火”变成“事前拦截”。当业务方看到第 7 项要求提供诊断日志路由证据时他自然会去查文档——而文档里写的正是 Landing Zones 的标准路径。6.3 习惯三每季度用Bicep What-If演练一次架构变更影响Landing Zones 的 Bicep 模块支持what-if模式能预演任何变更对现有环境的影响。我坚持每季度做一次修改./parameters/launchpad.parameters.json例如将enableLogAnalytics从true改为false运行az deployment tenant what-if --template-file ./eslz.bicep --parameters ./parameters/launchpad.parameters.json仔细阅读输出中的DELETE和MODIFY行——它会明确告诉你DELETE: Microsoft.OperationalInsights/workspaces2022-10-01将删除 Log Analytics 工作区MODIFY: Microsoft.Authorization/policyAssignments2022-09-01将修改策略分配作用域。教训去年我们曾因未执行what-if直接更新了 Policy 分配作用域导致corp管理组下所有资源的标签策略被意外解除。what-if就是你的“后悔药”它不阻止你改但强迫你看清代价。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/25 12:36:41 · 阅读 1.2k Azure Landing Zones：企业级云治理的落地实践指南
简介本资源是面向Azure云架构师与政府云迁移工程师的PowerShell自动化部署方案聚焦Microsoft Azure政府MAG环境下的企业级着陆区Landing Zones落地实践。它基于Cloud Adoption FrameworkCAF最新参考架构扩展支持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 集中管控。所有工作负载 VNetSpoke只与中心 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 条款重要数据应加密存储”被拆解为策略 1Audit if Storage Account encryption is disabled审计策略 2DeployIfNotExists: 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% 的失败都源于此租户层级权限你必须是 Azure AD 租户的Global Administrator或Privileged Role Administrator用于注册必需的 Azure Resource Providers如Microsoft.Authorization,Microsoft.PolicyInsights并创建 Management Group 层级结构订阅所有权至少拥有一个空订阅Clean Subscription的 Owner 权限该订阅将作为Management Group Root的承载容器注意不是用你的个人 MSDN 订阅本地工具链已安装Azure CLI 2.40、Bicep CLI 0.26、PowerShell 7.2且已执行az login --use-device-code登录到目标租户DNS 域名准备若启用 Azure AD Domain ServicesAD 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强制所有资源必须有Environmentprod/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 手动删除已创建的非法 MGPortal → 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/policyAssignments2022-09-01 { name: allowed-locations location: East US // ← 删除此行或改为 global properties: { // ... } } // 修改后正确 resource policyAssignment Microsoft.Authorization/policyAssignments2022-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和locationlogAnalyticsWorkspaceSettings: { 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的实际执行能力。请立即执行以下验证手动创建一个未启用磁盘加密的 Windows VM在corp管理组下的任意订阅中等待 15 分钟Policy 评估默认周期进入 Azure Policy → Compliance → 找到DeployIfNotExists: Enable OS disk encryption策略 → 查看该 VM 是否标记为Non-compliant点击该策略 →Remediate→ 创建修复任务Remediation task name建议填test-vm-encryption-fix进入Remediation tasks页面等待状态变为Succeeded登录该 VM运行Get-BitLockerVolumePowerShell确认ProtectionStatus为On。关键检查点修复任务日志中是否出现Deployment succeededVM 的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 小时时间到期后权限是否自动回收且无残留实操步骤在 Azure AD →Privileged Identity Management→Azure resources→ 选择corp管理组 →Assignments→Add assignments为测试用户分配Network Contributor角色Assignment type选EligibleJustification填Test PIM flow切换到测试用户账号访问My roles→Activate→ 选择Network Contributor→ 填写 Justification → 提交用管理员账号登录 PIM →Access reviews→ 找到该请求 →Approve回到测试账号确认Active assignments中出现该角色且End date为当前时间 2 小时等待 2 小时后再次检查Active assignments确认角色已消失尝试用该账号创建 NSG 规则应返回AuthorizationFailed错误。血泪经验PIM 审批邮件可能被归类为垃圾邮件。务必在PIM → Settings → Email notifications中开启Send email notifications for pending requests并检查管理员邮箱的垃圾邮件文件夹。5.3 动作三用 Azure Security Benchmark 扫描生成首份“治理健康度报告”Azure Security BenchmarkASB是微软官方发布的云安全基线覆盖 200 项控制点。Landing Zones 的 Policy 集成 ASB但需主动触发扫描才能生成报告。操作流程进入 Azure Security Center现为 Microsoft Defender for Cloud→Regulatory compliance→Azure Security Benchmark点击Initiate assessment→ 选择All subscriptions或指定corp管理组等待 30-60 分钟首次扫描较慢刷新页面查看Compliance score如82%点击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 storageKey Vault 未启用→ 检查mgmt管理组下是否已部署 Key Vault5.2 Ensure that Azure Defender is enabled for Storage AccountsDefender for Storage 未启用→ 进入Defender for Cloud → Environment settings → Auto Provisioning启用Storage Accounts。进阶技巧将 ASB 报告导出为 PDF用CtrlF搜索关键词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 项的检查清单由平台团队、安全团队、业务方三方签字确认。其中三项最常被卡住序号检查项负责人证据要求3网络拓扑确认业务 VNet 是否已与hub对等NSG 是否仅放行必要端口平台工程师提供az network vnet peering list输出截图7日志路由验证所有诊断日志是否已路由至mgmt管理组下的 Log Analytics 工作区SRE提供az monitor diagnostic-settings list --resource resource-id输出11密钥生命周期Key Vault 中的证书是否启用自动续订密钥轮换周期是否 ≤ 90 天安全工程师提供az keyvault certificate show和az keyvault key list-versions输出关键逻辑这不是增加流程负担而是把“事后救火”变成“事前拦截”。当业务方看到第 7 项要求提供诊断日志路由证据时他自然会去查文档——而文档里写的正是 Landing Zones 的标准路径。6.3 习惯三每季度用Bicep What-If演练一次架构变更影响Landing Zones 的 Bicep 模块支持what-if模式能预演任何变更对现有环境的影响。我坚持每季度做一次修改./parameters/launchpad.parameters.json例如将enableLogAnalytics从true改为false运行az deployment tenant what-if --template-file ./eslz.bicep --parameters ./parameters/launchpad.parameters.json仔细阅读输出中的DELETE和MODIFY行——它会明确告诉你DELETE: Microsoft.OperationalInsights/workspaces2022-10-01将删除 Log Analytics 工作区MODIFY: Microsoft.Authorization/policyAssignments2022-09-01将修改策略分配作用域。教训去年我们曾因未执行what-if直接更新了 Policy 分配作用域导致corp管理组下所有资源的标签策略被意外解除。what-if就是你的“后悔药”它不阻止你改但强迫你看清代价。希望帮到你。本文还有配套的精品资源点击获取