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

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

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

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

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

Схема	Рекомендуется, когда	Обязательные меры контроля
Loopback + SSH-туннель	Личное использование, административный доступ, отладка	Оставьте `gateway.bind: "loopback"` и туннелируйте `127.0.0.1:18789`
Loopback + Tailscale Serve	Личный доступ из tailnet к Control UI/WebSocket	Оставьте Gateway доступным только через loopback; полагайтесь на заголовки идентификации Tailscale только для поддерживаемых поверхностей
Привязка к tailnet/LAN	Выделенная частная сеть с известными устройствами	Аутентификация Gateway, allowlist в firewall, без публичного проброса портов
Доверенный reverse proxy	SSO/OIDC организации перед Gateway	Аутентификация `trusted-proxy`, строгие `trustedProxies`, правила перезаписи/удаления заголовков, явно разрешенные пользователи
Публичный интернет	Редкие развертывания с высоким риском	Прокси с учетом идентификации, TLS, ограничения частоты, строгие allowlist, изолированные неосновные сессии

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

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

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

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

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

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

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

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw 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 или метками сессий.

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

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

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

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

План отката

Если 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 },
  },
}

Затем:

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

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

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

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

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

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

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

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

​Проверки reverse proxy

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

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

​План отката

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