Maester：用 PowerShell 测试框架盯住 Microsoft 365 安全配置
Maester 是一个测试自动化框架，可帮助您保持对 Microsoft 安全配置的控制。
秒懂
- 它是什么？
- Maester 是一个基于 PowerShell 的测试自动化框架，用于持续验证 Microsoft 365 租户的安全配置。本文介绍它的工作原理、安装方式、已知限制，以及适合与不适合的人群。
- 适合谁用？
- Maester 适合已经熟悉 PowerShell 和 Pester 的 Microsoft 365 管理员，尤其是那些需要将安全配置检查纳入 CI/CD 流程的团队。它不适合完全没有 PowerShell 经验的人，也不适合需要图形界面或商业支持的企业。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 HTML（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月19日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁需要它
Microsoft 365 的安全配置散落在条件访问策略、Exchange Online 设置、身份验证方法等多个位置。手动检查这些配置既耗时又容易遗漏。Maester 把安全配置检查变成可重复运行的自动化测试。它的目标用户是负责 Microsoft 365 租户安全的 IT 管理员和安全工程师。这些人通常已经会用 PowerShell，并且可能已经有 Pester 测试的经验。Maester 不是安全扫描器，它不检测漏洞，而是验证配置是否符合预期。如果你需要定期证明某个安全设置没有被意外改动，Maester 是一个合适的工具。
核心机制：Pester 测试与 PowerShell 模块
Maester 本质上是一个 PowerShell 模块，它依赖于 Pester 测试框架。安装 Maester 后，你需要先运行 Install-MaesterTests 来下载一组预置的测试文件。这些测试文件放在你指定的目录中，比如 ~/maester-tests。运行测试时，Connect-Maester 负责建立与 Microsoft 365 的连接，Invoke-Maester 则执行当前目录下的所有测试。测试结果可以导出为 CSV、Excel、HTML、JSON 或 Markdown 格式。这种设计让 Maester 的测试集与模块本身分离，你可以自由修改或新增测试文件，而不必改动框架核心。
安装与运行：三条命令起步
安装 Maester 只需一条命令：Install-Module -Name Maester -Scope CurrentUser。接着创建测试目录并安装测试集：md ~/maester-tests，然后 cd 进入该目录，运行 Install-MaesterTests。之后每次运行都使用 Connect-Maester 和 Invoke-Maester 两条命令。如果你在非全局云环境，比如中国区或美国政府云，需要给 Connect-Maester 加上 -Environment 参数，可选值有 Global、China、USGov、USGovDOD。默认是 Global，所以大部分用户不需要额外指定。更新测试集也很直接：Update-Module Maester 更新模块，然后 Update-MaesterTests -Path ~/maester-tests 刷新测试文件。整个过程没有图形界面，完全依赖命令行。
CI/CD 集成：GitHub Action 的迁移注意点
Maester 可以嵌入 GitHub Actions 工作流，官方提供了 GitHub marketplace 上的 action。但 README 明确提醒，旧的 action 仓库 maester365/maester 已经弃用，你需要迁移到新的 maester365/maester-action。这个迁移不是可选的，如果你还在用旧 action，应该阅读 deprecation 文档并调整工作流。由于 Maester 输出格式多样，你可以在 CI 中上传 HTML 报告作为 artifact，或者把 JSON 结果用于后续分析。GitHub Action 的优势在于它原生支持 artifact 上传和 workflow summary，这些功能在本地运行时不具备。
已知限制：ExchangeOnlineManagement 版本陷阱
README 中有一个显眼的警告：不要使用 ExchangeOnlineManagement 模块的 3.9.2 版本。许多用户在用这个版本连接时遇到错误，而之前的版本通常没问题。这个警告说明 Maester 的某些测试依赖 Exchange Online 的连接，而该连接受第三方模块版本影响。这不是 Maester 自身的 bug，但使用 Maester 时你必须留意这个依赖。另一个限制是 Maester 的测试集是预置的，它可能不覆盖你租户特有的安全策略。如果你有自定义的合规要求，必须自己编写 Pester 测试来补充。
构建与定制：从源码到本地模块
如果你想修改 Maester 本身，而不是只写测试，可以从源码构建。仓库的 powershell/ 和 tests/ 目录包含主要源码。运行 ./build/Build-LocalMaester.ps1 会构建并验证模块，然后加载到当前 PowerShell 会话。构建产物放在 module/ 目录，但这个目录是 git 忽略的，不会提交到仓库。如果你改了报告模板，需要先运行 ./build/Build-LocalMaester.ps1 -BuildReport 来嵌入新模板，再重新构建模块。这种构建流程适合想贡献新测试或修复 bug 的开发者。对于普通用户，直接安装 PowerShell Gallery 上的版本更简单。
替代方案与差异
Maester 的直接替代品是微软自家的 Microsoft 365 DSC（Desired State Configuration）。Microsoft 365 DSC 采用声明式配置，你定义期望状态，DSC 负责让系统达到该状态。Maester 则采用测试驱动方式，它只检查配置是否符合预期，不主动修改任何设置。这意味着 Maester 更适合监控和审计，而 DSC 更适合自动修复。另一个区别是 Maester 基于 Pester，测试文件是 PowerShell 脚本，熟悉 Pester 的人可以快速上手。DSC 的配置语法更接近资源声明，学习曲线不同。如果你的目标是防止配置漂移并自动纠正，DSC 可能更合适；如果你只需要定期验证并生成报告，Maester 更轻量。
维护成本与许可证
Maester 采用 MIT 许可证，允许自由使用、修改和分发，没有强制的 copyleft 义务。维护成本主要体现在两方面：一是跟随 Maester 模块和测试集的更新，官方会定期添加新测试，你需要运行 Update-Module 和 Update-MaesterTests 来保持测试覆盖。二是处理依赖模块的版本问题，比如 ExchangeOnlineManagement 的 3.9.2 版本问题，你需要锁定或避开特定版本。由于 Maester 本身是一个活跃维护的项目，最近一次发布是 2026 年 8 月，预览版本更新频繁，这既是好事也意味着版本变动可能带来兼容性变化。在采用前，建议在非生产租户上先验证当前版本与你的环境兼容。
编辑结论
Maester 适合已经熟悉 PowerShell 和 Pester 的 Microsoft 365 管理员，尤其是那些需要将安全配置检查纳入 CI/CD 流程的团队。它不适合完全没有 PowerShell 经验的人，也不适合需要图形界面或商业支持的企业。在采用前，先确认你的租户环境支持 Connect-Maester 所依赖的模块，特别是 ExchangeOnlineManagement 的版本兼容性。还要检查 Maester 自带的测试集是否覆盖你关心的安全项，若不足，需要准备编写自定义 Pester 测试。最后，验证 GitHub Action 的迁移路径，确保你使用的是新的 maester-action 仓库，而不是已弃用的旧 action。
社区笔记