05-企业级安全策略与 MDM 部署

企业级安全策略与 MDM 部署

学习目标

本章将分析 Claude Code 的企业级部署能力，通过官方示例中的设置模板和 MDM 部署配置，掌握：

三层安全策略模板（Lax/Strict/Sandbox）的具体配置
安全 Hook 的 9 类监控模式及其实现细节
5 种 MDM 部署方式的适用场景和约束
设置优先级链和覆盖规则

前置知识

本章涉及企业级安全的通用原理，建议先阅读：

企业级安全策略与 MDM 部署

下文假设你已理解企业安全的基础概念，直接聚焦 Claude Code 的具体实现。

项目实践

三层设置模板

Claude Code 在 examples/settings/ 中提供三套配置模板：

Lax 模式（`settings-lax.json`）

最小限制配置，适用于信任度高的内部开发团队：

禁用 --dangerously-skip-permissions 标志（防止绕过权限检查）
阻止安装第三方插件市场（allowedMarketplaces 限制）

Strict 模式（`settings-strict.json`）

严格管控配置，适用于外包团队或高安全要求环境：

Lax 模式的所有限制 +
阻止用户和项目级权限覆盖（permissions.allow / permissions.ask / permissions.deny 被锁定）
阻止用户和项目级 Hook
拒绝 WebFetch 和 WebSearch 工具
Bash 工具需要逐次审批

Bash 沙箱模式（`settings-bash-sandbox.json`）

隔离执行配置，适用于执行不受信任代码的场景：

Bash 工具必须在沙箱中运行（bash.sandbox: true）

重要约束：沙箱仅保护 Bash 工具。Read、Write、MCP 工具不受沙箱保护。如需控制这些工具，需要配合 Strict 模式的工具权限设置。

安全模式监控实现

security-guidance 插件实现了 9 类安全模式监控，通过 PreToolUse Hook 拦截文件编辑操作。

GitHub Actions 命令注入检测是最复杂的规则：

# 17 种可注入的 GitHub Actions 输入
risky_inputs = [
    "github.event.issue.title",
    "github.event.issue.body",
    "github.event.pull_request.title",
    "github.event.pull_request.body",
    "github.event.commit.message",
    # ... 共 17 种
]

检测逻辑：如果编辑的文件匹配 .github/workflows/*.yml，且内容包含 ${{ <risky_input> }} 在 run: 块中，则触发安全警告。

推荐修复方案：使用 env: 块进行适当引用：

# 不安全
run: echo "Title: ${{ github.event.issue.title }}"

# 安全
env:
  TITLE: ${{ github.event.issue.title }}
run: echo "Title: $TITLE"

MDM 部署模板

Claude Code 在 examples/mdm/ 中提供 5 种部署方式的模板：

模板文件	平台	部署方式
`managed-settings.json`	跨平台	直接复制到系统配置目录
`macos/com.anthropic.claudecode.plist`	macOS	Jamf/Kandji Custom Settings
`macos/com.anthropic.claudecode.mobileconfig`	macOS	完整配置描述文件
`windows/Set-ClaudeCodePolicy.ps1`	Windows	Intune Platform Scripts
`windows/ClaudeCode.admx` + `en-US/ClaudeCode.adml`	Windows	Group Policy ADMX 导入

关键部署约束：

ADMX 单行 JSON：Windows Group Policy 通过 REG_SZ 存储设置值，必须是单行 JSON（无换行、无缩进）
Plist UUID 唯一性：每个 PayloadUUID 必须全局唯一，使用 uuidgen 生成
设置来源验证：部署后运行 /status，确认 Setting sources 列表中包含新部署的来源

设置优先级链的实际影响

Managed Settings（企业强制）
    ↓ 覆盖
Project Settings（项目级）
    ↓ 覆盖
User Settings（用户级）
    ↓ 覆盖
Local Settings（本地临时）

实际影响示例：

如果 Managed Settings 设置了 allowedMarketplaces: ["official"]，即使用户在 User Settings 中添加了第三方市场，也不会生效
如果 Managed Settings 设置了 allowManagedHooksOnly: true，只有企业批准的 Hook 可以执行
仅在高优先级生效的设置项：strictKnownMarketplaces、allowManagedHooksOnly、allowManagedPermissionRulesOnly

环境变量门控

安全 Hook 支持环境变量控制开关，使得运维团队可以在不修改配置的情况下临时关闭安全提醒：

ENABLED = os.environ.get("ENABLE_SECURITY_REMINDER", "1") == "1"
if not ENABLED:
    sys.exit(0)

这在以下场景特别有用：

CI/CD 环境中安全 Hook 会阻塞构建
开发者需要临时编辑包含敏感模式的文件（如 .env）
安全规则误报率过高需要临时关闭

陷阱与对策

陷阱	表现	对策
Managed settings JSON 格式错误	整个配置静默失效	部署前用 JSON 验证器（如 `jq`）检查
ADMX 单行 JSON 被截断	复杂配置不完整	压缩 JSON（无换行无缩进），确认 REG_SZ 长度限制
沙箱仅保护 Bash	Read/Write 工具不受保护	配合 Strict 模式的工具权限控制
Plist PayloadUUID 冲突	配置描述文件安装失败	使用 `uuidgen` 生成唯一 UUID
设置变更后未验证	旧配置仍在生效	每次变更后检查 `/status` 确认

设计取舍

为什么提供 3 种设置模板而非 1 种？

不同组织的安全需求差异巨大。提供模板而非单一配置，允许组织根据风险承受能力快速裁剪。例如，内部团队可能只需要 Lax 模式，而金融机构可能需要 Strict + Sandbox 的组合。

为什么安全规则嵌入 Hook 而非独立系统？

复用现有的 Hook 基础设施，避免额外的部署和维护成本。Hook 的 Fail-open 原则也确保安全规则失效时不会卡住正常操作。

为什么 MDM 模板只包含最小示例而非完整配置？

模板的目的是提供正确的格式和结构参考。完整配置因组织而异，放入模板会迅速膨胀且很快过时。组织应该以模板为基础，根据自身需求扩展。

参考来源

Claude Code Managed Settings 文档
源码: examples/settings/settings-*.json
源码: examples/mdm/ 目录下所有部署模板
源码: plugins/security-guidance/hooks/security_reminder_hook.py

版本信息

📅 2026-05-24 🏷️ v2.1.150 🔀 39e853e