Fleet 上的 macOS 15 Sequoia CIS Benchmark 落地指南：策略、配置描述文件与修复脚本的完整实践

• 后端
• 前端
• 企业应用
• 运维
• 网络安全

本篇技术指南以 Fleet 开源仓库中面向 macOS 15 Sequoia 的 CIS Benchmark 方案为核心，系统讲解如何基于 docs/solutions/cis/macos-15 目录下的policies/（GitOps 策略）、configuration-profiles/（Apple 配置描述文件）与scripts/（修复脚本）三大资产，在真实设备上完成 CIS 合规检查、配置强制与自动修复。读完本文，你将掌握这套方案针对 CIS Benchmark v1.1.0 的完整覆盖范围、无法用策略检查的基准清单、"需组织决策"类检查的双策略处置方法，以及如何通过fleetctl apply与 Fleet 页面把合规能力落地到你的 macOS 15 设备集群。

一、方案概览：CIS Benchmark 在 Fleet 中的落地形态

CIS（Center for Internet Security）Benchmark 是业界广泛采用的安全配置基线。Fleet 在 docs/solutions/cis/macos-15/README.md 中明确说明，本目录下的策略针对CIS macOS 15 Sequoia Benchmark v1.1.0编写，完整细节需参考 CIS 官网发布的该版本基准原文。

Fleet 并不只是简单地丢出一堆查询，而是围绕"检测 → 强制 → 修复"三个环节，将每个 CIS 控制项拆解为三类可消费的资产：

这一设计体现了 Fleet 一贯的 GitOps 理念：策略、配置、脚本全部以文件形式存在于仓库中，可以被版本管理、评审和审计追溯。仓库中的 articles/gitops-mode.md 与 articles/gitops-for-device-management.md 对这一工作流有更完整的论述。

二、策略资产剖析：一条 CIS 策略的完整结构

policies/cis-policy-queries.yml是整套方案的核心，共包含数百条策略（文件全文约 3300 行），每条策略遵循 Fleet 的 YAML 结构约定。先看文件头部说明：purpose、tags、contributors、platforms是只读元数据，GitOps 模式下不支持修改，保留它们是为了供其他工具引用。

以下面这条实际存在的策略为例：

- name: "[macOS 15] CIS - Ensure Firewall Is Enabled" # platforms: macOS platform: darwin description: A firewall minimizes the threat of unauthorized users gaining access to your system while connected to a network or the Internet. resolution: "Go to the Network pane in System Settings and ensure Firewall is active." query: SELECT 1 FROM alf WHERE global_state >= 1;

结构拆解：

• name：策略名称，统一以[macOS 15] CIS -前缀标识，便于在 Fleet UI 中检索与归类；
• platform：darwin，声明仅对 macOS 生效（Fleet 支持 跨平台策略，但 CIS macOS 基准只作用于 Apple 设备）；
• description：该项控制的安全动机，即 CIS 基准中的 Rationale，便于审计人员与管理员理解"为什么需要这条策略"；
• resolution：不合规时的处置说明，多数情况直接给出可执行命令或图形界面操作路径；
• query：osquery SQL，返回一行结果即视为通过（pass），否则判为 fail。

2.1 策略查询的三类典型模式

纵观 cis-policy-queries.yml，查询可以归纳为三种模式，理解它们有助于你自行扩展或维护策略：

模式一：直接查系统状态表。例如防火墙策略查询alf表（Application Layer Firewall 状态），要求global_state >= 1（已开启）；"确保防火墙隐身模式已启用"则在alf表上叠加stealth_enabled = 1条件。

模式二：查managed_policies表验证 MDM 描述文件是否已下发。这是本目录中出现频率最高的模式，例如"确保下载新更新时可用即下载（MDM Required）"：

query: | SELECT 1 WHERE EXISTS ( SELECT 1 FROM managed_policies WHERE domain='com.apple.SoftwareUpdate' AND name='AutomaticDownload' AND (value = 1 OR value = 'true') ) AND NOT EXISTS ( SELECT 1 FROM managed_policies WHERE domain='com.apple.SoftwareUpdate' AND name='AutomaticDownload' AND (value != 1 AND value != 'true') );

这类查询的特点是同时包含两个子句：EXISTS验证期望值已存在，NOT EXISTS排除冲突值，从而在设备上同时存在多个同名策略时也能正确判定。类似的还有AutomaticallyInstallMacOSUpdates（自动安装 macOS 更新）、AutomaticallyInstallAppUpdates（自动安装 App Store 应用更新）、CriticalUpdateInstall（安全响应与系统文件安装）、enforcedSoftwareUpdateDelay（更新延期不得超过 30 天）等，域均为com.apple.SoftwareUpdate或com.apple.applicationaccess。

