OpenClaw安全架构分析
1. 摘要
本报告对OpenClaw自托管 AI 网关平台进行全面的安全架构分析,包括安全设计机制评估和 STRIDE 威胁建模。
|
安全领域 |
设计状态 |
风险等级 |
|
认证与授权 |
Token/密码/设备认证 |
中 |
|
会话隔离 |
每发送者会话隔离 |
低 |
|
工具权限控制 |
可配置安全策略 |
中 |
|
执行沙箱 |
可选 Docker 沙箱 |
中 |
|
通道安全 |
配对/白名单机制 |
低 |
|
凭证存储 |
本地加密存储 |
中 |
核心结论:OpenClaw 采用"个人助理"信任模型,假设单一可信操作员边界。安全设计侧重于防止外部未授权访问,而非多租户隔离。
2. OpenClaw 架构概述
2.1 系统架构
OpenClaw 是一个自托管网关,连接聊天应用(WhatsApp/Telegram/Discord/飞书/微信/钉钉等)与 AI 编码代理。
|
组件 |
功能描述 |
|
Gateway(网关) |
控制平面,处理认证、路由、会话管理 |
|
Channels(通道) |
消息通道插件,支持 WhatsApp/Telegram/Discord 等 |
|
Agents(代理) |
AI 代理执行层,支持多代理路由 |
|
Nodes(节点) |
远程执行表面,支持 iOS/Android 设备配对 |
|
Tools(工具) |
工具执行层,包括 exec/browser/filesystem 等 |
2.2 信任模型
OpenClaw 采用“单一可信操作员”信任模型:
• 每个网关实例假设一个可信操作员边界
• 通过网关认证的调用者被视为该网关的可信操作员
• 会话标识符(sessionKey)是路由控制,不是每用户授权边界
• 不支持在同一网关/配置上运行多租户隔离
• 如需多用户隔离,建议每个信任边界使用独立的网关/主机
3. 安全设计机制
3.1 认证与授权
网关认证模式:
|
认证模式 |
描述 |
适用场景 |
|
Token 认证 |
使用长随机 Token |
API 调用、远程访问 |
|
密码认证 |
使用配置密码 |
本地管理 |
|
设备认证 |
配对设备信任 |
移动节点 |
|
代理认证 |
每代理认证配置文件 |
多代理场景 |
配置示例:
gateway.auth: { mode: "token", token: "长随机 Token" }
3.2 会话隔离
会话作用域配置:
• dmScope: "per-channel-peer" - 每通道对等体隔离
• dmScope: "per-account-channel-peer" - 每账户通道对等体隔离
• 会话标识符用于路由和上下文选择,不是授权令牌
3.3 工具权限控制
工具安全策略:
|
工具类别 |
安全控制 |
默认策略 |
|
Exec(执行) |
security: deny/allowlist/full |
deny(最严格) |
|
Browser(浏览器) |
profile 控制、远程节点配对 |
受限 |
|
Filesystem(文件系统) |
workspaceOnly: true |
工作区限制 |
|
Sessions(会话) |
sessions_spawn 拒绝 |
拒绝 |
|
Elevated(提升权限) |
enabled: false |
禁用 |
|
Node(节点) |
denyCommands/allowCommands |
精确命令匹配 |
3.4 执行沙箱
沙箱模式配置:
• agents.defaults.sandbox.mode: "off"(默认)- 直接在主机执行
• agents.defaults.sandbox.mode: "non-main" - 非主会话使用沙箱
• agents.defaults.sandbox.mode: "all" - 所有会话使用沙箱
• sessions_spawn 时可使用 sandbox: "require" 强制沙箱
Docker 沙箱特性:
• 非 root 用户运行(node 用户)
• 只读文件系统支持(--read-only)
• 能力限制(--cap-drop=ALL)
• 临时目录隔离(/tmp/openclaw)
3.5 通道安全
通道安全机制:
|
机制 |
描述 |
配置位置 |
|
配对(Pairing) |
需要用户确认配对 |
dmPolicy: "pairing" |
|
白名单(allowFrom) |
限制允许发送者 |
channels.<type>.allowFrom |
|
群组提及要求 |
群组中需要@提及 |
groups: { "*": { requireMention: true } } |
|
凭证隔离 |
每账户凭证存储 |
~/.openclaw/credentials/ |
3.6 凭证存储
凭证存储位置:
• WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• Telegram: channels.telegram.tokenFile(仅常规文件,拒绝符号链接)
• Discord: 配置/env 或 SecretRef
• 配对白名单:~/.openclaw/credentials/<channel>-allowFrom.json
• 代理认证:~/.openclaw/agents/<agentId>/agent/auth-profiles.json
3.7 网络安全
网络绑定配置:
• gateway.bind: "loopback"(默认)- 仅本地访问
• gateway.mode: "local" - 本地模式
• 远程访问建议:SSH 隧道或 Tailscale Serve/Funnel
• Control UI: 默认仅本地,禁止公开暴露
4. STRIDE 威胁建模分析
使用 STRIDE 模型对 OpenClaw 进行系统性威胁分析:
4.1 Spoofing(欺骗)
威胁场景:攻击者伪装成合法用户或组件
|
攻击向量 |
现有缓解 |
剩余风险 |
|
网关 API 未授权访问 |
Token/密码认证 |
弱 Token/密码风险 |
|
节点配对劫持 |
配对确认流程 |
中间人攻击(如未加密) |
|
通道消息伪造 |
通道平台认证 |
依赖平台安全 |
|
插件身份伪造 |
插件 ID 白名单 |
需启用 plugins.allow |
|
代理身份冒充 |
每代理认证配置 |
认证配置不当风险 |
建议:使用强随机Token、启用 TLS、配置 plugins.allow 白名单
4.2 Tampering(篡改)
威胁场景:攻击者篡改数据、配置或代码
|
攻击向量 |
现有缓解 |
剩余风险 |
|
配置文件篡改 |
文件系统权限 |
需 OS 级别保护 |
|
凭证文件篡改 |
文件权限、符号链接检查 |
可信操作员边界内风险 |
|
会话历史篡改 |
无完整性保护 |
内存/存储篡改 |
|
插件代码篡改 |
插件信任假设 |
安装后篡改风险 |
|
消息内容篡改 |
通道平台保护 |
依赖平台安全 |
建议:启用文件完整性监控、使用只读挂载、定期备份配置
4.3 Repudiation(抵赖)
威胁场景:用户否认执行的操作
|
攻击向量 |
现有缓解 |
剩余风险 |
|
Exec 命令执行 |
Exec 审批日志 |
日志可能被清除 |
|
工具调用 |
会话历史记录 |
无审计追踪 |
|
配置变更 |
无版本控制 |
无法追溯变更 |
|
消息发送 |
通道平台日志 |
依赖外部日志 |
建议:启用详细日志、配置日志持久化、实现配置版本控制
4.4 Information Disclosure(信息泄露)
威胁场景:敏感信息泄露给未授权方
|
攻击向量 |
现有缓解 |
剩余风险 |
|
凭证泄露 |
本地存储、文件权限 |
主机被入侵风险 |
|
会话历史泄露 |
会话隔离 |
共享网关场景风险 |
|
Memory 文件泄露 |
工作区文件保护 |
可信边界内风险 |
|
API Token 泄露 |
环境变量/配置文件 |
配置不当风险 |
|
浏览器控制暴露 |
节点配对、远程限制 |
配置不当风险 |
|
日志敏感信息 |
日志脱敏配置 |
脱敏不完整风险 |
建议:启用日志脱敏、限制会话历史访问、使用 secrets 管理敏感配置
4.5 Denial of Service(拒绝服务)
威胁场景:攻击者使服务不可用
|
攻击向量 |
现有缓解 |
剩余风险 |
|
API 洪水攻击 |
网关认证、速率限制 |
认证前攻击 |
|
大消息处理 |
媒体大小限制 |
资源耗尽 |
|
沙箱资源耗尽 |
Docker 资源限制 |
需配置限制 |
|
节点命令洪水 |
denyCommands/allowCommands |
允许列表内攻击 |
|
ReDoS(正则 DoS) |
配置输入验证 |
自定义正则风险 |
建议:配置速率限制、设置资源限制、监控异常流量
4.6 Elevation of Privilege(权限提升)
威胁场景:攻击者获取更高权限
|
攻击向量 |
现有缓解 |
剩余风险 |
|
Exec 命令注入 |
security: deny/ask |
审批绕过风险 |
|
沙箱逃逸 |
Docker 隔离 |
容器逃逸漏洞 |
|
插件权限提升 |
插件信任假设 |
恶意插件风险 |
|
节点命令执行 |
命令白名单 |
命令参数注入 |
|
配置热加载 |
需重启生效 |
运行时篡改 |
建议:严格 Exec 策略、启用沙箱、限制插件、定期更新
5. 安全审计与加固
5.1 安全审计命令
OpenClaw 提供内置安全审计工具:
• openclaw security audit - 快速审计
• openclaw security audit --deep - 深度审计(含实时探测)
• openclaw security audit --fix - 自动修复
• openclaw security audit --json - JSON 输出
5.2 审计检查项
审计覆盖范围:
- 入站访问(DM 策略、群组策略、白名单)
- 工具爆炸半径(提升工具 + 开放房间)
- Exec 审批漂移(security=full, autoAllowSkills)
- 网络暴露(网关绑定/认证、Tailscale)
- 浏览器控制暴露(远程节点、中继端口)
- 本地磁盘卫生(权限、符号链接、配置)
- 插件/扩展(无明确白名单)
- 策略漂移/误配置
- 运行时期望漂移
- 模型选择(过时模型警告)
5.3 60 秒加固基线
推荐加固配置:最小权限+本地隔离+工具强管控+会话隔离
{
gateway: {
mode: "local", //仅本地模式,不对外暴露服务
bind: "loopback", //只绑定127.0.0.1,禁止外部访问
auth: { mode: "token", token: "长随机 Token" }, //强制令牌鉴权
},
session: {
dmScope: "per-channel-peer", //会话隔离
},
tools: {
profile: "messaging", //基础权限:仅消息通信
deny: ["group:automation", "group:runtime", "group:fs"], //禁止高危能力
fs: { workspaceOnly: true }, //文件仅允许访问工作目录
exec: { security: "deny", ask: "always" }, //禁止执行命令,任务命令都需人工确认
elevated: { enabled: false }, //禁止提权/管理员权限
},
channels: {
whatsapp: { dmPolicy: "pairing", //私聊必须配对认证
groups: { "*": { requireMention: true } } }, //群内必须@才响应
},
}
6. 风险与建议
6.1 高风险场景
|
风险场景 |
风险等级 |
缓解措施 |
|
公开网络暴露 |
高 |
使用 loopback 绑定 + SSH/Tailscale |
|
共享网关 + 宽工具权限 |
高 |
分离信任边界、最小化工具 |
|
浏览器控制远程暴露 |
高 |
仅 tailnet、谨慎配对 |
|
Exec security=full 无沙箱 |
中 |
启用沙箱或 security=deny |
|
插件无白名单 |
中 |
启用 plugins.allow |
6.2 优先级修复建议
优先级 1(立即修复):
- 任何"开放"+工具启用:锁定 DM/群组,收紧工具策略
- 公开网络暴露:立即修复
优先级 2(尽快修复):
- 浏览器控制远程暴露:限制为 tailnet only
- 权限问题:确保状态/配置/凭证非组/世界可读
优先级 3(定期审查):
- 插件/扩展:仅加载明确信任的
- 模型选择:优先现代、指令强化模型
6.3 运营建议
定期任务:
- 每周运行 openclaw security audit
- 每月审查通道白名单和工具策略
- 每季度更新 OpenClaw 和依赖
- 定期备份配置和凭证
7. 结论
核心发现:
- OpenClaw 采用单一可信操作员信任模型,不适合多租户隔离
- 安全设计侧重于防止外部未授权访问,依赖主机信任边界
- 提供丰富的安全配置选项,但默认配置偏向易用性
- STRIDE 分析显示主要风险在于配置不当和网络暴露
安全态势总结:
OpenClaw 在正确的配置和运营下可以提供合理的安全保障,但需要操作员理解其信任模型并实施适当的加固措施,以及配合相应的安全管理策略。同时也要认识到它不是为应对多租户环境设计的,因此企业级生产环境部署需要综合考虑安全运营成本,在OpenClaw自身架构不改变情况下可以通过私有化部署进行多租户的集中管理实践,从而又将AI安全结合到云安全一起考虑。
更多推荐
所有评论(0)