配置安全与远程访问

OpenClaw 的安全前提很明确：它是个人助手信任模型，不是给多个互不信任用户共用的多租户安全边界。新手必须先理解这个前提，否则后面讨论 allowlist、pairing、Control UI、远程访问和 sandbox 都会跑偏。

一句话：不要把一个有真实工具权限的 OpenClaw Gateway，当成可以随便给陌生人访问的公共服务。

1. 先理解：信任边界是什么

官方安全页的核心说法是：一个 Gateway 应该属于一个受信任的操作边界。可以是一个人，也可以是一个可信团队；但不能是多个互不信任的人共享同一个有工具权限的 Agent。

推荐边界是一个用户或可信团队、一个 Gateway、一套 credentials、一个 OS 用户或一台主机。

不推荐的边界是：公开群组直接接入可执行命令的 Agent；多人共享同一套个人浏览器、账号和密钥；Gateway 端口裸露到公网；把运行时凭据和 session transcript 提交到 workspace 仓库。

如果确实有互不信任用户，正确做法不是“多写几个规则”，而是拆 Gateway，最好拆到不同 OS 用户、不同主机或不同 VPS。

flowchart TD
    Trust["一个信任边界"]
    Gateway["一个 Gateway"]
    Credentials["一套 credentials"]
    Host["一个 OS 用户 / 主机"]
    Agents["一个或多个 Agent"]
    Untrusted["互不信任用户"]
    Split["拆 Gateway / OS 用户 / 主机"]

    Trust --> Gateway
    Trust --> Credentials
    Trust --> Host
    Gateway --> Agents
    Untrusted --> Split

    style Trust fill:#dcfce7,stroke:#22c55e,stroke-width:2px
    style Gateway fill:#e0f2fe,stroke:#0284c7,stroke-width:2px
    style Untrusted fill:#fee2e2,stroke:#ef4444,stroke-width:2px
    style Split fill:#fef3c7,stroke:#f59e0b,stroke-width:2px

2. 怎么判断入口是否安全

先问“谁能发消息”。DM 默认应该走 pairing 或 allowlist；群组入口也应该 require mention 或 allowlist。陌生人能直接驱动工具，是 OpenClaw 里最危险的形态。

再问“这个 Agent 能做什么”。能读文件、写文件、执行命令、控制浏览器、发消息、访问网络的 Agent，都不应该暴露给不受信任入口。

再问“上下文是否隔离”。不要让陌生人共享 main session。多用户场景至少使用 per-channel-peer 或 per-account-channel-peer 这类 session scope，避免一个人的输入污染另一个人的上下文。

最后问“远程入口如何保护”。远程访问优先用 Tailscale / VPN，其次 SSH tunnel；只有在受控反代、TLS、认证、trusted proxy 和审计都到位时，才考虑公网入口。

3. 先跑安全审计

每次改 channels、Gateway、Control UI、sandbox、tools、远程访问后，都应该跑官方 security audit。

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json

普通审计看明显危险配置；deep 审计看更细的组合风险；fix 只做有限修复，不替你决定业务策略。它能帮你发现开放 DM、开放 group、危险 Control UI flag、共享 main session、debug 绕过、权限过宽等问题。

新手不要把 audit 当形式。它应该是每次开放新入口前的检查点。

官方 security audit --fix 的修复范围是刻意收窄的：它会修一些常见 open group policy、日志脱敏、权限和文件模式问题，但不会替你决定业务上谁该拥有工具权限。

4. Control UI 不要降级认证

Control UI 最适合在 localhost 或 HTTPS 安全上下文里使用。官方文档里有一些兼容或调试 flag，但它们不应该被当成远程访问方案。

尤其要警惕 gateway.controlUi.allowInsecureAuth 和 gateway.controlUi.dangerouslyDisableDeviceAuth。前者是本地兼容开关，不是远程放行；后者属于严重降级，只能短时调试，调完立刻关。

新手判断标准很简单：如果你说不清为什么必须开这个 flag，就不要开。

5. 远程访问优先顺序

第一选择是 Tailscale 或 VPN，让 Gateway 不直接暴露在公网。

第二选择是 SSH tunnel。远端 Gateway 仍然绑定 loopback，本机通过隧道访问 127.0.0.1:18789。这能显著降低误暴露风险。