模式三：查plist/file_lines/processes等底层表。用于无法通过 MDM 管理偏好强制、只能由用户或脚本设置的场景，例如：

• 屏幕共享是否被禁用：检查/var/db/com.apple.xpc.launchd/disabled.plist中com.apple.screensharing键是否为0。策略注释特别说明：不使用launchd表，因为它无法反映disabled.plist中的禁用状态——这是该偏好设置面板在服务曾被启用后再禁用时实际修改的文件；
• 打印机共享是否被禁用：检查/etc/cups/cupsd.conf中是否还有Allow @LOCAL行；
• 远程登录（SSH）是否禁用：检查disabled.plist中的com.openssh.sshd；
• 远程管理（Apple Remote Desktop）是否禁用：直接检查ARDAgent进程是否在运行；
• 蓝牙共享是否禁用：用path LIKE '/Users/%/Library/Preferences/ByHost/com.apple.Bluetooth.%.plist'遍历所有用户偏好；
• 登录屏幕自定义消息：查询plist表中/Library/Preferences/com.apple.loginwindow.plist的LoginwindowText键非空。

2.2 需要注意的执行前提

策略名称中的后缀揭示了其运行时依赖，这一点容易被忽略：

• (MDM Required)：查询依赖managed_policies表，意味着设备必须已通过 MDM 管理并下发了对应描述文件，否则查询结果恒为失败。这类策略本质上验证的是"描述文件是否到位"，而非"用户行为是否合规"；
• (Fleetd Required)：需要 Fleet 的 osquery agent（fleetd）具备相应表或权限；
• (FDA Required)：需要 Full Disk Access（完全磁盘访问权限），例如读取/Library/Preferences/com.apple.TimeMachine.plist检查 Time Machine 自动备份配置；
• (Fleetd Required)且查询本身可能较长，如"确保所有 Apple 提供软件均为最新"（software_update表）会标注"查询可能超过 10 秒"。

三、配置描述文件：MDM 强制的源头

策略查询能命中"通过"，前提是设备上真实存在正确的配置。configuration-profiles/目录中的.mobileconfig文件就是用来强制下发这些配置的。以 macos15-1.3.mobileconfig（对应"确保下载新更新时可用即下载已启用"）为例，其结构如下：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <array> <dict> <key>PayloadDisplayName</key> <string>test</string> <key>PayloadType</key> <string>com.apple.SoftwareUpdate</string> <key>PayloadIdentifier</key> <string>com.fleetdm.cis-1.3.check</string> <key>PayloadUUID</key> <string>5FDE6D58-79CD-447A-AFB0-BA32D889C396</string> <key>AutomaticDownload</key> <true/> </dict> </array> <key>PayloadDescription</key> <string>test</string> <key>PayloadDisplayName</key> <string>[macOS 15] Ensure Download New Updates When Available Is Enabled</string> <key>PayloadIdentifier</key> <string>com.fleetdm.macos15.cis-1.3</string> <key>PayloadRemovalDisallowed</key> <false/> <key>PayloadScope</key> <string>System</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>0A1C2F97-D6FA-4CDB-ABB6-47DF2B151F4F</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist>

关键要素：

• PayloadContent中的PayloadType必须与策略查询中managed_policies.domain完全一致——这里是com.apple.SoftwareUpdate，对应的策略查询才会命中；
• PayloadContent中的键值对必须与策略查询中的name与期望值一致——这里是AutomaticDownload为<true/>；
• 外层PayloadDisplayName描述该配置对应的 CIS 编号与要求，PayloadIdentifier遵循com.fleetdm.macos15.cis-<编号>的命名约定；
• PayloadScope为System，表示作用于整个系统而非某个用户。

这种"描述文件键值 ↔ 策略查询字段"的对应关系是整套方案的灵魂：先由描述文件把系统设置强制到位，再由策略查询验证其确实到位，两者必须配套部署才能得到"合规"结果。目录内还包含需要多段配置的控制项，例如macos15-2.6.2-part1/2/3.mobileconfig（FileVault 相关多段描述文件）、macos15-5.2.3-and-5.2.4.mobileconfig（密码复杂度合并文件）、以及 macOS 15 新增的macos15-apple-intelligence-*.mobileconfig系列（Apple Intelligence 扩展、邮件、备忘录、写作工具分别独立成文件）。

密码策略域方面，以 macos15-5.2.1.mobileconfig（账户锁定阈值）为例，其PayloadType为com.apple.mobiledevice.passwordpolicy，通过maxFailedAttempts键值设为5来限制连续失败登录次数。

四、修复脚本：策略的run_script配套

对于无法仅靠描述文件落地的控制项，scripts/目录提供了对应的 Shell 修复脚本，通常可挂接到策略的run_script修复动作上，实现"检测失败 → 一键修复"的闭环。从文件内容看，脚本风格务实直接，例如：

