Инструкция по предоставлению доступа к Gateway

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

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

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

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

Предварительная инвентаризация

Зафиксируйте следующие сведения перед изменением политики привязки, прокси, Tailscale или каналов:

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

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

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

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

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

Сначала устраните критические замечания. Принимайте предупреждения только в том случае, если они являются намеренными и задокументированы для данного развёртывания. Описание каждого checkId и соответствующего ключа исправления см. в разделе Проверки аудита безопасности.

Для удалённой проверки через 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 },  },}

Расширяйте по одной мере контроля за раз: добавьте список разрешений для конкретного канала перед включением инструментов с возможностью записи или включите обратный прокси перед приёмом удалённого трафика Control UI.

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

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

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

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

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

Проверки обратного прокси

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

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

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

Проверка инструментов и изоляции

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

• Проверьте, какие сеансы выполняются на хосте, а какие — в изолированной среде.
• Запретите выполнение команд на хосте или требуйте подтверждения.
• Не включайте инструменты с повышенными привилегиями, если они не нужны конкретному доверенному отправителю.
• Не предоставляйте инструменты браузера, canvas, node, cron, gateway и создания сеансов для открытых или полуоткрытых поверхностей обмена сообщениями.
• Ограничивайте точки монтирования; избегайте путей к учётным данным, домашним каталогам, сокету Docker и системным ресурсам.
• Используйте отдельные экземпляры Gateway, пользователей ОС или хосты для существенно различающихся границ доверия.

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

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

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

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 или маршруты обратного прокси.
2. Смените токены/пароли Gateway и затронутые учётные данные интеграций.
3. Удалите "*" и неожиданных отправителей из списков разрешений.
4. Проверьте последние журналы аудита, историю запусков, вызовы инструментов и изменения конфигурации.
5. Повторно запустите openclaw security audit --deep.
6. Повторно включите доступ, используя наиболее узкую схему, удовлетворяющую требованиям рабочего процесса.

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

• Gateway остаётся доступным только через loopback-интерфейс, если нет задокументированной причины для иного.
• Доступ не через loopback-интерфейс защищён аутентификацией и межсетевым экраном и не имеет прямого публичного маршрута.
• В развёртываниях с доверенным прокси строго ограничены IP-адреса прокси и контролируются заголовки.
• Для личных сообщений по умолчанию используются сопряжение или списки разрешений, а не открытый доступ.
• В группах требуются упоминания или явные списки разрешений.
• Общие каналы не имеют доступа к личным учётным данным.
• Сеансы, отличные от основного, выполняются в режиме изоляции.
• Выполнение команд на хосте и инструменты с повышенными привилегиями запрещены или требуют подтверждения.
• Секреты скрываются в журналах.
• Критические замечания аудита устранены.
• Шаги отката проверены и задокументированы.