安全加固（一）：访问控制与身份
一句话目标：这一课是 OpenClaw 安全加固的第一课，帮你收紧访问面——认清 Gateway 信任边界、管住谁能连上来、让每个审批都绑定到确切的人。
准备
- 已装好 OpenClaw（v2026.8.1 及以上，即 OpenClaw 2.0；写作时仓库版本为 2026.10.9），Node 24.16.0+ 或 26.1.0+。
- Gateway 已在你自己的机器上运行，并至少接入一个渠道（Telegram、Slack、Discord 等 20+ 渠道之一）。
- 建议先过一遍进阶手册：Skills 与安全加固。
先建立一个认知：OpenClaw 是自托管网关，没有托管服务，状态、记忆、凭据全部留在你自己的硬件上；一个 Gateway 进程就是整个信任边界，模型与 agent harness（Claude、Codex、本地模型）都只是可替换的插件。安全加固，就是缩小这个边界对外的暴露面。
跟我做
第 1 步：认清信任边界，用 dmPolicy 与白名单管住渠道入口
先在运行 Gateway 的机器上画出链路：「用户 → 渠道 → Gateway → 模型」。每接入一个渠道（Telegram、Slack、Discord……），就多一个能触达信任边界的入口。管住私聊入口的第一道闸门，是每个支持私聊的渠道都有的 dmPolicy：
dmPolicy 取值 | 行为 |
|---|---|
pairing（默认） | 陌生发送者收到一个配对码，批准前消息被忽略；配对码 1 小时过期，每个渠道挂起的配对请求最多 3 个 |
allowlist | 陌生发送者直接拒绝，没有配对握手 |
open | 任何人都能私聊；需渠道白名单包含 "*" 才生效（显式开通） |
disabled | 忽略所有入站私聊 |
默认的 pairing 已经很稳：陌生人在你批准前说不上话。有人私聊你的助手时，用这两条命令管理配对：
openclaw pairing list <channel> # <channel> 换成渠道名，如 telegram
openclaw pairing approve <channel> <code> # 批准后，对方才能与助手对话第二道闸门是白名单，分两层：
- 私聊层：
allowFrom（如channels.discord.allowFrom、channels.slack.allowFrom）决定谁能私聊助手；走配对批准的人会存入共享数据库（默认~/.openclaw/state/openclaw.sqlite），与配置白名单合并生效。 - 群组层：
channels.whatsapp.groups、channels.telegram.groups等决定助手接受哪些群，并可逐群设requireMention（必须 @ 它才响应）；设了groups就同时充当群白名单，想保留全部群写"*"。groupPolicy: "allowlist"加groupAllowFrom还能限制群内谁能触发它（WhatsApp/Telegram/Signal/iMessage/Teams 等渠道）。
💡 多人共用助手？隔离私聊会话
默认所有私聊汇进同一个主会话。如果有多人能私聊助手（多人白名单或 open），在 ~/.openclaw/openclaw.json 设置 session.dmScope: "per-channel-peer"，让每个「渠道 + 发送者」拿到隔离会话；openclaw security audit 检测到多用户私聊时也会给出同样建议。
预期结果：你得到一张入口清单，能明确回答「今天有哪些人、通过哪些渠道能和我的助手说话」；陌生发送者默认卡在配对这一关，批准前被忽略。
第 2 步：收紧 OpenClaw 安全的网络暴露面
渠道入口管住了，再看 Gateway 本身监听在哪：它用一个端口同时跑 WebSocket 和 HTTP，默认端口 18789（改端口用 gateway.port、--port 或环境变量 OPENCLAW_GATEWAY_PORT）。监听地址由 gateway.bind 决定：
"loopback"：常规主机默认，只有本机客户端能连。"auto"：容器里省略该配置时的默认，解析为0.0.0.0，方便端口转发与容器网络接入。"lan"/"tailnet"/"custom"：让更多客户端可达，必须同时配好认证和真正的防火墙。
规则很硬：非 loopback 启动必须配好认证，否则 Gateway 直接拒绝启动。远程访问优先走 Tailscale Serve（Gateway 保持 loopback，由 Tailscale 管住访问），而不是绑 LAN；绝不把无认证的 Gateway 暴露在 0.0.0.0。
认证默认就是必须的：没有有效认证路径时，Gateway 拒绝 WebSocket 连接；onboarding 默认会生成一个 token，本机客户端同样要认证。认证模式有三种，配在 gateway.auth：
token：共享 bearer token，多数部署的推荐选择。password：建议通过环境变量OPENCLAW_GATEWAY_PASSWORD设置。trusted-proxy：信任带身份认证的反向代理。
// ~/.openclaw/openclaw.json
{
gateway: {
bind: "loopback",
auth: { mode: "token", token: "replace-with-long-random-token" },
},
}这个 gateway token 用 openclaw doctor --generate-gateway-token 生成，或用 openssl rand -hex 32 自己造一个。注意：启动会拒绝空 token、字面量 undefined/null 和示例占位串；openclaw security audit 会对少于 24 字符的 token 报警。
预期结果：Gateway 只监听你允许的网络位置，且必须带认证才能连；从公网扫描你的机器，找不到 18789 端口上的 Gateway。
第 3 步：让审批绑定确切身份
让助手执行一个需要审批的敏感命令，观察审批提示里绑定的信息。OpenClaw 2.0 的安全模型把审批绑定到确切的请求、命令、会话和人：对陌生会话发来的敏感命令逐一人工确认，不要笼统放行。
预期结果：每次审批都能看到它来自哪个会话、哪个人、对应哪条命令，不存在「一个人批准、所有人放行」。
验证
- 用一个陌生账号向助手发私聊：默认
dmPolicy: "pairing"下，对方应收到一个配对码，且在你批准前被忽略；如果陌生人直接拿到完整能力，回到第 1、2 步收紧。 - 运行
openclaw pairing list <channel>，应能看到挂起的配对请求；用openclaw pairing approve <channel> <code>批准后，对方才能与助手对话。 - 从外部网络扫描你的公网 IP（如
nmap -sT -p 1-65535 <公网IP> --open），开放端口应只有你有意暴露的服务，看不到 18789 端口上的 Gateway。 - 触发一次需要审批的命令，核对审批信息是否显示确切的请求、命令、会话与人。
- 核对默认外联行为：OpenClaw 默认只做每日版本检查，匿名统计需要你主动 opt-in；想关掉版本检查，设置
update.checkOnStart: false。
常见坑
- 把 Gateway 当普通聊天机器人挂到公网。Gateway 是信任边界，暴露端口等于把凭据和记忆一并暴露。
- 图省事把
dmPolicy设成open。open让任何人都能私聊助手，且必须显式把渠道白名单设成"*"才生效——官方把它定位成「深思熟虑后的主动选择」，不是默认姿态。 - 以为数据在云端。状态、记忆、凭据都在你自己的硬件上，机器不安全，助手就不安全。
- 渠道越接越多，入口清单不更新。每接一个新渠道，都应回到第 1 步更新清单。
- 还在用 2.0 之前的版本。「审批绑定确切请求/命令/会话/人」是 v2026.8.1 引入的安全模型，旧版本请先升级再谈加固。
下一课
访问控制与身份，是 OpenClaw 安全的第一道门：陌生人过不了配对这一关，Gateway 不裸奔在公网，每次审批都对应确切的人。下一课安全加固（二）：工具权限与沙箱解决「进来之后能做什么」：限制工具权限、用沙箱隔离执行环境。