Руководство по открытию доступа к Gateway

Этот регламент превращает более общее руководство по безопасности в контрольный список оператора для удаленного доступа и доступа через каналы обмена сообщениями.

Выберите схему открытия доступа

Предпочитайте самую узкую схему, которая удовлетворяет рабочему процессу.

Избегайте прямого публичного проброса портов к Gateway. Если вам нужен публичный доступ, поставьте перед ним прокси с учетом идентификации и сделайте этот прокси единственным сетевым путем к Gateway.

Инвентаризация перед запуском

Зафиксируйте это перед изменением политики bind, proxy, Tailscale или каналов:

• Хост Gateway, пользователь ОС и каталог состояния.
• URL Gateway и режим bind.
• Режим аутентификации, источник токена/пароля или источник идентификации доверенного proxy.
• Все включенные каналы и принимают ли они личные сообщения, группы или webhooks.
• Агенты, доступные нелокальным отправителям.
• Профиль инструментов, режим sandbox и политика повышенных инструментов для каждого доступного агента.
• Внешние учетные данные, доступные этим агентам.
• Расположение резервной копии для ~/.openclaw/openclaw.json и учетных данных.

Если боту может писать больше одного человека, считайте это общей делегированной властью над инструментами, а не изоляцией хоста для каждого пользователя.

Базовые проверки

Выполните их перед открытием доступа:

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

Сначала устраните критические находки. Предупреждения могут быть приемлемы только тогда, когда они намеренны и задокументированы для развертывания.

Для удаленной проверки CLI передавайте учетные данные явно:

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

Не предполагайте, что учетные данные из локальной конфигурации применяются к явно указанному удаленному URL.

Минимальная безопасная базовая конфигурация

Используйте эту форму как отправную точку для развертываний с открытым доступом:

{  gateway: {    bind: "loopback",    auth: {      mode: "token",      token: "replace-with-a-long-random-token",    },  },  session: {    dmScope: "per-channel-peer",  },  agents: {    defaults: {      sandbox: { mode: "non-main" },    },  },  tools: {    profile: "messaging",    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

Затем расширяйте по одной мере контроля за раз. Например, добавьте allowlist для конкретного канала перед включением инструментов с возможностью записи или включите reverse proxy перед приемом удаленного трафика Control UI.

Строгая базовая настройка exec.security: "deny" блокирует все вызовы exec, включая безопасную диагностику. Если диагностика или команды с низким риском обязательны, ослабляйте это только после выбора конкретных отправителей, агентов, команд и режима подтверждения, которые соответствуют вашей модели угроз.

Доступ через личные сообщения и группы

Каналы обмена сообщениями являются недоверенными поверхностями ввода. Перед разрешением личных сообщений или групп:

• Предпочитайте dmPolicy: "pairing" или строгие списки allowFrom.
• Избегайте dmPolicy: "open", если не доверяете каждому отправителю.
• Не сочетайте allowlist "*" с широким доступом к инструментам.
• Требуйте упоминания в группах, если комната не находится под строгим контролем.
• Используйте session.dmScope: "per-channel-peer", когда несколько людей могут писать боту в личные сообщения.
• Направляйте общие каналы к агентам с минимальным набором инструментов и без личных учетных данных.

Pairing разрешает отправителю запускать бота. Он не делает этого отправителя отдельной границей безопасности хоста.

Проверки reverse proxy

Для прокси с учетом идентификации:

• Прокси должен аутентифицировать пользователей перед пересылкой в Gateway.
• Прямой доступ к порту Gateway должен быть заблокирован firewall или сетевой политикой.
• gateway.trustedProxies должен содержать только исходные IP-адреса прокси.
• Прокси должен удалять или перезаписывать предоставленные клиентом заголовки идентификации и пересылки.
• gateway.auth.trustedProxy.allowUsers должен перечислять ожидаемых пользователей, когда прокси обслуживает больше одной аудитории.
• Режим loopback-прокси на том же хосте должен использовать allowLoopback только тогда, когда локальным процессам доверяют и прокси владеет заголовками идентификации.

Запустите openclaw security audit --deep после изменений proxy. Находки trusted-proxy намеренно имеют высокий сигнал, потому что прокси становится границей аутентификации.

Проверка инструментов и sandbox

Перед открытием агента для удаленных отправителей:

• Подтвердите, какие сессии выполняются на хосте, а какие в sandbox.
• Запретите host exec или требуйте подтверждения для него.
• Держите повышенные инструменты отключенными, если они не нужны конкретному доверенному отправителю.
• Избегайте инструментов browser, canvas, node, cron, gateway и session-spawn для открытых или полуоткрытых поверхностей обмена сообщениями.
• Делайте bind mounts узкими и избегайте учетных данных, домашнего каталога, Docker socket и системных путей.
• Используйте отдельные gateways, пользователей ОС или хосты для существенно разных границ доверия.

Если удаленным пользователям нельзя полностью доверять, изоляция должна обеспечиваться отдельными развертываниями, а не только prompts или метками сессий.

Проверка после изменений

После каждого изменения доступа:

1. Повторно запустите openclaw security audit --deep.
2. Проверьте успешное авторизованное подключение.
3. Проверьте, что неавторизованный отправитель или браузерная сессия получают отказ.
4. Убедитесь, что логи редактируют секреты.
5. Убедитесь, что маршрутизация личных сообщений/групп достигает только нужного агента.
6. Убедитесь, что инструменты с высоким влиянием запрашивают подтверждение или запрещены.
7. Задокументируйте принятые остаточные предупреждения.

Не переходите к следующему изменению доступа, пока текущее не будет понято.

План отката

Если Gateway может быть чрезмерно открыт:

{  gateway: {    bind: "loopback",  },  channels: {    whatsapp: { dmPolicy: "disabled" },    telegram: { dmPolicy: "disabled" },    discord: { dmPolicy: "disabled" },    slack: { dmPolicy: "disabled" },  },  tools: {    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

Затем:

1. Остановите публичную пересылку, Tailscale Funnel или маршруты reverse proxy.
2. Ротируйте токены/пароли Gateway и затронутые учетные данные интеграций.
3. Удалите "*" и неожиданных отправителей из allowlists.
4. Просмотрите недавние audit logs, историю запусков, вызовы инструментов и изменения конфигурации.
5. Повторно запустите openclaw security audit --deep.
6. Снова включите доступ по самой узкой схеме, которая удовлетворяет рабочему процессу.

Контрольный список проверки

• Gateway остается доступным только через loopback, если нет задокументированной причины.
• Доступ не через loopback имеет аутентификацию, firewall и не имеет прямого публичного маршрута.
• Развертывания trusted-proxy имеют строгие IP-адреса proxy и контроль заголовков.
• Личные сообщения используют pairing или allowlists, а не открытый доступ по умолчанию.
• Группы требуют упоминаний или явных allowlists.
• Общие каналы не получают доступ к личным учетным данным.
• Неосновные сессии выполняются в режиме sandbox.
• Host exec и повышенные инструменты запрещены или требуют подтверждения.
• Логи редактируют секреты.
• Критические находки аудита устранены.
• Шаги отката протестированы и задокументированы.