kingsrule50/azure-update-manager-lab

# Azure Update Manager — 补丁管理与合规性报告 **企业级 Azure 基础设施自动化系列** — 基于策略的补丁评估、计划的维护时段以及自动化的合规性报告，通过模块化的 Terraform 部署到我现有的 Azure 基础设施上，并使用 PowerShell 进行了端到端验证。 **技术栈：** Terraform (azurerm) · Azure Update Manager · Azure Policy · ARM REST API · PowerShell 7 (Az module) · Azure CLI ## 💼 业务问题 未打补丁的系统是导致安全事件的最常见根本原因之一。大规模环境下面临的挑战不在于给单台服务器打补丁，而在于了解整个环境中有哪些机器缺失了哪些补丁，执行统一的补丁计划，并生成能向审计人员证明合规性的文档。 本项目实现的现实场景是：一个新的 CVE 发布，其 CVSS 评分为 9.8。安全团队询问*我们的哪些服务器缺失了该补丁？*运维工程师在整个机群中触发按需评估，在几分钟内拉取合规性报告，受影响的机器将在下一个批准的维护时段内完成补丁安装。自动化、文档化、可审计。 ## 🛠️ 我解决的问题 | 问题 | 我实施的解决方案 | | ------- | ---------------------- | | 手动为单台 VM 注册补丁无法大规模扩展 | 我在资源组作用域分配了 Azure Policy `59efceea`，以便每台 VM —— 包括未来新增的 VM —— 都能自动注册到周期性的补丁评估中 | | 在不可预测的时间应用补丁会导致计划外停机 | 我以代码形式定义了维护配置：每周六 02:00 ET 的时段，持续 3 小时，仅包含 Critical/Security/UpdateRollup，仅在需要时重启 | | 评估和修补在 Azure 中是独立的操作 —— 为 VM 注册评估**并不会**为其安装补丁 | 我创建了维护分配，将每台服务器与每周时段关联起来，完善了 pipeline 的两半操作 | | 必须在不触动现有生产级基础设施的情况下添加 Update Manager 层 | 我使用 Terraform data source 读取了现有的 VM 和资源组 —— 两个隔离的 state 文件共享基础设施且零冲突，并且 `terraform destroy` 仅移除本项目拥有的内容 | | 现有 VM 早于补丁编排要求出现，且 `az vm update --set` 无法创建嵌套的 `automaticByPlatformSettings` 对象 | 我通过 ARM REST API 使用 `az rest --method patch` 直接修补了 VM 模型 | | Windows 客户端 VM (CLIENT01) 不受 Azure VM 客户机补丁支持 | 我将其排除在维护分配之外，并记录了这一边界：服务器机群属于 Update Manager，客户端机群属于 Intune/Autopatch | | 审计人员和下游系统需要机器可读的证据，而不是门户截图 | 我编写了 `validate-lab.ps1` —— 查询每台 VM 的评估状态，打印 PASS/FAIL，并导出可供 SIEM 或 ServiceNow 集成使用的 JSON 报告 | ## 🏗️ 我的构建内容 本项目在我的 [ntfs-lab-terraform](https://github.com/kingsrule50/ntfs-lab-terraform) 部署的基础设施（DC01 域控制器，FS01 文件服务器）之上，分层构建了一个完整的补丁管理 pipeline —— 而无需修改或重新部署其中的任何内容。 ``` azure-update-manager-lab/ ├── backend.tf # Remote state — shared storage account, isolated state key ├── versions.tf ├── variables.tf ├── main.tf # Data sources for existing VMs + module wiring ├── outputs.tf ├── modules/ │ └── update-manager/main.tf # Azure Policy + Maintenance Config + Assignments └── scripts/ └── validate-lab.ps1 # Compliance validation + JSON report export ``` ## 📋 实施演练 ### 1 — 我通过 ARM REST API 为现有 VM 准备了计划内的补丁安装 计划内修补要求 `patchMode = AutomaticByPlatform` 且 `bypassPlatformSafetyChecksOnUserSchedule = true`。CLI 的 `--set` 无法在现有的 VM 模型上创建嵌套的设置对象，因此我直接向 Compute API 发送了 PATCH 请求。这也是 CLIENT01 暴露出客户端操作系统限制的地方（`InvalidParameter: The selected VM image is not supported`）—— 这是预期行为，已被记录并排除在外。  ### 2 — 我使用模块化的 Terraform 部署了 Update Manager 层 四个资源，对现有基础设施的零更改 —— 计划证明了 data-source 方法是只读而不做修改的：  与标准参考文档的一处偏差：策略定义 `59efceea` 具有 *Modify* 效果，因此我为分配添加了系统分配的托管身份和位置 —— 没有它们，apply 将会失败。  ### 3 — 我在整个机群中触发了按需评估 这就是响应 CVE 的操作：我没有等待大约 24 小时的计划评估周期，而是强制对两台服务器进行了立即扫描。  ### 4 — 我验证了合规性并导出了审计工件 参考脚本调用了 `Get-AzVMPatchAssessmentResult`，但该命令在 Az.Compute 中并不存在 —— 我针对实际模块对其进行了调试，并基于 `(Get-AzVM -Status).PatchStatus.AvailablePatchSummary` 进行了重构。  导出的报告 —— 这是 SIEM、ServiceNow 或合规性仪表盘将提取的工件： ``` { "GeneratedAt": "2026-07-08T14:07:11.4563760-04:00", "ResourceGroup": "RG-FileServerLab", "VMs": [ { "VMName": "DC01", "AssessmentStatus": "Succeeded", "CriticalAndSecurityCount": 0, "OtherPatchCount": 3, "LastAssessmentTime": "2026-07-08T17:59:08.5535941Z", "Compliant": true, "Result": "PASS" }, { "VMName": "FS01", "AssessmentStatus": "Succeeded", "CriticalAndSecurityCount": 0, "OtherPatchCount": 2, "LastAssessmentTime": "2026-07-08T18:00:11.530212Z", "Compliant": true, "Result": "PASS" } ] } ``` ### 5 — 我在 Azure 门户中验证了一切 两台服务器均已注册并关联了每周计划；CLIENT01 正确地报告为 *Unsupported*：  整个机群的合规性仪表盘：  作为业务合同的维护时段 —— 计划、持续时间、重启行为：  作用于资源组的基于策略的注册：  ## 🚀 运行它 ``` # 前提条件：Terraform >= 1.5、Azure CLI、PowerShell 7 + Az module az provider register --namespace Microsoft.Maintenance az provider register --namespace Microsoft.GuestConfiguration terraform init terraform plan terraform apply # 触发按需评估（VM 必须处于运行状态） foreach ($vm in "DC01","FS01") { az vm assess-patches -g RG-FileServerLab -n $vm } # 验证并导出合规性报告 pwsh -File .\scripts\validate-lab.ps1 -SubscriptionId -TenantId # Teardown — 仅移除 4 个 Update Manager 资源；现有 VM 不受影响 terraform destroy ``` ## 🎯 展现的技能 | 类别 | 本项目展示的内容 | | -------- | ----------------------- | | 基础设施即代码 | 针对现有基础设施的模块化 Terraform —— data source、远程 state 隔离、精准的 destroy 作用域 | | 大规模治理 | 使用 Azure Policy 进行自动注册 —— 一次定义规则，所有当前和未来的 VM 均遵从 | | 补丁管理设计 | 包含分类、重启行为和计划安排的维护时段，作为已记录的业务合同 | | API 级别操作 | 使用 ARM REST API 执行 CLI 无法表达的 VM 模型更改 | | 合规性自动化 | 具有易读输出和机器可读 JSON 导出的 PowerShell 验证 | | 真实场景调试 | 诊断出参考文档中不存在的 cmdlet 并根据实际的 Az 模块行为进行重构；处理了不受支持的操作系统限制 |

标签：Azure, ECS, IPv6, PowerShell, Terraform, 端点安全, 补丁管理, 运维