第三选择才是公网入口，而且必须有 TLS、认证、可信反代和日志审计。

远程连接不是“能打开页面就安全”。Gateway auth、device pairing、token 保管和 allowlist 仍然要保留。

SSH tunnel：

ssh -N -L 18789:127.0.0.1:18789 user@host

如果用 --url 访问远程 Gateway，CLI 不会自动复用隐式 config 或 env credentials。需要显式传 --token 或 --password，缺失就是错误。

6. Tailscale 的安全定位

OpenClaw 可以用 Tailscale Serve 或 Funnel 暴露 Gateway dashboard 和 WebSocket port。更稳的默认是 Serve：tailnet-only，Gateway 仍然绑定 loopback，Tailscale 提供 HTTPS、路由和身份头。

Funnel 是 public HTTPS，安全要求更高。新手不要把 Funnel 当成“比 SSH tunnel 更省事”的默认方案。

7. Sandbox 只降低爆炸半径，不等于完美隔离

OpenClaw 可以把 tools 放进 sandbox backend 里执行，例如 Docker、SSH 或 OpenShell。它能降低文件和进程访问范围，但不是完美安全边界。

被 sandbox 的通常是 tool execution，例如 exec、read、write、edit、apply_patch、process 等。Gateway 进程本身不在 sandbox 里；明确 elevated 的工具也可能绕开 sandbox。

8. Workspace 和运行时要分开

Workspace 可以作为私有 git 备份，但运行时状态不要进仓库。

不要提交 ~/.openclaw/openclaw.json、credentials、auth profiles、Codex home、sessions、全局 skills 等路径。它们可能包含模型授权、渠道登录态、session transcript、密钥和本机状态。

公开教程仓只能放脱敏说明和示例。私有 workspace 仓库也不要提交真实 token、OAuth 文件、密码和私密附件原文。

9. 共享入口怎么做

如果要给家人、公司同事或群聊使用，不要直接复用个人 main Agent。更稳的方式是单独建一个 shared Agent，给独立 workspace、独立 session、最少 tools 和尽量只读的访问策略。

共享入口只给完成任务必需的能力。需要写文件、执行命令、发消息、调用外部 API 时，再逐项增加，并重新跑 audit。

公司共享 Agent 可以接受的模式是：大家在同一个信任边界里，并且 runtime 是业务专用的。它应该运行在 dedicated machine / VM / container、dedicated OS user、dedicated browser profile 和 dedicated accounts 上。

不要把个人 Apple / Google 账号、个人密码管理器、个人浏览器 profile 混进公司共享 runtime。

10. 新手常见坑

• 把 pairing 当成唯一安全措施：它控制谁能连上，不等于工具权限最小化。
• 让群聊接入个人 Agent：群里任何允许用户都可能诱导工具调用。
• 公网暴露 Gateway 端口：没有 VPN / TLS / auth / trusted proxy 时风险很高。
• 打开危险 Control UI flag 后忘记关闭。
• 把 sessionKey 当授权边界：官方明确它是路由和上下文选择，不是用户认证。
• 把 workspace 备份到公开仓库：长期记忆和运行时凭据很容易混在一起。
• 只靠 prompt 规则防 prompt injection：真正边界要靠 channel policy、tool policy、sandbox、host isolation。

11. 怎么验收

你能明确说出：谁能发消息、谁能打开 Control UI、Gateway 绑定在哪个地址、远程访问走 Tailscale / SSH tunnel / TLS 反代中的哪一种。

你能跑完 security audit，并解释每个 warning 是已修复、已接受，还是需要拆分 Gateway。

你能证明共享入口没有使用个人 workspace、个人浏览器 profile、个人账号和个人密钥。

你能证明运行时凭据没有进入 workspace git，也没有出现在日志里。

12. 本章自检

1. 为什么 OpenClaw 不是互不信任用户共享的多租户安全边界？
2. 远程访问为什么优先 Tailscale / SSH tunnel，而不是直接公网端口？
3. sandbox、pairing、tool policy 各自管什么？

13. 接下来去哪

14. 官方资料

• Security
• Security audit checks
• Remote access
• Tailscale
• Sandboxing