--- read_when: - Публикация Gateway через LAN, tailnet, Tailscale Serve, Funnel или обратный прокси - Проверка развертывания перед допуском реальных пользователей мессенджинга - Откат рискованной конфигурации удаленного доступа или личных сообщений sidebarTitle: Exposure runbook summary: Предварительный контрольный список и список отката перед открытием OpenClaw Gateway за пределами loopback title: Руководство по открытию доступа к Gateway x-i18n: generated_at: "2026-06-28T23:00:59Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: c5e94cc03b9d79a03eb16aa04bad0fd311b72f27f14182c036832382dbce3d0f source_path: gateway/security/exposure-runbook.md workflow: 16 --- Открывайте Gateway только после того, как сможете объяснить, кто может получить к нему доступ, как они аутентифицируются, каких агентов они могут запускать и какие инструменты эти агенты могут использовать. Если сомневаетесь, вернитесь к доступу только через loopback и повторно выполните аудит. Этот регламент превращает более общее руководство по [безопасности](/ru/gateway/security) в контрольный список оператора для удаленного доступа и доступа через каналы обмена сообщениями. ## Выберите схему открытия доступа Предпочитайте самую узкую схему, которая удовлетворяет рабочему процессу. | Схема | Рекомендуется, когда | Обязательные меры контроля | | -------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------- | | 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` и учетных данных. Если боту может писать больше одного человека, считайте это общей делегированной властью над инструментами, а не изоляцией хоста для каждого пользователя. ## Базовые проверки Выполните их перед открытием доступа: ```bash openclaw doctor openclaw security audit openclaw security audit --deep openclaw health ``` Сначала устраните критические находки. Предупреждения могут быть приемлемы только тогда, когда они намеренны и задокументированы для развертывания. Для удаленной проверки CLI передавайте учетные данные явно: ```bash openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN" ``` Не предполагайте, что учетные данные из локальной конфигурации применяются к явно указанному удаленному URL. ## Минимальная безопасная базовая конфигурация Используйте эту форму как отправную точку для развертываний с открытым доступом: ```json5 { 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 может быть чрезмерно открыт: ```json5 { 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 и повышенные инструменты запрещены или требуют подтверждения. - Логи редактируют секреты. - Критические находки аудита устранены. - Шаги отката протестированы и задокументированы.