27-企业安全实践
本节目标
完成本节学习后，你将能够：
配置
.claude/settings.json安全规则，精准控制 Claude Code 的权限边界识别并分类危险命令，实施分级阻止策略（警告/确认/禁止）
使用
/sandbox命令实现 OS 级进程隔离（Linux bubblewrap / macOS Seatbelt）制定敏感文件保护策略，防止 AI 访问
.env、密钥、证书和内部文档建立环境变量安全管理与审计日志体系，满足企业合规要求
核心知识点
一、安全配置的三道防线
Claude Code 的企业安全通过三道防线实现纵深防御：
第一道防线：配置层 (settings.json) └─ 权限白名单/黑名单、命令限制、文件访问控制 └─ 最轻量、最容易部署，适合所有团队 第二道防线：沙箱层 (/sandbox) └─ OS 级进程隔离，文件系统和网络访问受限 └─ 适合高风险操作（如处理生产数据、执行未知代码） 第三道防线：审计层 (audit logging) └─ 所有操作的完整记录和事后追溯 └─ 适合有合规要求的行业（金融、医疗、政府）
二、危险命令分级体系
| 危险等级 | 命令类型 | 策略 | 示例 |
|---|---|---|---|
| L3 - 致命 | 不可逆的破坏性操作 | 硬阻止 (hard-block) | rm -rf /,git push --force origin main,DROP DATABASE |
| L2 - 危险 | 可能造成损失的操作 | 弹窗确认 (confirm) | git reset --hard,chmod 777,sudo |
| L1 - 警惕 | 有风险但必要的操作 | 静默警告 (warn) | npm publish,docker rm,kubectl delete |
| L0 - 安全 | 日常开发操作 | 允许 (allow) | git status,npm test,ls,cat |
三、/sandbox的三种隔离等级
Claude Code v2.1.x 支持三级沙箱模式：
| 等级 | 文件系统 | 网络 | 适用场景 |
|---|---|---|---|
read-only | 可读取项目文件，禁止写入 | 允许出站 | 代码审查、代码分析 |
isolated | 仅可读当前项目 | 仅允许白名单域名 | 运行不可信脚本、生成测试数据 |
air-gapped | 临时文件系统 | 完全隔离 | 处理高度敏感数据、合规审查 |
四、敏感文件分类保护
┌─────────────────────────────────────────────┐ │ 敏感文件保护矩阵 │ ├─────────────┬──────────┬────────────────────┤ │ 文件类型 │ 保护级别 │ 应对策略 │ ├─────────────┼──────────┼────────────────────┤ │ .env / .env.*│ 关键 │ 阻止读取，不显示内容 │ │ *.pem / *.key│ 关键 │ 阻止读取 │ │ credentials.*│ 关键 │ 阻止读取 │ │ internal/ │ 高级 │ 警告 + 需确认 │ │ *.conf (含密钥)│ 高级 │ 扫描后脱敏 │ │ .git/config │ 中级 │ 只读，提示风险 │ └─────────────┴──────────┴────────────────────┘
实操步骤
步骤1：配置项目级安全规则
创建.claude/settings.json：
{ "security": { "blockedCommands": [ "rm -rf", "rm -rf /", "git push --force origin main", "git push --force origin master", "DROP DATABASE", "DROP TABLE", ":(){ :|:& };:", "mkfs", "dd if=" ], "confirmCommands": [ "git reset --hard", "git clean -fd", "chmod 777", "sudo", "npm unpublish", "docker system prune" ], "warnCommands": [ "npm publish", "docker rm -f", "kubectl delete", "terraform destroy", "aws s3 rm" ], "fileAccessRules": { "denyPatterns": [ ".env", ".env.*", "*.pem", "*.key", "credentials.*", "**/secrets/**", "**/internal/**" ], "warnPatterns": [ "*.conf", ".git/config", "**/passwords/**" ] }, "networkRules": { "allowOutbound": true, "blockedDomains": [ "*.internal.corp.com", "pastebin.com", "termbin.com" ] } }, "sandbox": { "defaultMode": "read-only", "escalationRequiresApproval": true }, "audit": { "enabled": true, "logLevel": "info", "retentionDays": 90, "redactSecrets": true } }步骤2：启用/sandbox安全操作
# 进入隔离沙箱模式（默认 read-only） cc --sandbox read-only # 在沙箱中进行代码审查（AI 无法修改你的文件） cc@read-only> review the changes in src/auth/ # 进入完全隔离模式（处理敏感数据） cc --sandbox air-gapped # 编译器、Linter 等受信工具可在沙箱内运行 cc@air-gapped> analyze this SQL file for injection vulnerabilities # 注意：此模式下无法访问外部 API 文档，Claude 只能基于自身知识分析 # 退出沙箱 cc@air-gapped> /sandbox exit
步骤3：环境变量安全管理
# 方式1：通过 .env 文件注入（不纳入 git） # .claude/.env (已在 .gitignore 中) ANTHROPIC_API_KEY=sk-ant-xxx NODE_ENV=development # 方式2：系统环境变量（推荐用于 CI） export ANTHROPIC_API_KEY=sk-ant-xxx # Claude Code v2.1.x 支持读取环境变量但不会在输出中暴露 # 方式3：临时会话变量（最安全） ANTHROPIC_API_KEY=sk-ant-xxx cc --session one-shot ...
关键规则：
.env文件必须在.gitignore中，且在settings.json的denyPatterns中CI 环境的 Token 使用独立的、有限权限的 API Key
定期轮换所有 API Key，建议周期 ≤ 90 天
步骤4：配置审计日志
# 查看当前审计日志位置 cc audit --status # 导出审计报告（最近30天） cc audit --export --since "30 days ago" --output audit-report.json # 审计报告包含的结构 # { # "session_id": "sess_abc123", # "timestamp": "2026-05-26T10:30:00Z", # "user": "alice@company.com", # "commands": [...], # "files_accessed": [...], # "api_calls": 47, # "tokens_used": 32500, # "sandbox_mode": "read-only", # "warnings_triggered": ["attempted access to .env file"] # }定期导出审计日志并接入企业的 SIEM 系统（如 Splunk、ELK）：
# 周度审计脚本示例 #!/bin/bash WEEK=$(date +%Y-W%U) cc audit --export --since "7 days ago" --output "/var/log/claude/audit-$WEEK.json" # 推送至 SIEM curl -X POST https://siem.company.com/ingest \ -H "Authorization: Bearer $SIEM_TOKEN" \ -d @"/var/log/claude/audit-$WEEK.json"
步骤5：安全检查自动化
# 在 pre-commit 中集成安全检查 # .git/hooks/pre-commit #!/bin/bash echo "Running Claude Code security pre-check..." cc check --mode security --staged-only if [ $? -ne 0 ]; then echo "安全扫描发现问题，请修复后再提交" exit 1 fi
避坑指南
不要只靠在 settings.json 中的"禁止规则"就觉得安全了：攻击者可能通过 Shell 转义、别名绕过简单的字符串匹配。安全的核心是"纵深防御"：settings.json 只是第一层，配合 sandbox 和环境隔离才能有效防护。
沙箱模式不是万能的：
read-only沙箱仍然可能通过 Claude 的 API 调用泄露信息（如代码内容被发送到 Anthropic 服务器）。如果代码包含商业机密，需要评估 API 数据传输的风险，或考虑使用 air-gapped 模式下的本地模型（如果企业基础设施支持）。敏感文件保护要测试验证：不要以为配置了 denyPatterns 就万事大吉。实际测试：让 Claude 尝试读取
.env文件，看它是否被正确拦截。关注边界情况：符号链接、路径穿透（../../.env）。审计日志的成本：长期保留详细审计日志会占据大量存储空间。建议区分"全量日志"和"摘要日志"：全量日志保留 30 天，摘要日志保留 90 天以上。摘要日志只需记录关键事件（命令执行、文件访问、权限变更）。
不要用个人 API Key 跑 CI 任务：这是最常见的安全反模式。为每个 CI 任务创建独立的 API Key，并在 Key 中打上用途标签，方便成本和安全的归因分析。
课后作业
安全配置演练：为你当前的项目创建或审查
.claude/settings.json。根据实操步骤中的模板，补充适合你项目的危险命令和文件保护规则。至少配置 10 条 blockedCommands 和 5 条 fileAccessRules。沙箱实战：在 read-only 和 air-gapped 两种沙箱模式中各完成一次代码审查，对比两种模式的体验差异。记录：哪些操作在 air-gapped 下受限？这是否影响了审查效果？
审计日志分析：导出你（或团队）过去 30 天的 Claude Code 使用日志，尝试回答以下问题：日均 token 消耗？哪些文件被访问次数最多？是否有触发安全警告的事件？基于分析结果，写一份简短的优化建议。
总结
企业安全实践不是"加一把锁"而是"造一座城堡"——需要多层次、纵深化的防护体系。settings.json 提供了最灵活的配置层，/sandbox提供了 OS 级的隔离能力，审计日志则确保了事后追溯和合规报告的可能。三者配合，才能在"安全"与"效率"之间找到企业级的平衡点。
核心记忆点：
三道防线：配置层 -> 沙箱层 -> 审计层
危险命令三级分类：硬阻止(L3)、需确认(L2)、静默警告(L1)
沙箱三模式：read-only、isolated、air-gapped
敏感文件必须多重保护：.gitignore + settings.json + sandbox
审计日志是企业合规的必要条件
下一节将进入团队协作工作流，探讨多人团队中如何使用 Claude Code 协同开发。