10.3 企业级管控

当 Claude 进入组织规模，你需要不可被个人绕过的策略、审计和权限收敛。

读完你能做什么：理解管理策略层的能力，为组织设计安全合规的 Claude 部署。

---

一、管理策略层（Managed Settings）

组织的核心管控手段是管理策略设置 —— 它在配置优先级的最顶层，个人无法覆盖。

配置优先级（从低到高）
用户 < 项目 < 本地 < --settings < 【管理策略设置】← 最高，个人不可覆盖

1.1 部署位置

管理策略设置和管理 CLAUDE.md 部署在系统级路径，由 IT/DevOps 通过 MDM、组策略、Ansible 等下发：

macOS:        /Library/Application Support/ClaudeCode/
Linux/WSL:    /etc/claude-code/
Windows:      C:\Program Files\ClaudeCode\

---

二、能管控什么

管控项	配置	效果
禁止特定工具/命令/路径	permissions.deny	确定性阻止，个人不可解除
强制沙箱隔离	sandbox.enabled	强制隔离运行
环境变量与 API 路由	env	统一后端（如企业 Bedrock）
认证方式与组织锁定	forceLoginMethod、forceLoginOrgUUID	强制企业账号
组织级行为指令	管理 CLAUDE.md 或 claudeMd 键	全员生效的行为规范
只允许管理员的 hook	allowManagedHooksOnly	阻止个人/项目 hook
强制启用插件	enabledPlugins	下发经审核的能力包

---

三、设置 vs CLAUDE.md：分工

企业管控要用对工具：

需求	用什么	为什么
阻止具体工具/命令/路径	managed settings permissions.deny	客户端强制执行，确定性
强制沙箱	sandbox.enabled	技术强制
环境变量、后端路由	env	技术配置
认证锁定	forceLoginMethod 等	技术强制
代码风格、质量指引	管理 CLAUDE.md	行为引导
数据处理、合规提醒	管理 CLAUDE.md	行为引导

核心区别：

• settings 是客户端强制执行的 —— 无论 Claude 想做什么，都被硬性拦住
• CLAUDE.md 是行为引导 —— 塑造 Claude 的倾向，但不是硬拦

安全边界用 settings，行为规范用 CLAUDE.md。

---

四、管理 CLAUDE.md

组织可以下发一份全机器生效、个人不可排除的 CLAUDE.md：

部署到管理策略位置的 CLAUDE.md
  → 每个会话、每个仓库都加载
  → 个人的 claudeMdExcludes 无法排除它

或者直接在 managed-settings.json 里内联：

{
  "claudeMd": "提交前必须运行 make lint。\n禁止直接 push 到 main。\n处理客户数据时遵守数据分类政策。"
}

claudeMd 键只在管理/策略设置里生效。

---

五、权限收敛

企业最关心的往往是"防止 Claude 做危险的事"。用 managed settings 的 deny 规则建立不可绕过的底线：

{
  "permissions": {
    "deny": [
      "Bash(rm -rf /*)",
      "Read(./.env*)",
      "Read(./**/*secret*)",
      "Read(./**/credentials*)",
      "Bash(curl * | *sh)",
      "Bash(git push --force*)",
      "mcp__*(*delete*)",
      "mcp__prod_db__*"
    ]
  }
}

因为在管理层，个人的 settings.json 无法解除这些 deny。这是组织安全底线的技术保障。

---

六、Hook 的组织管控

6.1 只允许管理员 hook

{
  "allowManagedHooksOnly": true
}

启用后，个人、项目、插件的 hook 都被阻止，只有管理策略里的 hook 生效。这防止有人通过恶意 hook 绕过管控。

6.2 通过组织市场分发受审 hook

被 enabledPlugins 强制启用的插件里的 hook，可以豁免上述限制 —— 让管理员能通过组织的私有 marketplace 分发经过审核的 hook。

个人不能随便加 hook（allowManagedHooksOnly）
但管理员可以通过审核过的插件分发标准 hook
= 既安全又不失灵活

---

七、连接器的组织控制

对 MCP 连接器，组织可以：

• 把某些连接器工具设为 ask（强制人工确认）
• 完全禁用某些 claude.ai 连接器
• 通过管理设置锁定 MCP 配置

这对"防止敏感系统被 Agent 自动操作"很关键。见 07.3。

---

八、认证与账号锁定

{
  "forceLoginMethod": "sso",
  "forceLoginOrgUUID": "<你的组织 UUID>"
}

强制所有人用企业 SSO 登录，且锁定到指定组织 —— 防止员工用个人账号，确保用量和数据都在组织管控内。

---

九、后端路由

大型组织常把模型请求路由到自己的云平台（Bedrock / Vertex / Foundry）：

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1"
  }
}

配合区域、模型固定等配置，统一全组织的模型后端。具体以官方文档为准。

---

十、一份企业管控清单

部署 Claude 到组织时，逐项确认：

安全底线
□ 危险命令 deny 规则（rm -rf、force push、curl|sh）
□ 敏感文件 deny 规则（.env、密钥、凭据）
□ 生产系统的 MCP 工具禁用或强制确认
□ allowManagedHooksOnly 视需要开启

认证与账号
□ forceLoginMethod 强制 SSO
□ forceLoginOrgUUID 锁定组织

行为规范
□ 管理 CLAUDE.md 下发合规提醒
□ 数据分类/处理政策写入

能力分发
□ 经审核的插件通过 enabledPlugins 下发
□ 私有 marketplace 建立

后端
□ 模型后端路由配置（如需）
□ 网络代理配置

审计
□ 明确日志和审计方案

---

十一、平衡管控与效率

管控不是越严越好。过度收紧会让 Claude 失去价值：

管得太松 → 安全风险
管得太严 → Claude 什么都做不了，员工绕过它用别的

好的平衡：
- 硬性禁止真正危险的（删除、生产写、密钥）
- 放开安全的日常操作（读代码、跑测试、改文件）
- 敏感操作要人工确认，而非完全禁止

原则：deny 危险的，ask 敏感的，allow 安全的。

---

延伸阅读

• 10.1 Plugin 与 Marketplace
• 10.2 团队标准化配置
• 05.5 权限模型与安全边界
• 06.8 Settings 配置全解