配置安全與遠端訪問

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