• macos15-CIS_5.8.sh（登录横幅）：写入告警文本并修正属主与权限：

  echo "Content of the banner" | sudo tee /Library/Security/PolicyBanner.txt /usr/bin/sudo /usr/sbin/chown root:wheel /Library/Security/PolicyBanner.txt /usr/bin/sudo /bin/chmod o+r /Library/Security/PolicyBanner.txt

• macos15-CIS_2.3.3.1.sh：禁用 ODSAgent 目录服务：

  /usr/bin/sudo /bin/launchctl disable system/com.apple.ODSAgent

• macos15-CIS_2.10.3.sh：设置登录窗口提示文本：

  sudo /usr/bin/defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "Test Message 1"

脚本与策略的对应关系可以通过名称直观识别：例如策略文件中的Ensure a Custom Message for the Login Screen Is Enabled（查询LoginwindowText非空）就与 macos15-CIS_2.10.3.sh 形成"查询-修复"配对。部署时，只需在对应策略的run_script字段中引用该脚本，Fleet 即可在策略失败时自动触发修复，这一机制在 articles/policy-automation-run-script.md 中有详细说明。

五、覆盖边界：无法用策略检查的 CIS 控制项

并非所有 CIS 基准条目都能通过 osquery 策略自动判定。README 明确列出以下 9 项无法用 Fleet 策略检查的基准，它们大多依赖人工审计或系统外部信息：

1. 2.1.2Audit App Store Password Settings（App Store 密码设置审计）
2. 2.3.3.12Ensure Computer Name Does Not Contain PII or Protected Organizational Information（计算机名不得包含 PII 或受保护的组织信息）
3. 2.6.6Audit Lockdown Mode（锁定模式审计）
4. 2.11.2Audit Touch ID and Wallet & Apple Pay Settings（Touch ID 与钱包/Apple Pay 设置审计）
5. 2.13.1Audit Passwords System Preference Setting（密码系统偏好设置审计）
6. 2.14.1Audit Notification & Focus Settings（通知与专注模式设置审计）
7. 3.7Audit Software Inventory（软件清单审计）
8. 6.2.1Ensure Protect Mail Activity in Mail Is Enabled（邮件隐私保护审计）
9. 2.6.3.5Ensure Share iCloud Analytics Is Disabled (manual)（共享 iCloud 分析（手动））

这些条目中，部分标注为Audit（审计类），CIS 本身要求定期人工复核；部分依赖主观判断（如计算机名是否含敏感信息）；还有像邮件隐私保护这类设置在 macOS 15 中缺乏稳定的可查询接口。针对这些条目，正确的落地方式是纳入组织内部的人工审计流程或补充脚本化检查，而不是期待一条策略查询给出结论。

六、需要组织决策的检查：双策略设计模式

CIS 对部分控制项不给出硬性推荐值，而是把参数决定权交给基准实施者。README 明确指出，对于以下 4 项，Fleet 同时提供了-enabled与-disabled两个版本：

• 2.1.1.1Audit iCloud Keychain
• 2.1.1.2Audit iCloud Drive
• 2.5.1Audit Siri
• 2.8.1Audit Universal Control

策略名称会带有-enabled或-disabled后缀（如2.1.1.1-enabled），对应的描述文件也成对出现（如 macos15-2.1.1.1-enable.mobileconfig 与macos15-2.1.1.2-disable.mobileconfig）。这种设计的运作逻辑是：

• 两个版本同时导入时，必有一条失败——这正是刻意为之，用于提醒组织"你还没有做出决定"；
• 一旦组织明确了策略方向（例如"允许 iCloud Keychain 同步"或"禁止 iCloud Drive"），删除与决定相反的那条策略即可，剩下的策略将稳定返回通过。

在策略文件中可以看到对应注释，例如 iCloud Drive 条目：

query: | SELECT 1 WHERE EXISTS ( SELECT 1 FROM managed_policies WHERE domain='com.apple.applicationaccess' AND name='allowCloudDocumentSync' AND (value = 0 OR value = 'false') ) AND NOT EXISTS ( SELECT 1 FROM managed_policies WHERE domain='com.apple.applicationaccess' AND name='allowCloudDocumentSync' AND (value != 0 AND value != 'false') ); /*CIS does not make a hard recommendation for this policy. Fleet has provided two policies (one failing, one succeeding). Depending on your organization's decision, you can delete this policy or its counterpart.*/

iCloud Keychain（allowCloudKeychainSync）、Siri（allowAssistant）以及 Siri 的多个子字段（TypeToSiriEnabled、StatusMenuVisible、VoiceTriggerUserEnabled、LockscreenEnabled，均以-enabled/-disabled成对存在于策略文件中）遵循同样的模式。对于 iCloud 类控制，描述文件中给出的键值规范非常明确：PayloadType为com.apple.applicationaccess，allowCloudDocumentSync/allowCloudKeychainSync按决定设为<true/>或<false/>。

七、CIS 未强制但 Fleet 仍提供的密码复杂度策略

README 还特别指出，CIS 已决定不强制要求以下 4 项密码复杂度设置：

• 5.2.3Ensure Complex Password Must Contain Alphabetic Characters Is Configured
• 5.2.4Ensure Complex Password Must Contain Numeric Character Is Configured
• 5.2.5Ensure Complex Password Must Contain Special Character Is Configured
• 5.2.6Ensure Complex Password Must Contain Uppercase and Lowercase Characters Is Configured

但 Fleet仍以策略形式提供了这些检查（目录中的 macos15-5.2.3-and-5.2.4.mobileconfig 与macos15-5.2.5.mobileconfig即对应此类控制）。这样做的原因是：部分行业或组织有比 CIS 默认基线更严格的口令策略需求。README 给出的处置建议非常干脆：如果组织不打算实施这些更严格的要求，直接删除对应策略即可，不影响其余 CIS 基线的合规判定。

八、部署实操：从文件到生产设备

结合 README 与仓库其他文档，完整落地流程如下：

步骤 1：准备 Fleet 环境

确保 Fleet 服务器可用、目标 macOS 15 设备已通过 MDM 与 fleetd 完成注册（enrollment），相关流程可参考 articles/enroll-macos-devices.md（实际仓库对应文件为 docs/Using Fleet 相关章节及 articles/end-user-authentication.md）。

步骤 2：导入策略（GitOps 方式）

策略文件是标准 Fleet 策略 YAML，支持两种导入路径：

# 方式一：直接应用整个策略文件 fleetctl apply -f docs/solutions/cis/macos-15/policies/cis-policy-queries.yml # 方式二：在 GitOps fleet.yml 中以 - path: 引用（推荐，便于纳入 Git 工作流） # fleet.yml 中: # controls: # policies: # - path: docs/solutions/cis/macos-15/policies/cis-policy-queries.yml

GitOps 模式的整体理念可参见 articles/gitops-mode.md 与 articles/preventing-mistakes-with-gitops.md。

步骤 3：上传配置描述文件

在 Fleet UI 的 MDM 配置描述文件管理页面逐条上传configuration-profiles/下的.mobileconfig文件，或同样通过fleetctl apply下发。务必把描述文件与对应策略的适用范围对齐（同一团队/同一组设备），否则会出现"策略在跑、描述文件没下发"的持续失败状态。

步骤 4：关联修复脚本

对策略名带(Fleetd Required)、且存在对应脚本的控制项（如登录横幅 2.10.3、目录服务 2.3.3.1 等），在策略编辑页面把scripts/中的对应脚本设置为run_script修复动作，实现失败自动修复。

步骤 5：处理决策类策略

按第六节所述，在明确组织决定后删除-enabled或-disabled中多余的一条；按第七节评估是否需要密码复杂度策略，不需要则一并删除。

步骤 6：验证

在 Fleet UI 的"主机详情 → 策略"视图中观察各 CIS 策略的通过/失败情况；对(MDM Required)类策略，先确认描述文件是否已成功下发（可参考仓库中 MDM 配置描述文件状态相关文档）。需要注意的是，部分查询（如软件更新检查）运行时间较长，应给予足够的执行窗口。

九、方案边界与最佳实践总结

• 基准版本锁定：本目录针对 CIS macOS 15 Benchmarkv1.1.0编写。若 CIS 发布更高版本，需要人工比对增量控制项，不能简单认为目录内容自动覆盖新版本；
• 检测 ≠ 强制：策略查询只负责"判断"，真正的"强制"靠.mobileconfig描述文件，"修复"靠scripts/脚本，三者缺一不可；
• 人工审计项不可自动化：第五节的 9 项清单必须纳入人工审计 SOP，避免误以为"导入策略 = 全量合规"；
• 决策类策略会制造持续告警：同时存在-enabled/-disabled时必有失败项，这是设计使然，应在组织决策后收敛；
• 元数据仅作参考：策略文件中的purpose、tags、contributors等字段在 GitOps 模式下为只读，不要试图通过 GitOps 修改它们。

通过以上方式，你可以把 macOS 15 Sequoia 的 CIS 基线转化为 Fleet 中可持续运行的自动化合规体系，将"人工翻设置"升级为"策略检测 + 描述文件强制 + 脚本修复"的闭环，并借助 GitOps 让整套合规配置可审计、可回滚、可复现。

• 后端
• 前端
• 企业应用
• 运维
• 网络安全